헤더 KPI 칩 제거하고 검색바 확장해 가독성 개선
목차
헤더에 KPI 칩이 붙은 구조를 쭉 써왔는데, 어느 순간부터 화면이 산만하다는 느낌이 쌓이기 시작했다. 숫자가 작은 칩 안에 들어가 있으면 "있다"는 느낌은 나지만 실제로 읽히지 않는다. 시선이 한 곳에 머물지 못하고 헤더 영역에서 분산되는 현상이었음. 결국 헤더는 아이덴티티(로고, 네비게이션)만 담고, 수치를 봐야 하는 사람은 해당 섹션에서 보도록 분리하는 방향을 택했다.
검색바 확장은 그 연장선이다. KPI 칩이 차지하던 공간을 치우고 나니 검색 입력창이 더 넓어질 여지가 생겼다. 검색바가 좁으면 쿼리 텍스트가 잘려서 "내가 뭘 치고 있는지" 확인이 어렵고, 특히 필터가 붙는 복합 검색이라면 UX 손실이 꽤 크다. 넓힌다고 기능이 늘어나는 건 아니지만, 체감 편의성 차이는 생각보다 컸다.
KPI를 헤더에서 빼야 했던 이유
헤더 KPI 칩이 생긴 배경은 보통 비슷하다. "한눈에 보고 싶다"는 요구가 처음에 들어오고, 빠르게 붙이기 가장 쉬운 자리가 헤더라서 거기 꽂힌다. 초기엔 나쁘지 않다. 칩 두세 개, 숫자 간단, 배경색으로 상태 구분. 그런데 시간이 지나면서 요구가 쌓인다. 칩이 네 개, 다섯 개가 되거나, 각 칩에 단위·툴팁·색상 로직이 붙는다. 그 시점부터 헤더는 더 이상 "빠른 맥락 파악" 영역이 아니라 "해석이 필요한 데이터 구역"이 된다.
이번에 제거한 것도 이 경로를 걷고 있었다. 헤더 칩이 늘어나면서 레이아웃 정렬이 틀어졌고, 모바일에서는 줄 바꿈이 생겼다. 반응형 분기 처리 코드가 헤더 컴포넌트 안에 조용히 쌓여 있었다.
칩을 제거하고 나서 헤더 마크업이 확연히 단순해졌다. 아이덴티티 영역과 검색바, 사용자 메뉴만 남았다. 반응형 처리도 훨씬 단순해짐.
스타일 작업 실제 흐름
변경한 파일은 뷰/스타일 쪽 세 개였다. CSS specificity 문제가 이번에도 예상대로 걸렸다.
칩 스타일이 !important를 한 군데 쓰고 있었는데, 그 여파로 인접한 검색바 너비 계산이 제대로 반영되지 않았다. !important는 찾아서 제거하는 게 원칙이지만, 제거하면 연쇄적으로 다른 선택자의 specificity를 올려야 할 수 있어서 범위를 먼저 확인했다.
/* 전: !important로 고정 */
.header-chip {
max-width: 120px !important;
}
/* 후: 부모 컨텍스트로 specificity 확보 */
.header-identity .header-chip {
max-width: 120px;
}
이렇게 부모 선택자로 specificity를 올리면 전역 오염 없이 범위를 한정할 수 있다. 변수(--search-bar-max-width 같은)도 이번 기회에 정의해 뒀다. 나중에 검색바 너비를 다시 조정해야 할 때 변경 지점이 하나라서 관리가 편하다.
반응형 처리는 아래 방식으로 정리했다.
| 해상도 | 검색바 너비 | 헤더 동작 |
|---|---|---|
| 모바일 (~767px) | 100% (펼침) | 햄버거로 대체 |
| 태블릿 (768~1023px) | 40% | 아이콘만 표시 |
| 데스크톱 (1024px~) | 480px 고정 | 풀 레이아웃 |
브레이크포인트를 변수로 빼두면 나중에 숫자 하나 바꿀 때 여기저기 찾아다니지 않아도 된다. SCSS 환경이라면 @mixin respond-to($bp) 패턴으로 묶어두는 게 편하고, 바닐라 CSS라도 @custom-media나 변수 조합으로 어느 정도 가능하다.
작업 후기 - 작은 변경인데 왜 이게 중요한가
화면에서 요소 하나를 지우는 작업이 단순해 보여도, 그게 데이터를 표시하던 요소였다면 이야기가 달라진다. 칩이 보여주던 수치가 어디서 왔는지, 제거 후 그 데이터를 접근할 다른 경로가 있는지, 권한에 따라 보이고 안 보이는 처리가 있었는지까지 확인했다. 사용자가 "칩이 있을 거라고 생각하고 쓰던" 워크플로우가 있으면 제거 후에 민원이 생길 수 있어서, 접근 경로가 있는지 먼저 확인하는 게 순서다.
이번엔 칩이 제공하던 수치가 다른 뷰에서 더 풍부하게 제공되고 있었고, 헤더 칩은 중복이었다. 그러니까 제거가 맞았음.
변경 전에 현재 동작 상태를 스크린샷으로 찍어두는 습관이 이런 작업에서 특히 유효하다. "원래 어떻게 생겼었는지"를 기억에 의존하면 리뷰 때 비교가 어렵고, 배포 후 문의가 들어왔을 때 "이전 상태"를 빠르게 보여주기 어렵다. 변경 후 같은 케이스로 확인하고, 커밋은 "칩 제거"와 "검색바 확장"을 분리했다. 두 작업이 논리적으로 독립적이라서, 하나가 문제가 생겨도 다른 커밋은 살아남을 수 있도록.
CSS 작업이 특히 그런데, "대충 맞는 것 같다"로 넘어간 specificity 충돌이나 !important 하나가 한참 뒤에 예상 못한 레이아웃 버그로 돌아온다. 지금 찾아서 정리해두는 비용이 나중에 뒤지는 비용보다 항상 싸다.
댓글 0
첫 댓글 달아줘.