원격 협업 시대의 온보딩 문서 만들기

 

작년부터 재택근무가 길어지면서, 신규 입사자 온보딩이 예전과는 완전히 다른 문제가 되었습니다.
예전엔 옆자리 선배가 궁금한 거 있으면 바로 물어보고, 회의실에서 화이트보드에 구조도 그려주면서 설명해줬는데, 지금은 그게 불가능해요.
저희 팀에 신규 입사자가 들어왔을 때, 첫 2주 동안 슬랙 DM으로만 30개 넘는 질문을 받았던 게 이 글을 쓰게 된 계기였습니다.
이건 온보딩 문서가 없어서가 아니라, 있는 문서가 원격 환경에 맞지 않게 짜여 있어서 생긴 문제였어요.

 

사무실 근무 시절에는 온보딩 문서가 좀 부실해도 사람이 그 틈을 메워줬습니다.
누군가 물어보면 바로 답해주고, 어깨너머로 보고 배우는 것도 많았어요.
그런데 원격 환경에서는 이 즉시성이 사라집니다.
질문을 슬랙에 남기고 답을 기다리는 동안 신규 입사자는 그냥 멈춰 있는 시간이 생기고, 이게 며칠 쌓이면 온보딩 체감 속도가 확 느려집니다.
저희 팀은 이 문제를 겪고서야, 문서가 사람의 빈틈을 대신 채워줄 수 있을 만큼 촘촘해야 한다는 걸 깨달았어요.

 

처음엔 온보딩 문서 하나에 모든 걸 다 넣으려고 했습니다.
회사 소개, 조직도, 개발 환경 세팅, 서비스 아키텍처, 코드 컨벤션까지 한 문서에 다 있었는데, 신규 입사자 입장에서는 그냥 압도당하는 느낌이었다고 하더라고요.
그래서 저희는 온보딩 문서를 시점별로 다시 쪼갰습니다.
1일차엔 계정 발급, 툴 접근 권한, 개발 환경 세팅처럼 "당장 막히는 걸 뚫어주는" 문서만 보게 하고, 1주차엔 서비스 구조와 팀 프로세스, 1개월차엔 코드 컨벤션과 배포 프로세스처럼 시점별로 필요한 문서만 순서대로 노출되게 재구성했어요.
이렇게 나누고 나니 첫 주 질문 수가 눈에 띄게 줄었습니다.

 

문서를 아무리 잘 만들어도, "이거 지금 물어봐도 되는 질문인가"를 판단하는 심리적 장벽은 문서가 못 없애줍니다.
저희는 신규 입사자마다 버디를 한 명씩 지정해서, 사소한 질문은 언제든 편하게 물어볼 수 있는 창구를 따로 만들었어요.
버디에게는 매일 15분씩 짧게 체크인 미팅을 하도록 가이드했는데, 이 15분이 은근히 큰 역할을 했습니다.
문서로는 안 풀리는 "이게 팀 분위기상 괜찮은 건가요" 같은 질문들이 이 짧은 대화에서 다 해소되더라고요.
문서와 사람, 이 두 트랙을 같이 돌리는 게 원격 온보딩의 핵심이라는 걸 이때 확실히 알게 되었습니다.

 

온보딩 문서의 가장 큰 함정은, 만들고 나서 방치되는 겁니다.
저희도 초반엔 문서를 만들어놓고 반년 동안 업데이트를 안 해서, 새로 들어온 사람이 이미 없어진 툴 이름을 보고 헤매는 일이 있었어요.
그래서 규칙을 하나 만들었습니다.
온보딩 기간이 끝난 신규 입사자에게 반드시 "이 문서에서 헷갈렸던 부분"을 피드백받고, 그 자리에서 문서를 바로 고치는 걸 온보딩 프로세스의 마지막 단계로 넣었어요.
신규 입사자의 시선이 가장 날카로울 때 피드백을 받아야 한다는 걸 깨닫고 나서부터는, 문서가 훨씬 덜 낡은 상태로 유지되고 있습니다.

 

마지막으로 형식 얘기를 조금 덧붙이면, 저희는 온보딩 문서를 노션으로 관리하면서 각 문서 상단에 "마지막 업데이트 날짜"와 "담당자"를 반드시 적어두게 했습니다.
날짜가 오래된 문서를 보면 신규 입사자도 "이건 최신 정보가 아닐 수도 있겠다"고 스스로 필터링할 수 있으니까요.
또 텍스트로만 설명하기 어려운 아키텍처나 플로우는 캡처나 간단한 다이어그램을 꼭 넣도록 했는데, 이게 있고 없고에 따라 이해하는 속도 차이가 크더라고요.

 

온보딩 문서는 결국 "내가 없어도 팀이 돌아가게 만드는 장치"라는 생각이 듭니다.

저희 팀은 이 프로젝트를 하면서 온보딩 문서를 정리한 게, 사실 신규 입사자보다 기존 팀원들에게 더 도움이 됐다는 걸 알게 됐어요.
문서화 과정에서 "우리가 이걸 왜 이렇게 하고 있었지"라는 질문이 계속 나왔거든요.
다음에는 이 온보딩 문서를 정기적으로 감사(audit)하는 프로세스도 만들어보려고 합니다.