<div id="readability-page-1" class="page"><div id="contents">
      <article id="entry">
         <div> 
	
	
<p>아마존에서는 업무를 위한 소통과정에서 글쓰기를 매우 중요하게 생각합니다. 일상적인 대화, 미팅, 발표 등의 구두 방식의 모호함을 벗어나서 정보를 온전하게 기록하고 공유할 수 있기 때문인데요. 그중에서도 <a href="http://channy.creation.net/blog/1269">고객 중심 거꾸로 일하기</a>(Working Backward)를 실현할 수 있는 보도자료(PRFAQ) 문서, 최대 6장을 넘기지 않는 내러티브(Narrative) 문서 형식은 꽤 많이 알려져 있습니다. 사내 교육 프로그램에도 글쓰기 강좌가 있을 정도입니다.</p>



<p>이 글에서는 하나의 문장부터 시작해서, 문단, 팀 미팅 보고서 및 월간 보고서에  이르기까지 일상 업무 중에서 글 쓰기가 어떻게 이뤄지는지 살펴보겠습니다.</p>



<h3>1. 데이터를 기반한 명확한 문장</h3>



<p>어릴 때부터  학교에서 육하원칙(5W1H)에 따라 문장을 쓰라고 배웠습니다. 비즈니스 글쓰기에는 거기에 더해 2개의 How 즉, ‘How Much’와 ‘How Long’을 추가하라고 합니다. 그만큼 업무용 문장에는 데이터 포인트를 추가하는 것이 중요하다는 것을 알 수 있는데요. 널리 알려진 ‘아마존 글쓰기 스타일(Amazon Writing Style)’이라는 짤방에는 아마존에서 문장을 어떻게 쓰는지 몇 가지 사례가 나와 있습니다.</p>



<figure><img width="940" height="357" src="http://channy.creation.net/data/channy/2022/07/05030650/amazon_writing_style-940x357.png" alt="" sizes="(max-width: 940px) 100vw, 940px"><figcaption>Amazon Writing Style – 출처: LinkedIn (<a href="https://channy.creation.net/data/channy/2022/07/05030650/amazon_writing_style.png">크게 보기</a>)</figcaption></figure>



<ul><li>문장은 “주어-목적어-동사” 구조로 실행하는 주체와 행동을 명확히 쓴다. (예: 수동태 금지)</li><li>영어로 30단어 이하, 불필요한 구절을 안 쓴다. (예: due to the fact that -&gt; because)</li><li>약어는 처음에는 풀어 쓴다. (예: NDA -&gt; Non Disclosure Agreement (NDA)…)</li><li>모호한 ‘형용사’ 대신 데이터를 넣는다. (예: 대부분 AWS 고객 -&gt; 한국 AWS 계정의 86%)</li><li>모호한 ‘부사’ 대신 데이터를 넣는다. (예: 매출이 상당히 증가했다 -&gt; 매출이 40% 증가했다)</li></ul>



<p>군더더기 없이 핵심만 말하는 문장을 만들기 위한 위의 항목들은 당연한 것처럼 보이지만 쉽게 지키기 힘듭니다. 그래서 하나의 문장이라도 몇 번의 퇴고 과정을 늘 거치면서 다듬어야 합니다.</p>



<h3>2. 구조화된 문단 구성</h3>



<p>문장을 잘 쓰는 훈련을 했다면, 다음에는 문장들을 이은 구조화된 문단을 쓰는 방법입니다. 한 문단은 대략 3-4문장으로 이루어지는데, 이때 좋은 구조를 가지는 것이 중요합니다. 한 문단으로 간단한 보고를 할 때 쓸 수 있는 형식입니다.</p>



<ul><li><span>업무에 대한 정의 및 진행하게 된 이유</span></li><li><span>데이터와 함께 업무의 진행 결과 제시</span></li><li><span>업무 후 배운 점, 혹은 부족한 점 공유</span></li><li><span>다음 단계 혹은 미래의 계획 및 예상 결과</span></li></ul>



<p>위의 4가지 구조를 가지고 예시 문단을 한번 만들어 보겠습니다.</p>



<blockquote><p>“<span>차니의 클라우드 클리닉은 온라인 비디오 팟캐스트 시리즈로서, 팬데믹으로 인해 어려워진 오프라인 활동을 대체하기 위한 목적으로 시작하였습니다.</span> <span>2000년 3월부터 2021년 8월까지 국내 AWS 사용 개발자를 대상으로 AWS Hero 인터뷰, AWS 주요 소식, 아마존의 개발 문화 등을 주제로 총 30개의 에피소드를 진행하였으며, 유튜브에서만 총 20만 회 (목표 8만 회, 목표 대비 250%)의 시청 횟수를 기록하였습니다.</span> <span>각 에피소드의 콘텐츠 형식을 분석해 본 결과, 인터뷰어의 이야기를 듣는 대담 형식의 콘텐츠가 높은 관심을 얻었지만, 혼자서 진행하는 뉴스 형식은 낮은 조회수를 보였습니다.</span> <span>청취자 530명에 대한 설문 조사 결과, 60%가 AWS에 대한 신규 소식을 매월 계속 듣고 싶다고 응답하였기 때문에, 향후 시즌 2를 진행할 경우에는 AWS 전문가와 대담 형식으로 신규 서비스를 소개하는 에피소드를 제작할 계획입니다.</span>“</p></blockquote>



<h3>3. 똑같은 정보를 기반한 팀 미팅</h3>



<p>아마존 내부 팀 미팅 형식과 주기는 조금씩 차이는 있습니다만, 저희 팀은 2주마다 각자의 업무 보고 내용을 (위키나 노션과 유사한) 문서에 ‘잘한 점(Highlight), 못한 점(Lowlight), 진행 중(Download), 토론 주제(Discussion)’ 등을 나눠서 씁니다. 여기서 주목할 것은 각 항목을 구조화된 문장으로 적어도 1개 이상 써야 합니다. 2주 동안 일했는데 못했거나 아쉬운 일이 없을 수 없겠죠.</p>



<p>팀 회의가 시작되면, 15분 정도 각자가 미리 써 놓은 4가지 업무 항목들을 함께 읽는 시간을 가집니다. 이것은 아마존의 독특한 회의 방식인데, 문서를 함께 읽음으로써 모두 똑같은 정보를 가지고 회의에 참여할 수 있습니다. 6페이지 내러티브 같은 긴 문서를 읽을 때는 적어도 30분 정도 조용히 함께 읽습니다.</p>



<p>읽는 시간 동안에 가만히 있는 게 아니라, 펜으로 밑줄을 치면서 코멘트를 달기도 합니다. 오프라인 미팅에서는 종이로 인쇄된 문서에 질문이나 요청 사항을 적고, 회의 후에 작성자가 걷어가기도 하는데요. 온라인 문서와 미팅에서도 똑같은 방법으로 진행합니다. 너무 심각한 것만 공유하는 것은 아니구요. 때로는 영화 감상평을 올리면, 익살스러운 피드백을 남겨주기도 합니다.</p>



<figure><img loading="lazy" width="940" height="584" src="http://channy.creation.net/data/channy/2022/07/05031858/amazon-weekly-meeting-940x584.jpg" alt="" sizes="(max-width: 940px) 100vw, 940px"></figure>



<p>함께 읽기와 문서에 피드백을 주는 시간이 끝나면, 업무 보고 내용 중에서 몇 가지 토론 주제를 정해서 함께 이야기합니다. 업무 보고 같은 불필요한 시간을 줄이고 서로 질의응답을 통해 배우고 의견을 나누는 시간을 가지는 것입니다.</p>



<h3>4. 성과가 아닌 고객 중심 2×2 보고서</h3>



<p>아마존 내부에 여러 사업 조직 중에 AWS에서는 월간 보고서를 낼 때, 2×2 매트릭 형식을 널리 사용합니다. X-Y축의 관점에 따른 항목을 설정하고, 이를 기반으로 사분면에 해당 사항을 정리하는 것으로 가장 대표적인 예가 ‘강점(Strength) – 약점(Weakness) – 기회(Oppotunity) – 위협(Threat)’을 정리하는 SWOT 시장 분석이 있습니다.</p>



<p>2×2의 형식은 조금씩 다를 수는 있지만, 저희 팀에서는 업무 결과와 대상을 기준으로 ‘잘한 점(Highlight) – 못한 점(Lowlight) – 배운점(Insight) – 문제점(Challenge)’ 등 4가지 영역을 사용합니다. 눈치채셨겠지만, 격주간 미팅 때 쓴 문장과 문단을 붙여 넣기만 하더라도 손쉽게 개인 2×2를 채울 수 있습니다.</p>


<div>
<figure><img loading="lazy" width="500" height="707" src="http://channy.creation.net/data/channy/2022/07/05083204/amazon-2x2_matrix_swot_amazon-report-2.jpg" alt="" sizes="(max-width: 500px) 100vw, 500px"></figure></div>


<p>여기서도 4분면의 모든 항목을 한 개 이상 채워야 합니다. 일반적인 업무 보고는 높은 성과를 보인 결과를 위주로 하게 됩니다만, 2×2 매트릭에서는 그게 25%밖에 해당하지 않습니다. 각자의 업무 결과가 50%라면, 고객에서 얻은 배운 점과 고객이 겪는 문제점을 파악하는 것이 나머지 50%입니다.</p>



<p>개인 2×2는 워드 문서로 공유 폴더에 올리면, 팀 미팅 때와 마찬가지로 매니저와 팀원들이 밑줄 쫙 피드백을 해주면 이를 토대로 업데이트해서 최종본을 올립니다. 개인 2×2를 기초로 팀 2×2가 만들어지고, 팀 2×2가 취합되어 더 높은 조직 구조 단위의 2×2가 만들어져서, 최종적으로 CEO는 가장 중요한 항목만 담긴 2×2를 보게 됩니다.</p>



<h3>5. 예의 바른 태도와 정중한 표현</h3>



<p>아마존에서 명확한 글쓰기를 지향한다고 해서 현실에서 필요한 말만 하고 마는 것은 아닙니다. 이를 전달하는 방식은 예의 바르고 정중하게 합니다. 예를 들어, 각종 미팅에서 뿐만아니라 이메일이나 채팅 같은 업무 소통에서는 ‘Would you…’, ‘Please …’, ‘Thanks’ 같은 표현은 필수 요소입니다.</p>



<p>제가 가장 많이 쓰는 표현을 보면, 맨 처음에 ‘기다려 주셔서 감사합니다. (Thanks for your patience!)’나 맨 마지막에 ‘미리 감사드립니다. (Thanks in advance!)’입니다. 소통의 뼈대는 데이터를 기반한 명확한 문장, 구조화된 문단 구성 같은 원칙을 따르지만, 태도와 표현은 약간의 유머와 함께 인간적인 살을 붙여야 합니다.</p>



<p><a href="https://peerj.com/articles/cs-73/">정중함이 소프트웨어 프로젝트의 성공과 관련 있을까?</a>라는 주제의 연구 논문에 따르면, 오픈 소스 소프트웨어 프로젝트에서 개발자 간의 의사소통 과정에서 공손함의 정도가 문제 해결에 소요되는 시간에 영향을 미치는 것으로 나타났으며, 프로젝트의 능동성과 매력도와 양의 상관관계를 보였다고 합니다. 예의 바른 개발자일수록 문제를 해결하는 데 걸리는 시간이 줄어든다고 합니다. 거들먹거리거나, 기계적이고 비관적인 <a href="https://edykim.com/ko/post/tech-has-a-toxic-tone-problem-lets-fix-it/">독성 말투</a>는 지양해야 합니다.</p>



<figure><img loading="lazy" width="940" height="471" src="http://channy.creation.net/data/channy/2022/07/05034627/2022-sw-manners-comment-940x471.jpg" alt="" sizes="(max-width: 940px) 100vw, 940px"><figcaption>소스 코드 커밋 메시지 중 정중한 표현 정도의 차이 (출처: <a href="https://peerj.com/articles/cs-73/">Giuseppe Destefanis et al, 2016</a>)</figcaption></figure>



<p>물론 회사에서 만드는 상업용 소프트웨어 개발에 100% 적용된다고 볼 수는 없습니다만, 소프트웨어 개발 과정에서 인간적인 측면을 무시하는 것은 잠재적으로 소프트웨어 생산 프로세스와 팀 효율성에 막대한 영향을 미칠 수 있습니다. 또 다른 <a href="https://peerj.com/articles/289/">연구 결과</a>에서도 정서적 상태와 창의성 및 분석적 문제 해결 기술 간의 상관관계를 조사한 결과, 행복한 개발자가 분석 능력 면에서 실제로 더 나은 문제 해결사라고 합니다.</p>



<p>합리적이고 논리적이면서도 가슴이 따듯한 개발자가 됩시다!</p>
<div><h3>더 읽어 볼 글</h3></div>	

	<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>- ;</small></p>

	
	

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

Channy's Blog

아마존에서는 업무를 위한 소통과정에서 글쓰기를 매우 중요하게 생각합니다. 일상적인 대화, 미팅, 발표 등의 구두 방식의 모호함을 벗어나서 정보를 온전하게 기록하고 공유할 수 있기 때문인데요. 그중에서도 고객 중심 거꾸로 일하기(Working Backward)를 실현할 수 있는 보도자료(PRFAQ) 문서, 최대 6장을 넘기지 않는 내러티브(Narrative) 문서 형식은 꽤 많이 알려져 있습니다. 사내 교육 프로그램에도 글쓰기 강좌가 있을 정도입니다.
이 글에서는 하나의 문장부터 시작해서, 문단, 팀 미팅 보고서 및 월간 보고서에  이르기까지 일상 업무 중에서 글 쓰기가 어떻게 이뤄지는지 살펴보겠습니다.
1. 데이터를 기반한 명확한 문장
어릴 때부터  학교에서 육하원칙(5W1H)에 따라 문장을 쓰라고 배웠습니다. 비즈니스 글쓰기에는 거기에 더해 2개의 How 즉, ‘How Much’와 ‘How Long’을 추가하라고 합니다. 그만큼 업무용 문장에는 데이터 포인트를 추가하는 것이 중요하다는 것을 알 수 있는데요. 널리 알려진 ‘아마존 글쓰기 스타일(Amazon Writing Style)’이라는 짤방에는 아마존에서 문장을 어떻게 쓰는지 몇 가지 사례가 나와 있습니다.
문장은 “주어-목적어-동사” 구조로 실행하는 주체와 행동을 명확히 쓴다. (예: 수동태 금지)
영어로 30단어 이하, 불필요한 구절을 안 쓴다. (예: due to the fact that -> because)
약어는 처음에는 풀어 쓴다. (예: NDA -> Non Disclosure Agreement (NDA)…)
모호한 ‘형용사’ 대신 데이터를 넣는다. (예: 대부분 AWS 고객 -> 한국 AWS 계정의 86%)
모호한 ‘부사’ 대신 데이터를 넣는다. (예: 매출이 상당히 증가했다 -> 매출이 40% 증가했다)
군더더기 없이 핵심만 말하는 문장을 만들기 위한 위의 항목들은 당연한 것처럼 보이지만 쉽게 지키기 힘듭니다. 그래서 하나의 문장이라도 몇 번의 퇴고 과정을 늘 거치면서 다듬어야 합니다.
2. 구조화된 문단 구성
문장을 잘 쓰는 훈련을 했다면, 다음에는 문장들을 이은 구조화된 문단을 쓰는 방법입니다. 한 문단은 대략 3-4문장으로 이루어지는데, 이때 좋은 구조를 가지는 것이 중요합니다. 한 문단으로 간단한 보고를 할 때 쓸 수 있는 형식입니다.
업무에 대한 정의 및 진행하게 된 이유
데이터와 함께 업무의 진행 결과 제시
업무 후 배운 점, 혹은 부족한 점 공유
다음 단계 혹은 미래의 계획 및 예상 결과
위의 4가지 구조를 가지고 예시 문단을 한번 만들어 보겠습니다.
“차니의 클라우드 클리닉은 온라인 비디오 팟캐스트 시리즈로서, 팬데믹으로 인해 어려워진 오프라인 활동을 대체하기 위한 목적으로 시작하였습니다. 2000년 3월부터 2021년 8월까지 국내 AWS 사용 개발자를 대상으로 AWS Hero 인터뷰, AWS 주요 소식, 아마존의 개발 문화 등을 주제로 총 30개의 에피소드를 진행하였으며, 유튜브에서만 총 20만 회 (목표 8만 회, 목표 대비 250%)의 시청 횟수를 기록하였습니다. 각 에피소드의 콘텐츠 형식을 분석해 본 결과, 인터뷰어의 이야기를 듣는 대담 형식의 콘텐츠가 높은 관심을 얻었지만, 혼자서 진행하는 뉴스 형식은 낮은 조회수를 보였습니다. 청취자 530명에 대한 설문 조사 결과, 60%가 AWS에 대한 신규 소식을 매월 계속 듣고 싶다고 응답하였기 때문에, 향후 시즌 2를 진행할 경우에는 AWS 전문가와 대담 형식으로 신규 서비스를 소개하는 에피소드를 제작할 계획입니다.“
3. 똑같은 정보를 기반한 팀 미팅
아마존 내부 팀 미팅 형식과 주기는 조금씩 차이는 있습니다만, 저희 팀은 2주마다 각자의 업무 보고 내용을 (위키나 노션과 유사한) 문서에 ‘잘한 점(Highlight), 못한 점(Lowlight), 진행 중(Download), 토론 주제(Discussion)’ 등을 나눠서 씁니다. 여기서 주목할 것은 각 항목을 구조화된 문장으로 적어도 1개 이상 써야 합니다. 2주 동안 일했는데 못했거나 아쉬운 일이 없을 수 없겠죠.
팀 회의가 시작되면, 15분 정도 각자가 미리 써 놓은 4가지 업무 항목들을 함께 읽는 시간을 가집니다. 이것은 아마존의 독특한 회의 방식인데, 문서를 함께 읽음으로써 모두 똑같은 정보를 가지고 회의에 참여할 수 있습니다. 6페이지 내러티브 같은 긴 문서를 읽을 때는 적어도 30분 정도 조용히 함께 읽습니다.
읽는 시간 동안에 가만히 있는 게 아니라, 펜으로 밑줄을 치면서 코멘트를 달기도 합니다. 오프라인 미팅에서는 종이로 인쇄된 문서에 질문이나 요청 사항을 적고, 회의 후에 작성자가 걷어가기도 하는데요. 온라인 문서와 미팅에서도 똑같은 방법으로 진행합니다. 너무 심각한 것만 공유하는 것은 아니구요. 때로는 영화 감상평을 올리면, 익살스러운 피드백을 남겨주기도 합니다.
함께 읽기와 문서에 피드백을 주는 시간이 끝나면, 업무 보고 내용 중에서 몇 가지 토론 주제를 정해서 함께 이야기합니다. 업무 보고 같은 불필요한 시간을 줄이고 서로 질의응답을 통해 배우고 의견을 나누는 시간을 가지는 것입니다.
4. 성과가 아닌 고객 중심 2×2 보고서
아마존 내부에 여러 사업 조직 중에 AWS에서는 월간 보고서를 낼 때, 2×2 매트릭 형식을 널리 사용합니다. X-Y축의 관점에 따른 항목을 설정하고, 이를 기반으로 사분면에 해당 사항을 정리하는 것으로 가장 대표적인 예가 ‘강점(Strength) – 약점(Weakness) – 기회(Oppotunity) – 위협(Threat)’을 정리하는 SWOT 시장 분석이 있습니다.
2×2의 형식은 조금씩 다를 수는 있지만, 저희 팀에서는 업무 결과와 대상을 기준으로 ‘잘한 점(Highlight) – 못한 점(Lowlight) – 배운점(Insight) – 문제점(Challenge)’ 등 4가지 영역을 사용합니다. 눈치채셨겠지만, 격주간 미팅 때 쓴 문장과 문단을 붙여 넣기만 하더라도 손쉽게 개인 2×2를 채울 수 있습니다.
여기서도 4분면의 모든 항목을 한 개 이상 채워야 합니다. 일반적인 업무 보고는 높은 성과를 보인 결과를 위주로 하게 됩니다만, 2×2 매트릭에서는 그게 25%밖에 해당하지 않습니다. 각자의 업무 결과가 50%라면, 고객에서 얻은 배운 점과 고객이 겪는 문제점을 파악하는 것이 나머지 50%입니다.
개인 2×2는 워드 문서로 공유 폴더에 올리면, 팀 미팅 때와 마찬가지로 매니저와 팀원들이 밑줄 쫙 피드백을 해주면 이를 토대로 업데이트해서 최종본을 올립니다. 개인 2×2를 기초로 팀 2×2가 만들어지고, 팀 2×2가 취합되어 더 높은 조직 구조 단위의 2×2가 만들어져서, 최종적으로 CEO는 가장 중요한 항목만 담긴 2×2를 보게 됩니다.
5. 예의 바른 태도와 정중한 표현
아마존에서 명확한 글쓰기를 지향한다고 해서 현실에서 필요한 말만 하고 마는 것은 아닙니다. 이를 전달하는 방식은 예의 바르고 정중하게 합니다. 예를 들어, 각종 미팅에서 뿐만아니라 이메일이나 채팅 같은 업무 소통에서는 ‘Would you…’, ‘Please …’, ‘Thanks’ 같은 표현은 필수 요소입니다.
제가 가장 많이 쓰는 표현을 보면, 맨 처음에 ‘기다려 주셔서 감사합니다. (Thanks for your patience!)’나 맨 마지막에 ‘미리 감사드립니다. (Thanks in advance!)’입니다. 소통의 뼈대는 데이터를 기반한 명확한 문장, 구조화된 문단 구성 같은 원칙을 따르지만, 태도와 표현은 약간의 유머와 함께 인간적인 살을 붙여야 합니다.
정중함이 소프트웨어 프로젝트의 성공과 관련 있을까?라는 주제의 연구 논문에 따르면, 오픈 소스 소프트웨어 프로젝트에서 개발자 간의 의사소통 과정에서 공손함의 정도가 문제 해결에 소요되는 시간에 영향을 미치는 것으로 나타났으며, 프로젝트의 능동성과 매력도와 양의 상관관계를 보였다고 합니다. 예의 바른 개발자일수록 문제를 해결하는 데 걸리는 시간이 줄어든다고 합니다. 거들먹거리거나, 기계적이고 비관적인 독성 말투는 지양해야 합니다.
물론 회사에서 만드는 상업용 소프트웨어 개발에 100% 적용된다고 볼 수는 없습니다만, 소프트웨어 개발 과정에서 인간적인 측면을 무시하는 것은 잠재적으로 소프트웨어 생산 프로세스와 팀 효율성에 막대한 영향을 미칠 수 있습니다. 또 다른 연구 결과에서도 정서적 상태와 창의성 및 분석적 문제 해결 기술 간의 상관관계를 조사한 결과, 행복한 개발자가 분석 능력 면에서 실제로 더 나은 문제 해결사라고 합니다.
합리적이고 논리적이면서도 가슴이 따듯한 개발자가 됩시다!

아마존에서 배운 5가지 글쓰기와 소통 방식

댓글