급여·퇴직금·실업급여 계산기 UI 전면 시각 통일

한 번에 여러 페이지를 뜯어고쳤다. 단순 색상 수정이 아니라 hero 영역, FAQ 애니메이션, 도구 카드, 결과 카드까지 — 사실상 전체 UI 레이어를 다시 짠 것에 가깝다.

왜 이 타이밍에 스타일을 "대폭" 손댔나

기능 개발 사이클이 어느 정도 안착하면 반드시 이 시점이 온다. 데이터는 잘 나오는데 화면이 못 생겼거나, 정보 구조는 맞는데 사용자가 어디를 봐야 할지 모르는 상태. salary / severance / unemployment 세 페이지가 각각 독립적으로 자라다 보니 디자인 일관성이 조금씩 어긋나 있었다. Layout.astro까지 같이 건드렸다는 건 공통 레이아웃 수준의 변경도 포함됐다는 뜻이다. 보통 이런 작업은 "디자인 빚(design debt)" 해소라고 부른다.

팀에서 스타일 작업을 미루는 이유는 대부분 두 가지다. 우선순위 뒤로 밀리거나, 범위가 너무 커서 엄두를 못 내거나. 근데 묵혀두면 묵혀둘수록 나중에 건드릴 때 연쇄 영향이 커진다. 이번처럼 한 번에 몰아서 정리하는 게 오히려 나은 경우도 있다. 다만 커밋 단위가 크기 때문에 리뷰어 입장에서는 힘들다 — 이건 아래에서 따로 얘기하겠다.

변경 범위 정리

세 계산기 페이지(salary / severance / unemployment)가 동일한 도구 카드 + 결과 카드 패턴을 공유하게 된 게 이번 작업의 핵심이다. 즉 기능 수정이 아니라 시각적 일관성을 확보한 것.

Hero / FAQ animation / 카드 디자인 — 각각 왜 중요한가

Hero 영역은 첫인상이다. 사용자가 "이 서비스가 뭘 하는 곳인지" 3초 안에 판단하는 공간. 텍스트 계층(타이포 크기, 굵기), 배경 처리, CTA 버튼 배치 하나가 이탈률에 직결된다. 뭘 어떻게 바꿨는지는 커밋 diff에 있지만, 손을 댔다는 것 자체가 "기존 hero가 역할을 못 하고 있었다"는 판단이 내려진 것.

FAQ 애니메이션은 체감 품질 영역이다. 아코디언 열고 닫힐 때 애니메이션이 없으면 화면이 툭툭 튀는 느낌이 난다. CSS transition이나 max-height 트릭 하나 차이인데 완성도 인상이 꽤 달라진다.

/* FAQ 아코디언 — 애니메이션 없는 경우 */
.faq-body {
  display: none;
}
.faq-body.open {
  display: block;
}

/* 부드러운 전환 적용 예시 */
.faq-body {
  max-height: 0;
  overflow: hidden;
  transition: max-height 0.3s ease, opacity 0.3s ease;
  opacity: 0;
}
.faq-body.open {
  max-height: 500px;
  opacity: 1;
}

display: none → block 전환은 CSS만으로 애니메이션을 걸 수가 없다. max-height 우회 패턴이 가장 흔하게 쓰이는 이유다. 콘텐츠 길이가 가변이면 max-height 값 설정이 까다롭긴 하지만, 작은 트레이드오프다.

도구 카드 / 결과 카드는 입력 → 출력 플로우의 핵심 UI다. 계산기 서비스 특성상 "입력하고 → 결과 확인하는" 흐름이 명확해야 한다. 카드 구분이 약하면 사용자가 어디에 값 입력하고, 어디서 결과를 보는지 혼란스럽다. 시각적 분리(그림자, 배경색 차이, 보더 처리)가 UX 가이드 역할을 한다.

이런 작업 리뷰할 때 주의할 점

스타일 대규모 변경은 코드 리뷰가 어렵다. diff가 수백 줄 넘어가면 리뷰어 눈이 피로해지고, 실제 문제(반응형 깨짐, 특정 브라우저 렌더링 이슈)는 코드로 안 잡힌다. 이런 커밋일수록:

• 스크린샷 비교(before/after)를 PR에 첨부하는 게 효과적
• 브라우저 여러 개(Chrome / Safari / Firefox) + 모바일 뷰 체크
• 공통 Layout 변경은 전체 페이지 회귀 테스트 필요 — Layout.astro 건드리면 index 말고 다른 페이지도 영향받는다

Layout.astro 같은 공통 파일은 항상 "이 파일 바꾸면 어디까지 영향가나"를 먼저 그려보고 들어가는 습관이 필요하다. 실제로 작업하다 보면 공통 파일에 페이지별 예외 처리가 슬금슬금 들어가는 일이 생기는데, 그게 쌓이면 나중에 진짜 골치 아파진다.

style 커밋이라 기능 변경 없이 끝났지만, 이런 작업의 의사결정 — "지금 이걸 해야 하나, 나중에 해야 하나" — 이게 더 어렵다. 이번엔 해소하는 방향으로 판단했고, 결과적으로 세 계산기 페이지가 동일한 시각 언어를 쓰게 됐다는 게 작업의 실질적인 성과다.

끝.

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

• 기계식키보드 쿠팡에서 보기 →
• 모니터 쿠팡에서 보기 →
• 사무의자 쿠팡에서 보기 →

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