홈 비교 화면 완전히 다시 만든 이유

보험 홈의 비교 보드를 거의 처음부터 다시 설계했다. 단순히 색깔을 바꾸거나 레이아웃을 약간 조정하는 수준이 아니었다. 메트릭 아이콘을 SVG로 마이그레이션하면서, 함께 컴포넌트 구조를 정리하고 스타일 시스템을 개선하는 대규모 작업이었다.

리디자인 전, 무엇이 불편했나?

처음 이 작업을 시작했을 때 느낀 점은 기존 비교 보드가 여러 방식으로 불완전했다는 것. 메트릭 아이콘이 정적 이미지 파일(PNG, JPG 등)로 관리되고 있었는데, 이는 몇 가지 문제를 안고 있었다. 먼저 성능 관점에서는 각 아이콘이 별도의 HTTP 요청을 필요로 했고, 스타일 커스터마이징이 불가능했다. 다크모드 같은 테마 전환이 필요할 때마다 별도의 이미지 세트를 관리해야 했고, 나중에 색상이나 크기를 바꾸려면 이미지 파일 자체를 재생성해야 했다. 코드 관점에서도 PostMetrics 컴포넌트가 정적 이미지 경로에 강하게 의존하고 있어서, 변경에 유연하지 못했다.

홈 페이지(index.astro)의 비교 보드 자체도 여러 레이아웃과 스타일이 산재되어 있었다. 기본 레이아웃(Base.astro)에는 공통 스타일이, 페이지 수준에서는 비교 보드 특화 스타일이, 그리고 전역 스타일(styles.css)에도 부분적인 스타일이 흩어져 있었다. 이런 구조는 나중에 보드를 개편할 때 수정점을 놓치기 쉽고, 일관성을 유지하기 어렵게 만들었다.

SVG 마이그레이션, 단순 기술 업그레이드가 아니라 설계 개선

이 작업의 핵심은 메트릭 아이콘을 SVG로 변경하는 것이었다. SVG는 단순히 "더 나은 형식"이 아니라, 이를 기점으로 전체 시스템을 재구성할 수 있는 기회였다.

SVG 도입으로 얻은 이점들:

• 스케일: 화면 크기에 상관없이 선명하게 표시, 별도 반응형 이미지 세트 불필요
• 성능: 개별 HTTP 요청 감소, 번들에 포함되면 지연 로딩 불필요
• 동적 스타일링: CSS와 직접 통합, 색상·크기·애니메이션을 런타임에 제어 가능
• 접근성: SVG에 aria-label 등 구조화된 마크업 추가 가능
• 유지보수: 디자인 변경이 단순 파일/코드 수정, 버전관리 용이

PostMetrics 컴포넌트를 수정할 때는, 아이콘 데이터를 인라인 SVG로 정의할지 외부 파일로 분리할지를 고민했다. 최종적으로는 컴포넌트 자체에 SVG 마크업을 포함시키는 방식을 택했다. 이렇게 하면 컴포넌트가 자체적으로 완결되고, Props로 아이콘 타입을 받아 동적 렌더링도 가능해진다. 나중에 다른 페이지에서도 쉽게 재사용할 수 있다는 게 큰 이득이었다.

파일 구조 개선, 설계 의도를 코드에 담다

이번 리디자인에서 수정한 파일들의 역할을 정리해보니 다음과 같다:

가장 중요한 변경은 스타일을 한곳으로 수렴시키는 것이었다. 이전에는 페이지, 레이아웃, 전역 스타일이 각각 비교 보드에 대한 부분적인 정의를 가지고 있었다. 이번 리디자인에서는 전역 스타일(styles.css)을 중심으로 통합하되, 컴포넌트 레벨의 스타일(PostMetrics.astro 내의 <style> 블록)은 그 컴포넌트만 필요한 것들로 최소화했다. 이렇게 하면 팀의 다른 개발자도 "비교 보드 스타일을 변경하려면 styles.css를 봐"라고 명확히 알 수 있다.

회고: 이런 규모의 리디자인을 진행하며 배운 점들

1. 점진적 개선 vs 대규모 재구성의 선택

처음에는 "SVG 아이콘만 바꾸면 되지 않을까" 생각했다. 하지만 작업 초반 설계 검토에서 팀과 함께 "이 김에 주변의 레이아웃, 스타일링, 컴포넌트 구조도 개선하면 어떨까"라는 의견을 나눴다. 결과적으로 한 번의 큰 작업으로 여러 개선사항을 동시에 적용할 수 있었다. 대신 PR 리뷰가 길어졌고, 테스트 커버리지도 함께 검토해야 했다. 다음에는 변경 범위를 미리 명확히 정의하고, 필요하면 단계적 롤아웃 계획을 세워야겠다는 생각이 들었다.

2. 컴포넌트 경계의 중요성

이전에는 PostMetrics가 단순한 "메트릭 표시 컴포넌트"였다. 이번 리디자인에서는 그 책임을 명확히 재정의했다: "메트릭 데이터를 SVG 아이콘과 함께 시각화한다. Props로 유연한 커스터마이징을 지원한다." 이렇게 경계를 명확히 하니, 나중에 컴포넌트를 재사용하거나 수정할 때 의도가 분명해졌다. 코드 리뷰도 수월했다.

3. 스타일 시스템은 "단일 출처"여야 한다

Astro와 같은 컴포넌트 기반 프레임워크에서는 각 컴포넌트에 <style> 블록을 두고 싶은 유혹이 크다. 하지만 이번 작업을 통해 느낀 건, 단일 도메인(예: 비교 보드)의 공유 스타일은 가능하면 한곳에 모아야 한다는 것. styles.css를 "비교 보드 스타일의 단일 출처"로 삼으면, 변경 영향도를 예측하기 쉽고, 일관성을 유지하기 간단해진다.

결국 이 리디자인은 기술 개선만이 아니라, 팀의 설계 원칙과 코드 리딩 경험을 함께 개선하는 과정이었다.

🛒 이 글과 어울리는 추천 상품

• 모니터 쿠팡에서 보기 →
• 기계식키보드 쿠팡에서 보기 →
• 외장SSD 쿠팡에서 보기 →

*위 링크는 쿠팡파트너스 활동의 일환이며, 일정액의 수수료를 제공받을 수 있습니다.