2. 기능 명세

⚠ 2026-08-28 기능 재편 — 아래 본문보다 이 표가 우선한다

_project/decisions/201 로 도메인을 다산콜센터 하나로 줄이고 기능을 재편했다. 문서 우선순위상 결정 기록이 이 문서보다 위다(CLAUDE.md).

블록	바뀐 내용
A-5 (신규)	동시 통번역. 1차 범위는 ⓑ 서툰 한국어를 정확히 전사하는 것 — 외국어 → 한글(ⓐ)과 상담원 → 고객 TTS 는 여유 시 확장. ⚠ A-3 이 아니다 — A-3 은 아래 2.2 의 WebSocket 전달이다
B (재정의)	문서 추천 → 필요서류 자동 제시. 다산 고객 질문의 2.60%(174건)가 서류를 묻고 69종 서비스에 흩어져 있다
C-6 (신규)	콜 가드 — 고객 욕설·폭언 탐지. C-1~C-4(상담원 위반)와 방향이 반대라 추가다
D (확장)	요약·유형분류에 감정분석 기반 상담품질 평가를 더한다
F-2 (전용)	종결 요건 게이트 → 필요서류 체크리스트. 다산은 종결 유형이 없지만 판정 구조가 같다. 차단하지 않고 경고만 한다 — 다산에는 차단할 종결 행위가 없다(verdict 가 blocked → incomplete). F-1·F-3·F-4 는 폐기·보류
에스컬레이션	보류 — AI 콜봇 선응대를 전제하는데 콜봇이 없다

아래 2.x 절의 금융보험·쇼핑·질병관리본부 예시는 그 시점의 사실이라 지우지 않았다.

기획서 본체(_project/plan.md)는 2026-08-28 에 rev.5 로 다시 썼다 — A~F 기능 블록, 화면 구성, 인터페이스 계약, 8주 마일스톤이 모두 다산 기준으로 갱신됐다. 이 페이지가 그와 다르면 기획서가 맞다(.claude/rules/rfp-harness.md §1).

2.1 화면 구성

상담원 대시보드(apps/dashboard)만 둔다. 고객이 볼 별도 화면은 없다 (음성 통화 — _project/decisions/014-고객화면-스코프-재철회.md, 013 철회).

┌──────────────────────┬──────────────────┐
│  실시간 자막          │  경고            │
│                      │                  │
│ 고객                 │ ⚠ 확정적 보장    │
│  아 저번에 가입할     │   표현 감지      │
│  때 6개월 할인       │                  │
│  된다고 했는데       │  "무조건        │
│  지금 요금 보니까    │   환불됩니다"    │
│  안 빠진 것 같아서요 │   (14:32)       │
│                      │                  │
│ 상담원               │ → 권장:          │
│  네 확인해           │  "확인 후        │
│  드리겠습니다        │   안내드리겠     │
│                      │   습니다"        │
│  카드번호는 ****     │                  │
└──────────────────────┴──────────────────┘
┌ 프로모션 할인 적용 시점 안내 ─────────────────┐
│ 신규 가입 할인은 가입 다음 달 청구서부터 반영. │
│ 📄 요금제약관 제3조 2항                        │
├──────────────────────────────────────────────┤
│ ▌요금제약관 제3조 2항                          │
└──────────────────────────────────────────────┘
                    추천 카드 = 하단 책갈피 팝업 (탭은 누적, 펼침은 일시)
                                          F-2 게이트는 이 화면 위 모달로 표시

자막·경고 패널은 위쪽을 유지하고(자막 넓게 2fr, 경고 좁게 1fr), 추천 카드는 화면 최하단 책갈피 바에 둔다. cards 이벤트마다 탭이 추가되고 카드가 아래에서 짧게 펼쳐졌다가 접힌다. 접힌 탭은 남아 있고 클릭하면 다시 펼친다. 상담원은 검색창에 타이핑하지 않는다.

위 화면은 금융보험(한별금융) 도메인의 예시다. 실제로는 4개 도메인 (금융보험·다산콜센터·쇼핑·질병관리본부) 각각 자기 지식베이스에서 카드가 뜬다 — 예를 들어 쇼핑 도메인에서는 “반품 배송비 부담 기준”, 질병관리본부 도메인에서는 “증상별 일반 안내”가 같은 자리에 뜬다. 화면 레이아웃과 카드 구조는 도메인 무관하게 동일하다.

2.2 A. 실시간 음성 → 텍스트

A-2 확인 완료: AI Hub 데이터(ktelspeech·krespspeech·lowquality-phone 전부)는 모노로 확인됐다(V1). 실무 콜센터처럼 2채널 스테레오로 물리 분리되어 있지 않으므로 채널 분리로 우회할 수 없고, Google STT diarization을 반드시 써야 한다. diarization 정확도가 C-1~C-3, C-5 전체의 성능 상한선이 된다(리스크).

2.3 B. 자동 문서 추천 — RAG 핵심

2.4 C. 실시간 컴플라이언스 감지 + 마스킹

C-1~C-4는 KcELECTRA 계열 분류기 파인튜닝으로 구현한다. 재현율 우선 설계 — 놓치는 것이 과잉 경고보다 위험하다.

C-5 상세 — 코어에 포함

이 시스템은 실시간 자막을 화면에 띄우고 전사 결과를 DB에 저장한다. 마스킹이 없으면 그 자체가 설계 결함이다.

탐지 파이프라인 — STT 출력은 정형 문자열이 아니므로 정규화가 선행된다.

STT 전사 결과
   ↓
① 구분자·공백 제거 후 연속 숫자열 판정   ← 주 실패 모드 대응
   "123456 1234567" / "1234561234567" 모두 포착
   ↓
② 한글 수사 → 숫자 변환 (보조)
   "구일공" → "910"
   ↓
③ 패턴 매칭 (정규식) + NER (이름·주소)
   ↓
④ 마스킹

주의: Google STT 한국어는 긴 숫자열을 대체로 아라비아 숫자로 정규화하므로, 한글 수사보다 구분자 부재와 띄어쓰기 붕괴가 지배적 실패 모드다. ①을 ②보다 앞에 둔다.

대상 패턴 목록 (문서에 고정하고, 이 목록에 대해 누락 0건을 목표로 한다)

지표 우선순위 — 두 목표는 동시에 최적화할 수 없으므로 순서를 고정한다. 누락 0건 > 과잉 마스킹 억제. 애매하면 가린다. 과잉 마스킹률은 목표가 아니라 참고 기록이다.

2.5 D. 통화 후 처리

D-4 확장 — 탐지 실패도 같은 루프에 넣는다

2.6 E. 평가 하네스

2.7 F. 종결 요건 검증 (조건부 모듈 — 종결형 처리가 있는 도메인)

배경 — 문제 구조

신고·요청 처리 시스템에서 반복되는 실패 유형이 있다. 종결 사유는 기재되었으나 그것을 뒷받침하는 근거가 검증되지 않는 것이다. 처리자가 “확인했다”고 적으면 그대로 닫힌다. 4개 데모 도메인 중 종결(closure)이 있는 처리 유형을 가진 금융보험·쇼핑에도 같은 구조가 존재한다 — 다산콜센터·질병관리본부는 안내형 업무라 F-2 대상이 아니다(지식베이스 README).

주장 범위 — 반드시 지킬 것: “근거 없는 종결의 비용을 올린다.” — “이런 일을 막습니다”가 아니다. 고의적 허위 기재는 어떤 시스템도 막을 수 없다. 이 구분을 흐리면 프로젝트의 신뢰도가 떨어진다 (부록 A-3).

F-4 표현 정정: “불변 감사 로그”는 과장이다. PostgreSQL에서 완전한 불변성은 애플리케이션 레벨로 보장할 수 없다(DB 권한자는 삭제 가능). 추가 전용 테이블 + 정정 이력 보존 방식으로 기술하고, 한계를 함께 적는다.

F-2 상세

상담원이 "고지 완료" 사유로 상품 해지 처리 종결 시도  (금융보험 도메인 예시)
        ↓
[RAG] 코어와 동일한 ES 인덱스에서 해당 도메인·처리 유형의 필수 확인 항목 검색
        ↓
[규칙] 근거 필드 충족 여부 판정
        ↓
┌───────────────────────────────────────┐
│ ⛔ 종결 요건 미충족                     │
│                                       │
│ 도메인: 금융보험 / 처리 유형: 상품 해지   │
│ 필요 근거:                             │
│   ☑ 중도해지수수료 안내                 │
│   ☐ 약정혜택 소멸 안내                  │
│   ☐ 고객 확인 응답 기록                 │
│                                       │
│ 근거 3건 중 1건 → 종결 차단             │
│ 📄 근거: 응대 매뉴얼 3.1 / 이용약관 3.3조 │
└───────────────────────────────────────┘

RAG의 역할이 여기서 달라진다. A~E의 RAG는 “답을 찾아 사용자에게 보여준다”. F-2의 RAG는 “행위를 검증할 근거를 가져온다”. 검색 결과가 화면에 표시되는 정보가 아니라 게이트 판정의 입력이 된다. 판정 자체는 규칙으로 하고 LLM은 설명만 생성한다 (부록 A-2).

아키텍처 영향 — 없음

새 DB, 새 검색엔진, 새 화면, 새 프로토콜 — 아무것도 추가되지 않는다.

조사 결과 국내 AICC는 STT/TA 기반 불완전판매 방지(하면 안 되는 말 감지)를 제공한다. 그러나 “근거 없이 처리를 닫는 것을 차단하는” 기능은 확인되지 않았다 (레퍼런스 분석).

2.8 G. 위기 상황 자원 연계 (여유 시 — 범위 엄격 제한)

절대 선: LLM이 위기 상황의 당사자와 직접 대화하게 만들지 않는다. 어떤 형태로도. 시스템은 상담원을 돕는 도구로만 존재한다.

단방향 경고 원칙: 시스템은 “위험 신호가 감지됐다”만 말한다. “안전하다”는 절대 말하지 않는다.

• 위험도 점수를 화면에 표시하지 않는다. 낮은 점수는 상담원의 경계를 늦춘다
• 신호가 있으면 안내를 띄우고, 없으면 아무것도 하지 않는다
• UI에서 침묵이 “이상 없음”으로 읽히지 않도록 명시한다

G-2만 남기는 이유: 확장 기능 중 유일하게 공개 데이터로 정답을 확인할 수 있다. 관할이 맞는지, 운영시간이 맞는지, 폐지된 기관을 반환하지 않는지가 전부 검증 가능하다. 기술적 화려함이 아니라 측정 가능성 때문에 존재한다.

만들지 않는 것: 위험도 점수화 및 표시 / 당사자에 대한 자동 응답 / 위치 추적·신고 자동화 / 실제 위기 상담 통화 수집.

← 개발목차로 돌아가기