채용 데이터를 묻는 AI를 만들기 전에, 답할 수 없는 것부터 셌습니다

HATS는 데이터가 없어서 못 쓰는 제품이 아니었습니다. 데이터가 화면마다 흩어져 있어서, 어디를 봐야 하는지 아는 사람만 쓸 수 있는 제품이었습니다.

이번 달 지원자 수는 통계 화면에, 이번 주 면접 일정은 일정 화면에, 공고별 검토 결과는 서류 평가 화면에 있습니다. 담당자 한 명이 공고 열 개를 돌리는 상황에서 "지금 뭐가 급한가"를 알려면 화면 네 개를 순회해야 합니다.

그래서 자연어로 묻는 창을 만들기로 했습니다. 그런데 착수하면서 가장 먼저 만든 것은 프롬프트도, 모델 비교표도 아니었습니다.

요구사항을 데이터 원천에 하나씩 대봤습니다

받고 싶은 질문 목록을 적고, 각 질문에 들어가는 지표가 어느 테이블에서 나오는지를 옆에 적었습니다. 나오지 않으면 그 자리에 「산출 불가」를 적었습니다.

이 표가 왜 먼저냐면, 없는 데이터를 물었을 때 AI가 가장 잘하는 일이 그럴듯한 숫자를 만들어 내는 것이기 때문입니다. 채용 소요일을 물었을 때 집계 결과의 0을 그대로 읽어 "채용 소요일 0일"이라고 답하면, 그건 빈 값이 아니라 거짓말입니다.

우리 화면들은 이미 이 규율을 지키고 있었습니다. 산출 불가 지표는 가짜 수치 대신 0이나 빈 표를 보여줍니다. 에이전트도 같은 규율을 따라야 했고, 그러려면 어느 것이 산출 불가인지를 코드가 알고 있어야 했습니다.

「지원율」은 세 가지로 읽혔습니다

"이번 주에 오픈한 공고의 지원율이 어느 정도야?" — 실제로 받고 싶었던 질문입니다. 그런데 정의를 적으려니 세 가지로 갈렸습니다.

• 공고 조회수 대비 지원 전환율
• 목표 채용 인원 대비 지원자 수
• 비슷한 과거 공고 대비 몇 배인가

셋 다 계산할 수 있지만 값이 전혀 다릅니다. 모호한 말을 그대로 받으면 AI는 셋 중 하나를 조용히 골라 단언합니다. 어느 것을 골랐는지는 답변에 안 나옵니다.

그래서 에이전트는 「지원율」이라는 말을 쓰지 않기로 했습니다. 목표 인원이 입력된 공고면 그 기준으로 답하고, 전환율을 낼 때는 조회수 집계가 언제부터 쌓였는지를 함께 말합니다. 용어를 쓰지 않는 것도 설계입니다.

안 하기로 한 것을 먼저 적었습니다

기능 목록보다 비목표를 먼저 확정했습니다.

• 자율 실행 안 함. 탈락 처리·메일 발송·일정 확정을 AI가 직접 하지 않습니다.
• 합격·불합격 추천 안 함. 채용 판단은 차별 리스크가 있는 영역입니다. 근거를 모아 주고 결정은 사람이 합니다.
• 새 지표 발명 안 함. 기존 집계를 그대로 부릅니다.

세 줄을 합치면 정의가 하나 나옵니다 — 이 기능은 분석가가 아니라 안내원입니다. 그리고 이 정의가 이후 아키텍처를 거의 다 결정했습니다.

점수를 절대값으로 말하지 않기로 한 이유

"적합도 82%" 같은 표현을 금지 목록에 넣었습니다. AI 서류 점수는 채점 기준을 조이거나 모델을 바꾸면 분포가 통째로 움직입니다. 실제로 모델을 교체하며 같은 이력서를 다시 채점해 본 적이 있는데, 평균이 3점가량 내려가고 여덟 건 중 한 건은 합불이 뒤바뀌었습니다.

같은 이력서인데 시기에 따라 82점도, 76점도 됩니다. 그래서 에이전트는 같은 공고 안에서의 상대 순위로만 말하고, 점수를 인용할 때는 그것이 AI 서류 점수라는 축을 반드시 붙입니다. 사람 평가와 인적성 점수는 별개의 축이라 임의로 합치지 않습니다.

기획에서 남은 한 문장

AI 기능 기획이라고 하면 어떤 모델을 쓸지부터 정할 것 같지만, 실제로 시간을 가장 많이 쓴 곳은 우리가 가진 데이터로 무엇을 말할 수 있는지 세는 일이었습니다.

그 목록이 곧 답변의 상한입니다. 그리고 목록 밖의 질문에 "그건 아직 수집하지 않습니다"라고 답하게 만드는 것이, 그럴듯한 숫자를 하나 더 만들어 내는 것보다 어렵고 중요했습니다.

이 시리즈는 세 편입니다. 다음 편은 이 기획을 어떤 구조로 구현했는지 — 특히 LLM에게 무엇을 주지 않았는지 — 를 다룹니다 (LLM에게 데이터베이스를 주지 않았습니다). 마지막 편은 화면 네 개를 돌던 질문이 한 줄이 됐습니다입니다.