채용과 AI에 대한 인사이트, 고객 활용 사례, 제품 뒷이야기를 담은 글을 소개합니다.
"지원자 개인정보를 국외로 이전하지 않는다"고 방침에 적어두고 코드를 열어보니, 이력서 한 페이지가 이미지로 해외 모델에 나가고 있었습니다. 문서가 아니라 코드가 틀린 상태였고, 그것을 코드로 강제된 사실로 바꾸면서 무엇을 잃었는지 적었습니다.
사내 테스트를 시작하면서 규칙을 하나 정했습니다. 그날 나온 문제는 그날 끝낸다는 것. 이 규칙 하나가 속도를 만든 방식과, 그 대가로 미뤄야 했던 것을 적었습니다.
채용관리를 전부 우리 시스템으로 옮겼는데도 지원서는 여전히 남의 시스템으로 들어오고 있었습니다. 지원서가 들어오는 입구를 가져오기 전까지는 이전이 끝난 게 아니었습니다.
도구 도입의 성과를 비용 절감으로 설명하면 결재는 나도 조직은 안 바뀝니다. 회수한 시간에 무엇이 들어오는지, 그리고 무엇을 할지 미리 정하지 않으면 왜 다른 행정업무가 그 자리를 채우는지 정리했습니다.
처음 만든 건 이력서를 읽는 기능 하나였습니다. 단순하게 만들려다 보니 발송·리포트·콘텐츠·문의까지 AI가 들어갔고, 그 과정에서 어디에 붙이고 어디에 붙이지 않을지 기준이 생겼습니다.
휴머스온이 자사 채용을 돌리려고 시작한 프로젝트가 제품이 됐습니다. 견적서 앞에서 멈춘 이유, 사내 도구가 제품이 되는 지점, 그리고 "한 사람이 시작한 도구를 믿어도 되나"에 대한 답입니다.
HATS는 humusOn ATS의 줄임말입니다. 그런데 이름을 정하고 나서 떠오른 분류모자 은유가, AI에게 무엇을 시키고 무엇을 시키지 않을지 정하는 기준이 됐습니다.
과거 지원자를 전부 옮기는 것으로 시작하면 대개 실패합니다. 이관하지 않을 것을 먼저 정하고, 마스터 데이터부터 세우고, 다음 공고 하나로 시작하는 8단계 순서와 각 단계에서 실제로 깨지는 지점을 정리했습니다.
지원자 관리 양식을 더 잘 만들어도 해결되지 않는 것들이 있습니다. 최신본 혼선, 통보 누락, 평가 근거 소실, 개인정보 노출, 파기 기한, 그리고 나중에는 복원할 수 없는 숫자까지 — 엑셀의 구조적 한계 7가지와 넘어갈 시점의 판단 기준을 정리했습니다.
