개발부서에서 메일이 왔다. 첨부파일 세 개. 업무절차서, 업무흐름도, 계약서_증빙기준서. 본문은 한 줄이었다. “HR 챗봇 골든 데이터 작성용 샘플입니다. 이 형식으로 부탁드립니다.” 파일을 열었다. OO사업 절차가 유입부터 사후관리까지 아홉 단계로 정리되어 있었다. 이걸 HR로 옮기라는 것이다. 어디서부터 어디까지, 어느 수준으로. 감이 오지 않았다. 영역별 담당자 회의는 다음 주였다.
이 글은 그 일주일 동안 정리한 것이다. 보상·복리후생·인력운영·승진·평가, HR의 모든 문의를 받아주는 페르소나형 HR 챗봇을 사내에 만들려는 사람이라면 같은 벽에 부딪힐 것이다. 문서 양식은 받았는데, 무엇을 얼마나 써야 하는지 아무도 알려주지 않는 벽.
개발팀이 원한 것은 문서가 아니었다
골든 데이터(Golden Data)라는 말부터 짚어야 한다. 개발부서가 보낸 문서 3종은 골든 데이터가 아니다. 골든 데이터를 담는 그릇이다.
골든 데이터의 실체는 세 가지가 묶인 세트다. 직원이 실제로 쓰는 말투의 질문, 지금 전화를 받으면 해 줄 정답, 그 답의 출처가 되는 근거. 문서 3종은 이 중 근거의 소스일 뿐이다. 그런데 문서만 잔뜩 쌓으면 어떻게 되는가. 검색은 된다. 답은 계속 틀린다.
왜 틀리는가. HR 규정집은 질문에 답하는 형태로 쓰여 있지 않기 때문이다. “제○조(경조휴가) 직원 본인 및 배우자의 직계존속 사망 시 경조휴가 5일을 부여한다.” 이 문장을 챗봇에 넣으면, “장인어른 상인데 배우자 기준 증명서를 내야 하나요?”라는 질문에 답하지 못한다. 규정은 되는 것을 적어 놓은 책이다. 직원이 전화로 묻는 것은 대부분 안 되는 경우와 애매한 경우다.
그래서 규정집을 통째로 넣는 것은 출발점이 아니라 실패의 원인이다. 이 사실을 담당자 회의 첫 슬라이드에 올려야 한다. 그러지 않으면 담당자들은 규정집 요약본을 써 온다.
그렇다면 개발부서 샘플은 왜 OO사업 절차서였을까. 그 안에 답이 있었다.
OO사업 챗봇 문서를 뜯어보니 3계층이었다
샘플로 받은 OO사업 절차 문서를 며칠 들여다봤다. 처음엔 세 문서가 병렬로 나열된 산출물로 보였다. 아니었다. 서로를 호출하고 참조하는 구조였다.
| 계층 | 문서 | 역할 | 챗봇에서의 기능 |
|---|---|---|---|
| Layer 1 | 업무흐름도 | 전체 여정의 지도. 단계 구분과 이동 규칙 | 대화가 지금 어느 지점인지 판단 |
| Layer 2 | 업무절차서 | 각 단계의 실행 매뉴얼 | 실제 응대 스크립트 |
| Layer 3 | 판단·증빙기준서 | 판단 근거가 되는 지식 | 답변의 근거, 인용 출처 |
흐름도의 각 단계에는 「호출 절차서」라는 칸이 있다. 절차서의 각 세부 절차에는 「참조 문서」라는 칸이 있다. 흐름도가 절차서를 부르고, 절차서가 기준서를 부른다. 이 링크 덕분에 같은 내용을 세 군데 중복 기술하지 않아도 된다.
두 번째 발견은 파일명이었다. (공통)OO_판단기준서, (공통)자격(재직)_증빙기준서. 여러 상품이 공유하는 지식을 별도 문서로 뽑아놓은 것이다. HR로 옮기면 (공통)가족관계_판단기준서, (공통)재직기간_산정기준서가 된다. 이걸 먼저 만들지 않으면 경조·학자금·육아휴직 문서에 가족 범위 정의가 세 번 들어가고, 개정할 때 반드시 하나는 빠진다.
세 번째가 가장 값졌다. 단계마다 「예시질문」 여섯 개가 붙어 있었다. “이미 OO상품이 있는데 추가로 받을 수 있나요?” 같은 고객 말투 그대로. 절차서는 담당자 관점으로 쓰이지만 챗봇은 고객 관점으로 답해야 한다. 그 간극을 메우는 다리가 이 칸이다.
여기까지가 배울 것이다. 그런데 이 구조를 HR에 그대로 옮기면 실패한다.
HR 제도는 세 종류다 — 여기서 작업량이 절반으로 준다
현업의 예시는 고객 유입에서 사후관리까지 파이프라인 하나다. 모든 문의가 그 축 위에 놓인다. HR은 다르다. 수십 개의 독립 제도가 있고, 상당수는 애초에 단계라는 것이 없다. “성과급은 어떻게 산정되나요”에 무슨 단계가 있는가. 없다. 기준만 있다.
그래서 제도를 먼저 분류해야 한다. 이 분류가 곧 “어느 수준까지 써야 하는가”에 대한 답이다.
| 유형 | 판별 질문 | 해당 제도 | 작성할 문서 |
|---|---|---|---|
| P형 (프로세스형) | 신청하고 승인 단계를 거치는가 | 육아휴직, 학자금, 경조, 승진 심사 | 흐름도 + 절차서 + 기준서 풀세트 |
| R형 (기준형) | 단계 없이 기준과 금액만 있는가 | 보상 체계, 복지포인트, 평가 등급 정의 | 기준서 + Q&A만 |
| V형 (VOC형) | 정답보다 응대 순서가 필요한가 | 평가 결과 불만, 배치 불만, 제도 개선 의견 | 응대 시나리오 카드 + 에스컬레이션 규칙 |
R형에는 흐름도와 절차서를 만들지 않는다. 없는 단계를 억지로 만들면 챗봇이 존재하지 않는 절차를 안내한다. 이 결정 하나로 문서 작업량이 절반 가까이 줄었다. 체감으로 HR 문의의 절반가량이 R형인데, 문서 작성 부담은 P형이 압도적으로 크기 때문이다.
V형은 아예 다른 문서다. 정답을 적는 것이 아니라 어디서 멈추고 사람에게 넘길지를 적는다. “평가가 납득이 안 됩니다”에 챗봇이 규정을 들이대면 불만이 커진다. 공감, 사실 확인, 절차 안내, 티켓 생성, 회신 약속. 이 순서와 “절대 하지 않을 것”이 문서의 전부다.
분류를 마치고 나서야 담당자들에게 뭐라고 요청할지 정해졌다. 문제는 그다음이었다. P형 문서를 어느 깊이로 쓸 것인가.
어느 수준까지 쓰나 — 입사 3개월차 테스트
담당자에게 제시할 기준은 하나면 된다. 이 문서만 읽고, 오늘 발령받은 신입 담당자가 그 전화를 혼자 받을 수 있는가.
대조 예시를 함께 보여주면 회의가 빨라진다. 아래는 규정 원문이다.
제○조(경조휴가) 직원 본인 및 배우자의 직계존속 사망 시
경조휴가 5일을 부여하고 경조금을 지급한다.같은 항목을 골든 데이터 수준으로 쓰면 이렇게 된다.
[항목] 직계존속 사망 경조휴가
· 인정 범위: 본인 및 배우자의 부모, 조부모
- 인정: 계부모(부양 사실 확인 시), 양부모
- 불인정: 배우자의 외조부모 → 별도 일수 적용
· 일수 계산: 휴일 포함 연속 사용, 분할 불가
- 예외: 장례 절차상 1일 분할 승인 사례 있음
· 증빙: 배우자 측 상은 배우자 기준 가족관계증명서 필요
· 자주 틀리는 지점: 증빙 미제출 시 무급 전환 (문의 1위)
· 근거: 취업규칙 제○조 / 시행 2024.01.01 / 담당 HR운영팀차이는 세 가지다. 예외, 불인정 사례, 자주 틀리는 지점. 이것이 유선 문의의 실체이고, 규정집에는 절대 적혀 있지 않은 부분이다.
왜 하필 불인정인가. 인정 조건만 잘 쓰면 되지 않는가.
안 된다. 챗봇이 문서를 읽는 방식 때문이다. 챗봇은 질문을 이해하고, 관련 문서 조각을 검색하고, 그 조각을 근거로 답을 만든다. 조각에 “되는 것”만 적혀 있으면 안 되는 경우에도 된다고 답한다. 조각에 예외가 없으면 예외 없이 답한다. 담당자들은 습관적으로 무엇이 되는지만 쓴다. 그래서 시간이 없으면 불인정 사례 세 건부터 쓰라고 못 박았다.
그 예외는 어디서 오는가 — 전화 한 통이 네 문서가 된다
여기서 담당자들이 반드시 묻는다. “예외랑 불인정 사례를 어디서 찾아 쓰나요?” 규정집에는 없다. 담당자 머릿속에 있다. 정확히는, 지난 6개월간 받은 전화 속에 있다.
그래서 문서 작성 전에 요청한 것이 하나 있다. 최근 6개월간 가장 많이 받은 문의 30건과, 그때 실제로 한 답변을 그대로 적어 달라는 것. 이걸 문의로그라 부르는데, 처음엔 담당자들이 이 로그가 3종 문서 중 어디에 들어가는지 헷갈려 했다. 답은 “어디에도 통째로 들어가지 않는다”이다. 쪼개져서 세 문서 전부에 들어간다.
문의로그 한 줄은 세 조각으로 되어 있다. 직원이 말한 그대로의 질문, 그때 실제로 한 답변, 그리고 답하기 곤란했던 이유. 조각마다 가는 곳이 다르다.
| 문의로그의 조각 | 들어가는 문서 | 들어가는 칸 |
|---|---|---|
| 질문 원문 | 업무흐름도 | 예시질문 |
| 답변 중 “되는 경우” | 판단기준서 | 인정 기준 |
| 답변 중 “안 되는 경우” | 판단기준서 | 불인정 기준 |
| 답하기 곤란했던 이유 | 판단기준서 | 주의 사항 (자주 틀리는 지점) |
| “이럴 땐 어떻게”류 답변 | 업무절차서 | 예외 / 보완 시 조치 |
| 서류 반려 관련 답변 | 증빙기준서 | 서류별 주의 사항 |
한 건을 골라 끝까지 따라가 보면 이렇다. “장인어른 상인데 가족관계증명서를 냈더니 반려됐어요. 왜죠?” 답변은 배우자 기준 증명서가 필요하다는 것. 경조 문의에서 흔한 유형이다. 이 한 줄이 네 군데로 흩어진다. 질문은 경조 흐름도의 예시질문으로. 답변은 증빙기준서의 주의사항으로. “배우자의 직계존속은 본인 기준 증명서로 확인 불가”라는 판단은 (공통)가족관계_판단기준서로. 배우자 기준 증명서를 재요청하는 절차는 증빙확인 절차서의 예외 조치로.
전화 한 통이 네 문서에 흔적을 남긴다. 30건이면 120개 항목의 씨앗이 된다. 그래서 30건이면 충분하다고 한 것이고, 그래서 작성 순서를 문의로그 → Q&A → 기준서 → 절차서 → 흐름도로 잡은 것이다. 원재료 없이 문서부터 쓰면 규정집 요약본이 나온다.
하나 더. 문의로그의 (질문, 답변) 쌍은 세 문서의 원재료이면서 그 자체로도 산출물이다. 정제되면 챗봇이 정답으로 삼는 Golden Q&A가 되고, 그중 일부는 나중에 챗봇의 정확도를 재는 시험 문제가 된다. 문서 3종은 그 정답의 근거를 대는 관계다.
문서 수준은 이렇게 정해졌다. 그런데 회의 준비를 하면서 깨달았다. 문서보다 먼저 결정해야 할 것들이 있었다.
문서를 쓰기 전에 정해야 하는 세 가지
하나는 답변의 경계다. 개인 평가등급, 개인 연봉, 타인의 처우, 승진 심사 내부 기준. 챗봇이 절대 답하면 안 되는 목록을 문서 작성 전에 확정해야 한다. 이걸 뒤로 미루면 담당자들이 “어차피 다 답해야 하니까”라며 개인 처우 정보까지 문서에 적어 온다. 그 문서는 폐기해야 하고 작업이 되돌아간다. 금칙 위반의 허용치는 0건이다. 정확도가 목표에 못 미쳐도 오픈할 수 있지만, 개인 등급이 한 번 노출되면 프로젝트 전체의 신뢰가 무너진다.
다음은 담당자 간 답변 불일치다. 이걸 어떻게 처리할 것인가. 문의로그를 모으면 같은 질문에 담당자 A와 B가 다르게 안내해 온 사례가 반드시 나온다. 이건 결함이 아니라 이 프로젝트의 가장 큰 부산물이다. 다만 “누가 맞았나”로 흐르면 담당자들이 문서 작성을 꺼린다. 불일치 항목을 따로 모아 격주로 정답 확정 회의를 열고, 과거 안내의 옳고 그름은 따지지 않는다는 원칙을 먼저 세웠다.
[경험담 필요: 첫 정답 확정 회의에서 실제로 드러난 불일치 사례 1건 — 제도명과 쟁점만, 담당자는 익명]
마지막은 관행이다. 규정에 없는 관행을 문서에 적을 것인가. “규정엔 없지만 늘 이렇게 해 왔어요”가 많이 나온다. 문서에 적는 순간 그것은 사실상 규정이 된다. 챗봇이 전사에 안내하기 때문이다. 규정에 반영할지, 재량으로 남겨 문서에서 뺄지, 아예 없앨지. 담당자 혼자 판단할 일이 아니라 영역 오너가 결정할 일이다.
이 세 가지를 회의 전에 정리하지 않았다면, 8주 뒤에 완성도 30%짜리 문서 다섯 묶음이 남았을 것이다.
파일럿은 반드시 한 영역만
보상·복리후생·인력운영·승진·평가를 동시에 열면 실패한다. 담당자들은 본업이 따로 있고 8주짜리 문서 작업은 반드시 후순위로 밀린다. 설득으로는 안 된다.
복리후생 하나로 시작한다. 규칙이 명확하고, 문의량이 가장 많고, 개인 처우 리스크가 가장 낮다. Q&A 30~50건이면 된다. 그리고 3주 안에 시연을 한다. 자기가 쓴 문서로 챗봇이 답하는 것을 본 담당자는 태도가 바뀐다. 완성도가 아니라 동작하는 것을 보여주는 것이 목적이다.
평가와 승진은 맨 마지막이다. 금칙과 VOC 비중이 가장 높아서 설계 난이도가 다르다.
이 글의 핵심 세 가지
- 골든 데이터는 문서가 아니라 (질문, 정답, 근거) 세트다. 규정집을 넣으면 검색은 되고 답은 틀린다.
- HR 제도를 P형·R형·V형으로 먼저 나눈다. R형에 흐름도를 그리지 않는 것만으로 작업량이 절반으로 준다.
- 인정 조건보다 불인정 사례가 먼저다. 챗봇은 문서에 없는 “안 됨”을 스스로 만들지 못한다.
회의를 준비하면서 가장 오래 걸린 것은 문서 양식이 아니었다. 우리가 지금까지 전화로 뭐라고 답해 왔는지를 글로 옮기는 일이었다. 규정집은 회사가 아는 것을 적은 책이다. 챗봇에 필요한 것은 담당자가 아는 것을 적은 책이다. 그 둘은 생각보다 멀리 떨어져 있었다.
챗봇은 우리가 아는 것을 배우지 않는다. 우리가 적은 것만 배운다.
[함께 읽으면 좋은 글]