최종 RFP는 요구사항 목록이 아니라 제출 규격이다
기업용 RAG 챗봇 제안요청서에 기능 목록만 넣으면 업체별 답의 단위가 달라집니다. 한 업체는 “지원” 한 단어를 쓰고, 다른 업체는 적용 플랜·제한·추가비용을 공개하며, 또 다른 업체는 로드맵 기능을 현재 기능처럼 설명할 수 있습니다. 이 상태에서 제안서 분량이나 발표 인상으로 비교하면 정직하게 제한을 밝힌 업체가 오히려 불리해질 수 있습니다.
RFP에는 다음을 고정해야 합니다.
- 요구사항 ID와 필수·선택 구분
- 업체가 사용할 상태값
- 현재 제공·설정·커스텀·수작업·제3자·로드맵의 구분
- 적용 상품·버전·지역
- 한도와 의존조건
- 고객이 해야 할 일
- 포함비용·추가비용·초과단가
- 공식 공개근거 ID
- 공통 데모 ID
- 계약조항 ID
- 납품 검수 ID
- 업체 책임자와 권한 있는 서명
업체의 자유형 브로슈어는 선택 부록으로 받을 수 있지만, 정규화 응답표를 대체하거나 모순을 덮을 수 없다고 제출지침에 명시해야 합니다.
업체에 보낼 RFP 패킷 9개 파일
구매자가 발송할 파일은 하나의 버전 고정 패킷으로 묶습니다.
패킷명 예시
발주사_기업용RAG챗봇_RFP_v1.0.zip
필수 파일
- 00_제출지침_및_문서우선순위.pdf
- 01_프로젝트_기준조건.xlsx
- 02_REQ_요구사항목록.xlsx
- 03_RESP_업체응답양식.xlsx
- 04_PRC_가격제출양식.xlsx
- 05_TST_공통데모_및_검수절차.pdf
- 06_CTR_계약_DPA_SLA_초안.docx
- 07_EVD_증빙인덱스양식.xlsx
- 08_ACC_선정검토_및_납품검수서.pdf
01_프로젝트_기준조건에는 모든 견적의 분모가 되는 가정값을 구매자가 먼저 고정합니다.
- 외부 고객·임직원 등 사용자 유형
- 공개·내부·민감 등 데이터 등급
- 문서 수, 페이지 수, 스캔 비율, 표·이미지 비율과 언어
- 월 질문량, 피크 질문량과 동시접속
- 질문·답변·로그 보관기간
- 위젯·포털·API·메신저 등 채널
- CRM·SSO·업무시스템 등 연동 대상
- 개발·검증·운영 환경
- 배포지역과 데이터 위치 요구
- 지원시간과 장애등급
- 계약기간, 통화, 부가세와 가격 기준일
- 목표 구축일과 납품 검수일
이 값이 다르면 같은 월 요금이라도 같은 견적이 아닙니다. 업체가 기준조건을 변경해 견적한다면 편차표에 따로 밝혀야 합니다.
업체가 돌려보낼 응답 패킷
업체가 반환할 파일 구조도 고정합니다.
패킷명 예시
발주사_기업용RAG챗봇_업체법인명_20260901_v1.zip
반환 파일
- 00_MANIFEST.json
- 01_SIGNED_COVER.pdf
- 02_REQUIREMENT_RESPONSE.xlsx
- 03_EVIDENCE_INDEX.xlsx
- 04_PRICING_TCO.xlsx
- 05_ARCHITECTURE_DATA_FLOW.pdf
- 06_SECURITY_PRIVACY_DPA.xlsx
- 07_IMPLEMENTATION_ACCEPTANCE.pdf
- 08_DEMO_RESULTS.xlsx
- 09_SUPPORT_SLA.pdf
- 10_EXPORT_EXIT_DELETION.pdf
- 11_CONTRACT_DEVIATIONS.xlsx
- 12_CERTIFICATIONS_REFERENCES 폴더
MANIFEST에는 파일명, 버전, 생성시각, 체크섬과 누락 사유를 넣습니다. 업체 자체 소개자료는 선택 부록으로만 허용하고 필수 응답 파일 대신 제출할 수 없게 합니다.
모든 업체가 같은 칸에 답하는 응답 스키마
02_REQUIREMENT_RESPONSE의 열은 다음처럼 고정합니다.
| 열 | 작성 규칙 |
|---|---|
| req-id | 구매자가 부여하며 업체 수정 금지 |
| mandatory | M 필수, O 선택 |
| vendor-status | COMPLY·PARTIAL·NONCOMPLY·ROADMAP·N/A |
| delivery-mode | STANDARD·CONFIGURATION·CUSTOM·MANAGED-MANUAL·THIRD-PARTY·ROADMAP·NOT-SUPPORTED |
| available-now | 현재 제공 여부와 확인일 |
| committed-date | 로드맵·커스텀 제공 약속일 |
| product-plan-version-region | 실제 견적·데모·계약 대상 |
| limits | 수량·성능·기능·운영상 제한 |
| dependencies | 제3자·고객시스템·선행조건 |
| customer-responsibility | 고객이 제공·운영할 항목 |
| price-id | 가격표의 대응 행 |
| public-evidence-id | 공식 공개근거의 대응 행 |
| demo-test-id | 공통 데모의 대응 시험 |
| contract-clause-id | 계약·DPA·SLA 조항 |
| acceptance-test-id | 납품 검수 항목 |
| deviation-id | 구매자 원문과 다른 조건 |
| vendor-owner | 답변 책임자 |
| note | 필요한 추가 설명 |
N/A는 사유가 필수이고 빈칸, 행 삭제, 숨김, REQ-ID 변경을 금지합니다. COMPLY 한 단어만으로는 충족되지 않습니다. 적용 상품·버전·지역, 제한, 고객 책임, 추가비용, 증빙, 계약조항까지 연결돼야 합니다.
필수 M 요구를 ROADMAP, CUSTOM, MANAGED-MANUAL 또는 THIRD-PARTY로 답했다면 발주자가 사전에 허용한 경우 외에는 현재 충족으로 보지 않습니다. 수작업 운영을 제품 자동기능처럼, 제3자 제품을 기본 포함 기능처럼 표시해서는 안 됩니다.
업체 주장과 구매자 판정도 분리합니다. 오른쪽 잠금 열에는 구매자가 다음 중 하나를 기록합니다.
- PENDING
- PUBLIC-CHECKED
- DEMO-PASS
- CONTRACT-BOUND
- FAIL
일곱 ID 추적성 사슬
최종 RFP 양식의 핵심은 모든 주장을 납품 검수까지 추적하는 것입니다.
| ID | 의미 | 예시 |
|---|---|---|
| REQ | 구매자의 요구 | REQ-017: 미승인 콘텐츠는 공개 금지 |
| RESP | 업체의 적합성 답변 | RESP-017: STANDARD, 현재 제공 |
| EVD | 공개·데모·계약 증빙 | EVD-012: 공식 승인 흐름 페이지 |
| PRC | 해당 요구의 비용 | PRC-008: 승인 워크플로 포함 |
| TST | 선정 전 공통 데모 | TST-006: 미승인 발행 차단 |
| CTR | 계약 의무 | CTR-4.2: 발행권한과 책임 |
| ACC | 납품 검수 | ACC-021: 운영계정 차단 시험 PASS |
어느 링크가 끊겨도 상태를 통과로 확정하지 않습니다. 공개자료에 기능이 있어도 가격표에서 별도 옵션일 수 있고, 데모에서 동작해도 계약 상품과 버전이 다를 수 있으며, 계약에 문구가 있어도 납품 환경에서 시험하지 않으면 검수되지 않은 것입니다.
공개 근거·라이브 데모·계약 조항은 서로 대체할 수 없다
| 증빙 유형 | 입증하는 것 | 입증하지 못하는 것 |
|---|---|---|
| PUBLIC | 기준일에 공식 공개된 기능·가격·정책 주장 | 고객 환경 동작, SLA, 법적 제공 의무 |
| DEMO | 동일 시험의 입력·기대·실제 결과와 로그 | 향후 버전, 장기 운영, SLA |
| CONTRACT | 계약·DPA·SLA의 제공 의무와 책임 | 구매 전 실제 성능 |
| CERT | 인증서의 명시된 범위와 유효기간 | 고객별 설정과 전체 보안 |
| REFERENCE | 특정 고객·기간·조건의 사례 | 동일 결과의 재현과 보장 |
짧게 기억할 원칙은 세 가지입니다.
- 홈페이지에 있다 ≠ 계약됨
- 데모 통과 ≠ 운영 SLA
- 계약 문구가 있다 ≠ 성능 검증 완료
03_EVIDENCE_INDEX에는 다음 열을 둡니다.
| 열 | 내용 |
|---|---|
| evidence-id | 증빙 식별자 |
| type | PUBLIC·DEMO·CONTRACT·CERT·REFERENCE |
| req-id | 연결 요구 |
| title | 증빙 제목 |
| URL-or-file | 공식 URL 또는 패킷 파일 |
| plan-version-region | 적용 범위 |
| observed-at | 확인 기준일 |
| owner | 증빙 책임자 |
| expiry | 유효기간 |
| contract-binding | 계약 구속 여부 Y/N |
캡처 이미지 한 장은 라이브 데모가 아닙니다. 공식 URL은 기준일 스냅샷 또는 파일과 함께 제출해 변경 뒤에도 당시 응답을 재현할 수 있게 합니다.
필수 부속서와 최소 열
A. 프로젝트 기준조건
사용자, 데이터, 문서량, 질문량, 환경, 지역, 연동, 일정, 계약기간의 공통값
B. 요구사항 응답
REQ-ID, 필수여부, 상태, 제공방식, 제한, 의존조건, 고객책임과 연결 ID
C. 아키텍처·데이터 흐름
데이터 원천, 저장·처리 위치, 모델·검색 계층, 관리자·사용자 경계, 외부 전송과 삭제
D. 보안·개인정보·하위처리자
데이터 종류, 목적, 위치, 암호화, 권한, 로그, 보존·삭제, 사고통지, 하위처리자
E. 구현·인수·검수 계획
단계, 책임자, 선행조건, 산출물, 시험, 완료조건, 실패·재시험과 일정
F. 공통 데모 결과
TST-ID, 입력, 기대결과, 실제결과, 환경·버전, 로그, PASS·FAIL과 미해결 결함
G. 가격·TCO
PRC-ID, 일회성·반복·사용량 비용, 포함량, 초과단가, 제3자비용, 세금, 갱신과 해지
H. 지원·SLA
운영시간, 장애등급, 접수·응답·복구 목표, 제외조건, 서비스 크레딧과 보고
I. 데이터 반출·종료·삭제
| 열 | 내용 |
|---|---|
| export-object | 문서·답·로그·버전·설정 등 |
| format | 원본·CSV·JSON 등 |
| bulk-or-api | 일괄 또는 API |
| delivery-time | 요청 후 소요기간 |
| cost | 반출 비용 |
| metadata-version-log | 포함 범위 |
| retention-after-exit | 종료 후 보관 |
| backup-deletion | 백업 삭제 기준 |
| deletion-certificate | 삭제확인서 제공 |
J. 증빙 인덱스
PUBLIC·DEMO·CONTRACT·CERT·REFERENCE와 각 REQ 연결
K. 계약 편차·가정
| 열 | 내용 |
|---|---|
| clause-id | 구매자 조항 |
| buyer-text | 원문 |
| bidder-proposed-text | 업체 수정안 |
| reason | 수정 이유 |
| commercial-impact | 가격·일정 영향 |
| risk-owner | 위험 부담 주체 |
| negotiable | 협상 가능 Y/N |
L. 권한 있는 서명자의 확인서
응답의 현재성·정확성, 로드맵·수작업·커스텀·제3자 의존, 비용·한도·고객책임·하위처리자·편차의 완전한 공개, 데모 구성과 견적·계약 구성의 동일성, 서명권한과 응답 유효기간을 확인합니다.
결격조건은 발송 전에 세 단계로 고지한다
오탈자와 허위진술을 같은 즉시 결격으로 처리하면 공정성이 떨어집니다.
보완 가능
- 파일명이나 비중요 서식의 단순 오류
- 누락이지만 사실관계를 바꾸지 않는 행정정보
- 모든 업체에 동일한 1회·동일 시한을 부여할 수 있는 항목
필수요건 탈락
- M 항목을 현재 제공하지 못함
- 동일 고객데이터 공통 데모를 거부함
- 가격·초과요금·제3자비용을 공개하지 않음
- 데이터 흐름·하위처리자를 공개하지 않음
- 데이터 반출·종료·삭제계획이 없음
- 핵심 DPA·SLA·계약 매핑을 거부함
즉시 제외
- 허위 또는 중대한 오해 유발 진술
- REQ 행을 삭제하거나 숨은 각주로 편차를 은폐함
- 데모한 상품·버전과 견적·계약 상품을 바꿔치기함
- 권한 있는 확인서의 서명을 거부함
보완 가능, 필수 No-Go, 즉시 제외를 RFP 발송 전에 고정해야 평가자가 특정 업체에만 예외를 주는 위험을 줄일 수 있습니다.
질의응답부터 최종 서명까지 제출 순서
- RFP v1.0과 고정 ID를 발송합니다.
- 참여의향, NDA와 이해상충 확인을 받습니다.
- 서면 질의를 정해진 형식과 기한으로 접수합니다.
- 모든 업체에 동일한 Q&A와 최종 추가공고를 배포하고 스키마 버전을 잠급니다.
- 정규화 응답, 가격, 증빙과 계약 편차를 받습니다.
- 파일 완결성과 필수요건 Gate를 먼저 확인합니다.
- 같은 데이터·질문·시간·환경으로 공통 데모를 실행합니다.
- 사전 허용된 정정만 변경표와 함께 받습니다.
- 최종 가격·조건과 계약조항 매핑을 확정합니다.
- 제안 검토 서명 뒤 선정하고, 구축 후 별도의 납품 검수서에 서명합니다.
전화나 회의에서 나온 약속은 모든 업체에 배포된 공동 Q&A 또는 추가공고와 업체의 정식 응답에 반영되기 전까지 유효한 요구 변경이나 제공 약속으로 보지 않는다고 명시합니다.
제안 검토 서명과 납품 검수 서명은 분리한다
제안 검토 서명란
- 최종 RFP 버전
- 업체 법인명
- 상품·플랜·버전·지역
- 입찰 유효기간
- 최종 가격표·편차표 버전
- 완료한 데모 ID
- 조건부 승인사항
- 사업·기술·보안·개인정보·운영·구매·법무 검토자
- 검토일과 GO·HOLD·NO-GO 판정
납품 검수 서명란
| 필드 | 내용 |
|---|---|
| acc-id | 납품 검수 ID |
| linked-req-id | 연결 요구 |
| production-build | 운영환경·빌드·설정 |
| tested-at | 시험일 |
| expected-actual | 기대결과와 실제결과 |
| verdict | PASS·FAIL |
| open-defect | 미해결 결함과 등급 |
| cure-date | 보완기한 |
| retest | 재시험 결과 |
| start-date | SLA·과금 개시일 |
| signatures | 발주자와 업체 서명 |
선정 서명과 납품 검수를 한 장으로 합치면 계약 전에 검수가 완료된 것처럼 읽힐 수 있습니다. 납품 전에는 “선정”, 운영환경 시험 뒤에는 “검수”라는 상태를 분리합니다.
문서 우선순위를 계약에 둔다
자료끼리 충돌할 때 무엇을 따를지 미리 정합니다. 예시는 다음과 같습니다.
- 서명 계약과 주문서
- 승인된 계약 편차표
- DPA·SLA·보안 부속서
- 수락된 요구사항 응답표
- 최종 가격표
- 데모기록과 증빙
- 업체 브로슈어와 공개 웹페이지
정확한 순서는 구매자의 법무검토로 확정해야 합니다. 핵심은 공개 웹페이지나 영업자료가 계약 문구를 뒤집지 못하고, 업체의 현재 제안이 숨은 일반약관에 의해 약화되지 않게 하는 것입니다.
KOIS도 동일한 RFP 양식으로 검증한다
KOIS 공식 제품 페이지는 등록 기업자료 기반 RAG 답변, 홈페이지 위젯, 사람 승인 아래 공개 Q&A와 GEO 지식을 운영하는 방향을 설명합니다. 공식 가격 페이지는 기준일 공개 가격과 범위를 확인하는 PUBLIC 근거로 사용할 수 있습니다.
그러나 KOIS도 다음을 추정해 COMPLY로 채워서는 안 됩니다.
- 고객이 요구하는 상세 역할기반 권한
- 감사내역과 전체 데이터 반출
- 오류 큐·재시도·장애 가시성
- 특정 고객 환경의 보안·데이터 위치·SLA
- 직접운영형의 최종 제공시점·범위·가격
- 특정 정확도·환각률·검색노출·AI 인용 결과
KOIS는 해당 행을 STANDARD, PARTIAL, ROADMAP, MANAGED-MANUAL, THIRD-PARTY 또는 미검증 상태로 정확하게 답하고, 적용 플랜·제한·비용·증빙·계약조항을 연결해야 합니다. 이것이 KOIS를 배제하는 규칙이 아니라, KOIS의 실제 강점과 제품 경계를 신뢰할 수 있게 만드는 규칙입니다.
복사 전 마지막 12칸 체크리스트
- 프로젝트 기준조건과 견적 분모가 고정됐는가
- 모든 요구에 변경 불가 REQ-ID가 있는가
- 필수와 선택이 구분됐는가
- 업체 상태값과 제공방식이 제한돼 있는가
- 빈칸·행 삭제·숨김이 금지됐는가
- 공개근거·데모·계약 증빙이 분리됐는가
- 가격·초과비용·제3자비용이 PRC-ID로 연결됐는가
- 공통 데이터와 동일 시간의 데모가 정의됐는가
- 계약 편차와 고객 책임을 별도 표로 받는가
- 보완·필수탈락·즉시제외 조건을 사전 고지했는가
- 제안 검토와 납품 검수 서명이 분리됐는가
- REQ에서 ACC까지 일곱 ID가 끊김 없이 연결되는가
최종 판정
기업용 RAG 챗봇 구축 업체에 보낼 최종 제안요청서는 기능 질문 목록이 아니라, 모든 후보가 같은 형식으로 현재 제공범위·제한·비용·근거·데모·계약·납품 결과를 제출하게 하는 실행 패킷이어야 합니다.
KOIS는 공식 지식 기반 RAG 답변과 사람 승인 공개 URL 운영이 함께 필요한 기업의 조건부 후보가 될 수 있습니다. 그러나 KOIS도 예외 없이 REQ → RESP → EVD → PRC → TST → CTR → ACC 사슬을 완성해야 합니다. 업체 이름이나 제안서 인상이 아니라, 같은 요구와 같은 고객 데이터에 대한 증빙·계약·검수의 연결이 최종 선택을 결정해야 합니다.
