온보딩을 개선하겠다고 마음먹으면 가장 먼저 하게 되는 일이 설문입니다. 교육이 끝난 날 오후에 만족도 조사 링크를 보내고, 평균 4.2점이라는 결과를 받아 보고서에 적습니다. 나쁜 숫자는 아닙니다. 다만 그 숫자로는 다음 분기에 무엇을 바꿔야 하는지 알 수 없습니다.
온보딩은 교육 만족도의 문제가 아니라 적응 속도의 문제입니다. 신규 입사자가 언제부터 혼자 일할 수 있게 되는지, 어디에서 막히는지, 왜 3개월 안에 떠나는지를 봐야 합니다. 이 글에서는 90일 안에 실제로 수집할 수 있는 지표 네 가지와, 각 지표의 정의·계산식·수집 방법·함정을 정리합니다.
만족도 설문이 알려주지 않는 것
만족도 점수는 교육 경험의 품질을 어느 정도 보여줍니다. 강의가 지루했는지, 자료가 이해할 만했는지는 알 수 있습니다. 문제는 이 점수가 업무 성과와 거의 연결되지 않는다는 점입니다. 친절한 멘토와 잘 만든 슬라이드는 높은 점수를 받지만, 그것만으로 첫 배포를 혼자 해낼 수 있게 되지는 않습니다.
설문에는 구조적인 한계도 있습니다. 응답 시점이 교육 직후라 실무에서 무엇이 부족했는지는 아직 모릅니다. 신규 입사자는 평가하는 입장이 아니라 평가받는 입장이라 낮은 점수를 주기 어렵습니다. 표본도 작습니다. 분기에 다섯 명이 입사하는 조직에서 평균 4.2와 3.9의 차이는 해석할 수 없습니다.
그래서 설문은 버리지 않되 보조 지표로 내려두는 것이 맞습니다. 주 지표는 업무 쪽에서 가져와야 합니다.
측정할 수 있는 지표 네 가지
지표를 고를 때 기준은 하나입니다. 이미 어딘가에 기록이 남는 것을 쓰는 겁니다. 새로 수집 프로세스를 만들어야 하는 지표는 두 달이면 관리가 끊깁니다.
Time-to-Productivity: 자립까지 걸린 시간
팀이 정한 기준 업무를 신규 입사자가 감독 없이 완료하기까지 걸린 영업일 수입니다. 직무마다 기준 업무를 하나씩 정해두면 계산은 단순합니다. 개발자는 리뷰에서 큰 수정 없이 병합된 첫 커밋, 퍼블리셔는 혼자 마크업을 마친 첫 페이지, PMO는 본인이 작성해 그대로 보고된 첫 주간 리포트를 기준으로 삼을 수 있습니다. 계산식은 기준 업무 완료일에서 입사일을 뺀 값이고, 조직 지표로는 분기 입사자의 중위값을 봅니다.
수집은 이미 쓰는 도구에서 가져옵니다. Git 이력, 이슈 트래커, 업무 요청 시스템에 날짜가 남아 있습니다. 함정은 기준 업무의 난이도가 사람마다 달라진다는 점입니다. 누군가는 첫 주에 문구 수정 티켓을 받고, 누군가는 결제 모듈을 받습니다. 기준 업무를 난이도까지 포함해 미리 정의해두지 않으면 이 지표는 배정 운을 측정하게 됩니다. 평균 대신 중위값을 쓰는 이유도 같습니다.
첫 기여까지 걸린 시간
Time-to-Productivity가 자립까지의 시간이라면, 첫 기여는 그 앞 단계입니다. 크기와 무관하게 실제 산출물이 팀에 들어간 첫 시점을 봅니다. 오타 수정 하나, 회의록 정리, 테스트 케이스 한 건도 모두 포함됩니다. 계산식은 첫 산출물 반영일에서 입사일을 뺀 값입니다.
이 지표가 유용한 이유는 조직의 진입 마찰을 그대로 드러내기 때문입니다. 첫 기여가 9일차에 나온다면 보통 사람 문제가 아니라 계정 발급, 로컬 환경 구축, 접근 권한, 첫 과제 배정 중 어딘가가 막혀 있습니다. 함정은 이 숫자를 줄이려고 형식적인 과제를 만들어주는 것입니다. 의미 없는 첫 커밋은 지표만 좋아지고 적응에는 도움이 되지 않습니다.
30/60/90 체크포인트 달성률
입사 30일, 60일, 90일에 도달해야 하는 상태를 미리 문장으로 적어두고 해당 시점에 달성 여부를 확인합니다. 30일은 도구와 프로세스를 알고 도움을 요청할 사람을 아는 단계, 60일은 정형 업무를 혼자 처리하는 단계, 90일은 예외 상황에서 판단하고 필요한 사람을 찾아가는 단계 정도로 잡습니다. 계산식은 달성 항목 수를 전체 항목 수로 나눈 값입니다.
수집은 1대1 면담에서 매니저가 체크하면 됩니다. 함정은 항목을 행동이 아니라 감각으로 쓰는 것입니다. "팀 문화에 익숙해졌다"는 확인할 방법이 없습니다. "장애가 발생했을 때 에스컬레이션 순서를 설명할 수 있다"처럼 관찰 가능한 문장으로 써야 합니다. 항목은 직무별로 다섯 개 안쪽이어야 관리됩니다.
90일 조기 이탈률
입사 90일 안에 퇴사한 인원을 같은 기간 입사자 수로 나눈 값입니다. 온보딩 지표 중 가장 늦게 나오지만 가장 무겁습니다. 채용 비용과 팀의 시간이 함께 사라지기 때문입니다.
입사 규모가 작은 조직에서는 한 명이 떠나도 비율이 크게 튀므로 분기 대신 연 단위로 보고, 숫자보다 퇴사 면담의 사유 분류를 더 중요하게 다루는 편이 낫습니다. 함정은 이 지표를 온보딩 담당의 성과로만 귀속시키는 것입니다. 조기 이탈에는 채용 단계의 기대치 불일치, 매니저와의 관계, 처우 문제가 섞여 있습니다. 원인을 나눠 보지 않으면 엉뚱한 곳을 고치게 됩니다.
지표를 수집하는 현실적인 방법
네 지표를 한 번에 도입하려고 하면 대체로 실패합니다. 순서를 정하는 편이 낫습니다.
- 1분기: 입사일과 첫 기여일만 기록합니다. 스프레드시트 한 장으로 충분합니다.
- 2분기: 직무별 기준 업무를 정의하고 Time-to-Productivity를 재기 시작합니다.
- 3분기: 30/60/90 체크리스트를 직무별로 다섯 항목씩 만들어 1대1에 붙입니다.
- 4분기: 1년치 데이터로 조기 이탈률과 앞 지표들의 관계를 봅니다.
측정 자체가 일이 되지 않도록, 지표는 분기마다 한 번만 보고 그때 한 가지만 바꿉니다.
게임형 온보딩이 자동으로 남기는 데이터
시나리오 기반 온보딩을 쓰면 위 지표의 일부를 별도 수집 없이 얻을 수 있습니다. 플레이 자체가 기록이기 때문입니다.
First Run 같은 퀘스트 구조에서는 직무별 퀘스트 정답률, 같은 유형에서 반복되는 오답, 판단 문제에 걸린 시간, 재시도 횟수, 완료하지 못한 영역이 남습니다. 이 데이터는 성과 평가용이 아니라 교육 설계용입니다. 신규 입사자 여섯 명 중 다섯 명이 변경 요청 처리 퀘스트에서 같은 선택지를 골랐다면, 그건 개인의 실수가 아니라 그 절차가 문서에 불명확하게 적혀 있다는 신호입니다.
한 가지는 분명히 해둘 필요가 있습니다. 퀘스트 점수는 업무 성과의 대리 지표가 아닙니다. 게임 안에서 판단을 잘하는 것과 실제 프로젝트에서 판단을 잘하는 것은 상관이 있을 수는 있어도 같지 않습니다. 퀘스트 결과는 어디를 보완해야 하는지 알려주는 진단 도구로 쓰고, 자립 시점 판단은 실제 업무 지표로 하는 것이 맞습니다.
측정 체크리스트
- 직무별로 기준 업무를 하나씩 정의했는가
- 입사일, 첫 기여일, 기준 업무 완료일이 한곳에 기록되는가
- 30/60/90 항목이 관찰 가능한 행동으로 쓰여 있는가
- 지표를 평균 대신 중위값으로 보고 있는가
- 조기 이탈 사유를 채용·매니저·처우·온보딩으로 나눠 보는가
- 분기마다 개선 항목을 한 가지만 정해 실행하는가
- 만족도 설문을 주 지표가 아니라 보조 지표로 두고 있는가
온보딩 측정의 목적은 점수표를 만드는 것이 아닙니다. 사람들이 어디에서 막히는지 같은 자리에서 반복 확인하는 것입니다. 지표 네 개와 체크리스트 하나면 대부분의 조직은 다음에 무엇을 고쳐야 할지 알 수 있습니다.
---