<div id="readability-page-1" class="page"><div>

<article>
   
  <div><p>CTO 3년차. 급하게 쓴 2022년 회고.</p>
<p>작은 기업의 CTO는 <code>Chief of Technology Officer</code>가 아니라 <code>Chief of Troubleshooting Officer</code>라는 우스개소리가 있다. 하지만 적어도 올 한해 나로서는 우스개소리가 아니었다. 올 한해는 CTO가 된 이후 업무적으로나 업무 외적으로나 가장 힘든 한 해였다.</p>
<p>풀필먼트 업무가 본궤도에 오르면서 반드시 처리해야할 일은 많아지는 한편 심각한 개발 리소스 부족에 직면하게 되었다. 직접 API개발, 코드리뷰 등 직접 개발의 최전선에 있긴 하지만 이 때는 개발 리소스가 너무 없어서 군단장(장군)이 직접 참호에 들어가서 밀려드는 이슈에 대고 총을 쏘아야 했다.</p>
<h2 id="업무-1---풀필먼트">업무 1 - 풀필먼트</h2>
<p>작년에 풀필먼트 시스템(WMS + 주문 수집)을 자체 개발해서 10월 말에 배포했다. 들어간 M/M은 굉장히 적은 편이었다. 프론트 2.5명, 백엔드 3명으로 5개월만에 만들었기 때문에 진짜 최소한의 기능만 만들고 계속 붙여나가는 방식으로 개발했다. 그래서 작년 10월 말에 릴리즈하고 계속해서 추가 기능을 개발하고 있었다.</p>
<p>그리고 2022년이 밝았다.</p>
<p>1분기에는 창고에서 개발팀이 만든 솔루션을 제대로 사용하지 않고 있다는 사실을 알았다. 여기엔 두 가지 이유가 있었다.</p>
<ol>
<li>창고관리시스템(WMS)는 PDA를 통해 이루어지는데, 창고의 1/3 정도가 인터넷이 안되고 있었다. 창고의 일부 구간에서는 쓸 수 있고 일부 구간에서 쓸 수 없다면 당연히 나 같아도 쓰지 않았을 거다. 좀 어이가 없긴 했는데 창고쪽도 당시는 보관 및 출고 물량도 적고 솔루션에 버그도 많아서 수동으로 처리하고 있었다.</li>
<li>가장 큰 문제는 <code>출고 입력 -&gt; 송장 출력 -&gt; 피킹/패킹 -&gt; 출고</code> 로 이어지는 기획이 하나도 안 들어맞았다. 송장은 CJ 프로그램을 통해서 인쇄했기 때문에 출고는 계속 나가고 있었으나 문제는 정확한 위치와 재고였다. 어떤 물건 A가 위치 1, 2, 3에 있다면 지금 우리 WMS가 <code>위치1의 A 2개 </code>이런 식으로 찍어주면서 송장이 인쇄되어야 하는데 그게 계속 안되고 있었다.</li>
</ol>
<p>이 때문에 실제 전산상 재고와 실물 재고가 맞질 않았고 사용자(화주) 입장에서는 애당초 우리가 만든 솔루션의 실시간 가시성이 0에 수렴했다. 실시간 가시성은 둘째치고 전산재고와 실재고를 맞추는게 우선이었다. 나는 창고에 지시하여 택배사 출고 마감과 설 연휴 이전의 이틀을 모두 재고파악에 투입시켜서 DB의 재고를 맞추고 매일매일 출고건을 스크립트를 통해 수동으로 재고 차감해주는 일을 1분기 내내 진행했다. 업무시간에는 앞서 재고 맞추는 일을 주로 했으며 밤에는 개발을 했다.</p>
<p>1분기 막바지에 웹에서 송장을 대량으로 뽑아낼 수 있게 되었는데, 그러니 이제 어드민 기능 부족이 문제가 되었다. 슬랙 지원-풀필먼트 채널에서는 창고 오퍼레이터들의 요청과 버그 리포팅이 매일 불을 뿜었다. 엎친데 덮친격으로 풀필먼트 백엔드 (나 빼고) 3명 중 1명이 이탈하게 되었다. 어쩔 수 없이 이제 막 입사한 신입도 바로 실전 투입을 시킬 수 밖에 없었다. 6.25 당시 교도대대라는 이름으로 학사생도를 전선에 밀어넣은 윗 사람들의 기분이 이렇겠구나 생각이 들었다.</p>
<p><code>일 따위가 날 울게 만드는 인생은 덧없다</code> 라는 생각을 평소에 하고 있었는데, 프로그래밍 시작하면서 이때는 정말 울고 싶었다. 낮에는 계속 이슈 대응, 밤에 코딩하는 시간이 계속 이어졌다. 창고에서 요구하는 요청 사항 중 자동화 할 수 있는건 어드민에 기능을 붙여서 창고 이슈는 스스로 해결할 수 있도록 만들어 줘야 개발팀의 낮 시간이 편해진다. 이런 상황은 거의 상반기 내내 이어졌다.</p>
<h2 id="업무-2---국제물류포워딩">업무 2 - 국제물류(포워딩)</h2>
<p>상반기 풀필먼트 정상화에 매달리느라 포워딩은 미들급 개발자 한 명에게 일임을 하였다. 지금와서 생각해보면 일임이 아니라 방치인 것 같다. 하긴 나부터도 최전선에서 총질하고 있는 마당에 누가 누굴 신경쓸 수 있는 상황이 아니었다. 국내 물류 관련 프로젝트도 이제 갓 1년된 주니어 개발자에게 맡겼는데, 원래 다른 회사와 협업하는 일은 주니어 개발자에게 잘 주지는 않았다만 그럴걸 고려할 때가 아니었다. 올해 1분기가 끝나갈 당시에는 앞서 말한 미들급 개발자를 빼고는 경력 1년이 백엔드에서 가장 경력이 오래된 사람이었기 때문이다. 😂</p>
<p>3분기부터 풀필먼트를 새로 오신 경력 개발자분께 넘기기 시작하면서 다시 포워딩으로 넘어오기 시작했는데 하필 그 때 당시 그 미들급 개발자는 이직하게 되었고 다시 포워딩 파트를 맡게 되었다. 하반기에는 풀필먼트보다는 국제물류에 좀 더 힘을 싣기로 회사에서 결정을 해서 하반기부터는 계속 국제물류쪽 개발을 하고 있다. 12월부터는 회사의 중요한 개발을 위해 직접 개발을 하면서 어떤 곳에는 PM으로 부르는 PO 역할을 잠깐 맡게 되었다. 특히 한 번에 3~4개의 일을 동시에 관리하고 있긴 한데 나도 개발하면서 관리까지 하니까 정신은 없지만 이것도 잠깐 시한분 PO라 그런가 재미는 있다.</p>
<h2 id="업무-3---개발팀">업무 3 - 개발팀</h2>
<p>올 해는 개발팀에 특이점이 상당히 많았다. 개인적으로 처음으로 개발팀원 퇴사를 겪었고, 내내 나를 괴롭힌 <code>백설공주와 일곱난쟁이</code> 문제를 어느정도 해결할 수 있었다. 또한 개발팀 리소스가 역대급으로 늘어났고 역대급으로 빠졌다.</p>
<p>작년 개발팀의 가장 큰 문제는… 나, 디자이너 빼고 7명의 개발팀원들의 경력을 다 합쳐도 내 경력이 안된다는 점이다. 작년 상황을 일반 기업에 대입해 보자면 차장1, 사원 6이었다.(디자이너 제외) 좀 어이없는 조직 구성이긴 하지만 … 어쩔 수 없었다.</p>
<p>올 해 연말에는 총원이 8명이 늘어난 17명이 되었다. 프론트엔드가 2명이 늘었으며, 백엔드는 6명이 늘었다. 부장급과 대리급도 영입하여 작년보다는 조금 나은 상태인 부장1, 차장1, 대리 2, 사원 12이 되었다.</p>
<p>그래도 여전히 사원이 많다. 여기에는 여러 이유가 있긴한데, 크게 2가지만 뽑자면 대표의 빠른 사업 전개 속도와 채용의 불확실성이다. C레벨은 대표의 사업 전개를 도와주는 이들이다. 대표는 기업가 정신에 대해서는 정말 존경할 만한 사람인 지금 대표가 여러 사업을 벌이다보면 반드시 어떤 항목이 언제까지 개발 되어야 하는 일이 많다. 맞다. 할 일이 겁나게 많다. 아마 개발팀 크기가 네이버급이었으면 아마 뭐가 되어도 되었을거다.</p>
<p>문제는 지금 회사의 채용 파워다. 배민이나 네이버에서 경력 많고 실력 뛰어난 개발자를 구하는건 “상수"다. 수 많은 지원자들이 있을테니 언제나 마음만 먹으면 가능하단 얘기다. 하지만 여기는 “변수"이다. 회사 크기도 작거니와 B2B, 수출입물류라는 생판 모르는 분야다보니까 지원자가 선호하지 않는 분야다. 사업을 전개해나가기 위해서는 개발 리소스 확충을 해야하는데, “실력 좋은 경력 개발자를 구해서 하겠다"는 곧 “대표의 비즈니스는 개발팀에서 개발해 줄수도 있고 못해줄 수도 있다"라는 말이 된다. 반면 신입급 채용은 우리에게도 “상수"이다. 채용 공고를 열면 우리같은 쪼렙 회사에서도 많게는 3자리수의 지원자가 몰린다. 내 입장에서는 사업을 전개를 지원하기 위해선 변수보다는 상수에 기대야한다.</p>
<p>근데 이러면 계속 신입 밖에 받을 수 없는 악순환에 빠질 수 있기에 이 기형적인 구조를 완화할 수 있도록 이래저래 궁리 중이긴 하다.</p>
<p>어찌되어 백엔드를 왜이렇게 많이 뽑았나하면… 올 해 개발팀 이탈인원이 6명이었는데 전원 백엔드였기 때문이다. CTO이자 백엔드 팀장으로 반성해야 할 부분도 있고 불가항력도 있었다. 6명 중 절반은 불가항력에 가까웠다. 1명은 입사 한 달 만에 대기업 오퍼로 이직, 1명은 내부 집안 사정으로 퇴사, 1명은 반 창업으로 퇴사했다. 하지만 나머지 3명의 이탈은 살짝 뼈아픈 일이었다. 아무래도 1, 2분기 내내 풀필먼트 정상화에 매달리느라고 팀원 매니징을 전혀 못한 여파라고 생각한다.</p>
<h2 id="업무4---기술">업무4 - 기술</h2>
<p>올해는 작년에 비해 기술적으로 딱히 발전한건 없다. 크게 기술적 발전이라면 APM 추가, Go 언어 확대 도입정도이지 않을까.</p>
<h2 id="개인">개인</h2>
<p>상반기에는 완전 온 힘을 다해 이슈를 막느라 힘들었고 3분기에는 개인적으로 회사 들어와서 가장 힘든 시기였다. 1~2 분기 달린 여파가 3분기에 오기 시작했는데 그건 바로 번아웃이었다. 정확하게는 번아웃이 온 건 아니고 번아웃의 전조 증상을 심하게 느끼고 있었다. 과거 번아웃으로 퇴사까지 한 쓰디쓴 경험의 댓가로 얻은 능력(?)이다. 어찌되었건 잘 넘어가긴 했는데.. 3분기에는 번아웃 외에 회사 내에 사람과 사람 사이의 의견 대립 때문에 너무 힘들었다.</p>
<p>어쨌든 3분기 내내 나를 괴롭히던 컨디션 저하는 4분기 중반부터는 다시 정상궤도에 올라온 상태다.</p>
<h2 id="회사">회사</h2>
<p>작년 대비 매출 수 배 성장했다. 올해 5월 경에는 시리즈 A 투자도 받았다.</p>
<h3 id="작년에-하고팠던-일-성과-보고">작년에 하고팠던 일 성과 보고</h3>
<p>한 사람이 매니징할 수 있는 범위는 6~7명 정도라는 평범한 진리를 깨달았다</p>
<ol>
<li>좋은 경력자 분 3명 뽑아서 150% 부하를 100%로 낮추고 싶다.
-&gt; 3명까진 실패. 2명은 뽑았다. 부하는 아직 많이 떨어지진 않았다.</li>
<li>책을 완성까진 아니고 출판사와 계약을 하고 싶다. 그럼 두 번째 책이 되겠지. 첫 번째 책 쓸때 너무 고생을 해서 또 쓰고싶지는 않은데, 요즘 좀 욕심이 생긴다. : &gt;
-&gt; 못했다. 올 해 중으로도 못할 듯 하다</li>
<li>부트캠퍼를 위한 컴퓨터 과학을 출판사와 계약하고 싶다.
-&gt; 이 것도 위 책을 쓰느라 못썼다</li>
<li>Nest.js 용 eslint 를 만들다가 말았는데 좀 더 해서 완성을 하고 싶다. 사실 0.0.4인가 6 버전이 있긴하다. Nest.js Controller에서 @apiOperation 를 반드시 추가해야하고 그 인자로 summary, description을 넣어야 한다는 룰이다.
-&gt; 이것도 못했다</li>
<li>사이드 프로젝트 끝을 내고야 말겠다.
-&gt; 포기로 끝을 냈다. 어쨌든 성공</li>
<li>MDN 50 PR Merge 를 달성했다.</li>
</ol>
<h3 id="내년에-해야-할-일-조직">내년에 해야 할 일 (조직)</h3>
<ol>
<li>QA 조직을 만들고 싶다. 근데 아직까지 회사 내부 조직 문제상 가능할지 모르겠다.</li>
<li>배민의 문화인 피트 스탑을 꼭 개발 문화에 넣어보고 싶다.</li>
<li>인프라, 포워딩 개발 권한 이양
백엔드 인프라는 AWS / EKS 인데, 이 관리 권한과 책임을 선임 백엔드 개발자분께 상당 부분 이양해드릴 예정이다. 포워딩쪽도 새로 개발자가 오셔서 이 부분도 이관해드릴 예정이다.</li>
<li>좀 더 매니징에 신경쓰자.</li>
<li><code>기술 조직은 회사의 비즈니스 지표에 따라 평가되어야 한다</code>는게 지론이다. 회사의 성장을 위해 좀 더 공격적으로 나아가고 싶다.</li>
</ol>
<h3 id="내년에-해야-할-일-기술">내년에 해야 할 일 (기술)</h3>
<ol>
<li>Node 14 -&gt; 16
아마 2~3월 달쯤에 수행할 듯 하다. 이것 때문에 기능 개발과 동시에 Data Layer를 분리하는 작업을 하고 있다. 16으로 올리면서 NestJS, TypeORM 버전업도 동시에 진행할 예정이다. 좀 더 나가면 Node 18로 올라갈 수 있지 않을까.</li>
<li>Go 언어를 좀 더 공격적으로 도입해보자.</li>
<li>WASM 한 번 테스트해볼까? 하지만 Rust 도입은 절대 안할 예정</li>
</ol>
<h3 id="내년에-달성하고-싶은-일개인">내년에 달성하고 싶은 일(개인)</h3>
<ol>
<li>Nest.js 용 eslint 를 좀 더 보강하고 싶다</li>
<li>지금 쓰고 있는 글을 출판사와 계약하고 싶다. 글을 써야하는데 출퇴근할때 쓰긴 하는데 어느정도까지 쓸 수 있으려나 모르겠다.</li>
<li>MDN 100회 PR Merge을 달성하고 싶다.</li>
</ol>


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

dev || log

CTO 3년차. 급하게 쓴 2022년 회고.
작은 기업의 CTO는 Chief of Technology Officer가 아니라 Chief of Troubleshooting Officer라는 우스개소리가 있다. 하지만 적어도 올 한해 나로서는 우스개소리가 아니었다. 올 한해는 CTO가 된 이후 업무적으로나 업무 외적으로나 가장 힘든 한 해였다.
풀필먼트 업무가 본궤도에 오르면서 반드시 처리해야할 일은 많아지는 한편 심각한 개발 리소스 부족에 직면하게 되었다. 직접 API개발, 코드리뷰 등 직접 개발의 최전선에 있긴 하지만 이 때는 개발 리소스가 너무 없어서 군단장(장군)이 직접 참호에 들어가서 밀려드는 이슈에 대고 총을 쏘아야 했다.

2022년 회고

댓글