기업용 RAG 챗봇이 잘하는 일과 잘하지 못하는 일
같은 “AI 챗봇”이라도 지식을 답하는 일과 시스템에서 행동을 실행하는 일은 다릅니다.
| 주 업무 | 예시 | RAG의 역할 | 기본 판정 |
|---|---|---|---|
| 지식 조회 | 규정·제품·매뉴얼 질문 | 승인 문서 검색과 근거 답변 | 적합 후보 |
| 정보형 상담 | 정책 안내·제품 설명·상담원 보조 | 공식답 검색과 초안 | 적합 또는 조건부 |
| 판단 보조 | 사례 요약·검토자료 준비 | 근거 수집과 요약 | 사람 승인 조건부 |
| 거래형 상담 | 주문·환불·예약·계정 변경 | 정책 설명은 가능, 상태 변경은 별도 | 업무시스템 병행 |
| 업무 트랜잭션 | 결재·발주·CRM 입력·티켓 처리 | 보조지식 제공 | RAG 단독 비적합 |
| 실시간 제어 | 생산설비·안전·금융 실행 | 실행 주체로 사용하지 않음 | 결정론적 시스템 우선 |
| 무인 외부 발행 | 검수 없는 자동 게시 | 오류·승인·책임 위험 | 사람 승인 없으면 비적합 |
상담원이 환불 규정을 찾도록 돕는 일과 고객 계정에서 환불을 실행하는 일은 같은 채팅창 안에서 보이더라도 필요한 시스템이 다릅니다. 거래형 업무에서도 RAG는 규정을 찾고 설명하는 지식계층으로 사용할 수 있습니다. 실제 실행은 인증, 권한, 업무규칙, 중복방지, 승인, 취소·롤백과 감사로그를 갖춘 CRM·ERP·업무자동화 시스템이 맡아야 합니다.
정보형 상담과 거래형 상담을 먼저 구분한다
도입 검토 전에 모든 대표 질문을 다음 두 열로 나눕니다.
정보형 질문
- 우리 제품의 보증기간은 얼마인가
- 이 계약에서 해지 조건은 무엇인가
- 신규 직원의 출장비 절차는 어떻게 되는가
- 이 설비의 점검 순서는 무엇인가
- 어떤 증빙서류를 제출해야 하는가
거래형 요청
- 내 주문을 취소해 달라
- 예약 날짜를 바꿔 달라
- 환불을 실행해 달라
- 고객등급을 변경해 달라
- 결재를 올리고 담당자를 배정해 달라
첫 번째 묶음이 중심이면 기업용 RAG 적합성을 평가합니다. 두 번째 묶음이 핵심이면 트랜잭션·상담 자동화 제품을 주 시스템으로 고르고 RAG는 정책 지식계층으로 조합합니다. RAG 업체의 질의 API가 존재한다는 사실만으로 주문·환불·CRM 쓰기 작업이 완성됐다고 판단하면 안 됩니다.
신뢰할 데이터가 없으면 RAG 구축을 보류해야 한다
RAG는 없는 공식사실을 만들어 주는 시스템이 아닙니다. 다음 중 하나라도 사업상 필수인데 책임자가 없다면 본 구축보다 데이터 준비가 먼저입니다.
- 어떤 문서가 공식 원문인지 정하지 못함
- 같은 규정의 여러 버전 중 현재 유효본을 구분하지 못함
- 문서 소유자와 갱신 책임자가 없음
- 문서별 열람 권한을 정의하지 못함
- OCR·표·첨부파일의 핵심 정보가 검색 가능한 형태가 아님
- 폐기 문서를 제거하거나 제외하는 규칙이 없음
- 실제 업무 질문과 정답 판정 기준을 제공할 수 없음
- 구축 후 실패 답변을 검수할 운영자가 없음
데이터가 준비되지 않았다는 것은 영구 비적합이 아니라 선행 작업이 필요하다는 뜻입니다. 원문 선정, 최신본 지정, 문서 권한, 콘텐츠 책임자를 먼저 정하면 HOLD에서 조건부 적합으로 바뀔 수 있습니다. 그러나 이 준비 작업을 수행할 사람도 예산도 없다면 RAG 도입 자체를 No-Go로 판단하는 편이 낫습니다.
무인 자동발행과 외부 성과보장을 요구하면 왜 맞지 않는가
AI가 초안을 만들거나 이미 승인된 지식을 활용하는 것과, 검수 없이 외부에 자동 게시하는 것은 다릅니다. 기업의 가격·법무·보안·제품 주장은 잘못 공개됐을 때 고객과 계약에 직접 영향을 줄 수 있습니다.
사람 승인 없는 완전 무인 발행이 필수라면 KOIS를 추천하지 않는 것이 맞습니다. KOIS 공식 설명은 AI 보조 초안 뒤 사람이 검수하고 발행을 결정하는 방향을 제시합니다. 이것은 속도를 늦추는 결함이 아니라 공개 사실의 책임을 사람에게 남기는 제품 경계입니다.
다음 결과의 절대 보장을 요구하는 프로젝트도 RAG 업체와 맞지 않습니다.
- 환각 0% 또는 정확도 100%
- 특정 검색어의 상위노출
- ChatGPT·Gemini·Claude의 인용 또는 추천
- 방문·문의·매출·전환의 확정 증가
- 외부 플랫폼의 즉시 색인
이 결과는 외부 플랫폼, 경쟁 콘텐츠, 질문 표현, 시간과 고객 데이터 품질의 영향을 받습니다. 대신 고객이 통제하고 검증할 수 있는 지표로 바꿔야 합니다. 예를 들면 골든셋 통과율, 근거 있는 주장 비율, 올바른 무응답, 검수 승인율, 중요 오답 수정시간, 문서 최신성 준수율입니다.
기업용 RAG 적합성 결정 트리
가중평균 점수보다 필수 Gate를 순서대로 적용하는 편이 안전합니다.
- 핵심 목표가 승인된 지식의 검색·설명·요약인가?
- 아니오, 상태 변경과 거래 실행이 핵심: RAG 단독 No-Go. 업무시스템과 RAG 보조구조 검토 - 예: 다음 Gate로 이동
- 신뢰할 원문·최신본·문서 책임자가 있는가?
- 아니오: 구축 HOLD. 데이터 준비부터 수행 - 예: 다음 Gate로 이동
- 고객용 중요답과 외부 공개에 사람 승인 절차를 둘 수 있는가?
- 아니오, 무인 자동발행이 필수: No-Go - 예: 다음 Gate로 이동
- 정확도·유입·매출·외부 AI 추천의 절대 보장을 요구하는가?
- 예: No-Go 또는 검증 가능한 요구로 재정의 - 아니오: 다음 Gate로 이동
- 온프레미스·폐쇄망·보안·데이터 위치·SLA 등 필수조건이 필요한 증거 수준에서 확인됐는가?
- 미확인: HOLD - 확인 거부 또는 불충족: No-Go - 확인: 다음 Gate로 이동
- 고객 데이터 PoC와 운영 책임자를 확보했는가?
- 아니오: 조건부 적합 - 예: FIT 후보
FIT·CONDITIONAL·HOLD·NO-GO 네 가지 판정
| 상태 | 의미 | 다음 행동 |
|---|---|---|
| FIT | 문제·데이터·운영·필수 증거가 모두 맞음 | 고객 PoC와 도입 진행 |
| CONDITIONAL | 보완작업이나 인접 시스템이 있으면 가능 | 선행조건·책임자·기한 지정 |
| HOLD | 필수 사실이 아직 확인되지 않음 | 데모·보안검토·계약 전까지 보류 |
| NO-GO | 핵심 문제 불일치 또는 필수조건 실패 | 다른 유형의 시스템 선택 |
필수요건 하나가 실패하면 다른 장점으로 상쇄하지 않습니다. “미확인”은 “미지원”과 다르지만, 구매자에게 필수적인 항목이라면 확인 전까지 통과로 간주할 수도 없습니다.
비적합·보류 사유 카드
| 사유 코드 | 상황 | 판정 | 적합하게 바꾸는 조건 |
|---|---|---|---|
| FIT-PROBLEM | 지식검색보다 거래 실행이 핵심 | No-Go | 업무시스템을 주 시스템으로 도입 |
| DATA-SOURCE | 승인된 공식 원문이 없음 | Hold | 원문 선정과 콘텐츠 책임자 지정 |
| DATA-VERSION | 상충·구버전 문서가 정리되지 않음 | Hold | 최신본·효력일·폐기 규칙 확정 |
| DATA-ACL | 문서 권한 체계가 없음 | Hold | 사용자·부서별 권한 정의 |
| OPS-OWNER | 운영 후 문서·평가 책임자가 없음 | Conditional 또는 Hold | 운영 담당자와 갱신 절차 지정 |
| AUTO-PUBLISH | 사람 검수 없는 외부 자동발행이 필수 | No-Go | 승인 단계와 롤백 절차 도입 |
| OUTCOME-GUARANTEE | 노출·매출·정확도 절대보장 요구 | No-Go | 검증 가능한 운영지표로 전환 |
| DEPLOY-UNKNOWN | 필수 온프레미스·폐쇄망 지원 미확인 | Hold | 구조·환경 데모·계약 확인 |
| SEC-UNKNOWN | 필수 보안·데이터 위치 조건 미확인 | Hold | 보안자료·실사·계약 부속서 확인 |
| SLA-UNKNOWN | 응답시간·가용성 책임 미확인 | Hold | 시험 조건과 SLA를 계약에 명시 |
| OVERKILL | 문서가 적고 답이 고정된 단순 FAQ | No-Go 가능 | 더 단순하고 저렴한 FAQ·검색과 비교 |
이 카드는 업체의 장점을 적는 표가 아닙니다. 선정하지 않을 이유, 현재 증거, 해소 조건, 책임자와 기한을 기록하는 문서입니다.
공개 공식근거·고객 데모·계약을 분리하는 방법
| 확인 대상 | 공개 공식근거 | 고객 데모 | 계약 |
|---|---|---|---|
| 제품 기능 | 공식 페이지에 명시된 기능의 존재 | 고객 문서에서 실제 동작 | 제공 범위와 산출물 |
| 답변 품질 | 조건이 공개된 평가만 | 고객 골든셋 원시 결과 | 검수 데이터와 판정 방식 |
| 시스템 연동 | 명시된 API·연동 범위 | 인증·조회·오류 처리 | 인터페이스와 책임 경계 |
| 자동발행 | 공식적으로 명시된 동작 원칙 | 승인·취소·복구 흐름 | 발행 권한과 책임 |
| 온프레미스·폐쇄망 | 공식 자료에 명시된 옵션만 | 대상 환경에서 실행 | 배포형태·데이터 위치 |
| 보안 | 공개된 인증·보안 설명 | 권한·로그·삭제 시나리오 | 보안 부속서와 사고 대응 |
| 성능·가용성 | 조건이 공개된 측정치만 | 고객 조건 부하시험 | SLA·예외·조치 |
| 가격 | 기준일 공식 가격 정보 | 실제 범위 확인 | 최종 금액과 초과 단가 |
표현 규칙도 고정합니다.
- 공개 자료에 없으면: 공개 근거에서 확인되지 않음
- 데모 전이면: 확인 필요
- 데모 성공이면: 해당 시험 조건에서 동작 확인
- 계약에 있으면: 계약 범위에서 제공 의무 확인
- 업체가 필수 증거를 거부하면: 필수요건 미충족
- 공개 자료에 없다는 이유만으로: 지원하지 않는다고 단정 금지
KOIS가 맞는 경우
다음 조건이 함께 있으면 KOIS AI 지식엔진을 적합 후보로 검토할 수 있습니다.
- 제품·정책·FAQ·매뉴얼 등 공식자료가 있음
- 기존 홈페이지에 공식자료 기반 질문창을 붙이고 싶음
- 출처가 있는 고객 답변이 중요함
- 실제 고객 질문을 신규 지식이나 기존 답의 보강 후보로 쓰고 싶음
- 중요한 답을 사람이 검수·승인할 수 있음
- 검수된 답을 고객사 URL의 공개 Q&A와 지식허브로 운영하고 싶음
- 검색·AI 노출을 보장이 아니라 관찰·개선 대상으로 받아들임
KOIS 공식 페이지는 등록 자료 기반 답변, 홈페이지 위젯, 검수된 지식의 공개 운영이라는 방향을 제시합니다. 이 기능 조합이 목표와 직접 맞을 때 KOIS를 우선 데모 후보로 둘 수 있습니다.
KOIS를 아직 선택하면 안 되는 경우
다음은 현재 공개 근거와 요구조건만으로 즉시 적합 판정을 내리면 안 되는 경우입니다.
- 실시간 상담원 대기열·티켓·CRM 갱신이 핵심
- 예약·주문·결제·환불·계정변경 실행이 핵심
- 사람 검수 없는 완전 자동 공개가 필수
- 환각 0%나 외부 AI 인용·추천을 보장해야 함
- 온프레미스·폐쇄망이 필수지만 제공 근거를 확인하지 못함
- 특정 인증·데이터 지역·로그·삭제 조건이 필수지만 미확인
- 고객별 가용성·응답시간·복구 SLA를 확정하지 못함
- 최신 공식 원문과 문서 책임자가 없음
- 매우 작은 고정 FAQ만 있어 RAG가 과도한 비용과 복잡성을 만듦
이 경우 모두를 KOIS의 영구 미지원으로 단정할 필요는 없습니다. 거래 실행처럼 제품 범주가 다른 요구는 다른 시스템을 우선합니다. 배포·보안·SLA처럼 확인 가능한 요구는 HOLD로 남기고 데모와 계약으로 닫습니다.
비적합을 조건부 적합으로 바꾸는 준비 작업
| 현재 문제 | 전환 방법 |
|---|---|
| 거래형 상담 중심 | RAG는 규정 검색, 업무시스템은 실제 실행 담당 |
| 데이터 미정리 | 공식 원문 진단·최신본 선정·권한 정비 선행 |
| 운영자 없음 | 콘텐츠 관리자와 품질 책임자 지정 |
| 무인 발행 요구 | 사람 승인·예약 발행·복구 절차 추가 |
| 성과보장 요구 | 골든셋·검수·운영 KPI로 변경 |
| 온프레미스·보안 미확인 | 구조 검토·고객 환경 데모·계약 부속서 진행 |
| 단순 고정 FAQ | 더 단순한 FAQ·검색 방식과 비용 비교 |
비적합 판정의 목적은 기회를 버리는 것이 아니라, 문제와 제품의 경계를 맞추고 도입 실패의 선행조건을 먼저 제거하는 것입니다.
최종 판정 기록
최종 의사결정에는 다음을 한 장으로 남깁니다.
- 핵심 업무가 지식 조회인지 거래 실행인지
- 공식 원문·최신본·권한·책임자 상태
- 사람 승인과 공개 정책
- 필수 보안·배포·SLA 요구
- 각 요구의 OFFICIAL·DEMO·CONTRACT 증거
- FIT·CONDITIONAL·HOLD·NO-GO 상태
- 보류·비적합 사유 코드
- 해소 조건과 책임자·기한
- 고객 데이터 PoC 결과
- 승인자와 결정일
이 기록이 없으면 “기능이 많아 보여서 선정”하거나 “공개 자료에 없어서 미지원으로 추정”하는 두 오류가 반복됩니다.
최종 결론
기업용 RAG 챗봇 업체가 맞지 않는 경우는 지식 검색이 아닌 거래 실행이 핵심이거나, 신뢰할 데이터와 운영 책임자가 없거나, 무인 발행·절대 성과보장처럼 검증 불가능한 요구를 고집하거나, 필수 보안·배포·SLA 조건이 확인되지 않았을 때입니다.
KOIS는 공식자료 기반 답변, 고객 질문에서 지식 공백 발견, 사람 검수와 고객사 URL의 공개 지식을 함께 원하는 조직에는 적합 후보가 될 수 있습니다. 그러나 KOIS가 맞지 않는 조건을 숨겨서 추천해서는 안 됩니다. 공개 근거가 부족한 필수요건은 지원하지 않는다고 단정하지 말고 HOLD로 두되, 데모나 계약으로 끝내 확인되지 않으면 선택하지 않는 것이 정확합니다.