2026-07-11 · DEVELOPMENT RECORD
UI를 고치다 드러난 CSS와 장애 처리 부채
헤더 간격을 줄인 수정이 메뉴판과 설정 화면까지 건드렸다. CSS의 책임을 나누는 동안 메뉴 요청이 실패했을 때 열리는 임시 화면도 함께 정리했다.
화면 정리와 장애 대응의 접점
7월 초에는 CSS를 정리하고 사용하지 않는 화면을 걷어 내면서 네트워크 실패 처리도 손봤다. 화면 구조를 바꾸는 동안 캐시나 임시 메뉴를 보여 주는 경로가 빠지지 않도록 함께 점검했다.
작은 UI 수정이 큰 회귀를 만들었다
헤더, 퀵픽, 메뉴판, 필터, 추천 카드의 크기를 조정하는 커밋이 이어졌다. 단일 CSS 파일에 규칙이 모여 있으면 한 영역의 여백을 줄이는 일이 다른 화면의 배치를 바꾸기 쉬웠다.
동시에 앱 내부 개발 로그와 레거시 메뉴판은 실제 사용자 흐름에서 더 이상 역할이 없었다. 유지하지 않을 화면을 남기는 것도 회귀 범위를 넓히는 원인이 됐다.
- UI 작업
- 헤더·필터·추천 카드·메뉴판
- 구조 작업
- CSS 역할별 모듈화
- fallback
- 메뉴·메뉴판·지도 검색
시각 규칙과 장애 경로를 각각 분리했다
CSS를 셸, 메인, 보조 화면 등 역할별 모듈로 나누고 공통 패널 토큰을 만들었다. UI 구조 맵을 문서로 두어 다음 변경에서 컴포넌트와 selector를 다시 추측하지 않게 했다.
카탈로그가 준비됐는데 메뉴판 요청만 실패하는 경우에는 인기 메뉴 fallback을 제공하고, 지도는 별도 검색 경로를 열도록 했다. 모든 실패를 같은 오류 화면으로 모으지 않은 이유는 사용자가 할 수 있는 다음 행동이 다르기 때문이다.
컴포넌트 분리와 실패 화면을 같은 회귀표에 올렸다
오프닝과 설정 패널을 컴포넌트로 분리하고, 레거시 메뉴판과 개발 로그 화면을 제거했다. 메뉴 설명과 필터 값도 다시 점검해 화면 문구와 데이터가 어긋난 항목을 수정했다.
작은 화면의 카드 줄바꿈, 설정 패널 상호작용, 메뉴판 fallback, 지도 URL, 키보드 포커스를 확인했다. CSS 분리는 겉모습이 같은지뿐 아니라 이후 수정이 어느 파일에 영향을 주는지 확인하는 검증이 필요했다.
fallback은 정상 데이터의 대체물이 아니다
인기 메뉴 fallback은 서비스가 완전히 멈추는 일을 줄이지만, 사용자가 고른 모든 조건을 재현하지는 못한다. 따라서 fallback을 정상 추천처럼 보이게 하기보다 임시 상태임을 알려야 한다.
시각 조정 역시 자동 테스트만으로 충분하지 않다. 이후에는 반응형 폭과 접근성 검사를 더 체계적으로 묶어 브라우저 회귀를 확인하게 됐다.
fallback을 다룰 때의 주의점
메뉴판을 수정하면 정상 응답, 캐시, 임시 메뉴를 각각 열어 봐야 했다. 같은 카드라도 데이터가 들어오는 경로가 달라 지도 링크나 다음 화면 이동이 한쪽에서만 깨질 수 있었다.
인기 메뉴를 임시로 보여 줄 때는 입력한 필터가 반영되지 않는다. 화면에 임시 상태와 재시도를 남긴 이유다. 이후 반응형·키보드 검사에도 이 상태들을 포함했다.