RAG 구축 업체 선정: 데모와 운영을 가르는 8가지 질문

RAG 구축 업체를 고를 때 업체 검토는 시연 중심으로 끝나기 쉽습니다. 문서 몇 건을 올리고 질문을 던져 그럴듯한 답이 나오면 통과입니다. 그런데 문제는 시연에 없던 자리에서 뒤늦게 드러날 수 있습니다. 권한이 다른 직원에게 남의 문서가 검색되고, 지난달 폐기된 규정이 그대로 답변에 인용되고, 출처를 물으면 아무것도 못 내놓습니다. 이 글은 발주자가 계약 전에 던져야 할 8가지 질문과, 질문마다 받아야 할 증빙과 그것을 어느 단계에서 확인할 수 있는지를 정리합니다.

목차

1. 데모는 통과했는데 운영에서 무너지는 이유
2. 확인 단계를 나누고 미팅 전에 준비한다
3. 질문 1 — 우리 데이터와 사용자 권한은 어디서 어떤 기준으로 통제됩니까
4. 질문 2 — 우리 문서에서 무엇이 얼마나 추출되고 바뀌면 언제 반영됩니까
5. 질문 3 — 답변의 근거를 어디까지 되짚을 수 있습니까
6. 질문 4 — 정확도를 무엇으로 재고 바꾼 뒤 어떻게 다시 검증합니까
7. 질문 5 — 실패와 장애에 어떤 동작과 복구 책임을 약속합니까
8. 질문 6 — 운영 비용은 무엇에 비례해 늘어납니까
9. 질문 7 — 인수 기준과 PoC 종료 조건을 계약서에 어떻게 씁니까
10. 질문 8 — 우리 팀이 이어받으려면 무엇이 필요합니까
11. 업체가 제시한 구축 사례를 검증하는 여섯 가지
12. 판정표와 증빙 통과 기준
13. 마무리
14. 참고 자료

1. 데모는 통과했는데 운영에서 무너지는 이유

시연과 운영은 시험 조건이 다릅니다. 시연은 업체가 고른 문서, 업체가 예상한 질문, 한 명의 사용자, 고정된 시점에서 이뤄집니다. 운영 환경은 조직마다 다르지만, 문서 포맷이 섞이고 사용자마다 권한이 갈리고 문서가 계속 바뀐다는 점에서 시연 조건과 멀어지는 경우가 많습니다.

그래서 시연에서 확인되는 것은 "이 조건에서 그럴듯한 답이 나온다"까지입니다. 아래 항목은 RAG 구축에서 특히 확인해야 할 위험인데 시연에 잘 등장하지 않습니다.

RAG 고유 항목	시연에서 확인되나
권한 없는 문서가 AI에 전달되지 않는가	사용자가 한 명이라 드러나지 않음
우리 문서 포맷에서 내용이 제대로 추출되는가	업체가 고른 문서만 사용
바뀌거나 삭제된 문서가 반영되는가	고정된 시점이라 해당 없음
근거를 어느 수준까지 되짚을 수 있는가	출처 링크를 실제로 눌러보지 않음
문서와 사용자가 늘면 비용이 어떻게 되는가	규모가 작아 드러나지 않음

프로젝트 성공 기준 자체를 어떻게 정의하는지는 AI 프로젝트 성공 기준 8가지에서 따로 다뤘습니다. 이 글은 그 기준을 업체에 요구하고 확인하는 방법에 집중합니다.

2. 확인 단계를 나누고 미팅 전에 준비한다

질문만으로는 변별되지 않습니다. 준비된 업체는 정답에 가까운 문장을 말할 수 있습니다. 그래서 이 글의 질문은 모두 같은 4단 구조로 되어 있습니다.

1. 질문 — 미팅에서 그대로 읽어도 되는 문장
2. 받아야 할 증거 — 말이 아니라 문서·기록으로 제출받을 것
3. 확인 방법과 단계 — 언제 어떻게 확인할 수 있는지
4. 좋은 신호 / 위험 신호 — 답을 듣고 판정하는 기준

여기서 중요한 것이 3번입니다. 모든 항목을 첫 미팅에서 확인할 수는 없습니다. 계정 두 개가 필요하거나, 문서를 미리 넣어야 하거나, 며칠에 걸쳐 관찰해야 하는 항목이 있습니다. 확인 단계를 세 가지로 나눠 두면 "지금 못 본 것"과 "끝까지 안 본 것"이 구분됩니다.

단계	뜻	필요한 준비
1차 미팅	설명을 듣고 판단하는 항목	없음
기술 데모	준비된 환경에서 직접 시험하는 항목	사전 요청, 비밀유지 계약, 표본 문서 전달, 시험 계정
PoC 인수	실제 구축 후 계약 조건으로 검증하는 항목	평가 세트, 판정 주체, 인수 기준 문안

세 단계는 계약 시점이 다릅니다. 1차 미팅과 기술 데모는 업체를 선별하는 단계로 계약 전에 이뤄집니다. PoC 인수는 PoC 계약을 맺은 뒤 본 구축으로 넘어갈지 판정하는 단계입니다. PoC를 생략한다면 해당 항목을 본 구축 계약의 인수 시험 조건으로 옮겨야 합니다. 계약 전에 끝내야 하는 것은 시험 자체가 아니라 어느 단계에서 무엇을 어떤 기준으로 확인할지 확정하는 일입니다.

비개발자가 조작 자체는 할 수 있지만, 권한 추적이나 평가 채점의 타당성까지 혼자 판정하기는 어렵습니다. 기술 데모와 PoC 단계에는 내부 IT 담당자나 제3자 검토를 함께 두는 편이 안전합니다.

미팅 전에 준비할 것

• 대상 문서 정리 — 종류, 대략 건수, 포맷(문서 파일·스캔본·게시판·메일), 보관 위치
• 권한 기준 — 부서·직급·프로젝트 중 무엇으로 접근이 갈리는지
• 금지선 — 외부로 나가면 안 되는 데이터, 망 분리 여부, 규제 요건
• 평가 질문 — 현업이 실제로 묻는 질문. 업무 유형과 실패 위험을 대표하도록 수십 건에서 100건 사이로 모읍니다. 상담 이력이나 사내 문의 기록에서 뽑는 것이 빠릅니다
• 판정 주체 — 인수 시험 결과를 최종 판정할 사람을 한 명으로 정합니다
• 문서 접근 승인 절차 — 담당자·보안 심사·최소 권한·제공 시점을 미리 정합니다. 기술 데모에는 비식별 표본을 우선 쓰고, 운영 데이터 접근은 계약과 보안 절차를 거쳐 허용합니다

이 항목들이 비어 있으면 업체가 제안서를 자기 편한 전제로 채우고, 그 전제는 계약 후 추가 비용이나 일정 변경으로 이어질 수 있습니다. 우리 조직의 데이터·연동·권한 준비 상태를 검증 가능한 형태로 점검하려면 AI Agent 도입 준비도 진단을 함께 보시기 바랍니다.

3. 질문 1 — 우리 데이터와 사용자 권한은 어디서 어떤 기준으로 통제됩니까

가장 먼저 물어야 할 질문입니다. RAG에서 권한 사고는 화면이 아니라 그 앞 단계에서 납니다. 사용자가 볼 수 없는 문서라도 그 내용이 AI에 전달되면, 요약이나 추론을 거쳐 답변에 섞여 나올 수 있습니다.

판정 기준은 "검색 전이냐 후냐"가 아닙니다. 권한 없는 내용이 모델 입력에 들어가기 전에 차단되는가입니다. 검색 후보를 가져온 뒤라도 모델에 전달하기 전에 원본 권한을 판정해 걸러낸다면 안전한 설계일 수 있습니다. 반대로 모델이 이미 읽은 뒤 화면에서만 숨기는 방식은 위험합니다.

권한과 함께 데이터가 어디에 머무는지도 같은 질문에서 확인해야 합니다. 규제 업종이라면 이쪽이 권한보다 먼저 걸리는 조건일 수 있습니다.

받아야 할 증거

• 문서·질문·답변·로그의 저장 위치와 보존 기간, 삭제 요청 시 처리 절차
• 외부 모델 사업자와 재위탁 사업자 목록, 우리 데이터가 모델 학습에 쓰이는지 여부
• 권한 설계서와 권한 시험 결과, 암호화·관리자 접근·감사 로그 정책
• 보안 사고 발생 시 통지 시점과 책임 범위

확인 방법과 단계

• 1차 미팅 — 저장 위치와 재위탁 관계, 학습 이용 여부를 문서로 요청
• 기술 데모 — 권한이 다른 시험 계정 두 개로 같은 질문을 던져 결과가 갈리는지 확인. 계정 발급과 권한 연동이 사전에 준비돼야 합니다
• PoC 인수 — 권한을 회수한 뒤 반영 시점을 측정하고, 제한된 문서가 모델 호출 전에 제외됐음을 보여주는 익명화된 요청 추적 기록을 확인. 화면 결과만으로는 차단 지점까지 증명되지 않습니다

좋은 신호 — 권한을 검색이나 전달 단계의 조건으로 설명하고, 권한 회수 반영 시점을 시간 단위로 말합니다. 데이터 위치와 재위탁 관계를 묻지 않아도 먼저 문서로 제시합니다.

위험 신호 — "화면에서 막습니다", "프롬프트로 답하지 말라고 지시합니다"에 머무는 경우입니다. 저장 위치나 재위탁 사업자를 즉답하지 못하는 것도 확인이 더 필요하다는 뜻입니다.

설계 관점의 상세는 멀티테넌트 RAG 보안에 정리해 두었습니다.

4. 질문 2 — 우리 문서에서 무엇이 얼마나 추출되고 바뀌면 언제 반영됩니까

RAG 실패는 검색 이전, 문서를 읽어 들이는 단계에서 시작되기도 합니다. 스캔 PDF, 표, 이미지 안의 글자, 오래된 포맷, 첨부파일은 일부 내용이 누락된 채 색인될 수 있습니다. 그 다음 문제가 갱신입니다. 폐기된 규정이나 지난 분기 가격표가 계속 인용되는 것은 원본은 지웠는데 색인에 남아 있기 때문입니다.

받아야 할 증거

• 우리 문서 표본에 대한 추출 결과 — 텍스트·표·페이지 위치가 얼마나 보존되는지
• 갱신 주기와 계약상 반영 목표 시간, 갱신 작업 로그
• 삭제 요청이 색인까지 전파되는 절차

확인 방법과 단계

• 1차 미팅 — 갱신 주기와 반영 목표 시간을 숫자로 요청
• 기술 데모 — 우리 쪽 문서 표본 5~10건(스캔본과 표 포함)의 추출 결과를 확인. 비밀유지 계약과 표본 사전 전달이 필요합니다
• PoC 인수 — 문서 1건을 수정하고 1건을 삭제한 뒤 반영까지 걸리는 시간을 실측. 갱신 주기가 하루 단위라면 시험도 그만큼 걸립니다

좋은 신호 — 갱신 주기를 숫자로 말하고, 같은 문서를 다시 넣어도 조각이 중복 생성되지 않는 구조를 설명합니다. 우리 문서 표본으로 시험해 보자는 제안을 반깁니다.

위험 신호 — 추출 품질을 문서 종류와 무관하게 단정하거나, 삭제가 색인에 전파되지 않는 경우입니다. 갱신 방식이 전체 재색인이라는 것 자체는 문제가 아닙니다. 문서가 적고 변경이 드물거나 새 색인을 만들어 교체하는 구조라면 합리적인 선택일 수 있습니다. 확인할 것은 문서량이 늘어난 뒤에도 그 주기를 지킬 수 있는가입니다.

중복과 갱신 처리 방식은 RAG 운영 설계: 멱등 인덱싱에서 다뤘습니다.

5. 질문 3 — 답변의 근거를 어디까지 되짚을 수 있습니까

출처는 신뢰의 문제이자 책임의 문제입니다. 답이 틀렸을 때 어디서 왔는지 확인할 수 없으면 원인을 고칠 수 없고, 담당자는 그 답을 업무에 쓰기 어렵습니다.

받아야 할 증거

• 출처 표기 방식과, 문서 형식별로 어느 수준까지 위치를 특정할 수 있는지

확인 방법과 단계

• 1차 미팅 — 문서 형식별로 어느 수준까지 위치를 특정하는지 설명하게 요청
• 기술 데모 — 무작위 답변 5~10건의 출처 링크를 눌러 실제로 그 대목이 나오는지 확인합니다. 시연 화면만 있으면 되므로 여덟 질문 중 가장 적은 준비로 확인할 수 있는 항목입니다

좋은 신호 — 문서 형식에 맞는 재현 가능한 위치를 제시합니다. PDF는 페이지와 절, 스프레드시트는 시트와 셀, 메일과 게시판은 원문 링크와 작성 시점입니다. 근거를 찾지 못했을 때 출처 없이 답하지 않는다는 점도 함께 말합니다.

위험 신호 — 문서 제목만 보여주거나, 출처가 실제 근거와 무관하게 붙는 경우입니다.

6. 질문 4 — 정확도를 무엇으로 재고 바꾼 뒤 어떻게 다시 검증합니까

"정확도 90퍼센트"는 그 자체로는 판단 근거가 되지 못합니다. 무엇을 세었는지가 빠져 있기 때문입니다.

받아야 할 증거

• 평가 질문의 구성 방식과 개수, 오류 유형별 결과, 실패 사례
• 프롬프트나 모델을 바꾼 전후 비교 보고서

확인 방법과 단계

• 1차 미팅 — 측정 방법과 평가 질문 구성 방식을 설명하게 요청
• 기술 데모 — 우리가 만든 질문 10건 정도를 던져 결과와 근거를 함께 확인합니다. 이건 큰 문제가 있는지 훑는 점검이지 정확도 판정이 아닙니다
• PoC 인수 — 정답과 채점 기준을 갖춘 평가 세트로 판정합니다. 현업 판정자가 필요합니다

좋은 신호 — 검색이 올바른 문서를 가져왔는지와 답변이 그 근거에 부합하는지를 나눠 측정합니다. 변경 후 같은 질문 세트로 다시 돌려 이전보다 나빠지지 않았는지 확인한다고 설명합니다.

위험 신호 — 측정 방법 없이 숫자만 제시하는 경우입니다.

한 가지 계약 조건을 미리 정해 두십시오. 업체의 기존 벤치마크나 평가 도구까지 우리 소유가 될 필요는 없지만, 이 프로젝트의 인수용 질문·정답·채점 기준·결과·버전 이력은 우리가 열람하고 반출하고 재사용할 수 있어야 합니다. 업체를 바꿔도 같은 기준으로 비교할 수 있어야 하기 때문입니다.

7. 질문 5 — 실패와 장애에 어떤 동작과 복구 책임을 약속합니까

운영 전에 반드시 대비해야 하는 상황입니다. 근거를 못 찾았을 때와 시스템이 멈췄을 때를 나눠 물어야 합니다.

받아야 할 증거

• 근거 부족·검색 실패·모델 시간 초과 각각에 대한 응답 정책
• 장애 감지와 알림 방식, 응답·복구 목표 시간, 담당자와 연락 체계
• 장애 보고서 양식과 재발 방지 절차, 모델·프롬프트·색인 변경 후 재검증 책임

확인 방법과 단계

• 1차 미팅 — 근거 부족·검색 실패·시간 초과 각각에 대한 응답 정책을 설명하게 요청
• 기술 데모 — 문서에 없는 내용을 묻는 질문을 실제로 던져 근거 부족 시 동작을 확인
• PoC 인수 — 검색 실패, 모델 시간 초과, 서비스 중단을 각각 재현해 대체 동작과 복구 시간을 측정합니다. 장애 주입은 업체와 합의한 격리된 PoC 환경에서 수행합니다

좋은 신호 — 업무 위험에 맞는 대체 동작을 구분해 설명합니다. 규정 해석처럼 위험이 큰 질문에는 근거 없이 답하지 않고, 단순 검색에는 질문 재확인이나 관련 문서 제시로 이어가는 식입니다. 복구 책임과 목표 시간을 숫자로 말합니다.

위험 신호 — 위험도와 무관하게 "그래도 답은 나옵니다"로 일관하거나, 장애 시 연락 체계와 복구 책임이 계약에 없는 경우입니다.

8. 질문 6 — 운영 비용은 무엇에 비례해 늘어납니까

계약 시점의 월 비용보다 증가 곡선이 중요합니다.

받아야 할 증거

• 낮음·예상·높음 세 가지 시나리오의 운영비 추정과 각 시나리오의 가정
• 단가 기준과 초과 시 과금 조건

확인 방법과 단계

• 1차 미팅 — 우리 쪽 기준값(문서 건수, 월 변경률, 월 질문 수, 동시 사용자)을 먼저 제시하고 같은 조건으로 계산해 달라고 요청합니다. 기준값 없이 받은 견적은 업체끼리 비교할 수 없습니다

좋은 신호 — 비용을 문서량에 비례하는 것, 사용량에 비례하는 것, 고정비로 나눠 설명하고 각각의 증가 조건을 말합니다.

위험 신호 — 월 정액 하나만 제시하고 초과 조건을 말하지 않는 경우입니다. 문서가 자주 바뀌는 조직이라면 재색인 관련 비용이 예상보다 커질 수 있으므로, 제안서에 그 항목이 있는지 확인하십시오.

견적을 구성하는 항목 전반과 시나리오 작성법은 AI 프로젝트 견적 10개 산정 항목에서 다뤘습니다.

9. 질문 7 — 인수 기준과 PoC 종료 조건을 계약서에 어떻게 씁니까

"만족스러울 때까지"는 인수 기준이 아닙니다. 분쟁의 씨앗입니다.

받아야 할 증거

• 측정 공식·시험 데이터·재시험 조건·미달 시 조치를 포함한 계약 문안 초안

확인 방법과 단계

• 1차 미팅 — "이 프로젝트의 인수 기준 문장을 지금 세 개만 제안해 주십시오"라고 요청합니다. 시험이라기보다 업체의 계약 설계 경험을 보는 질문입니다

좋은 신호 — 측정 가능한 문장을 먼저 제안합니다. "우리가 제공한 평가 질문에 대해 근거 문서 적중률 X 이상", "권한 시험 케이스 전건 통과", "문서 갱신 후 Y시간 이내 반영" 같은 형태입니다.

위험 신호 — 인수 기준을 발주자가 알아서 정하라고 미루거나, 정성 표현만 쓰는 경우입니다.

PoC 계약에는 다음 다섯 가지를 넣어 두십시오. 평가 질문 세트는 발주자가 제공하고 결과에 대한 재사용 권리를 확보한다, 권한 시험 케이스를 포함하고 전건 통과를 조건으로 한다, 문서 갱신과 삭제 반영을 시험 항목에 넣는다, 근거를 찾지 못한 경우의 동작을 명시한다, PoC 결과가 기준에 미달했을 때 중단·축소·재산정 중 무엇을 하는지 정한다. 마지막 항목이 없으면 PoC가 형식적인 통과 의례가 됩니다.

PoC가 운영으로 넘어가지 못하는 전형적인 원인은 AI PoC가 운영 단계에서 멈추는 이유에 정리했습니다.

10. 질문 8 — 우리 팀이 이어받으려면 무엇이 필요합니까

계약이 끝나도 시스템은 남습니다. 이관 조건을 처음에 정하지 않으면 선택지가 줄어듭니다.

받아야 할 증거

• 산출물 목록 — 소스 코드, 색인 파이프라인 구성, 평가 세트와 결과, 운영 문서, 장애 대응 절차
• 사용 중인 모델·검색 엔진·저장소의 교체 시 영향 범위, 라이선스와 계정 이전 조건

확인 방법과 단계

• 1차 미팅 — "새 환경에 배포한다면 무엇이 필요하고 며칠 걸립니까"를 단계로 설명하게 요청
• PoC 인수 — 별도 환경 배포 리허설과 데이터 반출을 실제로 수행해 봅니다

좋은 신호 — 산출물을 구체적으로 나열하고, 특정 제품을 바꾸려면 무엇을 다시 만들어야 하는지 설명합니다.

위험 신호 — "저희가 계속 운영해 드립니다"만 반복하는 경우입니다. 위탁 운영 자체는 문제가 아니지만, 이관이 불가능한 구조인지 선택하지 않은 것인지는 구분해야 합니다.

11. 업체가 제시한 구축 사례를 검증하는 여섯 가지

업체가 제시하는 구축 사례는 성공한 장면 중심으로 제시되기 쉽습니다. 사례를 들을 때는 다음 여섯 가지를 물어보십시오.

1. 데모나 PoC입니까, 지금 운영 중입니까 — 가장 먼저 갈리는 지점입니다
2. 운영 기간과 실제 사용자 범위는 어떻게 됩니까 — 전사 배포인지 한 부서 시범인지
3. 문서 형식과 권한 구조가 우리와 얼마나 비슷합니까 — 문서 건수와 함께 난이도를 좌우하는 조건입니다
4. 적용 전후 지표와 측정 방법이 있습니까 — 체감 개선만 있다면 객관적인 전후 비교 근거로는 부족합니다
5. 장애나 품질 저하 사례도 설명할 수 있습니까 — 문제를 겪고 고친 이야기가 있는 쪽이 확인할 근거가 많습니다
6. 익명화된 인수 보고서나 고객 확인 같은 증빙이 가능합니까 — 실명 공개 없이도 제출할 수 있는 형태입니다

고객사 실명을 밝히기 어려운 것은 흔한 일입니다. 다만 실명을 못 밝히는 것과 내용을 설명하지 못하는 것은 다릅니다. 익명화한 상태에서 답할 수 있는 항목이 하나도 없다면 확인이 더 필요합니다. 반대로 재식별 위험이나 고객 계약 때문에 일부 항목만 답하지 못하는 것은 실패가 아니라 대체 증빙이나 미평가로 처리하는 편이 공정합니다.

12. 판정표와 증빙 통과 기준

업체 비교는 기억이 아니라 기록으로 해야 합니다. 1차 미팅에서 표 작성을 시작하고, 기술 데모와 PoC 인수가 끝날 때마다 결과를 갱신하십시오.

#	질문	업체 답변	제출 증빙	확인 단계와 결과	계약 반영	판정
1	데이터·권한		설계서·시험 결과·위탁 목록	데모: 계정 2개 / 인수: 요청 추적
2	추출·갱신		표본 추출 결과·갱신 로그	데모: 표본 추출 / 인수: 반영 시간
3	근거		형식별 출처 표기 기준	미팅: 출처 링크 확인
4	평가		오류 유형별 결과·변경 전후 비교	데모: 간이 점검 / 인수: 채점
5	실패·장애		응답 정책·복구 목표 시간	미팅: 근거 부족 / 인수: 장애 주입
6	비용		세 시나리오·단가·초과 조건	미팅: 동일 기준값 계산
7	인수·PoC		계약 문안 초안	미팅: 기준 문장 3개 요청
8	이관		산출물 목록·교체 영향 범위	미팅: 절차 설명 / 인수: 배포 리허설

판정은 통과·조건부·실패·미평가 네 가지로 두십시오.

증빙이 갖춰야 할 조건

증빙 열이 채워졌다고 통과가 아닙니다. 오래된 범용 정책서나 다른 제품의 시험 결과로도 칸은 채워집니다. 통과로 인정할 증빙은 아래를 만족해야 합니다.

• 이번 제안 대상 제품과 구성에 해당할 것 — 다른 고객사 구축물의 자료가 아닐 것
• 적용 범위·버전·작성일 또는 시험일이 식별될 것
• 가능하면 원시 로그나 재현 절차가 함께 있을 것
• 참고 자료인지 계약상 약속인지 구분될 것 — 제안서 문구와 계약 문안은 다릅니다

증빙이 이 조건에 미달하면 조건부로 두고, 어떤 자료를 언제까지 보완할지 함께 적으십시오.

제안서에서 미리 확인할 것

• 아키텍처 그림에 사용자 권한이 표시되어 있는가
• 갱신과 재색인이 운영 일정에 들어 있는가
• 정확도 숫자에 측정 방법이 붙어 있는가
• 모델 이름이 아키텍처 설명 자리를 대신하고 있지 않은가
• PoC 기준 미달 시 중단·축소·재산정 조건이 있는가

가중치는 조직마다 다르게 잡는다

규제 업종이라면 데이터 처리 위치와 삭제가, 고객 응대 시스템이라면 최신성과 가용성이 차단 기준일 수 있습니다. 우리 조직에서 한 번이라도 어긋나면 안 되는 항목을 두세 개 먼저 정하고, 그 항목은 다른 점수로 상쇄하지 않는다고 규칙을 세워 두십시오.

13. 마무리

RAG 구축 업체 선정에서 흔한 실패는 나쁜 업체를 고르는 것이 아니라, 시연에서 확인할 수 없는 항목을 확인하지 않고 계약하는 것입니다. 여덟 질문과 각 질문의 증빙·확인 단계는 계약 전에 확인 일정과 합격 기준을 확정하고, 기술 데모와 PoC 인수에서 실제 결과를 검증하기 위한 도구입니다.

한 번에 다 볼 수는 없습니다. 1차 미팅에서 볼 것, 데모에서 볼 것, PoC에서 볼 것을 나눠 두고, 지금 확인하지 못한 항목은 미평가로 남겨 계약 문구에 반영하십시오.

답이 막힘없이 나오는지보다 조건과 한계를 함께 말하는지를 보십시오. "이 조건에서는 이렇게 하고, 이런 경우에는 이런 제약이 있습니다"라는 답변은 검증할 근거가 더 많습니다.

받은 RAG 제안서에서 빠진 범위와 인수 조건을 확인하고 싶다면, 조직의 문서·권한·운영 조건에 맞춰 여덟 질문과 판정표를 함께 정리할 수 있습니다.
크몽에서 RAG 구축 제안서·인수 기준 상담하기

함께 읽으면 좋은 글: 멀티테넌트 RAG 보안, AI Agent 도입 준비도 진단.

14. 참고 자료

• OWASP Top 10 for LLM Applications · 업체에게 물어야 할 보안 항목의 출처. 특히 Prompt Injection과 민감정보 노출
• Azure Architecture — RAG solution design and evaluation guide · 평가 지표와 설계 결정 목록. 데모와 운영의 차이를 항목으로 확인할 때
• NIST AI Risk Management Framework · 위험을 식별·측정·관리로 나누는 용어. 계약서의 책임 범위를 쓸 때