---
**[참고]** 이 문서는 로빙의 [대화형 점진적 의도 구축 시스템](../ideas/250819_대화형_점진적_의도_구축_시스템.md)의 일환으로, 네이버웍스 슬랙 브리핑 프로젝트(Phase 2+)에서 '의도분석 + 되묻기' 기능 구현 중 발생한 문제 해결 기록입니다.
---

# 네이버웍스 슬랙 브리핑 Phase 2+ 문제 해결: 의도분석 및 되묻기

## 작성일: 2025-09-19
## 작성자: happybell80
## 범위
- 본 문서는 02 문서(일일 브리핑 핵심 구현)를 완료한 뒤 진행할 추가 단계(프론트엔드/슬랙 UX/의도분석/관측·보안)와 관련 리스크·대응을 정리한다.
- 의사코드는 포함하지 않으며, 핵심 내용과 아이디어만 제시한다.

---

## Phase 2 — 의도분석 + 되묻기(Clarifying)
- 의도 라벨
  - email.daily_briefing, email.list, email.send (브리핑 우선)
- 슬롯(필수/선택)
  - source(메일 소스: naverworks/gmail), period(24h/48h/7d), destination(DM/channel), privacy(제목/발신자만 요약 동의)
- 전략
  - 이중 경로: 빈도 높은 명확 의도는 DecisionEngine(정규식), 롱테일/모호 발화는 IntentAnalyzer(LLM) 보조
  - 임계값: DecisionEngine 신뢰도 < 0.6 또는 충돌 시 1문장 되묻기 + 선택지, 필요 시 LLM 의도 분석 결과 채택
  - 폴백: LLM/네트워크 실패 시 키워드 기반 파서(EmailIntegration)로 안전 폴백
  - Slot-filling: 누락 슬롯만 질문, 답변은 컨텍스트에 저장 후 같은 스레드에서 실행
  - 안전 규칙: 의도 분석은 “사용자 원문 텍스트” 기준 처리(파일 내용은 제외). 파일만 업로드 시 DOCUMENT_ANALYSIS로 강제 분기
- Slack UX 지침
  - 버튼(예: [네이버웍스][24h][DM])과 드롭다운으로 빠르게 확정
  - 진행중 메시지 생략, 최종 결과만 스레드에 게시
- 리스크/대응
  - 과도한 질문 → 기본값(사용자 Preferences) 적용 후 1문장만 질문
  - 혼합 언어 입력 → 한국어 기준으로 처리하되 영어 키워드 맵핑 유지

---

## 리서치 통합 요약(의도분석)
- 병행 전략: 정규식 기반 DecisionEngine + LLM 기반 IntentAnalyzer를 병행해 정확도/속도 균형 확보
- 점진적 의도 구축: 멀티턴 대화에서 슬롯(필수/선택)을 순차적으로 채우고, 완성 시 자동 실행
- 시간·맥락 인식: 시간 관련 발화엔 KST 현재시각을 컨텍스트에 주입, “그때/어제”류 질의엔 최근 대화 일부를 회수하여 반영
- 스케줄 의도: 일회성/반복/상대시간(“N시간 후”)까지 포괄, APScheduler + DB JobStore로 영속 스케줄 관리
- 인터페이스 역할: Slack은 실시간 인터랙션(버튼/스레드 유지), Frontend는 기본값(Preferences)·상태 가시화·온디맨드 실행 담당

---

## Phase 3 — 프론트엔드 설정/온디맨드
- Preferences 저장 항목
  - 브리핑 소스(기본 naverworks), 기간(기본 24h), 전송 경로(기본 DM), 키워드(긴급/계약/결제/공지)
- 화면 포인트
  - 브리핑 설정 섹션: ON/OFF, 시간, 대상자 미리보기(등록 사용자 수)
  - 상태 패널: 마지막 실행 시각/성공·실패·무항목 카운트, 다음 실행 예정
  - 온디맨드 실행 버튼: 즉시 실행(같은 파이프라인 재사용)
- API 경로(현행 구성 활용)
  - Preferences: Gateway → robeing-monitor `/api/preferences/{user_uuid}`
  - 온디맨드: `POST /api/chat`로 “네이버웍스 브리핑” 트리거(의도분석 경유)
- 리스크/대응
  - 시간대/서머타임 혼선 → KST 고정 표기 + 서버 타임존 명시
  - 설정/실행 불일치 → 저장 성공 토스트 + 다음 실행 미리보기 업데이트

---

## Phase 4 — Slack UX 고도화
- 메시지 구성
  - 머리말: 날짜/타이틀, 실행 소스/기간 배지
  - 섹션: 🔴긴급, 🟡중요, 🟢일반 (각 3~5건 제한, 나머지는 “기타 X건” 집계)
  - 각 항목: 제목 · 발신자 · 수신일자 · 원본 링크(본문 미노출)
- 인터랙션
  - 버튼: “자세히”, “기간 변경(24h/48h/7d)”, “전송 경로 변경(DM/채널)”
  - thread_ts 유지로 결과만 교체
- 채널 브리핑 정책
  - 기본은 DM만, 채널 포스팅은 별도 옵션(민감도·레이트리밋 고려)
- 리스크/대응
  - 레이트리밋 → 사용자별 순차 전송 + 지연 삽입, 실패 재시도/백오프
  - 민감정보 노출 → 본문/첨부 미전송 원칙 유지, 제목·발신자·링크만 표기

---

## Phase 5 — 관측(Observability) · 보안(Compliance)
- 관측 지표
  - 단계별 처리 시간(수집/필터/요약/전송), 성공·실패·무항목 카운트, 재시도 횟수
  - 의도분석 정확도(되묻기 진입률/완료율), 사용자 취소율
- 로깅 정책
  - PII 제거된 구조화 로그(사용자 UUID, 건수, 상태코드)
  - 에러 시 원인 카테고리화(토큰/네트워크/레이트리밋/포맷)
- 보안
  - 본문/첨부 불수집(원본 링크만), 민감 키워드 사전 필터(금액/계좌 등)
  - 권한 경계 준수(네이버웍스 접근권은 원 시스템이 검증)

---

## 운영 상 고려사항
- 대상자 결정: `naverworks_token` 보유 사용자 기준(만료 자동 갱신 경로 확인)
- 재시작 복원: 스케줄/설정은 DB 기반, 프로세스 재시작 시 자동 로드
- 설정 충돌: 프론트 설정 vs 채팅 요청 충돌 시 채팅의 명시 선택을 우선 적용

---

## 예상 리스크와 완화
- 토큰 만료/갱신 실패
  - 사전 점검 잡(08:55)으로 토큰 상태 확인, 실패 시 DM 사전 안내
- 데이터 과다(메일 폭증)
  - 24h 윈도우 엄수 + 상한(limit) + “기타 N건” 요약
- 의도 오인식
  - 임계값 기반 되묻기, Preferences 기본값으로 무인입력 보정

---

## 단계별 마일스톤(핵심 산출물)
- Phase 2: 의도·슬롯 정의, 되묻기 메시지 세트, 성공률 80%↑
- Phase 3: 설정 화면/온디맨드, 다음 실행 미리보기, 실패 알림
- Phase 4: Block Kit 통일, 액션 버튼, thread 일관성
- Phase 5: 메트릭/알람 대시보드, PII 안전 로그

---

## 메모
- 02 핵심 구현(09:00 자동 브리핑 DM)이 안정화되면 본 문서의 단계별 항목을 순서대로 적용한다.