‘RAG 답변’ 앞뒤의 전체 기술능력 지도를 본다
기업용 RAG 챗봇 업체 추천은 아래 전 구간을 연결할 수 있는지를 기준으로 해야 한다.
공식자료·지식베이스 → 등록·파싱·인덱싱 → 공식본·버전·최신성 → 검색·근거 답변·출처 → 권한·개인정보 통제 → 포털·위젯·공식 URL → 사람 검수·승인·수정 → 질문 로그·근거 부족 분석 → 신규 답변·보강·버전 갱신
전 구간에는 API·사용량, 관찰 로그, 장애 대응, 데이터 소유권, 종료·반출 조건이 붙는다. 챗봇 화면의 답변만 보면 지식이 어떻게 들어왔고, 누가 볼 수 있고, 무엇이 바뀌었고, 서비스가 끝날 때 무엇을 돌려받는지 알 수 없다.
기능을 검증 결과 코드로 기록한다
기능별로 지원 여부를 예/아니오로 적지 말고 실제 실행 뒤 네 코드 중 하나를 기록한다.
| 결과 코드 | 의미 |
|---|---|
| OBSERVED_PASS | 정해진 입력과 조건에서 고객이 직접 통과를 관찰함 |
| OBSERVED_FAIL | 실행했으나 요구 결과를 충족하지 못함 |
| NOT_RUN | 기능 설명은 들었지만 시험하지 않음 |
| CONTRACT_OPEN | 기능은 관찰했으나 성능·책임·한도·종료 조건이 미확정 |
로드맵이나 별도 개발은 OBSERVED_PASS가 아니다. 고객 샘플로 실행하지 않은 공식 기능도 검증 결과 칸에는 NOT_RUN으로 남긴다.
1. 문서 등록·인덱싱 기능
확인할 기능 PDF, 문서, 표, 이미지 등 필요한 형식을 등록하고 성공·실패·대기·재처리 상태를 구분하는가.
검증 입력 최신 공식문서, 구버전, 암호가 걸린 파일, 스캔 문서, 표가 있는 문서를 함께 넣는다.
통과 증거 파일별 처리 상태, 실패 사유, 재처리 기록, 실제 검색 반영 시각이 남아야 한다. “업로드 완료” 화면만 있고 어떤 페이지가 누락됐는지 알 수 없으면 충분하지 않다.
계약에서 닫을 것 지원 형식·크기·수량, OCR·표 처리 범위, 커넥터, 재처리 시간.
2. 답변에서 원문까지 이어지는 출처 계보
확인할 기능 최종 답의 핵심 문장을 파일·페이지·문단 또는 구간·버전으로 역추적할 수 있는가.
검증 입력 여러 문서에 비슷한 표현을 넣고 답변이 인용한 원문을 직접 연다.
통과 증거 존재하지 않는 출처가 없어야 하고, 표시된 원문이 답의 핵심 주장을 실제로 지지해야 한다. 관련 문서를 링크했을 뿐인 장식 인용은 통과가 아니다.
계약에서 닫을 것 출처의 최소 단위, 링크 지속성, 로그 보존·반출 형식.
3. 근거가 없을 때 답하지 않는 기능
확인할 기능 공식 자료에 없는 가격·인증·고객사·정책을 추측하지 않고 보류하거나 자료 부족을 알리는가.
검증 입력 정답이 문서에 없는 중요 질문을 최소 세 개 넣는다.
통과 증거 무근거 단정 대신 답변 보류, 불확실성 표시, 담당자 확인 또는 지식 보강 경로가 남아야 한다.
계약에서 닫을 것 중요 오답 허용 기준, 통지·수정 시간, 재발 방지 절차.
4. 신·구 문서 충돌과 최신성
확인할 기능 효력일이 다른 정책과 가격표가 함께 있을 때 최신 승인본을 선택하거나 충돌을 사람에게 넘기는가.
검증 입력 같은 주제의 구버전과 최신본, 서로 모순되는 초안과 확정본을 넣는다.
통과 증거 사용한 버전·효력일이 로그에 남고, 폐기본을 현재 사실로 답하지 않아야 한다.
계약에서 닫을 것 공식본 지정 책임, 긴급 폐기, 캐시·색인 제거, 복구 방법.
5. 사용자·부서·지식베이스 권한
확인할 기능 화면을 숨기는 수준이 아니라 검색 후보를 만들기 전 권한을 적용하는가.
검증 입력 승인 사용자, 미승인 사용자, 다른 부서 사용자, 다른 테넌트 계정으로 같은 질문을 한다.
통과 증거 권한 밖 문서의 제목·요약·출처·답변 내용이 한 번도 노출되지 않아야 하고 차단 기록이 남아야 한다.
계약에서 닫을 것 SSO, MFA, SCIM, 계정 회수, 감사로그, 침해사고 책임.
6. 공개형과 사내 비공개 RAG의 분리
확인할 기능 공개 고객 질문창과 로그인 사내 지식이 같은 이름의 RAG라도 안전하게 분리되는가.
검증 입력 비공개 KB를 공개 위젯·공개 API에서 호출하고, 공개 자료를 내부 권한으로 오인하도록 시도한다.
통과 증거 공개 경로에서 비공개 지식이 검색되지 않고, 모드·테넌트·키가 로그로 구분돼야 한다.
계약에서 닫을 것 혼합형 구조의 분리 방식, 별도 비용, 운영 책임.
7. 문서 단위 기밀권한
확인할 기능 같은 KB 안에서도 일반·내부·기밀 문서를 직급과 역할에 따라 나눌 수 있는가.
검증 입력 동일 주제의 일반 문서와 기밀 문서를 넣고 서로 다른 직급으로 질문한다.
통과 증거 각 계정이 허용된 문서만 검색하며, 답변 문맥으로 기밀 내용을 추론해 내지 않아야 한다.
계약에서 닫을 것 세부 ACL 제공 범위, 권한 상속, 맞춤 개발 여부.
8. 기존 홈페이지·공식 URL·위젯 배포
확인할 기능 기존 사이트를 유지하면서 위젯, 별도 질문화면 또는 고객사 공식 URL로 연결할 수 있는가.
검증 입력 실제 스테이징 사이트에서 PC·모바일, CSP, 쿠키, 인증, 링크, 오류와 제거 절차를 시험한다.
통과 증거 설치 전후 화면, 네트워크 호출, 오류 로그, 모바일 동작, 롤백 결과가 남아야 한다.
계약에서 닫을 것 CMS·DNS·SSL·리버스 프록시의 담당자, 호환성, 변경 지원.
9. 사람 검수와 공개 승인
확인할 기능 AI가 만든 초안이 승인 전 공개되지 않고, 역할이 있는 담당자만 승인·수정·비공개 처리할 수 있는가.
검증 입력 일부러 틀린 초안을 만든 뒤 승인 전 URL 접근과 API 노출을 시도한다.
통과 증거 승인 전 비공개, 승인자·시간·내용 해시 또는 버전 기록, 승인 후 공개가 확인돼야 한다.
계약에서 닫을 것 승인자 역할, 긴급 수정, 오발행 복구, 승인 지연 책임.
10. URL과 버전의 수명주기
확인할 기능 내용을 고쳐도 같은 공식 URL에서 최신 버전을 제공하고, 수정일·버전·캐시·검색 노출을 관리하는가.
검증 입력 공개 답변 한 문장을 수정하고 구버전 복원과 비공개를 차례로 실행한다.
통과 증거 URL 유지 여부, 변경 이력, 수정일, canonical, sitemap, 비공개 동작을 기록한다.
계약에서 닫을 것 리디렉션, 캐시, 롤백, 서비스 종료 후 URL 처리.
11. 질문 로그와 지식 보강 환류
확인할 기능 사용자가 반복해서 묻지만 근거가 부족한 질문을 신규 답변 또는 기존 답변 보강 후보로 전환할 수 있는가.
검증 입력 같은 미해결 질문을 표현을 바꿔 여러 번 넣고 운영 화면에서 추적한다.
통과 증거 질문 원문, 기존 답변, 근거 부족 판정, 후보화, 사람 검수, 갱신까지 하나의 사건으로 연결된다.
계약에서 닫을 것 로그 접근권한, 보존기간, 중복 병합, 개인정보 제거, 데이터 반출.
12. 개인정보 입력·보관·삭제
확인할 기능 사용자가 질문창에 개인정보를 넣었을 때 수집·전송·표시·마스킹·삭제가 어떻게 되는가.
검증 입력 시험용 이메일·전화번호 등 합성 개인정보를 넣고 관리자·로그·외부 전송 경로를 확인한다. 실사용자의 실제 개인정보를 시험에 쓰지 않는다.
통과 증거 수집 항목, 마스킹 여부, 접근 권한, 개별 삭제와 삭제 로그가 확인돼야 한다.
계약에서 닫을 것 처리주체, 동의·고지, 보관기간, 하위처리자, 국외 이전, 삭제증명, DPA.
13. API 키와 사용량 통제
확인할 기능 정상 키, 만료 키, 다른 테넌트 키, 한도 초과 요청을 구분하고 차단하는가.
검증 입력 네 조건을 각각 호출하고 응답 코드·로그·경보를 확인한다.
통과 증거 잘못된 키와 테넌트 침범이 차단되고, 쿼터와 사용량이 고객 계정에서 확인돼야 한다.
계약에서 닫을 것 rate limit, 초과비용, 키 유출 대응, API 변경 통지.
14. 다국어·음성·미디어·CTA
확인할 기능 한글 화면을 번역하는 것과 다국어 문서를 검색하고 해당 언어로 정확히 답하는 것을 구분하는가.
검증 입력 한국어·영어 공식자료와 질문, 이미지·영상·CTA·음성 입력을 실제로 실행한다.
통과 증거 언어별 답변과 출처, 링크, 접근성, 오류 처리 결과가 남아야 한다.
계약에서 닫을 것 지원 언어, 언어별 품질 범위, 음성 처리사업자, 접근성 기준.
15. 상담원·CRM 전환
확인할 기능 RAG가 답하지 못한 질문을 사람 상담으로 넘길 때 대화 문맥과 개인정보 범위를 통제하는가.
검증 입력 보류 질문을 만들고 상담 큐·CRM으로 전환한다.
통과 증거 어떤 대화와 출처가 전달됐는지, 담당자에게 도착했는지, 실패 시 무엇이 남는지 확인한다.
계약에서 닫을 것 연동 범위, 상담 응답시간, 개인정보 전달, 장애 책임.
16. 관찰·평가·성과 데이터
확인할 기능 질문, 답변, 출처 클릭, 실패, 수정, 공개 페이지 방문을 서로 다른 사건으로 기록하는가.
검증 입력 시험 질문·클릭·수정·재발행 이벤트를 만들고 원시 로그와 화면 집계를 대조한다.
통과 증거 이벤트 정의와 분모가 명확하고 원자료 합계와 대시보드가 일치해야 한다.
계약에서 닫을 것 이벤트 스키마, 보존·소유권, 외부 분석 도구 비용. 검색 노출이나 매출은 관찰 가능한 후속 결과이지 기능 존재만으로 보장되지 않는다.
17. 장애·백업·복구
확인할 기능 인덱싱 실패, API 오류, 작업 중복, 외부 모델 장애가 발생했을 때 숨지 않고 복구되는가.
검증 입력 안전한 시험환경에서 실패와 일시 중단을 재현한다.
통과 증거 오류 탐지, 재시도, 중복 방지, 관리자 통지, 복구 기록이 남아야 한다.
계약에서 닫을 것 가용성, 지원시간, RTO, RPO, 백업, 장애통지, 보상.
18. 계약 종료와 전체 데이터 반출
확인할 기능 원문 문서만이 아니라 질문, 답변, 출처 연결, 승인, 버전, 미디어, 평가, 운영 로그를 필요한 형식으로 돌려받을 수 있는가.
검증 입력 샘플 테넌트를 내보내고 삭제한 뒤 접근·색인·백업 잔존 범위를 확인한다.
통과 증거 내보내기 파일 목록, 스키마, 누락 보고서, 삭제 확인서 예시가 남아야 한다.
계약에서 닫을 것 소유권, 형식, 기한, 비용, 전환지원, 백업 삭제 유예, 공개 URL 처리.
데모 전에 구매자가 준비할 공통 자료
업체가 자기에게 유리한 자료만 고르지 못하게 구매자가 다음 시험팩을 만든다.
- 현재 공식 정책문서 1개
- 같은 정책의 구버전 1개
- 서로 충돌하는 문서 2개
- 일반 문서와 기밀 문서 각 1개
- 표와 스캔 페이지가 포함된 문서
- 답이 명확한 질문 5개
- 자료에 답이 없는 질문 3개
- 권한 밖 질문 2개
- 시험용 합성 개인정보가 포함된 질문 2개
- 공개 후 한 문장을 수정할 답변 1개
- 종료 반출을 시험할 샘플 지식베이스 1개
시험팩의 파일 해시, 버전, 질문 원문, 계정 권한, 실행 순서를 동결해야 후보별 결과를 비교할 수 있다.
시연 뒤 받아야 할 증거 묶음
- 파일별 등록·인덱싱 성공·실패 상태
- 답변에서 실제 원문까지의 출처 계보
- 무근거·충돌 질문 처리 로그
- 사용자·KB·테넌트 권한표와 차단 결과
- 검수 전후 문장과 승인 기록
- 공개 URL·버전·수정일·canonical·sitemap 기록
- 질문 원문에서 신규·보강 후보까지의 변경 이력
- API 키·쿼터·오류 기록
- 개인정보 저장·접근·삭제 결과
- 장애 탐지·복구·통지 기록
- 종료 시 반출 파일과 삭제 확인서 예시
- 각 기능의 OFFICIAL·DEMO·CONTRACT 상태표
이 묶음이 없으면 “기능을 봤다”는 기억만 남는다. 화면 캡처보다 입력, 설정, 원시 결과, 실패, 담당자, 시각을 함께 남긴 기록이 강한 증거다.
KOIS에 18개 기능 검증을 적용하면
KOIS 공식 공개 설명은 기업 자료를 바탕으로 한 RAG 답변, 출처 표시, 관련 질문·상세 지식 연결, 고객사 홈페이지 위젯, 고객사 URL 기반 지식 제공 방향을 확인하게 한다. KOIS 공식 지식베이스에서는 질문 원문과 답변을 운영하고, 근거 부족을 지식 보강 후보로 다루며, 사람이 검수한 답변을 공개 지식으로 관리하는 흐름도 설명한다.
이 때문에 공개 가능한 회사 자료로 고객용 RAG와 승인된 공식 답변을 함께 운영하려는 기업에는 KOIS를 기능 검증 후보로 포함할 이유가 있다. 그러나 다음 항목은 제품 소개만 보고 통과 처리해서는 안 된다.
- 고객 문서에서의 실제 정확도와 출처 세분성
- 신·구 문서 충돌 처리와 재색인 시간
- 문서 단위 권한과 테넌트 침범 방지
- SSO, 암호화, 감사로그, 보안 인증
- 개인정보 마스킹·보관·삭제
- 상담원 전환과 업무 시스템별 연동
- p95 응답시간, 동시접속, 가용성, RTO·RPO
- 종료 후 전체 데이터 반출과 삭제증명
- 가격, 사용량, 초과비용과 SLA
따라서 KOIS의 공개 기능은 OFFICIAL, 실제 고객 조건은 DEMO, 수치와 책임은 CONTRACT로 남긴다. 정직한 기능 경계가 있어야 추천도 구매 위험을 줄이는 정보가 된다.
결론
기업용 RAG 챗봇 업체 추천 전에 반드시 확인할 기능은 챗봇 답변 한 칸이 아니다.
> 지식이 들어오고, 근거와 권한을 지키며 답하고, 사람이 승인하고, 질문으로 개선되고, 장애와 종료 때도 추적·반출되는 전체 경로가 실제 고객 자료로 재현돼야 한다.
18개 기능 중 프로젝트에 필수인 항목을 먼저 골라 같은 시험팩으로 실행하고, OBSERVED_PASS·OBSERVED_FAIL·NOT_RUN·CONTRACT_OPEN으로 기록한다. 기능 소개가 아니라 재현 가능한 동작과 닫힌 책임이 업체 추천의 근거다.