직원 온보딩 챗봇

"법인카드 어디서 신청하나요?" 입사 첫 주 신입의 메신저에서 가장 자주 올라오는 한 줄입니다. 사수는 회의에 들어가 있고, 인사팀은 다른 응대에 묶여 있고, 사내 위키는 어디 있는지 아무도 알려 주지 않았습니다. 그렇게 신입의 30분이 조용히 사라집니다.

온보딩 챗봇이란 사내 위키·인사 정책·시스템 가이드·전임자 노하우를 한곳에 모아 두고, 신입이 한국어로 묻기만 하면 출처와 함께 답을 돌려주는 시스템을 말합니다. 입사 후 첫 30일 동안 반복되는 100여 개의 질문을 이 시스템이 대신 받아 냅니다.

이 글은 온보딩 챗봇이 입사 첫 달의 풍경을 어떻게 바꾸는지, 어떤 도구 조합으로 시작할 수 있는지, 도입 과정에서 무엇에 걸려 넘어지기 쉬운지를 도입 판단에 필요한 만큼 정리한 가이드입니다.

세 사람의 첫 달이 달라집니다

가장 먼저 달라지는 사람은 신입입니다. 질문 하나에 답을 받기까지 평균 25분을 기다리던 자리에 출처 링크가 붙은 즉시 답변이 들어옵니다. 첫 주 만족도 조사에서 "조직에 묻기 어렵다"고 답하는 비율을 절반 이하로 낮추는 것이 이 단계의 현실적인 목표입니다.

사수와 인사팀의 하루도 함께 가벼워집니다. 같은 질문을 한 달에 30번씩 받아 주던 사수 대신 신입이 챗봇으로 먼저 스스로 해결하고, 인사팀의 단순 문의 처리 시간은 주 15시간에서 주 3시간 수준까지 줄이는 것을 목표로 잡습니다. 그렇게 확보한 시간은 정책을 다듬는 일에 돌아갑니다.

눈에 덜 띄지만 오래가는 변화는 문서 쪽에서 일어납니다. 챗봇이 답하지 못한 질문이 카탈로그에 자동으로 쌓이고, 다음 주에 그 목록을 보며 위키를 보강하는 리듬이 생기면 문서는 낡지 않고 계속 살아 있게 됩니다.

질문 하나가 돌아오는 길

신입이 메신저에 한 줄을 던진 순간부터 따라가 보겠습니다. 챗봇은 질문의 의도를 읽어 사내 RAG를 검색하고, 신뢰도가 충분하면 출처를 붙여 바로 답합니다. 신뢰도가 낮으면 질문은 인사팀으로 넘어가고, 인사팀이 직접 답한 내용은 다시 위키로 돌아옵니다.

이 사이클에서 눈여겨볼 곳은 마지막 두 단계입니다. 답하지 못한 질문이 인사팀으로 이관되고 그 답이 위키와 카탈로그에 쌓이는 학습 루프가 있어야, 도입 3개월 무렵 80~90% 자가 응답률이라는 목표에 다가갈 수 있습니다.

신입의 질문은 의외로 좁습니다

입사 첫 달 신입이 던지는 질문을 모아 보면 범위가 생각보다 좁습니다. "법인카드는 어디서 신청하고 한도는 얼마인가요?", "연차는 입사 몇 개월부터 쓸 수 있나요?" 같은 제도 질문이 한 축이고, "VPN 접속이 안 되는데 누구한테 문의하나요?", "재택근무 신청서는 어디 있고 승인은 누가 하나요?" 같은 시스템·절차 질문이 다른 축입니다. 여기에 "이번 주 전사 회의 참석은 필수인가요?", "점심 식대 정산은 어디에 올리나요?" 같은 일상 질문까지 더하면 여섯 카테고리 안에 대부분이 들어옵니다.

이 여섯 카테고리에 직무별 시스템 가이드를 얹으면 커버리지가 한층 넓어집니다. 디자인팀이라면 Figma 라이브러리 위치, 개발팀이라면 Git 권한 신청 같은 문서를 함께 카탈로그에 넣어 두는 식입니다. 이렇게 시작하면 첫 달 자가 응답률을 끌어올리기가 한결 수월해집니다.

질문에도 다섯 가지 상태가 있습니다

챗봇이 받은 질문의 운명은 답한다와 답하지 못한다 둘로 갈리지 않습니다. 인입, 자동 분류, 자동 응답, 인사팀 검토, 학습 완료라는 다섯 상태를 거치고, 각 상태는 카탈로그 학습에 서로 다른 의미를 남깁니다.

특히 부정 피드백이 인사팀 검토와 위키 보강을 거쳐 다시 자동 응답으로 이어지는 경로가 학습 엔진의 심장입니다. 이 루프 없이 답변 생성만 잘하는 챗봇은 한 분기만 지나도 정확도가 흔들리기 쉬우니, 설계 단계에서 루프부터 그려 두는 편이 안전합니다.

위키가 어디 있느냐가 도구를 정합니다

도구 선택은 사내 위키가 어디에 있는가라는 한 가지 질문에서 갈립니다. 이 질문에 답하고 나면 권장 조합은 자연스럽게 좁혀집니다.

위키가 Notion에 잘 정돈되어 있다면 Sonnet과 Notion API를 잇는 옵션 A가 가장 빠른 길이고, 1주 안에 파일럿을 돌려볼 수 있습니다. Confluence를 쓰는 중대형 조직이라면 GPT와 Glean을 묶어 사내 검색 자체를 자산으로 만드는 옵션 B가 어울립니다. 문서가 슬랙·드라이브·메일에 흩어져 있다면 Haiku로 RAG 인덱싱을 직접 구축하는 옵션 C를 고려하되, 이때는 문서 정리부터 시작해야 합니다.

걸려 넘어지기 쉬운 네 지점

가장 흔한 실패는 위키가 없는데 챗봇부터 만드는 순서입니다. 챗봇은 답을 지어내는 도구가 아니라 찾아 주는 도구라서, 위키가 비어 있으면 LLM은 일반 상식으로 답하거나 환각을 일으킵니다. 도입 첫 2주를 핵심 카테고리 위키 정리에 쓰는 편이 돌아가는 듯해도 가장 빠릅니다.

권한은 초기에 정리해 두어야 합니다. 신입의 질문에 임원 연봉 정책이나 다른 부서의 인사 정보가 검색되어 나오면 그날로 사고가 됩니다. 문서별 접근 권한이 챗봇 답변 단계까지 그대로 이어지도록 RAG 인덱스를 권한별로 분리해 두는 것이 안전합니다.

"조직 분위기 어때요?" 같은 정답 없는 질문도 함정입니다. 의도 분류 단계에서 정책·시스템·도구 카테고리만 챗봇이 답하고, 문화·관계 영역은 사수나 인사팀으로 넘기는 가이드라인을 세워 두면 위험을 크게 줄일 수 있습니다.

마지막은 출처 표기입니다. "출처: 인사정책 v3.2 위키 7쪽" 형태의 링크가 답변마다 붙지 않으면 신뢰를 잃기 쉽습니다. 출처는 옵션이 아니라 기본 설정으로 두는 것이 좋습니다.

정착 여부는 숫자가 말해 줍니다

도입 6개월 시점에 다음 네 가지 지표를 보면 정착 여부를 가늠할 수 있습니다.

자가 응답률: 챗봇 단독으로 답한 질문의 비율이며, 80% 이상이면 정착 단계로 볼 수 있습니다.

핸드오프 평균 시간: 인사팀으로 넘어간 질문이 신입에게 답으로 돌아오기까지의 시간이며, 30분 미만을 목표로 합니다.

신입 첫 달 만족도: "질문이 막혔을 때 어떻게 했는지" 항목 기준으로 도입 전 대비 30% 상승을 목표로 잡습니다.

인사팀 단순 응대 시간: 주간 처리 시간 기준으로 도입 전 대비 70% 감소가 목표입니다.

도입 전 회의실에서 나오는 질문들

도입을 검토하는 자리에서 거의 항상 나오는 걱정이 몇 가지 있습니다. 신입이 들어올 때마다 새로 학습시켜야 하느냐가 첫 번째인데, 한 번 만들면 모든 신입이 같은 챗봇을 쓰고 직무·부서 정보는 메타데이터로 전달되어 답변이 자동으로 맞춤화되므로 그럴 필요가 없습니다.

잘못 답했을 때의 책임을 묻는 질문도 많습니다. 답변마다 출처와 함께 "이 답이 정확하지 않으면 인사팀에 직접 확인하세요" 안내를 붙이는 것이 표준이고, 정책 문서가 출처로 명시되어 있으면 문서 책임자가 곧 답변 책임자가 되는 구조입니다.

규모가 고민이라면 연간 입사자 30명이 하나의 기준선입니다. 그 이상이면 ROI가 비교적 빠르게 측정되고, 그 미만이라면 사수의 1:1 온보딩과 잘 정돈된 위키만으로 충분한 경우가 많습니다. 한국어와 영어를 함께 써야 하는 조직도 걱정할 일은 아닙니다. LLM 모델은 양쪽 언어를 동등하게 처리하므로, 위키 원본 언어와 답변 언어를 분리해 카탈로그에 넣으면 됩니다.

오늘 시작한다면

이 가이드에 담긴 내용만으로도 사내에서 직접 첫걸음을 뗄 수 있습니다. Notion 위키가 잘 갖춰진 조직이라면 옵션 A로 1~2주 파일럿을 가동하고, 첫 분기 자가 응답률을 측정해 보는 것이 좋은 출발점입니다.

위키 정리부터 챗봇 설계, 권한 분리까지 한 호흡에 짚고 싶다면 권앤컴퍼니의 사내 강의·파일럿 옵션을 함께 활용할 수 있습니다.

강의·파일럿 모두 30분 무료 상담으로 함께 검토할 수 있습니다: 상담 신청하기