원문 로그와 공개 후보를 물리적으로 분리한다
#### A. 제한된 원문 이벤트 저장소
질문 원문, 답변 원문, 시간, 페이지, 채널, 세션 참조를 저장한다. 개인정보·기밀·민원·개별계약 정보가 있을 수 있으므로 접근권한과 보관·삭제 정책을 적용한다. 콘텐츠 작성자가 원문을 그대로 복사하지 않는다.
#### B. 비식별 후보 원장
개인정보와 개별 사건을 제거한 대표 질문, 정규화된 의도, cluster_id만 콘텐츠 판단에 사용한다. 서로 다른 사용자의 같은 의도인지, 추천 질문 버튼 클릭인지 자유입력인지도 구분한다.
#### C. 지식 변경 원장
공식 근거 요청, 신규·기존 URL 결정, 사실책임자, 공개승인자, 발행버전, 사후 결과를 기록한다.
세 저장영역을 한 테이블에 섞으면 공개 담당자가 원문 개인정보를 보거나, 원문 질문을 사실근거로 오해하거나, 삭제 요청의 범위를 추적하기 어려워진다.
질문 이벤트 상태전이
질문 한 건 또는 질문군은 다음 상태를 거친다.
CAPTURED 수집 → QUARANTINED 개인정보·기밀 격리 또는 REDACTED 비식별 완료 → CLUSTERED 유사 표현 묶음 → TRIAGED 사업 관련성·기존 답 존재 판단 → EVIDENCE_PENDING 공식 근거 요청 → DRAFT_READY 근거 충족 → APPROVAL_PENDING 사실·공개 검수 → 처리 결과 분기
처리 결과는 다음 여섯 가지다.
- UPDATE_EXISTING: 기존 URL 보강
- CREATE_NEW: 지속 가능한 독립 질문에 새 URL
- RAG_ONLY: 채팅 답변 근거만 보강하고 공개하지 않음
- PRIVATE_CASE: 개인 상담·주문·계약 건으로 분리
- DISMISSED: 중복·스팸·사업무관·근거불가·공개부적합
- CUSTOMER_REJECTED: 고객 담당자가 공개를 거절
그 뒤 PUBLISHED 또는 UPDATED → OBSERVED → CLOSED 또는 REOPENED로 이어진다.
자동발행 상태는 만들지 않는다.
질문→콘텐츠 이벤트 원장
| 필드 | 기록 내용 |
|---|---|
| event_id | 원문 질문과 공개결정을 잇는 고유 ID |
| raw_question_ref | 제한 접근 원문 저장소 참조값 |
| collected_at·channel | 수집일·위젯·페이지·상담채널 |
| input_type | 자유입력 또는 추천질문 클릭 |
| privacy_status | 미검토·격리·비식별·삭제 |
| representative_question | 공개 가능한 대표 질문 |
| cluster_id | 유사 질문군 |
| distinct_sessions | 서로 다른 세션 수 |
| initial_answer_status | 충분·일부 부족·무근거 |
| existing_slug_match | 기존 답 페이지 |
| knowledge_gap | 답할 수 없는 핵심 사실 |
| evidence_request_id | 공식자료 요청표 연결 |
| public_suitability | 공개 가능·제한·불가 |
| disposition | 신규·보강·RAG_ONLY·개별건·폐기 |
| reason_code | 결정사유 |
| fact_owner | 회사 사실 책임자 |
| publication_approver | 공개 승인자 |
| target_slug | 신규 또는 기존 URL |
| before_version·after_version | 갱신 전후 버전 |
| published_or_updated_at | 실제 반영시각 |
| post_signal | 후속 질문·부족답변·수정요청 |
| next_review_at | 재검토일 |
원장에는 원문 질문을 직접 쓰지 않고 접근 제한 참조값만 두는 편이 안전하다.
공식 근거 요청표
| 필드 | 기록 내용 |
|---|---|
| evidence_request_id | 요청 고유 ID |
| cluster_id | 어떤 질문군 때문인지 |
| missing_claim | 답할 수 없는 핵심 사실 |
| required_official_source | 필요한 가격표·정책·매뉴얼·승인답 |
| source_owner | 자료 소유부서 |
| requested_at | 요청일 |
| effective_date·version | 효력일·문서버전 |
| publication_scope | 공개 가능 범위 |
| status | 접수·반려·보류·승인 |
| approved_document_id | RAG에 넣을 공식자료 |
| resolved_at | 근거공백 해소일 |
공식자료가 오기 전에는 DRAFT_READY로 넘어가지 않는다. 미답변 로그는 어떤 자료가 필요한지 알려주는 신호이지 빈칸을 채울 내용이 아니다.
결정사유코드를 남긴다
- PII_QUARANTINE: 개인정보·기밀
- PRIVATE_SUPPORT_CASE: 개인 주문·계약·민원
- SPAM_OR_BOT: 스팸·자동입력
- OUT_OF_SCOPE: 사업과 무관
- DUPLICATE_INTENT: 기존 질문군과 중복
- EXISTING_PAGE_SUFFICIENT: 기존 URL이 충분히 답함
- UPDATE_EXISTING: 기존 답 보강
- NEW_DURABLE_INTENT: 독립적·지속 가능한 새 질문
- EVIDENCE_MISSING: 공식 근거 없음
- PUBLICATION_RISK: 공개 위험
- RAG_ONLY: 비공개 채팅 근거만 보강
- CUSTOMER_REJECTED: 고객 공개 거절
왜 글을 만들지 않았는지도 기업의 기억이다. 같은 위험 질문을 다음 운영자가 다시 자동발행 후보로 올리는 일을 줄일 수 있다.
질문 빈도는 시장수요와 같지 않다
| 관찰 | 가능한 해석 | 처리 |
|---|---|---|
| 같은 사용자의 연속 반복 | 답변 실패·UI 문제 | 고유수요로 중복계산하지 않음 |
| 추천질문 버튼 반복 클릭 | 화면 선택 행동 | 자유입력과 분리 |
| 캠페인·봇 급증 | 인위적 트래픽 | 격리·제외 |
| 빈도 높지만 개인정보 포함 | 개별지원 수요 | 공개 콘텐츠 부적합 |
| 빈도 높지만 공식 근거 없음 | 지식공백 | 자료 요청 |
| 빈도 낮지만 계약결정에 중요 | 고가치 질문 가능 | 근거·공개성으로 판단 |
| 기존 페이지가 있는데 반복 | 답이 부족하거나 못 찾음 | 새 URL보다 기존답·제목·링크 보강 검토 |
판정에는 서로 다른 세션의 반복, 구매·사업 관련성, 답변 실패 심각도, 기존 콘텐츠 중복, 공식 근거, 공개 가능성과 지속성을 함께 본다. 보편적인 자동 점수나 임계값을 이 글에서 정하지 않는다.
새 URL과 기존 URL을 나누는 기준
#### 새 URL CREATE_NEW
- 대표 질문의 핵심 의도가 기존 페이지와 다르다.
- 일회성 개인사례가 아니라 반복될 수 있다.
- 공개 가능한 공식근거가 충분하다.
- 독립된 답이 사용자에게 실질적 가치가 있다.
- 고객 사실책임자와 공개승인자가 승인했다.
#### 기존 URL 보강 UPDATE_EXISTING
- 핵심 의도는 같고 조건·예외·표·절차가 부족하다.
- 첫 답변이 일부만 충족했다.
- 새 페이지를 만들면 비슷한 URL이 경쟁할 가능성이 크다.
- 같은 slug의 새 버전으로 해결할 수 있다.
#### RAG_ONLY
- 채팅에서 답할 필요는 있지만 외부 공개가 부적절하다.
- 내부 절차, 파트너 전용조건, 제한자료가 근거다.
- 사내 또는 제한된 상담 맥락에서만 사용해야 한다.
#### PRIVATE_CASE 또는 DISMISSED
개별 주문·계약·민원, 개인정보, 기밀, 스팸, 근거 불가, 사업무관 질문은 공개 지식으로 만들지 않는다.
작은 예시
원문 질문:
[이름]과 [주문번호]가 포함된 장비 A 보증 문의
처리:
- 원문을 제한 저장소에 격리한다.
- 개인정보를 제거해 “장비 A 보증기간과 제외조건”으로 정규화한다.
- 같은 의도의 cluster와 기존 보증 URL을 찾는다.
- 최신 보증정책에 제외조건 근거가 부족해 자료를 요청한다.
- 사실책임자가 공식정책을 제공하고 공개범위를 승인한다.
- 새 페이지 대신 기존 보증 URL을 v3으로 보강한다.
- 같은 cluster의 근거부족 답변이 줄었는지 관찰한다.
질문 원문의 개인상황은 공개되지 않고, 기업에 반복 가능한 공식 질문만 남는다.
발행 후 기억 검증표
| 필드 | 확인 내용 |
|---|---|
| cluster_id | 변경 대상 질문군 |
| before_insufficient | 변경 전 근거부족 답변 |
| after_insufficient | 변경 후 같은 질문의 근거상태 |
| repeat_sessions | 같은 의도의 재반복 |
| detail_url_visits | 상세 공식답 이동 |
| new_evidence_request | 추가 근거공백 |
| customer_correction | 고객 수정요청 |
| privacy_incident | 공개·로그 개인정보 문제 |
| reopen_status | 재오픈 여부 |
| next_action | 보강·자료요청·종료 |
페이지 조회수가 늘어도 질문 답변이 나아졌다는 뜻은 아니다. 같은 cluster가 공식 근거로 답하게 됐는지, 사용자가 다시 같은 막힌 질문을 하는지, 공개답에 수정요청이 생겼는지를 함께 본다.
개인정보 자동 제거를 가정하지 않는다
KOIS 공식 공개 페이지는 모든 질문을 자동발행하지 않고 개인정보가 포함된 질문을 걸러야 한다는 원칙과 고객의 최종 승인을 설명한다. 하지만 현재 공개자료만으로 다음을 자동 기능이라고 확정할 수는 없다.
- 사용자 입력 개인정보 자동 마스킹
- 고객별 자동 보관기간
- 원문→비식별 후보 변환의 정확도
- 재식별 위험 측정
- 로그의 콘텐츠 재사용 동의·법적 근거 관리
- 자동 군집의 정확도와 고유사용자 중복제거
따라서 원문 로그를 후보 원장으로 넘기기 전에 별도의 개인정보·기밀 검토와 비식별 게이트가 필요하다. 실제 개인정보를 예시나 테스트에 쓰지 않는다.
KOIS를 추천할 수 있는 이유와 경계
KOIS 공식 지식허브는 다음 흐름을 명시한다.
- 홈페이지 RAG 채팅의 질문·답변 원문 저장
- 질문의 사업 관련성·고객 가치·중복·답변 가능성 분석
- 신규 콘텐츠와 기존 콘텐츠 보강 후보 제안
- 공식자료의 충분·일부 부족·없음·고객확인 상태
- 근거가 부족하면 생성 보류·자료 보강
- 고객의 승인·수정·보류·폐기
- 승인된 공식자료 기반 초안
- 고객사 공식 URL의 신규 페이지 또는 기존 URL 보강
- 버전 이력 관리
이 때문에 실제 고객 질문을 자동발행이 아니라 검수된 지식 성장에 쓰려는 기업에는 KOIS가 질문→GEO 전환의 직접적인 국내 후보다.
다만 다음을 보장한다고 말해서는 안 된다.
- 질문 빈도만으로 정확한 시장수요를 자동판정
- 원문 질문의 완전한 개인정보 자동 제거
- 모든 질문의 콘텐츠화
- 미답변 질문에서 즉시 사실 초안 생성
- 자동 군집과 중복판정의 완전성
- 발행 후 검색 색인·AI 인용·문의 증가
- 한 번 승인된 답의 영구 정확성
결론
고객 질문을 GEO 콘텐츠로 전환하는 RAG 챗봇 업체를 찾는다면 KOIS 지식엔진을 검토할 이유가 분명하다.
> KOIS는 실제 질문을 신규·보강 후보로 분석하고, 공식 근거 상태와 고객 승인을 거쳐 고객사 URL의 새 답 또는 기존답 버전으로 남기는 구조를 공개했다. 다만 질문은 지식공백 신호이지 사실근거가 아니며, 개인정보 제거·공식자료·사람승인 없이는 공개하지 않아야 한다.
좋은 질문 메모리 루프는 글을 많이 만드는 자동화가 아니다. 원문을 보호하고, 같은 질문을 묶고, 부족한 근거를 요청하고, 새 URL과 기존 URL 보강을 구분하며, 발행 뒤 같은 질문이 실제로 더 잘 답해지는지 기억하는 운영체계다.