성장하는 스타트업은 필요에 따라 사람을 충원한다. 하지만 충원될 사람을 충분히 업무에 온보딩 시키기 위한 프로세스와 자료는 미리 준비되어 있기 어렵다. 일손 부족해서 사람을 뽑은 거니까, 언젠가 들어올 누군가를 위해 없는 일손을 미리 쓸 수 없었던 것은 어쩌면 자연스럽다.
예전 동료 중 한 명이 입사하고 나서 1달간 뭘 해야 할지도 모른 채로 방치된 적이 있었다. 그 때 나는 내가 맡은 중요한 기능 개발이 이미 최초 목표 일정을 넘긴 시점이었고, 주변을 쳐다볼 여력이 전혀 없는 상태였다. 그 동료는 이로 인해 심각하게 잘 못 들어온 거 아닌가 하는 고민을 했었다고 훗날 얘기했고, 나는 진심으로 미안하다고 사과했다. (지금도 술을 먹으면 가끔 그때의 이야기를 듣는다)
허슬의 시간이 끝나고, 그 때의 반성 이후로 온보딩을 고민하기 시작했다. 새로 입사한 사람이 최대한 빠른 시간 내에 기존 멤버와 대등한 수준의 논의와 의사결정을 할 수 있는 동료가 될 수 있는 상태로 만드는 것을 온보딩의 목표로 삼았다. 하지만 당시 코드베이스는 이미 상당히 복잡했고, 문서는 거의 없다시피 했다. 최신 상태로 유지되는 문서는 정말 중요한 몇 개 수준이었다. (그나마 그 문서들은 잘 유지되었던 게 다행이었다)그렇다고 여전히 부족한 시간에 잘 정리된 문서를 쓰는 일 또한 투자 대비 효용이 썩 기대하기 어려운 일이었고, 그렇게 만들어진 문서를 검토하고, 최신 버전으로 업데이트 되어 있도록 하는 일 또한 상당한 비용을 치를 게 불보듯 예상되는 방법이었다.
그래서 전체적으로 제품 코드에 대해 설명할 항목들을 쭉 목차 수준에서만 정리를 한 다음에 주니어 한 명과 정기적으로 줌을 했다. 개념을 설명하고, 코드를 같이 살펴보고, 어떻게 동작하는지 실행해서 보여주고, 어떤 부분을 조심해야 하는지를 설명했다. 그리고는 주니어에게 녹화된 줌 영상을 유튜브 비공개 채널에 올리고, 영상의 내용을 문서로 요약하고, 각 주제 항목마다 영상에 타임스탬프를 매겨두도록 요청했다. 개인적으로는 부끄러움 가득한 코드베이스가 도망갈 곳 없이 영구히 박제되는 느낌이 들어서 너무 괴로웠지만, 필요하다는 사실 자체는 부정할 수가 없었다. 그렇게 대략 16편의 (기억에 의존한 거라 정확하지 않음) 영상을 만들었다. 소요된 시간은 내가 한 사람을 온보딩 하는 데 드는 시간의 총합을 넘지 않는 수준이었다.
그렇게 한 번 자료를 구축한 뒤로는 일이 꽤 쉬워졌다. 새로 들어오는 사람이 있을 경우 매일의 온보딩 체크업 미팅 시간을 15분 가량 짧게 잡았다. 1일 1영상 정주행을 요청했고, 영상을 보면서 궁금했던 점들을 미리 온보딩 일지에 정리해 오도록 요청했다. 그리고 온보딩 체크업 미팅에서는 정리해온 내용을 같이 읽고 바로 답변을 해줬다. 단지 수동적 수용이 아니라 능동적 학습이 되도록 하기 위해 현재의 이해 수준에서 해결할 수 있는 소소한 태스크를 먼저 전달하고, 그 일을 하기 위해서는 어떤 개념을 이해해야 하는지, 어떤 영상을 참고할 수 있는지를 함께 알려줬다.
이 방법은 꽤 유용했다. 흔히 새로 입사한 사람이 기존의 코드베이스를 충분히 이해하지 못하는 어려움을 겪다 보니 의도치 않게 자연스레 기능별로 담당자가 나뉘어지는 경향이 있다. 독립적 결정을 최대한 빠르게 수행될 수 있도록 위해 관심 영역을 분리하기 위한 의도로 담당자를 나누는 것은 긍정적인 선택일 수 있지만, 코드베이스에 대한 지식을 충분히 공유하지 못해서 자연스레 경계가 만들어지는 건 조직의 생산성에 상당한 악영향을 끼친다. 그럼에도 불구하고 이러한 형태가 자연스레 형성되는 이유는 코드를 읽을 줄 몰라서가 아니라 “이 코드(또는 아키텍처)가 무슨 의도로 이렇게 짜여져 있는가” 라는, 코드에는 거의 쓰여 있지 않은 정보를 얻을 방법이 없어서이다. 기능이 너무 전형적이면 이런 정보가 상대적으로 덜 중요하지만, 복잡하고 추상화가 많이 개입되는 어플리케이션일 수록 의도에 대해 설명하는 정보의 가치가 큼에도 정보를 얻기는 쉽지 않다. 이런 정보는 문서로 설명할 수 있는 부분도 있지만, 코드베이스를 같이 보면서 설명하는 게 훨씬 더 효과적이다. 따라서 영상이라는 매체가 가지는 강점이 극대화될 수 있다. 또, 몇 번이고 다시 돌려보면서 이해할 수 있다는 점도 상당한 장점으로 작용한다. 지금 생각해 보면 유튜브 댓글로 질의응답이 오갔어도 괜찮았을 것 같다.
더불어 너무 완벽한 온보딩 자료를 만들려 하기 보다는, 온보딩 체크업 미팅 시 설명한 부분에 대해 “다음 사람을 위해서 이 부분을 더 보완해주세요” 라는 요청을 잊지 않았다. 새로 설명한 내용, 그동안 바뀐 부분. 내가 설명했을 때 어려웠던 부분들을 좀 더 쉽게 다시 설명한 자료. 이런 것들을 문서에 보완해가면서 신규입사자도 다음 사람을 위해 공헌할 수 있는 부분을 만들어 주려 했고, 그들은 이내 다음 입사자의 훌륭한 도우미가 되었다.
이러한 방식의 접근을 새로운 회사에서도 시도했다. 내가 이해하기 위해 정리한 제품의 특징, 성능을 정의한 기준, 개발 프로세스, 주요 이슈들을 새로 제품 개발 팀을 맡은 팀 리더에게 설명하기 위해 슬라이드로 정리를 했고, 그 한 명의 오디언스를 타겟으로 한 자료이긴 했지만 전사 교육으로 진행했고, 이걸 영상으로 만들었다. 이렇게 영상들이 빠르게 갖춰지면서 새로 입사한 사람들을 온보딩 시킬 때 “아~ 그건 이 자료 보시면 설명이 잘 되어 있을 거예요” 라면서 빠르게 전해줄 수 있었다.
돌이켜서 관찰해보면 온보딩은 단지 누군가를 신속하게 승선시키는 정도의 의미로 끝나지 않았었다. 사람은 무언가를 신선한 시각으로 바라볼 수 있는 시간이 한정되어 있다. 그리고 일이 익숙해지면 관성이 생기게 마련이다. 그래서 아직 신선한 시각으로, 아직 모든것에 도전적인 태도를 가졌을 때 전체의 구조를 더 빨리 볼 수 있게 된다면, 관점 자체가 훨씬 넓어지게 된다. 적절한 온보딩은 승선한 동료가 얼마나 훌륭한 기여를 할 수 있게 해주는지에 큰 영향을 미치는, 장기적 레버리지가 큰 프로세스라고 느껴진다. 아마 어떤 새로운 일을 하게 되더라도, 그 상황이 허락하는 여건 내에서 비슷한 시도를 할 것 같다.