“RAG로 충분하지 않을까요, 굳이 온톨로지까지 필요한가요?”라는 질문을 자주 받습니다. 이 글은 그 질문에 정직하게 답하려는 글입니다. RAG를 깎아내리고 온톨로지를 파는 글이 아니라, 각각 어디까지 되고 어디서부터 안 되는지를 구분하는 글입니다.
RAG로 잘 되는 것
RAG(검색증강생성)는 문서 안에 답이 그대로 들어 있는 질문에 강합니다. 사규, 매뉴얼, 계약서, 회의록처럼 “찾아서 요약하면 되는” 성격의 질문이 대표적입니다. 구축 비용도 낮습니다. 문서를 벡터 데이터베이스에 넣고 검색 파이프라인만 붙이면 되기 때문에, 며칠 안에 데모를 돌릴 수 있습니다.
이런 특성 때문에 RAG는 사내 위키 검색, 고객 문의 응대 보조, 신입 온보딩 문서 검색 같은 영역에서 실제로 효과를 봅니다. “이 조항이 무슨 뜻이야”, “작년 회의에서 뭐라고 결정했지” 같은 질문에는 RAG만으로도 충분한 경우가 많습니다.
RAG로 잘 안 되는 것
문제는 질문이 “찾기”가 아니라 “연결하고 계산하기”로 넘어가는 순간입니다. “이번 분기 매출 상위 20% 고객 중 최근 3개월간 문의가 늘어난 고객은 누구인가”라는 질문을 생각해보면, 이건 문서 하나를 검색해서 답할 수 있는 질문이 아닙니다. 매출 테이블, 고객 테이블, 문의 이력 테이블을 정확한 규칙으로 조인하고 집계해야 답이 나옵니다.
RAG는 이런 질문에서 두 가지 문제를 반복적으로 드러냅니다.
- 의미 추측의 문제: 컬럼명과 값이 무엇을 뜻하는지 문맥으로 추측할 뿐, 정의된 사전이 없습니다.
- 관계 탐색의 문제: 테이블 간의 연결 경로를 매번 새로 찾다 보니, 같은 질문도 실행할 때마다 다른 경로로 답을 찾을 수 있습니다.
실행할 때마다 결과가 미묘하게 달라지는 현상은 데모 단계에서는 잘 드러나지 않다가, 실무자가 매일 쓰기 시작하는 순간 바로 발각됩니다.
둘을 가르는 기준 표
| 기준 | RAG | 온톨로지 기반 |
|---|---|---|
| 가장 잘 맞는 질문 | 문서 안에 답이 있는 질문 | 여러 테이블을 연결·계산해야 하는 질문 |
| 의미 정의 방식 | LLM이 문맥으로 추측 | 사전에 업무 용어로 정의 |
| 답의 일관성 | 실행 경로에 따라 달라질 수 있음 | 같은 관계 구조를 따르므로 상대적으로 안정적 |
| 실행 가능성 | 답만 제공, 실행은 별도 시스템 | 정의된 액션으로 실행까지 연결 가능 |
| 초기 구축 비용 | 낮음 | 높음(설계·유지보수 필요) |
| 적합한 조직 규모 | 단일 부서, 단순 문서 검색 | 여러 시스템을 지속적으로 다뤄야 하는 조직 |
온톨로지가 “필요해지는 지점”은 어디인가
정리하면 온톨로지가 필요해지는 지점은 대략 세 가지 신호로 알아챌 수 있습니다.
첫째, 같은 질문에 다른 답이 나오기 시작할 때입니다. RAG 기반 챗봇이 어제와 오늘 다른 근거로 답을 내놓는다면, 이는 관계를 매번 새로 탐색하고 있다는 신호입니다.
둘째, 질문 대응 쿼리가 계속 늘어날 때입니다. “이 질문 유형은 이 쿼리, 저 질문 유형은 저 쿼리” 식으로 예외를 계속 추가하고 있다면, 관계를 그때그때 하드코딩하고 있다는 뜻입니다. 관계를 온톨로지로 한 번 정의해두면 이 확장이 구조적으로 해결됩니다.
셋째, 답이 실행(승인, 처리)으로 이어져야 할 때입니다. “위험 고객을 찾아줘”에서 그치지 않고 “찾은 고객에게 자동으로 케어 액션을 걸어줘”까지 가야 한다면, 이건 검색이 아니라 액션의 영역이고 RAG만으로는 애초에 설계 범위 밖입니다.
반대로, 온톨로지가 과한 경우
온톨로지가 항상 정답은 아닙니다. 보고서 몇 개만 정기적으로 뽑으면 되는 단순한 상황, 단일 시스템 안에서 데이터가 이미 깔끔하게 정리되어 있는 상황이라면 온톨로지 설계·유지보수 비용이 얻는 이득보다 클 수 있습니다. 이런 경우는 RAG나 기존 BI 도구만으로 충분합니다. 이 판단을 명확히 하려는 것이 이 글의 목적입니다. 온톨로지는 “항상 더 나은 선택”이 아니라 “특정 지점을 넘어서면 필요해지는 선택”입니다.
더 읽어보기
이 판단 기준을 실제 실패 경험에 비추어 더 자세히 보고 싶다면 기업 AI가 챗봇에서 멈추는 이유를 참고하세요. 온톨로지가 실제로 어떤 형태로 구현되는지는 Foundry 전체 아키텍처 한 번에 잡기에서 다룹니다. 처음부터 “온톨로지가 뭔지”를 정리하고 싶다면 온톨로지란 무엇인가부터 읽어보시길 권합니다.