사내 위키 챗봇, 처음엔 며칠 만에 잘 돌아갔다
“사내 규정 찾기 귀찮으니까 챗봇 하나 만들자.” 이렇게 시작한 프로젝트는 보통 며칠 안에 데모가 나옵니다. RAG로 사내 위키 문서를 인덱싱하고, 질문을 던지면 관련 문서에서 답을 찾아주는 구조입니다. “연차는 며칠 전에 신청해야 하나요”, “출장비 정산 한도는?” 같은 질문에 정확하게 답합니다. 구축 비용도 낮고, 효과도 바로 눈에 보입니다.
RAG가 잘 하는 일
RAG는 문서 안에 답이 그대로 있는 질문에 강합니다.
- 사규, 매뉴얼, 계약서, 회의록처럼 텍스트 문서에서 답을 찾는 질문
- 구축 비용이 낮아서 며칠 안에 데모까지 가능
- 사내 위키 검색, 1차 고객 응대, 신입 교육 자료 안내 같은 곳에서 실제로 효과를 냅니다
그런데 질문이 점점 복잡해진다
챗봇이 잘 작동하는 걸 본 다른 팀들이 요청을 얹기 시작합니다. “이 고객의 계약 현황이랑 최근 문의 이력을 같이 보여줘.” “이번 분기 이탈 위험이 높은 고객을 뽑아줘.” 이런 질문은 문서 하나에 답이 있는 게 아니라, 여러 테이블의 데이터를 연결하고 계산까지 해야 나옵니다.
여기서 RAG의 한계가 드러납니다.
- 의미 정의 부재: 컬럼과 값이 정확히 무엇을 의미하는지 미리 정의되어 있지 않아, RAG가 추측에 의존합니다
- 관계 탐색이 불안정: 같은 질문이라도 매번 다른 경로로 데이터를 찾다 보니 결과가 흔들립니다
- 재현성 문제: 어제 물었을 때와 오늘 물었을 때 결과가 미묘하게 달라질 수 있습니다
RAG와 온톨로지, 나란히 놓고 보면
| 항목 | RAG | 온톨로지 |
|---|---|---|
| 적합한 질문 | 문서 검색형 | 여러 테이블 연결·계산이 필요한 질문 |
| 의미 정의 | AI가 추측 | 미리 정의됨 |
| 답의 일관성 | 매번 달라질 수 있음 | 상대적으로 안정적 |
| 실행 연결 | 지원 안 함 | Action으로 실제 업무 실행까지 연결 |
| 초기 구축 비용 | 낮음 | 상대적으로 높음 |
온톨로지가 필요해지는 3가지 신호
신호 1. 같은 질문에 다른 답이 나오기 시작한다. “이번 달 이탈 고객 수가 몇 명이야?”를 어제와 오늘 물었는데 답이 다르다면, 이건 데이터가 바뀐 게 아니라 AI가 매번 다른 방식으로 답을 찾고 있다는 신호입니다.
신호 2. 질문 유형별 예외 처리가 계속 늘어난다. 처음엔 질문 하나에 예외 처리 하나였는데, 몇 달 지나니 예외 처리가 수십 개로 불어나 아무도 전체를 관리하지 못하는 상태가 됩니다.
신호 3. 검색 결과를 실제 행동으로 옮겨야 한다. “이탈 위험 고객을 찾아서 자동으로 리텐션 오퍼를 발송해줘”처럼, 조회에서 끝나지 않고 실제 시스템에 반영해야 하는 요청이 들어오기 시작하면, RAG만으로는 구조적으로 불가능합니다.
이 세 가지 신호 중 하나라도 반복적으로 나타난다면, 사내 위키 챗봇 수준을 넘어 온톨로지 기반 구조로 넘어갈 시점입니다.
반대로, 온톨로지가 과한 경우
모든 상황에 온톨로지가 필요한 건 아닙니다.
- 정기적으로 필요한 보고서가 몇 개뿐이고 구조가 단순한 경우
- 데이터가 이미 단일 시스템 안에 깔끔하게 정리되어 있는 경우
- 지금 쓰는 RAG나 기존 BI 도구로 충분히 답이 나오는 경우
이런 상황에서 굳이 온톨로지를 도입하면, 얻는 것보다 구축·운영 비용이 더 클 수 있습니다.
정리하면
사내 위키 챗봇에서 시작해 온톨로지까지 가는 여정은 흔한 패턴입니다. 문제는 “RAG냐 온톨로지냐”를 처음부터 정하는 게 아니라, 지금 받고 있는 질문의 성격이 바뀌고 있는지를 계속 관찰하는 것입니다. 같은 질문에 다른 답이 나오거나, 예외 처리가 통제 불능으로 늘어나거나, 조회를 넘어 실행이 필요해지는 순간이 바로 그 신호입니다.
이 판단 기준을 실제 실패 경험에 비추어 더 자세히 보고 싶다면 기업 AI가 챗봇에서 멈추는 이유를 참고하세요. 온톨로지가 실제로 어떤 형태로 구현되는지는 Foundry 전체 아키텍처 한 번에 잡기에서 다룹니다.
자주 묻는 질문
Q. RAG로 만든 챗봇을 나중에 온톨로지 기반으로 완전히 바꿔야 하나요? 전면 교체가 아니라 공존이 일반적입니다. 문서 검색은 RAG로 그대로 두고, 여러 테이블을 엮어야 하는 질문 영역만 온톨로지 기반으로 확장하는 방식이 현실적입니다.
Q. 온톨로지 도입 여부를 어떻게 미리 가늠할 수 있나요? 최근 한 달간 챗봇이나 담당자가 받은 질문을 모아, “문서 하나로 답이 되는 질문”과 “여러 데이터를 엮어야 하는 질문”의 비율을 확인해보세요. 후자가 늘어나는 추세라면 온톨로지를 검토할 시점입니다.