PMS 문의·답변 → 표준답변 수집 절차 — 도메인 기획·정책 정본

최초 작성 — 2026-06-18 · 기획자(planner) · PMS(tb_post/tb_post_comment)에 누적된 문의·답변을 표준답변/표준 안내답변으로 수집·분류·등록하는 단계별 절차의 정본

상위/연계 정본: STANDARD-ANSWER-CURATION.md(큐레이션·승인 워크플로) · ADMIN-PLAN.md §4-3 · HP-SCHEMA.md · PROJECT-INQUIRY-ANALYSIS.md · REQUIREMENTS.md

포지셔닝: 이 문서는 STANDARD-ANSWER-CURATION.md의 상위 수집 파이프라인이다. 본 문서는 "PMS에서 무엇을 어떤 순서로 끌어와 어떻게 분류·태깅해 draft로 만드는가"(수집 단계)를 정의하고, draft 이후의 검토·승인·중복/병합·KPI는 큐레이션 정본에 위임한다. 두 문서의 경계는 §4-6 단계 ⑦에서 명시한다.

1. 개요

1-1. 목적

PMS(맑은프로젝트게시판)에는 약 1,358건의 Q&A 후보가 200여 프로젝트에 누적돼 있다(PROJECT-INQUIRY-ANALYSIS.md). 이 자산을 챗봇/상담사 보조의 1순위 소스인 표준답변(hp_standard_answer)으로 환류시키려면, 수집 대상 선별 → 서비스 자동 배정 → 안내글/Q&A 분기 → 토픽 분류 → 후보 가치 판단 → draft 등록 → 검토·승인까지의 절차가 표준화돼야 한다.

이 문서는 그 **단계별 절차(파이프라인)**를 정본화하고, 각 단계의 입력·처리·출력·자동/수동 경계를 못박는다. 실제 DDL·코드·인덱스는 dba/api/admin/pms가 만들며, 본 문서는 그들에게 넘길 요구사항을 §9에 분해한다.

1-2. 범위

1-3. 권한 (수집 단계, ADMIN-PLAN.md §2-1 준수)

수집 단계의 서비스 자동 배정·staff 판정은 결정적(rule) 처리라 자동, 토픽 분류·후보 채택은 사람 검토 게이트가 있다(§7).

2. 전체 파이프라인 한눈에 (7단계)

  ① 스캔            ② 서비스 배정       ③ 안내글/Q&A 분기   ④ 토픽 분류
 PMS tb_post   →  group.name→service  →  작성자 staff?    →  LLM topic 추론
 (기간·프로젝트)    (A 매핑, 결정적)      (C, 결정적)          (B, LLM + 보류)
 제외 룰 적용                              │                     │
      │                                   ├─ staff 첫글 → 안내글  │
      ▼                                   └─ 그 외 → Q&A          ▼
 ⑤ 후보 가치 판단  →  ⑥ draft 등록  →  ⑦ 검토·승인
 답변 존재·재사용성    분류·트랙별 테이블   admin이 approved
 (반자동: 점수+사람)   approval_status=draft  → 큐레이션 정본으로 위임
                       Q&A→hp_standard_answer / 안내글→hp_announce

• 결정적(자동) 단계: ① 제외 룰, ② 서비스 배정, ③ staff 판정.
• LLM + 보류 단계: ④ 토픽 분류(신뢰도 낮으면 미분류 보류).
• 반자동(점수 + 사람) 단계: ⑤ 후보 가치 판단.
• 수동(사람 확정) 단계: ⑥ draft 확정 태깅, ⑦ 승인.

수집 파이프라인의 **출력은 항상 draft**다. 무검증 답변이 챗봇에 직행하지 않게 하는 게이트(STANDARD-ANSWER-CURATION.md §3-4·FR-1 AC-1.2).

3. 그룹 → 서비스 자동 배정 (A 규칙 · 정본)

3-1. 매핑 테이블 (정본 — 고정)

PMS tb_project_group.name(API가 이미 group_name으로 조회 — ../malgn-helper-api/src/index.ts /pms/projects)을 hp_service에 결정적으로 매핑한다.

⚠ 2026-06-18 현행화 — api(DRAFT 분석)가 발견한 실측 DB 그룹명으로 매핑 표를 교체했다(TOPIC-CATALOG-DRAFT.md §1-3). 이전 표의 OTT서비스(공백 누락)·글로벌이러닝 서비스(≠실측 글로벌LMS 서비스)·맑은이러닝 종료(누락) 등을 실측값으로 정정. 매칭 키는 아래 "PMS 그룹명(실측)" 컬럼이다.

서비스는 7종(OTT·범용·글로벌·공공·유지보수·환급·독립). 그룹 #2·#3·#4 세 그룹이 "범용"(general)에 매핑된다(오픈전/오픈후/종료 구분은 서비스 식별엔 영향 없음 — 동일 범용 자산. 단 맑은이러닝 종료는 노후 가드 태그). #10~#12(완료/진행/파트너)는 자동 배정 않고 hold_service 보류.

3-2. 매칭 방식·정규화

• 매칭 키는 tb_project_group.name의 trim + 정확 일치(대소문자·공백 정규화). PMS 그룹명은 운영자가 수기 입력하므로 공백/괄호 변형 흡수(예: 맑은이러닝 서비스（오픈전） 전각 괄호 → 반각 정규화).
• 매핑은 코드 상수가 아니라 데이터로 둔다(운영자가 catalog에서 편집 가능). → §4-A hp_service_group_map 또는 hp_service.match_group_names JSON 중 택1(dba 결정, §9-A).

3-3. 미매핑 그룹 처리 규칙

표에 없는 그룹명(신규 그룹, 사내 게시판 등)을 만나면:

보류된 미매핑 그룹은 admin 수집 큐에 "서비스 미배정"으로 모여, 운영자가 (a) 매핑 테이블에 그룹 추가 또는 (b) 수집 제외를 결정한다.

4. hp_service 카탈로그 재정의 (002 → 재시드 제안)

4-1. 충돌 — 002 시드는 사용자 7서비스와 다름

../malgn-helper-api/migrations/002_admin_console.sql의 hp_service 시드는 step/lms-general/lms-mixed/lms-private/lms-public-security/lms-global 6종으로, 사용자가 준 A 규칙의 7서비스(OTT·범용·글로벌·공공·유지보수·환급·독립)와 불일치한다. A 규칙은 PMS 그룹명에서 직접 도출된 실데이터 기반이므로 이쪽을 정본으로 재정의한다.

4-2. 재시드 제안 (slug/name 안)

4-3. 마이그레이션 영향 (dba 위임)

• 002 시드 6종(step/lms-*)은 목업 기반 가상값으로, 실제 hp_standard_answer.service_id 참조가 아직 없다(분류 컬럼 자체가 미실체화 — STANDARD-ANSWER-CURATION.md §8-B). 따라서 재시드 시 데이터 유실 위험은 낮다.
• 결정 필요(dba): (a) 002 시드 6종을 status=-1 soft-delete 후 7종 신규 INSERT, 또는 (b) 기존 행을 7종으로 UPDATE(slug 재매핑). 운영 catalog에서 이미 편집됐는지 확인 후 결정.
• 큐레이션 정본의 미정 항목 **T1(카탈로그 정본 확정)**이 이 재정의로 부분 해소된다 → STANDARD-ANSWER-CURATION.md §2-2·§7-2 T1과 ADMIN-PLAN.md §4-3-1 표를 이 7서비스로 현행화(§10 핸드오프).

⚠ 이 재정의는 hp_service(서비스 축)만 다룬다. hp_topic(토픽 축) 정본은 별도이며 §6·큐레이션 T1에서 다룬다.

5. 단계별 절차 — 상세

5-1. ① PMS 문의 스캔 (대상 선별)

스캔 범위 권고(노후화 리스크 반영):

• 데이터 대부분 2022년 상반기 → 최신 답변 우선. 1차 스캔은 2025~2026 활동분 또는 운영자가 지정한 Top 프로젝트부터(PROJECT-INQUIRY-ANALYSIS.md §8-7).
• 종료 프로젝트(*)는 수집 가능하되 "현재 시스템과 다를 수 있음" 가드 태그 부여(§6-tags, PROJECT-INQUIRY-ANALYSIS.md §7).

5-2. ① 제외 룰 (수집 대상에서 빼는 것 — 결정적)

⚠ 2026-06-18 제외 룰 보강 — api(DRAFT §1-3)가 사내 게시판이 그룹명에 숫자 prefix가 없는 경우(보고/결재·이러닝컨설팅팀·종료/마감/보관·이러닝개발팀·학습조직·이러닝사업팀 — 모두 staff 100%)를 지적. 프로젝트명 ^[0-9]+\. REGEXP만으로는 안 걸린다. 아래에 그룹명 화이트리스트 + staff비중 안전망을 추가한다.

5-3. ③ 안내글 vs Q&A 분기 (C 규칙 · 결정적)

※ 단계 순서상 ②(서비스 배정) 다음이 ③(분기)이나, 분기 룰이 이후 모든 처리(④토픽·⑤가치판단)에 영향을 주므로 먼저 상술한다.

핵심 룰: 게시글의 첫 작성자가 우리 회사 직원(isStaff — @malgnsoft.com OR company='맑은소프트', ../malgn-helper-api/src/classify.ts)이면 그 글은 질문이 아니라 "안내글"(고객 대상 공지·안내)일 가능성이 높다.

• 입력: 게시글 작성자(tb_post.user_id → tb_user.email/company)에 classify.ts의 isStaff 적용. API는 이미 u_is_staff 계산식을 /pms/posts/:id/announce-eval에서 사용 중(../malgn-helper-api/src/index.ts:1483).
• 처리: isStaff=true → 안내글 트랙. 안내글은 본문 자체가 답변 콘텐츠(질문+답변 쌍이 아님) → ⑤ 가치 판단 기준이 다르다(§5-5).
• 출력: 트랙별 테이블 분리 — Q&A는 hp_standard_answer, 안내글은 hp_announce(아래 설계). 안내글 처리에는 기존 /pms/posts/:id/announce-eval/generate(직원 안내글 3축 평가 + 안내문 템플릿 3종 생성, ../malgn-helper-api/src/index.ts:1470) 재활용.
• 경계: 자동(결정적 룰). 단, "staff가 고객 질문을 대리 등록한 경우"(예: 전화 문의를 직원이 받아 적음)는 안내글이 아닐 수 있어 → ⑥/⑦ 사람 검토에서 트랙(테이블) 정정 가능(오버라이드, §7).

안내글 = 별도 테이블 hp_announce (2026-06-18 결정 — answer_type ENUM 권고 폐기)

변경 이력: 본 절은 이전에 안내글을 hp_standard_answer.answer_type ENUM('qa','announce') 단일 컬럼으로 구분하는 안 A를 권고했다. 2026-06-18 사용자 결정으로 안 A를 폐기하고, 안내글 전용 테이블 hp_announce로 물리 분리한다(아래 3안 중 (이전)C안 채택). 사유: 안내글(공지)과 Q&A는 데이터 형상(질문 유무)·승인 기준·챗봇 사용 방식·관리 메뉴가 본질적으로 달라, 한 테이블에 섞으면 NULL 컬럼·분기 조건이 누적되고 관리자 UX가 모호해진다. 운영자(기획)는 표준답변과 안내글을 admin에서 별도 메뉴로 다루기로 확정(§9-C) — 테이블 분리가 메뉴 분리와 정합.

hp_announce 설계 개요 (DDL·인덱스는 dba 소관 — 본 절은 요구사항/연결점):

안내글에 question을 억지로 채우던 이전 미정 TODO H3(질문 NULL 허용 규칙)은 hp_announce.title로 해소 — 안내글에는 question 개념 자체가 없다.

마이그레이션: answer_type 컬럼은 신설하지 않는다(004 후보에서 제외). 대신 hp_announce 신규 테이블(dba). hp_standard_answer는 Q&A 전용으로 단순 유지(CURATION §9-A 003 분류 컬럼은 그대로).

5-4. ② 서비스 자동 배정

5-5. ④ 토픽 LLM 분류 (B 규칙)

프롬프트 입력/출력 규약:

• 입력: { 본문, scope_hint(공통/서비스), 서비스명, 카탈로그[{slug,label,description}] }. 이름·회사로 도메인 추정 금지(분류 규칙 — 본문 내용만 근거).
• 출력(JSON): { topic_slug | null, confidence(0~1), new_topic_suggestion?: {label, reason}, reason }.
• 신뢰도 정책:
  • confidence ≥ 임계(기본 0.6, hp_settingsafetyconfidence_threshold 재사용 검토 또는 분류 전용 키) → topic_id 자동 태깅(단 ⑥에서 사람이 최종 확인).
  • confidence < 임계 → topic_id=NULL 미분류 보류 + 수집 큐에 "토픽 확인 필요"로 표시.
  • new_topic_suggestion 있으면 → 자동 생성 금지, 운영자 검토 후 catalog에 토픽 추가 결정(임의 카탈로그 증식 방지).

scope(common/service) 자체도 LLM이 보조 추론하나, 서비스 특화 여부 최종 판단은 사람이 ⑥에서 확정(서비스 배정 ②는 결정적이지만 "이 답변이 그 서비스에만 유효한지 vs 전사 공통인지"는 의미 판단).

5-6. ⑤ 표준답변 후보 가치 판단 (반자동)

수집 후보가 표준답변으로 등록할 가치가 있는지 점수화 후 운영자가 채택한다.

• 처리: 규칙 점수(신선도·답변 유무·길이) + 선택적 LLM 보조(재사용성 판단). 점수는 정렬·추천용이고 채택 결정은 사람.
• 출력: 채택(→⑥) / 기각 / 보류.
• 경계: 반자동 — 점수로 우선순위를 매기되 채택은 운영자가 확정(§7).

5-7. ⑥ draft 등록 (분류·유형 태깅 확정)

이 단계의 출력이 STANDARD-ANSWER-CURATION.md의 입력(진입점 ①~④와 동급의 "PMS 수집" 진입점)이 된다.

5-8. ⑦ admin 검토·승인 (→ 큐레이션 정본에 위임)

• draft → reviewing → approved 전이·중복/병합·반려 사유·KPI는 전적으로 STANDARD-ANSWER-CURATION.md §3~6이 정본.
• 본 수집 문서의 책임은 ⑥ draft 생성까지. ⑦은 경계 명시용으로만 기술한다.
• 안내글(hp_announce)도 동일 승인 워크플로(상태 모델)를 타되, admin은 "표준 안내답변" 별도 메뉴(hp_announce 목록)에서 검토한다 — Q&A 표준답변 메뉴와 분리(§9-C).

6. 자동 / 반자동 / 수동 경계 (요약)

원칙: 결정적으로 답이 나오는 것(제외 룰·서비스 매핑·staff 판정)은 자동, 의미 판단(토픽·재사용성·채택)은 사람이 최종 확정. LLM은 분류·점수의 보조이며 단독 등록·승인 권한 없음(안전 가드 — 추측 금지 정책 정합).

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

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

7-2. 미정 TODO

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

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

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

9-A. DBA — 스키마 요구사항

• hp_service 재시드(§4-2, 7서비스). 002 6종 처리 방식 결정(H2).
• 그룹→서비스 매핑 저장처(H1): hp_service_group_map(group_name VARCHAR, service_id INT) 신규 또는 hp_service.match_group_names(LONGTEXT JSON — 운영 DB MySQL 5.6.51 호환). 정규화 룰(전각 괄호 등)은 애플리케이션.
• hp_announce 신규 테이블(004 후보, §5-3). 핵심 컬럼: title/body/scope/topic_id/service_id/tags/source_post_id/valid_from/valid_to/approval_status/approved_by/approved_at/rejection_reason/usage_count/last_used_at/status. 인덱스: idx_approval (approval_status, status)·idx_scope_topic (scope, topic_id, service_id, status). hp_standard_answer에 answer_type 컬럼 추가하지 않음.
• 승인 워크플로 상태 전이 검증은 hp_standard_answer와 공통 헬퍼로 공유(api).
• 수집 출처 추적: source_post_id INT(이미 큐레이션 §9-A 제안)·harvest_status(hold_service/hold_topic 등 수집 보류 상태) 컬럼 검토.
• ※ 큐레이션 §9-A의 분류 컬럼(scope/topic_id/service_id/approval_status)이 선행 의존(003) — 본 004는 그 위에 얹는다.

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

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

• 수집 큐레이션 화면(신규 또는 /standard-answers 내 탭): 스캔 트리거 → 후보 목록(서비스 자동배정·토픽 추론·트랙(Q&A/안내글) 표시) → 채택/기각 → draft 저장. 미매핑(hold_service)·저신뢰 토픽(hold_topic)을 별도 필터로.
• 표준답변(Q&A)·표준 안내답변(안내글) 별도 메뉴: 안내글은 hp_announce 전용 메뉴(/announces)로 분리 — Q&A /standard-answers와 다른 목록·승인 흐름·필드(유효기간 등). 단순 탭이 아니라 별도 IA 메뉴(사용자 결정 2026-06-18).
• catalog(/catalog)의 hp_service를 7서비스로 현행화(재시드 후 자동 반영) + 그룹 매핑 편집 UI(H1 결정 시).

9-D. PMS — 요구사항

• QaEvalCard/안내글 카드에서 "표준답변으로 저장"(→hp_standard_answer)·"표준 안내답변으로 저장"(→hp_announce) 시 자동 배정된 서비스·추론 토픽 프리필 표시(운영자가 PMS 안에서도 채택 가능). 저장은 항상 draft임을 명시.
• 안내글(staff 첫 글) 화면은 기존 announce-eval 결과를 그대로 활용.

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

• 안내글(hp_announce)의 P2 고객 챗봇 노출 정책(H8): 공지성 안내가 특정 업체·내부 정책을 담을 수 있어, 일반화 검증·출처 표기·말투 가드 필요. 비공개 댓글 파생분은 큐레이션 §8-D/FR-10과 동일하게 가드.

10. 핸드오프 요약

본 문서가 확정·재정의한 7서비스·24토픽(TOPIC-CATALOG.md)·안내글 별도 테이블(hp_announce)·관리자 메뉴 분리는 STANDARD-ANSWER-CURATION.md §2-2·T1과 ADMIN-PLAN.md §4-3 표의 현행화 트리거다. dba 재시드가 진행되면 두 정본을 함께 갱신하고 docs/history/에 누적한다.

토픽 생성 범위 = 2022~2026 전 프로젝트(확정 — 사용자 결정 2026-06-18, TOPIC-CATALOG.md §1).