표준답변 수집·큐레이션 강화 — 도메인 기획·정책 정본

최초 작성 — 2026-06-17 · 기획자(planner) · malgn-helper-admin 표준답변 자산의 수집·분류·승인·중복·선순환·KPI를 정의하는 정본

상위 정본: REQUIREMENTS.md FR-1/FR-5/FR-7 · ADMIN-PLAN.md §4-3 · HP-SCHEMA.md §3-3 · ROADMAP.md

이 문서는 위 정본들과 충돌 시 표준답변 큐레이션 영역에 한해 정본이다. 충돌 항목은 §8(정합·현행화)에 명시하고 해당 문서를 갱신하도록 넘긴다.

1. 개요

1-1. 목적

표준답변(hp_standard_answer)은 챗봇 응답의 1순위 소스(FR-1)이자 P1 상담사 보조의 핵심 자산이다. 현재 테이블은 수집(저장) 기능만 있고 분류·승인 단계·중복 감지가 없어 다음 문제가 있다.

• 분류가 없어 scope/topic/service_tag 기반 매칭(FR-1 AC-1.3)이 불가능 — 같은 topic=환불이라도 서비스별로 답변이 다른데 구분 못 함.
• 승인 단계가 없어 approved만 응답에 쓴다(FR-1 AC-1.2)는 규칙을 실행할 수 없음 — 현재 status 1/-1뿐.
• 중복 감지가 없어 유사 질문 표준답변이 난립 → 일관성(NFR-2) 위협.

이 문서는 위 3대 공백을 메우는 분류 체계 · 승인 워크플로 · 중복/병합 · 수집 선순환 · 커버리지 KPI를 정의하고, 실제 구현(DDL·코드·인덱스)을 dba/api/admin/pms에 넘길 요구사항으로 분해한다.

1-2. 범위

1-3. 권한 (역할별, ADMIN-PLAN.md §2-1 준수)

핵심 분리: agent는 제안·분류까지, 승인은 admin/developer(FR-5 AC-5.1). 챗봇은 approved만 사용(FR-1 AC-1.2).

2. 분류 체계

2-1. 분류 축 (정본 — ADMIN-PLAN.md §4-3-1 계승)

표준답변(hp_standard_answer, Q&A)은 2축(scope·topic) + service + 자유 태그로 분류한다.

안내글은 분류 축이 아니라 별도 테이블 — 직원 작성 공지·안내("표준 안내답변")는 hp_standard_answer.answer_type 컬럼이 아니라 **별도 테이블 hp_announce**로 관리한다(2026-06-18 결정, PMS-INQUIRY-HARVEST.md §5-3). 이전 answer_type ENUM('qa','announce') 권고는 폐기. hp_announce는 위 분류 축(scope/topic_id/service_id/tags)과 승인 워크플로(§3)를 공유하되 질문 컬럼이 없고 유효기간(valid_from/valid_to)을 가진다. admin에서 별도 메뉴로 분리한다(§9-C).

카탈로그 정본: hp_service = PMS-INQUIRY-HARVEST.md §4-2의 7서비스(OTT·범용·글로벌·공공·유지보수·환급·독립). hp_topic = TOPIC-CATALOG.md의 24토픽(common 20 + service 4). 002 시드(서비스 6종·토픽 10종)는 목업 — 재시드 대상.

결정 — FK는 slug가 아니라 id로 연계한다. ADMIN-PLAN §4-3-4는 topic VARCHAR(50)(slug 매칭)을 제안했으나, 002 마이그레이션이 hp_topic/hp_service를 id PK + (scope,slug) UNIQUE로 이미 실체화했다(migrations/002_admin_console.sql). slug는 운영자가 정정할 수 있어(catalog.vue 편집) 불안정하므로 *_id FK를 정본으로 한다. 단 FK 제약은 걸지 않는다(HP-SCHEMA §1 원칙 — 애플리케이션 레벨 검증). 응답·로그에는 slug를 조인해 노출.

2-2. 카탈로그 정합 — 정본 확정 (2026-06-18)

확정 — hp_topic 토픽 정본은 TOPIC-CATALOG.md의 24토픽(common 20 + service 4)으로 확정됐다(2022~2026 PMS 문의 실데이터 기반). hp_service는 PMS-INQUIRY-HARVEST.md §4-2의 7서비스. 아래 002/ADMIN-PLAN 시드 비교는 재시드 전 이력(historical) 으로 보존하며, 정본은 위 두 문서다. T1·T7 해소(§7-2).

002 마이그레이션의 실제 시드와 ADMIN-PLAN §4-3-1 문서가 달랐다(아래는 재시드 대상 이력).

hp_topic 시드 (002 실데이터) — CS 도메인 중심: login(로그인/계정) · enrollment(수강신청) · payment(결제/비용) · refund(환불/취소) · certificate(수료증/자격증) · content(콘텐츠/학습) · schedule(일정/기간) · technical(시스템 오류) 이상 common · step(STEP 전용) · lms-global(글로벌 LMS) 이상 service

ADMIN-PLAN §4-3-1 문서 토픽 — IT 일반 중심: domain/seo/it-general/account/payment common · feature/legal/policy/pricing/integration service

hp_service 시드 (002 실데이터): step(STEP 온라인) · lms-general(범용 LMS) · lms-mixed(혼합 LMS) · lms-private(민간 인증) · lms-public-security(공공 보안) · lms-global(글로벌)

ADMIN-PLAN §4-3-1 문서 서비스 (LMS 패밀리 6종): lms-general/lms-refund/lms-public/lms-security/lms-hybrid/lms-global

기획 판단: 실데이터(002)는 실제 CS 문의 도메인(로그인·수강·환불·수료증)에 맞춰 시드된 것으로, 고객 문의 분류에 더 적합하다(PROJECT-INQUIRY-ANALYSIS의 실제 문의 분포와 정합 검토 필요). ADMIN-PLAN 문서값은 초기 기획 시 IT/법령 관점 예시였다.

권고 — hp_topic/hp_service 정본은 "002 시드 + 운영자 catalog.vue 편집본"으로 하고, ADMIN-PLAN §4-3-1 표를 002 시드값으로 현행화한다. 단 다음은 보완 검토:

• 환급 LMS(lms-refund)·혼합(lms-hybrid)은 ADMIN-PLAN의 핵심 도메인 근거(고용보험법·복합 룰)였는데 002 시드엔 lms-mixed/lms-private/lms-public-security로 재명명됨 → 명칭 통일 결정 필요(§8-A).
• 법령·약관(legal) 토픽은 002 시드에 누락 — 서비스별 법령 답변 분류가 필요하면 추가.

2-3. 매칭 규칙 (FR-1 AC-1.3 — 챗봇/추천 시 적용, Phase 2 동작)

1. 질문 → LLM이 scope + topic 추론
2. scope=service이면 사용자가 쓰는 서비스(service_id)로 필터
3. scope=common이면 service 무관 매칭
4. 동점 시 tags 매치 수 + usage_count(채택수) 우선
5. approval_status=approved만 후보(FR-1 AC-1.2)
6. 매칭 N개를 LLM 컨텍스트에 첨부 + 출처 인용(FR-2)

3. 상태 모델·전이 (승인 워크플로)

3-1. 현재 → 목표

현재 hp_standard_answer.status는 **1(활성)/-1(삭제)**뿐이다. 이걸 승인 단계로 쓸 수 없다(저장 즉시 활성=무검증 답변이 챗봇에 노출 위험).

결정 — status(soft-delete)와 approval_status(승인 단계)를 분리한다. HP-SCHEMA §1-2의 "모든 테이블 status 1/-1 통일" 원칙을 유지하면서, 승인은 별도 컬럼으로.

3-2. 상태 정의

3-3. 전이 다이어그램

                ┌──────────────────────────────────────────┐
                │                                          │
  [신규 제안]   ▼                                          │ (재작업)
   ────────► draft ──(검토 착수)──► reviewing ──(승인)──► approved
                │  ▲                    │                    │
                │  └──(반려·재작업)──────┤                    │ (대체·노후)
                │                       │                    ▼
                └──────(반려)──────────►└──► rejected     archived
                                                              │
                                          (복원: archived → reviewing)

3-4. 정책 결정

• PMS·suggestions 경유 저장은 항상 draft로 진입. 무검증 답변이 챗봇에 직행하지 않게 함(FR-1 AC-1.2 보장).
• 반려는 사유 필수(rejection_reason) — 재작업 신호.
• approved 1건 수정 시: 경미한 오타는 approved 유지 + updated_at 갱신. 의미 변경은 새 row append(HP-SCHEMA §1-6 버전 보존 원칙)로 신규본을 reviewing에 두고 구본을 archived 권고. → 세부 규칙은 STANDARD-ANSWER-QUALITY.md §6으로 해소 (2026-06-23).

4. 중복 감지·병합

4-1. 저장 전 유사 탐지

표준답변 저장(제안) 시 질문 유사도로 기존 항목과 중복을 탐지해 운영자에게 경고한다. 난립을 막아 일관성(NFR-2)을 지킨다.

탐지 기준 (단계적 도입)

임계값(0.85/0.92)은 초기 가정 — 운영 데이터로 튜닝(§7 미정). 미커버 질문 클러스터링 임계(cosine ≥ 0.8, ADMIN-PLAN §4-5-1)와 별개 값임에 유의(중복 판정은 더 엄격).

동작: 저장 직전 POST /standard-answers/check-duplicate(또는 저장 응답에 similar[] 동봉) → 유사 후보 top N(점수·label·scope/topic) 표시 → 운영자가 (a) 그래도 신규 저장 / (b) 기존 항목 편집으로 이동 / (c) 병합 선택.

4-2. 병합 정책

두 표준답변을 하나로 통합할 때:

• 생존 row(primary): 운영자가 선택(보통 approved·usage_count 높은 쪽).
• 흡수 row(secondary): status=-1(soft delete) + merged_into_id에 primary id 기록(역추적·되돌리기).
• 보존 항목:
  • usage_count(채택수): primary += secondary (합산) — 채택 신호 손실 방지.
  • 출처(source_post_id·source_axis): primary가 NULL이면 secondary 값 승계. 다중 출처는 source_refs JSON에 누적(미정 — §7).
  • tags: 합집합.
  • last_used_at: 더 최근 값.
• 병합은 developer/admin만. agent는 중복 의심 "병합 제안"만(메모) — Phase 2 정교화.

4-3. 미커버 질문 클러스터링과의 관계

• 중복 감지(§4-1)는 표준답변 ↔ 표준답변 간. 미커버 클러스터링(ADMIN-PLAN §4-5-1)은 미커버질문 ↔ 미커버질문 간. 동일 임베딩 인프라를 쓰되 목적·임계가 다르다.
• 미커버 질문을 표준답변 후보로 전환(§5-1)할 때는 기존 표준답변과의 중복(§4-1)도 함께 검사 — 이미 답이 있는데 미커버로 잘못 분류된 경우를 거른다.

5. 수집 선순환 (자산 환류)

표준답변은 4개 진입점에서 수집되고, 사용 피드백이 다시 우선순위·후보로 환류한다(FR-7).

PMS 대량 수집 파이프라인(기간·프로젝트 스캔 → 서비스 자동배정 → 안내글/Q&A 분기 → 토픽 분류 → draft)은 PMS-INQUIRY-HARVEST.md가 정본이다. 그 파이프라인의 출력(draft)이 아래 진입점 ①(PMS)과 동급으로 본 큐레이션 워크플로에 합류한다.

                    ┌─────────────────────────────────────────────┐
                    │                                             │
  ① PMS QaEvalCard  │   ② suggestions      ③ 미커버 질문 큐        │  ④ 자료(materials)
  "표준답변 저장"   │   (LLM 후보추출)     (uncovered→후보)        │   에서 추출
        │           │        │                    │               │        │
        ▼           ▼        ▼                    ▼               ▼        ▼
   ┌──────────────────────────────────────────────────────────────────────────┐
   │  hp_standard_answer  (draft → reviewing → approved)                       │
   └──────────────────────────────────────────────────────────────────────────┘
        │ approved                                          ▲
        ▼                                                   │ 채택수↑ → 우선순위·후보 추천
  챗봇/추천 응답 ── 사용(usage_count++) · 채택(/use) ───────┘
        │
        └─ 답 못함(is_unknown / confidence<0.5) → 미커버 큐(③로 환류)

5-1. 미커버 질문 → 표준답변 후보 전환 (FR-7 AC-7.2)

• 챗봇이 is_unknown 또는 confidence<0.5로 분기한 질문 → hp_uncovered_question에 누적·클러스터링(cosine≥0.8).
• 같은 의미 주 3건 이상이면 후보 큐 등록 + Slack 알림(ADMIN-PLAN §9 기본값).
• POST /uncovered/:id/draft-sa로 표준답변 초안 생성(챗봇 응답 로직 재사용 — ADMIN-PLAN §4-5-2). 생성된 초안은 draft + source_uncovered_id 기록 + 미커버 추정 분류(estimated_scope/topic/service)를 초기 분류로 승계.
• 저장 시 §4-1 중복 검사 동반.

5-2. 채택 피드백 → 우선순위 (FR-7 AC-7.1)

• POST /standard-answers/:id/use로 usage_count++·last_used_at 갱신(이미 구현, requireServiceToken).
• 매칭 동점 시 usage_count 우선(§2-3). 자주 채택된 답변이 상위 노출.
• P1 상담사 채택 신호: AI 추천 답변(FR-6)을 상담사가 "채택"하면 그 근거 표준답변의 usage_count도 환류(Phase 1에서 선순환 시작). → 채택/수정/거절 구분 집계는 미정(§7).

5-3. suggestions(LLM 후보 추출)

• POST /pms/projects/:id/standard-answer-suggestions가 직원 응답(비공개 제외)에서 반복 패턴을 추출(이미 구현). 결과는 저장 전 후보일 뿐 → 운영자가 standard-answers/suggestions 화면에서 검토 후 POST /standard-answers(=draft).
• 추출 후보에 분류(scope/topic/service) 자동 추론 필드 추가 권고 — 현재 suggestions 응답은 label/question/answer/frequency만 반환(§6-B api 요구).

5-4. PMS QaEvalCard "표준답변으로 저장" (D축 템플릿)

• D축 답변 템플릿 6종(짧은/긴/친절/비즈니스/FAQ/단계별) 중 선택분을 저장 → source_axis='D'.
• 이미지 경로는 절대 URL 정규화 완료(PMS_ASSET_BASE, 2026-06 적용).
• 저장 시 분류 미지정이면 draft + 분류 NULL → 운영자가 admin에서 분류·승인.

6. 커버리지 KPI

도메인(topic/service)별 표준답변 자산의 건강도를 측정. admin 홈(§4-1)·/analytics/quality에 노출.

커버리지 갭이 핵심 운영 지표 — "미커버는 많은데 표준답변이 적은 도메인"을 자료·표준답변 보강 1순위로 노출(수집 선순환의 방향타).

KPI는 Phase 1에서 표준답변·미커버 수집이 시작되면 계산 가능하나, 채택률·미커버 수는 Phase 2 챗봇 가동 후 실데이터가 채워진다(ROADMAP Phase 구분 유지).

7. 정책 결정 사항 / 미정 TODO

7-1. 결정 (이 문서로 확정)

7-2. 미정 TODO (추가 합의·결정 필요)

8. 정합·현행화 (다른 정본과의 충돌)

§8-A·8-B는 dba/api 후속 작업이 진행되면 ADMIN-PLAN·HP-SCHEMA 정본도 함께 갱신해야 한다(임의 단정 금지 — T1 확정 후).

9. 연결점 — 후속 작업 요구사항

실제 DDL·코드·인덱스는 dba/api/admin/pms가 만든다. 아래는 요구사항이다.

9-A. DBA — 스키마 요구사항 (003 마이그레이션 후보)

추가(2026-06-18): 안내글은 hp_standard_answer에 answer_type 컬럼을 더하지 않고 별도 테이블 hp_announce로 신설한다(004 후보, PMS-INQUIRY-HARVEST.md §5-3·§9-A). hp_announce는 아래 분류·승인 컬럼 셋(scope/topic_id/service_id/tags/approval_status/approved_*/usage_count/...)을 hp_standard_answer와 동형으로 공유 + title/body/valid_from/valid_to(질문 컬럼 없음). hp_topic(24토픽)·hp_service(7서비스) 재시드도 병행(TOPIC-CATALOG.md §4).

hp_standard_answer 컬럼 보강 (모두 NULL 허용/DEFAULT로 기존 데이터 무영향):

인덱스:

• idx_approval (approval_status, status) — 승인 대기 큐·챗봇 approved 필터
• idx_scope_topic (scope, topic_id, service_id, status) — 분류 매칭(§2-3)
• idx_merged (merged_into_id) — 병합 역추적
• 기존 FULLTEXT idx_qa는 한국어 ngram parser 미설정 상태(코드가 LIKE 사용 중) → ngram 파서 도입 또는 OpenSearch 이관 결정(T2 관련)

⚠ 운영 DB는 MySQL 5.6.51(메모리 prod-db-host). JSON 타입·DEFAULT (expr) 미지원 → tags는 LONGTEXT(JSON 직렬화, HP-SCHEMA §1-4 원칙) 권고. ENUM 추가는 5.6 OK. dba가 버전 타깃 확정.

9-B. API — 엔드포인트 변경 요구사항

9-C. ADMIN — 화면 요구사항

• /standard-answers 목록: scope/topic/service/승인상태 필터 컬럼·배지(ADMIN-PLAN §4-3-2 목업대로) + 실데이터 분류 연동(현재 분류 컬럼 미존재).
• 상세·편집: 분류 셀렉터(hp_topic/hp_service 카탈로그 연동) + 승인/반려 버튼(권한 분기) + 반려 사유 입력 + 중복 경고 패널(저장 시 similar[]).
• /standard-answers/suggestions: 후보 검토 → draft 저장(분류 자동 추론값 프리필).
• 표준 안내답변 별도 메뉴 /announces(2026-06-18): hp_announce 전용 목록·상세·승인. Q&A /standard-answers와 분리된 IA 메뉴(탭 아님). 안내글 전용 필드(title·유효기간) 노출. 토픽/서비스 분류·승인 워크플로는 동일 UX 공유.
• 홈//analytics/quality: §6 KPI 카드(커버리지 갭·승인율·채택률).
• 사이드바 배지 "승인 대기 N"(ADMIN-PLAN §3-2 그룹2.1)을 approval_status IN(draft,reviewing) 카운트로.

9-D. PMS — 요구사항

• QaEvalCard "표준답변으로 저장" 시 선택적 분류 입력(scope/topic) 추가 또는 미지정 허용(admin에서 후분류). 저장은 항상 draft임을 UI에 명시("승인 후 챗봇이 사용").
• suggestions 후보 카드에 분류 추론값 표시(T6 반영 시).

9-E. PRIVACY-OFFICER — 협의 요구사항

• 비공개 출처(tb_post_comment.private_yn='Y')에서 파생한 표준답변의 P2 노출 가드(T8/§8-D): 본문 일반화 검증 + 출처 역추적·인용 표기 시 마스킹 정책. FR-10·HP-SCHEMA §7 정합.

10. 현재 구현 상태 (2026-06-17 기준)

11. 알려진 한계·후속

• MySQL 5.6 제약: JSON 타입·표현식 DEFAULT 미지원 → tags는 LONGTEXT, FULLTEXT 한국어는 ngram 미설정. OpenSearch 이관이 근본 해법(자료 인덱싱과 동기).
• 임베딩 의존: 중복 cosine·분류 자동 추론은 OpenSearch/임베딩 셋업(Phase 1 후반) 후에야 정밀. 그 전까지 LIKE·토큰 기반 MVP.
• Phase 경계: 미커버→후보·채택률 KPI는 Phase 2 챗봇 가동 후 실데이터. P1에서는 PMS·suggestions·상담사 채택 신호로 선순환을 먼저 시작한다(ROADMAP Phase 구분 유지).
• 본 문서 확정 항목 중 카탈로그(T1)·중복 임계(T2)는 운영 데이터로 재튜닝 — 결정 시 docs/history/에 누적.