10년 경력을 설계하는 방법

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

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

▩ 커리어의 장기적 사이클 – 성장/리딩/경영

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

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

▩ 관찰 – 신뢰 쌓기 -질적 -근본적 변화 만들기

저는 처음 7년간 벤처 기업(스타트업)에서 일했습니다. 당시 닷컴 버블이 한창일 때라, 20대의 젊은 열정으로 오로지 (성공)하고 싶은 일에만 시간을 썼습니다. 도와주는 멘토도 없어서 좌충우돌 했던 스타트업 경험은 신입 개발자로서 초보 팀장 및 임원으로서도 모두 부족함 투성이었습니다. (과로에 건강을 잃을 뻔도 했습니다.)

그 후 생업과 함께 뭔가 의미 있는 일을 하리라 결심했습니다. 나름 터득한 노하우가 바로 1-3-3-3 원칙인데요. 눈치 채셨겠지만, 10년 중 3년에 한번씩 전술적인 변화를 두는 것입니다. 바로 회사와 일이 나에게 맞는지 관찰하기(1년), 내외부의 신뢰 쌓기 (3년), 질적 변화 만들기 (3년), 근본적 변화 만들기(3년)를 고민하는 것입니다.

관찰하기(1년) – 새 회사에 가서 첫 일년이 매우 중요합니다. 갑자기 의욕에 앞서서 너무 앞서 나가면 안됩니다. 거기에서는 여러분을 믿어 주는 사람이 하나도 없기 때문인데요. 저도 Daum에 입사 후 맡은 팀에서 너무 의욕적으로 일하다, 팀원들의 신뢰를 잃은 적이 있습니다. 첫 해는 새로운 회사에 적응하면서 회사의 철학과 저의 생각이 잘 맞는지 알아보는데 시간을 보내야 합니다. 어떤 일을 적어도 1년은 해봐야만 업의 본질을 알 수 있습니다. 조급해 하지 말고, 회사의 철학과 문화와 내가 잘 맞는지 알아가는 과정이 필요하죠. (아니면 빨리 때려치워야 합니다. 사람과 회사는 고쳐쓰는 거 아닙니다.)

신뢰 쌓아가기(3년) – 회사가 나와 잘 맞다면, 천천히 신뢰를 쌓아야 합니다. Daum에서 첫 팀의 실패를 거울 삼아, 바로 팀장을 내려놓았습니다. 처음 부터 새로 시작하기로 했습니다. 그리고, 제가 처음 맡은 일은 회사 내외부의 기술 관련자를 연결하고 소통하는 일이었는데요. “낮은데로 임하라”는 말이 있죠. 내부에서는 혼자서 온갖 개발팀의 채용 및 교육 지원, 사내 기술 에셋을 만들어 주는 일을 했구요. 다행히, Daum이 웹 표준 기술에 관심 있었기 때문에, 회사의 배려로 외부 활동도 가능했습니다. 회사 밖에 있는 수 많은 웹 표준 커뮤니티의 리더와 멤버들 역시 저의 중요한 동료들이었습니다. 내외부 모두의 신뢰를 얻는 일은 단기간에 이뤄지지 않았습니다. (적어도 3년은 걸리는 것 같습니다.)

질적 변화 만들기(3년) – 신뢰가 어느 정도 쌓이자 내실에 집중하는 질적 변화에 매진했는데요. 새로운 일은 일단 작은 성과를 축적하면서 내실을 다져야죠. 제가 선택한 것은 바로 ‘오픈 API’ 였습니다. 지금은 당연한 것인데 당시에는 정말 생소한 개념이었습니다. 이를 위해 작은 팀을 만들어서 검색이나 지도 같은 주요 서비스를 오픈 API로 만들고, 외부에 홍보하는 일을 시작했죠. 사내에서 신뢰를 좀 쌓으니 오픈 API 만들어 달라는 부탁도 어느정도 통하더군요. 바쁜데 딴 팀에서 뭔지도 모르는 API를 만들어 달라고 하니 누가해주겠어요? 많은 팀들의 도움으로 탄생한 Daum DNA 서비스는 지금도 자랑스럽게 생각하고 있습니다. (지금은 Kakao Developers가 명맥을 잇고 있습니다.)

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

어떤 일으든 먼저 관찰하고, 신뢰를 쌓고, 본질을 바꾸고, 근본적인 변화를 만드는 단계를 가지면 좋습니다. 사실 제가 말한 10년은 예를 든 것 뿐입니다. 저처럼 10년에 걸쳐 1년, 3년, 3년, 3년일 수도 있고, 몇 개월에서 수년안의 짧은 주기로 한다해도 괜찮습니다. 다만, 짧은 시간에 쉽게 이루어지는 것은 잘 없으며, 다행히도 인간은 생각보다 오래 산다는 점은 기억하세요.

매년 연초에 업무 계획을 세우는 시점이 되면, 올해는 뭘할까?라는 고민을 하게 되는데요. 내년에는 팀장이 되야지, 내년에는 무슨 기능을 추가해야지가 아니라 어떻게 일을 할지, 어떤 변화를 만들지 고민한다면 좋을 것 같아요. 여기까지 읽어 주신 것 감사합니다. 나머지 부록은 그 이후 10년에 대한 이야기입니다. (자랑 글이니 그냥 넘어가셔도 됩니다. ㅎㅎㅎ)

▩ 부록 – 클라우드 컴퓨팅 분야에서 10년

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

관찰하기 (1년) – AWS에 입사한 첫 일 년은 Amazon의 업무 방식과 새로운 기술을 배우는데 집중했습니다. 너무 배울 게 많았습니다. 작은 스타트업처럼 직원의 숫자도 적어서 일당백으로 일할 수 밖에 없었습니다. 마케팅팀과 다양한 행사에 직접 손발을 맞추기 시작했구요. 당시, 몇몇 스타트업과 게임 회사를 제외하고는 클라우드 컴퓨팅이 무엇인지 몰랐습니다. 1년 기간 동안 얻은 제가 얻은 결론은 혼자로는 도저히 안되고, 개발자 커뮤니티와 함께 해야겠다는 것이었죠.

신뢰 쌓기 (3년) – 당시 AWS 한국 사용자 모임(AWSKRUG)은 스타트업 CTO들이 일년에 한 두번 정도 세미나를 열었고, 질문/답변을 위한 페북 그룹이 있었습니다. 먼저 AWS를 공부하고 싶은 분들을 운영진으로 참여시키고, 다양한 기술 분야 및 지역 소모임을 만들도록 장려했습니다. 당시 소모임을 매주 한 두번 평일 저녁이나 주말에 AWS 코리아 건물에서 진행했는데요. AWS 보안 규정상 직원이 항상 함께 해야 합니다. 저는 거기서 수 많은 개발자들의 다양한 목소리를 직접 들을 수 있었습니다. 사실 제 업무가 한국에서 혼자 하는 일이였기 때문에 그분들의 피드백과 함께 하면서 얻은 신뢰는 제가 하는 일의 가장 중요한 자원이었습니다. 또한, AWS의 각종 마케팅 이벤트에 콘텐츠 큐레이터로 활동하면서 몸으로 하는 일까지 도맡아 진행했었죠. 특히, 2016년 앤디 제시 CEO 방한 행사나 매년 Summit 기조 연설에 모든 슬라이드가 제 손을 거쳐갔습니다. 사내 직원들과도 여러 행사에서 부대끼면서 신뢰를 쌓아 2016년에 사내 글로벌 마케팅 어워드를 받기도 했구요. 마침내 2018년에는 그 어렵다는 빅테크 프로모션도 했습니다.

질적 변화 만들기 (3년) – 2019년까지 AWSKRUG 규모는 연간 총 100여회의 밋업을 열고, 1만 6천명의 회원을 가진 국내 최대 클라우드 커뮤니티로 성장했습니다. 전 세계적으로 인정받은 한국 AWS Hero도 열명이나 되고, AWSKRUG 슬랙 채널에는 30여명의 액티브 리더들이 있습니다. (지금 AWSKRUG는 자율적으로 스스로 잘 운영되고 있습니다.)

그런데, 팬데믹으로 인해 오프라인 활동이 줄어들면서 어떤 질적 변화가 필요한지 한번 생각을 해봤는데요. 클라우드 컴퓨팅 업계의 새로운 아젠다를 던지고 이야기를 던져야겠다고 생각했죠. 그래서, 카오스엔지니어링과 신뢰성 엔지니어링(SRE) 주제를 다루는 커뮤니티를 시작했구요. 오랫동안 잠자던 개인 유튜브 채널도 재활성화 했습니다. 차니의 클라우드 클리닉이라는 팟캐스트는 2년간 클라우드 네이티브 개발자들의 경험과 이야기를 전달했습니다.

근본적 변화 만들기(3년) – 재작년 부터는 영문 AWS News Blog 필진으로 참여하고 있는데, 다양한 AWS 제품팀과 협업을 통해 신규 서비스 출시를 돕고 있습니다. 2년간 총 50여개의 영문 블로그 글을 썼구요. 이제 한국을 넘어서 전 세계에서 다양한 독자들이 의견을 보내옵니다. 영어가 모국어가 아닌데도 불구하고, 클라우드 업계의 빅마우스인 Corey Quinn이 얼마전 “와! 이 AWS 블로그 글은 진짜 잘 썼는데, 누가 썼지?”라고 의문이 들때 마다 보면 차니가 쓴 글이네요.”라고 트윗을 남겨서 엄청 보람이 있었습니다. (주로 비판적인 트윗을 하시는 분인데, 칭찬을 들었다고…)

이제는 클라우드 기술은 일상화되어 있고, 팬데믹이 디지털 전환을 가속화되고 있는 상태죠. 요즘 무엇이 클라우드 생태계의 근본적 변화를 이끌지 고민이 많습니다. 물론 제가 해야 하는 고민이지만 힌트가 있으시면 댓글로도 알려주세요.

- Channy Yun (윤석찬);

※ Disclaimer- 본 글은 개인적인 의견일 뿐 제가 재직했거나 하고 있는 기업의 공식 입장을 대변하거나 그 의견을 반영하는 것이 아닙니다. 사실 확인 및 개인 투자의 판단에 대해서는 독자 개인의 책임에 있으며, 상업적 활용 및 뉴스 매체의 인용 역시 금지함을 양해해 주시기 바랍니다. 본 채널은 광고를 비롯 어떠한 수익도 창출하지 않습니다. (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. This channel does not monetize via any advertising.)