원격 팀 신규 입사자를 위한 첫 주 온보딩 체크리스트, 하루 단위 정리
원격 근무 첫 주를 위한 신규 입사자 온보딩 체크리스트. 입사 전 준비부터 계정, 정책, 버디, 첫 티켓, 금요일 점검까지 하루 단위로 정리했습니다.
목차
원격으로 입사한 사람의 첫 주 온보딩 체크리스트는 다섯 부분으로 이루어집니다. 입사일 전에 계정과 장비를 준비해 두는 것, 첫날 통화를 그 사람의 첫 작은 작업으로 마무리하는 것, 매니저가 아닌 버디를 붙이는 것, 읽고 동의해야 하는 정책을 월요일에 한꺼번에 주지 않고 한 주에 나눠 주는 것, 그리고 금요일에 30분 동안 무엇이 헷갈렸는지 묻는 점검입니다. 아래 내용은 모두 한 페이지에 들어가며, 매니저가 한 주 동안 쓰는 시간은 모두 합쳐 세 시간 정도입니다.
저희는 15명이 안 되는 원격 회사이고, 이것은 새로 사람이 들어올 때마다 쓰는 목록입니다. 이 목록이 생긴 이유는, 처음 온보딩이 Slack 환영 메시지와 핸드북 링크 하나가 전부였고, 그렇게 맞이한 두 번째 입사자가 저장소 접근 권한을 나흘 동안 조용히 기다렸기 때문입니다.
첫 주가 생각보다 많은 것을 결정하는 이유
Gallup의 온보딩 연구에 따르면, 자기 회사가 신규 입사자 온보딩을 매우 잘한다고 강하게 동의하는 직원은 12%에 불과하고, 매니저가 적극적으로 관여할 때 신규 입사자가 온보딩을 탁월했다고 평가할 가능성은 3.4배 높아집니다. 이 수치는 Gallup이 State of the American Workplace 데이터를 바탕으로 2019년에 발표한 온보딩 관련 보고서에서 나온 것이며, 이후 저희가 본 어떤 자료도 작은 회사가 큰 회사보다 더 잘한다는 근거가 되지 않았습니다.
5~15명 규모 회사에서 느린 첫 주의 비용은 아주 구체적입니다. 그 사람을 뽑은 이유는 팀에 일손이 부족해서인데, 접근 권한을 기다리는 하루하루는 팀이 여전히 일손이 부족한 채로 월급까지 나가는 날입니다. 그리고 첫 주에 생긴 습관, 즉 공개적으로 질문하는지 조용히 기다리는지, 작은 것을 배포하는지 회의에만 앉아 있는지는 오래 갑니다.
입사 전에
이 목록의 항목은 입사일 전날 업무 종료 전까지 모두 마칩니다. 따로 표시가 없으면 담당자는 매니저입니다.
- 서명된 오퍼 레터와 각종 계약서를 보관하고, 입사일을 서면으로 확정한다.
- 장비가 입사 2영업일 전에 도착하도록 발송하고, 운송장 번호를 본인에게 보낸다.
- 계정 생성: 이메일, 채팅, 워크스페이스, 코드 호스팅, 비밀번호 관리자. 회사 이메일이 열리기 전에 로그인해야 하는 것은 개인 이메일로 초대를 보낸다.
- 버디를 정하고 미리 알려 둔다. 매니저가 아니라, 비슷한 직급에 최근 2년 안에 입사한 사람으로.
- 첫 티켓 선정: 첫 주에 배포할 수 있는 실제 업무로, 작고 범위가 분명한 것. 문서 수정, 화면 하나짜리 버그, 문구 변경 같은 것. 바로 시작할 수 있을 만큼 맥락을 적어 둔다.
- 첫날 일정 발송: 업무 시작 시 환영 통화, 점심 이후 버디 통화, 그 외에는 없음.
- 짧은 "누가 누구인지" 페이지: 팀원 한 명당 한 줄, 무엇을 물어보면 되는지.
- 동의받을 정책을 준비하되, 첫날 필요한 것(보안, 허용 사용 정책)과 나중에 해도 되는 것(경비, 휴가)을 나눠 둔다.
한 주의 흐름, 하루 단위
각 날짜에 할 일과 담당자를 적었습니다. "완료 기준"은 그날 마지막에 확인하는 내용입니다.
1일 차: 도착하고, 만나고, 아직 아무것도 배포하지 않기
- 매니저와 환영 통화, 45분: 회사가 하는 일, 이번 달 팀이 하는 일, 첫 주의 흐름, 질문할 곳. (매니저)
- 목록의 모든 계정에 로그인하고, 안 되는 것은 DM이 아니라 팀 공개 채널에 알린다. (신규 입사자)
- 첫날 정책에 동의: 보안, 허용 사용 정책, 기밀 유지. (신규 입사자)
- 버디 통화, 30분: 팀이 실제로 일하는 방식, 문서에 없는 규칙, 조심해야 할 부분. (버디)
- "누가 누구인지" 페이지와 현재 사이클의 목표를 읽는다. (신규 입사자)
완료 기준: 모든 계정이 작동하고, 정책 두 개에 동의했으며, 본인이 팀 채널에 무언가를 썼다.
2일 차: 코드베이스, 제품, 첫 티켓
- 한 시간 동안 사용자 입장에서 제품을 써 보고 헷갈리는 점을 모두 적는다. (신규 입사자)
- 개발 환경 구동, 또는 비개발 직군이라면 그에 해당하는 준비. 두 시간 넘게 걸리면 버디와 함께 한다. (신규 입사자, 버디)
- 첫 티켓을 읽고 매니저에게 질문한다. (신규 입사자)
- 팀 회의 하나에 참석한다. 카메라는 켜고, 발언 의무는 없다. (신규 입사자)
완료 기준: 환경이 빌드되고, 티켓을 이해했고, 헷갈리는 점 목록이 있다.
3일 차: 일하기
- 첫 티켓 작업. 끝나지 않았더라도 그날 안에 리뷰를 요청한다. (신규 입사자)
- 첫 리뷰는 요청 후 두 시간 안에, 친절하고 구체적으로. (버디 또는 매니저)
- 두 번째 정책 묶음에 동의: 경비, 휴가, 장비. 휴가 잔여일이 제대로 표시되는지 확인한다. (신규 입사자)
- 프로필, 비상 연락처, 급여용 계좌 정보를 입력한다. (신규 입사자)
완료 기준: 리뷰가 이뤄졌고, 인사 기록이 채워졌다.
4일 차: 배포하고, 회사의 다른 사람들 만나기
- 리뷰 의견을 반영하고 첫 티켓을 배포한다. (신규 입사자)
- 직속 팀 밖의 세 사람과 15분씩 통화한다. 상대는 "누가 누구인지" 페이지에서 고른다. (신규 입사자)
- 지난달 회사 업데이트나 지표 페이지를 읽는다. (신규 입사자)
완료 기준: 본인이 만든 무언가가 프로덕션에 있거나 게시되었다.
5일 차: 점검
- 매니저와 금요일 점검, 30분, 질문 네 가지: 무엇이 헷갈렸는지, 무엇이 예상보다 오래 걸렸는지, 필요한데 없는 것은 무엇인지, 이 체크리스트에서 무엇을 바꿔야 하는지. (매니저)
- 헷갈리는 점 목록을 온보딩 페이지에 수정 제안으로 남긴다. (신규 입사자)
- 첫 달 목표를 함께 정한다: 결과 두세 개를 글로 적는다. (매니저, 신규 입사자)
- 버디와의 관계는 첫 달 동안 매주, 이후에는 필요할 때 이어 간다. (버디)
완료 기준: 점검 메모가 있고, 첫 달 목표가 적혀 있으며, 체크리스트에 신규 입사자가 남긴 수정이 하나 이상 있다.
담당자와 시점 한눈에 보기
| 항목 | 담당 | 시점 | 완료 기준 |
|---|---|---|---|
| 계정과 장비 | 매니저 | 입사 전날 | 첫날 모든 로그인이 작동 |
| 버디 지정 | 매니저 | 입사 일주일 전 | 첫날 일정에 버디 통화가 있음 |
| 첫 티켓 | 매니저 | 입사 일주일 전 | 작성 완료, 일주일 안에 배포 가능 |
| 첫날 정책 | 신규 입사자 | 1일 차 | People 기록에서 동의 완료 |
| 개발 환경 | 신규 입사자, 버디 | 2일 차 | 로컬에서 빌드됨 |
| 첫 리뷰 | 버디 또는 매니저 | 3일 차 | 요청 후 두 시간 안에 리뷰 |
| 첫 배포 | 신규 입사자 | 4일 차 | 프로덕션 반영 또는 게시 |
| 인사 정보 | 신규 입사자 | 3일 차 | 프로필, 비상 연락처, 계좌 정보 완료 |
| 금요일 점검 | 매니저 | 5일 차 | 메모 작성, 체크리스트 수정 |
| 첫 달 목표 | 매니저와 신규 입사자 | 5일 차 | 결과 두세 개를 문서화 |
첫 주에서 30일, 60일, 90일로
첫 주의 핵심은 접근 권한, 한 번의 배포, 그리고 버디입니다. 이후 석 달의 핵심은 담당 범위입니다.
- 30일 차까지: 작은 영역 하나를 맡고, 여러 번 배포했으며, 두 번째 점검을 마쳤다. 5일 차에 정한 첫 달 목표를 다시 보는데, 대부분은 진전이 있을 것이다.
- 60일 차까지: 무언가를 처음부터 끝까지 맡아 해냈다. 기능 하나, 고객 통화, 채용 과정 같은 것. 리뷰를 받기만 한 것이 아니라 직접 리뷰도 했다.
- 90일 차까지: 팀에 온콜이나 지원 당번이 있다면 거기에 들어가 있고, 팀의 일하는 방식에 대해 변경을 하나 제안했으며, 매니저는 이 채용이 잘 되고 있는지에 대한 짧은 메모를 써서 본인과 공유했다. 수습 기간이 있다면 이때 확정한다.
30/60/90일 목표는 첫 주 체크리스트와 같은 페이지에 두어, 누구도 두 번째 문서를 찾지 않아도 되게 하세요.
체크리스트를 어디에 둘 것인가
매니저 머릿속에만 있는 체크리스트가 저희의 나흘짜리 저장소 대기를 만들었습니다. 신규 입사자가 볼 수 있는 페이지여야 하고, 각 담당자가 체크하는 칸이 있어야 합니다.
Atrix에서는 온보딩 체크리스트 템플릿을 입사자마다 복제해서 쓰는 페이지로 제공하고, 셀프서비스 항목도 같은 곳에 있습니다. 본인이 People에서 정책에 동의하고, 휴가 잔여일을 확인하고, 경비를 제출하고, 계약서에 서명하며, 이런 셀프서비스 부분은 iPhone 앱에서도 할 수 있습니다(Android는 테스트 중). 채용 파이프라인에서 지원자를 채용하면 체크리스트가 연결되는 고용 기록이 만들어집니다. 그 기록에 무엇이 담기는지는 People 기능 페이지에 정리되어 있습니다. 한계도 있습니다. Atrix는 다른 도구의 계정을 대신 만들어 주지 않고, 장비도 보내지 않습니다. 그런 칸은 여전히 사람이 체크합니다. 신규 입사자가 3일 차에 동의할 휴가 규칙은 휴가 정책 템플릿에서 시작할 수 있습니다.
자주 묻는 질문
신규 입사자 온보딩 체크리스트에는 무엇이 들어가야 하나요?
입사 전: 계정, 장비, 버디, 첫 티켓, 첫날 일정. 첫 주 동안: 환영 통화, 며칠에 나눈 정책 동의, 개발 환경, 첫 리뷰와 첫 배포, 인사 정보, 다른 팀과의 통화 세 번, 그리고 첫 달 목표를 정하는 금요일 점검입니다.
온보딩은 얼마나 걸려야 하나요?
첫 주에는 일을 시작할 수 있게 하고, 처음 90일 동안 본래 맡을 범위까지 넓힙니다. 첫 주 금요일에 끝나는 체크리스트는 첫 단계일 뿐 전부가 아닙니다. 30일, 60일, 90일에 점검하세요.
작은 회사에서는 누가 온보딩을 맡아야 하나요?
체크리스트와 점검은 매니저가 맡습니다. 매니저가 아닌 버디는 일상적인 질문을 맡습니다. 신규 입사자는 목록에서 자신의 진행을 스스로 챙깁니다. 그래서 본인이 목록을 볼 수 있어야 합니다.
신규 입사자가 첫날 모든 정책에 동의해야 하나요?
아니요. 보안, 허용 사용 정책, 기밀 유지는 그 사람이 접근할 수 있는 범위에 영향을 주므로 첫날에. 경비, 휴가, 장비는 맥락이 생긴 3일 차에. 월요일 아침에 정책 열 개를 주면 아무도 읽지 않습니다.
신규 입사자의 첫 티켓으로는 무엇이 좋은가요?
실제 업무이면서 작고 범위가 분명한 것. 문서 수정, 화면 하나짜리 버그, 문구 변경, 아무도 쓸 시간이 없었던 보고서 같은 것입니다. 리뷰 한 번으로 첫 주에 배포할 수 있어야 하고, 조금은 의미가 있어야 배포가 시험이 아니라 일처럼 느껴집니다.
Atrix는 온보딩을 자동화하나요?
일부만 합니다. 체크리스트 템플릿, 정책 동의, 휴가 잔여일, 경비, 전자 서명된 계약서를 본인 기록에 모아 주고, 파이프라인에서 채용한 지원자를 팀원으로 전환하는 단계도 제공합니다. 다른 도구의 계정 생성이나 장비 발송은 하지 않으므로, 그 항목은 사람이 할 일로 체크리스트에 남습니다.
다음 단계
다음 채용을 위해 온보딩 체크리스트 템플릿을 복제하고, "입사 전에" 섹션을 일주일 전에 채워 두세요. 아직 오퍼를 쓰고 있다면 스타트업용 오퍼 레터 템플릿이 그 단계를 다루고, 입사 후 그 사람의 기록에 무엇이 담기는지는 People 기능 페이지에서 볼 수 있습니다.
출처
Gallup, "Why the Onboarding Experience Is Key for Retention", Gallup, "Creating an Exceptional Onboarding Journey for New Employees" (2019년 보고서). 12%와 3.4배 수치의 출처입니다.