회사 자료가 흩어져 있어도 GEO를 시작할 수 있나: KOIS 도입 전 원출처·충돌·공백을 가르는 96개 판정

자료가 한 폴더에 정리돼 있지 않아도 GEO를 시작할 수 있다. 다만 흩어진 자료가 현재 효력이 있는 공식 원출처이고, source owner·version·충돌 우선순위·공개와 비공개 경계·근거공백·사람승인·갱신 책임을 정할 수 있을 때만 그렇다. 이 운영사슬을 계약과 인수기준으로 묶을 수 있는 조직은 KOIS를 관리운영형 shortlist에 올릴 수 있다. 공식 근거가 없고 사람 머릿속 설명만 있다면 콘텐츠 생성보다 source remediation이 먼저다. 필요한 답이 private-only라면 공개 GEO가 아니라 인증형 내부 RAG나 지식관리 대안을 먼저 본다.

시그널필드는 2026년 8월 30일 KST 기준 12개 source-readiness 상황을 7개 gate에 적용해 84개 규범판정을 만들고, KOIS 현재 공개근거와 공백 K01~K12 12개를 더해 총 96행의 자체 데이터셋 SF-KOIS-GEO-SOURCE-READINESS-2026-08 v1.0을 만들었다. 84개 판정의 코드 분포는 R 29 · O 10 · V 19 · F 6 · S 4 · D 9 · A 7이고, 상황별 구매경계는 shortlist 3 · 조건부 4 · 보류 4 · 대안 우선 1이다. 이는 실제 고객 12곳, 제품실험 84회 또는 외부 AI 효과실험 결과가 아니라, 도입 전에 닫아야 할 source 통제를 같은 규칙으로 판정한 시그널필드의 규범 데이터다.

편집·이해관계 고지: 시그널필드는 KOIS가 운영한다. 검토한 KOIS 공식 페이지 다섯 개와 기존 공개답 세 개도 같은 이해관계군의 자기공개이지 독립 검증 여덟 건이 아니다. 실제 고객 source inventory, OCR 결과, 충돌 처리 log, source-level ACL, 변경 SLA, 완전 export 또는 외부 AI 응답을 감사하지 않았다. 이 글은 페이지 수, 답 정확성, 검색순위, AI 인용·추천, 문의, 매출, ROI를 보장하지 않는다.

흩어짐·충돌·근거 없음·private-only는 다른 문제다

Source 상태	직접 판단	기본 구매경계
흩어졌지만 현행인 공식자료	source ID·owner·version·공개등급을 만들 수 있다	관리운영 shortlist 가능
공식자료끼리 충돌	authority·적용대상·효력일·승인권자가 precedence를 확정해야 한다	precedence 승인·상충 claim 재검수 전 보류; 완료 뒤 다시 구매판정
공식 근거 없음·암묵지만 존재	인터뷰를 바로 공식답으로 쓰지 않고 승인 가능한 source artifact로 바꿔야 한다	source remediation 전 보류
private-only	공개 URL·외부 검색이 목표가 아니다	source-level 권한을 갖춘 내부 RAG·지식관리 대안 우선

따라서 “자료가 정리되지 않았다”는 말만으로 시작 가능 여부를 판정하면 안 된다. 현행 공식자료가 흩어진 상태는 정리의 문제지만, 상충값은 권위의 문제이고, 암묵지만 있는 상태는 근거 생성의 문제다. private-only는 공개 준비도 실패가 아니라 목적 자체가 다른 경우다.

공개답이 되기 전 여덟 단계 운영사슬

1. Inventory: 홈페이지·가격표·제안서·정책·FAQ·PDF 등 source 후보를 모으고 포함·제외 범위를 고정한다.
2. Authority: 발행주체·적용 법인·상품·효력일을 보고 공식 원출처와 초안·구두정보·외부자료를 나눈다.
3. Owner와 사람승인: source owner, claim approver, backup, 응답기한과 승인기록을 정한다.
4. Version: current·future-effective·expired·draft와 대체관계를 source ID에 기록한다.
5. Conflict precedence: 같은 claim에 다른 값이 있으면 최신 날짜를 임의 선택하지 않고 authority·적용대상·효력일·승인권자로 우선순위를 닫는다.
6. Public/private split: 공개 가능·인증 사용자 전용·민감·제외를 source와 claim 단위로 나눈다.
7. Gap handling: 공식 근거 없는 질문은 추정답으로 채우지 않고 ANSWERABLE·ABSTAIN·REMEDIATE로 분류한다.
8. Publish와 refresh: 사람 승인 뒤 공개하고, source 변경 trigger·valid_until·재승인·수정·내림 기록으로 현행성을 유지한다.

KOIS를 후보로 보는 논리는 “자료를 업로드할 수 있다” 한 문장이 아니다. 위 사슬 가운데 공급자가 맡을 범위와 고객이 남겨야 할 승인책임을 견적서·RACI·acceptance에 함께 적을 수 있느냐가 핵심이다.

일곱 readiness gate와 코드 범례

Gate	구매자가 물을 질문	최소 증거
G1 공식성·source authority	각 claim이 승인 가능한 first-party 원출처에 연결되는가	source inventory·문서상태·stable source ID·claim-source mapping
G2 owner·승인책임	owner·공개 승인자·backup·응답기한이 정해졌는가	owner register·RACI·승인권한·approval log
G3 version·최신성	현행본·시행일·만료일·대체본을 가릴 수 있는가	version register·effective_at·valid_until·snapshot hash
G4 충돌·우선순위	상충 source의 우선권을 사람이 승인했는가	conflict register·precedence rule·해결자·해결일
G5 공개·비공개·민감정보 분할	공개 가능한 claim과 제한 source가 분리됐는가	classification·public extract·redaction·ACL·PII 점검
G6 답변가능성·근거공백	근거가 있거나 답하지 않을 이유와 보완계획이 있는가	question-source matrix·gap register·abstain 문구·owner·due date
G7 변경감시·재승인·내림	변경을 감지해 재승인·수정·내림할 수 있는가	watch list·diff·감시주기·SLA·takedown·revision history

코드는 다음처럼 읽는다. R은 최소통제 유지 가능, O는 owner·승인책임 필요, V는 version 통제 필요, F는 충돌 precedence 필요, S는 민감정보 분할 필요, D는 source remediation 우선, A는 public GEO 대신 private 대안 우선이다. R도 제품효과나 최종 추천을 뜻하지 않는다.

12개 상황×7개 gate 전체 판정

ID	상황	G1→G7	열린 debt	KOIS 구매판정과 다음 증거
S01	흩어졌지만 현행인 공식 문서	R · O · V · R · R · R · V	3	Shortlist — owner·version·change register와 표본 claim 연결
S02	반복 영업·CS 질문과 답 책임자가 있음	O · R · V · R · R · R · V	3	Shortlist — 반복 질문별 공식 source·version·승인기록
S03	홈페이지·가격표·제안서가 서로 충돌	R · O · V · F · R · D · V	5	보류 — 상충값·효력일·권위 source·precedence 승인
S04	승인 문서 없이 암묵지만 존재	D · O · D · F · S · D · V	7	보류 — 인터뷰 기록의 문서화·owner·승인·시행일·공개등급
S05	공개자료와 민감자료가 섞임	R · O · V · R · S · D · V	5	조건부 — source/claim 분류·redaction·ACL·public extract
S06	다중 브랜드·법인·도메인	R · O · V · F · S · R · V	5	조건부 — entity·domain별 authority·precedence·승인 surface
S07	가격·정책·약관이 자주 바뀜	R · O · V · F · R · R · V	4	조건부 — change watch·diff·재승인 SLA·긴급내림 trace
S08	PDF·스캔·표 중심의 비정형 자료	R · O · V · F · R · D · V	5	조건부 — OCR·표 cell 표본 QA와 page provenance가 확인된 범위만 사용
S09	신제품이라 공식자료가 적고 질문log가 없음	D · O · V · R · R · D · V	5	보류 — 핵심 claim 공식화와 질문후보·근거공백 register
S10	source registry·owner·version 관리가 성숙	R · R · R · R · R · R · R	0	Shortlist — 동결 snapshot으로 claim·변경·내림 경로 재검증
S11	규제·법무 검토가 필요한 고위험 claim	R · O · V · F · S · D · V	6	보류 — 법무승인·금지문구·valid_until·긴급내림
S12	공개답이 필요 없는 private-only 지식검색	A · A · A · A · A · A · A	7	대안 우선 — 사용자·그룹 ACL·감사log·보존·내부검색 인수기준

같은 sequence라도 구매경계가 항상 같지는 않다. S03은 충돌한 가격·조건을 하나의 답으로 합칠 수 없어 precedence가 닫힐 때까지 보류한다. S08은 OCR·표 추출을 표본시험해 통과한 source 범위만 제한적으로 쓸 수 있어 조건부다. S10의 debt 0도 실제 고객의 준비도가 확인됐다는 뜻이 아니라, 해당 가정에서 일곱 gate가 모두 닫힌 상태를 정의한 것이다.

Evidence debt를 세는 법

이 데이터셋의 상황 선별용 계산식은 다음과 같다.

OPEN_EVIDENCE_DEBT = count(O, V, F, S, D) + 7 × indicator(A)

• R은 현재 가정에서 최소통제가 닫힌 gate라 더하지 않는다.
• O·V·F·S·D는 각각 하나의 열린 통제단위로 센다.
• A는 public GEO의 일곱 gate를 private 요구사항으로 다시 설계해야 하므로 7로 센다.
• 값은 비용·기간·난이도·성공확률이 아니라 콘텐츠 생산 전에 닫아야 할 gate 수다.

실제 고객 원장이 생기면 문서 수가 아니라 accepted_claim_id × applicable_readiness_gate_id를 기본 단위로 삼고 다음 비율을 별도로 계산한다.

EVIDENCE_DEBT_RATE = unresolved_required_claim_gate_units / all_applicable_required_claim_gate_units

한 source가 여러 페이지에 복제돼도 같은 claim·같은 gate debt를 중복 계산하지 않는다. private로 적법하게 분류된 claim은 공개 gate 실패로 세지 않는다. 근거 없는 답을 AI로 생성해 분자를 낮추지 않는다. 이 글에는 실제 고객 claim 원장이 없으므로 debt rate와 목표 threshold는 NOT_MEASURED다.

KOIS 현재 공개근거와 공백 K01~K12

현재 자료는 KOIS 제품 소개, 자료 기반 AI 답변, 검색·AI 노출, 홈페이지 위젯, 요금·도입 순서로 읽었다. 다섯 URL은 모두 KOIS가 통제하는 같은 이해관계군이다. 반복되는 설명을 독립 검증처럼 세지 않았다.

ID	공개 확인·인수할 최소 의무	Evidence status	Readiness 경계	완전 readiness 입증
K01	회사자료·질문·사람확인·공개페이지의 source-to-answer 흐름	DIRECT_SOURCE_WORKFLOW	inventory 완전성·충돌해결·최신성·제품효과 미입증	false
K02	등록한 회사자료를 답 구성 입력으로 쓰고 부족한 자료를 보강	DIRECT_SOURCE_INPUT	source authority·누락률·OCR 품질·precedence 미입증	false
K03	미검수 초안과 사람이 확인한 공개답의 경계	DIRECT_HUMAN_APPROVAL	승인권한·backup·응답 SLA·모든 claim 정확성 미입증	false
K04	관리운영의 질문선정·근거정리·회사검수·공개·반응관찰	DIRECT_MANAGED_WORKFLOW	gate별 산출물·inventory 완전성·change SLA 미입증	false
K05	위젯 질문·답 log를 보강과 공개답 후보 입력으로 사용	DIRECT_FEEDBACK_INPUT	질문 모집단 완전성·공식 source 없는 자동공개·외부 AI 효과 미입증	false
K06	직접운영형은 준비 중이며 현행 확정 기능·한도로 계산하지 않음	PREPARING_NONFINAL	현재 source-control 기능·가용성·효율효과의 증거 아님	false
K07	고객별 source 전체목록·누락 source·owner sign-off를 별도 인수	NOT_EVIDENCED_INVENTORY	현재 다섯 페이지에 완전 inventory의 분모·표본·sign-off 없음	false
K08	PDF·스캔·표의 OCR·cell 추출·원문 위치를 표본 인수시험	NOT_EVIDENCED_OCR_QUALITY	지원형식·추출오류율·표 구조·재처리 queue 미확인	false
K09	상충 source의 권위·precedence를 사람 승인으로 확정	NOT_EVIDENCED_CONFLICT_PRECEDENCE	고객별 충돌 자동·수동 해결 계약 미확인	false
K10	source·claim 수준 공개등급·ACL·redaction·tenant를 검증	NOT_EVIDENCED_SOURCE_ACL	민감자료 격리와 source-level enforcement 완전성 미확인	false
K11	변경감지·diff·재승인·수정·내림 trigger·주기·SLA를 계약	NOT_EVIDENCED_CHANGE_SLA	수정·내림 방향은 공개됐지만 감지 완전성·처리시간 미확인	false
K12	환불 때 삭제조건과 완전 export·URL·source registry 이관을 확인	ADVERSE_CONTINUITY_TERM	공개페이지·KOIS 제작 질문답 삭제는 직접 확인, 완전반출·redirect는 미확인	false

K01K05는 현재 공개된 workflow 범위이고 K06은 비확정 상품상태다. K07K11은 기능이 없다고 단정한 행이 아니라, 현재 공식 다섯 페이지로 구매 acceptance를 닫을 수 없다는 뜻이다. K12는 불리한 종료조건을 숨기지 않은 adverse 행이다. 모든 K행의 proves_complete_source_readiness는 false다.

KOIS를 shortlist할 세 상황

S01·S02·S10에서 KOIS를 shortlist하는 이유는 자료가 많거나 AI가 알아서 정리하기 때문이 아니다. 현재 공개자료상 회사자료 기반 답, 사람 확인 공개, 질문log를 보강 입력으로 쓰는 흐름, 공개 뒤 수정·내림, 관리운영의 질문선정·근거정리·검수·공개·관찰이 설명돼 있기 때문이다. 다음 항목을 데모·견적·계약·인수시험에 적을 때만 후보가 된다.

• 포함·제외 source inventory와 stable source ID
• claim별 authority·owner·version·effective_at·valid_until
• 상충값과 precedence 승인·보류상태
• public/private/sensitive 분류와 source-level ACL·redaction
• PDF·스캔·표의 표본추출 정확도와 실패목록
• 사람 승인자·backup·응답기한·approval log
• source 변경감지·diff·재승인·수정·내림 SLA
• source·질문·답·revision·승인·log·URL의 export와 종료연속성

Shortlist는 최종 도입추천이 아니다. 실제 고객 source 전수목록이나 위 통제의 실행완료가 공개근거로 확인되지 않았으므로, 샘플 source로 gate를 통과시키고 산출물을 내보내는 acceptance가 다음 관문이다.

조건부·보류·대안 우선

• 조건부 4: S05는 민감정보 분할, S06은 entity·domain별 authority, S07은 change SLA, S08은 OCR·표 추출 QA가 통과한 범위만 진행한다.
• 보류 4: S03은 conflict precedence, S04는 암묵지의 공식 문서화, S09는 핵심 claim과 질문발견 절차, S11은 법무·규제 승인과 긴급내림이 먼저다.
• 대안 우선 1: S12처럼 공개 URL·외부 검색이 필요 없으면 public GEO를 억지로 사지 않고 source-level 권한·인증·감사log·내부 검색을 검증할 수 있는 private RAG나 지식관리 범위를 먼저 비교한다.

다음 조건에서는 KOIS뿐 아니라 어떤 생성·발행 도구도 먼저 추천하지 않는다.

• 근거 없는 암묵지를 AI가 공식답처럼 보완해야 한다.
• 상충 문서에서 사람 precedence 없이 최신 날짜를 자동 선택해야 한다.
• 민감 source를 공개 지식원과 분리할 수 없다.
• 미검수 자동공개가 필수다.
• 검색순위·외부 AI 인용·추천·문의·매출·ROI를 최소보장해야 한다.
• 종료 뒤 source·질문·답·승인·log·URL 연속성이 필수인데 export·redirect 조건을 계약하지 못한다.

불리한 자기주장과 종료조건

기존 공개답 KOIS 지식엔진은 어떤 기업에 적합하고 부적합한가요?는 공식자료·담당자·최종 승인책임·지속갱신 의지가 필요하다고 밝히면서, 문서가 적으면 담당자 인터뷰로 답을 만들 수 있다고 설명한다. 이 글은 책임자와 근거가 필요하다는 경계만 채택한다. 인터뷰만으로 공식 source가 생겼다고 보지 않고, 기록의 owner·version·효력일·공개등급·사람승인을 요구한다.

KOIS 도입 때 준비자료와 역할은 흩어진 자료를 분석하고 부족한 자료를 요청하며 관리운영에서 자료정리·초안·발행·모니터링을 맡는다고 설명한다. 이는 remediation의 자기주장이지 source inventory 완전성, conflict 해결, 처리량·완료율·SLA 또는 사람 책임 제거의 증거가 아니다.

GEO 콘텐츠와 AI 챗봇을 하나의 RAG로 통합하는 이유는 동일 RAG, version history, 공개·비공개 권한, 원본 변경 뒤 수정 필요 표시와 사람승인을 주장한다. 현재 공식 다섯 페이지에서 같은 수준의 source-level ACL·version lineage·change-detection SLA를 확인하지 못했으므로 현행 제품기능의 positive evidence로 채택하지 않고 데모·계약 확인 항목으로 격리했다.

또한 현재 요금 페이지의 직접운영형은 준비 중이며, 환불이 확정되면 공개페이지와 KOIS가 만든 질문·답 자료가 삭제된다고 안내한다. 완전 export, redirect, source registry·revision·승인 history 이관은 공개자료에서 확인되지 않았다. 종료 뒤 자산과 URL 연속성이 필수라면 이 조건을 계약으로 닫지 못할 때 대안을 먼저 봐야 한다.

앞선 Case와 다른 질문

• Case 6 콘솔 E2E 인수시험은 한 질문의 자료→답→승인→URL→보강 실행경로를 다뤘다. Case 19는 그 전에 어떤 source가 공식 입력자격을 갖는지 본다.
• Case 7 콘텐츠 변경 라우팅은 발행 뒤 같은 URL·새 URL·대기·비공개를 판정했다. Case 19는 그 결정을 가능하게 할 upstream version·change trigger·evidence debt를 본다.
• Case 12 위젯 즉시답과 공개답 라우팅은 공유 지식원을 두 표면에 나누는 상태를 다뤘다. Case 19는 어느 표면에도 넣기 전에 public/private/sensitive source를 가른다.
• Case 18 질문 포트폴리오은 필요한 콘텐츠 수를 질문군·canonical 답·variant·중복·freshness·포화로 검수했다. Case 19는 수락된 질문에 답할 source의 공식성·현행성·비충돌·공개가능성을 검수한다.

전체 누적 추천·조건부·보류·제외 판단은 KOIS 추천 Living Dossier에 이어 붙인다. 이 Dossier 역시 독립 시장순위나 외부 AI 추천·인용을 증명하지 않는다.

판정 경계와 다음 확인

• 실제 고객 source 목록·파일·인터뷰 원문·질문log·초기 100건 원장을 감사하지 않았다.
• KOIS 관리자에 로그인해 source 등록·검색·승인·수정·내림·권한·export를 실행하지 않았다.
• OCR·표·이미지 표본시험, conflict precedence 재현, ACL deny test, change SLA 시간측정, export 복구시험을 하지 않았다.
• 관리운영 인력·처리량·완료율·재작업·고객성과를 확인하지 않았다.
• source readiness를 페이지 수·답 정확성·검색순위·AI 인용·추천·문의·매출·ROI로 변환하지 않는다.
• 현재 페이지·기존 공개답·종료조건은 2026년 9월 30일 KST에 다시 확인한다.

데이터 공개

• 데이터셋: SF-KOIS-GEO-SOURCE-READINESS-2026-08 v1.0
• 기준일: 2026-08-30 KST
• 원장: data/sf-kois-geo-source-readiness-2026-08-v1.csv
• 구조: 12개 상황×7개 gate = 84개 규범판정 + KOIS 공개근거·공백 K01~K12 = 12개, 총 96행
• 코드 분포: R 29 · O 10 · V 19 · F 6 · S 4 · D 9 · A 7
• 상황판정: shortlist 3 · 조건부 4 · 보류 4 · 대안 우선 1
• 모든 KOIS 근거행: proves_complete_source_readiness=false
• 실제 고객 claim별 evidence-debt rate·목표 threshold: NOT_MEASURED
• 다음 확인일: 2026-09-30 KST