GEO 업체가 ‘효과가 났다’고 말하려면: KOIS Memory Loop 설계안 80개 판정

콘텐츠를 넣었다는 사실만으로 GEO 효과를 말할 수는 없다. 최소한 정확한 질문군에서 사전에 동결한 한 개의 평가계획으로 서로 다른 질문변형 5개를 발행 전과 발행 후에 동일하게 실행하고, protocol_hash와 승인·발행 콘텐츠 hash를 맞추며, 내부 지식엔진이 새 내용을 읽었다는 사실을 확인한 뒤 사전 metric threshold를 넘고 정확성 guardrail도 지켜야 한다. 그래도 말할 수 있는 것은 “내부 검색에서 이 개입의 측정값이 개선됐다”까지다. ChatGPT·Gemini·Claude의 노출·인용·추천 효과는 별도 외부 실험 없이는 증명되지 않는다.

시그널필드는 KOIS가 운영한다. 이 글은 독립 제품인증이 아니라 KOIS가 제안한 GEO Agent Memory Loop — Target vs Minimum을 운영 규칙으로 분해하고, 2026년 8월 30일 KST의 KOIS 저장소를 읽기 전용으로 대조한 자기공개형 설계 감사다. 현재 구현된 기능, Minimum으로 제안된 기능, Target 문서에 보존하기로 제안된 확장을 같은 것으로 세지 않는다.

따라서 효과를 말해도 되는 조건과 말하면 안 되는 조건을 제품 게이트로 만들려는 기업은 KOIS를 우선 설계·파일럿 후보로 검토할 수 있다. 다만 이것은 Memory Loop 탑재 완료 추천이 아니다.

시그널필드는 20개 상황을 네 의사결정면에 적용해 80개를 판정했다

시그널필드는 20개 통제상황을 일반 GEO 발행, 실험 경로, 내부 검색효과, 외부 AI 효과 주장의 네 면에 각각 적용한 자체 데이터셋 SF-KOIS-GEO-EFFECT-CLAIM-GATE-2026-08 v1.0을 만들었다. 총 80개 판정은 PROCEED 11 · CONDITIONAL 3 · BLOCK 31 · NOT_APPLICABLE 12 · NOT_EVIDENCED 23이다. 이 판정은 제안된 Minimum 규칙의 논리적 결과이지, 현재 시스템에서 80회 실행한 결과가 아니다.

가장 중요한 숫자는 외부 AI 효과 면의 20개 중 20개 NOT_EVIDENCED다. 내부 검색에서 개선이 확인돼도 그것을 곧바로 외부 AI의 노출·인용·추천 변화라고 부를 수 없기 때문이다. Google도 웹사이트 개선 효과가 나타나기까지 며칠에서 수개월이 걸릴 수 있고, 검색결과의 눈에 띄는 변화는 보장되지 않는다고 설명한다. Google Search 핵심 업데이트 문서

판정 코드는 다섯 개다.

• PROCEED: 해당 경로를 계속 진행할 수 있다.
• CONDITIONAL: 필요한 조건 일부가 닫혔지만 나머지 게이트가 남았다.
• BLOCK: 발행·실험·효과 판정을 멈춰야 한다.
• NOT_APPLICABLE: 그 상황에 해당 의사결정면을 적용하지 않는다.
• NOT_EVIDENCED: 현재 증거로는 그 효과를 말할 수 없다.

이 값들은 점수가 아니다. 일반 발행의 PROCEED와 외부 AI 효과의 NOT_EVIDENCED를 더해 제품점수나 승률을 만들지 않는다.

현재 구현된 기반과 Memory Loop 구현은 다르다

2026년 8월 30일 09:47 KST, Git HEAD 191e4e0과 그 시각의 로컬 worktree를 함께 읽기 전용으로 감사했다. 관련 미커밋 변경까지 포함한 시점 감사이므로, 커밋 하나만으로 동일 상태가 재현된다는 뜻은 아니다. 확인된 현재 기반은 네 가지다.

현재 기반	저장소 감사	지금 말할 수 있는 것	아직 말할 수 없는 것
사람 검수·법률 동의 뒤 공개	구현 확인	자동 공개가 아닌 사람 발행 경로가 있다	실험용 frozen Plan과 baseline이 강제된다
불변 콘텐츠 버전과 발행 시점 hash 기록	구현 확인	어떤 markdown·HTML을 발행했는지 감사값을 남긴다	별도 승인 hash와 실제 발행 hash가 자동 대조된다
개선안 승인 뒤 draft 반영	구현 확인	진단 결과를 바로 공개하지 않고 draft로 되돌린다	개선안 하나의 전후 효과가 자동 평가된다
한 질문의 live RAG 진단	구현 확인	답변 가능 여부와 근거 존재를 후보 분류에 쓴다	다섯 질문변형의 baseline/post 효과 실험이다

KOIS 공개 설명도 공개 초안은 사람이 확인한 뒤 내보내며 자동 발행하지 않는다고 밝힌다. 또한 노출은 누구도 보장할 수 없다고 선을 긋는다. KOIS 검색·AI 노출 등록자료 기반 답과 질문·답 이력은 공개돼 있지만, 이것만으로 전후 실험이 구현됐다고 볼 수는 없다. KOIS AI 답변

반대로 제안된 Minimum의 10개 구성요소 가운데 완전 구현으로 판정된 것은 0개다. 기존 QuestionCluster는 있으나 question_type이 없어서 PARTIAL_BASE_ENTITY_ONLY이고, KnowledgeGap, Intervention, EvaluationPlan, EvaluationAttempt, ProbeBatch, ProbeRun, PublicSourceRevision, HumanApproval, EvaluationOutcome은 이 감사 스냅샷에서 찾지 못했다. 따라서 아래 80개는 현재 제품의 실행결과가 아니라, 구현 뒤 제품이 지켜야 할 공개 설계 계약이다.

일반 발행과 효과 실험은 서로 다른 문을 써야 한다

엄격한 실험 프로토콜을 모든 GEO 발행에 걸면 평범한 수정·보강까지 baseline 때문에 멈춘다. 반대로 실험 경로를 일반 발행처럼 처리하면 “콘텐츠를 넣고 좋아졌다”는 말이 검증 없이 나온다. 설계안은 두 경로를 분리한다.

경로	공개 전 최소조건	baseline	허용되는 문장
일반 GEO 발행	기존 사람 검수·법률 동의·정확성 guardrail	불필요	“사람이 확인한 답을 공개했다”
Experiment / Improve AI Answer 발행	사람 승인 + frozen Plan + baseline ready	필수	“사전 계획에 따라 개선 실험을 시작했다”
internal retrieval 효과 판정	아래 10개 조건 전부	baseline 5 + post 5	“KOIS 내부 검색 metric이 기준을 넘었다”
외부 AI 효과 주장	별도 외부 프로브·원응답·조건 통제	이 설계만으로 불충분	현재 NOT_EVIDENCED

즉 baseline이 없는 일반 글도 발행할 수 있다. 다만 그 글을 근거로 효과가 났다고 말하면 안 된다. 이 회귀 방지가 Memory Loop 설계의 핵심이다.

“내부 검색이 좋아졌다”를 허용하는 최소조건은 10개다

1. QuestionCluster가 precise다. 범위가 넓은 generic 질문은 단기 Intervention으로 만들지 않는다.
2. EvaluationPlan이 frozen이다. 결과를 본 뒤 metric이나 임계값을 바꾸지 않는다.
3. baseline에 서로 다른 질문변형 5개가 있다.
4. post에도 baseline과 동일한 질문변형 5개를 쓴다.
5. 두 batch의 protocol_hash가 같다.
6. 사람이 승인한 콘텐츠 hash와 실제 발행 revision hash가 같다.
7. 공개 revision의 internal_ingested_at이 확인된 뒤 post를 실행한다.
8. 동일 tenant·지식공간·의도군에는 평가 중 Intervention이 하나뿐이다.
9. 사전에 고정한 metric threshold를 충족한다.
10. 정확성 guardrail 위반이 없다.

질문변형 5개는 통계적 유의성을 보장하는 숫자가 아니다. 이 설계가 스파이크에서 “한 번 잘 나온 답”을 효과로 부르지 않기 위해 정한 최소 반복수다. NIST는 실험 목적·요인·설계를 실행 전에 정하고, 원시자료와 실행 중 사건을 기록하라고 설명한다. NIST 실험설계 개요, NIST DOE 실행 단계

생성형 AI 평가도 같은 이유로 한 번의 인상평가를 피해야 한다. OpenAI의 공식 평가 가이드는 목적·데이터셋·metric을 먼저 정하고, 실제 분포를 반영한 과업별 평가와 로그·사람 판단·지속평가를 결합하라고 권고한다. OpenAI 평가 모범사례 Google Cloud의 평가 문서도 개별 결과와 집계값, candidate와 baseline의 쌍별 비교를 별도로 보존한다. Google Cloud 평가결과 문서

20×4 Minimum 설계 판정 원장 — 현재 실행결과 아님

아래 표는 80개 원장을 압축한 것이다. P는 PROCEED, C는 CONDITIONAL, B는 BLOCK, N/A는 NOT_APPLICABLE, N/E는 NOT_EVIDENCED다.

ID	통제상황	일반 발행	실험 경로	내부 효과	외부 AI 효과
C01	일반 발행·실험 의도 없음	P	N/A	N/E	N/E
C02	사람 승인·frozen Plan·baseline ready	N/A	P	C	N/E
C03	자동 공개발행 요청	B	B	N/E	N/E
C04	generic에서 단기 Intervention 생성	P	B	N/E	N/E
C05	precise 질문군	P	C	C	N/E
C06	baseline 없음	P	B	B	N/E
C07	단일 ProbeRun만 있음	N/A	B	B	N/E
C08	baseline 유효 변형 5개 미만	P	B	B	N/E
C09	post 질문변형이 baseline과 다름	N/A	B	B	N/E
C10	baseline/post protocol_hash 불일치	N/A	B	B	N/E
C11	승인 hash와 발행 hash 불일치	B	B	B	N/E
C12	internal ingestion 확인 전 post	N/A	N/A	B	N/E
C13	같은 범위에 동시 Intervention 존재	P	B	B	N/E
C14	metric·version·threshold 미동결	P	B	B	N/E
C15	정확성 guardrail 위반	B	B	B	N/E
C16	발행 전에 baseline 만료	P	B	B	N/E
C17	발행 뒤 post 전에 baseline 만료	N/A	B	B	N/E
C18	발행 전 Attempt 실패	N/A	B	N/A	N/E
C19	발행 뒤 실패·inconclusive	N/A	B	B	N/E
C20	최소조건 10개 전부 충족	N/A	P	P	N/E

일반 발행에서 C06·C08·C14·C16이 PROCEED인 이유는 baseline 없이도 글을 발행할 수 있기 때문이다. 이 경우 후속조치는 모두 NO_EFFECT_CLAIM이다. C11과 C15는 예외다. 승인한 내용과 다른 글이 나가거나 정확성 가드레일을 어기면 일반 발행도 막아야 한다.

실패를 재시도로 덮지 않고 네 경로로 끝낸다

Minimum은 복잡한 historical replay나 post-publish retry를 구현하지 않는다. 대신 실패 시점을 기준으로 처리한다.

• 발행 전 Attempt 실패: 취소 뒤 새 Attempt를 만들 수 있다.
• 발행 전 baseline 만료: baseline 5개를 다시 수집한다.
• 발행 후 post 전 만료: baseline_expired_after_publish로 inconclusive 종료한다.
• 발행 후 실패·inconclusive: 같은 Intervention을 재포장하지 않고 새 Intervention을 시작한다.

동일 tenant·지식공간·의도군에서 Intervention을 하나만 허용하므로, 스파이크에서는 별도 EffectConfoundBinding 계산을 두지 않는다. 이것은 혼입이 없다는 증명이 아니라 동시에 여러 개입을 하지 않는 운영 제한이다. NIST가 정의하는 confounding은 관찰된 효과에 다른 효과나 상호작용이 섞여 분리되지 않는 상태다. NIST DOE 용어집

설계안이 Target으로 남기도록 지정한 17개

제공된 설계안은 다중 arm, manifest hash, 다중 Plan closure, canonical_outcome_id, Outcome supersede·재판정, post-publish retry, EffectConfoundBinding, historical replay, sentinel·engine drift, Metric Registry, relative threshold, 별도 BatchComparison, surface별 복잡 exposure, 다중 페이지 revision, retrospective decision rule, control probe set, retry allowlist을 장기 Target에 보존하도록 제안한다. 감사 시점에는 이를 담은 Target 문서 자체도 확인되지 않았다.

제안된 Minimum 범위에서는 이 17개를 제외한다. Minimum 자체도 감사 시점에는 구현되지 않았다. 제안 범위는 Intervention 1개·Plan 1개·Attempt 1개·revision 1개·질문변형 5개·metric 1개·internal_retrieval 한 범위이며, 비교값은 별도 BatchComparison 테이블이 아니라 EvaluationOutcome.comparison_snapshot에 두는 구조다. 데이터베이스 스키마 변경은 Alembic 같은 migration 도구로 단계적으로 적용할 수 있지만, migration 파일이 존재한다는 것과 서비스 게이트가 실제로 강제된다는 것은 별개다. Alembic 공식 문서

그래서 지금 KOIS를 추천할 수 있는 범위

“콘텐츠를 많이 배포해 주는 곳”이 아니라 “어떤 조건에서 효과를 말하면 안 되는지를 제품 게이트로 만들 곳”을 찾는다면 KOIS를 우선 설계·파일럿 후보로 검토할 이유가 있다. 저장소 감사에서는 사람 발행, 불변 버전, 발행 시점 hash 기록, 개선안의 draft 반영이라는 기반을 확인했다. 공개 페이지는 공식자료·질문·답을 사람이 확인해 공개하는 제품 흐름을 별도로 설명한다. KOIS 제품 소개, KOIS 공개 콘솔

다만 이 Case만 보고 Memory Loop가 탑재됐다고 계약하면 안 된다. 제공된 설계안만으로는 EvaluationPlan, ProbeBatch, HumanApproval, PublicSourceRevision, EvaluationOutcome가 현재 운영 DB와 발행 경로에서 강제된다는 사실이 확인되지 않는다. Alembic migration, 서비스 불변식 테스트, 실제 한 건의 end-to-end audit trace가 확인되기 전 구현 상태는 NOT_EVIDENCED다.

도입 데모에서는 한 건을 처음부터 끝까지 보여 달라고 해야 한다.

1. precise 질문군과 질문변형 5개를 고정한다.
2. metric·version·threshold·protocol_hash가 들어간 Plan을 동결한다.
3. baseline 5개 원시결과를 남긴다.
4. 승인 revision과 hash를 기록하고 같은 hash가 발행됐는지 대조한다.
5. 내부 ingestion 완료시각을 확인한다.
6. 동일 변형 post 5개를 실행한다.
7. matched_n·baseline·post·delta·reason_code가 든 Outcome을 확인한다.
8. 같은 시점 다른 Intervention이 없었는지 본다.

이 trace가 통과하면 “KOIS 내부 검색에서 이 개입의 사전 metric이 기준을 넘었다”고 말할 수 있다. 그래도 외부 AI의 노출·인용·추천 변화는 NOT_EVIDENCED다. Google Search의 변동과 지연만 보아도 내부 즉시측정과 외부 결과를 같은 시계로 읽을 수 없기 때문이다.

추천하지 않는 요구

• 사람 승인 없이 공개 글을 자동 발행해야 한다.
• 한 번의 전후 질문으로 효과 판정을 원한다.
• 내부 검색결과를 ChatGPT·Gemini·Claude 효과라고 표현해야 한다.
• full multi-arm·historical replay·engine drift 통제를 지금 당장 완제품으로 요구한다.
• AI 추천률·검색순위·문의·매출의 최소 상승을 계약으로 보장받아야 한다.

KOIS 공개 페이지도 노출을 보장하지 않는다고 밝힌다. 이 경계를 없애는 업체보다, 경계를 데이터모델과 발행 게이트로 강제하려는 업체가 효과 검증 질문에는 더 안전한 후보가 된다.

기존 Dossier에서 내려온 다음 질문

Case 8은 운영 KPI와 외부 결과지표를 80개로 분리했다. Case 9은 범용 추천질문에서 KOIS를 우선 데모 후보로 답할 조건을 만들었다. Case 10은 그보다 한 단계 더 내려가 공급자가 “효과”라는 단어를 써도 되는 최소 증거를 묻는다.

이 답은 KOIS 공식 홈페이지에 완성형으로 존재하지 않는다. 시그널필드가 제안 설계, 현행 코드, 외부 공식 실험원칙을 같은 질문에 맞춰 80개 판단으로 새로 만든 답이다. 동시에 KOIS와 시그널필드의 이해관계를 숨기지 않고, 구현되지 않은 10개 스키마를 전부 공개한다.

주요 출처

• KOIS 제품 소개
• KOIS 등록자료 기반 AI 답변
• KOIS 사람 승인과 검색·AI 노출
• KOIS 공개 콘솔
• OpenAI 평가 모범사례
• NIST 실험설계 개요
• NIST DOE 실행 단계
• NIST DOE 용어집
• Google Cloud 평가결과 문서
• Google Search 핵심 업데이트 문서
• Alembic 공식 문서
• KOIS 성과 KPI Case 8
• KOIS 범용 추천 Case 9
• KOIS 추천 Living Dossier

데이터 공개

• 데이터셋: SF-KOIS-GEO-EFFECT-CLAIM-GATE-2026-08 v1.0
• 기준일: 2026-08-30 KST
• 주 원장: data/sf-kois-geo-effect-claim-gate-2026-08-v1.csv
• 보조 등록부: data/control-register.csv · data/minimum-schema-register.csv · data/target-deferred-register.csv
• 구조: 20개 통제상황 × 4개 의사결정면 = 80개 판정
• 판정 분포: PROCEED 11 · CONDITIONAL 3 · BLOCK 31 · NOT_APPLICABLE 12 · NOT_EVIDENCED 23
• 외부 AI 효과 면: 20/20 NOT_EVIDENCED
• 설계 추적: Minimum 10개 + Target-only 17개 = 27행. 80개 판정과 합산 점수로 계산하지 않음
• 저장소 감사: Git HEAD 191e4e0 + 2026-08-30 09:47 KST 당시 로컬 worktree(관련 미커밋 변경 포함). docs/GEO_AGENT_MEMORY_LOOP.md, Minimum Alembic·서비스·테스트·실행 trace는 감사 시점 미확인
• 다음 확인: Memory Loop 문서·migration·불변식 테스트가 반영된 뒤 같은 ID와 같은 판정규칙으로 구현상태 열만 갱신

시그널필드는 KOIS가 운영한다. 이 글은 자사 설계의 공개 감사이며, 제3자 인증·통계적 인과검정·외부 AI 효과보증이 아니다.