데모는 성공했다. 그리고 다음 날 무너졌다
사내 데이터에 ChatGPT를 연결하는 데모를 준비할 때는, 보통 미리 정해둔 몇 가지 질문으로 리허설을 합니다. “이번 달 매출이 얼마야?”, “제일 많이 팔린 상품은?” 같은 질문에는 잘 대답합니다. 경영진 앞에서 데모는 성공적으로 끝납니다.
그런데 다음 날, 실무자가 진짜 궁금한 걸 묻습니다. “이번 달 이탈한 고객 중에서, 지난 분기 매출 상위 20%에 들었던 고객이 누구야?” 이 질문 앞에서 시스템이 멈추거나, 그럴듯하지만 틀린 답을 내놓습니다. 데모용 질문과 실무자의 질문 사이에는 근본적인 차이가 있었던 겁니다.
왜 이런 차이가 생기는가
데모용 질문은 대개 테이블 하나만 보면 답이 나오는 단순 조회입니다. 반면 실무자의 질문은 “이탈 이력 테이블”과 “매출 테이블”을 연결하고, 그 위에 “상위 20%”라는 계산까지 얹어야 합니다. 여러 테이블을 엮고 계산까지 필요한 복합 질문 앞에서, 단순 검색 기반 접근은 한계를 드러냅니다.
RAG는 어디까지 잘 되는가
RAG(검색 증강 생성)는 사규나 매뉴얼처럼 문서에서 답을 직접 찾는 질문에는 효과적입니다. “연차 신청은 며칠 전에 해야 하나요”처럼 특정 문서 안에 답이 그대로 적혀 있는 질문이라면 RAG로 충분합니다.
정형 데이터(테이블) 앞에서 RAG가 흔들리는 이유
문제는 테이블 데이터입니다.
- 컬럼명이 축약되어 있다:
TB_CUSTOMER,CUST_ID같은 이름만 보고는 정확한 의미를 알기 어렵습니다. - 같은 개념이 시스템마다 다르게 불린다: 고객이 어떤 시스템에서는
CUSTOMER, 다른 시스템에서는CLIENT나LEAD로 불립니다. - 연결 키 형식이 시스템마다 다르다: 한쪽은 문자열, 다른 쪽은 숫자로 저장된 고객 ID를 그대로 조인하면 매칭이 안 됩니다.
- 질문마다 검색 경로가 달라진다: 같은 질문을 두 번 물어도 AI가 매번 다른 경로로 답을 찾다 보니, 결과가 일관되지 않습니다.
“더 큰 모델을 쓰면 되지 않나”라는 오해
이 문제를 GPT의 다음 버전, 혹은 파라미터가 더 큰 모델로 해결할 수 있을 거라고 기대하기 쉽습니다. 하지만 근본 원인은 모델의 추론 능력 부족이 아닙니다. 데이터의 의미 자체가 어디에도 정의되어 있지 않다는 게 원인입니다. 모델이 아무리 똑똑해져도, 정의되지 않은 정보를 정확하게 알아낼 수는 없습니다. 대신 “그럴듯한 추측”으로 빈틈을 채웁니다. 모델이 좋아질수록 이 추측이 더 자연스러워 보여서, 오히려 오류를 알아채기가 더 어려워집니다.
지금 쓰는 우회 전략의 한계
이 문제를 우회하려고 실무에서 흔히 하는 시도가 있습니다. 질문 유형별로 전용 쿼리를 미리 짜두거나, 서브 쿼리와 오케스트레이션 로직을 추가하는 방식입니다. 처음 몇 개 질문 유형까지는 그럭저럭 굴러갑니다. 그런데 질문 유형이 열 개, 스무 개로 늘어나면 관리해야 할 예외 로직도 기하급수적으로 늘어나고, 결국 아무도 전체 구조를 파악하지 못하는 상태에 이릅니다.
근본적인 해결책: 의미를 먼저 정의한다
우회하는 대신, 데이터의 의미 자체를 미리 정의해두는 방법이 있습니다.
- 기술적인 이름을 업무 용어로 바꿉니다 (
TB_CUSTOMER→ “고객”) - 테이블 간의 관계를 명시적으로 연결해둡니다 (고객 → 이탈 이력 → 매출)
- 이 구조를 온톨로지, 지식 그래프, 데이터 카탈로그 같은 형태로 관리합니다
이렇게 해두면 “이번 달 이탈 고객 중 지난 분기 매출 상위 20%”라는 질문도, AI가 매번 다른 경로를 추측하는 대신 이미 정의된 관계를 따라 정확하게 답할 수 있습니다. 그리고 이 구조는 조회에서 그치지 않고, “이탈 위험 고객에게 자동으로 리텐션 오퍼를 발송한다” 같은 실제 업무 처리로도 확장할 수 있습니다.
RAG를 버리라는 말이 아니다
여기서 오해하지 말아야 할 게 있습니다. RAG 자체가 잘못된 기술이라는 뜻이 아닙니다. 문서형 질의응답에는 지금도 RAG가 효율적입니다. 문제는 정확하고 반복 가능하며 실행까지 이어져야 하는 정형 데이터 영역에 RAG만으로 대응하려 할 때 생깁니다. 두 방식은 경쟁 관계가 아니라, 상황에 맞게 나눠 써야 하는 서로 다른 도구입니다.
정리하면
데모가 성공했다고 실전에서도 성공하는 건 아닙니다. 그 차이는 대개 “여러 테이블을 엮어야 하는 복합 질문”에서 드러납니다. 이 간극을 메우는 방법은 더 큰 모델이 아니라, 데이터의 의미를 미리 정리해두는 작업입니다.
자주 묻는 질문
Q. RAG와 온톨로지 중 어느 쪽을 먼저 도입해야 하나요? 사내 문서 검색처럼 RAG로 충분한 영역이 있다면 그것부터 빠르게 시작하고, 여러 테이블을 엮는 질문이 반복적으로 나온다면 그 영역부터 온톨로지로 정리하는 게 효율적입니다.
Q. 지금 우회 전략(질문 유형별 전용 쿼리)이 이미 많이 쌓여 있다면 어떻게 하나요? 가장 자주 쓰이는 질문 유형 몇 개부터 역으로 추적해서, 그 질문들에 공통으로 필요한 테이블과 관계를 온톨로지로 먼저 정리하는 걸 권합니다. 한 번에 전체를 갈아엎을 필요는 없습니다.