프론트엔드

• 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를 붙여도 흔들리지 않는 구조를 거의 완성했다.
• 오늘 작업으로 다음 단계는 고민이 아니라 연결과 검증만 남았다.

• WeeklyReview 화면 UX 전반 점검 및 상태 분기 설계 정리
• daily_log 테이블 잘못 들어간 데이터(id 31~54) 삭제 계획 수립
• 실제 UI 테스트를 위한 더미 데이터 시딩 전략 확정
• EMPTY_WEEK / NEEDS_GENERATION / READY 상태를 의도적으로 만들기 위한 날짜 범위 설계
• 주간 리뷰 생성 버튼의 역할과 위치(WeeklyReviewPage 중심) 재정의

💡 배운 점

• UI 상태 분기는 “데이터가 어떻게 들어가 있느냐”로 대부분 검증할 수 있다.
• AI 연결 전에도 충분히 의미 있는 UX 검증이 가능하며, 오히려 이 단계가 더 중요하다.
• AUTO_INCREMENT를 되돌리는 건 로컬/테스트 환경에서만 허용해야 한다.
• 주간 리뷰는 자동 생성물이 아니라, 사용자의 ‘요청 행위’에 의해 생성되는 결과물로 정의하는 게 맞다.

🚀 내일 할 일

• 1/9~1/22 범위로 daily_log 실제 테스트 데이터 INSERT
• 의도된 EMPTY_WEEK(로그 0), NEEDS_GENERATION(로그만 존재), READY(로그+리뷰) 상태 완성
• weekly_reviews 테이블 구조 확인 후, READY 케이스용 더미 리뷰 데이터 추가
• 생성 버튼 클릭 → 상태 변화 UX 흐름 점검

🧩 느낀 점

• 지금 만들고 있는 건 단순한 화면이 아니라 “기록이 의미로 변하는 지점”이다.
• AI는 부가 기능이고, 핵심은 사용자가 언제·왜 리뷰를 생성하고 싶은지를 자연스럽게 유도하는 구조다.
• 오늘은 기능 추가보다 설계의 기준선을 확실히 긋는 날이었다.

• WeeklyReview 상세 화면 가독성 마감

  • 우측 상세 카드 구조 최종 확정 (주차/기간 → 요약 → 명언 → counts → patterns → evidences)

  • 요약(summary) 렌더링 이슈 해결

    • 선택 주차 데이터 우선, 샘플 데이터 fallback 구조 적용

  • AI 텍스트(요약/명언)와 사실 기반 데이터(patterns/evidences/counts) 역할 분리

• 타이포·여백 정리

  • 제목(subtitle2) vs 본문(body1/body2) 위계 고정
  • 패턴 카드 밀도 조절로 시선 과점유 문제 해소

• “이번 주 목표” 기준으로 완료 여부 냉정하게 재검증 후 종료 결정

💡 배운 점

• 요약이 안 보이는 문제는 UI가 아니라 데이터 소스 우선순위 설계 문제였다
• AI 문장은 결과가 아니라 보조 레이어로 다뤄야 화면이 안정된다
• “완성도”는 더 고칠 수 있느냐가 아니라 목표 정의를 충족했느냐로 판단해야 한다
• Panel 책임 범위를 명확히 하면 Page 코드가 자연스럽게 단순해진다

🚀 내일 할 일

• AI 요약/명언 영역 접기 또는 구분 UI 검토
• counts 확장(활동일, 연속일 등) 가능성 검토
• 전주 대비 비교를 위한 데이터 구조 초안 설계

🧩 느낀 점

• 오늘은 추가한 것보다 멈춘 게 더 중요한 날이었다
• “이 정도면 끝”이라고 선언할 수 있는 기준을 세운 게 가장 큰 수확
• WeeklyReview가 이제 실험용 화면이 아니라 사용 가능한 기록 도구로 보이기 시작했다

• WeeklyReview 좌측 리스트 UX 전면 수정

  • 카드 hover/selected 상태 분리 설계
  • hover 시 투명해지는 문제 원인 추적 및 해결
  • overlay 방식으로 hover 강조 구현

• 연도(2025/2026) 구분 UX 개선

  • 연도 헤더를 단순 텍스트 → 중앙 정렬 섹션 헤더로 변경
  • 다크 배경에서 확실히 보이도록 흰색 + pill 배경 적용

• LEFT 리스트를 “보기용”이 아닌 “탐색용 네비게이션”으로 재정의

• WeeklyReviewPage 구조 정리

  • 중복 렌더 제거
  • Panel 책임 범위 명확화
  • 불필요한 effect 주석 처리(API 대비로만 유지)

💡 배운 점

• 다크 테마에서 transparent hover는 거의 항상 UX 실패다
• hover는 “클릭 가능”, selected는 “현재 위치”를 의미해야 하며 시각적 언어가 달라야 한다
• 배경을 바꾸는 hover보다 overlay(::after) 방식이 안정적이다
• 연도 같은 메타 정보는 장식이 아니라 네비게이션 기준점이다
• “지금 필요 없는 미래 대비 코드”를 구분해서 관리하는 감각이 중요하다

🚀 내일 할 일

• 연도 헤더 sticky 옵션 적용 여부 검토
• 첫 주차(연도 경계 주)에 보조 배지 추가 검토
• WeeklyReview 데이터 API 연동을 가정한 상태 전이 점검
• 좌측 리스트 키보드 네비게이션 가능성 검토

🧩 느낀 점

• 오늘 작업은 기능 추가가 아니라 해석과 정리의 날이었다
• UI가 좋아졌다는 느낌보다, “이 화면의 역할이 명확해졌다”는 게 더 크다
• 이제 WeeklyReview는 단순 기록 뷰가 아니라, 시간을 탐색하는 도구로 보이기 시작했다

• WeeklyReview 페이지의 주차 리스트 UX 개선

  • 연도 경계(2025년 55주차 → 2026년 1주차)를 고려한 정렬 로직 수정
  • weekKey 문자열이 아닌 rangeFrom(주차 시작일) 기준으로 시간순 정렬

• 왼쪽 주차 카드 UI 정리

  • YYYY년 N주차 형태로 가독성 개선
  • 선택된 카드의 외곽 강조(컬러/두께) 처리

• 상태 분기 로직 점검

  • 로딩 / 빈 주 / payload 없음 케이스 재확인

• mock 데이터 기반으로 API 교체 포인트 주석 정리

💡 배운 점

• ISO Week에서는 연도와 실제 날짜가 어긋날 수 있으므로 정렬 기준은 반드시 날짜(rangeFrom) 여야 한다.
• UI에서 “사람이 읽는 식별자(weekKey)”와 “시스템이 판단하는 기준(날짜)”을 분리하는 것이 안정적이다.
• 주간 리뷰처럼 누적 히스토리를 다루는 화면은 정렬 로직 하나가 UX 전체 신뢰도에 큰 영향을 준다.

🚀 내일 할 일

• 패턴 카드(RHYTHM / TOPICS / MIX) UI 디테일 보완
• Evidence 리스트 클릭 인터랙션 정리(날짜 이동 또는 스낵바)
• 전체 WeeklyReview 화면 여백/정렬 최종 정리

🧩 느낀 점

• “AI 없이도 의미가 통하는 화면”이라는 목표에 상당히 근접했다.
• 지금 구조라면 AI는 정말 문장화만 얹는 역할로 자연스럽게 붙을 것 같다.
• 결정론 → UI → AI 순서로 쌓아온 접근이 확실히 안정적이다.

• WeeklyReview 화면용 샘플 데이터 구조 확정

• weeklyReview.sample.json을 중심으로

  • 단일 주차 파일(weeklyReview.2026-W01~W03.json)
  • 다중 주차 리스트 파일(weeklyReviews.sample.json)
  • narrative 전용 샘플(narrative.sample.json) 구성 완료

• 주간 리뷰 UI 방향 결정

  • 상단: narrative summary
  • 중단: quote(고정 랜덤)
  • 하단: 결정론 weeklyReview (counts / patterns / evidences)

• “주간 리뷰는 언제든 확인 가능”한 옵션2 UX로 방향 확정

💡 배운 점

• 데이터가 먼저 정리되면 UI는 자연스럽게 따라온다
• 단일 주차 JSON과 다중 주차 JSON을 분리해두면 → 디버그 / 리스트 UI / API 연동 전환이 훨씬 수월함
• WeeklyReview는 “한 주의 결과물”이므로 카드 단위 박스 구조가 개념적으로 가장 맞다
• AI 연동 전에도 결정론 JSON만으로 충분히 “읽을 수 있는 리뷰”가 가능하다는 확신을 얻음

🚀 내일 할 일

• 패턴 카드 UI(RHYTHM / TOPICS / MIX) 시각적 정리
• EvidenceSection을 패턴별로 묶어 표시
• Evidence 클릭 시 날짜 기반 인터랙션(스낵바 or 표시) 추가

🧩 느낀 점

• 구조를 먼저 고정해두니 이후 작업이 심리적으로 굉장히 가벼워짐
• 지금 단계는 “기능 추가”가 아니라 개념을 화면으로 번역하는 과정이라는 게 명확해졌다
• AI 없이도 의미가 통하는 상태까지 왔다는 점에서 프로젝트의 중심축이 흔들리지 않는다는 안정감을 느낌

• Weekly Review 전용 페이지(WeeklyReviewPage) 생성
• Summary → Quote → WeeklyReview(결정론) 구조로 화면 레이아웃 설계
• WeeklyReviewPanel, PatternSection, EvidenceSection를 하나의 큰 Paper 박스 안에 배치
• weekKey(예: 2026-W02)를 파싱해 몇 주차인지(2주차) 표시 로직 추가
• narrative 더미 JSON과 weeklyReview 더미 JSON을 분리해 UI 연결
• Quote는 weekKey 기반 고정 랜덤 방식으로 표시되도록 구현

💡 배운 점

• 주간 리뷰 화면은 “정보를 위에서 아래로 읽히게” 만드는 것이 핵심이다 (Summary → 한 줄 문장 → 구조화된 데이터)
• AI 결과(JSON)는 UI의 상단 요약 영역에만 쓰고, 결정론 결과는 하단의 안정된 구조로 유지하는 분리가 효과적이다
• weekKey 같은 메타 정보는 UI에서 충분히 의미 있는 문구(“N주차”)로 변환할 수 있다
• 지금 단계에서는 API 연동보다 더미 JSON 기반 UI 완성이 훨씬 생산적이다

🚀 내일 할 일

• PatternSection을 표(Table) 형태로 더 정돈
• EvidenceSection 클릭 시 날짜 이동 UX 설계
• 전체 Weekly Review 화면 여백/정렬을 Logs(Grid) 화면과 톤 맞추기

🧩 느낀 점

• Weekly Review 화면의 “형태”가 명확해지니, AI는 정말로 나중에 얹어도 되는 부품이라는 확신이 생겼다
• 지금은 기능을 늘리는 단계가 아니라, 읽기 쉬운 구조를 고정시키는 단계라는 감각이 분명해졌다

• WeeklyReview 기능의 현재 완성도와 경계선을 명확히 정리함

• AI 연결이 불가능한 상황을 전제로 계획 재수립

• 1/14~1/25 중 주말 제외 + AI 제외 현실적인 일정 재설계

• 이번 주 목표를 WeeklyReview UI 단독 완성으로 확정

• 주간 리뷰 시스템의 흐름을 다시 점검

  • 결정론 Context → 저장 → 조회 → (이후 AI 문장화)

• “지금 할 수 있는 것 / 나중에 할 것”을 분리해서 생각함

💡 배운 점

• 기능이 막혔을 때는 멈추는 게 아니라 범위를 줄이는 게 정답

• AI는 핵심이지만, AI 없이도 의미 있는 시스템이 먼저 있어야 한다

• WeeklyReview는

  • 데이터 계산
  • 구조 고정
  • UI 표현 이 3단계가 분리되어야 안정적이라는 걸 다시 확인

• 일정은 길게 잡는 것보다 짧고 명확한 스프린트가 효율적이다

🚀 내일 할 일

• WeeklyReview UI 작업 시작

  • 리뷰 페이지/패널 뼈대 생성
  • 더미 weekly review JSON으로 화면 렌더링

• 패턴(RHYTHM / TOPICS / MIX) 구조를 UI에 매핑

🧩 느낀 점

• 지금 구조는 “AI만 붙이면 되는 상태”까지 잘 왔다
• 조급해질 필요 없이, 지금 가능한 것부터 정확히 완성하는 게 맞다
• DailyLog 2단계는 이미 방향이 흔들리지 않는 상태라는 확신이 든다

• 주간 리뷰 시스템의 AI 연계 구조를 설계하고, AI의 역할을 “정리자”로 한정하는 방향을 명확히 함

• WeeklyReviewService를 기준으로 결정론적 주간 리뷰 Context(JSON) 가 이미 완성되었음을 재확인

• AI 관련 패키지(service.ai)의 책임을 재정의하고, 파일 단위 역할을 정리함

• instruction.txt를 수정하여

  • 평가/훈계/목표 제시 금지
  • mood 데이터는 사실 기반 요약만 허용
  • 출력은 JSON 스키마 강제라는 원칙을 명문화

• Day 6 목표(“AI 입력 & 프롬프트”)의 완료 조건을 점검함

💡 배운 점

• AI 품질은 “모델 성능”보다 입력 컨텍스트와 제약 조건이 더 중요함
• mood 같은 주관 데이터도 → 해석 금지 + 사실 요약만 허용 규칙을 두면 안정적인 시스템 입력이 될 수 있음
• 서비스 레이어에서 이미 결정론이 완성된 상태라면 → AI는 “결과를 말로 풀어주는 어댑터” 이상이 될 필요가 없음
• 프롬프트는 코드만큼이나 명확한 계약(spec) 이 필요함

🚀 내일 할 일

• Day 7 준비: NarrativeResponse 출력 JSON 스키마 정의
• 50자 요약 / 패턴 설명 / 회고 문구를 구조적으로 분리
• AI 출력 실패 시를 대비한 안전 응답 전략 구상

🧩 느낀 점

• “AI를 어디까지 믿을 것인가”가 아니라 “AI가 넘지 못할 선을 어디에 긋는가”가 핵심이라는 확신이 생김
• 지금 구조는 AI가 없어도 의미 있고, AI가 있어도 시스템을 망치지 않는 형태라 안정감이 큼
• v0의 설계 철학이 흔들리지 않고 잘 유지되고 있음

• 주간 리뷰 결정론 엔진 v0 최종 완성

• WeeklyReviewService에 counts + patterns + evidences를 하나의 Context JSON으로 조합

• 패턴별 Evidence 선정 로직 구현

  • RHYTHM / TOPICS / MIX 각각 2~5개 로그 스냅샷 연결
  • rule 기반 근거 명시 (first_active_day, token_match, top_combo_day 등)

• weekly_reviews 저장/재조회 흐름 확정

  • GET: 캐시 조회 (존재하면 그대로 반환)
  • POST: 명시적 생성/갱신

• 컨트롤러/서비스 책임 분리 명확화

• 프론트 로그 입력 이슈 디버깅

  • mood NOT NULL 오류 원인 파악
  • LogDialog / LogsGrid / CalendarPage에 mood 입력 필드 추가

• 미래 날짜 입력 UX 정책 정리 (프론트 차단 + 서버 차단 예정)

💡 배운 점

• AI를 늦추는 게 오히려 설계를 단단하게 만든다

  • AI 이전에 “사람이 읽어도 의미 있는 JSON”을 만드는 것이 핵심

• Evidence는 단순 보조 데이터가 아니라

  • 패턴의 신뢰성을 보장하는 계약(Contract) 역할을 한다

• 주간 리뷰는 “매번 계산”이 아니라

  • weekKey 기준 캐시처럼 동작해야 UX와 비용 모두 안정된다

• DB 제약조건(NOT NULL)은

  • 프론트 UX 설계와 항상 같이 고려해야 한다

🚀 내일 할 일

• (Week 2 시작 준비)

• AI 입력 Context JSON을 기준으로

  • AI 프롬프트 구조 설계
  • 금지 톤/역할 제한 명확화

• 주간 리뷰 GET/POST 플로우 전체 한 번 더 점검

🧩 느낀 점

• 이번 주는 기능 추가가 아니라 구조를 완성한 주였다
• “AI 없이도 완성된 시스템”이라는 기준을 실제 코드로 달성했다는 점이 가장 크다
• 이제 AI는 중심이 아니라 정리자 역할로 안전하게 붙일 수 있는 상태
• 다음 단계로 넘어갈 준비가 명확하게 끝났다

• DailyLog 프론트엔드–백엔드 연동 디버깅

  • 신규 로그 생성 시 mood 컬럼이 NOT NULL인데 프론트에서 값이 전달되지 않아 발생한 SQLIntegrityConstraintViolationException 원인 파악
  • 백엔드 DB 스키마(mood not null) ↔ 프론트 입력 폼 불일치 문제로 정리

• 프론트엔드 입력 구조 개선

  • LogDialog에 Mood 선택 필드 추가
  • enum 값(VERY_BAD)과 label(VERY BAD) 불일치로 발생할 수 있는 매핑 오류 수정
  • form에 mood가 없는 경우를 대비한 기본값 보정 로직 추가

• LogsGrid / CalendarPage 상태 정합성 맞춤

  • LogsGrid와 CalendarPage 모두에서 mood를 포함한 form 상태 관리로 통일
  • create / edit 시 payload에 mood가 항상 포함되도록 정리

• UX 정책 추가

  • “오늘 이후 날짜는 입력 불가”라는 도메인 규칙을 명확히 정의
  • 미래 날짜 클릭 시 로그 입력 모달 대신 안내용 block 모달을 띄우는 구조 설계 및 LogDialog에 반영

• 아키텍처 흐름 재확인

  • 프론트 입력 → 컨트롤러 → 서비스(payload 생성/저장) → (향후) AI → 저장된 weekly payload 재사용
  • 현재 단계에서 “정리자 역할”까지는 안정적으로 구현되었음을 확인

💡 배운 점

• DB 제약 조건은 곧 프론트 UX 요구사항

  • NOT NULL 컬럼 하나가 프론트 입력 설계를 강제한다는 점을 다시 체감
  • “백엔드에서 터지는 에러”는 대부분 프론트에서 예방 가능

• enum은 값과 표현(label)을 반드시 분리해야 한다

  • 사용자에게 보여주는 문자열과 실제 저장되는 enum 값이 섞이면, 나중에 디버깅 비용이 급격히 증가

• 공통 컴포넌트(LogDialog)는 방어적으로 작성해야 한다

  • 페이지마다 form 구조가 조금씩 달라도 깨지지 않도록 기본값 보정(useMemo)이 중요

• 도메인 규칙은 UI에서 명시적으로 드러내는 것이 좋다

  • “미래 날짜 불가”를 단순히 막는 것보다, 이유를 설명하는 모달이 사용자 경험과 코드 가독성 모두에 유리

🚀 내일 할 일

• Weekly Review PatternEvidence 2~5개 연결 로직 최종 점검

  • 로그 삭제/수정 시 snapshot이 유지되는지 다시 한 번 확인

• mood를 활용한 주간 패턴/요약 아이디어 스케치

  • (예: 주간 기분 분포, 특정 패턴과의 상관관계)

• 프론트에서 weekly review payload를 조회/표시하는 화면 초안 구상

🧩 느낀 점

• 오늘 작업은 “기능 추가”라기보다 구조를 단단하게 다지는 날이었다.
• 단순한 에러 하나가 프론트–백엔드–DB–도메인 규칙까지 모두 다시 보게 만들었고, 그 덕분에 DailyLog가 기록 앱 → 시스템으로 한 단계 올라간 느낌이 든다.
• 지금 속도는 빠르지 않지만, 이후 AI나 고급 분석을 붙일 때 흔들리지 않을 기반을 잘 다지고 있다는 확신이 생겼다.

• Weekly Review 기능의 서비스 레이어 리팩토링 진행

• 주간 로그 집계(Counts)와 패턴 분석(Patterns)을 명확한 책임 단위로 분리

• Day2 / Day3라는 작업 단계 중심 네이밍을 제거하고, 도메인 역할 중심 네이밍으로 변경

  • WeeklyReviewPayload
  • CountsSummary

• 주간 리뷰 생성 흐름을 다음과 같이 고정:

  • 주간 로그 단일 조회 → 집계 계산 → 패턴 계산 → 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가 헛소리 못 하게 하는 백엔드”라는 목표에 잘 부합함
• 기능을 더 늘리기보다, 이 구조를 얼마나 오래 버틸 수 있게 만들지가 다음 관건이라는 확신이 생김

• Day 2′(주간 로그 집계) 완결

  • WeeklyReviewService.getWeeklyCounts() 구현 및 검증
  • 카테고리 빈도 집계(Map<Category, Long>)와 DateQuality 산정 완료

• 주간 리뷰 저장 파이프라인 완성

  • generateAndSaveWeeklyReview() 구현 (upsert)
  • weekly_reviews.payload_json에 Day2 전용 payload 저장

• API 연결 및 검증

  • POST /api/reviews/weekly/generate
  • GET /api/reviews/weekly
  • Postman으로 생성→조회→DB 일치 확인

• Flyway 초기 도입 이슈 해결

  • baselineOnMigrate 설정으로 기존 스키마 기준선 확정
  • ddl-auto=validate로 충돌 방지

• 도메인 정합성 정리

  • DailyLog에 Category, logDate 추가 및 DB 컬럼 일치 확인

💡 배운 점

• Flyway 첫 도입 시 non-empty schema + history 없음 에러는 정상적인 케이스이며, baseline으로 해결한다.
• 주간 리뷰는 계산(Counts) → 저장(Upsert) → 조회의 파이프라인이 명확해야 한다.
• payload는 확장 가능한 최소 스키마로 먼저 고정하는 것이 이후 Day3/4(패턴·근거)에 유리하다.
• 엔티티/DB/Repository 계약 불일치가 가장 큰 리스크다. 초기에 맞추는 게 비용을 줄인다.

🚀 내일 할 일

• Day 3′ 시작:

  • PatternContext 구조 고정
  • RHYTHM / TOPICS / MIX 계산 로직 스켈레톤 구현

• payload_json에 patterns 섹션 확장 설계

🧩 느낀 점

• Day 2′를 “완전히 닫으니” 다음 단계로 넘어갈 기준이 명확해졌다.
• AI 없이도 주간 리뷰 자산이 축적되는 구조가 만들어졌다는 점이 가장 큰 수확이다.

• DailyLog 2단계(v0) 작업 진행
• weekly_reviews 테이블 설계 및 MySQL 생성
• 주간 기준(월요일 시작, KST) 계산 로직 구현
• WeekKeyUtil, WeekRangeUtil 유틸 추가
• 주간 리뷰 도메인(WeeklyReview, DateQuality, PatternType) 생성
• GET /api/reviews/weekly 스켈레톤 API 구현
• Flyway 도입 개념 정리 및 V1/V2 마이그레이션 SQL 분리
• 커밋을 DB / 유틸 / 도메인·API 단위로 나누는 전략 정리

💡 배운 점

• “테이블이 있다”와 “마이그레이션이 있다”는 다르다

  • MySQL에 직접 생성한 테이블은 스키마 상태일 뿐, 재현 가능성은 Flyway가 책임진다.

• ddl-auto=update는 개발 속도에는 좋지만, CI/CD·운영 단계에서는 Flyway + validate로 전환하는 게 정석이다.

• enum(DateQuality, PatternType)에 no usage가 뜨는 것은 Service 계층이 아직 없기 때문이며, 설계상 자연스러운 상태다.

• 2단계 v0에서 AI보다 중요한 것은 주간 리뷰를 담을 “그릇”과 계약(API/DB) 을 먼저 고정하는 것이다.

🚀 내일 할 일

• WeeklyReviewService 생성
• 주간 로그 집계 로직 구현
• 로그 개수 기반 DateQuality 계산 규칙 정의
• daily_log → 주간 범위 조회 쿼리 작성

🧩 느낀 점

• 기능을 빨리 붙이는 것보다 구조를 먼저 고정한 게 심리적으로 훨씬 안정적이다.
• “AI 어시스턴트”라는 말에 끌려가지 않고, 결정론 → 그 다음에 AI라는 순서를 지킨 게 잘한 선택이다.
• 지금 단계의 DailyLog는 기능은 적지만 방향은 매우 명확한 상태에 들어왔다.

이번 글에서는 2단계(MVP) 를 어디까지 구현하면 “완료”로 판단할지, 그리고 무엇을 의도적으로 하지 않을 것인지를 명확히 정리한다.

1. 왜 2단계 MVP를 명확히 정의하는가

AI가 붙는 순간, 프로젝트는 쉽게 끝이 없는 상태로 들어간다.

• 더 똑똑하게 만들고 싶고
• 더 많은 분석을 하고 싶고
• 더 많은 말을 하게 만들고 싶어진다

그래서 DailyLog의 2단계는 AI의 성능이 아니라 AI의 역할을 제한하는 단계로 정의한다.

“AI는 여기까지다” 라는 선을 먼저 긋지 않으면, 2단계는 3단계가 되고, 프로젝트는 멈춘다.

2. 2단계 MVP의 목적

2단계의 목적은 단 하나다.

“기록이 쌓였을 때 내가 보낸 한 주(또는 한 달)를 빠르게 되짚어볼 수 있는가?”

• 행동 변화 유도 ❌
• 목표 제시 ❌
• 반성/평가 ❌
• 코칭 ❌

오직 정리와 맥락화만 다룬다.

AI는 “조언자”가 아니라 기록을 대신 펼쳐주는 정리자다.

3. 2단계 MVP 핵심 기능 (Must Have)

1️⃣ 주간 기록 요약 (Weekly Review)

• 주간 단위(월요일 기준)로 리뷰 생성
• 상단에 50자 이내 한 줄 요약 표시
• 이 요약은 판단이 아닌 사실의 요약만 포함한다

2️⃣ 패턴 카드 3종 고정

AI는 아래 3가지 패턴만 다룬다.

• RHYTHM : 기록의 연속/공백 흐름
• TOPICS : 반복적으로 등장한 활동/키워드
• MIX : 같은 날 함께 등장한 카테고리 조합

패턴의 종류는 늘리지 않는다.

3️⃣ 모든 패턴에는 근거가 존재한다

• 각 패턴마다 대표 기록 2~5개를 함께 표시
• 근거는 실제 저장된 로그만 사용한다
• AI가 새로운 사실을 만들어내지 않는다

4️⃣ 회고 문구 1줄

• 매주 리뷰 상단에 회고에 어울리는 문구 1줄 제공
• 명언 인용이 아닌, 중립적인 회고 문구를 기본으로 한다
• 문구는 방향을 제시하지 않는다

5️⃣ AI는 “설명”만 한다

AI가 하는 일:

• 패턴을 문장으로 풀어 설명
• 기록 흐름을 자연어로 정리

AI가 하지 않는 일:

• 평가
• 훈계
• 목표 제안
• 행동 지시

4. 2단계에서 하지 않는 것 (Won’t Have)

의도적으로 제외한 기능들이다.

• 자유 질의형 AI 챗
• 행동 추천 / 코칭
• 목표 관리 / 회고 질문
• 감정 분석
• 알림 / 자동 리마인드
• 기록 자동 생성
• 외부 데이터 연동

이 기능들은 2단계의 범위를 벗어난다.

5. Definition of Done (완료 기준)

아래 조건을 모두 만족하면 2단계는 완료로 판단한다.

1. 주간 리뷰가 안정적으로 생성·저장·재조회된다
2. 요약은 항상 50자 이내로 유지된다
3. 패턴은 항상 동일한 3종 구조로 표시된다
4. 모든 패턴에 실제 기록 근거가 연결된다
5. AI가 평가/훈계/목표 톤을 사용하지 않는다
6. 2~3주 사용 후, 매주 한 번 이상 리뷰를 열어본다

6. 2단계 이후를 분리하는 이유

2단계는 나만 쓰는 도구다.

• 정교함보다 안정성
• 똑똑함보다 신뢰
• 확장보다 경계 설정

이 단계가 명확해야, 2.5단계(CI/CD & 클라우드 안정화), 3단계(Web/App 확장)가 자연스럽게 분리된다.

7. 정리

DailyLog의 2단계는 AI를 붙이는 단계가 아니라,

AI를 ‘통제된 역할’로 고정하는 단계다.

AI가 말을 많이 하지 않아도, 기록이 잘 정리되어 있다면 2단계는 성공이다.

이번 글에서는
내가 처음에 정의했던 1단계(MVP)의 기준에 실제로 도달했는지를 점검하고,
그 기준을 충족했기 때문에 2단계로 넘어갈 수 있는지를 스스로 판단한다.

이 글은 “회고”이자 동시에
다음 단계를 허용해도 되는지에 대한 검증 문서다.

1. 왜 1단계 MVP를 명확히 정의했는가

사이드 프로젝트에서 가장 흔한 실패는 이것이다.

• 기능을 계속 추가한다
• 끝이 없다
• 결국 안 쓴다
• 목표점이 확실하지 않다

그래서 DailyLog는 처음부터 이렇게 정했다.

“기능을 늘리는 프로젝트”가 아니라
완료 기준점이 먼저 존재하는 프로젝트

즉, ** 1차적인 기준점을 먼저 만들고, 거기에 도달하면 멈춘다.**

2. 1단계 MVP의 목적 (다시 확인)

1단계의 목적은 단 하나였다.

“캘린더를 열었을 때
내가 어떤 하루들을 보내고 있는지
직관적으로 인식할 수 있는가?”

의도적으로 제외한 것들:

• 생산성 향상 ❌
• 목표 달성 ❌
• 습관 강제 ❌

오직 ‘인식’과 ‘기록’만 다룬다.

3. 1단계 MVP 핵심 기능 — 실제 구현 여부

1️⃣ 캘린더 중심 UI

• 첫 화면 = 월간 캘린더 ✅
• 날짜별 기록이 카테고리 색 블록으로 표시 ✅
• 한 달의 흐름을 스크롤 없이 인식 가능 ✅

→ 캘린더는 단순한 뷰가 아니라 ‘진입점’ 및 '대시보드' 역할을 한다.

2️⃣ 기본 기록 CRUD

• 생성(Create) ✅
• 조회(Read) — 월 단위 기준 ✅
• 수정(Update) ✅
• 삭제(Delete) ✅

→ 캘린더 / 그리드 어디서든 동일한 모달 UX 사용

3️⃣ 카테고리 + 색상 고정

• 카테고리 enum 고정 (EXERCISE / STUDY / MEETING) ✅
• 카테고리별 색상 통일 ✅
• 사용자 커스터마이징 없음 ✅

→ 시각적 의미를 줄이기 위해 선택지를 줄였다.

4️⃣ 최소 입력 UX

• 필수 입력:
  • 날짜(logDate)
  • 카테고리
  • 제목(title)
• 메모(content)는 선택이지만 권장
• “작성”이 아니라 “확인 후 저장”에 가까운 흐름 ✅

5️⃣ 최근 7일 복사 입력

• 최근 1주일 기록 계산 ✅
• 클릭 1번으로 자동 채움 ✅
• 저장까지 2~3번의 액션으로 완료 ✅
• EXERCISE 우선 추천 로직 적용 ✅

→ 반복 기록의 ‘귀찮음’을 제거하는 데 실제로 효과가 있었다. (하지만 이를 카테고리 별로 줄일지 더 고민해야하는 문제임)

4. 1단계에서 하지 않기로 한 것 — 지켰는가?

의도적으로 제외한 기능들:

• 알림 / 리마인드 ❌
• 차트 / 통계 ❌
• AI 요약 ❌
• 커스텀 이미지 / 도트 트래커 ❌
• 세부 운동 구조화 ❌
• 로그인 / 계정 / 공유 ❌
• 모바일 앱 ❌

👉 단 하나도 넣지 않았다.

이 점이 오히려 이번 단계의 완성도를 높였다.

5. 기준점 최종 점검

아래 조건을 모두 만족하면
1단계는 ‘완료’로 판단하기로 했다.

• 캘린더에 월 단위 기록이 정상 표시된다 ✅
• 날짜 클릭 → 추가/수정/삭제가 안정적이다 ✅
• 색 블록만 봐도 하루의 활동이 인식된다 ✅
• 최근 7일 복사 입력으로 빠르게 기록 가능하다 ✅
• 실제로 며칠 이상 사용해도 거부감이 없다 ✅

👉 모두 충족했다.

따라서
1단계는 완료되었다고 판단한다.

⚠️ 중간에 겪은 실패: WebSquare 연동 시도

처음에는 프론트엔드를
WebSquare 기반으로 구성하려는 시도를 했다.

SI회사 특성상 웹스퀘어, 넥사크로, 엑스프레임 같은 것을 많이 써서 선행 학습 및 적응용으로 쓰기 위해 시도했다.

결과는 실패였다.

실패 이유

• 유효한 라이선스 없이는 정상적인 개발이 어려움
• SPA 구조에 맞지 않음
• Git 협업 / 컴포넌트 분리에 치명적인 제약
• 개인 프로젝트의 속도와 목적에 부적합

중요한 교훈

이 실패는 시간 낭비가 아니었다.

• “기술적으로 가능한가?”보다
• “이 프로젝트의 목적과 맞는가?”가 더 중요하다는 걸 깨달았다.

그래서 과감히:

• WebSquare 제거
• React SPA로 전면 전환
• Backend는 순수 API 서버로 역할 고정

👉 이 결정이 없었다면
지금의 1단계 완성도는 불가능했다.

Related Posts: 연동시키기 1편 연동시키기 2편 연동시키기 3편

🤖 2단계로의 전환 — AI 어시스턴트

1단계가 끝났기 때문에
이제서야 2단계를 이야기할 수 있다.

2단계의 역할 정의

AI는 코치도, 평가자도 아니다.
“정리자” 역할만 수행한다.

2단계에서 할 것

• 주간 / 월간 기록 요약
• 패턴 인식
• 맥락 정리 (무슨 날이 많았는지, 흐름이 어땠는지)

하지 않을 것

• 평가 ❌
• 훈계 ❌
• 목표 설정 ❌
• 행동 교정 ❌

👉 판단은 여전히 사용자의 몫

AI는 해석을 도와줄 뿐이다.

(이에 관련한 프롬프트 작성 및 수치적으로 어떻게 평가할 건지에 대해서 공부해야한다..)

7. 정리

DailyLog 1단계는:

• 작다
• 단순하다
• 하지만 방향이 명확하다

기능을 많이 만드는 대신
사용 흐름이 깨지지 않는 것을 목표로 했다.

Vite도 활용해보고 프론트와 백 모두 다룰 수 있어서 좋았다.

• 캘린더 UI 안정화 마무리

  • CalendarView에서 이벤트 title overflow 처리 (ellipsis + tooltip)
  • dayMaxEvents={3} 적용으로 일정 과다 시 UI 깨짐 방지
  • fixedWeekCount={false}로 월별 높이 자연스럽게 조정

• 이벤트 데이터 방어 로직 강화

  • logDate 유효성 체크 후 이벤트 생성 (YYYY-MM-DD 길이 기준)
  • 잘못된 데이터가 FullCalendar로 들어가지 않도록 map → filter(Boolean) 패턴 적용

• 삭제/수정 흐름 최종 점검

  • 캘린더에서 삭제 버튼 동작 확인
  • 삭제 후 캘린더/모달 상태 정상 동기화 확인

• 목요일 UI 미세 조정 과제 완료 판단

  • 캘린더 이벤트 표시 안정성 확보
  • 사용 중 “왜 이래?” 나오는 구간 제거

💡 배운 점

• FullCalendar는 start 값이 애매하면 경고 없이도 UI 이상이 생길 수 있어 사전 필터링이 중요함
• map 단계에서 유효하지 않은 데이터는 아예 null로 만들고 filter(Boolean)로 제거하는 방식이 가장 읽기 좋고 안전함
• UI 미세 조정은 “기능 추가”보다 예외/엣지 케이스 제거가 체감 품질을 훨씬 크게 올림

🚀 내일 할 일

• DataGrid 쪽 UI 최종 정리

  • 컬럼 폭/행 밀도 재확인
  • 캘린더와 동일한 UX 톤 유지

• 전체 플로우 10~15분 실제 사용 테스트

• 1단계(MVP) 종료 기준 정리 및 브랜치 마무리

🧩 느낀 점

• 기능 구현보다 안정화와 방어 코드가 프로젝트 완성도를 결정한다는 걸 체감함
• 오늘 작업으로 “사이드 프로젝트 티”가 많이 빠졌고, 실제 서비스처럼 쓸 수 있는 상태에 가까워짐

• Calendar / DataGrid 공통 LogDialog 재사용 구조 완성

• useLogsApi 도입으로 프론트엔드 데이터 계층 단일화

  • CalendarPage / LogsGrid에서 axios 직접 호출 제거
  • list / create / update / remove API 접근을 한 곳으로 통합

• Grid 화면 UI 개선

  • DataGrid width/height 조정으로 컬럼 잘림 문제 해결

• 상단 네비게이션 개선

  • NavLink 기반으로 현재 페이지(Calendar / DataGrid)만 active 컬러 표시

• 전체 플로우 점검

  • 캘린더 ↔ 그리드 동일한 CRUD UX 유지 확인

💡 배운 점

• UI 컴포넌트 재사용보다 더 중요한 건 데이터 흐름의 일관성

• axios 호출을 흩어두면 “작동은 되지만 유지보수는 망가진다”

• useLogsApi 같은 얇은 추상화 레이어만 있어도

  • API 변경 비용이 급격히 줄어든다

• NavLink + isActive 패턴은 탭 UI에서 거의 정답에 가깝다

🚀 내일 할 일

• 공통 데이터 계층(useLogsApi) 기준으로 코드 정리 마무리

• UI 디테일 정리

  • 버튼 간격 / 컬럼 가독성

• 1단계 마무리 기준 점검

  • “설명 없이 써도 되는가?”
  • “다음 주에 다시 열고 싶을까?”

🧩 느낀 점

• 기능 추가보다 구조를 정리한 날
• 이 시점에서 느끼는 안정감은 “코드가 통제되고 있다”는 감각에서 온다
• 지금 상태면 MVP 1단계는 명확히 끝났다
• 다음 단계는 기능이 아니라 밀도를 높이는 작업이 될 것

• Logs(Grid) 화면 분리 완료

  • Calendar와 분리된 LogsGrid 페이지 구성
  • /api/logs를 공용 데이터 소스로 유지

• LogDialog 공용 컴포넌트 적용

  • Calendar / Grid 모두 동일한 Dialog 사용
  • mode(create/edit), form, onSave/onDelete 인터페이스 통합

• CRUD 흐름 통합

  • 생성/수정/삭제 로직을 동일한 패턴으로 정리
  • optimistic update 방식으로 UI 즉시 반영

• DataGrid UI 문제 해결

  • 가로 잘림 이슈 해결 (width: 100%, flex, minWidth 조정)
  • 스크롤/페이지네이션 정상 동작 확인

💡 배운 점

• 화면이 달라도 Dialog·Form·CRUD 흐름은 하나의 규약으로 묶는 게 유지보수에 압도적으로 유리하다.
• 데이터가 적을 때 “잘 돌아가는 것처럼 보이는 코드”와 구조적으로 안전한 코드는 전혀 다르다.
• 기능 추가보다 먼저 화면/컴포넌트 경계를 명확히 나누는 작업이 전체 개발 속도를 올린다.

🚀 내일 할 일

• Calendar / Grid 공용 로직 정리 여부 최종 점검
• 불필요한 상태(state) 중복 제거
• 1단계 마무리 기준 재확인 및 PR 정리

🧩 느낀 점

• 오늘은 “기능을 만든 날”이 아니라 구조를 완성한 날이다.
• 이 상태면 이후 작업은 쌓는 일이지, 고치는 일이 아니다.
• 여기서 더 욕심내면 오히려 망가질 수 있는 지점까지 왔다.

이번 글에서는

왜 인덱스가 필요한지 → 어떤 인덱스를 추가했는지 → 실제로 인덱스를 타는지 를 EXPLAIN 기준으로 정리한다.

1️⃣ 현재 문제 인식

초기 상태의 daily_log 테이블은 다음과 같았다.

SHOW INDEX FROM daily_log;

결과

• PRIMARY KEY (id)만 존재
• log_date, category 관련 인덱스 없음

즉,

• 날짜 기반 조회
• 최근 7일 조회
• 월 단위 캘린더 조회
• 카테고리 필터

모두 풀 테이블 스캔(Full Scan) 상태였다.

데이터가 적을 때는 문제가 없어 보이지만, 데이터가 쌓이면 성능 저하가 바로 발생할 수 있는 구조였다.

2️⃣ 사용 패턴 분석

DailyLog에서 실제로 발생하는 조회 패턴은 다음과 같다.

• 📅 월 단위 캘린더 조회 (log_date BETWEEN)
• 🕒 최근 7일 기록 조회
• 🏋️ 최근 7일 중 EXERCISE 우선 노출
• 📌 특정 날짜 클릭 조회

→ 모든 쿼리의 중심은 log_date

3️⃣ 인덱스 설계 전략

✅ 필수 인덱스: log_date

ALTER TABLE daily_log
ADD INDEX idx_daily_log_log_date (log_date);

• 날짜 범위 조회 최적화
• 캘린더/최근 기록/날짜 클릭 전부 커버

✅ 복합 인덱스: (log_date, category)

ALTER TABLE daily_log
ADD INDEX idx_daily_log_log_date_category (log_date, category);

• 최근 7일 + 카테고리 필터
• 향후 통계/집계 대비

복합 인덱스는 왼쪽 컬럼부터 사용되므로 log_date → category 순서가 중요하다.

4️⃣ 인덱스 적용 결과

SHOW INDEX FROM daily_log;

결과 요약

👉 의도한 인덱스가 정확히 적용됨.

5️⃣ 인덱스가 실제로 사용되는지 확인 (EXPLAIN)

① 월 단위 조회 (캘린더)

EXPLAIN
SELECT *
FROM daily_log
WHERE log_date >= '2025-12-01'
  AND log_date <  '2026-01-01'
ORDER BY log_date DESC, created_at DESC;

기대 결과

• type = range
• key = idx_daily_log_log_date 또는 복합 인덱스

결과값

② 최근 7일 조회

EXPLAIN
SELECT id, title, category, log_date
FROM daily_log
WHERE log_date >= CURDATE() - INTERVAL 6 DAY
  AND log_date <= CURDATE()
ORDER BY log_date DESC;

결과값

③ 최근 7일 + 카테고리 필터

EXPLAIN
SELECT id, title, category, log_date
FROM daily_log
WHERE log_date >= CURDATE() - INTERVAL 6 DAY
  AND log_date <= CURDATE()
  AND category = 'EXERCISE'
ORDER BY log_date DESC;

기대 결과

• key = idx_daily_log_log_date_category
• type = range 또는 ref

결과값

④ 특정 날짜 클릭 조회

EXPLAIN
SELECT id, title, category, log_date
FROM daily_log
WHERE log_date = '2025-12-12'
ORDER BY created_at DESC;

결과값

6️⃣ 인덱스 사용 여부 체크 포인트

EXPLAIN 결과에서 아래만 보면 된다.

⚠️ 특히 아래 형태는 인덱스를 못 탄다:

WHERE DATE(log_date) = '2025-12-12'

반드시 이렇게 써야 한다:

WHERE log_date = '2025-12-12'

7️⃣ 결론

• 테이블 구조 변경 ❌
• 데이터 삭제 ❌
• 인덱스 추가만으로 구조 안정화 완료 ✅

“구조는 이미 맞았고, DB가 그 구조를 제대로 받쳐줄 차례였다.”

이번 작업으로 DailyLog는 데이터가 늘어나도 프론트 구조를 바꾸지 않아도 되는 상태가 되었다.