[개발 회고] 틀린 가설을 실제 로그로 검증한 날
틀린 가설을 실제 로그로 검증한 날
개발 회고 — 2026-07-30 (수요일)
오늘 작업 요약
캘린더가 같은 페이지의 원본 그리드와 연동되어 있을 때, 필터가 적용된 상태에서 캘린더가 비어 보이는 버그를 디버깅하고 수정했다. 초기 가설이 틀렸다는 것을 사용자의 실제 로그로 확인하고, 비동기 데이터 로딩의 타이밍 문제를 이벤트 대칭성 부족으로 특정해 해결했다.
- 원본 그리드의 데이터 로드 이벤트 구독/해제 로직 추가 — 캘린더 마운트 시 그리드 연결, 언마운트 시 연결 해제
- 캘린더 데이터 생성 순서 개선 — 원본이 다른 그리드인 경우, 먼저 데이터를 동기화한 뒤 이벤트를 생성하도록 처리
- 필터 연동 시나리오를 검증하는 E2E 테스트 추가 — 원본 필터에 연결된 필터가 있는 그리드를 원본으로 둔 캘린더가, 최초 진입 및 새로고침 시에도 일정을 올바르게 표시하는지 검증
- 브라우저 콘솔 디버그 로그 추가해 사용자 환경에서의 실행 흐름 추적
STAR 정리
Situation (상황)
캘린더와 같은 페이지의 그리드가 연동되어 있을 때, 그리드의 필터가 적용된 상황에서 캘린더를 열면 마치 데이터가 없는 것처럼 일정이 표시되지 않는 버그가 있었다. 필터 자체는 올바르게 동작하고 있었고, 일정 데이터도 그리드에 있었으나 캘린더에는 나타나지 않는 상황이었다.
Task (과제)
- 캘린더 필터 연동 버그의 근본 원인 파악
- 원본 그리드와의 데이터 동기화 타이밍 문제 해결
- 버그를 검증하는 자동화 테스트 작성
Action (행동)
- 처음에는 그리드의 필터 평가 타이밍 문제로 가설을 세우고, 그리드 초기화 로직에 재시도 메커니즘을 추가하려 했으나, 사용자 테스트 결과 효과가 없어 이를 되돌림
- 실제 원인을 찾기 위해 브라우저 콘솔에 디버그 로그를 추가해 사용자의 재현 환경에서 실행 흐름을 수집함
- 수집된 로그를 분석한 결과, 필터는 정상적으로 평가되고 있었으나 캘린더가 복사한 데이터 자체가 0건인 상태(행 개수가 0)였음을 확인
- 원인 분석: 캘린더가 같은 페이지의 그리드 데이터를 스냅샷으로 복사하는 시점과 원본 그리드의 데이터 로드 완료 시점 사이에 race condition이 있었음. 캘린더가 원본 그리드의 데이터 로드 이벤트를 구독하지 않아서, 원본이 데이터 로드를 마치기 전에 빈 상태의 데이터를 먼저 복사하고 있었음
- 데이터 로드 완료 이벤트의 대칭성 확인: 다른 이벤트(저장 완료 이벤트)는 캘린더와 원본 그리드 모두에서 구독되고 있었으나, 데이터 로드 이벤트는 캘린더 쪽에만 일방적으로 구독되어 있었음을 확인
- 원본 그리드의 데이터 로드 이벤트를 캘린더가 구독하도록 추가하고, 캘린더 언마운트 시 구독을 해제하도록 처리
- 원본이 다른 그리드인 경우, 먼저 데이터를 동기화한 뒤 일정을 생성하는 순서로 변경
- 필터 연동 시나리오를 테스트하는 E2E 테스트를 작성. 그리드의 날짜 컬럼에서 데이터를 동적으로 읽어와 캘린더를 해당 월로 이동시킨 뒤, 일정이 올바르게 표시되는지 검증
Result (결과)
- 캘린더 필터 연동 버그가 근본 원인부터 해결됨 — 이제 필터가 적용된 상태에서도 캘린더가 올바른 데이터를 표시함
- 원본 그리드와의 이벤트 대칭성 문제가 제거됨
- 동일한 버그의 재발을 방지하는 E2E 테스트가 추가됨
- 빌드 검증 통과(npm run build:test)
실제 측정 가능한 지표
| 지표 | 확인 방법 | 비고 |
|---|---|---|
| 추가된 이벤트 구독 위치 | 코드에서 데이터 로드 이벤트 리스너 추가 개소 확인 | 캘린더 마운트/언마운트 위치에서 확인 가능 |
| Cypress 테스트 케이스 | 필터 연동 시나리오 검증 테스트 구성 확인 | 원본 필터 + 다이나믹 필터 + 캘린더 구성 |
| 디버그 로그의 정보량 | 추가된 브라우저 콘솔 로그의 라인 수 | 실행 흐름 추적을 위한 최소한의 로그만 유지 |
| 초기 가설 검증 | 필터 평가 재시도 로직의 추가/제거 여부 | 틀린 가설은 되돌림 |
| 이벤트 구독 대칭성 | 저장 완료/데이터 로드 이벤트 구독 위치 비교 | 이제 모두 일관되게 구독되는지 확인 |
추정 가능한 효과 (근거 포함)
- 이벤트 구독 대칭성으로 타이밍 버그 방지 (추정): 캘린더와 원본 그리드 사이의 이벤트 구독이 대칭적으로 설정되면서, 향후 데이터 로드 순서가 바뀌어도 일관되게 동기화될 것으로 예상됨. 근거: 데이터 로드 이벤트가 양쪽에서 모두 구독되는 구조로 변경된 것을 확인함
- E2E 테스트 추가로 회귀 방지 (추정): 필터 연동 시나리오에 대한 E2E 테스트가 추가되면서, 유사한 버그가 재발할 가능성이 감소할 것으로 예상됨. 근거: 원본 필터 + 다이나믹 필터 + 캘린더라는 복합 시나리오를 자동화 테스트로 검증하는 구조가 마련됨
더 측정하면 좋은 지표
- 비동기 race condition 감지 메커니즘: 향후 유사한 타이밍 문제를 더 빨리 감지하기 위해, 이벤트 대칭성을 자동으로 검사하는 린트 규칙이나 테스트가 가능한지 검토
- 디버그 로그의 성능 영향: 추가된 콘솔 로그가 실제 성능에 미치는 영향 측정 (간단한 타이밍 측정 가능)
- 필터 연동 시나리오의 엣지 케이스: 여러 그리드가 연쇄적으로 연동될 때, 캘린더와 최상위 원본 그리드 외의 중간 그리드들과의 데이터 동기화 정확성 확인
- 이벤트 대칭성 원칙의 다른 곳 적용: 캘린더 외의 다른 컴포넌트에서도 같은 패턴의 구독 비대칭이 있는지 전수 조사
오늘 배운 것
- 초기 가설이 틀렸을 때 재빨리 인식하고 방향을 바꿀 수 있는 능력이 디버깅에서 가장 중요하다는 것을 다시 확인함. 예상대로 효과가 없으면 그 즉시 가설을 되돌리고 실제 데이터(로그)를 보는 것이 훨씬 효율적임
- 비동기 데이터 로딩 관련 타이밍 버그는 이벤트 구독의 “대칭성”으로 감지할 수 있다는 것을 배움. 같은 종류의 이벤트에 대해 여러 컴포넌트가 구독하고 있다면, 모두 동일한 이벤트를 구독하고 있는지 확인하는 것이 중요함
- 복잡한 초기화 로직을 이해할 때는 “인과 맵”(시간 순서대로 정렬한 이벤트와 호출 순서)을 만들면, 엉킨 흐름이 한눈에 정리된다는 것을 실감함
- 사용자와 직접 협업하며 로그를 수집하고 분석하는 과정이 문제 해결에 얼마나 큰 도움이 되는지 확인함. 예상 기반 수정보다 실제 데이터 기반 수정이 훨씬 정확하고 빠름
어려웠던 점 / 막힌 부분
- 처음에 필터 평가 타이밍 문제로 잘못 판단해서 그 방향으로 코드를 수정했으나, 사용자 테스트에서 효과가 없었고 이를 되돌려야 했음. 가설 검증 없이 코드부터 수정한 것이 비효율적이었음
- 원본 필터와 다이나믹 필터라는 개념이 처음에는 명확하지 않았으나, 사용자와 대화하며 재확인함으로써 이해할 수 있었음
- E2E 테스트 작성 중 캘린더가 기본적으로 “오늘”을 기준으로 열려서, 실제 테스트 데이터가 다른 월에 있을 때 테스트가 실패하는 문제가 있었음. 그리드 데이터에서 날짜를 동적으로 읽어와 캘린더를 이동시키는 방식으로 해결했는데, 이 과정에서 Cypress 코드를 여러 번 수정해야 했음
내일 하면 좋은 작업
- hotfix 브랜치 커밋 및 코드 리뷰 대비
- 진행 중인 다른 브랜치들(hotfix 포함) 상태 확인
- 이벤트 대칭성 원칙이 다른 컴포넌트에도 적용되어 있는지 감사
한 줄 요약
초기 가설이 틀렸을 때 실제 로그로 재검증해야 근본 원인을 찾을 수 있다는 것을 배웠고, 비동기 타이밍 문제는 이벤트 대칭성 부족으로 감지할 수 있다는 깨달음을 얻은 하루였다.
댓글남기기