🎯 오늘 한 일
프론트엔드
- Weekly Review 페이지를 실제 백엔드 API 기반으로 전환
payloadJson파싱을 통해 패턴/근거 렌더링 로직 보강- 리스트 조회(
/api/reviews/weekly/list) 우선 → 실패 시 단건 API fallback 구조 적용 - 선택된 주차 상세 데이터가 없을 경우 자동 재조회 처리
- 생성/재생성 버튼을 항상 노출하고, 누락 주차 일괄 생성 버튼 추가
weekKey기준 리스트 병합으로 중복 주차 제거- 근거 로그(evidences) 중복 제거(dedupe) 로직 프론트에 추가
백엔드
- 주간 리뷰 조회 시 캐시 히트/미스 로직 정리 및 미존재 시 생성 후 저장하는 흐름 유지
- 특정
weekKey기준 상세 조회 + 주간 리뷰 리스트 응답 엔드포인트 구성 - DailyLog는 있으나 WeeklyReview가 없는 주차를 찾아 일괄 생성하는 배치 로직 추가
- ISO week 기준 주차 집계를 위한 native query 추가
weekKey리스트로 기존 주간 리뷰를 조회하는 레포지토리 메서드 확장- 근거 로그(evidence) 중복 제거 및
logDate / patternType / rule기준 정렬로 응답 안정성 확보
💡 배운 점
- 단건 API + 리스트 API가 공존할 때는 fallback + lazy fetch 구조가 UI 안정성과 확장성 모두에 유리하다.
- 백엔드가 아무리 정제돼도 프론트에서의 방어 로직(dedupe, merge)은 필수다.
- 주간 리뷰 생성은 “주간 로그 1회 조회 → counts/patterns/evidences 재사용” 구조가 성능·일관성 측면에서 가장 깔끔하다.
- 누락된 주간 리뷰를 복구할 때는
주차 집계 → weekKey 비교 → 없는 것만 생성이라는 파이프라인이 명확해야 한다.
🚀 내일 할 일
- 주간 리뷰
evidences선정 규칙 및 정렬 기준을 문서로 고정 - FE/BE 중 어디서 정렬을 책임질지 결정 후 단일 책임으로 정리
- 리뷰 생성 로직에 대한 통합 테스트 추가 검토
🧩 느낀 점
- 이제 Weekly Review는 “보여주는 화면”을 넘어서 상태를 관리하는 시스템이 됐다.
- AI는 마지막 퍼즐일 뿐이고, 지금은 AI를 붙여도 흔들리지 않는 구조를 거의 완성했다.
- 오늘 작업으로 다음 단계는 고민이 아니라 연결과 검증만 남았다.
