[TIL] 2026-01-08

🎯 오늘 한 일

• 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나 고급 분석을 붙일 때 흔들리지 않을 기반을 잘 다지고 있다는 확신이 생겼다.