표준답변 품질 기준점 — 승인·게이트·버전 정본

최초 작성 — 2026-06-23 · 기획자(planner)
세 전문가(IT·CS·QA) 기여물을 종합·정제한 품질·승인 기준점 단일 정본.
수집·분류·승인 프로세스는 STANDARD-ANSWER-CURATION.md가 정본이다.
이 문서는 각 상태 전이의 통과 조건(품질 게이트) 과 버전 규칙을 구체화한다.

이 문서가 해소하는 미정 항목:

• STANDARD-ANSWER-CURATION.md §3-4 미정 TODO T3 (approved 수정·버전 규칙)
• STANDARD-ANSWER-CURATION.md §7-2 T3 (세부 규칙)

→ CURATION.md §3-4와 §7-2(T3)에 "→ STANDARD-ANSWER-QUALITY.md §6으로 해소" 교차링크를 추가해야 한다(정합 §10).

1. 개요·목적·범위

1-1. 원칙

표준답변(hp_standard_answer)은 챗봇 1순위 응답 소스(FR-1 AC-1.2)다. 따라서 approval_status='approved'로의 전이는 단순 관리 액션이 아닌 품질 보증 선언이다.

승인 = 품질 보증. 승인된 표준답변은 자동으로 챗봇에 노출되므로, 게이트를 통과하지 못한 답변이 승인 상태에 진입하는 것은 허용되지 않는다.

1-2. 적용 범위

1-3. 분류 정본 참조

2. 품질 차원별 합격 기준

qa-eval 5축 정본: A 응답속도 · B 정확성 · C 명확성 · D 표준화 가능성 · E 친절도·태도

표준답변에 A(응답속도) 미적용. 표준답변은 텍스트 자산이며 실시간 생성이 아니므로 A축은 평가 대상 외다. B·C·D·E 4축으로 평가한다.

① B축 — 정확성

합격 임계: B 평균 4점 이상(5점 만점), B1 단독 3점 이하는 자동 반려.

② 완전성

완전성은 별도 점수축을 두지 않고 B2·C축 항목에 흡수한다.

③ C축 — 명확성·가독성

합격 임계: C 평균 4점 이상(5점 만점)

④ E축 — 톤·격식

표준답변은 기본 격식체(존댓말) 를 기준으로 한다. 아래 3가지 톤 유형이 있으며, 각 답변의 분류·용도에 맞는 톤을 선택해야 한다.

합격 임계: E 평균 3점 이상(5점 만점)

⑤ D축 — 구조·마크업

D축은 "이 답변이 챗봇 응답으로 재사용 가능한 형태인가"를 평가한다.

합격 임계: D 평균 3점 이상(5점 만점)

⑥ 분류·라벨 정합

분류가 미지정(topic_id=NULL)인 채 reviewing으로 전이하는 것은 원칙적으로 허용하지 않는다. 단, 긴급한 경우 reviewing 진입을 허용하되 approved 전이 전까지 분류 필수 지정(CK-5 참조).

⑦ 최신성

최신성 위반은 approved 상태에서도 archived 전이 사유가 된다(§4).

⑧ PII·비공개

이 항목은 P2-EXPOSURE-GUARD.md §4-2를 준용한다. 여기서 재정의하지 않는다.

reviewing→approved 전이 시 P2-EXPOSURE-GUARD §4-2 체크리스트 전 항목을 통과해야 한다. 구체적으로:

• 본문·이미지 캡션 PII 없음(또는 마스킹)
• 비공개 출처 파생 확인
• 고유식별정보(주민번호 등) 없음 — 있으면 승인 불가, 원천 제거 필수
• 이미지 보유 시 image_pii_status 롤업이 clear/removed/masked 상태

3. 통합 승인 체크리스트

CK 항목 전체 통과 시에만 approved 전이 가능. 자동(A) 항목은 api가, 수동(M) 항목은 승인자가 체크.
admin UI에서 M 항목은 필수 체크박스로 구현하며, 미체크 시 승인 버튼 비활성.

4. 상태 게이트별 통과 조건

CURATION §3-3의 상태 다이어그램을 계승하며, 이 문서는 각 전이의 품질 게이트를 구체화한다.

(신규) → draft

• 게이트 없음. 모든 수집 진입점(PMS·suggestions·uncovered·자료)은 검증 없이 draft로 진입.
• approval_status='draft' 저장 시 C1 자동 스캔 병행(PII 패턴·비공개 출처 플래그 세팅만, 저장 차단 아님).

draft → reviewing

이 전이는 "검토 준비 완료 선언"이며 품질 평가는 아직 일어나지 않는다.

reviewing → approved ← 핵심 게이트

CK-1~14 전항목 통과 시에만 전이 허용.

• A 항목(CK-1~4)은 api가 자동 검사 후 결과를 승인 화면에 표시.
• M 항목(CK-5~14)은 승인자(developer/admin)가 admin UI 체크박스를 직접 체크.
• 미체크 항목이 하나라도 있으면 승인 버튼 비활성.
• B1 단독 3점 이하 또는 PII 발견(마스킹 미완료) 는 자동 반려 사유 — 승인 시도 자체를 차단.
• 승인자·타임스탬프는 approved_by·approved_at·last_verified_at에 기록.

reviewing → rejected / draft → rejected

• rejection_reason 필수(비어있으면 전이 거부).
• 사유는 §7 표준 코드(ERR_*) 중 하나 이상 선택 + 자유 메모 허용.

approved → archived

• 트리거: (a) 신규본(approved)으로 대체 시, (b) 180일 재검증 실패, (c) 제품 폐기 도메인.
• 대체 보관 시 superseded_by_id에 신규본 id 기록.
• archived_reason 기록(대체·노후·도메인폐기 중 선택).
• archive 후 챗봇 노출에서 즉시 제외.

archived → reviewing (복원)

• developer/admin만 가능.
• 복원 시 last_verified_at 초기화 → 재검증 필수.

5. 품질 점수 임계 및 한계

5-1. 점수 임계 (5점 만점 각 축)

5-2. 운영 전제

• 교차 채점: 단일 평가자 편향을 줄이기 위해 경영진/CS 리드가 월 1회 무작위 표본(최소 10건)을 2인 독립 채점 후 평균.
• 점수 임계의 가정: 위 임계(B·C≥4, D·E≥3)는 현행 가정이다. 운영 3개월 후 챗봇 채택률·사용자 만족도 데이터로 재보정.
• A축(응답속도) 비적용 근거: 표준답변은 저장된 텍스트 자산으로 실시간 생성 지연이 없다. A축은 Phase 2 챗봇 응답 품질 평가(LLM 생성 답변)에서 사용한다.
• 자동 평가 한계: B1·B2 정확성·최신성은 자동 신호(버전 키워드 탐지·last_verified_at)로 후보를 가릴 뿐이며, 실제 사실 확인은 사람 평가가 필요하다. 자동 "합격"은 없다.

6. approved 수정·버전 규칙

CURATION §3-4 미정 TODO T3을 이 섹션에서 확정·해소한다. → CURATION.md §3-4와 §7-2(T3)에 "→ STANDARD-ANSWER-QUALITY.md §6으로 해소" 교차링크 추가 필요.

6-1. 수정 유형 분류

경계 판정 원칙: 판단이 모호하면 의미 변경으로 처리한다(보수 원칙). 예시:

6-2. 오타 수정 처리 (in-place)

approved 상태 in-place 수정 (원자적 전이)
1. approved → reviewing (즉시, 자동)
2. 수정 적용
3. CK 체크리스트 재확인(오타 수정은 간소 — CK-6~9 재확인 필수, 나머지는 변경 없으면 생략)
4. reviewing → approved (승인자 재승인)

• 수정 중 상태는 reviewing이므로 챗봇에서 잠시 제외된다.
• updated_at 갱신, last_verified_at 갱신.
• 동일 id row 유지(새 row 생성 없음).

6-3. 의미 변경 처리 (new row)

의미 변경 처리 (원자적 전이, 단일 트랜잭션)
1. 신규 row INSERT (approval_status='draft', supersedes_id = 기존 id)
2. 기존 row: approved → archived (archived_reason='superseded', superseded_by_id = 신규 id)
   → 두 전이는 동일 트랜잭션으로(중간 상태 없음)
3. 신규 row: draft → reviewing → approved (정규 승인 절차)

• 기존 row는 archived로 보관(삭제 아님) — HP-SCHEMA §1-6 버전 보존 원칙 계승.
• superseded_by_id(신규 id)와 supersedes_id(구 id) 양방향 링크 — 역추적 가능.
• 신규 row가 approved되기 전까지 기존 row가 approved 유지 또는 즉시 archive 중 선택:
  • 권고: 즉시 archive. 의미가 다른 두 버전이 동시에 approved이면 챗봇이 양쪽을 모두 매칭해 일관성을 해친다. 신규본이 approved되는 기간 동안 해당 주제 챗봇 응답이 빈다는 의도적 트레이드오프다.
  • 예외: 챗봇 공백이 허용되지 않는 핵심 토픽(결제·오류)이라면 신규본 승인 완료 후 구본 archive. 이 경우 승인자가 CK-5 단계에서 명시.

6-4. 버전 링크 컬럼 요약 (dba §10 참조)

7. reject 사유 표준 코드

반려(reviewing→rejected 또는 draft→rejected) 시 rejection_reason에 기록. ERR_* 코드(IT 시스템 관점)와 고객관점 사유(CS 관점)를 단일 표로 통합.

코드가 겹치는 복합 오류는 해당 코드를 콤마로 나열(예: ERR_FACT,ERR_OUTDATED).
코드 없이 자유 메모만 입력하는 것은 허용되지 않는다(자유 메모는 코드 선택 후 추가 설명으로).

8. 회귀·유지 점검

8-1. 정기 재검증 주기

last_verified_at은 승인 시점 및 재검증 확인 시점에 갱신한다.

8-2. 자동 탐지 후보

아래는 Phase 2 이후 도입을 목표로 하는 자동 신호 탐지 목록이다. Phase 1에서는 수동 점검으로 대체.

9. D축 6스타일 선택 가이드

표준답변 작성 시 목적·내용에 맞는 스타일을 먼저 선택하고, 그 형식에 맞게 구조화한다.

선택 기준 플로우:

1. 절차가 3단계 이상인가? → D-P
2. 공감·사과가 필요한 오류/환불/불편 상황인가? → D-F
3. 계약·법령·공공기관 대상인가? → D-B
4. 자주 묻는 변형이 3개 이상인가? → D-Q
5. 배경·개념 설명이 필요한가? → D-L
6. 위 모두 아니면 → D-S

혼합 사용(예: D-P + D-F)은 허용하되, 지배적 스타일 코드를 tags에 명시(예: ["style:D-P"]).

10. 정합·후속 핸드오프

10-1. CURATION.md 교차링크 추가 (기획 — 즉시)

10-2. dba — 스키마 보강 요청 (003/004 마이그레이션 후보)

hp_standard_answer 및 hp_announce에 아래 컬럼 추가. CURATION §9-A에서 요청한 컬럼 외 이 문서에서 추가 요청하는 항목만 기재.

qa_eval_* 컬럼은 운영 초기에는 수동 입력·선택적 사용이며, Phase 2 이후 자동화 점수 파이프라인 연동 시 활성화한다. 도입 시기는 미정(dba와 추가 합의).

P2-EXPOSURE-GUARD.md §4-B에서 요청한 pii_text_status·private_source_flag·image_pii_status·pii_checked_by/at 컬럼은 P2 §4-B가 정본이며 이 문서에서 중복 요청하지 않는다.

10-3. api — 전이 시 자동 게이트 요청

10-4. admin — 승인 UI 요청

11. 결정 사항 요약

12. 알려진 한계·후속

• 점수 임계 재보정: 현 B·C≥4, D·E≥3은 운영 전 가정값. 채택률·사용자 피드백 데이터가 쌓이면 재보정.
• 자동 평가 미구현: B1 정확성·C 명확성의 자동 점수 산출은 현재 미구현. Phase 2 LLM 기반 평가 파이프라인 도입 시 자동화 가능.
• qa_eval_ 컬럼*: 도입 시기 미정(dba + 기획 추가 합의 필요).
• D-스타일 혼합 기준: 혼합 사용 시 "지배적 스타일"의 경계 판정이 주관적일 수 있음 — 운영 중 사례 축적 후 판정 가이드 보완.
• S3~S6 자동 탐지: Phase 2 목표. Phase 1에서는 수동 재검증으로 대체.
• hp_announce 준용: 이 문서의 기준은 Q&A에 최적화됐으며, 안내글(hp_announce)은 유효기간·말투 등 차이가 있으므로 별도 기준 보완 문서가 필요할 수 있다(미정 TODO).