[개발 회고] 엔진은 삭제 레코드를 진짜로 지우지 않는다
엔진은 삭제 레코드를 진짜로 지우지 않는다
개발 회고 — 2026-07-06 (월요일)
오늘 작업 요약
캘린더 목록 뷰의 네비게이션 테스트를 작성하고, 캘린더와 같은 페이지의 소스 그리드 간 동기화 메커니즘을 리팩토링했다. 그 과정에서 삭제된 일정이 캘린더에 잔존하는 문제와 불필요한 리프레시로 인한 unsaved data 유실 위험을 함께 다뤘다. 아직 커밋 전 상태로, 6개 파일에 걸쳐 166줄 추가/24줄 삭제가 진행 중이다.
- 캘린더 목록 뷰 네비게이션 테스트 작성 — 미래 일정 생성/전체 삭제 helper 함수 추가, “다음” 버튼 점프 동작 검증 테스트 2개 추가
- 캘린더와 소스 그리드 동기화 메커니즘 리팩토링 — 같은 페이지 소스 그리드 리프레시 메서드 분리로 불필요한 리프레시 제거 및 unsaved data 보존
- 삭제된 일정 캘린더 잔존 문제 해결 — 삭제 상태 필터링으로 엔진 인덱스에 남아있는 레코드를 UI에서 제거
- 라이프사이클 정리 — 데이터 로드 완료 시점과 저장 완료 시점 이벤트 구분, 누락된 컴포넌트 연결 해제 로직 보충
- 캘린더 콜백 흐름 개선 — Promise chain으로 리프레시 이후 이벤트 생성이 보장되는 순서로 정리
STAR 정리
Situation (상황)
캘린더 컴포넌트는 같은 페이지에 있는 소스 그리드의 데이터를 복사해서 사용하는 구조였는데, 이 때문에 외부에서 소스 그리드가 변경될 때 이를 감지해 반영하는 것과 캘린더 자체의 저장되지 않은 데이터를 보존하는 것 사이에 충돌이 있었다. 또한 일정을 삭제해도 캘린더 화면에 계속 남아있는 문제가 있었는데, 이는 엔진이 인덱스 유지를 위해 삭제된 레코드를 실제로는 지우지 않고 상태만 변경하기 때문이었다. 목록 뷰의 “다음” 버튼 네비게이션에 대한 테스트도 없는 상태였다.
Task (과제)
- 목록 뷰 네비게이션의 “다음” 버튼 점프 동작을 검증하는 테스트 작성
- 소스 그리드 변경 감지와 캘린더의 unsaved data 보존을 동시에 만족하는 동기화 구조 설계
- 삭제된 일정이 화면에 남아있는 문제를 근본 원인(엔진의 삭제 레코드 처리 방식)에 맞게 해결
- 데이터 로드/저장 관련 라이프사이클 이벤트를 구분해 불필요한 리프레시 방지
- 리프레시와 이벤트 생성 로직의 실행 순서를 보장
Action (행동)
- Cypress 테스트 파일에 미래 일정을 생성하고 모든 일정을 재귀적으로 삭제하는 helper 함수를 추가하고, 이를 활용해 “다음” 버튼 점프 동작을 검증하는 테스트 2개를 작성함
- 같은 페이지의 소스 그리드를 리프레시하는 전용 메서드를 분리해, 불필요한 시점에 리프레시가 발생하지 않도록 하고 캘린더의 unsaved data가 보존되도록 처리함
- 삭제된 행 상태를 나타내는 상수 기반으로 필터링 로직을 추가해, 엔진 인덱스에는 남아있지만 실제로는 삭제된 레코드가 캘린더 화면에 표시되지 않도록 수정함
- 데이터가 로드만 된 시점(셀 편집 시에도 발생)과 실제로 저장이 완료된 시점을 구분하는 이벤트 구독 로직을 정리하고, 누락되어 있던 컴포넌트 연결 해제 로직을 보충함
- 소스 그리드 리프레시 이후에 캘린더 이벤트 생성이 실행되도록 Promise chain으로 콜백 흐름의 실행 순서를 보장함
Result (결과)
- “다음” 버튼 네비게이션에 대한 테스트가 추가되었으나, helper 함수가 실제로 안정적으로 동작하는지는 아직 실행 검증 전
- 소스 그리드 동기화 리팩토링으로 불필요한 리프레시 발생 경로를 하나 줄였으나, 여전히 리프레시가 발생하는 지점이 여러 곳에 흩어져 있어 완전히 정리되지는 않은 상태
- 삭제된 일정 잔존 문제는 필터링 로직 추가로 해결된 것으로 보이나, 아직 커밋 전이라 실제 회귀 여부는 검증되지 않음
- 전체 작업이 미커밋 상태로, 다음 단계는 커밋과 테스트 실행 검증
실제 측정 가능한 지표
| 지표 | 확인 방법 | 비고 |
|---|---|---|
| 변경 규모 | git diff --stat (unstaged) |
6개 파일, 166줄 추가/24줄 삭제 |
| 신규 작성된 Cypress 테스트 수 | 테스트 파일 내 it() 블록 개수 확인 |
“다음” 버튼 관련 테스트 2개 |
| 삭제된 일정 잔존 버그 재현 여부 | 필터링 로직 적용 전/후 수동 재현 테스트 | 삭제 후 화면 새로고침 없이 즉시 사라지는지 확인 |
| 리프레시 발생 횟수 | 리프레시 메서드에 로그/카운터 추가 후 콘솔 확인 | 리팩토링 전/후 호출 횟수 비교 가능 |
| Promise chain 적용 후 실행 순서 | 콜백 내부에 타임스탬프 로그 추가 | 리프레시 완료 후 이벤트 생성이 실행되는지 확인 |
추정 가능한 효과 (근거 포함)
- 불필요한 리프레시 감소로 unsaved data 유실 위험 감소 (추정): 같은 페이지 소스 그리드 리프레시를 전용 메서드로 분리하면서, 이전에는 모든 변경에 반응해 리프레시하던 것을 필요한 시점에만 리프레시하도록 좁혔을 것으로 보임. 근거: 코드 상 리프레시 메서드가 분리되고 불필요한 호출 제거를 목표로 수정된 것을 확인함. 다만 실제로 리프레시 발생 빈도가 얼마나 줄었는지는 로그 기반 정량 확인이 아직 없음.
- 삭제된 일정 잔존 문제 해결 (추정): 삭제 상태 필터링을 추가함으로써 엔진 인덱스에 남아있는 레코드가 UI에 노출되지 않게 될 것으로 예상됨. 근거: 필터링 로직이 삭제 상태 상수를 기준으로 추가된 것을 확인함. 다만 커밋 전 상태이고 실제 재현 테스트는 아직 하지 않아 확정할 수 없음.
더 측정하면 좋은 지표
- 리프레시 호출 빈도: 여러 흐름(같은 페이지 소스 데이터 있음/없음)에서 실제로 몇 번 리프레시가 발생하는지 로그로 수집
- “다음” 버튼 네비게이션 테스트의 안정성: 여러 번 반복 실행해 flaky 여부 확인
- 삭제 후 캘린더 반영 지연 시간: 삭제 액션부터 화면에서 사라지기까지 걸리는 시간 측정
- postDataLoaded/postDataSaved 이벤트 발생 빈도 비교: 리팩토링 전/후 각 이벤트가 얼마나 자주 발생하는지 비교해 실제로 분리된 목적대로 동작하는지 확인
- Promise chain 적용 후 순서 보장 여부: 다양한 타이밍(느린 네트워크, 빠른 연속 조작 등)에서도 순서가 깨지지 않는지 테스트
오늘 배운 것
- 같은 페이지의 소스 데이터를 복사해서 쓰는 컴포넌트는 외부 변경 감지와 자신의 unsaved data 보존이라는 두 요구사항이 충돌할 수 있고, 이를 Promise chain으로 순서를 보장하는 방식으로 풀 수 있다는 것을 확인함
- 엔진이 삭제 레코드를 인덱스 유지를 위해 실제로는 지우지 않는다는 점을 처음으로 명시적으로 다뤄봤고, UI에 반영할 때는 삭제 상태 필터링이 필수라는 것을 배움
- 데이터가 로드된 시점(셀 편집만 해도 발생)과 실제로 저장이 완료된 시점을 구분하지 않으면 불필요한 리프레시가 계속 발생할 수 있다는 것을 확인함
어려웠던 점 / 막힌 부분
- 캘린더 리프레시가 여러 곳에서 발생하는 구조라, 같은 페이지 소스 데이터가 있을 때와 없을 때 흐름이 다르고 각 경로마다 호출되는 로직도 달라 전체 흐름을 파악하기 어려웠음. 리프레시 메서드를 분리해 일부 개선했지만, 호출 지점이 여러 곳에 남아있어 여전히 실수의 여지가 있음
- 목록 뷰 네비게이션 테스트를 위해 깨끗한 상태에서 시작해야 했는데, 기존에 쌓인 일정들을 재귀적으로 삭제하는 helper 함수를 새로 만들어야 했음. 이 helper가 실제로 안정적으로 동작하는지는 아직 실행 검증이 필요함
내일 하면 좋은 작업
- 목록 뷰 “이전” 네비게이션 개선 — 현재와 이전 스케줄 범위가 일정 기간을 초과할 때 중간 달을 건너뛰지 않고 단계적으로 이동하도록 수정
- 작성 중인 코드를 커밋하고 Cypress 테스트 실행으로 검증
- 캘린더 리프레시 흐름을 문서화하거나 주석으로 더 명확히 정리
한 줄 요약
오늘은 캘린더 목록 뷰의 네비게이션과 데이터 동기화를 정비하면서 같은 페이지의 소스 데이터 관리 복잡성을 직면했고, 이를 Promise chain과 상태 체크로 개선한 하루였다.
댓글남기기