옮겼다고 생각했는데, 절반만 옮긴 상태였습니다.
옮겼는데 옮겨지지 않았다
서류 검토도, 평가도, 안내 발송도, 통계도 전부 우리가 만든 시스템으로 옮겼습니다. 담당자가 매일 여는 화면은 바뀌었고 손이 확실히 덜 갔습니다.
그런데 공개 채용 사이트는 그대로였습니다. 기존에 쓰던 외부 채용 솔루션이 제공하는 페이지에 공고를 올리고 있었고, 지원자가 "지원하기"를 누르는 곳도 거기였습니다.
그 말은, 이력서가 계속 그쪽으로 들어가고 있었다는 뜻입니다.
순서상 그렇게 될 수밖에 없었습니다. 당장 급한 건 담당자가 하루를 보내는 화면이었지 지원자가 3분 머무는 화면이 아니었습니다. 공개 사이트는 이미 돌아가고 있었으니 건드릴 이유도 없어 보였습니다. 그 판단이 틀렸다는 건 몇 주 뒤에 드러났습니다.
입구를 남이 쥐고 있으면 생기는 일
지원서가 들어오는 입구는 단순한 화면 하나가 아닙니다. 거기서 네 가지가 갈립니다.
- 원본이 어디에 쌓이나 — 이력서 파일 자체가 저쪽 저장소에 남습니다. 우리 쪽에는 옮겨온 사본만 있습니다
- 언제 들어오나 — 지원 즉시가 아니라 내보내기를 돌리는 시점에 들어옵니다. 그 사이의 지원자는 우리 화면에 없습니다
- 누구의 브랜드로 보이나 — 지원자가 마지막으로 본 화면이 우리 회사 페이지가 아닙니다
- 끊을 수 있나 — 계약을 끝내면 과거 지원자 데이터를 어떻게 할지부터 정해야 합니다
정리하면, 채용관리 도구만 바꾸는 것으로는 종속이 끊기지 않습니다. 도구는 바꿔도 데이터가 태어나는 자리는 그대로이기 때문입니다.
그래서 채용 사이트를 만드는 기능을 만들었다
회사가 자기 도메인으로 채용 사이트를 여는 기능을 제품에 넣었습니다. 별도 개발 없이 관리 화면에서 구성합니다.
- 공고 목록과 상세, 지원서 접수
- 회사 소개, 복리후생, 조직 문화, 채용 과정, FAQ
- 공개한 페이지에 맞춰 상단 메뉴가 자동으로 구성됨
- 문구는 백지에서 쓰지 않도록 AI 초안으로 시작
만들면서 회사 소개와 복리후생을 별도 페이지로 뺀 건 취향 문제가 아니었습니다. 공고 하나만 있는 사이트에서는 지원자가 "이 회사가 어떤 곳인지" 를 확인할 방법이 없고, 확인하지 못한 사람은 지원 버튼 앞에서 멈춥니다. 채용 사이트는 공고를 나열하는 곳이 아니라 지원을 결심하게 하는 곳입니다.
미게시 상태에서 미리보기가 되는 것도 필요했습니다. 담당자가 발행 전에 실제 화면을 봐야 문구를 고칠 수 있는데, 처음에는 미게시 공고를 열면 404가 났습니다.
우리 것부터 열었습니다
기능을 만들고 나서 가장 먼저 한 일은 우리 채용 사이트를 그 기능으로 만드는 것이었습니다. career.humuson.com이 그렇게 열렸습니다.
직접 쓰면서 나온 문제들은 기능 목록에 없던 것들이었습니다.
- 중복 지원이 안 걸렸습니다. 이메일만으로 판단하니 같은 사람이 다른 메일로 또 넣으면 통과했습니다. 전화번호를 축으로 추가하고, 동시에 제출되는 경우도 막았습니다
- 한글 파일명이 깨졌습니다. 지원자가 올린 "홍길동_이력서.pdf"가 알아볼 수 없는 이름으로 저장됐습니다
- 지원자 전원이 같은 요청 제한을 공유하고 있었습니다. 한 명이 여러 번 시도하면 다른 지원자까지 막혔습니다
- 공고 본문의 글머리표가 한 문단으로 뭉쳐 보였습니다. 담당자가 정리해 붙여넣은 항목이 그대로 이어 붙은 문장이 됐습니다
- 회사명 뒤 조사가 어색했습니다. "휴머스온와"처럼 표시되는 문구가 있었습니다
이런 것들은 남의 사이트를 쓸 때는 만날 일이 없고, 만나도 고칠 수 없습니다. 문의를 넣고 기다리는 것 말고는 할 수 있는 게 없습니다. 그리고 대부분은 아예 발견되지 않습니다 — 지원자는 한글 파일명이 깨진 걸 모르고, 우리도 저쪽 저장소를 들여다볼 수 없기 때문입니다.
옮기기 전에 확인해야 했던 것
기능을 만들었다고 곧바로 끊을 수 있는 건 아니었습니다. 채용 사이트를 바꾼다는 건 이미 나가 있는 링크와 진행 중인 채용을 건드리는 일입니다. 순서를 잘못 잡으면 지원 자체가 끊깁니다.
- 진행 중인 공고를 어떻게 할 것인가 — 마감이 남은 공고를 옮길지, 끝날 때까지 두 곳을 병행할지 먼저 정해야 합니다
- 이미 뿌려둔 링크가 어디를 가리키나 — 채용 채널, 사내 공유, 메일에 나간 URL은 회수되지 않습니다. 옮긴 뒤에도 한동안 살아 있어야 합니다
- 과거 지원자 데이터를 어디까지 가져올 수 있나 — 목록은 내보내지지만 이력서 원본까지 받을 수 있는지는 다른 문제입니다
- 지원자에게 나가는 안내가 끊기지 않나 — 접수 확인과 결과 통보가 새 경로에서 동일하게 나가는지 확인해야 합니다
지원자 데이터를 어디에 두느냐의 문제
이력서는 회사가 다루는 개인정보 중 민감한 축에 속합니다. 이름, 연락처, 학력, 경력, 때로는 사진까지 한 파일에 들어 있습니다.
입구가 밖에 있으면 원본도 밖에 있습니다. 지원자가 파기를 요청하면 두 곳을 모두 지워야 하고, 저쪽에서 실제로 지워졌는지는 확인할 방법이 마땅치 않습니다. 보관 기간을 정해도 우리가 통제하는 건 사본 쪽뿐입니다.
입구를 가져오면서 이 부분도 정리했습니다. 파일은 회사(워크스페이스) 단위로 나뉜 경로에 저장되고, 지원자를 삭제하면 이력서 파일도 함께 파기됩니다. 처음에는 지원자만 지우고 파일이 남는 문제가 있었는데, 직접 운영하다 발견해서 고쳤습니다.
그러고 나서야 끝났습니다
우리 도메인으로 지원서가 들어오고, 접수되는 즉시 채용 시스템에 쌓이기 시작했습니다. 내보내기 절차가 사라졌고, 원본 파일도 우리 저장소에 있습니다.
달라진 건 데이터 위치만이 아니었습니다. 지원자가 접수 확인 안내를 받는 시점, 그 안내에 적히는 문구, 서류 결과를 어떻게 알릴지가 전부 우리가 정할 수 있는 것이 됐습니다. 그전에는 남의 기본 문구였습니다.
기존 솔루션과 완전히 정리할 수 있었던 건 그 시점입니다. 채용관리 화면을 옮긴 날이 아니라, 지원서가 들어오는 입구를 옮긴 날이었습니다.
| 입구가 밖에 있을 때 | 입구를 가져온 뒤 | |
|---|---|---|
| 지원서 도착 시점 | 내보내기를 돌린 때 | 접수되는 즉시 |
| 이력서 원본 위치 | 외부 저장소 | 우리 저장소 |
| 지원자가 마지막에 본 화면 | 솔루션이 제공한 페이지 | 우리 도메인의 채용 사이트 |
| 접수 확인·결과 안내 문구 | 대체로 기본 문구 | 우리가 정함 |
| 문제를 발견했을 때 | 문의하고 기다림 | 그날 고침 |
| 계약을 끝낼 때 | 과거 데이터 처리부터 협의 | 해당 없음 |
도구를 고를 때 먼저 볼 것
이 경험에서 남은 기준이 하나 있습니다.
확인할 항목을 조금 더 풀면 이렇습니다. 데모를 볼 때 이 순서로 물어보면 대부분 갈립니다.
- 우리 도메인(또는 서브도메인)으로 열 수 있나, 아니면 제공사 주소 아래에 놓이나
- 지원서 폼의 항목을 우리가 바꿀 수 있나
- 중복 지원을 무엇으로 판단하나 — 이메일만인가, 전화번호도 보나
- 첨부 파일 원본이 어디에 저장되고, 우리가 직접 받을 수 있나
- 접수 확인과 결과 통보 문구를 우리가 쓰는가
- 발행 전 실제 화면을 미리 볼 수 있나
- 모바일에서 지원까지 끝나나 — 지원자 상당수가 휴대폰으로 들어옵니다
기능 목록에는 대개 "채용 페이지 제공"이라고 한 줄로 적혀 있지만, 위 일곱 개의 답은 제품마다 크게 다릅니다.
이 시리즈의 다음 글은 오늘 나온 이슈는 오늘 끝낸다입니다.