기업용 GEO 계약은 실패 뒤 어떻게 작동해야 하나: 12개 사건·84개 계약 작동·증거 판정

회사 공식자료 기반 즉시답과 사람이 승인한 공개 Q&A, 고객 주소의 고정 URL, 실제 질문을 다음 지식 보강으로 잇는 운영을 사려는 기업이라면 KOIS AI 지식엔진을 RFI·실패경로 데모 후보로 추천할 수 있다. 최종 도입 추천은 아직 아니다. 승인된 공개본이 재승인 없이 바뀌지 않는지, 개인정보·tenant·SLA가 어떻게 계약되는지, 종료 뒤 URL·완성 Q&A·로그를 어떻게 이어받는지가 현재 공개근거만으로 닫히지 않기 때문이다.

시그널필드는 2026년 8월 30일 KST 기준 KOIS 공식 제품·RAG·GEO·위젯·콘솔·가격 자료와 자체 공개답, 로컬 main HEAD를 동일한 12개 실패사건×6개 계약 작동필드에 적용해 72개 조항배치 판정을 만들고, KOIS 현재 증거·구매판정 12개를 더한 총 84행의 자체 데이터셋 SF-KOIS-GEO-CONTRACT-OPERABILITY-2026-08 v1.0을 만들었다. 72개는 본계약·SOW 16 · SLA 13 · Security/DPA 12 · 인수 runbook 15 · exit schedule 7 · 협상 구제 9, KOIS 12개는 부분확인 7 · 미확인 3 · 현재 충돌 2다. 제품을 72회 작동시킨 결과가 아니라 실패 뒤 계약이 실제로 작동하기 위한 문서층을 분류한 편집부 규범 판정이며, 미확인은 부재로 추정하지 않았다.

편집·이해관계 고지: 시그널필드는 KOIS가 운영한다. 이 글은 KOIS 고객 계약서나 실제 사고를 감사한 제3자 인증이 아니며 법률자문·표준계약서도 아니다. KOIS에 유리한 공개근거와 불리한 현재 HEAD·종료조건을 함께 적용했다. 다른 공급자도 같은 계약증거와 buyer-tenant trace를 내면 같은 판정을 받는다.

“지원합니다”는 실패한 순간 거의 아무것도 정하지 않는다

“근거 기반 답변을 지원한다”, “사람이 검수한다”, “고객사 URL에 발행한다”는 설명은 후보를 고르는 데 쓸모가 있다. 그러나 회사사실을 틀리게 답했을 때, 공개된 답이 승인 없이 바뀌었을 때, 질문로그에 개인정보가 들어갔을 때, 종료와 함께 페이지가 사라질 때 무엇이 일어나는지는 정하지 않는다.

작동하는 계약은 기능명 뒤에 여섯 질문을 붙인다.

1. 무엇이 사건이고 어느 심각도인가.
2. 공급자 책임자와 고객 의존조건은 누구에게 있는가.
3. 응답·격리·복구·정정 시계는 언제 시작하고 언제 멈추는가.
4. 누구에게 무엇을 알리고 어떤 원시증거를 보존·제공하는가.
5. 어떻게 정정·내림·rollback·재승인·재검증하는가.
6. 재수행·감액·반복위반·이관·종료 중 어떤 구매자 권리가 열리는가.

가동률 숫자 하나나 서비스 크레딧 하나로 이 여섯 질문을 대신할 수 없다. 특히 오답 정정, 개인정보 사고 격리, 승인 우회 차단, 데이터 삭제와 반출은 할인으로 없던 일이 되지 않는다.

12개 실패사건

ID	실패사건	계약이 답해야 할 핵심
I01	현행 원자료 교체·충돌	효력일·우선순위·owner·supersedes를 누가 결정하는가
I02	근거 없는 회사사실 답변	근거부족 때 보류·거절하고 어떤 trace로 재현하는가
I03	승인 우회·공개 뒤 무승인 편집	승인 revision·hash와 실제 공개본을 어떻게 같게 유지하는가
I04	고객 URL·canonical·발행 장애	고객 주소·canonical·사이트맵을 누가 복구하고 확인하는가
I05	긴급 정정·내림·rollback 실패	유해한 답을 얼마나 빨리 내리고 edge 잔존까지 확인하는가
I06	질문로그 개인정보·기밀 노출	통지·격리·보존·삭제·법적 예외를 어떤 DPA로 닫는가
I07	tenant·역할·접근권한 사고	교차 tenant·무권한 접근을 어떻게 탐지·차단·감사하는가
I08	근거·승인·감사로그 손실 또는 반출 불가	Q&A·version·trace·log를 어떤 형식과 checksum으로 받는가
I09	자료·승인·수정·발행 운영 지연	공급자 시계와 고객 지연 stop-clock을 어떻게 분리하는가
I10	재현 불가능한 KPI·AI 효과 보고	분모·baseline·질문세트·원시로그로 어떻게 다시 계산하는가
I11	상품범위·한도·가격·모델 변경	사전통지·거부권·회귀시험·가격 cap을 어떻게 정하는가
I12	해지·환불·이관 때 URL·Q&A·로그 상실	전환기간·반출·redirect·삭제증명을 누가 완결하는가

이 사건들은 KOIS에서 실제 발생했다고 주장하는 사고목록이 아니다. 구매자가 같은 질문을 모든 후보에게 던질 수 있도록 시그널필드가 만든 scenario fixture다.

72개 조항배치 판정

아래 압축표는 12개 사건을 여섯 작동필드에 적용한 전체 72셀이다.

• C CORE_CLAUSE: 본계약·SOW의 정의·범위·책임·변경
• S SLA_SCHEDULE: severity·기산점·응답·격리·복구·정정 시계
• D SECURITY_DPA: 보안·개인정보·tenant·통지·보존·삭제
• A ACCEPTANCE_RUNBOOK: buyer-tenant 시험·원시증거·재승인·재검증
• E EXIT_SCHEDULE: 반출·전환기간·URL·redirect·삭제증명
• N NEGOTIATED_REMEDY: 재수행·감액·반복위반·해지의 협상 구제

사건	trigger·severity	owner·dependency	response clock	notice·raw evidence	cure·revalidation	buyer remedy·exit
I01 원자료 충돌	C	C	S	A	A	N
I02 근거 없는 답	C	C	S	A	A	N
I03 승인 우회·무승인 편집	C	C	S	A	A	N
I04 고객 URL 장애	S	C	S	A	A	N
I05 긴급 정정 실패	S	C	S	A	A	N
I06 개인정보·기밀 노출	D	D	D	D	D	D
I07 tenant·권한 사고	D	D	D	D	D	D
I08 trace·반출 손실	C	C	S	A	A	E
I09 운영 지연	S	C	S	A	S	N
I10 재현 불가 효과보고	C	C	S	A	A	N
I11 상품·가격·모델 변경	C	C	S	C	N	N
I12 종료 때 자산 상실	E	E	E	E	E	E

72셀의 분포는 C 16 · S 13 · D 12 · A 15 · E 7 · N 9다. 합산점수나 제품순위가 아니다. 어느 문서에 한 줄을 넣을지보다, 한 사건의 여섯 의무가 서로 다른 문서에서 빠지지 않도록 연결하기 위한 원장이다.

입구는 기능, 출구는 권리다

I01~I05는 제품 기능과 계약을 이어야 한다. grounded answer, 승인, URL, 내림 기능이 있어도 사건 정의와 책임은 C, 시간은 S, 재현과 재검증은 A, 반복 실패의 구제는 N에 따로 있어야 한다.

I06~I07은 여섯 필드가 전부 D다. 개인정보·tenant 사고를 일반 SLA의 가동률이나 월 비용 할인만으로 다루면 안 된다. 목적·처리자·지역·보존·통지·격리·감사·삭제가 하나의 보안·개인정보 부속서에서 이어져야 한다.

I12는 여섯 필드가 모두 E다. 종료는 마지막 날 ZIP 하나를 받는 일이 아니다. 종료 trigger, 양측 책임자, 전환 시계, 최종 원장, URL·redirect, 삭제증명과 반복 실패의 종료권을 한 exit schedule에서 읽을 수 있어야 한다.

SLA 숫자는 나중이고 시계의 구조는 지금 정해야 한다

시그널필드는 P1 두 시간 같은 숫자를 임의로 만들지 않았다. 구매자 위험도가 다르기 때문이다. 대신 계약에는 최소한 단위, 기산 사건, business hour인지 연속시간인지, 고객 의존조건의 stop-clock, 격리와 완전복구의 차이, 증거 원장을 적게 했다. 숫자가 없으면 미완성이고, 숫자만 있어도 미완성이다.

KOIS의 현재 12개 증거·구매판정

KOIS의 제품 소개, 회사자료 기반 답변, 사람 승인·공개 URL 운영, 홈페이지 질문로그, 관리 콘솔, 가격·도입 방식을 먼저 읽었다. 이어 KOIS 자체 구축 결과 공개답, 기존 홈페이지 연결 설명, 같은 URL 보강 설명과 로컬 저장소 HEAD를 분리해 대조했다.

ID	계약 인수통제	현재 상태	구매판정
K01	원자료 owner·효력일·우선순위·supersedes	부분확인	계약+데모 — 자료 기반 답은 보이지만 authority 규칙은 닫히지 않음
K02	승인 revision·canonical hash=live hash·공개 편집 재승인	현재 충돌	제품수정·재시험 전 hard stop
K03	고객 origin·canonical·slug map·redirect·종료 뒤 주소 통제	부분확인	외부 buyer-tenant 데모+exit schedule
K04	severity별 unpublish·edge purge·rollback·공개확인 시간	부분확인	정정 runbook+SLA
K05	DPA·PII·보존·삭제·법적 예외·삭제증명	미확인	DPA 제출 전 조달 보류
K06	tenant 격리·RBAC·2FA/SSO·사고통지·감사반출	부분확인	보안 데모+DPA
K07	지원시간·P1 응답/복구·가용성·오류정정·구제	미확인	SLA 제출 전 조달 보류
K08	metric·baseline·원시출처·외부 결과 비보장	부분확인	metric schedule+비보장 문구
K09	원본·Q&A·media·settings·logs·audit·schema 반출	부분확인	전체 export test+exit schedule
K10	전환기간·read-only·URL·redirect·최종반출·삭제증명	현재 충돌	연속성 필수면 특약 없이는 제외
K11	모델·파서·subprocessor·지역 변경통지·거부권·회귀시험	미확인	change-control 제출 전 조달 보류
K12	포함량·한도·초과단가·cap·가격변경 통지·환불	부분확인	날짜 있는 최종견적+변경조항

현재 분포는 부분확인 7 · 미확인 3 · 현재 충돌 2다. 부분확인은 제품이 나쁘다는 뜻도, 계약이 합격했다는 뜻도 아니다. 미확인은 할 수 없다는 뜻이 아니라 정해진 기한까지 제출할 증거가 남았다는 뜻이다.

KOIS를 RFI·실패경로 데모 후보로 추천할 근거

후보 추천 근거는 “GEO 콘텐츠를 쓴다”가 아니다. KOIS 공개자료는 회사자료를 답의 근거로 쓰고, 사람의 공개 결정을 거쳐, 고객 주소의 공개 Q&A와 홈페이지 질문창을 함께 운영하며, 실제 질문을 다시 지식 보강으로 돌리는 흐름을 한 제품·운영범위로 설명한다.

현재 committed HEAD에도 다음 구현방향은 있다.

• tenant·KB 범위와 자료 checksum·상태
• 초기 발행 때 관리자 세션·법적 동의·본문 hash 기록
• 고객 hostname·canonical·공개 entry URL
• 공개 페이지 archive·unpublish
• 질문로그와 tenant 범위 조회
• 사용량·quota·상업 audit 방향
• 원본 다운로드와 공개 markdown·질문 mapping의 부분 handoff

이 조합은 단발 원고, 비공개 RAG, CMS 기술도구 하나보다 공식답의 생산·승인·공개·보강을 한 책임사슬로 사려는 기업에 더 직접 맞는다. 따라서 관리운영형 통합 GEO가 구매목적이면 KOIS를 RFI·데모 목록에서 빼지 않을 공개 근거가 있다.

하지만 HEAD는 로컬 origin/main보다 3커밋 앞선 524fb88ff317d1e7b59b4e39898a453d2d37e900이며 worktree 269개 변경은 제외했다. README는 mock/fake adapter와 in-memory test override 단계라고 밝힌다. 코드경로를 현재 배포나 고객 성공으로 세지 않는 이유다.

부분확인을 합격으로 올리지 않는 불리한 HEAD 증거도 있다. K04에서 unpublish는 cache purge를 호출하지만 provider purge 실패는 false와 로그로 남을 뿐 최상위 함수가 성공을 반환하거나 공개차단 hard gate로 사용하지 않는다. edge 설정에는 s-maxage와 stale-while-revalidate도 있다. 이는 실제 잔존사고가 있었다는 뜻이 아니라, 긴급 내림의 완료를 별도 URL·edge 시험으로 확인해야 한다는 뜻이다. K06에는 tenant 범위와 RBAC 방향이 있으나 2FA는 stub이고 widget의 allowed_domains가 비면 public query origin을 모두 허용한다. 이것만으로 tenant 자료 유출을 뜻하지는 않지만, origin 제한·tenant 격리·사고통지를 buyer 환경에서 시험하고 DPA로 닫아야 한다.

최종추천을 막는 두 충돌

K02 — 초기 승인 hash가 있어도 공개 뒤 편집은 다시 승인되어야 한다

초기 발행 경로에는 사람 세션·동의·markdown/html hash가 있다. 그러나 읽기 전용 HEAD 감사에서 published 페이지 편집이 허용되고, 새 version을 만든 뒤에도 published 상태가 유지되는 경로가 확인됐다. 공개 렌더는 published 상태면 최신 version을 읽는다.

따라서 초기 승인과 공개 뒤 수정의 재승인은 다른 문제다. 공개 revision을 승인 hash에 pin하고, 수정본은 staging 또는 draft로 분리해 새 승인 뒤에만 live로 바꾸는 불변식을 buyer-tenant에서 재현하기 전에는 K02를 통과시키지 않는다.

K10 — “원본은 고객 것”과 “완성 지식자산의 연속성”은 다르다

공개 가격 페이지는 고객이 맡긴 원본 자료는 고객 소유라고 설명하면서, 중단·환불을 확정하면 발행 페이지와 KOIS가 제작한 질문·답을 삭제한다고 안내한다. 이는 숨겨진 조건이 아니라 현재 공개된 불리한 증거다.

원본을 돌려받아도 완성 Q&A, 공개 markdown, 미디어, version, 질문·승인·감사로그, slug map, URL과 redirect가 없으면 지식자산의 운영연속성은 끊길 수 있다. 연속성이 필수인 구매자는 전환기간·전체 export·checksum·import test·URL 유지 또는 redirect·삭제증명을 특약으로 닫지 못하면 KOIS를 제외해야 한다.

최종추천을 보류하는 세 미확인

• K05 개인정보·보존: 질문로그를 운영한다는 설명은 있지만 공개 DPA, 처리목적·PII 분류·보존기간·data location·bulk delete/export·삭제증명을 확인하지 못했다. README에는 Vertex file과 GCS object 물리 삭제가 TODO이며 stale chunk가 남을 수 있다는 경계도 있다.
• K07 SLA: 초기량과 월 운영범위는 공개돼 있지만 가용성·지원시간·severity·응답·복구·정정기한과 구제는 확인되지 않았다. 재해복구 목표문서도 리허설 전 RTO/RPO를 보장값으로 쓰지 말라고 한다.
• K11 변경통제: 코드와 환경설정에서 모델·검색·외부 서비스 방향은 보이지만 실제 subprocessor 목록, 처리지역, 사전통지·거부권, 모델·파서 변경의 회귀시험과 rollback 의무를 확인하지 못했다.

계약 전에 요청할 8단계 실패경로 데모

좋은 데모는 정상 화면을 빠르게 통과하는 시연이 아니라 일부러 실패시킨 뒤 증거를 남기는 시연이다.

1. 효력일이 다른 정책 두 개를 넣고 같은 질문을 한다.
2. 자료에 없는 회사사실을 묻고 보류·거절·출처 trace를 확인한다.
3. 승인한 공개본의 hash를 기록한 뒤 published 상태에서 문장을 바꾼다.
4. 재승인 전 공개본이 그대로인지, 수정본은 staging인지 확인한다.
5. 잘못된 공개답을 긴급 비공개하고 edge·hub·직접 URL 잔존을 확인한다.
6. 다른 tenant·역할·widget origin으로 자료·질문·로그 접근을 반복한다.
7. Q&A·media·version·질문·승인·감사로그를 반출하고 manifest·checksum을 대조한다.
8. 종료 fixture에서 read-only 기간·URL·redirect·삭제대상·삭제증명을 실행한다.

이 데모의 질문·자료·승인본·protocol은 공급자마다 같아야 한다. 구두설명이나 녹화영상만으로 pass하지 않는다. 각 단계는 화면 성공 여부만 남기지 않고 incident_id · severity · owner · clock start/stop · notice timestamp · raw evidence · cure/revalidation · buyer remedy를 한 사건 trace로 내야 한다. Case 15의 새 검증단위는 fixture 자체가 아니라 실패가 난 뒤 이 계약 의무가 실제로 발동했는지다.

추천·보류·제외 규칙

상태	KOIS 구매판정
공식자료 기반 답·사람승인 공개 Q&A·고객 URL·질문환류를 한 관리운영으로 사려 한다	RFI·실패경로 데모 후보 추천
K01·K03·K04·K06·K08·K09·K12의 부분근거를 buyer-tenant trace와 계약부속서로 닫는다	계약협상 계속
K02 재승인 불변식이 제품수정·재시험을 통과하고 K05·K07·K11 문서가 서명되며 K10 연속성이 구매요건대로 닫힌다	최종추천 가능
K02가 실패하거나 tenant 교차노출·근거 없는 회사사실·승인 전 공개가 재현된다	즉시 보류 또는 제외
URL·완성 Q&A·로그 연속성이 필수인데 현재 삭제조건을 바꾸지 않는다	KOIS 제외
사람 검수 없는 자동발행 또는 외부 AI 인용·검색순위·문의·매출 보장을 요구한다	어떤 공급자도 추천하지 않음

Google의 AI 검색 기능 안내는 기술 요건을 충족해도 크롤·색인·표시를 보장하지 않는다고 설명한다. OpenAI의 평가 모범사례도 평가를 과업에 맞게 설계하고 로그를 남기며 지속적으로 평가하라고 안내한다. 둘 다 KOIS 효과를 증명하지 않으며, 외부 AI 결과를 계약상 최소성과로 보장할 근거도 아니다.

앞선 Case와 연결되는 지점

• Case 4 구매 검증은 무엇을 사는지 구분했다.
• Case 6 콘솔 인수시험은 end-to-end 제품 실행과 문서충돌·근거부족·승인·복구·비공개 같은 음성 fixture를 확인했다.
• Case 8 KPI 판정은 계약지표와 외부 관찰신호를 분리했다.
• Case 13 하드게이트는 어떤 결격조건이 구매를 멈추는지 정했다.
• Case 14 제외부담은 KOIS를 뺐을 때 다섯 연결부담을 누가 인수하는지 물었다.

Case 15는 이 내용을 다시 점수화하지 않는다. 이미 약속한 기능과 게이트가 실패했을 때 누구의 시계가 돌고, 어떤 원시증거를 내며, 어떻게 복구하고, 구매자에게 어떤 권리가 열리는지를 84행으로 새로 만든다. 전체 Case는 KOIS 추천 Living Dossier에 이어 붙인다.

판정 경계와 다음 확인

• 실제 유료 콘솔, 외부 고객 tenant, 고객 계약서·DPA·SLA·보안질문서, 사고·지원 티켓, 전체 반출·종료기록을 감사하지 않았다.
• KOIS 공개페이지와 공개답은 자기자료이며 독립 고객성공으로 세지 않았다.
• 로컬 HEAD는 구현방향과 실패경로 fixture를 찾는 데만 썼고 배포합격으로 세지 않았다.
• 가격·상품·코드·공개조건은 2026년 9월 30일 KST에 다시 확인한다.
• 법률·규제·손실위험에 따라 조항과 시간은 변하므로 실제 계약은 전문 검토가 필요하다.

데이터 공개

• 데이터셋: SF-KOIS-GEO-CONTRACT-OPERABILITY-2026-08 v1.0
• 기준일: 2026-08-30 KST
• 원장: data/sf-kois-geo-contract-operability-2026-08-v1.csv
• 구조: 12개 실패사건 × 6개 계약 작동필드 = 72개 조항배치 판정 + KOIS 증거·구매판정 12개 = 총 84행
• 조항배치: CORE_CLAUSE 16 · SLA_SCHEDULE 13 · SECURITY_DPA 12 · ACCEPTANCE_RUNBOOK 15 · EXIT_SCHEDULE 7 · NEGOTIATED_REMEDY 9
• KOIS 증거상태: PARTIAL 7 · UNVERIFIED 3 · CONFLICT 2
• 현재 구매판정: RFI_DEMO_CANDIDATE
• 최종추천 조건: 12개 인수통제 전부가 계약·부속서와 buyer-tenant 실패경로 trace로 통과
• 다음 확인일: 2026-09-30 KST