채용 소요 기간

사람을 못 뽑아 계획이 밀리는 일은 흔한데 왜 밀렸는지는 잘 설명되지 않습니다. 채용은 여러 사람이 조금씩 붙어 있는 일이고 각자는 자기 몫을 늦추지 않았다고 생각합니다. 서류를 검토하는 사람은 사흘 늦었을 뿐이고, 면접관은 일정을 맞추느라 한 주 밀렸을 뿐입니다.

그렇게 작은 지연이 쌓이면 분기가 통째로 사라집니다. 페이지덱에서 태오가 개발자 한 명을 요청한 것이 4개월 전이었고, 규원이 왜 이렇게 걸렸는지 물었을 때 누구도 답하지 못했습니다. 기록을 되짚어 보니 서류 검토를 기다린 3주, 면접 일정을 맞추느라 보낸 2주, 오퍼 금액 승인을 기다린 2주가 있었습니다. 실제 면접에 쓴 시간은 넉 달 가운데 이틀이었습니다.

이 숫자가 필요한 이유가 여기 있습니다. 누가 게으른지 찾는 값이 아니라 아무도 일하지 않고 지나간 구간을 눈에 보이게 만드는 값입니다. 사람이 아니라 대기 시간을 셉니다.

끝점에서 시작점을 뺍니다. 다섯 단계로 적으면 이렇습니다.

1. 시작점과 끝점을 정하고 문서로 남깁니다. 시작점은 채용 공고를 올린 날 또는 채용 요청이 접수된 날이고, 끝점은 오퍼 수락일 또는 실제 출근일입니다. 어느 쪽이든 되지만 회사마다 달라서, 업계 수치와 견줄 때는 상대의 기준을 먼저 확인합니다. 요청 접수일부터 출근일까지로 잡은 값이 공고 게시일부터 수락일까지보다 6주쯤 길게 나옵니다.
2. 채용이 끝난 건만 셉니다. 중간에 취소되거나 자리가 없어진 건은 이 값에서 빼고 따로 셉니다. 섞으면 오래 끌다 접은 건이 기간을 늘려 놓습니다.
3. 평균이 아니라 중위값으로 냅니다. 28, 31, 35, 40, 120일짜리 다섯 건이면 평균은 51일이지만 중위값은 35일입니다. 한 건이 전체를 끌고 가지 않게 하려는 것이고, 120일짜리는 따로 떼어 왜 그랬는지 봅니다.
4. 단계별로 쪼갭니다. 이 값 하나만으로는 손댈 곳이 나오지 않습니다. 서류 검토까지 걸린 날, 1차 면접까지, 최종 면접까지, 오퍼까지, 출근까지를 각각 셉니다. 페이지덱의 지난 분기 개발자 채용은 12일, 9일, 14일, 11일, 30일이었습니다.
5. 직무와 레벨로 나눠 봅니다. 회사 전체를 한 숫자로 내면 채용 건수가 많은 직무의 값이 전체를 대표하게 됩니다.

4번에서 나온 숫자를 보면 무엇을 고칠지 갈립니다. 12일과 14일은 사람이 일하지 않고 대기한 구간이라 줄일 수 있고, 마지막 30일은 합격자가 다니던 회사에 통보하는 기간이라 대개 줄일 수 없습니다. 통제할 수 있는 칸과 없는 칸을 나눠 두지 않으면 목표를 세울 때 무리한 숫자가 나옵니다.

절대 기준은 없고 직무에 따라 두 배 이상 벌어집니다. 지원자가 많은 직무는 35주 안에 끝나고, 조건이 좁은 시니어 엔지니어는 812주가 예사입니다. 지원을 기다리지 않고 후보자를 직접 찾아가는 소싱에 의존하는 자리일수록 앞쪽 구간이 길어집니다.

짧은 것이 늘 좋은 것도 아닙니다. 기준을 낮추면 이 값은 즉시 줄어듭니다. 대신 합격한 사람이 제 몫을 하기까지 더 걸리고, 6개월 안에 나가는 사람이 늘어납니다. 그래서 이 숫자는 혼자 보지 않습니다. 제안한 오퍼 중 수락된 비율인 오퍼 수락률과 입사 6개월 유지율을 함께 놓고 봅니다. 기간이 줄었는데 수락률이 함께 떨어졌다면 급하게 아무에게나 오퍼를 낸 것입니다.

견줄 대상은 업계 평균보다 우리 회사의 지난 분기 값입니다. 회사 규모와 지역이 다 다르므로 남의 숫자는 참고가 되기 어렵습니다. 같은 직무를 지난 분기에 47일에 뽑았고 이번 분기에 61일이 걸렸다면 그 사이에 무엇이 바뀌었는지 물을 수 있습니다.

실제로 움직이는 손잡이는 단계별 대기 시간입니다. 서류 검토를 48시간 안에 끝내는 규칙, 면접관 일정을 주마다 두 칸 비워 두는 규칙, 오퍼 승인 권한을 채용 담당 관리자에게 내려 주는 결정이 각각 며칠씩 줄입니다. 면접 횟수를 줄이는 것도 기간을 줄이지만 판단의 근거가 함께 줄어드니, 단계 수를 건드리기 전에 대기 시간을 먼저 봅니다.

"채용 소요 기간이 61일인데 그중 26일이 대기예요. 면접 횟수는 그대로 두고 일정 잡는 방식을 고치죠."

단계 수가 아니라 대기 구간이 문제라는 지적입니다.

"이 숫자는 요청 접수일 기준입니다. 공고 게시일 기준으로 보면 6주 짧게 나옵니다."

기준이 다르면 비교가 성립하지 않는다는 뜻입니다.

"기간은 줄었는데 오퍼 수락률이 같이 떨어졌어요. 급하게 낸 오퍼가 늘었습니다."

속도만 보고 관리한 결과를 짚는 말입니다.

페이지덱은 태오의 4개월을 되짚은 뒤 규칙 셋을 만들었습니다. 서류 검토는 접수 후 48시간 안에, 면접관은 주마다 두 칸을 비워 두고, 오퍼 금액이 급여 밴드 안에 있으면 관리자 선에서 확정합니다.

다음 분기 개발자 채용의 중위값은 61일에서 43일이 됐습니다. 줄어든 18일은 전부 대기 구간에서 나왔고 면접 횟수와 합격 기준은 그대로였습니다. 같은 기간 오퍼 수락률은 62퍼센트에서 71퍼센트로 올랐는데, 후보자가 다른 회사의 제안을 기다리며 저울질할 시간이 줄어든 것이 이유로 보였습니다.

짧을수록 좋다고 읽는 경우가 가장 많습니다. 기간 지표는 대개 줄이는 것이 목표라 그렇게 보입니다. 하지만 이 값을 목표로 걸면 가장 빠른 방법은 기준을 낮추는 것입니다. 지원자가 세 명일 때 그중에서 고르면 6주가 3주가 되고, 반년 뒤 같은 자리를 다시 뽑게 됩니다. 이 오해를 그대로 두면 채용 속도는 개선된 표로 남고 팀은 계속 사람이 부족한 상태에 있습니다.

채용팀의 성과 지표라고 보는 것도 오해입니다. 채용 절차를 운영하는 쪽이 채용팀이니 자연스러운 배정입니다. 실제로 지연이 쌓이는 자리는 대부분 그 밖에 있습니다. 서류를 검토하는 사람, 면접에 들어가는 사람, 금액을 승인하는 사람이 각각 며칠씩 만듭니다. 이 값을 채용팀에만 걸어 두면 채용팀은 자기가 통제하지 못하는 숫자로 평가받고, 정작 며칠을 쥐고 있는 사람들에게는 아무 신호가 가지 않습니다. 단계별로 쪼개 그 칸을 맡은 사람에게 붙이는 편이 값을 합니다.