일지 탐색 날짜가 운동 저장 날짜를 바꾸지 않도록 분리 (2026-09-10)
- 기간: 2026-09-10, 오너 지시 “응 특히 일지에서 선택한 날짜는 일지 탭 내에서만 영향력이 있도록 제한해줄래?”
- 랜딩: 앱 PR #1539 →
release/v0.17.10, 병합4d9705c617821f79be085859cfe1d928a9e4156c(2026-09-10 19:27:54 KST). 구현6ca14e1a96b6bf0dab6a7c167aa8c787ba0caf7c의 포함을 원격 release에서 확인했다. Production 승격·배포는 이번 범위 밖. - 설계서: 없음(수리 건). 이슈 #1529 설계·검증 기준.
- 정본·계약: 일지 날짜 경계, 운동 초안 보호.
- 도구: 앱 기존 검사·precheck·Merge Check. 운영 실측 SQL과 결과는 조사 checkout 상위
work/에 로컬 보관하며 인증정보는 기록하지 않았다. - 게이트: Phase 1·2
npm run check각각 3,400 통과·0 실패·35 조건부 skip(Phase 2 101.0초), CASE-011 실제 브라우저+격리 DB 1/1 통과(28.7초). precheck 성공(1분 54초), Merge Check 성공(검사·반영 단계 37초). 신규 DB 마이그레이션·SQL·pgTAP 변경 없음. - 버그리포트: BUG-105.
- 후속 원본 수리: 별도 오너 승인 #1546으로 19:46:06 KST에 대상 운동의 날짜 한 값을 Production에서 복구했다. 앱 코드 배포와 별개이며 상세 감사·검증은 아래 후속 절을 따른다.
Phase 현황
| Phase | 내용 | 상태 |
|---|---|---|
| Phase 1 | 일지·운동 날짜 분리, 초안·저장·복원 날짜 보존 | 완료 — PR #1539 (4d9705c6), check 통과 |
| Phase 2 | 사용자 경로 회귀, 계약·버그 기록 | 완료 — PR #1539 (4d9705c6), CASE-011·최종 check 통과, 문서 등록·검사 완료 |
1. 배경
오늘 저장한 화이트보드 운동이 오늘 일지에서 빠졌다. 원본은 3종목·10세트가 남았지만, 화이트보드 출처 날짜 9/10과 달리 운동 날짜가 최초 저장부터 9/1이었다. 사건의 실제 사용자 클릭 이력은 미확인이다.
2. 문제 제기
운동 초안의 시작 날짜가 화면 변환에서 빠졌고, 저장·보존이 일지 탐색과 같은 날짜 상태를 사용했다. 확인된 함수 재현은 9/10 시작 → 일지 9/1 선택 → 9/1 저장이다. 원본·집계는 같은 날짜를 가리키므로 단순 집계 갱신 문제로 판단하지 않았다.
3. 해결 방안
D1(2026-09-10): “메인화면에서 운동을 시작하거나, 그룹 보드에서 시작한 운동은 당연히 오늘로 기록되어야하거든”. D2: 일지 선택일의 영향은 일지 탭에 한정한다.
일지 선택일은 조회 전용 상태로 분리하고, 운동 시작·과거 기록 추가·기존 기록 수정에서 날짜를 한 번 확정해 초안이 소유하도록 했다. 저장 때 오늘 강제와 이어하기 때 일지 날짜 초기화는 과거 기록·자정 이후 복원을 깨뜨리거나 공유 상태 의존이 남으므로 기각했다.
4. 적용한 내용
Phase 1은 일지 선택 날짜와 운동·계획 편집 날짜의 상태·전달 경로를 분리하고 초안 변환·저장·체크포인트·복원에 같은 날짜를 보존했다. Phase 2는 CASE-011의 실제 일지 탐색·이어하기·재시작·저장·DB 재조회 단언과 계약·버그 기록을 보강했다. 변경 파일과 검증 범위는 BUG-105를 따른다. 19:27 release 반영까지의 코드 수리 단계에는 DB·운영 원본 수정이 없었다.
후속 — 해당 운동 한 건의 날짜 복구 (#1546)
이후 오너가 “오늘 성근 계정에 잘못기록되었던 운동을 원래 있어야할 날짜에 복귀시켜줄 수 있어?”라고 명시 승인해 별도 #1546 수리 티켓을 만들었다. 사전 db:loss-audit는 보호 테이블 23개·누락 0, 날짜 한 값 변경·삭제 0·다른 원본 변경 0을 658ms에 확인하고 감사 트랜잭션을 전부 되돌렸다.
실제 수리는 19:46:06.637846 KST에 대상 날짜 9/1 → 9/10·revision 1 → 2로 완료했고, 변경 전 이력 2655와 changed_columns=['date']·issue#1546을 남겼다. 대상 세션과 자식 원본 5개 테이블의 날짜 제외 fact 해시는 동일하다. 정상 통계 job은 1회 시도로 19:46:19.409177 KST에 완료돼 requested/applied 512 = 512, 미처리 dirty 없음으로 수렴했다. 세션·job 식별자와 원본 행별 대조는 BUG-105 후속 수리 기록에 둔다.
피드 누락처럼 보인 원인은 date DESC 우선 정렬이었다. 운영 실제 피드 엔진에서 복구 전 팔로워 첫 20건에는 없고 본인 피드는 15번째였으며, 전체 조건상 팔로워 순위는 24위(2페이지)였다. 복구 후 두 계정 모두 첫 페이지 2번째로 확인했다. 화이트보드 제외·게시 누락이 아니며 실제 사용자 UI 캐시를 확인한 결과와 구분한다. 이 후속 작업의 코드·스키마·배포 변경은 없다.
5. 적용 결과
| 항목 | 전 → 후 / 검증 범위 |
|---|---|
| 일지 탐색의 타 탭 영향 | 공유 날짜 참조 → 일지 조회 상태로 한정. 모바일·데스크톱 실제 셸 콜백 검사에서 운동 날짜 변경 호출 0회 |
| 진행 중 운동의 날짜 | 선택 날짜로 저장되는 함수 재현 → CASE-011의 탐색·재개·재시작·저장·DB 재조회에서 시작일 유지, 1/1 통과(28.7초) |
| 초안 자동 저장·복원 | 공유 환경 날짜 사용 → 초안/봉투 날짜 보존. 체크포인트·계정 전환·날짜 없는 기존 초안 복원 검사 통과 |
| 그룹 운동 | 공통 운동 화면의 날짜 누락 → 화이트보드 형태 초안의 날짜 보존을 컴포넌트로 확인. 그룹 시작부터 전체 브라우저 동작은 미실행 |
| 과거 기록·기존 수정 | 선택/원본 날짜를 사용하던 의미 → 진입 시 명시 전달로 유지. 이번 CASE-011이 이 경로의 전체 브라우저 검증을 대신하지 않음 |
| 로컬 검사 | Phase 1·2 check 각각 3,400 통과·0 실패·35 조건부 skip. Phase 2 101.0초 |
| precheck | HEAD 6ca14e1a, base a66c706b에서 성공(1분 54초). static 58초, unit1 1,671 통과·12 skip(54초), unit2 1,729 통과·23 skip(1분 53초), 실패 0 |
| release 통합 | 앱 PR #1539의 Merge Check 성공, 검사·반영 단계 37초. 19:27:54 KST 4d9705c6으로 실제 release 병합 확인 |
| 문서 검증 | npm run check·build:docs·check:docs-artifact 통과. 333개 경로·31개 자산 확인 |
| 앱 코드 운영 적용 | 코드 수리는 release 반영까지 완료. 후속 원본 복구는 앱 코드 Production 배포를 수행하거나 검증한 결과가 아님 |
| 대상 원본 날짜 | 최초 코드 수리 때 변경 없음 → 별도 #1546 승인 후 Production 날짜 9/1 → 9/10, revision 1 → 2. 날짜 외 원본 fact 해시 동일 |
| 날짜별 집계 | 9/1: 2운동·4종목·11세트 → 1운동·1종목·1세트. 9/10: 1운동·1종목·1세트 → 2운동·4종목·11세트. 정상 job 1회 완료·버전 512 = 512 |
| 피드 조회 | 팔로워 24위(첫 페이지 미포함)·본인 15위 → 운영 실제 엔진에서 둘 다 첫 페이지 2번째. 실제 UI 캐시는 미검증 |
6. 이번 개선으로 향상된 것
운동 중 지난 기록을 둘러봐도 운동 날짜가 시작일에 남는다. 일지 조회와 운동 저장의 날짜 원천이 분리되어 자동 저장·재개·앱 리로드에도 같은 계약을 적용한다.
남은 것
코드 구현은 release/v0.17.10 실제 병합까지 완료했고, 이후 별도 승인 #1546의 대상 원본 날짜 복구와 정상 집계·피드 엔진 결과 확인도 완료했다. Production 앱 코드 승격·배포는 이 작업에서 수행하지 않았다. 그룹 보드 시작부터의 전체 브라우저 동작, 사건의 실제 사용자 클릭 이력, 사용자가 열어 둔 실제 UI 캐시는 미검증이다.