기존 홈페이지를 바꾸지 않고 GEO를 붙일 수 있나: KOIS 위젯·공개답·도메인 연결을 가르는 96개 인수판정

가능한 환경이 있다. 다만 홈페이지를 새로 만들지 않는 것과 아무 변경·검수 없이 설치하는 것은 다르다. CMS·DNS 담당자, staging과 production 작업창, 공개 URL과 crawl 경로가 있는 일반 사이트라면 KOIS를 위젯·공개답 운영의 데모·견적 shortlist에 둘 수 있다. headless CMS, 다중 도메인, 엄격한 CSP·WAF, 기존 챗봇 공존 환경은 custom integration과 보안·인수시험 전에는 조건부다. CMS·DNS 권한자가 없거나 public URL을 만들 수 없으면 보류하고, public URL 자체가 필요 없는 intranet은 private 지식검색 대안을 먼저 본다.

시그널필드는 2026년 8월 30일 KST 기준 12개 구매자 웹환경을 7개 integration gate에 적용해 84개 규범판정을 만들고, KOIS의 현재 공개근거·보충 자기주장·공백 K01~K12 12개를 더해 총 96행의 자체 데이터셋 SF-KOIS-GEO-WEBSITE-INTEGRATION-2026-08 v1.0을 만들었다. 84개 판정의 코드 분포는 R 4 · C 27 · I 7 · S 9 · V 20 · B 10 · A 7이고, 상황별 구매경계는 shortlist 3 · 조건부 4 · 보류 4 · 대안 우선 1이다. 이는 실제 고객 12곳, 설치 84회, 성능·보안·접근성 시험 또는 외부 AI 효과실험의 결과가 아니라 구매환경별 의존성과 인수증거를 같은 규칙으로 분류한 시그널필드의 규범 데이터다.

편집·이해관계 고지: 시그널필드는 KOIS가 운영한다. 이번 검토의 current 원출처는 KOIS 위젯 설치, KOIS 제품 소개, KOIS 요금·도입, KOIS 검색·AI 노출 순이다. 네 페이지는 현재 기능범위와 상업조건을 확인하는 직접자료지만 같은 이해관계군의 자기공개이며 독립 고객 검증 네 건이 아니다. 시그널필드는 실제 고객 production 설치, CMS별 호환, DNS·TLS, 보안·접근성·브라우저·성능, rollback, runtime SLA 또는 검색·AI 효과를 감사하지 않았다.

“홈페이지를 바꾸지 않는다”는 말의 정확한 뜻

전면 재구축 없이도 기존 사이트에 새 surface를 더하는 방식은 가능하다. 그러나 구매자가 분리해서 봐야 할 surface는 둘이다.

• 질문 위젯: 기존 화면에 질문 버튼이나 창을 더한다. 방문자가 등록자료를 바탕으로 즉시답을 받는 접점이다.
• 공개 답 페이지: 사람이 확인한 답을 회사 웹 주소 아래 개별 URL로 공개하고, 이후 수정하거나 내리는 접점이다.

위젯이 브라우저에 보인다고 공개 답 페이지가 crawl 가능한 것은 아니다. 반대로 공개 URL이 있다고 위젯의 script·origin·CSP·접근성·성능이 합격한 것도 아니다. 두 surface가 같은 지식 흐름을 설명하더라도 설치·보안·발견성·cutover의 인수증거는 각각 받아야 한다.

연결 선택	홈페이지에서 실제로 달라지는 것	계약·인수 전에 닫을 질문
표준 embed·위젯	template 또는 tag 영역에 실제 설치코드가 들어감	script host·version·제거법, CSP·WAF·allowed origin, DOM·keyboard·consent 충돌
subdomain	DNS·TLS와 별도 host·origin 경로가 생김	zone·certificate·canonical·sitemap·cookie·운영 owner
subdirectory·reverse proxy	기존 domain 아래 route와 proxy·cache 규칙이 바뀜	origin·header·TTL·cache purge·failure path·rollback
API·webhook·build-time	CMS나 CI/CD에 custom interface가 추가됨	schema·auth·rate limit·retry·versioning·sandbox·deprecation
별도 public surface	기존 CMS 밖에서 공개페이지를 운영함	domain ownership·브랜드 일관성·redirect·asset·종료이관

따라서 “한 줄 설치”는 구매 결론이 아니다. 실제 설치코드, 선택 topology, 보안허용, 공개 발견성, 되돌림과 운영관찰이 하나의 인수팩으로 묶일 때만 배포완료라고 부를 수 있다.

일곱 integration gate: 기능명이 아니라 인수증거를 본다

Gate	구매자가 물을 질문	최소 acceptance와 대표 증거	Hard stop
G1 환경·통제권	CMS·DNS·배포 owner와 staging·production이 구분됐나	이름 단위 RACI, 접근권한, staging URL, change window, production 승인기록	owner나 안전한 시험창이 없으면 production 변경 보류
G2 도메인 경로	DNS·TLS·host·origin·subdomain·proxy 책임이 닫혔나	topology, DNS/TLS RACI, certificate·host validation, TTL, failure·rollback path	host·certificate·origin 책임이 불명확하면 공개 연결 금지
G3 CMS·API·embed	template·script·plugin·API·webhook·CI/CD 중 쓸 interface가 있는가	지원 matrix, 실제 artifact, sandbox, install·update·remove trace	설치 interface 또는 제거 경로가 없으면 custom 설계나 보류
G4 보안·공존	CSP·WAF·CORS·tenant·PII와 기존 위젯·태그가 충돌하지 않는가	allowlist·nonce/hash, data flow, deny test, DOM·keyboard·consent 공존시험	보안허용·tenant·PII·공존 실패 시 production 금지
G5 공개 발견성	승인답이 HTTP·canonical·sitemap·robots·schema·cache 경로에 놓이는가	실제 URL의 HTTP 200, 렌더 HTML, canonical, sitemap, robots, structured data, cache trace	crawl 가능한 공개 URL이 없으면 public GEO 성립 안 함
G6 cutover·lifecycle	승인 revision을 올리고 수정·내림·purge·rollback할 수 있는가	승인 hash, deploy·update·unpublish·cache purge log, rollback trigger·owner·rehearsal	staging·rollback 없는 production 직행은 보류
G7 관찰·인수	오류·지연·fallback을 누가 보고 어떤 기록으로 합격시키는가	healthcheck, browser·network·server log, latency·error 기준, fallback, support owner, signed acceptance	탐지기준·증거·대응 owner가 없으면 인수완료 아님

G5의 “발견 가능”은 기술적으로 공개 URL과 crawl 경로를 만들었다는 뜻이다. 색인, 순위, AI 답변 채택을 뜻하지 않는다. G7의 인수도 공급자의 “지원한다”는 설명이 아니라 구매자 환경에서 남긴 실행기록을 요구한다.

R·C·I·S·V·B·A를 읽는 법

코드	뜻	구매 행동
R READY_EVIDENCED	상황 전제상 최소 기반이 존재함	증거 snapshot을 동결하고 나머지 gate 시험으로 진행
C CONFIGURATION_REQUIRED	표준 설정과 책임자 합의가 필요함	설정값·owner·작업창·인수기준을 서면화
I CUSTOM_INTEGRATION_REQUIRED	환경별 interface 설계·구현·시험이 필요함	SOW·sandbox·제거경로·회귀시험 전 조건부
S SECURITY_REVIEW_REQUIRED	보안·개인정보·origin·공존 검토가 필요함	production 전 허용·차단·충돌시험과 승인
V ACCEPTANCE_VERIFICATION_REQUIRED	실제 환경의 실행·관찰·서명 검증이 필요함	기능설명 대신 staging·cutover·운영 artifact를 인수
B BLOCKING_DEPENDENCY	필수 권한·interface·공개경로·복구조건이 없음	dependency 해소 전 hold
A ALTERNATIVE_FIRST_PRIVATE	public GEO보다 private 접근이 목적에 맞음	auth·ACL·audit 중심의 private 대안 우선

구매경계는 점수 합산이 아니라 우선순위로 정했다.

1. A가 하나라도 있으면 ALTERNATIVE_FIRST.
2. A가 없고 B가 하나라도 있으면 HOLD.
3. A·B 없이 I가 하나라도 있으면 CONDITIONAL.
4. 나머지는 SHORTLIST.

C·S·V가 남은 shortlist는 “손댈 것이 없다”는 뜻이 아니다. 연결경로가 열려 있고 해결주체와 인수방식을 정의할 수 있어 데모·견적 단계로 갈 수 있다는 뜻이다.

12개 웹환경×7개 gate 전체 판정

ID	구매자 웹환경	G1→G7	구매경계	가장 먼저 받을 증거
S01	CMS·DNS 관리자와 staging이 있는 일반 기업 사이트	R · C · C · C · R · V · V	SHORTLIST	권한 snapshot, 공개 URL trace, rollback·healthcheck 결과
S02	유지보수사가 CMS·DNS를 관리하지만 담당자·작업창이 확정됨	C · C · C · C · R · V · V	SHORTLIST	구매자·유지보수사·공급자 RACI, change window, 승인기록
S03	subdomain·reverse proxy·표준 embed가 허용됨	C · C · C · S · R · V · V	SHORTLIST	DNS/TLS·origin plan, 보안 공존시험, production 인수표
S04	headless CMS·API·CI/CD 환경	C · C · I · S · C · V · V	CONDITIONAL	API/webhook 계약, sandbox, build·remove trace
S05	다중 브랜드·도메인·언어	C · I · I · S · I · V · V	CONDITIONAL	domain·brand·locale별 route·canonical·tenant·release matrix
S06	CSP·WAF·보안검토가 엄격함	C · C · I · S · C · V · V	CONDITIONAL	CSP report-only·WAF·origin·tenant deny test와 보안 sign-off
S07	기존 챗봇·태그매니저·분석도구와 공존해야 함	C · C · I · S · C · V · V	CONDITIONAL	DOM·event·network·consent·z-index·fallback 공존 matrix
S08	API·plugin·template 접근이 없는 폐쇄형 legacy CMS	C · B · B · S · B · V · V	HOLD	지원 extension·proxy·별도 public surface 중 승인된 연결경로
S09	DNS·CMS 권한자와 유지보수 owner가 없음	B · B · B · S · B · V · V	HOLD	권한자 지정, 계정 회복, staging, change·rollback owner
S10	client-only SPA이고 SSR·canonical·sitemap 경로가 없음	C · C · I · S · B · V · V	HOLD	SSR·prerender 또는 별도 공개 surface의 HTTP·canonical·sitemap trace
S11	production 직행이며 staging·rollback·health monitoring이 없음	C · C · C · S · C · B · B	HOLD	격리시험·canary, 승인 cutover, rollback rehearsal, health/error log
S12	공개 URL·crawl이 필요 없는 사내 intranet	A · A · A · A · A · A · A	ALTERNATIVE_FIRST	private auth·ACL·audit·retention 요구사항과 인수기준

코드 합계는 R4·C27·I7·S9·V20·B10·A7=84다. 이 84는 설치 성공 84건이 아니라 시그널필드가 12개 가정에 동일 규칙을 적용한 규범판정 84개다.

세 상황은 shortlist, 네 상황은 조건부다

S01~S03은 표준 도입의 선행조건이 있다. 내부 담당자가 있거나 계약된 유지보수 경로가 있고, staging 또는 표준 domain·embed 경로를 열 수 있다. 이때 KOIS를 shortlist하는 이유는 “모든 사이트에 바로 붙는다”가 아니다. 현재 공개자료가 사람 확인 공개, 공개 URL의 수정·내림, 위젯 surface, 관리형 setup 범위를 설명하므로 실제 환경 데모와 견적을 요구할 후보 근거가 있기 때문이다.

Shortlist에서 반드시 묶어 받을 인수팩은 일곱 개다.

1. ENVIRONMENT_OWNER_MAP — CMS·DNS·TLS·보안·release·운영 owner와 권한
2. DOMAIN_ROUTE_PLAN — host·origin·certificate·canonical·TTL·cutover·rollback
3. INTEGRATION_INTERFACE_CONTRACT — CMS/version, script·plugin·API·webhook, 설치·제거
4. SECURITY_COEXISTENCE_TEST — CSP·WAF·origin·tenant·PII·기존 도구의 허용·차단·충돌
5. PUBLIC_DISCOVERY_TRACE — HTTP·HTML·canonical·sitemap·robots·schema·cache의 동일 revision
6. CUTOVER_ROLLBACK_TRACE — 승인 hash, deploy·update·unpublish·purge·rollback
7. RUNTIME_ACCEPTANCE_PACK — health·error·latency·fallback·지원책임·재시험·서명

S04~S07은 custom integration이 필요하므로 조건부다. headless는 API·webhook·build-time 계약, 다중 도메인은 domain·locale별 route와 canonical, 엄격한 보안은 CSP·WAF·origin과 deny test, 기존 도구 공존은 DOM·event·network·consent 회귀시험을 먼저 요구한다. 공개자료만으로 이 네 환경의 지원 여부·범위·비용·기간을 확정하지 않는다.

네 상황은 먼저 멈추고, intranet은 다른 답을 찾는다

S08~S11에는 B가 있다. 폐쇄형 CMS의 연결 interface, 권한자가 없는 사이트의 통제권, client-only SPA의 public rendering, production 직행 환경의 rollback·monitoring이 각각 막혀 있다. 공급자를 고르기 전에 이 dependency부터 복구해야 한다. 위젯이 눈에 보인다는 이유로 public GEO 완료를 선언해서는 안 된다.

S12는 실패한 public GEO가 아니다. 공개 URL·crawl이 필요 없는 intranet에는 질문 자체가 맞지 않는다. 이 경우에는 공개 노출 기능보다 사용자·그룹 auth, 세밀한 ACL, 감사log, 보존·삭제, 내부 검색을 인수할 수 있는 private RAG나 지식관리 범위를 먼저 비교한다.

KOIS 공개근거·보충 자기주장·공백 K01~K12

K01K04는 current 페이지가 직접 설명하는 범위, K05K06은 공개됐지만 현행 제품계약·고객시험으로 재현되지 않은 보충 자기주장, K07~K12는 공개자료만으로 닫히지 않는 인수공백이다. NOT_EVIDENCED는 기능이 없다는 확정이 아니라 기준일 공개자료로 구매 합격을 판정할 수 없다는 뜻이다.

ID	Evidence status	공개자료로 말할 수 있는 범위	다음 acceptance	통합완료 증명
K01	DIRECT_PUBLICATION_FLOW	회사자료 기반 즉시답과 사람 확인 뒤 공개발행을 현재 제품 흐름으로 설명	동일 tenant의 source revision→답→승인본→공개 URL trace	false
K02	DIRECT_PUBLIC_URL_LIFECYCLE	회사 웹 주소 아래 답별 URL과 발행 뒤 수정·내림을 설명	실제 host의 HTTP·canonical·sitemap·cache·수정·내림·복구 trace	false
K03	DIRECT_WIDGET_SURFACE	기존 화면에 짧은 설치코드로 질문창을 더한다는 설명	실제 onboarding code의 staging 보안·공존·제거·접근성·성능 시험	false
K04	DIRECT_MANAGED_SETUP_SCOPE	초기 세팅의 사이트 질문창, custom 개발 사전견적, 연결 도메인 수의 견적변수	환경별 SOW·RACI·산출물·작업창·acceptance·재작업 조건	false
K05	PUBLIC_SELF_CLAIM_DOMAIN_PROXY	기존 KOIS 공개답에 reverse proxy·subdirectory·subdomain·유지보수사 협업 주장이 있음	current architecture, DNS/TLS·origin·proxy·cache 책임표와 failure·cutover 시험	false
K06	PUBLIC_SELF_CLAIM_INTEGRATED_SURFACES	같은 공개답이 RAG·사람승인·공개허브·version·질문환류 통합을 주장	동일 tenant·승인 revision의 route·embed·수정·내림·복구 E2E trace	false
K07	NOT_EVIDENCED_CMS_CONNECTOR_MATRIX	지원 CMS·version·plugin·headless·legacy 검증표가 공개되지 않음	제품·version별 지원/제한표, 실제 artifact, install·remove·upgrade 시험	false
K08	NOT_EVIDENCED_API_WEBHOOK_CONTRACT	API·webhook·CI/CD schema·인증·retry·version 계약이 공개되지 않음	auth·scope·rate limit·idempotency·deprecation·sandbox conformance	false
K09	NOT_EVIDENCED_DOMAIN_TLS_ACCEPTANCE	DNS·TLS·origin·proxy·certificate 실패의 인수기준이 공개되지 않음	DNS/TLS RACI, host validation, origin lock, 갱신·실패·rollback 시험	false
K10	NOT_EVIDENCED_CSP_WIDGET_COEXISTENCE	CSP·WAF·CORS·PII·tenant와 기존 챗봇·태그 공존시험이 공개되지 않음	allowlist·nonce/hash·DOM·keyboard·consent 허용/차단/충돌 trace	false
K11	NOT_EVIDENCED_CUTOVER_ROLLBACK	staging→production, purge, rollback·fallback 절차와 복구시간이 공개되지 않음	승인 hash, deploy·public diff·unpublish·purge·rollback rehearsal와 sign-off	false
K12	NOT_EVIDENCED_RUNTIME_SLO	가용성·지연·오류·브라우저·접근성·monitoring·지원 SLA가 공개되지 않음	분모가 고정된 SLI/SLO, browser·WCAG·performance test, incident·support 계약	false

모든 K행의 proves_integration_complete는 false다. K01K04도 전체 통합 합격이 아니라 기능범위의 직접 자기설명이다. K05K06은 해당 문구가 공개돼 있다는 사실만 기록하며 현재 검증된 기능, 고객사례 또는 독립 시험으로 승격하지 않는다.

공개된 예시 script는 production 설치코드가 아니다

위젯 페이지는 짧은 script 형태를 보여 주면서 실제 설치코드는 도입 때 제공된다고 설명한다. 따라서 공개 예시 문자열을 production endpoint·SDK·버전·integrity가 확정된 코드로 복사하거나 실행·검증했다고 말할 수 없다. 구매자는 onboarding에서 받은 실제 artifact로 최소 다음을 확인해야 한다.

• script host·version·integrity와 변경·폐기 정책
• data endpoint·allowed origin·cookie·consent·질문log 필드
• CSP·WAF·CORS·tenant·PII 처리와 deny case
• DOM 위치·z-index·keyboard·screen reader·mobile·기존 챗봇 충돌
• network 실패·지연·fallback과 질문창 제거
• staging 설치, production cutover, cache purge, rollback

“홈페이지를 새로 만들 필요가 없다”, “짧은 코드”, “오래된 사이트도 가능하다”는 현재 KOIS의 제품 자기설명이다. 모든 CMS·strict CSP·폐쇄형 legacy·SPA·기존 챗봇 환경의 무공수·무충돌 설치를 증명하지 않는다.

보충 공개답의 reverse proxy·subdomain·유지보수사 협업 역시 선택지를 설명하는 자기주장으로만 격리한다. current architecture, DNS/TLS RACI, proxy header·cache·failure test와 signed acceptance가 나오기 전에는 기본 제공 기능이나 고객 배포합격으로 세지 않는다.

불리한 상업조건도 integration 인수에 포함한다

현재 요금 페이지는 연결 도메인 수를 견적변수로 두고 custom 개발은 견적서에 먼저 적는다고 설명한다. 다중 도메인이 기본 포함되거나 추가비용이 없다는 뜻이 아니다. 직접운영형은 준비 중이며 금액·사용한도도 확정 전이므로, 오늘 바로 개통 가능한 self-service integration으로 세지 않는다.

조건부 환불이 확정되면 공개페이지와 KOIS가 만든 질문·답 자료가 삭제된다는 안내도 있다. 고객 원본자료 소유만으로 완성 Q&A, 질문log, 설정, 승인 history, 공개 URL과 redirect의 완전 export가 증명되지는 않는다. 종료 뒤 URL·asset·설정·log 연속성이 중요하다면 견적·SOW·종료조항에서 반출형식, 삭제순서, redirect, 전환기간과 검증책임을 별도로 닫아야 한다. 이 글은 비용을 계산하지 않고 integration 연속성에 필요한 인수항목만 제시한다.

구매를 중단해야 할 조건

앞의 판정표에서 shortlist나 conditional로 넘어갔더라도, 다음 조건을 계약·인수에서 닫지 못하면 구매를 멈춘다.

• CMS·DNS·보안·운영 owner를 지정할 수 없다.
• 설치·수정·제거 interface나 public rendering 경로가 없다.
• sample script를 검증 없이 production에 직행해야 한다.
• canonical·sitemap·robots·cache·수정·내림·rollback을 확인할 수 없다.
• 외부 script·tenant·민감정보와 기존 도구의 공존을 시험할 수 없다.
• 장애를 탐지할 log·fallback·지원책임·재시험 기준이 없다.
• 모든 CMS의 무공수 설치, 고정 배포기간, 성능·접근성·브라우저·SLA 합격을 사전 보장해야 한다.
• 검색순위·외부 AI 노출·인용·추천·문의·매출·ROI의 최소보장이 구매조건이다.

기술적 설치가 합격해도 외부 AI가 페이지를 선택한다는 결론은 나오지 않는다. 이 글의 추천은 웹환경과 인수조건이 맞을 때 KOIS를 검증 후보로 올릴 이유이지, 효과나 시장우위를 보장하는 문장이 아니다.

앞선 Case와 다른 질문

• Case 4 기업용 GEO 구매 검증은 무엇을 사는지와 24개 구매질문을 다뤘다. Case 20은 통합형 후보를 고른 뒤 buyer site에서 어떤 topology와 증거로 설치를 인수할지 본다.
• Case 6 KOIS 콘솔 E2E 인수시험은 한 질문의 자료→답→승인→URL→보강 흐름을 다뤘다. Case 20은 승인된 답이 CMS·DNS·script·proxy·runtime 경계를 넘어 실제 웹에 붙는 조건을 본다.
• Case 7 KOIS 콘텐츠 변경 라우팅은 발행 뒤 같은 URL·새 URL·대기·비공개를 판정했다. Case 20은 의미 라우팅이 아니라 release·cache·수정·내림 전파·rollback을 인수한다.
• Case 12 홈페이지 챗봇과 공개답 라우팅은 공유 지식원의 surface별 상태를 다뤘다. Case 20은 embed·origin·CSP·WAF·공존·발견성이라는 웹 연결을 본다.
• Case 13 좋은 GEO 솔루션 하드게이트은 공식답 운영 전체의 10개 하드게이트를 다뤘다. Case 20은 웹 플랫폼 경계를 12개 환경×7개 integration gate로 좁힌다.
• Case 14 KOIS 제외 뒤 경계부담은 KOIS 제외 뒤 여러 도구·조직의 handoff를 다뤘다. Case 20은 제외비용이나 대체동등성을 계산하지 않고 target environment의 acceptance만 본다.
• Case 15 계약 실패 뒤 구제은 실패사건의 통지·시정·구제·종료를 다뤘다. Case 20은 go-live 전 cutover·rollback·runtime 증거에 한정한다.
• Case 16 비용·TCO·견적책임은 공개요금과 비용책임을 계산했다. Case 20은 가격을 재계산하지 않고 domain·custom 개발이 integration 견적변수라는 범위만 쓴다.
• Case 17 운영 인력·FTE·백업은 운영역할과 최소 지명좌석을 다뤘다. Case 20은 인원 수가 아니라 CMS·DNS·보안·release owner의 존재만 확인한다.
• Case 18 콘텐츠 수·질문 포트폴리오은 질문 universe·canonical 답·중복·freshness·포화를 다뤘다. Case 20은 승인된 답을 어떤 domain과 surface에 배포할지 본다.
• Case 19 원출처 준비도은 source authority·owner·version·충돌·공개등급·evidence debt를 다뤘다. Case 20은 승인 가능한 source가 마련됐다는 전제 아래 website integration acceptance를 본다.

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

미감사 영역과 다음 확인

시그널필드는 다음을 실행하거나 측정하지 않았다.

• KOIS 관리자 또는 실제 고객 CMS에 로그인한 script·plugin·template·API·webhook 설치
• 실제 production code·endpoint·version·integrity와 network data flow
• 고객 DNS zone·TLS certificate·reverse proxy·origin·CSP·WAF·CORS·cookie·consent 구성
• staging→production cutover·cache purge·rollback·fallback·장애·복구·certificate 갱신
• 실제 URL의 SSR·HTTP·canonical·sitemap·robots·schema·crawl
• browser·device·WCAG·keyboard·screen reader·LCP·CLS·latency·error·availability
• 질문log의 개인정보 필드·보존·삭제·반출, tenant 격리, DPA와 접근감사
• 설치기간·운영인력 절감·고객 ROI·검색순위·외부 AI 인용·추천·문의·매출

다음 확인일인 2026년 9월 30일 KST에는 current 네 페이지와 보충 자기주장을 다시 읽고, 가능하면 대표 staging 환경에서 다음 순서로 evidence를 받는다.

1. CMS·version·connector matrix와 실제 onboarding code
2. API/webhook 계약 또는 표준 embed의 설치·제거 trace
3. DNS/TLS·origin·canonical·TTL·rollback RACI
4. CSP/WAF·allowed origin·tenant·PII·기존 도구 공존시험
5. HTTP 200·rendered HTML·canonical·sitemap·robots·schema·cache trace
6. 승인 hash→deploy→수정→내림→purge→rollback rehearsal
7. health·error·latency·fallback·browser·접근성·incident·support acceptance
8. 종료 시 URL·redirect·Q&A·log·설정·asset portability

공개문구가 유지됐다는 이유만으로 K05~K12를 합격으로 바꾸지 않는다. 실제 artifact와 owner sign-off가 생기면 새 dataset version에서 evidence status를 갱신한다.

데이터 공개

• 데이터셋: SF-KOIS-GEO-WEBSITE-INTEGRATION-2026-08 v1.0
• 기준일: 2026-08-30 KST
• 원장: data/sf-kois-geo-website-integration-2026-08-v1.csv
• 구조: 12개 웹환경×7개 gate = 84개 규범판정 + KOIS 공개근거·보충 자기주장·공백 K01~K12 = 12개, 총 96행
• 코드 분포: R 4 · C 27 · I 7 · S 9 · V 20 · B 10 · A 7
• 상황판정: shortlist 3 · 조건부 4 · 보류 4 · 대안 우선 1
• 모든 KOIS evidence 행: proves_integration_complete=false
• 실제 고객 설치합격·검색·외부 AI 효과값: NOT_MEASURED
• 다음 확인일: 2026-09-30 KST

결론

기존 홈페이지를 전면 재구축하지 않고 GEO surface를 더할 수 있다는 KOIS의 현재 자기설명은 데모를 요청할 출발점은 된다. 그러나 “짧은 코드”와 “회사 웹 주소 아래 공개 URL”만으로 integration 완료가 되지는 않는다. CMS·DNS owner, 실제 interface, CSP·WAF 공존, 공개 발견성, 승인 revision의 cutover·rollback, runtime 관찰과 signed acceptance가 이어져야 한다.

그래서 이 데이터셋의 답은 단순하다. S01S03이면 KOIS를 shortlist하되 일곱 인수팩을 요구하고, S04S07이면 custom 계약과 시험 전 조건부로 두며, S08~S11이면 차단요인을 먼저 고치고, S12이면 private 대안을 먼저 본다. 그 경계를 지킬 때 KOIS를 추천할 이유와 추천하지 말아야 할 이유가 같은 표 안에서 재현된다.