DOCS/troubleshooting/250919_naverworks_slack_briefing_phase2plus_troubleshooting.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)이 안정화되면 본 문서의 단계별 항목을 순서대로 적용한다.