온보딩 첫 주: 읽을 것의 순서
신규 입사자에게 문서를 전부 주면 아무것도 안 읽힌다. 순서가 전부다.
다 주면 아무것도 안 읽힌다
처음 온보딩 자료를 정리할 때, 나는 모든 걸 한 노션 페이지에 때려넣었다. 아키텍처 다이어그램, 사고 대응 런북, 배포 가이드, 팀 컨벤션, 용어집까지. “다 거기 있어요”라고 했다.
막상 신규 입사자는 첫 주에 아무것도 기억 못 했다. 당연하다. 맥락 없이 문서를 읽으면 단어만 보인다.
문서가 부족한 게 아니었다. 순서가 없었다.
1주일, 읽히는 것만 남긴다
지금은 첫 주를 세 구간으로 자른다.
Day 1 — 딱 두 가지만.
README첫 세 줄: 이 팀이 뭘 운영하고, 장애 나면 누구한테 전화하는지.- 슬랙 채널 목록과 각 채널의 한 줄 용도.
이게 전부다. 첫날 목적은 “내가 어디 있는지” 한 문장으로 말할 수 있게 만드는 것이다.
Day 2~3 — 손을 움직이는 자료만.
- 로컬 개발환경 셋업 가이드. 단, 최근 6개월 안에 누군가 실제로 따라한 흔적이 있는 버전만. 낡은 가이드는 잠깐 숨겨둔다. 막히면 더 불안해진다.
- 첫 PR 템플릿. 내용은 중요하지 않다. 제출해봤다는 경험이 중요하다.
막상 해보면 셋업 가이드가 가장 자주 썩어 있다. macOS 버전 다르거나, brew formula 이름이 바뀌었거나. 그래서 나는 신규 입사자한테 가이드를 따라가면서 틀린 부분을 직접 PR로 고쳐달라고 한다. 첫 기여가 문서 수정이어도 충분하다. 코드베이스에 손댄 적 없어도, 고쳤다는 감각은 심어진다.
Day 4~5 — 시스템 지도 한 장.
아키텍처 전체 문서 말고, 딱 “이 팀이 건드리는 서비스들” 한 장짜리 다이어그램. 화살표 방향이 전부 맞을 필요도 없다. 어디서 트래픽이 들어오고 어디로 나가는지, 그 흐름이 머릿속에 들어오면 된다.
나머지 런북, 사고 대응 가이드, 모니터링 설명은 2주차 이후로 미룬다. 사고가 안 나면 런북은 읽혀도 안 박힌다.
다음 한 가지
셋업 가이드에 마지막으로 손댄 날짜를 적어둔다. 6개월 넘으면 다음 신규 입사자 오기 전에 한 번 직접 따라가본다.
🛒 이 글과 어울리는 추천 상품
위 링크는 쿠팡파트너스 활동의 일환이며, 일정액의 수수료를 제공받을 수 있습니다.