디자인 개편과 함께 발견된 데이터 버그들
목차
에디토리얼 디자인을 전면 개편하면서 버그 2건을 함께 수정했다. 공통 레이아웃을 건드리는 작업이 얼마나 큰 파급을 일으키는지, 그 과정에서 어떤 일들이 벌어지는지 정리해본다.
디자인 개편의 영향 범위
변경 파일 목록을 보면 흥미로운 구조가 드러난다. Base.astro(공통 레이아웃)를 중심으로 pages/albums/[slug].astro, pages/groups/[slug].astro, pages/index.astro, pages/members/[slug].astro 5개 페이지가 함께 수정되었고, src/lib/db.ts도 함께 손댔다.
| 역할 | 파일 | 영향 |
|---|---|---|
| 공통 레이아웃 | Base.astro | 모든 페이지에 cascade됨 |
| 콘텐츠 페이지 | albums, groups, members, index | Base 변경에 맞춰 조정 필요 |
| 데이터 계층 | db.ts | 버그 2건 포함 |
Astro에서 Base 레이아웃은 기초가 되는 컴포넌트다. 헤더, 네비게이션, 푸터 같은 전역 UI가 자리 잡는다. 여기를 손대면 필연적으로 각 페이지도 따라가야 한다. 단순 스타일 변경이 아니라 구조 자체가 바뀌면, 개별 페이지들도 새로운 레이아웃에 맞춰서 재정렬하고 조정해야 한다.
설계 개편 중에 버그가 드러난 이유
눈여겨볼 부분이 db.ts의 등장이다. 데이터 접근 계층이 디자인 개편과 함께 수정되었다는 건 UI만 손댄 게 아니라, 데이터 흐름 자체를 재검토했다는 뜻이다.
이런 상황은 대규모 레이아웃 작업에서 자주 일어난다:
- 새로운 구조에서 기존 데이터를 어떻게 배치할지 검토하며 데이터 모양 재확인
- 페이지를 다시 렌더링하면서 "어? 이 데이터 처리 로직 왜 이렇게 되어 있지?" 같은 발견
- API 응답 형식이 새 UI에 정말 맞는지 테스트하다가 모서리 케이스 발견
- 필터링이나 정렬 로직을 다시 들여다보면서 버그 노출
기존 UI에서는 숨겨져 있던 데이터 처리 오류들이, 큰 구조 변화의 과정에서 수면 위로 떠오르는 거다. 이번에 발견된 버그 2건도 아마도 이런 식으로 나타났을 것 같다. 대규모 개편은 코드베이스 전체를 다시 보는 기회가 되고, 그 과정에서 기술 부채들이 자연스럽게 드러난다.
Feature와 Bugfix를 함께 커밋하는 것의 트레이드오프
이 커밋을 보면서 고민해봐야 할 지점이 있다.
함께 커밋의 장점:
- 관련 작업들을 논리적으로 묶을 수 있다. 디자인 개편 작업 속에서 발견하고 바로 고친 버그니까.
- 히스토리가 더 명확해진다. 이 커밋을 보면 "디자인 개편에 버그 수정도 포함"이라고 한눈에 알 수 있다.
- 테스트와 QA를 한 번에 끝낼 수 있다.
함께 커밋의 단점:
- 코드리뷰가 복잡해진다. UI 변경과 데이터 로직 수정을 분리해서 봐야 하니까.
- 롤백이 필요할 때 문제다. Feature는 유지하고 싶은데 버그 수정 중 하나만 문제 있으면, 전체를 되돌리기 어렵다.
- 나중에 git blame으로 추적할 때 "이 라인을 왜 바꿨지?"라는 질문에 대한 답이 모호해진다. 디자인 때문인지 버그 수정 때문인지.
일반적으로는 feature와 bugfix를 분리하는 게 권장된다. 따로 커밋하면 각각의 변경 의도가 명확해지고, 필요시 선택적 롤백도 가능하다. 다만 이 두 작업이 밀접하게 얽혀 있다면(예: "새 레이아웃에서만 발생하는 버그"), 함께 커밋해도 문제없다. 중요한 건 커밋 메시지에 그 관계를 명확히 써주는 것.
다중 페이지 개편에서 자주 놓치는 것들
여러 페이지를 한 번에 개편할 때, 경험상 자주 빠지는 부분들이 있다:
- 일관성 검증: 5개 페이지가 모두 새 레이아웃을 제대로 적용했는지. 한두 페이지는 꼼꼼히 봤는데 나머지는 스킵하는 경우가 생긴다.
- 전체 사용자 경험: 홈에서 상세 페이지까지 흐르는 네비게이션이 자연스러운지. 각 페이지 간 시각적 일관성이 있는지.
- 성능: Base 레이아웃 변경이 번들 크기를 키웠는지, 렌더링 성능에 영향이 없는지.
- 기존 데이터: 과거 데이터들이 새 레이아웃에서도 제대로 표시되는지.
이번 작업에서 버그 2건을 발견한 걸 보면, 여러 페이지를 다 돌면서 충분히 체크했다는 신호다. 물론 그 과정이 버그를 찾아낸 거니까, 결과적으로는 좋은 QA였던 셈이다.
다음 번을 위해
큰 규모의 디자인 개편은 단순한 스타일 변경이 아니다. 레이아웃이 바뀌면 데이터 흐름도, 렌더 구조도, 성능 특성도 함께 변한다. 버그들이 함께 나오는 건 자연스러운 일이고, 그만큼 철저한 검토가 필요하다는 뜻이기도 하다.
다음 번 유사한 작업을 할 때는, feature와 bugfix를 명확히 분리하고, 각 파트마다 독립적인 테스트와 리뷰 사이클을 갖는 게 좋다. 특히 여러 페이지에 걸친 개편이라면 더욱.
🛒 이 글과 어울리는 추천 상품
*위 링크는 쿠팡파트너스 활동의 일환이며, 일정액의 수수료를 제공받을 수 있습니다.
댓글 0
첫 댓글 달아줘.