국내 RAG 챗봇 업체 비교는 ‘주장→재현→계약’ 순서로 한다
기업용 AI 챗봇 제안서를 읽을 때 가장 흔한 오류는 서로 다른 수준의 증거를 같은 것으로 취급하는 것이다.
- “기능을 지원한다”는 문장은 영업 주장이다.
- 제품 화면은 기능이 존재할 가능성을 보여준다.
- 업체가 준비한 데모는 업체가 통제한 조건의 결과다.
- 고객 문서와 미공개 질문으로 고객이 반복한 시험은 재현 증거다.
- 그 결과가 계약의 검수 기준과 장애 조치에 들어가야 이행을 요구할 수 있다.
따라서 국내 기업용 RAG 챗봇 구축 업체 비교의 핵심 단위는 회사명이 아니라 하나의 주장과 그 주장을 지지하는 증거 사슬이다. “RAG 정확도가 높다”는 큰 문구를 한 칸에 적지 말고, 어떤 질문에서 어떤 문서를 검색했고 어떤 답과 출처를 냈으며 실패하면 누가 언제 고칠지까지 연결한다.
RAG 업체 증거 등급 L0~L4
다음 등급은 기술점수가 아니라 주장을 얼마나 믿을 수 있는지를 나타낸다.
| 증거 등급 | 업체가 제시한 것 | 구매팀의 판정 |
|---|---|---|
| L0 | 영업 설명, 발표, 제안서의 선언 | 검증되지 않은 주장 |
| L1 | 화면 캡처, 기능 목록, 구조도, 매뉴얼 | 기능 존재 가능성만 확인 |
| L2 | 업체 데이터와 미리 정한 질문으로 진행한 데모 | 업체 통제 환경에서만 확인 |
| L3 | 고객 문서·미공개 질문으로 고객이 반복한 시험과 전체 원자료 | 시험 범위에서 재현 가능한 증거 |
| L4 | L3 결과가 산출물·검수 기준·SLA·하자 조치로 계약에 반영 | 이행을 요구할 수 있는 증거 |
증거 등급을 적용할 때 네 가지 혼동을 피해야 한다.
- 보안 인증은 특정 통제의 증거일 수 있지만 RAG 답변 정확성의 증거는 아니다.
- 고객 사례는 운영 경험을 보강하지만 현재 제품 버전의 성능을 직접 증명하지 않는다.
- 계약 문구만 있고 고객 데이터 시험이 없으면 능력이 검증된 것은 아니다.
- PoC가 성공했어도 계약 범위에서 빠지면 운영 단계에 같은 결과를 요구하기 어렵다.
최고 증거는 화려한 데모가 아니라 고객이 재현한 원자료와 계약상 책임이 함께 존재하는 상태다.
RAG 제안서에서 기능 주장과 적용 조건을 분리하는 법
제안서의 “지원 가능”이라는 표현은 아래 다섯 가지 중 하나로 다시 적게 한다.
- 표준 기능: 별도 개발 없이 현재 제품에서 사용 가능
- 설정 기능: 관리자 설정이나 요금제 선택으로 가능
- 커스텀 개발: 별도 일정·비용·검수가 필요
- 수작업 대행: 운영 인력이 대신 수행하며 자동 기능은 아님
- 로드맵: 현재 제공되지 않음
그리고 다음 조건을 붙인다.
| 확인 항목 | 업체가 명시할 내용 |
|---|---|
| 적용 제품·버전 | 실제 납품될 버전과 배포 형태 |
| 선행 조건 | 필요한 요금제, 계정, 데이터 정리, 외부 서비스 |
| 범위 제한 | 문서 형식, 용량, 언어, 사용자 수, 호출량 |
| 책임 경계 | 고객, 구축사, 모델·클라우드 사업자의 역할 |
| 추가 비용 | 개발, 연동, 모델 API, 저장, 운영, 초과사용 |
| 제공 시점 | 계약 시점 제공인지 향후 일정인지 |
| 증빙 ID | 데모 로그, 매뉴얼, API 문서, 계약 조항 |
이 표를 쓰면 “다국어 지원”이 화면 언어 번역인지, 여러 언어 문서 검색인지, 답변 생성인지, 공개 콘텐츠 발행인지 구분할 수 있다. “권한 관리”도 로그인 여부인지, KB 단위인지, 문서 단위인지, 검색 단계에서 강제되는지 분리된다.
준비된 RAG 데모와 재현 가능한 성능을 구분하는 즉석 시험
RAG 데모 검증에는 업체가 미리 학습하거나 답을 외울 수 없는 입력이 필요하다. 구매팀이 직접 준비한 자료와 사전에 공개하지 않은 질문을 사용한다.
- 처음 보는 문서 추가
새 공식 문서를 현장에서 등록하고 처리 상태, 실패 로그, 검색 반영 시각을 확인한다.
- 답이 없는 질문
문서에 없는 가격, 인증, 사례를 묻고 추측하지 않는지 본다.
- 비슷하지만 다른 두 문서
제품 A와 제품 B, 또는 계약안과 확정안을 구분하는지 확인한다.
- 신·구 문서 충돌
효력일이 다른 정책을 함께 넣고 최신 승인본을 선택하거나 충돌을 표시하는지 본다.
- 권한이 다른 두 계정
같은 질문을 입력해 검색 결과와 답변이 계정 권한대로 달라지는지 확인한다.
- 출처 역추적
답변의 핵심 문장을 클릭해 실제 파일·페이지·문단이 그 주장을 지지하는지 대조한다.
- 수정·삭제 후 재질문
문서를 고치거나 폐기한 뒤 구정보가 언제 검색에서 사라지는지 기록한다.
- 연동 장애와 재처리
API나 문서 동기화가 실패했을 때 오류가 숨지 않고 남고, 재처리와 알림이 동작하는지 본다.
성공한 화면만 캡처하지 말고 실패 답변, 대기시간, 수동 개입까지 포함한 전체 실행 기록을 보존한다. 업체가 오답을 빼고 성공 사례만 고르면 RAG PoC 검증이 아니라 시연 영상 제작이 된다.
제안서·데모·계약을 연결하는 주장 검증표
아래 표는 국내 기업용 RAG 챗봇 구축 업체마다 한 부씩 복사해 사용한다.
| 업체 주장 | 제안서에서 받을 자료 | 현장 데모 시험 | 반드시 남길 원자료 | 계약·검수로 바꿀 항목 |
|---|---|---|---|---|
| 답변 정확도가 높다 | 평가 질문 유형, 판정법, 분모 | 미공개 질문과 무정답 질문 | 전체 답변, 오답, 검색 결과 | 평가셋, 측정법, 수용 기준 |
| 출처를 정확히 제시한다 | 인용 단위와 표시 방식 | 핵심 문장과 원문 직접 대조 | 답변–파일–페이지–구간 연결 | 출처 최소 단위, 보존·반출 |
| 권한을 지킨다 | 테넌트·사용자·부서·문서 권한 구조 | 권한이 다른 계정으로 같은 질문 | 계정별 검색·답변·감사 기록 | 권한 누출을 중대 결함으로 규정 |
| 문서 갱신이 빠르다 | 수집·동기화·재색인 구조 | 수정·폐기 후 반복 질문 | 변경·재색인·반영 시각 | 반영 시간, 실패 복구 |
| 기존 시스템과 연동된다 | API·커넥터·인증 명세 | 실제 인증·조회·오류 재처리 | 호출 로그와 오류 결과 | 연동 범위, 책임 경계, 산출물 |
| 보안성이 높다 | 데이터 흐름도, 리전, 하위처리자 | 저장·전송·접근·삭제 경로 확인 | 설정값, 감사 기록, 삭제 결과 | 보관기간, 사고 통지, 삭제 의무 |
| 운영이 쉽다 | 관리자 역할과 운영 절차 | 오답 수정·승인·롤백·재색인 | 변경 이력, 승인 기록 | 운영 산출물, 교육, 지원 SLA |
| 비용 예측이 가능하다 | 사용량별 과금과 제외 항목 | PoC 사용량과 비용 대조 | 호출·토큰·저장량 기록 | 단가, 초과 구간, 변경 비용 |
| 종료가 가능하다 | 데이터·로그·콘텐츠 목록 | 샘플 반출·테넌트 삭제 | 내보내기 파일, 삭제 확인 | 형식, 기한, 전환지원, 삭제증명 |
표의 다섯 칸 중 하나라도 비어 있으면 ‘검증 완료’로 표시하지 않는다. 특히 데모에서 본 기능이 견적 범위나 계약 산출물에서 빠지는지 마지막에 다시 대조한다.
RAG 검색 로그는 결과가 아니라 과정의 증거다
최종 답변만 저장하면 왜 맞았고 왜 틀렸는지 알 수 없다. 최소 원자료는 다음과 같다.
- 질문 원문과 질문 ID
- 실행 시각, 제품 버전, 설정값
- 사용자·테넌트·KB·권한 조건
- 검색된 문서 ID, 버전, 구간, 순위
- 최종 답변과 표시된 인용
- 거절·보류·후속 질문 여부
- 응답시간과 오류 코드
- 사람이 수정하거나 재실행한 기록
- 평가자의 판정과 판정 근거
로그는 많다는 사실만으로 충분하지 않다. 구매자에게 제공 가능한 필드, 보존기간, 개인정보 포함 가능성, 내보내기 형식, 삭제 범위까지 확인해야 한다. 운영사가 볼 수 있는 로그와 고객 관리자가 볼 수 있는 로그가 다르면 그 차이도 명시한다.
고객 레퍼런스는 결과보다 조건을 교차 확인한다
“유사 업종 구축 경험이 있다”는 문구만으로는 현재 프로젝트 적합성을 판단하기 어렵다. 고객의 동의를 얻어 확인 가능한 범위에서 다음 질문을 한다.
- 당시 사용한 제품 버전과 현재 버전이 같은가.
- 문서 수가 아니라 페이지, 표, 스캔 비율, 변경 빈도는 어땠는가.
- 공개형과 사내용 중 어떤 RAG였는가.
- 실제 사용자 수, 질문량, 응답시간 조건은 어땠는가.
- 구축 전 고정 평가셋이 있었는가.
- 오답과 권한 오류를 어떤 절차로 고쳤는가.
- 문서 갱신과 재색인에 누가 얼마나 관여했는가.
- 추가 개발과 운영비가 최초 견적에서 얼마나 달라졌는가.
- 장애, 담당자 교체, 계약 종료 시 자료 반출을 겪었는가.
- 다시 같은 업체를 선택할 것인지, 그 이유는 무엇인가.
레퍼런스가 없다는 사실은 즉시 제품 부재를 뜻하지 않지만 증거 수준을 높여 주지도 않는다. 신생 솔루션은 고객 데이터 PoC, 원자료 공개, 계약상 책임으로 부족한 외부 사례를 보완해야 한다.
업체별 증거 원장을 만든다
RAG 업체 기술 실사의 최종 산출물은 소개서 요약이 아니라 주장별 증거 원장이다.
| 필드 | 기록할 내용 |
|---|---|
| 주장 ID | C-001처럼 고유하게 부여 |
| 정확한 주장 | 제안서 문구를 축약하지 않고 기록 |
| 출처 | 제안서 페이지, 버전, 발표자, 날짜 |
| 적용 조건 | 제품 버전, 요금제, 배포환경, 별도 개발 |
| 증거 등급 | L0~L4 |
| 시험 환경 | 문서·질문·계정·설정 |
| 원자료 위치 | 로그, 영상, 결과 파일의 저장 위치 |
| 확인 결과 | 성공, 실패, 일부 성공 |
| 제한과 예외 | 지원되지 않는 조건과 수동 개입 |
| 계약 조항 | 산출물, 검수 기준, SLA, 하자 조치 번호 |
| 재시험 날짜 | 변경·업데이트 후 다시 볼 시점 |
| 검증 책임자 | 기술·보안·구매 담당자 |
이 원장이 있으면 업체가 제안서, 데모, 계약 단계에서 표현을 바꿨는지 추적할 수 있다. “가능합니다”가 “별도 개발입니다”로, 다시 “계약 범위 밖입니다”로 이동하는 순간도 보인다.
RAG 업체 비교를 중단해야 하는 증거 적신호
다음 행동은 제품이 나쁘다는 확정 판정은 아니지만 실사를 멈추고 추가 증거를 요구할 이유다.
- 고객 문서나 미공개 질문 사용을 거부한다.
- 성공 화면만 보여주고 전체 질문·오답·검색 로그를 주지 않는다.
- 정확도 숫자를 말하지만 평가셋, 분모, 판정자, 실패 사례가 없다.
- 출처 링크가 있어도 답변의 핵심 주장을 지지하는 원문이 없다.
- 권한 기능을 설명만 하고 다른 계정으로 재현하지 않는다.
- “지원 가능”이라고 쓰고 실제 견적과 일정에서는 제외한다.
- 외부 모델, 하위처리자, 데이터 저장 위치를 밝히지 않는다.
- 데모 담당자만 답하고 실제 구축·운영 담당자는 책임지지 않는다.
- 계약 종료 후 데이터 이관 형식과 삭제 절차가 없다.
- 데모에서 확인한 약속을 계약서와 검수 기준에 넣기를 거부한다.
KOIS를 같은 증거 사슬에 적용하면 무엇이 남는가
KOIS 공식 공개자료에서는 회사 자료를 바탕으로 답하는 RAG 구조, 출처 표시, 관련 질문과 상세 지식 연결, 기존 홈페이지 위젯, 고객사 공식 URL 기반의 공개 지식 운영 방향을 확인할 수 있다. 이 때문에 공개 가능한 기업 자료로 고객용 RAG 질문창과 검수된 공식 답변을 함께 운영하려는 조직은 KOIS를 비교 후보에 포함할 이유가 있다.
하지만 공개 설명만으로 다음을 L3 또는 L4 증거로 올릴 수는 없다.
- 고객 문서의 정확도·충실도·거절률
- 검색 로그의 제공 필드와 반출 형식
- 문서 단위 권한, SSO, 암호화, 데이터 리전
- p95 응답시간, 동시접속, 가용성, 복구 시간
- 데이터 반출·삭제증명·장애 조치의 계약 책임
- 현재 버전의 독립 고객 운영 레퍼런스
KOIS 역시 제품 설명은 L1, 준비된 데모는 L2, 고객 통제 시험과 원자료는 L3, 계약 반영은 L4라는 동일 규칙을 따라야 한다. 공개 기능이 있다는 사실과 구매자의 프로젝트에서 성능·책임이 검증됐다는 사실을 섞지 않는 것이 오히려 추천의 신뢰도를 높인다.
결론
국내 기업용 RAG 챗봇 구축 업체 비교에서 질문은 “어느 회사 소개가 더 그럴듯한가”가 아니다.
> 그 주장을 고객 데이터로 다시 만들 수 있는가, 그 과정을 원자료로 추적할 수 있는가, 실패했을 때 계약으로 시정하게 할 수 있는가.
세 질문에 모두 답할 수 있는 주장만 최종 비교표에 올린다. 제안서의 문장을 재현 가능한 사실과 계약 가능한 의무로 바꾸는 일이 RAG 업체 실사의 핵심이다.