🎯 오늘 한 일
-
Weekly Review 기능의 서비스 레이어 리팩토링 진행
-
주간 로그 집계(Counts)와 패턴 분석(Patterns)을 명확한 책임 단위로 분리
-
Day2 / Day3라는 작업 단계 중심 네이밍을 제거하고,
도메인 역할 중심 네이밍으로 변경WeeklyReviewPayloadCountsSummary
-
주간 리뷰 생성 흐름을 다음과 같이 고정:
- 주간 로그 단일 조회 → 집계 계산 → 패턴 계산 → payload JSON 생성 → DB upsert
-
서비스 코드 전반에 역할 설명 주석 추가하여 가독성과 의도 명확화
-
“AI는 판단자, 서비스는 정리자”라는 역할 분리를 코드 구조로 확정
💡 배운 점
-
작업 단계(Day2, Day3)는 코드 네이밍에 남기지 않는 것이 좋다
- 단계는 일정 관리용, 코드는 영속적인 도메인 언어를 사용해야 한다
-
로그 조회를 여러 메서드에서 중복 호출하지 않고,
단일 데이터 소스(fetchWeeklyLogs) 로 통합하면- 성능
- 디버깅
- 추후 확장
모두에서 이점이 크다
-
PatternContext를 “AI 입력 계약”으로 고정하니
이후 Day4(Evidence), AI 연동 단계가 자연스럽게 이어질 구조가 됨
🚀 내일 할 일
-
Day 4: 패턴별 Evidence 선정 규칙 설계
- 각 패턴당 2~5개의 실제 DailyLog 연결
- 로그 삭제/수정 시 안전 처리 전략 정의
-
Evidence 구조를 payload에 어떻게 포함할지 스키마 설계
🧩 느낀 점
- 오늘로 Day 2(정량 요약) + Day 3(패턴 구조) 가 사실상 완결됨
- 지금 구조는 “AI가 헛소리 못 하게 하는 백엔드”라는 목표에 잘 부합함
- 기능을 더 늘리기보다,
이 구조를 얼마나 오래 버틸 수 있게 만들지가 다음 관건이라는 확신이 생김
