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

<article>
   
  <div><p>회고는 사실 공개적으로 처음 써본다. 떨려…</p>
<h2 id="개인">개인</h2>
<ol>
<li>
<p>연초대비 살을 10kg 뺐다. 의지를 가지고 뺀건 맞는데, 회사일이 고되어 다이어트에 매우 큰 도움이 되었다. 퇴근해서 몸무게를 재보면 아침대비 1kg나 빠지는 날도 꽤 있었다. 뱃살과 턱살은 사라졌는데 그 반대급부로 추위를 잘타게 되었다. 요즘은 날이 추워서 잘 먹어야 하기 때문에 최저 몸무게보다 1~2kg 정도 더 찌긴 했지만….</p>
</li>
<li>
<p>일을 그만 벌여야겠다.
하나, 올 한해도 사이드프로젝트를 진행하지 못했다. 내 커밋 기록을 보니까 딱 11개월이 마지막이었다. 그만큼 바쁘기도 했고, 거의 회사일에 올인했던 올 한해였다.</p>
<p>둘, <code>부트캠퍼를 위한 컴퓨터 과학</code> v0.2 정도 쓰다가 또 다 못썼다.</p>
</li>
<li>
<p>번아웃을 슬기롭게 잘 넘겼다.
중간에 번아웃이 한 번 올뻔했다. 번아웃을 3년 전에 제대로 한 번 겪은 적이 있다. 안 겪어본 사람은 어떤 느낌인지 전혀 감이 안올텐데, 딱 한 마디로 요약할 수 있다.</p>
<p><strong>“프로그래머인데 코드를 쓸 수가 없다”</strong></p>
<p>이미 한 번 겪으니까 다행히 번아웃의 전조 증상들을 쉽게 알아차릴 수 있게 되었고 나름의 해결책도 생겼다. 해결책 중 하나는 책을 쓰는건데 올해만 10포인트 글자로 거의 100페이지 가까이 썼고, 다른 하나는 출퇴근시 아무것도 안하고 넷플릭스만 보는 일이었다. 물론 야근은 안하고</p>
</li>
</ol>
<h2 id="회사일">회사일</h2>
<h3 id="기술도입">기술도입</h3>
<p>올 한 해는 회사나 개발팀이나 많은 변화가 있었다. 프론트엔드는 프론트엔드 리더에 상당히 권한을 이양했고 팀 내의 기술 단일성을 해치지 않는 수준에서 뭐든지 할 수 있도록 했다.</p>
<ul>
<li>
<p>Nest.js 도입</p>
<p>기존 typescript-rest 라이브러리에서 Nest.js 로 이관했다.</p>
</li>
<li>
<p>monorepo 도입</p>
<p>프론트엔드와 백엔드 각각 모노레포를 도입했다. 프론트엔드는 lerna로, 백엔드는 nest 기반 모노레포로 구성했다. 다만 프론트와 백엔드 두 개를 통합하진 않았다.</p>
</li>
<li>
<p>Vercel 도입</p>
<p>싱가폴 서비스를 하려다보니, CDN을 태워도 되지만 차라리 Vercel로 Edge Network 에 접속하게 하는게 더 좋겠다는 생각으로 프론트엔드 리더와 함께 상의하여 Vercel을 도입했다. 현재 만족하며 쓰고 있다. 다만 이 부수효과로 프론트엔드팀의 레포가 Azure Devops에서 Github로 이전하게 되었다. Vercel이 Azure Devops 지원을 안하기 때문이다.</p>
</li>
<li>
<p>Event 중심의 비동기적 동작</p>
</li>
<li>
<p>모놀리틱 구조를 일부 분산 시킴. Go 도입했다가 실패.</p>
</li>
</ul>
<h3 id="서비스-도입">서비스 도입</h3>
<ul>
<li>
<p>잔디 → 슬랙</p>
<p>합류했을때 회사는 잔디를 사용하고 있었다. 원래 난 잔디를 선호하는 사람은 아닌데, 그렇다고 회사 인프라를 내맘대로 바꾸는 행위는 별로 좋아하지 않는지라 그대로 잔디를 썼다. 잔디를 2년 가까이 써보니 장단점이 명확했다. 한 마디로 하자면 잔디는 IT가 아닌 “일반회사”용 메신저라는 점이다. 연동되는 기능 차이가 젖먹이 유아와 전문가 수준이다. 예전부터 슬랙으로 가고 싶었으나 순수 IT회사가 아니라서 비개발직군이 상당히 많기 때문에 낯설은 UI에 적응하지 못할까봐 상당히 망설여지기도 했다. 허나 프론트엔드 리더의 꽤 강력한 요구에 용기내어 변경했다. 의외로 비개발직군에서 불편하다고 하지 않는다. 사실 그 분들은 잔디의 메신저 기능 밖에 안썼던지라 별 무리 없이 넘어올 수 있었다.</p>
</li>
<li>
<p>Notion</p>
<p>원래 개발 내용은 Azure Devops 내 Wiki 를 사용했었다. 기능이 너무 제한적이고 비개발직군이 사용하기 좋지 않아서 내가 총대를 메고 도입했다. 덕분에 흩어져 있던 문서를 노션으로 모두 모을 수 있었는데다가 사내 문서량도 많아져서 만족하며 쓰고 있다.</p>
</li>
</ul>
<h3 id="스터디">스터디</h3>
<ul>
<li>클린코드</li>
<li>이펙티브 타입스크립트</li>
</ul>
<h3 id="행사---테크토크">행사 - 테크토크</h3>
<p>다른 회사에서는 어떻게 일하는지 궁금했다. 그래서 인맥을 동원해서 좀 이름있으신 분들을 초청해서 개발팀과 대화를 나누는 자리를 마련하곤 한다. 물론 소정의 사례는 한다.</p>
<ul>
<li>제 1회 대담자 박*운님(토스)</li>
<li>제 2회 대담자 이*립님(당시 마켓컬리)</li>
</ul>
<p>3회, 특별 대담자도 벌써 섭외했다 후훗. 올 해는 딱 5회까지 진행할까 한다.</p>
<h3 id="행사---mdn-기여">행사 - MDN 기여</h3>
<p>개발을 하면서 MDN으로부터 상당히 많은 도움을 받았다. 개인적으로 은혜를 입었으면 반드시 갚아야 한다고 생각하는 사람이라 무언가 기여하고 싶어서 MDN 한글화 프로젝트에 계속적으로 PR을 보내고 있다. 여태 20번 넘는 PR을 보내어 머지 되었다.</p>
<p>이 좋은걸 나만 할 수 없어서 백엔드 팀만 시범적으로 MDN에 기여하는 행사를 가졌는데, 다음 번에는 개발팀에 분기별 1회 정도 기여 페스티벌이라도 열까 생각하고 있다.</p>
<h3 id="개발팀">개발팀</h3>
<p>작년 12월에 5명에 불과했던 개발팀은 1년이 지난 지금 이제 13명이 되었다. 10명이 들어왔고 주니어 개발자 1명이 입사 과정에서의 문제로 잠깐 일하고 헤어졌으며 1명은 복학때문에 미국으로 돌아갔다. 겉보기에는 괄목할만한 성장이지만 내부 사정은 썩 그렇게 아름답지가 않았다.</p>
<h3 id="개발팀의-말-못할-사정">개발팀의 말 못할 사정</h3>
<p>치부를 드러내는 듯하여 공개적으로 말할까 망설였지만 어차피 시드 ~ 시리즈 A정도에서 많은 IT기반 스타트업들이 겪고 계시리라 생각하여 용기를 내본다.</p>
<p><strong>“인큐베이터”</strong></p>
<p>누군가 나에게 이런 멋진 별명을 붙여주었다. 아주 맞는 말이다. 올 해 추가로 팀에 합류한 동료 8명의 평균 경력은 1년도 안된다. 절반 이상이 경력 0의 완전 주니어 개발자였다. 아 물론 올해를 맞이하기 전에 있던 개발자(본인 제외) 3명 중 2명이 경력 0였으니까 뭐 이젠 그러려니 한다.</p>
<p>개발팀 채용, 운영, PM, 리드 개발, DevOps 를 책임져야하는 초창기 CTO(라 읽고 잡부라 부르는 직책)의 역할 중에서 나를 제일 괴롭혔던 일은 뭐니뭐니해도 채용이었다. 개발자 채용의 어려움은 시드 ~ 시리즈 A단계의 모든 IT기반 스타트업들이 다 겪고 있으리라 생각한다. 나에게 있어서 채용은 <strong>세 가지 문제</strong>로 여러웠다.</p>
<p>첫 번째는 가용할만한 개발자 채용 채널이 없었다. 나는 다른 CTO처럼 스타 개발자도 아니고 아는 개발자도 많지 않은, 즉 동원할 사적 네트워크가 없었다. 공개적 개발자 구인 네트워크 중 최고인 원티드는 아무나 채용공고를 낼 수 없고 일정 투자금이나 매출액 조건이 있었기 때문에 사용할 수 없었다. 로켓펀치는 개발자 구인글을 올릴 수 있었지만 …. 서비스 만드는 분들께는 정말정말 죄송한 말씀인데 파워가 너무 약했다.</p>
<p>두 번째, 경력자 지원이 너무너무 없었다. 1월 말에 다행히 본엔젤스와 빅베이슨으로부터 프리A 시리즈 투자를 받을 수 있었고 받자마자 바로 원티드 기업회원 가입신청부터 했다. 그 당시만해도 정말 희망에 부풀었다. ‘우리도 이제 실력자 분들을 모실 수 있겠구나’ 하는 희망 말이다. 근데 두괄식으로 시작한 문단에서 눈치채셨을거다. 채용 공고를 열자마자 부트캠프 수료하신 주니어 분들이 벌떼처럼 몰려들었다. 아마도 많은 부트캠프에서 사용하는 Node.js + React.js 스택이라서 그러리라 생각하긴 한다. 참고로 그 벌떼 중에 몇 분이 저와 같이 일하고 있다. : ) 하지만 충격적이게도 경력있으신 분들의 지원은 없었다. (1~2년 경력의 지원자분 1~2명 있긴 있었지만, 너무 테크스택이 안맞는 분들이라 패스). 여러 이유가 있을 수 있겠지만 채용공고가 매력적이지 않거나, 잘 모르는 회사거나 CTO가 이름난 사람이 아니거나, 테크스택이 안맞거나 ….</p>
<p>세 번째는 회사의 네임 파워가 너무 약하고 개발자들이 별로 관심갖지 않는 사업을 하고 있다. 개발자 중에 전동 킥보드 타본 사람은 많지만 국제 물류를 경험한 사람은 거의 0에 수렴한다. 개발자도 직장인이니까 이름난 곳(네XX, 쿠X 등)이나 돈 많이 주는 곳으로 가겠지만 아무래도 스타트업이다보니 경력 개발자들은 자신의 관심사가 회사 선택에 미치는 영향이 아예 없다고 말할 수 없다. 그러다보니 이름나지도 않고 자금력도 달리고 관심사와 먼 일을 하는 우리는 아무래도 선택지에 없을 가능성이 매우 높다.</p>
<h3 id="해답-경력자가-없으면-경력자를-만든다">해답: <strong>경력자가 없으면 경력자를 만든다</strong>.</h3>
<p>작년부터 각종 테크 대기업에서 분기가 멀다하고 대규모 채용 운운하는 이 마당에 경력 개발자를 공개적으로 뽑을 확률은 굉장히 낮다고 판단했다. 이렇게 판단한게 작년 11월 쯤이었고 올해 초 투자를 받을때쯤 되서 사람을 뽑기 시작했다. 그 결과는 앞서 밝혔듯이 완전 망했다.</p>
<p>게다가 어쩌다보니 풀필먼트(WMS) 시스템을 자체 개발을 하게 되었다. 휴…. 다시 채용을 시작했는데 여전히 경력자는 거의 없었다. 이럴 경우 2가지 선택을 해야 한다. 언제 올지 모르는 경력직 개발자를 기다리면서 비즈니스를 불확실하게 만들던가 당장 신입을 뽑아서 내가 멱살잡고 하드캐리하느냐. 나는 후자를 택했다. 성향 차이인데 나는 불확실성을 썩 좋아하지 않기 때문이다.</p>
<p>그나마 경력 0~2년 개발자 3명을 채용해서 프론트엔드팀과 내가 직접 맡는 백엔드팀에 넣고 개발을 시작했다. 사실 풀필먼트 시스템을 주니어 3~4명 모아서 완성할 수 있는게 아니었는데 놀랄만큼 잘 따라와주어서 10월쯤에 풀필먼트 서비스를 오픈할 수 있었다. 가끔씩 이건 기적이 아닐까 생각도 해본다. 허나 남들은 개발자 수 십명에서 만드는 시스템을 고작 몇 명에서 만드려니 기능적으로 부족했고 앞으로 개발해야 할 분량이 너무나 많았다. 9월에 다시 채용을 시도했으나 또 망했다. 이번 채용도 결국 경력직을 뽑지 못했다. 그래서 또 주니어 개발자를 모시고 와서 일을 하고 있다.</p>
<h3 id="앞으로-또-주니어를-뽑을것인가">앞으로 또 주니어를 뽑을것인가</h3>
<p>답은 당분간은 <strong>아니오</strong>. 경력직이 들어오면 기존 조직이랑 어떻게 잘 융화되느냐가 제일 큰 문제지만 완전 경력 0 주니어가 들어오면 이 분께서 코드를 잘 짤때까지 옆에서 케어해줘야한다. 신입마다 능력이 다르고 단순히 개인적인 생각이지만 부트캠프 수료한 나름 평범한 분들이라면 초기 석 달은 -0.5, -0.3, 0.1 인분이다. 즉 초반에는 내 발목을 잡을 일이 많았기 때문에 업무 시간엔 이 분 가르키는데 쓰고 밤에 개발을 진행했으며 어떤 PR은 100번 가까운 코멘트를 주고받은 적도 있었다. 가끔씩 날아오는 정말 얼토당토 않은 PR을 볼때마다 내가 무슨 부귀영화를 누리겠다고 이 고생이냐며 속으로 엄청 울었다. 한 명 받을 때마다 수명 0.5년씩 줄어드는 느낌이었다.</p>
<p>나도 살아야 하기 때문에 경력직이 오기 전까지는 주니어를 더 받을 수 없다.</p>
<h3 id="분기별">분기별</h3>
<p>1분기: 처음으로 i18n의 쓴맛을 보았다. 현재 서비스를 해외로 들고 나가자니 상표권 문제가 걸려서 들고나갈 수 없었고, 현재 한국 수입으로만 최적화되어 있는 React 프로젝트에서 i18n을 적용하려니 정말 말도 안되게 힘들었다. 제일 힘든건 잘못 번역한 것과 빼먹고 번역을 못한것.</p>
<p>2분기: 풀필먼트 시스템 구축을 시작했다. 사실 나는 시스템을 새로 만드는걸 반대하는 입장이었다. 먼저 가용 리소스가 절대 부족했다. 위X, 품X, 두X 등은 개발자 수 십명으로 몇 년 동안해서 성과를 낸 회사다. 그 회사 상대로 개발팀 총원 5명 가지고 만들자고 했을때 사실 기가 막혔다. 추가 인원 채용해서 만들라는데 안그래도 경력자 뽑기 어려운 마당이라 그 말인즉슨 주니어 2~3명 추가해줄테니까 만들어라는 말이 되겠다. 이건 뭔가 천원 줄테니까 매점가서 빵하고 우유사오고 300원 남겨와라는 말과 동일하지 않은가. 두 번째는 도메인 지식이고. 근데 결국 만들게 되었다. 4~5월 중에는 거의 스터디 및 설계만 했고 실질적으로 프로그래밍에 들어간건 6월정도였다.</p>
<p>3분기: 풀필먼트 시스템을 개발했다. 진짜 힘들었다. 백신맞은 다음 날도 일했고 주말에도 일하고…</p>
<p>4분기: 결국 10월달에 풀필먼트 오픈했다. 오픈 후에도 100개가 넘는 버그와 추가 요구사항이 들어와서 11월 중순까지도 악전고투였다. 그 와중에 신입이 몇 명 더 들어왔고 내가 한 달 정도 가르친 다음에 바로바로 실전에 투입했다. 신병 징집해서 바로 최전선으로 보내는 지휘관 마음이 이와 같았구나.</p>
<h3 id="회사-자체">회사 자체</h3>
<p>뉴욕타임즈 전 CTO가 남긴 말 중에 “기술조직은 회사의 비즈니스 지표에 따라 평가되어야 한다"는 말을 굉장히 좋아한다. 기술 조직은 기술적 성취도 중요하지만 결국 회사의 비즈니스 결과로 좌지우지 된다. 특히 스타트업이 그러하다. 돈은 못버는데 / 투자를 못받는데 분위기 좋은 개발팀이 있다? 글쎄요다. 아무리 좋은 팀이라도 결국 돈 못벌면 공중 분해는 시간 문제다.</p>
<p>회사가 작년 대비 매출은 수 배나 성장했다. 올 해는 성공적이라고 자평해본다.</p>
<h2 id="내년에-하고싶은-일">내년에 하고싶은 일</h2>
<ol>
<li>좋은 경력자 분 3명 뽑아서 150% 부하를 100%로 낮추고 싶다.</li>
<li>책을 완성까진 아니고 출판사와 계약을 하고 싶다. 그럼 두 번째 책이 되겠지. 첫 번째 책 쓸때 너무 고생을 해서 또 쓰고싶지는 않은데, 요즘 좀 욕심이 생긴다. : &gt;</li>
<li><code>부트캠퍼를 위한 컴퓨터 과학</code>을 출판사와 계약하고 싶다.</li>
<li>Nest.js 용 eslint 를 만들다가 말았는데 좀 더 해서 완성을 하고 싶다. 사실 0.0.4인가 6 버전이 있긴하다. Nest.js Controller에서 <code>@apiOperation</code> 를 반드시 추가해야하고 그 인자로 summary, description을 넣어야 한다는 룰이다.</li>
<li>사이드 프로젝트 끝을 내고야 말겠다.</li>
</ol>


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

dev || log

회고는 사실 공개적으로 처음 써본다. 떨려…
개인   연초대비 살을 10kg 뺐다. 의지를 가지고 뺀건 맞는데, 회사일이 고되어 다이어트에 매우 큰 도움이 되었다. 퇴근해서 몸무게를 재보면 아침대비 1kg나 빠지는 날도 꽤 있었다. 뱃살과 턱살은 사라졌는데 그 반대급부로 추위를 잘타게 되었다. 요즘은 날이 추워서 잘 먹어야 하기 때문에 최저 몸무게보다 1~2kg 정도 더 찌긴 했지만….
  일을 그만 벌여야겠다. 하나, 올 한해도 사이드프로젝트를 진행하지 못했다. 내 커밋 기록을 보니까 딱 11개월이 마지막이었다.

2021년 회고

댓글