팀 온보딩 문서 시스템 — 첫 한 달이 다음 한 해를 결정한다

문제

새 팀원이 들어올 때마다 나는 같은 설명을 처음부터 다시 했다. "우리 코드베이스 구조는...", "배포는 이렇게 하고...", "이 채널은 X 용도고...". 입사자가 바뀌어도 대사는 똑같았고, 전달하는 사람에 따라 빠지는 정보가 달랐다. 신규 팀원이 첫 달에 받는 정보가 누가 옆에 앉았느냐에 따라 무작위로 결정되고 있었다.

문제는 시간 손실에서 끝나지 않았다. 첫 한 달에 무엇을 모르냐가 그 사람의 다음 한 해 기여 곡선을 결정한다. 첫 달에 안 다듬어진 정보는 그 후로도 잘 안 다듬어지고, 잘못 박힌 모델은 6개월 뒤까지 영향을 남긴다. 온보딩은 "친절한 안내"가 아니라 팀이 새 멤버에게서 얼마나 빨리 가치를 회수하느냐의 문제였다 — 그래서 나는 이걸 일회성 안내가 아니라 운영하는 제품으로 다뤘다.

역할

• 문서 5단 구조 설계: Day-1 / Week-1 / Month-1 / Quarter-1 / 정기 갱신
• 각 단계의 정보 우선순위 정의: 무엇을 첫 날에 알아야 하고 무엇을 첫 주에, 첫 달에 알아야 하는지
• 문서 운영 매뉴얼: 신규 입사자가 들어올 때마다 무엇이 갱신되어야 하는지
• 분기마다 회고 후 문서 갱신

접근

버린 선택지

• 단일 거대 onboarding 문서: 100 페이지짜리 wiki는 신규 팀원이 읽다가 포기. 정보 우선순위가 안 보임.
• 사람 1:1 전달: 일관성 0. 전달자 부담 ↑.
• 외부 SaaS (Notion templates 등): 회사 specific 정보가 외부 SaaS에 묶이는 게 부담. 자체 wiki + git으로.

채택 — 시간 단위 5단 구조

각 단계는 그 시점에 알아야 할 최소 필수 정보만 담는다. 다음 단계에서 알면 되는 정보는 다음 단계로.

Day-1 (입사 첫 날)

목표: 첫 날 끝에 "내가 이 팀에 왔구나" 감각 + 다음 날 출근할 의지.

• 팀 멤버 사진 + 한 줄 자기 소개 (이름 + 역할)
• 1주차 일정표 (누구와 언제 만나고 무엇을 하는지)
• 기본 셋업 체크리스트 (이메일·Slack·git·VPN 5개)
• 점심·간식·휴게 정보 (소소한 정보)
• 인사할 채널 (welcome channel)

기술 깊이 0. 첫 날엔 사람과 환경.

Week-1 (첫 주)

목표: 코드를 처음 만지고 작은 PR을 머지.

• 코드베이스 high-level 구조 (디렉토리·핵심 모듈 5-10개만)
• 로컬 개발 환경 셋업 (Day-1에서 끝났어야 하지만 안 됐을 가능성)
• 첫 PR 후보 (well-defined 작은 작업 3-5개)
• 1on1 일정 (매니저·sibling·다른 팀)
• "우리 팀의 일하는 방식" — 미팅 빈도·async 규칙·코드 리뷰 SLO 등

Month-1 (첫 달)

목표: 작은 기능 1개를 처음부터 끝까지 (작성·리뷰·머지·배포·운영).

• 배포 프로세스 깊이 (CI/CD·롤백·monitoring)
• 운영 책임 (oncall·incident response)
• 비즈니스 컨텍스트 (우리 팀이 회사에서 무엇을 하는지)
• 도메인 깊이 (광고 산업·user funnel 등)
• 첫 회고 1on1 (한 달 동안 안 다듬어진 모델 잡기)

Quarter-1 (첫 분기)

목표: 팀의 정기 작업 흐름에 자연스럽게 참여.

• 분기 OKR / planning 흐름
• 다른 팀과의 인터페이스 (디자인·PM·데이터)
• 회사 wide 정보 (전사 미팅·culture)
• 시간에 따라 변하는 정보 (분기 우선순위·진행 중인 큰 작업)

정기 갱신

• 신규 입사자가 들어올 때마다 Day-1/Week-1 문서 한 번 훑고 outdated된 거 수정
• 분기마다 Month-1/Quarter-1 정보 갱신
• 분기마다 회고: "지난 신규 팀원이 무엇을 모르고 있었나" 검토

결과

새 멤버가 처음 코드에 손대고 처음 배포를 책임지기까지의 시간이 절반 가까이로 줄었다.

• 첫 PR까지 평균 5-7일 → 2-3일
• 첫 deploy 책임까지 3개월 → 1.5개월
• 신규 팀원당 온보딩 소요 시간 약 절반으로 단축 (사람 1:1 전달 → 문서 + 1:1 spot)
• 전달자에 따라 들쭉날쭉하던 정보가 누구에게나 같은 밀도로 도달

첫 PR과 첫 배포는 새 멤버가 팀에 실제로 기여를 시작하는 두 분기점이다. 이 두 곡선을 앞으로 당긴 것이 이 시스템의 핵심 성과다.

회고

잘된 점

• 시간 단위 5단 구조가 정보 우선순위를 자연스럽게 만들었다. "이건 첫 주에 알 필요 없네, Month-1로 보내자"의 분류가 가능.
• 정기 갱신 메커니즘이 핵심. 문서는 만들고 안 갱신하면 6개월 안에 outdated. 신규 입사자가 들어올 때마다 작은 갱신.
• Day-1을 기술 깊이 0으로 만든 게 큰 변화. 첫 날 기술 압박 없이 사람·환경에 적응할 자리.

다시 한다면

• 신규 팀원이 첫 주에 직접 onboarding 문서 수정: 본인이 헷갈렸던 부분을 직접 수정. 다음 신규 팀원에 도움 + 본인이 문서 운영에 참여한 신호. 이게 정기 갱신의 가장 자연스러운 형태.
• 첫 회고 1on1 더 빠르게: Month-1 끝이 아니라 Week-2에 첫 회고. 잘못 박힌 모델을 일찍 잡으려면 회고가 빨라야 한다.
• 버디 시스템 명시: 같은 팀의 senior 한 명을 buddy로 매칭. 매니저보다 자주 묻기 쉬운 자리.
• 마이크로 동영상: 일부 정보는 글보다 5분 동영상이 훨씬 빠름 (예: 배포 프로세스). loom 같은 도구로 짧게.

전이된 인사이트

이 5단 구조는 개인 학습에도 적용된다. 새 기술/도구를 배울 때:

• Day-1: 일단 hello world 돌리기
• Week-1: 작은 기능 1개 만들기
• Month-1: 작은 프로젝트 1개 끝내기
• Quarter-1: 깊은 부분 (성능·디버깅·아키텍처)

학습도 정보 우선순위가 시간에 따라 다르다. Quarter-1 깊이를 Day-1에 시도하면 매몰. 반대도.

핵심

온보딩을 매뉴얼이 아니라 운영하는 제품으로 보면, 신규 팀원의 첫 기여 시점을 지표로 당길 수 있다. 첫 PR 5-7일 → 2-3일, 첫 배포 3개월 → 1.5개월. 새 멤버가 가장 빨리 가치를 내도록 설계하는 사람.