ivada-infra/DOCS
3
0
Fork 0
Code Issues 1 Pull Requests 5 Actions Packages Projects Releases Wiki Activity
DOCS/journey/troubleshooting/250919_naverworks_slack_briefing_phase2plus_troubleshooting.md
Claude-51124 22557e7132 docs: 오래된 트러블슈팅 아카이브 및 구조 정리 
- 7-8월 초기 구축 문서 12개를 _archive/troubleshooting/2025_07-08_initial_setup/로 이동
- book/300_architecture/390_human_in_the_loop_intent_learning.md를 journey/research/intent_classification/로 이동 (개발 여정 문서)
- 빈 폴더 제거 (journey/assets/*)
2025-11-17 14:06:05 +09:00

6.2 KiB
Raw Blame History

[참고] 이 문서는 로빙의 대화형 점진적 의도 구축 시스템의 일환으로, 네이버웍스 슬랙 브리핑 프로젝트(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)이 안정화되면 본 문서의 단계별 항목을 순서대로 적용한다.