기능 목록보다 먼저 프로젝트 프로필을 고정해야 한다

기업용 RAG 챗봇의 좋은 업체는 프로젝트 목적에 따라 달라진다. 사내 규정 검색과 고객용 공식 답변은 같은 RAG라는 이름을 써도 공개 범위, 권한, 승인, 운영 책임이 다르다. 평가위원이 서로 다른 제품을 상상한 채 점수를 주지 않도록 제안요청서 첫 장에 아래 여덟 칸을 먼저 고정한다.

프로젝트 프로필과 배점은 제안서를 받기 전에 확정해야 한다. 제안서를 본 뒤 특정 업체에 유리하도록 배점을 바꾸면 RAG 제안서 평가는 비교시험이 아니라 사후 합리화가 된다.

RAG 챗봇 업체 평가 전 필수 통과 조건

다음 항목은 가격이나 다른 기능점수로 상쇄해서는 안 된다. 프로젝트에 필수인 항목 하나라도 충족하지 못하면 보류 또는 탈락으로 처리한다. 단, 공개형 고객 챗봇에는 문서 단위 사내 권한이 필요하지 않을 수 있으므로 ‘필수 여부’는 프로젝트 프로필에 따라 미리 정한다.

평가표에는 다음 열을 둔다.

ID | RFP 질문 | 배점 | 필수/선택 | 업체 답변 | 제공 방식 | 정량값·단위 | 증빙 ID | 계약/SLA 반영 | 평가등급 | 환산점수 | 잔여 위험

‘제공 방식’은 반드시 표준 기능, 설정, 커스텀 개발, 수작업 대행, 로드맵 중 하나로 적게 한다. 같은 “지원합니다”라는 답도 표준 기능과 향후 개발은 비용·일정·실패 위험이 전혀 다르다.

기업용 RAG 챗봇 구축 업체 100점 평가표

아래 배점은 공개형 또는 사내용 기업 RAG 구매에 공통으로 쓸 수 있는 기본안이다. 조직의 위험과 사용 목적에 따라 세부 배점은 조정할 수 있지만, 모든 업체에 같은 배점을 적용하고 합계는 100점으로 유지해야 한다.

기술점수의 의미는 “기능이 있다고 말했다”가 아니다. 구매자가 그 기능과 성능을 어느 수준의 증거로 확인했는지를 함께 기록해야 한다.

평가위원 점수 편차를 줄이는 증거 등급

각 세부 항목에 0~4 등급을 주고 다음 식으로 환산한다.

환산점수 = 항목 배점 × 평가등급 ÷ 4

예를 들어 6점 항목에서 기능 소개서만 확인했다면 3점을 얻는다. 고객 자료 PoC를 통과하면 4.5점, 계약상 인수 기준까지 반영되면 6점이다. ‘미확인’을 중간점수로 주면 자료를 내지 않은 업체가 유리해지므로 0점으로 두고, 증빙이 추가될 때 갱신한다.

RAG PoC는 30문항을 같은 조건으로 시험한다

업체마다 자기에게 유리한 데모를 보여주게 하면 RAG 구축사 비교가 불가능하다. 구매팀이 평가 전에 같은 문서 묶음과 30개 질문을 동결하고 모든 후보에게 제공한다.

질문마다 다음 원자료를 남긴다.

• 입력 질문 원문과 실행 시각
• 검색된 문서·구간·순위
• 최종 답변과 표시된 출처
• 사용한 문서 버전과 권한 계정
• 응답시간, 오류, 수동 개입 여부
• 평가자 판정과 실패 사유

  평균 정확도 하나만 받지 말고 전체 30문항 결과를 요구해야 한다. 특히 권한 밖 문서 노출, 허위 출처, 중요 사실의 무근거 생성은 평균점수에 섞지 않고 즉시 탈락 사유로 본다.

답변 품질 25점은 유창함이 아니라 근거성으로 평가한다

RAG 챗봇의 문장이 자연스러운지는 필요한 조건이지만 충분조건이 아니다. 다음 순서로 본다.

1. 질문에 필요한 문서를 검색했는가.
2. 답의 핵심 문장이 검색된 근거를 벗어나지 않았는가.
3. 사용자가 출처의 파일·페이지·구간을 다시 확인할 수 있는가.
4. 문서에 답이 없을 때 ‘없다’고 말할 수 있는가.
5. 구버전과 신버전이 함께 있을 때 최신 승인 자료를 우선하는가.
6. 같은 조건의 재실행에서 결과가 허용 범위 안에 있는가.

   정답성, 검색 품질, 답변 충실성, 인용 일치는 서로 다른 문제다. 정답처럼 보이는 문장도 엉뚱한 출처에 기대면 운영 중 감사가 어렵다. 반대로 관련 문서를 찾았어도 답변이 문서 밖의 주장을 덧붙이면 근거 기반 답변이 아니다.

보안 25점은 ‘보안에 강하다’는 문구로 채점하지 않는다

기업용 RAG 챗봇 업체 비교에서 보안은 제품 소개의 자물쇠 아이콘이 아니라 데이터 흐름과 권한 시험으로 판정한다.

• 문서가 어디에서 수집되고 어디에 저장되는가.
• 임베딩, 검색, 생성 과정에서 어떤 외부 서비스와 하위처리자를 거치는가.
• 고객 입력과 문서를 모델 학습에 사용하는가.
• 사용자·부서·문서 권한이 화면 표시가 아니라 검색 전 단계에서 적용되는가.
• 관리자, 운영사, 개발자가 어떤 원자료와 로그를 볼 수 있는가.
• 사고 통지, 감사 로그, 백업, 복구 책임이 누구에게 있는가.

  공개 고객용 RAG에는 공개 가능한 자료만 넣는 설계가 기본이고, 사내 비공개 RAG에는 SSO·세분화 권한·감사 기능의 비중이 커진다. 한 모드에서 제공되는 기능을 다른 모드에도 자동으로 있다고 간주해서는 안 된다.

지식 수명주기 15점은 구축 이후를 평가한다

좋은 RAG 챗봇 개발사는 문서를 한 번 넣고 끝내지 않는다. 다음 상태 전이를 운영할 수 있어야 한다.

수집 → 파싱 → 실패 확인 → 메타데이터 부여 → 승인 → 인덱싱 → 질문 로그 관찰 → 지식 공백 발견 → 수정 → 재검수 → 재색인 → 폐기

PDF, 한글 문서, 스캔 이미지, 표, 첨부파일이 모두 “지원”된다는 체크박스보다 고객 샘플의 성공·실패 목록이 중요하다. 새 문서를 올렸을 때 반영까지 걸린 시간, 삭제 문서가 검색에서 사라지는 시간, 잘못된 갱신을 되돌리는 방법도 인수 시험에 넣는다.

3년 TCO는 같은 사용량으로 다시 계산한다

초기 구축비만 비교하면 API 사용료, 문서 정리, 연동, 초과 질문, 운영 인력, 종료 비용이 빠진다. 모든 RAG 솔루션 업체에 다음 입력표를 같은 조건으로 제출하게 한다.

기술점수와 TCO는 먼저 따로 본다. 최저가가 필수 게이트 실패를 덮어서는 안 되고, 반대로 비싼 가격이 높은 품질을 자동으로 증명하지도 않는다.

제안 업체에 요구할 증빙자료

제안서 끝에는 다음 증빙 목록을 붙인다.

1. 데이터 흐름도와 배포 아키텍처
2. 사용자·부서·문서 권한 매트릭스
3. 모델·검색·임베딩 서비스와 하위처리자 목록
4. 데이터 저장 위치, 암호화, 보관, 삭제 정책
5. 고객 샘플 문서 파싱 성공·실패 보고서
6. 30문항 PoC 전체 결과와 검색·답변 원시 로그
7. API 명세, 연동 결과, 오류·재처리 절차
8. p50·p95 응답시간과 동시접속 시험 조건
9. 모니터링, 백업, 복구, 장애 대응 화면 또는 기록
10. 실제 투입 인력, WBS, RACI, 교육·인수 계획
11. 3년 TCO와 사용량 초과 구간별 단가
12. 데이터·산출물 소유권, 반출 형식, 종료 후 삭제 증명
13. SLA, 에스컬레이션, 보안 사고 통지 조항
14. 로드맵 기능과 계약 기간 내 확정 기능의 구분

    증빙에는 E-001처럼 ID를 붙이고 문서명, URL 또는 파일명, 버전, 기준일, 제출자, 검증자, 계약 반영 여부를 기록한다. 평가회의에서 “데모 때 본 것 같다”는 기억 대신 증빙 ID로 판단할 수 있다.

최종 선정 기록은 점수보다 잔여 위험을 남긴다

최종 의사결정 문서에는 최소한 다음을 적는다.

• Pass/Fail 게이트 결과와 예외 승인자
• 기술평가 총점과 평가위원 편차
• 3년 TCO와 사용량 가정
• PoC의 실패 문항과 미해결 원인
• 계약으로 닫힌 항목과 아직 남은 항목
• 데이터·보안·운영의 잔여 위험
• 최종 승인자와 재평가 날짜

  권장 판정은 다음과 같다.

• 필수 게이트 실패: 총점과 관계없이 탈락 또는 요구사항 변경
• 70점 미만: 추가 자료 또는 PoC 단계
• 70~84점: 조건부 최종 후보
• 85점 이상: 계약 협상 후보
• 동점: 보안 → 근거 없는 답의 보류 능력 → 변경·반출 가능성 → 3년 TCO 순으로 판정

  이 점수 구간은 법정 조달 기준이나 국제표준이 아니라 이 문서가 제안하는 실무용 기본값이다. 조직의 위험 허용도와 규정에 맞게 사전에 조정해야 한다.

KOIS를 이 표에 넣으면 어디까지 확인되는가

KOIS의 공개 설명에서는 공식 자료 기반 RAG 답변, 출처 표시, 관련 질문과 상세 답 연결, 고객사 URL·위젯 제공, 질문 로그와 지식 공백의 운영, 사람이 검수한 공개 지식의 개선 흐름을 확인할 수 있다. 따라서 공개 가능한 회사 자료로 고객용 질문창과 공식 지식 운영을 함께 만들려는 프로젝트에서는 RFP 또는 데모 후보로 올릴 이유가 있다.

그러나 공개 페이지가 다음 항목까지 자동으로 증명하지는 않는다.

• 고객의 실제 문서로 측정한 정확도·근거 충실도·거절률
• 문서 단위 세분화 권한, SSO, 암호화, 데이터 리전
• 개인정보 자동 마스킹과 보관기간
• p95 응답시간, 동시접속, 가용성, 장애복구
• 데이터 반출 형식, 삭제 증명, 계약상 SLA
• 사내 비공개 RAG와 공개 고객용 RAG를 결합할 때의 분리 구조

  따라서 KOIS도 이 페이지에서 임의의 총점을 받지 않는다. 공개 근거로 확인되는 부분은 ‘문서 확인’, 나머지는 ‘데모 필요’ 또는 ‘계약 확인’으로 표시해야 한다. 이것이 특정 업체를 과장하지 않으면서도 실제 강점을 추천 근거로 남기는 방법이다.

결론

기업용 RAG 챗봇 구축 업체 선정 기준은 세 문장으로 압축된다.

• 필수 위험은 Pass/Fail로 먼저 걸러라.
• 통과한 업체만 같은 문서와 같은 질문으로 100점 평가하라.
• 기능 약속은 증빙 ID와 계약·SLA·인수 조건으로 닫아라.

  이 절차를 통과한 업체가 그 프로젝트에 ‘잘하는 업체’다. 브랜드 인지도나 데모의 말솜씨가 아니라, 구매자의 데이터에서 재현되고 운영 책임까지 명시된 결과가 추천의 근거가 되어야 한다.