<div id="readability-page-1" class="page"><div id="contents">
      <article id="entry">
         <div> 
	
	
<p>Amazon에서는 <a href="https://aws.amazon.com/ko/careers/culture/#Our_Leadership_Principles">14가지 리더쉽 원칙(Leadership Principles)</a>을 기준으로 모든 업무를 진행 합니다. <a href="https://aws.amazon.com/blogs/aws/">AWS News Blog</a>팀 대장 역할을 하고 계신 <a href="https://www.linkedin.com/in/jeffbarr/">Jeff Barr</a> 부사장님이 아마존 리더쉽 원칙에 기준으로 한 <a href="https://www.linkedin.com/pulse/leadership-principles-aws-news-bloggers-jeff-barr/">AWS News Blog 글쓰기 원칙</a>을 공유해 주셨습니다. 저도 2020년에 AWS News Blog팀에 참여하면서 내부적으로 공유받고 항상 유념하면서 블로그 글을 씁니다. 이 글에서는 해당 번역본과 함께, 제가 AWS News Blog를 쓰면서 개인적으로 느낀 점도 항목마다 괄호안에 넣어두었습니다.</p>



<figure><img decoding="async" width="940" height="600" src="https://channy.creation.net/data/channy/2020/08/14162431/2016-reinvent-jeff-barr-940x600.jpg" alt="" sizes="(max-width: 940px) 100vw, 940px"><figcaption>AWS News Blog를 시작하신 Jeff Barr (VP 및 AWS Chief Evangelist)와 함께</figcaption></figure>



<p><strong>◼ Customer Obsession (고객에 집착하라)</strong> – 여러분은 두 종류의 고객이 있습니다. 먼저, 여러분의 글을 읽고 있는 AWS 고객으로 가장 먼저 염두해 두셔야 하며, 그 분들은 한정된 시간과 관심을 가지고 있습니다. 두 번째는 함께 일하는 AWS 제품 팀으로 고객의 요구 사항에 충족하는 제품을 만들기 위해 열심히 노력해 왔습니다. 블로거로서 여러분은 독자들이 제품팀의 노력을 고맙게 느끼도록 해주셔야 합니다. (블로그 글을 게시한 후, 고객들로 부터 좋은 글 써 줘서 고맙다며, 꼭 사용해보고 싶다며 담당자와 연결해 달라는 경우가 참 많습니다. 이 때, 고객의 의견 및 연락처를 제품팀 담당자 전달하는 것이 제일 보람되는 것 중에 하나입니다.)</p>



<p><strong>◼ Ownership (주인 의식을 가져라)</strong> – 여러분의 이름은 AWS 서비스 출시 블로그 맨 마지막에 적히게 됩니다. 여러분의 하는 일에 자부심을 가지고 임하시기 바랍니다. (다른 회사 블로그를 보면, 대부분 제품 개발을 직접 담당한 분들이 출시 블로그 글을 씁니다. 대신, AWS는 News Blog팀의 각 블로거들이 제품팀의 의뢰를 받아 독자들의 입장에서 제품을 먼저 써보고 미리 경험한 것을 작성합니다. 제품팀이 직접 쓰면 될 걸 한 단계 더 거치는 것이 번거러울 수 있으나, 제3자 리뷰 과정을 거쳐서 더 품질 높고 완성된 기능을 만들 수 있다고 생각합니다. 제가 <a href="https://aws.amazon.com/blogs/aws/author/channy-yun/">최종적인 글 저자</a>가 되기 때문에, 하나의 출시 글을 완성하는데 몇 개월간 수십번의 리뷰 과정을 거칩니다.)</p>



<figure><img decoding="async" loading="lazy" width="940" height="552" src="https://channy.creation.net/data/channy/2022/08/30042506/2022-aws-news-blog-channy-yun-940x552.jpg" alt="" sizes="(max-width: 940px) 100vw, 940px"><figcaption>AWS News Blog의 저자별 블로그 글 목록</figcaption></figure>



<p><strong>◼ Invent and Simplify (발명하고 단순화하라)</strong> – 블로그 글을 작성하거나 제품을 설명하는 정해진 방법은 없습니다. 창의력을 발휘하여 자신에게 맞는 스타일과 목소리를 찾으세요. 풍부한 어휘를 사용하되 과시하기 위한 모호한 단어를 사용하지 마십시오. (Jeff는 각자 자기 자신의 이야기 방식을 가지도록 권장합니다. 제가 가진 원칙은 독자가 글을 읽는 5분 내에 신규 기능을 완전히 이해하도록 하자는 것입니다. 그래서, 서론은 가급적 짧게 하고, 본론인 ‘ 기능 시작하기 (Getting Started)’ 영역에서 스크린샷이나 샘플 코드를 간결하지만 풍부하게 넣습니다. 그리고, 마지막에 알아두어야 할 점이 있다면 자세히 넣는 편입니다.)</p>



<p><strong>◼ Are Right, A Lot (올바른 판단을 많이 하라)</strong> – 제품 기능을 설명하기 어렵거나, 콘솔 화면에 혼란스럽거나, 잘못된 텍스트가 포함되어 있는 경우, 제품팀에 올바른 의견을 제시하세요. 여러분은 출시될 신규 기능을 가장 먼저 본 고객일 것입니다. 여러분이 혼란스러우면 다른 AWS 고객들도 그럴 가능성이 높습니다. (실제로 알파/베타 기능을 맨 먼저 써 보면, 콘솔 화면 플로우가 이상하다던가 기능에 버그가 있다던가 하는 경우가 많습니다. 개발팀 슬랙 채널이나 이슈 트래커에 리포팅을 하기도 하구요. 마지막 블로그 글 작성 과정에서 꽤 많은 것이 수정됩니다.)</p>



<p><strong>◼ Learn and Be Curious (호기심을 가지고 배워라) </strong>– 다양한 기술 주제들이 처음에는 익숙하지 않을 것입니다. 하지만, 새로운 것을 배우고 “발빠른 전문가”가 될 수 있는 기회입니다. 여러분이 이해하기 어려운 주제라면, 한 명의 인간으로서 글에서 인정하셔도 됩니다. 모든 것을 아는 사람은 없습니다. 누구나 새롭고 복잡한 것에 배우려고 최선을 다하는 사람과 같은 마음을 가질겁니다. (AWS 서비스가 많기 때문에 News 블로그 팀 내에도 전문성을 나누고 있습니다. 저는 주로 컨테이너, DB/분석, 보안/네트워크 그리고 사물 인터넷 분야 서비스 출시를 주로 다룹니다. 그렇다고 다른 분야 서비스를 아예 다루지 않는 건 아니구요. 호기심과 배움을 충족하기 위해 가끔 다른 분야 출시 글도 맡게 됩니다.)</p>



<p><strong>◼ Insist on the Highest Standards (높은 기준을 고집하라)</strong> – 만약 제품이 아직 출시될 준비가 되지 않았다고 생각되면, 팀에게 의견을 제시하세요. 출시 기능이 아직 불완전하거나 사용하기 너무 어렵다면 미리 팀에게 알려주세요. (제품 출시를 연기해야 합니다.) 신규 기능이 좋은 첫인상을 남길 수 있는 기회는 단 한 번뿐입니다. (어떤 신규 기능은 진짜 준비가 안되어 있는 경우도 있어요. 제품팀의 사정에 따라, 출시 일정을 촉박하게 잡고 진행하고 있는 경우도 있구요. 이때, 제가 직접 의견을 말하지 않아도 자연스럽게 출시가 연기가 되는 경우가 많습니다. 저만 그렇게 생각하지 않는 것이죠. 어떤 출시는 몇 달 혹은 1년이 연기되는 경우도 있습니다.)</p>



<p><strong>◼ Think Big (크게 생각하라) </strong>– 신규 기능이나 서비스가 미칠 장기적인 영향에 대해 많이 생각해 주세요. 앞으로 이러한 서비스가 어디로 갈지에 대해 독자가 생각할 수 있는 힌트를 남겨주세요. (이 부분이 가장 어려운 부분이기도 합니다. AWS의 신규 출시 기능은 고객의 요구 사항을 토대로 만들어졌고, 고객이 어떤 방식으로 사용할지, 어떤 새로운 요구 사항이 생길지 예측하기가 어렵거든요. 다만, 신규 기능이 어떤 이유로 만들어졌고, 과거에 출시된 기능과 연계된 맥락을 기존 글 링크를 통해 소개하는 것을 중요하게 생각합니다. 이를 토대로 고객 스스로가 앞으로 무엇을 원하는지 깨달을 수 있기도 하니까요.)</p>


<div>
<figure><img decoding="async" loading="lazy" src="https://channy.creation.net/data/channy/2023/01/16044108/2022-reinvent-blog-slack.png" alt="" width="213" height="343" sizes="(max-width: 213px) 100vw, 213px"><figcaption>2022 리인벤트 출시를 위한 슬랙 채널</figcaption></figure></div>


<p><strong>◼ Bias for Action (먼저 행동하라)</strong> – 초기에 제품 팀과 자주 의견을 주고 받고, 필요한 문서나 자료를 전달 받으세요. PRFAQ 문서, 기능 API, 콘솔 베타 화면 및 사용 가능한 기술 문서를 빠르게 전달 받으시기 바랍니다. (대략 신규 기능 출시 3개월 전 부터 블로그 글 작성 의뢰가 들어옵니다. 글 작성에 필요한 정보를 전달 받아 직접 테스트 하고, 출시 한달 전 쯤 첫번째 초안을 전달합니다. 최소 10여회 이상 초안을 다듬으면서 제품팀과 의견 조율을 합니다. 슬랙 채널을 통해 빠르게 의견을 교환해야 하는 것도 있지만, 제품 관리자, 제품 마케팅 관리자, 개발팀 관리자, 시니어 개발자, 필요에 따라 법무 혹은 PR 담당자 등 워낙 많은 분들이 관여하기 때문에 중요한 의사 결정은 꼭 이슈 티켓에 남기구요. 블로거가 주도적으로 피드백을 주고 받아야만 합니다.)</p>



<p><strong>◼ Frugality (절약하라) </strong>– 여러분과 독자의 시간을 모두 절약하세요. 여러분의 시간을 아낄 수 있게 제품팀의 출시 기능 목록과 한계점을 명확하게 전달 받으세요. 독자들의 시간을 절약하도록 글을 간결하게 유지하고 독자가 짧은 시간에 기능을 바로 이해하도록 하세요. (아무래도 제품팀 입장에서는 신규 기능에 대해 최대한 많은 설명을 넣고 싶어합니다. 하지만, 독자들은 짧은 시간에 글을 읽기 때문에 너무 길게 쓸 수가 없습니다. 이를 조율하는 것이 상당히 어렵습니다. 단계별로 기능을 설명 할때, 굳이 설명할 필요가 없거나 더 자세한 것은 기술 문서나 다른 블로그 글을 참조하도록 하면서 간결하게 쓰기위해서 노력합니다.)</p>



<p><strong>◼ Earn Trust (신뢰를 얻어라)</strong> – AWS 내 해당 주제에 대해 신뢰할 수 있는 권위자가 되세요. 글 내용이 100% 정확하도록 노력하고, 잘못된 것이 있다면 바로 인정하고 수정하세요. (같은 분야의 출시 글을 여러번 다루다 보면, 같은 제품팀의 같은 분들과 다시 협업하는 일이 많이 생깁니다. 다음에 또 다시 만날 수 있는 분들이라 신뢰를 주기 위해 노력합니다. 글 내용의 정확성 뿐만 아니라 협업 사이클도 중요한데요. 특히, 시차가 있기 때문에 시애틀 업무 시간에 맞추어 매일 늦은 밤과 아침 시간 두번의 피드백을 주려고 합니다. 제 업무 시간을 고집하면, 항상 피드백 주기가 하루가 늦어지니까요.)</p>



<p><strong>◼ Dive Deep (깊이 파고들어라)</strong> – 여러분이 다룰 주제를 심층적으로 연구하고 도전적인 질문을 함으로써 제품팀과 신뢰를 쌓으세요. (신규 기능을 최대한 간략하게 소개하다 보면 이러한 원칙을 지키기 어려울 때가 많습니다. 그래서, 기능 외적으로 몇 가지 영역은 심층적으로 살펴 봅니다. 대표적으로 고객이 서비스 기능상 보안을 어떻게 지킬 수 있는지, 신규 기능을 다른 AWS 서비스와 어떻게 연계해서 사용 가능한지, 그리고 대안 AWS 기능이 무엇이 있는지 등을 많이 질문합니다. 이렇게 얻은 해답을 “알아두어야 할 점 (Things to Know)”에 요약해서 자세히 넣기도 합니다.)</p>



<p><strong>◼ Have Backbone; Disagree and Commit (기개를 가지고, 반대하거나 받아들여라)</strong> – 제품팀의 의견이 어떤 식으로든 부족하다고 생각되면 블로그팀에 알리세요. 기능 재설계를 포함하여 개선하도록 강력히 권장할 것입니다. 다만, 제품팀의 응답에 따라 전략적 이유로 있는 그대로 출시해야 하는 경우도 있음을 인정해야 합니다. (제품팀과 블로거 사이 의견 충돌이 있을 때, Jeff와 제품 출시 마케팅팀이 도움을 주게 됩니다. 아무래도 VP 레벨인 Jeff가 나서서 최대한 블로거의 의사를 존중하도록 의견을 조율해 주기 때문에 힘이 됩니다. 가끔 블로거 의견 보다는 이 기능을 사용할 고객과의 약속 같은 정당한 이유로 그대로 강행되는 경우도 있는데요. 이 때는 당연히 양보를 해야겠죠.)</p>



<figure><img decoding="async" loading="lazy" width="940" height="514" src="https://channy.creation.net/data/channy/2023/01/16045325/2022-aws-news-blog-iot-greengrass-940x514.jpg" alt="" sizes="(max-width: 940px) 100vw, 940px"><figcaption>Amazon Workdocs를 통한 제품팀과 블로그 초안 피드백 과정 사례 (<a href="https://aws.amazon.com/blogs/aws/announcing-aws-iot-greengrass-2-0-with-an-open-source-edge-runtime-and-new-developer-capabilities/">AWS IoT Greengrass 2.0</a>)</figcaption></figure>



<p><strong>◼ Hire and Develop the Best (최고 인재를 채용하고 육성하라)</strong> – 블로그팀에 새로운 블로거를 추가할 때마다, 채용 기준을 높이면서, 기존 멤버들이 성장할 공간을 제공해 주세요. 신규 멤버들이 배우고 성공하도록 도와주세요. (News 블로그팀에는 다양성을 존중합니다. 그래서, 성별 뿐만 아니라 북미 뿐만 아니라 유럽, 아시아, 아프리카 등 다양한 지역의 에반젤리스트들이 블로거로 참여하고 있습니다. 다양성은 배움을 제공합니다. 한쪽에 치우치지 않는 의견을 들을 수 있어서 좋습니다. 영어가 모국어가 아닌 분들도 있기 때문에 글 작성을 도와 주는 영문 카피 에디터분들에게도 많은 것을 배우고 있습니다.)</p>



<p><strong>◼ Deliver Results (성과를 내라) </strong>– AWS 고객이 우리의 신규 제품을 이해하고, 이를 바로 활용하는 데 도움이 되는 멋진 블로그 게시물을 작성해 주세요. (글을 완성하는 것도 성과이기도 하지만 이를 얼마나 많은 사람이 읽어 주느냐도 중요합니다. 그래서, 대부분 블로그 KPI를 페이지뷰나 방문자 숫자로 정하는 경우가 많습니다. 하지만, 방문자 수 보다는 글을 읽고 어떤 행동을 이끌어 내는지 정성적인 부분도 간과하면 안됩니다. 그래서, 단순 방문자수가 아니라 글을 읽고 어떤 행동을 했는지를 – 예를 들어, 신규 가입을 했는지, 콘솔 로그인을 했는지 등 – 측정한다던가, 소셜 미디어에 어떤 피드백을 남겼는지 등을 살펴 보는 것도 필요합니다.)</p>



<figure><img decoding="async" loading="lazy" width="940" height="419" src="https://channy.creation.net/data/channy/2023/01/16043245/2022-adrian-blog-comment-940x419.jpg" alt="" sizes="(max-width: 940px) 100vw, 940px"><figcaption>2022년 AWS re:Invent 출시 블로그 글에 대한 Adrian Cockcroft (Ex-VP of AWS)의 감사한 평가</figcaption></figure>



<p>지금까지 살펴본 대로, 아마존의 리더쉽 원칙은 여러분의 개별 업무에도 세세하게 적용할 수 있습니다. 다니는 회사가 다르고 분야가 달라도 일를 진행하는데 기본이 되는 원칙이라 볼 수 있으니까요. 재밌게도 어떤 직원 분들은 개인사에도 적용하는 경우도 봤습니다. 예를 들어, 아이들에게 “Customer Obssession” 원칙을 이야기 하면서 너의 고객이 누구냐? 고객이 엄마와 선생님이라면, 어떻게 해야 할까? 이런식으로 말했다던지… 친구들과 약속을 정하면서 “Bia For Action” 원칙에 따라 맛집을 예약했다고 농담처럼 이야기합니다.</p>



<p>새해에는 여러분의 일에 맞는 리더쉽 원칙을 한번 만들어 보는 게 어떨까요?</p>
<div><h3>더 읽어 볼 글</h3></div>	

<p><small>- ;</small></p>

	<p>※ <a href="http://channy.creation.net/about/#disclaimer" target="new">Disclaimer</a>- 본 글은 개인적인 의견일 뿐 제가 재직했거나 하고 있는 기업의 공식 입장을 대변하거나 그 의견을 반영하는 것이 아닙니다. 사실 확인 및 개인 투자의 판단에 대해서는 독자 개인의 책임에 있으며, 상업적 활용 및 뉴스 매체의 인용 역시 금지함을 양해해 주시기 바랍니다. (The opinions expressed here are my own and do not necessarily represent those of current or past employers. Please note that you are solely responsible for your judgment on checking facts for your investments and prohibit your citations as commercial content or news sources.)</p>



	<p><small>* 이 글의 댓글 일부는 <a href="https://indieweb.org/Webmention">Webmention</a> 도구를 이용하여, 소셜 미디어 공유 반응(Comments, Like, Tweet)을 수집한 것입니다.</small></p>

<div id="respond"><h3>답글 남기기</h3>





</div>
   </div></article>
</div></div>

Channy's Blog

Amazon에서는 14가지 리더쉽 원칙(Leadership Principles)을 기준으로 모든 업무를 진행 합니다. AWS News Blog팀 대장 역할을 하고 계신 Jeff Barr 부사장님이 아마존 리더쉽 원칙에 기준으로 한 AWS News Blog 글쓰기 원칙을 공유해 주셨습니다. 저도 2020년에 AWS News Blog팀에 참여하면서 내부적으로 공유받고 항상 유념하면서 블로그 글을 씁니다. 이 글에서는 해당 번역본과 함께, 제가 AWS News Blog를 쓰면서 개인적으로 느낀 점도 항목마다 괄호안에 넣어두었습니다.
 Customer Obsession (고객에 집착하라) – 여러분은 두 종류의 고객이 있습니다. 먼저, 여러분의 글을 읽고 있는 AWS 고객으로 가장 먼저 염두해 두셔야 하며, 그 분들은 한정된 시간과 관심을 가지고 있습니다. 두 번째는 함께 일하는 AWS 제품 팀으로 고객의 요구 사항에 충족하는 제품을 만들기 위해 열심히 노력해 왔습니다. 블로거로서 여러분은 독자들이 제품팀의 노력을 고맙게 느끼도록 해주셔야 합니다. (블로그 글을 게시한 후, 고객들로 부터 좋은 글 써 줘서 고맙다며, 꼭 사용해보고 싶다며 담당자와 연결해 달라는 경우가 참 많습니다. 이 때, 고객의 의견 및 연락처를 제품팀 담당자 전달하는 것이 제일 보람되는 것 중에 하나입니다.)
 Ownership (주인 의식을 가져라) – 여러분의 이름은 AWS 서비스 출시 블로그 맨 마지막에 적히게 됩니다. 여러분의 하는 일에 자부심을 가지고 임하시기 바랍니다. (다른 회사 블로그를 보면, 대부분 제품 개발을 직접 담당한 분들이 출시 블로그 글을 씁니다. 대신, AWS는 News Blog팀의 각 블로거들이 제품팀의 의뢰를 받아 독자들의 입장에서 제품을 먼저 써보고 미리 경험한 것을 작성합니다. 제품팀이 직접 쓰면 될 걸 한 단계 더 거치는 것이 번거러울 수 있으나, 제3자 리뷰 과정을 거쳐서 더 품질 높고 완성된 기능을 만들 수 있다고 생각합니다. 제가 최종적인 글 저자가 되기 때문에, 하나의 출시 글을 완성하는데 몇 개월간 수십번의 리뷰 과정을 거칩니다.)
 Invent and Simplify (발명하고 단순화하라) – 블로그 글을 작성하거나 제품을 설명하는 정해진 방법은 없습니다. 창의력을 발휘하여 자신에게 맞는 스타일과 목소리를 찾으세요. 풍부한 어휘를 사용하되 과시하기 위한 모호한 단어를 사용하지 마십시오. (Jeff는 각자 자기 자신의 이야기 방식을 가지도록 권장합니다. 제가 가진 원칙은 독자가 글을 읽는 5분 내에 신규 기능을 완전히 이해하도록 하자는 것입니다. 그래서, 서론은 가급적 짧게 하고, 본론인 ‘ 기능 시작하기 (Getting Started)’ 영역에서 스크린샷이나 샘플 코드를 간결하지만 풍부하게 넣습니다. 그리고, 마지막에 알아두어야 할 점이 있다면 자세히 넣는 편입니다.)
 Are Right, A Lot (올바른 판단을 많이 하라) – 제품 기능을 설명하기 어렵거나, 콘솔 화면에 혼란스럽거나, 잘못된 텍스트가 포함되어 있는 경우, 제품팀에 올바른 의견을 제시하세요. 여러분은 출시될 신규 기능을 가장 먼저 본 고객일 것입니다. 여러분이 혼란스러우면 다른 AWS 고객들도 그럴 가능성이 높습니다. (실제로 알파/베타 기능을 맨 먼저 써 보면, 콘솔 화면 플로우가 이상하다던가 기능에 버그가 있다던가 하는 경우가 많습니다. 개발팀 슬랙 채널이나 이슈 트래커에 리포팅을 하기도 하구요. 마지막 블로그 글 작성 과정에서 꽤 많은 것이 수정됩니다.)
 Learn and Be Curious (호기심을 가지고 배워라) – 다양한 기술 주제들이 처음에는 익숙하지 않을 것입니다. 하지만, 새로운 것을 배우고 “발빠른 전문가”가 될 수 있는 기회입니다. 여러분이 이해하기 어려운 주제라면, 한 명의 인간으로서 글에서 인정하셔도 됩니다. 모든 것을 아는 사람은 없습니다. 누구나 새롭고 복잡한 것에 배우려고 최선을 다하는 사람과 같은 마음을 가질겁니다. (AWS 서비스가 많기 때문에 News 블로그 팀 내에도 전문성을 나누고 있습니다. 저는 주로 컨테이너, DB/분석, 보안/네트워크 그리고 사물 인터넷 분야 서비스 출시를 주로 다룹니다. 그렇다고 다른 분야 서비스를 아예 다루지 않는 건 아니구요. 호기심과 배움을 충족하기 위해 가끔 다른 분야 출시 글도 맡게 됩니다.)
 Insist on the Highest Standards (높은 기준을 고집하라) – 만약 제품이 아직 출시될 준비가 되지 않았다고 생각되면, 팀에게 의견을 제시하세요. 출시 기능이 아직 불완전하거나 사용하기 너무 어렵다면 미리 팀에게 알려주세요. (제품 출시를 연기해야 합니다.) 신규 기능이 좋은 첫인상을 남길 수 있는 기회는 단 한 번뿐입니다. (어떤 신규 기능은 진짜 준비가 안되어 있는 경우도 있어요. 제품팀의 사정에 따라, 출시 일정을 촉박하게 잡고 진행하고 있는 경우도 있구요. 이때, 제가 직접 의견을 말하지 않아도 자연스럽게 출시가 연기가 되는 경우가 많습니다. 저만 그렇게 생각하지 않는 것이죠. 어떤 출시는 몇 달 혹은 1년이 연기되는 경우도 있습니다.)
 Think Big (크게 생각하라) – 신규 기능이나 서비스가 미칠 장기적인 영향에 대해 많이 생각해 주세요. 앞으로 이러한 서비스가 어디로 갈지에 대해 독자가 생각할 수 있는 힌트를 남겨주세요. (이 부분이 가장 어려운 부분이기도 합니다. AWS의 신규 출시 기능은 고객의 요구 사항을 토대로 만들어졌고, 고객이 어떤 방식으로 사용할지, 어떤 새로운 요구 사항이 생길지 예측하기가 어렵거든요. 다만, 신규 기능이 어떤 이유로 만들어졌고, 과거에 출시된 기능과 연계된 맥락을 기존 글 링크를 통해 소개하는 것을 중요하게 생각합니다. 이를 토대로 고객 스스로가 앞으로 무엇을 원하는지 깨달을 수 있기도 하니까요.)
 Bias for Action (먼저 행동하라) – 초기에 제품 팀과 자주 의견을 주고 받고, 필요한 문서나 자료를 전달 받으세요. PRFAQ 문서, 기능 API, 콘솔 베타 화면 및 사용 가능한 기술 문서를 빠르게 전달 받으시기 바랍니다. (대략 신규 기능 출시 3개월 전 부터 블로그 글 작성 의뢰가 들어옵니다. 글 작성에 필요한 정보를 전달 받아 직접 테스트 하고, 출시 한달 전 쯤 첫번째 초안을 전달합니다. 최소 10여회 이상 초안을 다듬으면서 제품팀과 의견 조율을 합니다. 슬랙 채널을 통해 빠르게 의견을 교환해야 하는 것도 있지만, 제품 관리자, 제품 마케팅 관리자, 개발팀 관리자, 시니어 개발자, 필요에 따라 법무 혹은 PR 담당자 등 워낙 많은 분들이 관여하기 때문에 중요한 의사 결정은 꼭 이슈 티켓에 남기구요. 블로거가 주도적으로 피드백을 주고 받아야만 합니다.)
 Frugality (절약하라) – 여러분과 독자의 시간을 모두 절약하세요. 여러분의 시간을 아낄 수 있게 제품팀의 출시 기능 목록과 한계점을 명확하게 전달 받으세요. 독자들의 시간을 절약하도록 글을 간결하게 유지하고 독자가 짧은 시간에 기능을 바로 이해하도록 하세요. (아무래도 제품팀 입장에서는 신규 기능에 대해 최대한 많은 설명을 넣고 싶어합니다. 하지만, 독자들은 짧은 시간에 글을 읽기 때문에 너무 길게 쓸 수가 없습니다. 이를 조율하는 것이 상당히 어렵습니다. 단계별로 기능을 설명 할때, 굳이 설명할 필요가 없거나 더 자세한 것은 기술 문서나 다른 블로그 글을 참조하도록 하면서 간결하게 쓰기위해서 노력합니다.)
 Earn Trust (신뢰를 얻어라) – AWS 내 해당 주제에 대해 신뢰할 수 있는 권위자가 되세요. 글 내용이 100% 정확하도록 노력하고, 잘못된 것이 있다면 바로 인정하고 수정하세요. (같은 분야의 출시 글을 여러번 다루다 보면, 같은 제품팀의 같은 분들과 다시 협업하는 일이 많이 생깁니다. 다음에 또 다시 만날 수 있는 분들이라 신뢰를 주기 위해 노력합니다. 글 내용의 정확성 뿐만 아니라 협업 사이클도 중요한데요. 특히, 시차가 있기 때문에 시애틀 업무 시간에 맞추어 매일 늦은 밤과 아침 시간 두번의 피드백을 주려고 합니다. 제 업무 시간을 고집하면, 항상 피드백 주기가 하루가 늦어지니까요.)
 Dive Deep (깊이 파고들어라) – 여러분이 다룰 주제를 심층적으로 연구하고 도전적인 질문을 함으로써 제품팀과 신뢰를 쌓으세요. (신규 기능을 최대한 간략하게 소개하다 보면 이러한 원칙을 지키기 어려울 때가 많습니다. 그래서, 기능 외적으로 몇 가지 영역은 심층적으로 살펴 봅니다. 대표적으로 고객이 서비스 기능상 보안을 어떻게 지킬 수 있는지, 신규 기능을 다른 AWS 서비스와 어떻게 연계해서 사용 가능한지, 그리고 대안 AWS 기능이 무엇이 있는지 등을 많이 질문합니다. 이렇게 얻은 해답을 “알아두어야 할 점 (Things to Know)”에 요약해서 자세히 넣기도 합니다.)
 Have Backbone; Disagree and Commit (기개를 가지고, 반대하거나 받아들여라) – 제품팀의 의견이 어떤 식으로든 부족하다고 생각되면 블로그팀에 알리세요. 기능 재설계를 포함하여 개선하도록 강력히 권장할 것입니다. 다만, 제품팀의 응답에 따라 전략적 이유로 있는 그대로 출시해야 하는 경우도 있음을 인정해야 합니다. (제품팀과 블로거 사이 의견 충돌이 있을 때, Jeff와 제품 출시 마케팅팀이 도움을 주게 됩니다. 아무래도 VP 레벨인 Jeff가 나서서 최대한 블로거의 의사를 존중하도록 의견을 조율해 주기 때문에 힘이 됩니다. 가끔 블로거 의견 보다는 이 기능을 사용할 고객과의 약속 같은 정당한 이유로 그대로 강행되는 경우도 있는데요. 이 때는 당연히 양보를 해야겠죠.)
 Hire and Develop the Best (최고 인재를 채용하고 육성하라) – 블로그팀에 새로운 블로거를 추가할 때마다, 채용 기준을 높이면서, 기존 멤버들이 성장할 공간을 제공해 주세요. 신규 멤버들이 배우고 성공하도록 도와주세요. (News 블로그팀에는 다양성을 존중합니다. 그래서, 성별 뿐만 아니라 북미 뿐만 아니라 유럽, 아시아, 아프리카 등 다양한 지역의 에반젤리스트들이 블로거로 참여하고 있습니다. 다양성은 배움을 제공합니다. 한쪽에 치우치지 않는 의견을 들을 수 있어서 좋습니다. 영어가 모국어가 아닌 분들도 있기 때문에 글 작성을 도와 주는 영문 카피 에디터분들에게도 많은 것을 배우고 있습니다.)
 Deliver Results (성과를 내라) – AWS 고객이 우리의 신규 제품을 이해하고, 이를 바로 활용하는 데 도움이 되는 멋진 블로그 게시물을 작성해 주세요. (글을 완성하는 것도 성과이기도 하지만 이를 얼마나 많은 사람이 읽어 주느냐도 중요합니다. 그래서, 대부분 블로그 KPI를 페이지뷰나 방문자 숫자로 정하는 경우가 많습니다. 하지만, 방문자 수 보다는 글을 읽고 어떤 행동을 이끌어 내는지 정성적인 부분도 간과하면 안됩니다. 그래서, 단순 방문자수가 아니라 글을 읽고 어떤 행동을 했는지를 – 예를 들어, 신규 가입을 했는지, 콘솔 로그인을 했는지 등 – 측정한다던가, 소셜 미디어에 어떤 피드백을 남겼는지 등을 살펴 보는 것도 필요합니다.)
지금까지 살펴본 대로, 아마존의 리더쉽 원칙은 여러분의 개별 업무에도 세세하게 적용할 수 있습니다. 다니는 회사가 다르고 분야가 달라도 일를 진행하는데 기본이 되는 원칙이라 볼 수 있으니까요. 재밌게도 어떤 직원 분들은 개인사에도 적용하는 경우도 봤습니다. 예를 들어, 아이들에게 “Customer Obssession” 원칙을 이야기 하면서 너의 고객이 누구냐? 고객이 엄마와 선생님이라면, 어떻게 해야 할까? 이런식으로 말했다던지… 친구들과 약속을 정하면서 “Bia For Action” 원칙에 따라 맛집을 예약했다고 농담처럼 이야기합니다.
새해에는 여러분의 일에 맞는 리더쉽 원칙을 한번 만들어 보는 게 어떨까요?

블로거 리더쉽 원칙

댓글