<div id="readability-page-1" class="page"><div id="contents">
      <article id="entry">
         <div> 
	
	
<p>몇 달 전 AWS에 입사한지 7년째 되는 날이었습니다. 마침 매니저와 1:1이 있었는데, 입사 7주년 축하를 해주면서 “7년이나 같은 일을 했는데, 뭔가 새로운 일을 하고 싶지 않으세요?”라고 물었습니다. 저는 “아니오. 저는 어떤 일을 시작했다면, 10년을 장기적인 관점으로 하기를 원하고, 아직은 3년이나 남았네요.”라고 대답했습니다. ’10년이면 강산도 변한다’는 한국 속담이 있죠. 세상을 바꿀 수 있는 시간인데요. 회사든 개인이든 장기적인 전략을 가져야 합니다.</p>



<p>어떻게 10년을 한 가지 일에만 몰두 할 수 있는지 물어보실 것 같습니다. 3년이 지나면 대개 흥미를 잃고 새로운 일을 하고 싶으니까요. 맞습니다! 적어도 3년에 한번씩 직무를 바꾸거나 회사를 옮기면서 과거의 컴포트(Comfort) 존을 벗어날 필요가 있지요. 하지만, 장기적으로 연속적인 맥락(Context)을 가지는 것도 중요합니다.</p>



<h3 id="커리어의-장기적-사이클-성장-리딩-경영"><strong>▩  커리어의 장기적 사이클 – 성장/리딩/경영</strong></h3>



<p>최근에 직장인과 개발자의 멘토 역할을 하고 계신 KT의 신수정 부사장님과 몰로코의 박종천님이 나란히 ‘<a href="http://www.yes24.com/Product/Goods/102485494">일의 격</a>‘과 ‘<a href="http://www.yes24.com/Product/Goods/105645204">개발자로 살아남기</a>‘라는 책을 쓰셨는데, 오래된 내공에서 공통된 맥락이 있었습니다. 즉, ‘일의 격’에서는 커리어에 대해 성장-성공(리더십)-성숙의 단계를, 그리고 ‘개발자로 살아남기’에서는 성장-리딩-지원(경영, 사업)의 단계로 설명해 주셨습니다. 특히, 박종천님은 본인의 30년의 경력을 10년 단위로 나눠서 각 단계에서 개발 직군에게 꼭 필요한 스킬과 경험 요소를 경험을 기반으로 잘 녹여 놓았기에 꼭 추천합니다.</p>



<figure><img width="800" height="500" src="http://channy.creation.net/data/channy/2022/01/27054455/2022-career-books.jpg" alt="" sizes="(max-width: 800px) 100vw, 800px"></figure>



<p>사실 이러한 단계는 ‘현업-팀장-임원’의 역할을 거칠때, 필연적으로 가지게 되는 것이죠. 다만, 누구는 몇 년안에 경험하기도 하고, 누구는 아예 거꾸로 경험하기도 하죠. 예를 들면, 저는 이 3단계를 첫 직장 7년사이에 압축적으로 겪었습니다. 그러다 보니, 그 후 두번의 10년을 좀 다른 방식을 나름대로 터득했는데요. 거창하게 책을 쓸 정도는 그냥 아니고, 누구에게는 도움이 될 수도 있다는 전제하에 간단하게 공유해 볼께요.</p>



<h3 id="1-3-3-3의-원칙으로-10년-경력-이어가기">▩ 1-3-3-3의 원칙으로 10년 경력 이어가기</h3>



<p>첫 10년은 대학에서의 학업과 함께 새로운 기회를 찾아, 인터넷 업계에서 7년간의 스타트업 생활을 했습니다. 닷컴 버블이 한창일 때라, 20대의 젊은 열정으로 오로지 (성공)하고 싶은 일에만 시간을 썼습니다. 도와주는 멘토도 없어서 <a href="http://channy.creation.net/blog/1077">좌충우돌 했던 스타트업 경험</a>은 개발자로서 팀장으로서 그리고 임원으로서도 모두 부족함 투성이었습니다. <em>(과로에 <a href="http://channy.creation.net/blog/1445">건강을 잃을 뻔</a>도 했습니다.)</em></p>



<p>그 후, 20년은 먹고 사는 생업을 하면서도, 뭔가 의미 있는 일을 하리라 결심했습니다. 나름 터득한 노하우가 바로 1-3-3-3 원칙인데요. 눈치 채셨겠지만, 10년 중 3년에 한번씩 전술적인 변화를 두는 것입니다. 바로 회사와 일이 나에게 맞는가?(1년), 신뢰를 쌓았는가? (3년), 질적 변화를 만들었나? (3년), 근본적 변화를 만들었나? (3년)를 고민하는 것입니다.</p>



<p><strong>회사/일 관찰하기 (1년) </strong>– 첫 일년이 매우 중요합니다. 저의 두번째 직장인 Daum을 예로 든다면, 입사 첫 해는 새로운 회사에 적응하면서 회사의 철학과 저의 생각이 잘 맞는지 알아보는데 시간을 보냈습니다. 어떤 일을 적어도 1년은 해봐야만 업의 본질을 알 수 있습니다. 그리고, 그 일을 하는 모태인 회사의 철학과 문화와 내가 하고 싶은 일과 잘 맞는지 알아가는 과정도 필요하죠. <em>(아니면 빨리 때려치워야 합니다. 사람과 회사는 고쳐쓰는 거 아닙니다.)</em></p>



<p><strong>신뢰 쌓아가기</strong>(3년) – 제가 맡은 일은 회사 내외부의 기술 관련자를 연결하고 소통하는 일이었는데요. 회사와 일이 마음에 맞으니, 초기 3년은 신뢰를 다지는 데 충실했습니다. “낮은데로 임하라”는 말이 있죠. 회사내에서 작은 팀을 맡으면서 온갖 개발팀의 채용 및 교육 지원, 사내 기술 에셋을 만들어 주는 일을 했구요. Daum이 <a href="http://channy.creation.net/blog/233">웹 표준 기술</a>에 관심 있었기 때문에, 회사의 배려로 외부 활동도 가능했습니다. 회사 밖에는 <a href="http://webstandards.or.kr/about/">수 많은 웹 표준 커뮤니티의 리더와 멤버</a>들은 저의 중요한 동료들이었습니다. 내외부 모두의 신뢰를 얻는 일은 단기간에 이뤄지지 않았습니다. <em>(적어도 3년은 걸리는 것 같습니다.)</em></p>



<p><strong>질적 변화 만들기</strong>(3년) – 신뢰가 어느 정도 쌓이자 내실에 집중하는 질적 변화에 매진했는데요. 새로운 일은 처음부터 내실을 다지긴 힘듭니다. 일단 작은 성과를 축적하면서 내실을 다져야죠. 기술 생태계의 질적 변화를 위해 선택한 것은 바로 오픈 API 였습니다. 회사 내 주요 포털 서비스를 오픈 API로 만들고, 외부에 홍보하는 일을 시작했죠. 사내에서 신뢰를 좀 쌓으니 오픈 API 만들어 달라는 부탁도 어느정도 통하더군요. 바쁜데 딴 팀에서 뭔지도 모르는 API를 만들어 달라고 하니 누가해주겠어요? 그래도 많은 팀들의 도움으로 탄생한 <a href="http://channy.creation.net/blog/359">Daum DNA 서비스</a>는 지금도 자랑스럽게 생각하고 있습니다. <em>(지금은 <a href="https://developers.kakao.com/">Kakao Developers</a>가 명맥을 잇고 있습니다.)</em></p>



<figure><img loading="lazy" width="940" height="313" src="http://channy.creation.net/data/channy/2022/01/27055727/2014-daum-dna-1500x500-1-940x313.jpeg" alt="" sizes="(max-width: 940px) 100vw, 940px"><figcaption>Daum DNA DevDay 행사에서 (2014)</figcaption></figure>



<p><strong>근본적 변화 만들기</strong>(3년) – 오픈 API가 외부 생태계의 질적 변화는 가져왔지만, 회사 내에 근본적 변화를 바꾸기는 어렵더라구요. 그래서, 회사에 뿌리는 내리는데 집중을 했습니다. 먼저 지도 API를 비롯해서 몇몇 사내 팀에서 리팩토링 TF를 맡아서 하기도 했구요. 어찌 보면 지금의 마이크로서비스 아키텍처와 유사하다고 볼 수 있는데, 사내에 API 허브를 만들고 수천개의 서비스 API가 등록되도록 했습니다. 제가 퇴사할 무렵인 2013년에는 매일 5억건의 내부 API 요청이 있었는데, 이는 오픈 API가 매일 2천만건임을 생각하면 250배가 넘는 수치였습니다. 지금은 Daum 아니 카카오를 넘어서, 어느 기업 내부에서도 API를 설계하는 게 당연한 일이 되었죠. 근본적인 변화에 약간의 힘을 보탰다는 보람이 있습니다.</p>



<p>이를 위해 한 회사에서 10년씩 다닐 필요는 없습니다. 새로운 회사에서 새로운 일을 맡을 때, 공통적으로 업의 본질을 깨닫고, 신뢰를 쌓고, 본질을 바꾸고, 근본적인 변화를 이끌려는 단계는 필요한것 같아요. 10년에 걸쳐 1-3-3-3일 수도 있고, 몇 개월에서 수년안의 짧은 주기로 계획으로 한다해도 괜찮습니다. (다만, 짧은 시간에 이루어지는 것은 잘 없으며, 다행히도 인간은 생각보다 오래 산다는 점은 기억하세요.)</p>



<p>매년 연초에 업무 계획을 세우는 시점이 되면, 올해는 뭘할까?라는 고민을 하게 되는데요. 내년에는 팀장이 되야지, 내년에는 무슨 기능을 추가해야지가 아니라 어떻게 일을 할지, 어떤 변화를 만들지 고민한다면 좋을 것 같아요.</p>



<p>여기까지 읽어 주신 것 감사합니다. 나머지 부록은 그 이후 10년에 대한 이야기입니다. (자랑 글이니 그냥 넘어가셔도 됩니다. ㅎㅎㅎ)</p>



<h3 id="부록-클라우드-컴퓨팅-분야에서-10년">▩ 부록 – 클라우드 컴퓨팅 분야에서 10년</h3>



<p>제가 Daum에서 한 마지막 업무 중 하나는 AWS를 기반으로 글로벌 서비스를 만드는 사내 스타트업을 돕는 일이었습니다. 클라우드를 사용함으로서 인프라 조직의 도움 없이 웹 서비스를 만들어 내는 것이 매우 신기했습니다. 당시 많은 사람들이 클라우드가 인프라 엔지니어의 직업을 없앨 것이라고 생각했지만, 저는 새로운 기회라고 보았습니다.</p>



<p>AWS에 입사한 첫 일 년은 Amazon의 업무 방식과 새로운 기술을 배우는데 집중했습니다. <a href="http://channy.creation.net/blog/1231">너무 배울 게 많았습니다.</a> 작은 스타트업 처럼 직원의 숫자도 적어서 일당백으로 일할 수 밖에 없었습니다. 외부 개발자도 몇몇 스타트업과 게임 회사를 제외하고는 클라우드 컴퓨팅이 무엇인지 몰랐습니다. 1년 기간 동안 얻은 제가 얻은 결론은 혼자로는 도저히 안되고, 역시 커뮤니티와 함께 해야겠다는 것이었죠.</p>



<p>2015년경 <a href="http://www.awskr.org/">AWS 한국 사용자 모임(AWSKRUG)</a>은 스타트업 CTO들이 일년에 한 두번 정도 세미나를 열었고, 질문/답변을 위한 <a href="https://www.facebook.com/groups/awskrug">페북 그룹</a>이 있었습니다. 먼저 AWS를 공부하고 싶은 분들을 운영진으로 성장하도록 돕고, 다양한 기술 분야 및 지역 모임을 만들도록 장려했습니다. 팬데믹 전에는 커뮤니티 모임을 매주 한 두번 평일 저녁이나 주말에 AWS 코리아 건물에서 진행했는데요. AWS 보안 규정상 직원이 항상 함께 해야 합니다. 저는 거기서 수 많은 개발자들의 다양한 목소리를 직접 들을 수 있었습니다. 그분들의 피드백과 함께 하면서 얻은 신뢰는 제가 하는 일의 가장 중요한 자원이었습니다. </p>



<p>3년이 지난 후, 2018년 말에는 연간 총 100여회의 밋업과 1만 6천명의 회원을 가진 국내 최대 클라우드 커뮤니티로 성장했습니다. 전 세계적으로 인정받은 <a href="https://aws.amazon.com/ko/blogs/korea/get-to-know-the-newest-aws-heroes-winter-2019/">한국 AWS Hero</a>도 열명이나 되고, <a href="http://slack.awskr.org/">AWSKRUG 슬랙 채널</a>에는 30여명의 액티브 리더들이 있습니다. <em>(지금 AWSKRUG는 자율적으로 스스로 잘 운영되고 있습니다.)</em></p>



<figure><img loading="lazy" width="940" height="533" src="http://channy.creation.net/data/channy/2022/01/27062147/2019-aws-community-day-korea-940x533.jpg" alt="" sizes="(max-width: 940px) 100vw, 940px"><figcaption>AWS Community Day에서 AWSKRUG 운영진들과 (2019)</figcaption></figure>



<p><strong>신뢰를 쌓는</strong> 3년간의 단계를 넘어서는 시점에서… 그 이후 어떤 <strong>질적 변화</strong>가 필요한지 한번 생각을 해봤는데요. 클라우드 컴퓨팅 업계의 새로운 아젠다를 던지고 이야기를 던져야겠다고 생각했죠. 그래서, 카오스엔지니어링과 신뢰성 엔지니어링(SRE) 주제를 다루는 <a href="https://www.meetup.com/Korea-Chaos-Engineering-Community/">커뮤니티</a>를 시작했구요. 오랫동안 잠자던 개인 유튜브 채널도 재활성화 했습니다. <a href="http://blog.creation.net/category/cloud-clinic">차니의 클라우드 클리닉</a>이라는 팟캐스트는 2년간 클라우드 네이티브 개발자들의 경험과 이야기를 전달했습니다.</p>



<p>작년 부터는 <a href="https://aws.amazon.com/blogs/aws/author/channy-yun/">영문 AWS News Blog 필진</a>으로 참여하고 있는데, 다양한 AWS 제품팀과 협업을 통해 신규 서비스 출시를 돕고 있습니다. 2년간 총 50여개의 영문 블로그 글을 썼구요. 전 세계에서 다양한 독자들이 의견을 보내옵니다. 영어가 모국어가 아닌데도 불구하고, 클라우드 업계의 빅마우인 <a href="https://twitter.com/QuinnyPig/status/1480987913605160962">Corey Quinn</a>이 얼마전 “와! 이 AWS 블로그 글은 진짜 잘 썼는데, 누가 썼지?”라고 의문이 들때 마다 보면 차니가 쓴 글이네요.”라고 트윗을 남겨서 엄청 보람이 있었습니다.<em> (주로 비판적인 트윗을 하시는 분인데, 칭찬을 들었다고…)</em></p>



<figure><img src="http://channy.creation.net/data/channy/2021/12/26014408/271658605_477091107111790_6701089966275616978_n-940x560.jpeg" alt=""></figure>



<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

몇 달 전 AWS에 입사한지 7년째 되는 날이었습니다. 마침 매니저와 1:1이 있었는데, 입사 7주년 축하를 해주면서 “7년이나 같은 일을 했는데, 뭔가 새로운 일을 하고 싶지 않으세요?”라고 물었습니다. 저는 “아니오. 저는 어떤 일을 시작했다면, 10년을 장기적인 관점으로 하기를 원하고, 아직은 3년이나 남았네요.”라고 대답했습니다. ’10년이면 강산도 변한다’는 한국 속담이 있죠. 세상을 바꿀 수 있는 시간인데요. 회사든 개인이든 장기적인 전략을 가져야 합니다.
어떻게 10년을 한 가지 일에만 몰두 할 수 있는지 물어보실 것 같습니다. 3년이 지나면 대개 흥미를 잃고 새로운 일을 하고 싶으니까요. 맞습니다! 적어도 3년에 한번씩 직무를 바꾸거나 회사를 옮기면서 과거의 컴포트(Comfort) 존을 벗어날 필요가 있지요. 하지만, 장기적으로 연속적인 맥락(Context)을 가지는 것도 중요합니다.
▩  커리어의 장기적 사이클 – 성장/리딩/경영
최근에 직장인과 개발자의 멘토 역할을 하고 계신 KT의 신수정 부사장님과 몰로코의 박종천님이 나란히 ‘일의 격‘과 ‘개발자로 살아남기‘라는 책을 쓰셨는데, 오래된 내공에서 공통된 맥락이 있었습니다. 즉, ‘일의 격’에서는 커리어에 대해 성장-성공(리더십)-성숙의 단계를, 그리고 ‘개발자로 살아남기’에서는 성장-리딩-지원(경영, 사업)의 단계로 설명해 주셨습니다. 특히, 박종천님은 본인의 30년의 경력을 10년 단위로 나눠서 각 단계에서 개발 직군에게 꼭 필요한 스킬과 경험 요소를 경험을 기반으로 잘 녹여 놓았기에 꼭 추천합니다.
사실 이러한 단계는 ‘현업-팀장-임원’의 역할을 거칠때, 필연적으로 가지게 되는 것이죠. 다만, 누구는 몇 년안에 경험하기도 하고, 누구는 아예 거꾸로 경험하기도 하죠. 예를 들면, 저는 이 3단계를 첫 직장 7년사이에 압축적으로 겪었습니다. 그러다 보니, 그 후 두번의 10년을 좀 다른 방식을 나름대로 터득했는데요. 거창하게 책을 쓸 정도는 그냥 아니고, 누구에게는 도움이 될 수도 있다는 전제하에 간단하게 공유해 볼께요.
▩ 1-3-3-3의 원칙으로 10년 경력 이어가기
첫 10년은 대학에서의 학업과 함께 새로운 기회를 찾아, 인터넷 업계에서 7년간의 스타트업 생활을 했습니다. 닷컴 버블이 한창일 때라, 20대의 젊은 열정으로 오로지 (성공)하고 싶은 일에만 시간을 썼습니다. 도와주는 멘토도 없어서 좌충우돌 했던 스타트업 경험은 개발자로서 팀장으로서 그리고 임원으로서도 모두 부족함 투성이었습니다. (과로에 건강을 잃을 뻔도 했습니다.)
그 후, 20년은 먹고 사는 생업을 하면서도, 뭔가 의미 있는 일을 하리라 결심했습니다. 나름 터득한 노하우가 바로 1-3-3-3 원칙인데요. 눈치 채셨겠지만, 10년 중 3년에 한번씩 전술적인 변화를 두는 것입니다. 바로 회사와 일이 나에게 맞는가?(1년), 신뢰를 쌓았는가? (3년), 질적 변화를 만들었나? (3년), 근본적 변화를 만들었나? (3년)를 고민하는 것입니다.
회사/일 관찰하기 (1년) – 첫 일년이 매우 중요합니다. 저의 두번째 직장인 Daum을 예로 든다면, 입사 첫 해는 새로운 회사에 적응하면서 회사의 철학과 저의 생각이 잘 맞는지 알아보는데 시간을 보냈습니다. 어떤 일을 적어도 1년은 해봐야만 업의 본질을 알 수 있습니다. 그리고, 그 일을 하는 모태인 회사의 철학과 문화와 내가 하고 싶은 일과 잘 맞는지 알아가는 과정도 필요하죠. (아니면 빨리 때려치워야 합니다. 사람과 회사는 고쳐쓰는 거 아닙니다.)
신뢰 쌓아가기(3년) – 제가 맡은 일은 회사 내외부의 기술 관련자를 연결하고 소통하는 일이었는데요. 회사와 일이 마음에 맞으니, 초기 3년은 신뢰를 다지는 데 충실했습니다. “낮은데로 임하라”는 말이 있죠. 회사내에서 작은 팀을 맡으면서 온갖 개발팀의 채용 및 교육 지원, 사내 기술 에셋을 만들어 주는 일을 했구요. Daum이 웹 표준 기술에 관심 있었기 때문에, 회사의 배려로 외부 활동도 가능했습니다. 회사 밖에는 수 많은 웹 표준 커뮤니티의 리더와 멤버들은 저의 중요한 동료들이었습니다. 내외부 모두의 신뢰를 얻는 일은 단기간에 이뤄지지 않았습니다. (적어도 3년은 걸리는 것 같습니다.)
질적 변화 만들기(3년) – 신뢰가 어느 정도 쌓이자 내실에 집중하는 질적 변화에 매진했는데요. 새로운 일은 처음부터 내실을 다지긴 힘듭니다. 일단 작은 성과를 축적하면서 내실을 다져야죠. 기술 생태계의 질적 변화를 위해 선택한 것은 바로 오픈 API 였습니다. 회사 내 주요 포털 서비스를 오픈 API로 만들고, 외부에 홍보하는 일을 시작했죠. 사내에서 신뢰를 좀 쌓으니 오픈 API 만들어 달라는 부탁도 어느정도 통하더군요. 바쁜데 딴 팀에서 뭔지도 모르는 API를 만들어 달라고 하니 누가해주겠어요? 그래도 많은 팀들의 도움으로 탄생한 Daum DNA 서비스는 지금도 자랑스럽게 생각하고 있습니다. (지금은 Kakao Developers가 명맥을 잇고 있습니다.)
근본적 변화 만들기(3년) – 오픈 API가 외부 생태계의 질적 변화는 가져왔지만, 회사 내에 근본적 변화를 바꾸기는 어렵더라구요. 그래서, 회사에 뿌리는 내리는데 집중을 했습니다. 먼저 지도 API를 비롯해서 몇몇 사내 팀에서 리팩토링 TF를 맡아서 하기도 했구요. 어찌 보면 지금의 마이크로서비스 아키텍처와 유사하다고 볼 수 있는데, 사내에 API 허브를 만들고 수천개의 서비스 API가 등록되도록 했습니다. 제가 퇴사할 무렵인 2013년에는 매일 5억건의 내부 API 요청이 있었는데, 이는 오픈 API가 매일 2천만건임을 생각하면 250배가 넘는 수치였습니다. 지금은 Daum 아니 카카오를 넘어서, 어느 기업 내부에서도 API를 설계하는 게 당연한 일이 되었죠. 근본적인 변화에 약간의 힘을 보탰다는 보람이 있습니다.
이를 위해 한 회사에서 10년씩 다닐 필요는 없습니다. 새로운 회사에서 새로운 일을 맡을 때, 공통적으로 업의 본질을 깨닫고, 신뢰를 쌓고, 본질을 바꾸고, 근본적인 변화를 이끌려는 단계는 필요한것 같아요. 10년에 걸쳐 1-3-3-3일 수도 있고, 몇 개월에서 수년안의 짧은 주기로 계획으로 한다해도 괜찮습니다. (다만, 짧은 시간에 이루어지는 것은 잘 없으며, 다행히도 인간은 생각보다 오래 산다는 점은 기억하세요.)
매년 연초에 업무 계획을 세우는 시점이 되면, 올해는 뭘할까?라는 고민을 하게 되는데요. 내년에는 팀장이 되야지, 내년에는 무슨 기능을 추가해야지가 아니라 어떻게 일을 할지, 어떤 변화를 만들지 고민한다면 좋을 것 같아요.
여기까지 읽어 주신 것 감사합니다. 나머지 부록은 그 이후 10년에 대한 이야기입니다. (자랑 글이니 그냥 넘어가셔도 됩니다. ㅎㅎㅎ)
▩ 부록 – 클라우드 컴퓨팅 분야에서 10년
제가 Daum에서 한 마지막 업무 중 하나는 AWS를 기반으로 글로벌 서비스를 만드는 사내 스타트업을 돕는 일이었습니다. 클라우드를 사용함으로서 인프라 조직의 도움 없이 웹 서비스를 만들어 내는 것이 매우 신기했습니다. 당시 많은 사람들이 클라우드가 인프라 엔지니어의 직업을 없앨 것이라고 생각했지만, 저는 새로운 기회라고 보았습니다.
AWS에 입사한 첫 일 년은 Amazon의 업무 방식과 새로운 기술을 배우는데 집중했습니다. 너무 배울 게 많았습니다. 작은 스타트업 처럼 직원의 숫자도 적어서 일당백으로 일할 수 밖에 없었습니다. 외부 개발자도 몇몇 스타트업과 게임 회사를 제외하고는 클라우드 컴퓨팅이 무엇인지 몰랐습니다. 1년 기간 동안 얻은 제가 얻은 결론은 혼자로는 도저히 안되고, 역시 커뮤니티와 함께 해야겠다는 것이었죠.
2015년경 AWS 한국 사용자 모임(AWSKRUG)은 스타트업 CTO들이 일년에 한 두번 정도 세미나를 열었고, 질문/답변을 위한 페북 그룹이 있었습니다. 먼저 AWS를 공부하고 싶은 분들을 운영진으로 성장하도록 돕고, 다양한 기술 분야 및 지역 모임을 만들도록 장려했습니다. 팬데믹 전에는 커뮤니티 모임을 매주 한 두번 평일 저녁이나 주말에 AWS 코리아 건물에서 진행했는데요. AWS 보안 규정상 직원이 항상 함께 해야 합니다. 저는 거기서 수 많은 개발자들의 다양한 목소리를 직접 들을 수 있었습니다. 그분들의 피드백과 함께 하면서 얻은 신뢰는 제가 하는 일의 가장 중요한 자원이었습니다. 
3년이 지난 후, 2018년 말에는 연간 총 100여회의 밋업과 1만 6천명의 회원을 가진 국내 최대 클라우드 커뮤니티로 성장했습니다. 전 세계적으로 인정받은 한국 AWS Hero도 열명이나 되고, AWSKRUG 슬랙 채널에는 30여명의 액티브 리더들이 있습니다. (지금 AWSKRUG는 자율적으로 스스로 잘 운영되고 있습니다.)
신뢰를 쌓는 3년간의 단계를 넘어서는 시점에서… 그 이후 어떤 질적 변화가 필요한지 한번 생각을 해봤는데요. 클라우드 컴퓨팅 업계의 새로운 아젠다를 던지고 이야기를 던져야겠다고 생각했죠. 그래서, 카오스엔지니어링과 신뢰성 엔지니어링(SRE) 주제를 다루는 커뮤니티를 시작했구요. 오랫동안 잠자던 개인 유튜브 채널도 재활성화 했습니다. 차니의 클라우드 클리닉이라는 팟캐스트는 2년간 클라우드 네이티브 개발자들의 경험과 이야기를 전달했습니다.
작년 부터는 영문 AWS News Blog 필진으로 참여하고 있는데, 다양한 AWS 제품팀과 협업을 통해 신규 서비스 출시를 돕고 있습니다. 2년간 총 50여개의 영문 블로그 글을 썼구요. 전 세계에서 다양한 독자들이 의견을 보내옵니다. 영어가 모국어가 아닌데도 불구하고, 클라우드 업계의 빅마우인 Corey Quinn이 얼마전 “와! 이 AWS 블로그 글은 진짜 잘 썼는데, 누가 썼지?”라고 의문이 들때 마다 보면 차니가 쓴 글이네요.”라고 트윗을 남겨서 엄청 보람이 있었습니다. (주로 비판적인 트윗을 하시는 분인데, 칭찬을 들었다고…)
이제는 클라우드 기술은 일상화되어 있고, 팬데믹이 디지털 전환을 가속화되고 있는 상태죠. 요즘 무엇이 클라우드 생태계의 근본적 변화를 이끌지 고민이 많습니다. 물론 제가 해야 하는 고민이지만 힌트가 있으시면 댓글로도 알려주세요.

10년 경력을 설계하는 방법 – 1/3/3/3 원칙

댓글