온보딩 첫 주, 읽을 것 줄이기
신규 입사자에게 던져주는 자료가 많을수록 아무것도 안 읽힌다.
막상 해보면
자료를 많이 줄수록 신뢰받는 팀처럼 느껴진다. 착각이다. 첫 주에 Confluence 링크 20개 받은 사람이 끝까지 읽은 비율, 솔직히 10%도 안 된다. 나머지는 탭만 열어두다 닫는다.
올해 팀에 세 명이 연달아 들어왔다. 한 명씩 후기를 들으니 공통 답변이 하나였다. “어디서부터 봐야 할지 몰랐어요.” 자료가 없어서가 아니라, 순서가 없어서.
실제로 줄인 것
첫 주 필독을 세 가지로 고정했다.
- 장애 대응 런북 1개 — 실제로 on-call 전에 반드시 봐야 하는 것만. 페이지가 5장을 넘으면 런북이 아니라 설계 문서다. 분리해라.
- “누가 받고 / 누가 백업” 한 장짜리 연락망 — 슬랙 채널 목록이나 org chart 가 아니다. 지금 당장 뭔가 터지면 누구한테 DM 보내는지 그것만.
- 배포 절차 체크리스트 — CI/CD 흐름 전체 아키텍처 문서 말고, 첫 배포 때 실제로 누르는 버튼 순서. 2026년 기준 우리 팀은 GitHub Actions + Slack 승인 두 단계. 이것만 적혀 있으면 된다.
나머지 — 시스템 설계 문서, 히스토리 ADR, 모니터링 대시보드 설명 — 는 2주차 이후로 밀었다. 첫 주에 읽히면 좋고, 안 읽혀도 업무가 막히지 않아야 한다.
보통은 “이것도 알아야 하는데” 하면서 계속 추가한다. 추가할 때마다 뺄 것을 같이 정하지 않으면 목록은 단방향으로만 늘어난다.
기준 하나
자료를 추가하기 전에 물어볼 것이 있다. “이걸 모르고 첫 주를 버틸 수 있나?” 버틸 수 있으면 2주차 이후다. 이 기준만 지켜도 목록이 절반 이하로 줄었다.
그리고 읽기 자료와 별개로, 첫날 30분짜리 구두 설명은 남긴다. 문서는 맥락을 잘라먹는다. “왜 이렇게 됐는지”는 말로 전달하는 게 빠르다.
다음 한 가지
다음 신규 입사자 온보딩 때, 자료 목록에서 한 개를 추가하면 한 개를 지우는 것을 실제로 했는지 여기에 한 줄 적기로.
🛒 이 글과 어울리는 추천 상품
위 링크는 쿠팡파트너스 활동의 일환이며, 일정액의 수수료를 제공받을 수 있습니다.