초기 스타트업 CTO, 그 1년의 기록
부에노컴퍼니에 입사한 지도 어느덧 1년이 되어간다. 개인에게도, 가족에게도, 그리고 조직에게도 참 많은 일들이 있었는데, 어제의 나보다 나은 내가 되어보고자 CTO로서의 지난 1년을 정리해보고자 한다.
팀원 15인 규모의 개발팀장 vs 임직원 15인 규모의 스타트업 CTO
무스마에서 팀장을 하던 시절, 팀원이 많이 늘어나 팀이 더 이상 팀 같지 않은 수준에 이르렀을 때를 기억한다. 당시 마땅한 기획자가 따로 없어 개발팀장으로서 서비스 기획 업무까지 맡아야 했던 나로서는 협업 부서와의 회의, 협력사 PM과의 회의, 그리고 개발팀 내부 회의만으로도 시간이 쏜살같이 지나가는 하루 하루를 보내고 있었다.
‘피자 두 판의 법칙’ 을 정말이지 뼈 저리게 체감했는데, 언제부터인지 키보드를 두드리는 시간보다 사람들과 이야기 하는 시간이 더 많아졌다는 것을 깨달았고, 그것은 나에게 꽤나 ‘큰 일’ 로 다가왔다. 사람들과 이야기하는 것을 딱히 꺼려하지도 않고, 어느 정도 자신도 있는 나였지만, 아직 기술적으로 깊이 있게 무르익지 않은 내가 팀장이라는 미명 하에 하루 종일 기획만, 회의만, 의견 조율만, 의사 결정만 하고 있다는 게 주는 불만족은 점점 커져만 갔다. 조직도, 그리고 서비스도 계속 성장해가는 모습을 일선에서 지켜보는 것은 꽤 큰 만족감을 주었지만, 내가 매일같이 쏟는 그 열정과 에너지가 조금은 더 코드 작성 쪽이었으면 하는 바람은 아무래도 좀처럼 사그러들 줄 몰랐다.
그 시절과 비교하면 3–4인의 작은 개발팀을 꾸려나가는 지금은 꽤나 쾌적한 느낌이다. 코드 리뷰도 불가능할 정도로 미팅만 하다가 한 주가 다 지나가던 그 때와는 달리 지금은 원했던 대로 다시 hands-on으로 돌아와 개발도 실컷 하고 있고. 무엇보다도, 초기 멤버에게 주어지는 의무이자 권리라고 생각하는데, 아무 것도 없는 황무지에 떨어진 개척자가 된 양 내가 믿는 소중한 가치들을 듬뿍 담아 시스템을 하나 둘 신중하게 설계하고 세워가는 이 작업에는 무언가 이루 형언할 수 없는 강렬한 쾌감이 있다. 아직은 작지만 오롯이 나만의 것인 프로덕트를 하루 하루 정성껏 키워나가는 것이다.
리더로서 ‘개발팀에 미치는 영향력’ 만 생각해 본다면, 어쩌면 CTO인 지금이 아니라 예전 그 팀장이던 때가 더 강했던 것 같은데, 역시 직함 자체가 중요한 게 아니라 어느 규모의 조직에 속해 매일 같이 어느 정도의 시야를 유지하며 내 에너지를 쏟아붓고 있는지, 결국 행하는 일이 무엇이고, 어떤 가치를 좇고 있는지, 그게 더 중요하다는 생각이 든다.
또 한 가지 차이점이 있다면, 아무래도 ‘부서를 초월한 영향력 행사’ 정도가 되겠다. 지금 부에노컴퍼니에서는 내가 소위, Growth Manager도 담당하고 있어서 소프트웨어 개발팀뿐 아니라 인사팀, 영업팀, 기획팀, 데이터팀 멤버들과도 모두 적극적으로 1 on 1을 진행하고 있고, 모두와 함께 정보 방열기를 구축해본다든지, 애자일 프로세스를 우리 상황에 맞게 변형해 적용해본다든지, 초기 스타트업에서는 우리가 어떻게 일해야 좋을지, 이번 분기에는, 이번 반기에는 어떤 목표를 가지고 개인적으로, 또 조직적으로 나아갈지 방향을 맞추는 데 도움을 드리고 있다.
너무 이상적으로 들릴지 모르겠지만, 개인의 성장이 조직의 성장을 견인하고, 또 조직의 성장으로 말미암아 발생하는 일련의 보상들이 좋은 동기부여가 되어 개인의 성장을 견인하는 선순환 구조를 만들어보고 싶은데, 멤버들로부터 성장과 관련된 좋은 피드백을 받을 때마다 정말 어찌나 뿌듯하고 기분이 좋은지 아무도 모를 거다. 지금은 소규모인 만큼 참 ‘사람 냄새’ 물씬 나게 일하고 있는데, 참 이 맛에 스타트업 하는 게 아닐까 싶은 시간들을 보내고 있다. 힘은 들지만 이 과정을 충분히 즐기고 있다. 행복하다.
같은 실수를 저지르고 싶지 않다 vs 같은 결론만 반복하고 싶지 않다
무스마에 합류하던 당시, 개발자는 나 혼자였다. 아직 이렇다 할 솔루션도 없었고, 협업 도구는 커녕 휴가 결재 양식조차 없었던, 뭔가 회사보다는 아직 대학 동아리에 더 가까운 느낌의 스타트업에 합류해 지금은 그래도 50인에 달하는 인원에 서울 지사를 내고, 부산 본사 사옥까지 마련한 3년 반의 시간 동안 초기 멤버로서 정말 많은 것들을 시도해볼 수 있었고, 또 귀중한 경험들을 맛볼 수 있었다. 지금 잠깐 떠올려도 참 가슴 벅찬 순간들이 많았다.
개발자 채용 절차, git branch 전략, 협업 도구들을 도입하고 체계와 문화 그 모든 것들을 하나부터 열까지 많은 시행착오를 거쳐가며 당시의 우리에게 꼭 맞는 옷을 만들어 가는 과정이 있었는데, 재미있는 것은 또 이렇게 새 조직에 첫 개발자로 합류를 하고보니 아주 강한 기시감(旣視感)이 들더라는 것이다. 아니, 말을 똑바로 하자면 분명 기시감은 아니다. 왜냐하면 그저 느낌뿐인 게 아니라 현실 세계에서 실제로 4년 전 겪었던 동일한 굴레를 반복하는 것이니까.
최초에는 대번에 ‘같은 실수를 저지르고 싶지 않다. 나는 이미 충분히 많은 시행착오를 겪어봤으니, 이번에는 자잘한 실패 없이 바로 정답으로 가본다’는 생각이 앞섰는데, 또 한 편으로는 ‘이거 완전 꼰대같잖아? 내가 다 해봤는데 이게 최고더라며 예전에 내렸던 것과 같은 결론만 반복하고 싶지는 않은데… 그럼 처음부터 필연적으로 다시 부딪혀봐야만 하는 것일까?’ 하는 생각이 드는 것이다.
하지만 이는 오래 지나지 않아 곧 생각이 말끔하게 정리되었는데, 가만 보니 내가 감히 ‘이게 왕도이다. 정답이다.’ 라고 내놓았던 것들은 당시의 상황, 그 도메인, 그 비지니스, 그 사람들이었기에 맞추어보고 알맞게 만들어 입은 옷이었던 것이고, 지금 이 도메인, 이 비지니스, 이 사람들에게 딱 알맞는 옷은 확실히 다른 형태였다는 것이다.
게다가 무엇보다도, 그 시행착오들은 아무 것도 아닌 게 아니었다. 과거의 그 작은 여럿의 실패의 경험들이 지금의 나를 있게 했듯이, 이번에도 작은 여럿의 실패의 경험들이 새 조직, 새 동료들의 성장에 크게 도움이 되고 있는 것을 두 눈으로 똑똑히 지켜볼 수 있었다. 나에게야 반복이었지만 그들에게는 아니었던 것. 수동 배포를 한 차례도 경험해보지 않은 신입에게 자동 배포부터 일러주면 그 차이를 느낄 수 없는 것처럼, 우리는 보다 나은 맛을 더 제대로 느끼기 위해서 때때로 그렇지 않은 쪽도 ‘의도적으로’ 맛볼 필요가 있다는 것이다.
지금 떠올려보니 참으로 오만방자한 생각이 아닐 수 없다. 오늘도 같은 실수로 버그나 만들어내는 주제에 내가 무어라고 무려 조직의 문화를 하루 아침에 내 입맛대로, 내 결론대로 휘리릭 한 큐에 만들어볼 수 있으리라 속단했던 것인지. 이것도 이것대로 나에겐 또 한 번의 성장을 안겨다 줄 밑거름이 되리라.
“The most dangerous phrase in the language is: We’ve always done it this way.” - Grace Hopper
상환하고 있는 기술 부채, 그리고 새로 만들고 있는 기술 부채
내가 입사하기 전, 마트장보고 서비스는 약 2년여 기간 동안 무려 다섯 개의 외주 업체를 거쳐 개발/운영되고 있었다. 하나의 코드 베이스를 두고 무려 다섯 개 업체라니. 내 짧은 커리어 내에서는 최고 수준의 스파게티 코드를 맛보는 경험이 기다리고 있던 것.
초반의 스타트업은 아무래도 속도에 굉장히 민감하다. 제품을 최대한 빨리 시장에 내놓아보고, 피드백을 받아 이 기능, 저 기능 또 추가해보고, 넣었던 기능을 다시 내려도 보고, 대응할 것들이 산더미인데 일손은 부족하고…
한창 레거시 코드 리팩터링하다보면 ‘왜 이렇게 개발했을까? 이게 최선이었을까? 남이 만든 기술 부채를 지금 내가 다 갚고 있구먼.’ 싶은데 응, 그렇다. 그게 최선이었을 게다. 그러면 지금의 나는 왜 이렇게밖에 개발을 못 하고 있을까? 먼 훗날 나의 동료는 지금의 내 코드를 보며 같은 생각을 하고 있지 않을까? ‘왜 이렇게 개발했을까? 이게 최선이었을까? 남이 만든 기술 부채를 지금 내가 다 갚고 있구먼.’ 이유를 막론하고 그게 당대 최선인 것들이 존재하기 마련이다.
당시의 부에노컴퍼니로서는 외주를 맡기는 선택이 최선이었던 것이고, 외주 개발사에서야 그렇게 개발하는 게 또 최선이었던 것이고, 그 때 그런 형태로라도 기술 부채를 만들어가며 개발을 ‘비교적 빨리’ 한 덕분에, 어쩌면 그런 덕분에 부에노컴퍼니는 더 먼 미래가 아니라 작년 여름 나를 채용할 수 있었던 것일 수 있고, 나는 또 미래의 동료를 만나는 그 날을 하루라도 더 앞당겨보고자 오늘도 기술 부채를 만들어가며 개발을 해나가고 있는 것일 수도…
내가 오늘 작성한 코드가 ‘레거시’ 라 불리우는 순간은 언제인가? 참 재미있는 질문이다. 기술 부채를 너무 아무 생각 없이 마냥 찍어내는 것도 해롭겠지만, 그렇다고 또 너무 병적으로 기피하고 만들지 않는 방향으로만 가는 것도-이게 가능한지나 모르겠다만-건강하다고 생각하지 않는다. 칼 같이 정량적으로 계산될 수 있는 부분도 아니겠는데, 어느 정도의 ‘감’ 을 가지고 계속 헤아려가면서 때로는 기술 부채를 갚아가며, 때로는 기술 부채를 만들어가며 비지니스는 오늘도 그렇게 조금씩 멤버들과 함께 성장하는 것 아닐까.
채용과의 전쟁
수도권 소재 스타트업들은 어떠한지 모르겠다만, 여기 김해로 말할 것 같으면 정말이지 채용이 가뭄에 콩 나듯 이루어지는 곳이다. 업체가 없어 공고도 없고, 사람이 없어 지원도 없다. 면접이 잡히면 어떤 느낌이 드냐 하면 이 고장에서는 업체도 귀하고, 사람도 귀해서 참 오랜만에 어렵게 성사된 소개팅 자리이기 때문에 무언가 불필요하게 더 조심스러워지고, 멋쩍다가도 분위기가 무르익으면 이 때다 싶어 서로가 열을 내어 어필을 하는 참 웃지 못할 광경이 펼쳐지곤 한다.
처음에는 여기 김해에서 ‘부산 지사를 열면 채용은 해결되지 않겠냐’ 는 이야기가 솔솔 나왔지만, 바로 직전 회사에서 부산에서는 영 힘이 달려 서울 지사를 열어봤던 입장에서는 글쎄올시다, 부산 지사는 영 해결책이 아닌 것 같단 말이지. 협력사 미팅, 투자사 미팅 등 여러 전략적 이유들을 두고 서울에 전진 기지를 구축했던 것인데, 그 이유 첫째는 단연 채용이 아닐 수 없다.
그렇담, 서울 지사를 열면 그게 해결책이냐? 글쎄올시다, 더 큰 시장에서 더 큰 업체들과 경쟁해서도 매력적인 스타트업일 수 있다면, 인재들을 모으고 성장할 수 있다면, 그렇지, 해결책이 될 수 있겠다. 그러니까 결국 중요한 것은, 부산이냐, 서울이냐도 아니고, 우리 서비스의 경쟁력, 그리고 우리 조직의 역량, 외부 요인들을 차치하고 우리만 두고 바라봤을 때의 어떤 순수한 파워 그 자체에 달린 문제라고 보여졌다. 우리 하기 나름인 게지.
그러던 어느 날이다. 어쩌면 우리 같은 업체야말로 더더욱 적극적으로 full remote를 실현해야 되는 것 아닐까 하는 생각에 다다랐다. 그렇지 않은가? 부산 지사가 됐든, 서울 지사가 됐든 그 오피스 임대료 하며, 우리 사람 아무도 없는 그 외지에 누가 가서 그럼 먼저 깃발을 꽂을 것이고, 팀은 어느 세월에 누가 어떻게 빌딩할 것이며, 생각해보면 참 막막한데 그 비용들을 차라리 여기 우리 모두가 완전 원격 근무가 능숙하게 가능한 조직으로 성장하는 데 들여본다면 시도해 봄직한 장사가 아닌가? 게다가 지금처럼 총 인원이 몇 명 되지 않을 때 체계를 탄탄하게 잡아두는 게 나중에 조직이 커졌을 때 어설프게 시도해보는 것보다 훨씬 더 수월하지 않을까?
그러한 연유로 우리 조직은 현재 전 임직원 완전 원격 근무 가능한 소양, 그리고 체계를 갖추기 위해 이런 저런 다양한 시도들을 해보는 중이다. 아직은 주 1회 월요일 사무실 출근이라는 제약의 덫에서 더 나아가질 못 하고 있는데 이 한계도 머지 않아 극복할 것이다. 이것은 김해 스타트업에게 있어서는 마치 무인도 생존 전략과도 같아서 살아남으려면 반드시 극복해야만 하는 어떤 필사적인 목표가 되는 것이다. 목적이 목적인 만큼, 공간을 완전히 초월한 원격 근무 형태가 아니면 소용 없기 때문에 ‘사무실 출근이 제로에 수렴하냐?’, ‘특정 주기마다 최소 1회 이상의 사무실 출근이 불가피하냐?’ 는 우리에게 있어 결국 전국 인재 채용이 가능하다, 불가하다를 가르는 하늘과 땅 차이가 된다.
외주의 유혹
초기 스타트업에게 외주의 유혹이라 하면 두 가지가 있겠는데, 하나는 우리 서비스 개발만으로는 자생이 힘들어 우리가 외주 개발 업체로서 남의 서비스를 수주해 개발해주는 것으로 연명하는 게 있겠고, 다른 하나는 우리 서비스를 외주 개발 업체에 맡기는 게 있겠는데 이것은 후자에 관한 이야기이다. 어쩌면 전자의 경우보다는 상황이 조금은 나은 이야기일 수 있겠다. 아니, 딱히 그렇지도 않은가?
개발자도 있고, 개발할 서비스도 있는 회사에서 외주를 맡긴다니 웬 말이냐 하면 이게 또 앞서 언급한 채용과 아주 밀접한 관련이 있다. 서비스의 방향, 사용자 지표들을 인정 받아 어렵게 투자 받은 초기 스타트업은 그럼 더더욱 힘을 내어 속도감 있게 차기 버전 서비스 개발에 박차를 가해야 되는데 이렇게 채용 물이 바짝 말라버리면 회사 입장에서는 달리 손쓸 방도가 여럿 있는 게 아니다. 흔히 ‘턴키(turn-key)’ 방식으로 외주를 맡긴다고도 표현하는 바로 그것이다.
총알은 구비되어 있음에도 불구하고 오랜 시간 잘 안 풀렸던 채용 대신, 그 비용을 외주로 돌리면 이게 어찌 되었든 우리 기획안을 코드로 구현해줄 다수의 개발자들이 ‘시한부’로나마 현실 세계에 등장하게 되고, 프로젝트 착수에 들어갔다 하니 마치 채용 이슈가 눈 녹듯 사라진 것 같고, 이것이야말로 유레카 우리의 해법인가 싶지만 경험해본 바로는 전혀 그렇지 않았다. 그 코드들이 우리 손을 영영 떠날 아이들이면 또 모르겠건만, 낳아준 부모는 곧장 잃고 낯선 우리 손에 도로 맡겨질 아이들이 아니던가.
다행히 우리는 강한 유혹에도 아직은 꿋꿋하게 스스로 내부에서만 개발을 계속 해나가고 있지만 최종 면접까지 다 통과한 지원자가 결국 다른 업체를 택하는 날이면 아무래도 힘이 쭉 빠지는 건 어쩔 도리가 없다. 외주를 너무 부정적으로만 서술한 것 같지만, 그럼에도 기업의 제 1목적은 여전히 이윤의 극대화이고, 이 바닥에서 일단 살아남아야 나도 있고 너도 있고 회사도 있고 서비스도 있기 때문에, 때에 따라서는 분명 좋은 전략이 될 수도 있다고 생각한다. 때에 따라서는.
개발 얼마나 걸릴까요?
그 누구가 어느 시점에 물어와도 ‘검토해보고 말씀드리겠습니다.’ 외 다른 답변을 해본 적이 없는 것 같다. 왜냐하면 검토를 마친 후에는 다시금 질문이 들어오기 전에 내가 먼저 답을 건네고 상황을 종료하기 때문. 그래서 저 질문을 받을 때면 언제나 아직 검토하기 전이었고, 내 대답은 한결같았다.
개발 공수를 산정한다는 것은 뭔가 잘못한 것 하나 없이 괜히 내가 지금 변명을 하는 듯한 기분이 들게 만드는, 언제 어떤 상태에서 누구와 진행해도 항상 유쾌하지 않았던 불편한 작업이다. 그나마 ‘이 정도 소요되겠습니다.’ 했을 때 ‘네, 알겠습니다.’ 하면 막힐 것이 없는데 혹여나 ‘이게 왜 그렇게 오래 걸리지요? 그렇게 오래 걸릴 일인가요?’ 하면 우린 이제 테이블에서 건설적인 이야기를 하지 못 하게 된다.
다 이런 저런 까닭이 있어 팀원들과 시간을 들여 고민 고민 끝에 나름 줄여도 보고 쥐어짜서 내놓은 결과물인데 질문이 저렇게 들어오면 나도 요목 조목 논리적으로 판단 근거를 대가며 서로 시간을 허비하고 있을 수 밖에 없지 않은가. 건설적인 이야기를 하려면 ‘조금이라도 배포 일정을 당기고 싶은데 어느 기능부터 다음 차수로 미뤄볼까요?’ 하고 우선순위를 논하고, 스코프를 정하는 방향이 되어야 한다.
제품의 질(quality)을 낮출 수는 없겠고, 지출되는 금전적인 비용(cost)도 대개의 경우 고정값에 가깝다. 광의로 해석해서는 이 모든 요소들이 결국 비용과 직결되어 있으니 여기에서의 비용은 상급 엔지니어 채용 인건비와 같은 금전적인 지출로 해석해야 적절하겠다.
그럼 양(scope)이냐 시간(time)이냐의 문제로 귀결되는데, 일정을 당기고 싶으면 양을 줄이고, 양을 못 줄이겠으면 일정을 미루면 된다. 그런데 이 때 일정도 맞추고 싶고 양도 못 줄이겠다는 방향으로 일이 진행되면 야근이라는 애먼 비용이 발생하는 것이다.
그 야근이 초과 근로 수당을 발생시켜 본래 취지에 맞게 금전적인 비용 요소로서 정상 동작해야 옳겠는데, 종종 초과 근로 수당이랄 것이 없게 되면 그 비용이 발생 않는 게 아니라 직원들이 건강을 잃든, 애사심을 잃든 어쨌든 여러 다른 형태로 변화하여 발생하게 되는 것이다.
스크럼 포커다 뭐다 이렇게 저렇게 아무리 공들여 일정을 잡아봐도 잘 지켜지지 않는 경우가 태반이었는데, 최소한 내 경우에서는 그 까닭이 언제나 ‘운영 이슈’ 때문이었다. ‘A 기능을 B가 맡으면 최소 3일 최대 5일 정도면 될 것 같다.’ 고 B와 함께 논의를 마치면, 대개의 경우 그 산정은 들어맞았다. 가끔 큰 예외 상황이 발생하는 게 아니고선 new feature 개발 공수 산정이 틀린 경우는 잘 없었다.
진짜 문제는, 특히나 우리 같이 작은 초기 스타트업에게는 개발팀 따로, 운영팀 따로 따위는 없다는 것이다. 언제 어떻게든 예상하지 못 했던 긴급한 운영 상의 이슈가 발생하면 하릴 없이 신속하게 새로운 티켓이 기존 티켓들보다도 높은 우선순위로 부여되고, 기존에 작업하던 것은 그게 무엇이었든 바로 stop이다. 지극히 자연스러운 처사이다. 그리고 이 때 발생하는 context switching은 추가 비용을 요구해서 시간이 덜 걸렸을 이슈에도 더 걸리게 만드는 파장을 일으킨다. 그럼 이렇게 한 번, 두 번, 중간 중간에 운영 상의 이슈를 해결하기 위해 긴급하게 투입된 시간들의 총합만큼 배포 시기도 미뤄져야 합리적일 것 같지만 냉혹한 현실은 우리 기대와 달리 동작하고, 대체로 이 운영 이슈 해결에 들었던 시간만큼의 초과 근로를 통해 밀린 개발 일정을 바로 잡으려 애썼던 것 같다.
얼마나 소요될지 산정한 그 delta를 현재 시점 t에 대고 냅다 t+delta 더해서 배포 시기를 잡아선 곤란하다는 이야기이다. 50%를 더해라, 두 배를 하면 맞더라는 이야기들이 딱히 틀리지도 않는 게, 정말 상당량의 예상하지 못한 이슈들이 우리 앞날에 포진해있기 때문. 다음 주에는 이게 터질 것 같고, 다음 다음 주에는 이게 터질 것 같으니까… 하면서 개발 일정 잡을 수는 없으니까, 예상은 예상으로만 보고, 마감일로 상정하진 말자.
더 본질적인 부분을 논해보면, 이 런칭 시점의 예상을 통해 기획, 영업, 마케팅 등 타 부서에서도 긴밀하게 업무 일정을 조율하고, 큰 흐름을 지켜가는 건강한 긴장감, 적절한 스트레스를 유지하여 종래에는 보다 질 높은 제품을 개발하는 데 진정한 의의가 있다고 생각한다. 일정 산정을 질 높은 제품을 개발하는 데 유용하게 동작하는 도구로서 활용해야지, 마감을 맞추는 게 전부인 양 목적이라고 착각해버리면 개인도 조직도 그에 매몰되고 진짜 중요한 것은 망각하게 되는 것 같다.
CTO 물러나기
“2–3년 뒤 정도면 아직 괜찮겠지만, 5–6년 뒤의 부에노컴퍼니 CTO가 여전히 저여서는 곤란하지 않을까요?”
조금 놀란 표정으로 들던 숟가락을 내려 놓으시는 대표님께서는 그런 생각을 해보신 적 없단다. 내가 만들고 있는 긍정적인 변화들이 너무 좋아 오래 오래 함께 일 했으면 좋겠는데, 혹시 부에노컴퍼니랑 일 하는 게 싫냐고 물으신다.
<마트장보고> 서비스는 좋은 비지니스 모델을 가지고 있다. 잘 될 것 같고, 꼭 잘 되게 만들 거다. 초기 스타트업에 합류한 중니어 CTO의 사명이란 무엇일까? 나는 합류를 결정하기 전부터 이 질문에 답해보고자 고민했었는데, 내가 내린 결론은 ‘다음 레벨 CTO를 하루라도 더 빨리 모셔올 수 있도록 그 날까지 이 조직을, 서비스를 계속 성장시키는 것’이다. 그러니까 5–6년 뒤에도 여전히 겨우 나 정도의 재목이 부에노컴퍼니 CTO로 있다면-나도 물론 안간힘을 다해 계속 성장해나갈 테지만- <마트장보고> 서비스는 내 예상과는 달리 성공 신화를 쓰는 데 실패했다는 방증이 아닐까.
사실 바로 전 무스마에서 유사한 상황을 한 차례 경험해본 바 있다. 아무 것도 없던 초기에 입사해 솔루션을 하나 둘 내 손으로 직접 만들고, 산업 현장을 누비고, 기술 블로그를 만들고, 내 뒤로 열 명이 넘는 개발자들을 채용하고, 협업 체계를 만들고, 시리즈 A 라운드 투자를 받고. 작년의 나는 딱 거기까지였다. A까지는 어찌 잘 왔지만, 시리즈 B 라운드를 이끌어 가기엔 아직 역부족인 단계의 엔지니어. 그러니까 이번의 나는 적어도 시리즈 B 라운드까지는 이끌어봐야지 않을까. (웃음)
그래서 나의 목표는 올해도, 내년에도, ‘CTO 물러나기’ 이다. 다음 레벨 CTO를 하루라도 더 빨리 모셔올 수 있도록 그 날까지 최선을 다해 이 조직을, 서비스를 계속 성장시켜보이겠다. 이 부족한 나를 믿고 기회를 주신 boss에 대한 보은을 위해서라도.
