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

**작성일**: 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. 일기 포맷 초안

```markdown
# 로빙 일기 – 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 일기 안에서의 구조 (반성/성찰 전용 섹션)
```markdown
## 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로 주입해, 로빙이 반성/성찰 내용을 행동에 반영하되, 일기 원문·비밀은 절대 외부 응답에 재인용하지 않도록 가드레일을 구현.