ivada-infra/DOCS
3
0
Fork 0
Code Issues 1 Pull Requests 5 Actions Packages Projects Releases Wiki Activity
DOCS/journey/plans/251117_claude_robeing_diary_시스템_계획.md

8.9 KiB
Raw Blame History

로빙 일기(성장 일지) 시스템 계획서

작성일: 2025-11-17
작성자: claude

1. 목적

  • 로빙이 하루 활동과 감정 상태를 스스로 정리하는 “일기/성장 일지” 시스템을 설계한다.
  • 운영자/연구자가 로빙의 행동 변화·감정 흐름·반복 이슈를 한눈에 파악할 수 있는 기반을 만든다.
  • 추후 책 본문(400_growth)과 관리자 대시보드에서 재사용 가능한 표준 포맷을 정의한다.

2. 현재 상태 정리

  • 대화/피드백/의도 리뷰 큐:
    • rb8001에 대화 로그, intent 리뷰 큐, 감정 모델 등이 이미 구현되어 있음.
    • HITL 의도 학습 흐름이 DOCS/research/intent_classification/README.md, rb8001/experiment_results/e2e_final_experiment_report.md에 문서화됨.
  • 문서 관점:
    • 600_appendix/610_로빙_성장_일지_예시.md에 “성장 일지” 컨셉 예시가 있으나, 실제 서비스와 연결된 자동화 시스템은 아직 없음.

3. 요구사항 (초안)

  1. 자동 생성
    • 하루 단위(또는 세션 단위)로 일기를 자동 생성할 수 있어야 한다.
    • 입력: 대화 로그, 감정 스코어, 리뷰 큐/오류 로그 요약.
  2. 감정 상태 반영
    • “오늘의 주요 감정”, “감정 변화 요약”이 포함되어야 한다.
  3. 문제·개선점 정리
    • 장애/실패/리뷰 큐 쌓인 부분을 기반으로 “오늘의 문제/배운 점/개선 방향”을 자동 서술한다.
  4. 저장 포맷
    • 사람 읽기용: 마크다운(md) 일기 파일.
    • 분석용: DB에 동일 내용을 요약(텍스트 + 메타데이터) 형태로 저장.
  5. 조회/활용
    • 최소한 운영자는 서버/에디터로 md 파일을 쉽게 조회할 수 있어야 한다.
    • 추후 관리자 대시보드에서 일자별 목록 + 상세 보기로 확장 가능해야 한다.

4. 아키텍처 방향 (초안)

  1. 데이터 수집 계층
    • rb8001의 대화 로그/감정 분석/리뷰 큐/에러 로그에서 하루치 데이터를 집계하는 “Diary Aggregator” 함수 설계.
  2. 요약·서술 계층
    • Aggregator가 만든 구조화 데이터(예: JSON)를 바탕으로 “일기 텍스트”를 생성하는 템플릿/LLM 조합 설계.
  3. 저장 계층
    • DB: robeing_diary 테이블(예: date, robeing_id, summary, dominant_emotion, stats(jsonb) 등).
    • 파일: /code/logs/diary/YYYY/MM/robeing_diary_YYYY-MM-DD.md 형식의 md 파일 (Docker 볼륨 마운트 고려).
  4. 조회 계층
    • 1단계: 서버에서 md 파일 직접 열어보는 운영자용 뷰.
    • 2단계(향후): frontend-base 관리자 대시보드에서 일기 목록/상세 보기 제공.

5. 일기 포맷 초안

# 로빙 일기 – 2025-11-17

## 1. 오늘 한 일
- 주요 대화 주제 요약 (intent 기준)
- 호출된 스킬/액션 요약

## 2. 감정 상태
- 지배적인 감정: XXX
- 감정 변화 요약: 오전/오후/야간

## 3. 문제와 배운 점
- 오늘 발생한 주요 오류/리뷰 큐 이슈 요약
- 교훈/개선 방향

## 4. 내일을 위한 계획
- 내일 개선하고 싶은 점
- 실험/테스트 아이디어

6. 단계별 실행 계획

  1. 설계 정리
    • Diary Aggregator의 입력/출력 스키마 정의.
    • robeing_diary 테이블 스키마 초안 작성.
  2. TDD 테스트 설계
    • rb8001/tests/에 “일기 생성” 단위 테스트 초안 작성 (RED).
  3. Aggregator/포맷 구현
    • 집계 로직 + md 템플릿 생성 함수 구현 (DB/파일 저장은 나중 단계로 분리).
  4. DB/파일 저장 연결
    • 일기 생성 결과를 DB + md 파일로 저장하는 배치/엔드포인트 설계.
  5. 관리자 대시보드 연동(선택)
    • frontend-base에서 일기 리스트/상세 보기 추가 (23번 서버 계획 문서와 연계).

7. 열려 있는 질문

  • 일기 생성 주기: “하루 1회” vs “세션/이벤트 기반” 중 무엇이 기본이 될 것인가?
  • 감정 상태: 단일 지배 감정만 쓸지, 감정 분포 그래프/지수까지 포함할지?
  • 사용자 프라이버시: 어떤 수준까지 실제 대화 내용을 일기에 포함할지, 익명화/요약 기준은 무엇으로 할지?

8. 로빙의 ‘반성/성찰’ 관점에서의 요구사항

8.1 어떤 신호를 반성 대상으로 삼을 것인가

  • 저신뢰/불확실 응답
    • intent confidence가 일정 이하(예: 0.5 미만)이거나, UNKNOWN/clarify 흐름이 반복된 케이스.
    • LLM 응답에 “잘 모르겠습니다/확실하지 않습니다” 패턴이 포함된 케이스.
  • 사용자 피드백/재질문
    • 같은 질문이 짧은 시간 안에 반복되는 경우(“다시 설명해줘”, “이 말이 무슨 뜻이야?” 등).
    • Slack/프론트에서 직접적인 불만/부정 감정이 나타난 대화(감정 모델 + 텍스트 패턴 조합).
  • 시스템 오류·윤리 필터
    • 예외/500, ethics 필터 차단, 권한/인증 오류가 발생한 요청.
    • intent_review_queue에 쌓인 케이스 중 “사람이 보기에도 잘못된 의도/응답”으로 라벨링된 항목.

8.2 일기 안에서의 구조 (반성/성찰 전용 섹션)

## 3. 오늘의 반성 노트
- 내가 잘 이해하지 못한 요청: (요약 1~3개)
- 사용자가 헷갈려 했던 설명: (요약 1~3개)
- 시스템/윤리 필터에 막힌 지점: (요약)

## 4. 배운 점과 내일의 실험
- 오늘 배운 것: (패턴/원인 수준으로 서술)
- 내일은 이렇게 대응해 보고 싶다: (구체 행동 2~3개)
  • 중요: 여기에 들어가는 내용은 “자기 비난”이 아니라 행동/패턴 중심의 학습 포인트여야 함 (예: “사용자가 화를 냈다”가 아니라 “나는 이메일 요약을 너무 길게 답했다 → 다음에는 먼저 요약 길이를 물어보자”).

8.3 어떤 데이터로 채울 것인가 (데이터 소스 매핑)

  • conversation_log:
    • 하루치 로그에서 intent, confidence, channel, timestamp 기준으로 “문제 가능성이 높은 대화”를 샘플링.
  • intent_review_queue:
    • 오늘 생성된 리뷰 항목 중 레이블이 확정된 것(사람이 ‘틀림/개선 필요’로 표시한 것)을 “배운 점” 후보로 사용.
  • 감정/윤리 시스템:
    • 감정 모델이 “강한 부정 감정 + 낮은 이해도”로 태깅한 순간, 윤리 필터에 의해 수정·차단된 응답을 별도 리스트업.

9. 프라이버시·비유출 원칙 (일기 활용 시 가드레일)

  1. 저장 계층 분리
    • robeing_diary(가칭) 테이블/스토리지에만 일기 원문을 저장하고,
      • RAG 검색 인덱스(ChromaDB 등)에는 포함하지 않는다.
      • 일반 대화 컨텍스트(최근 대화 불러오기)에도 직접 합치지 않는다.
  2. LLM 컨텍스트 제공 방식
    • LLM 호출 시, 일기 원문 전체가 아니라 요약된 메타정보만 전달:
      • 예: “최근 7일 동안 사용자가 피곤함을 자주 호소함”, “최근 이메일 요약을 길게 답해 불만이 있었음”.
    • 시스템 프롬프트에 다음 규칙을 명시:
      • “일기 내용(구체 사건/이름/회사)을 직접 인용하거나 언급하지 말 것.”
      • “일기에서 배운 태도·주의점만 반영해 현재 대화 톤/전략을 조정할 것.”
  3. 외부 노출 경계
    • 관리자 페이지에서는 일기 전체를 볼 수 있지만,
      • API 단에서는 관리자용 인증 경로를 제외하고 일기 데이터를 제공하지 않는다.
    • 사용자에게는 “일기”라는 개념을 설명하되, 원문을 그대로 보여주지 않고 요약된 인사이트(“요즘 피곤해 보여서 답변을 조금 더 짧게 할게요” 정도)만 드러내도록 한다.

10. 단계별 구현 계획 (반성/성찰 기능 중심)

  1. Phase 1 – 데이터 수집·집계
    • conversation_log, intent_review_queue, 감정/윤리 로그에서 “문제 가능성이 높은 케이스”를 하루 단위로 집계하는 Aggregator를 설계·구현.
    • 하루치 집계 결과를 JSON 형태로 파일/DB에 저장하고, 아직 일기 텍스트 생성은 하지 않음.
  2. Phase 2 – 일기 텍스트 생성 (내부 전용)
    • Aggregator 출력 + 템플릿/LLM을 조합해, 위 5장·8장 포맷(오늘 한 일 + 감정 + 반성 노트 + 내일 계획)에 맞는 일기 텍스트를 생성.
    • robeing_diary 저장소 설계: date, robeing_id, summary_text, reflection_text, emotion_summary(jsonb), meta(jsonb) 등.
  3. Phase 3 – Admin UI 및 안전한 활용
    • 관리자 대시보드에서 로빙/날짜별 일기 목록·상세 보기 추가 (검색/필터 포함).
    • 일부 LLM 호출에서 “일기 메타정보”를 system context로 주입해, 로빙이 반성/성찰 내용을 행동에 반영하되, 일기 원문·비밀은 절대 외부 응답에 재인용하지 않도록 가드레일을 구현.