개발 slecs

헤더 파트너 정보 칩 비주얼 개선

목차

헤더 파트너 정보 영역을 오랫동안 미뤄두다가 이번에 드디어 손을 댔다. 기능은 이미 완성된 상태였고 데이터도 잘 들어오고 있었지만, 화면을 볼 때마다 뭔가 어색한 느낌이 있었음. 정보가 있는데 눈에 안 들어오는 상태랄까. 칩/뱃지 형태로 파트너 정보를 보여주는 구조였는데, 레이아웃 정렬이 들쭉날쭉하고 아이콘 크기도 주변 텍스트와 비율이 안 맞았다.

결국 "보기 싫다"는 인상 자체가 사용자 경험에 영향을 주니까, 기능 완성 = 화면 완성이 아니라는 거다.

어떤 부분을 바꿨는가

크게 네 가지.

헤더 레이아웃 정렬: 파트너 정보 칩이 헤더 내 다른 요소들과 수직 정렬이 안 맞아 있었음. align-items를 명확히 잡고 flex 컨테이너 기준을 통일했다.

칩/뱃지 비주얼: 기존 칩은 패딩이 너무 좁고 border-radius도 애매했음. 사이즈를 약간 키우면서 여백을 다시 잡았더니 훨씬 읽기 편해졌다. 폰트 사이즈도 보조 정보는 작게, 핵심 수치는 크고 굵게 분리했음.

아이콘 위치 및 크기: 아이콘이 텍스트보다 약간 큰 상태였는데 line-height 기준으로 정렬이 안 돼 있어 시각적으로 떠 있는 것처럼 보였다. vertical-align: middle 단독으로는 한계가 있어서 flex 기반으로 아이콘-텍스트 쌍을 감싸는 방식으로 바꿨음.

반응형 처리: 모바일에서는 칩을 축약하거나 줄바꿈이 허용되도록 조건을 추가했음. 태블릿 이상에서는 인라인 유지.

변경 파일은 뷰 파일, 스타일 파일 등 세 파일. 기능 코드는 건드리지 않고 스타일 레이어만 수정한 케이스라 사이드이펙트 위험은 낮았지만, 연관된 화면은 모두 눈으로 확인했다.

CSS specificity 얘기를 안 할 수 없음. 예전에 작업된 스타일 중에 !important가 섞여 있었는데, 이걸 그냥 두고 위에 덮어쓰면 결국 나도 !important를 써야 하는 상황이 생긴다. 이번엔 기존 !important를 걷어내고 specificity를 올리는 방향으로 재작성했음.

/* 이전: !important에 의존 */
.partner-chip {
  padding: 4px 8px !important;
  font-size: 12px !important;
}

/* 이후: 상위 컨텍스트 클래스로 specificity 확보 */
.header-area .partner-chip {
  padding: 6px 12px;
  font-size: 13px;
  border-radius: 20px;
}

이런 식으로 정리하면 나중에 테마 변경이나 다크모드 대응할 때도 CSS 변수로 깔끔하게 처리가 된다.

:root {
  --chip-bg: #f0f4ff;
  --chip-text: #3b4bdb;
  --chip-radius: 20px;
  --chip-padding-v: 6px;
  --chip-padding-h: 12px;
}

.header-area .partner-chip {
  background-color: var(--chip-bg);
  color: var(--chip-text);
  border-radius: var(--chip-radius);
  padding: var(--chip-padding-v) var(--chip-padding-h);
}

SCSS를 쓰는 프로젝트라면 반응형 브레이크포인트 mixin으로 관리하는 게 중복을 많이 줄여줌. 브레이크포인트 값을 여러 곳에 하드코딩해두면 나중에 수치 하나 바꿀 때 전부 다 찾아야 하는데, mixin 하나로 빼두면 그런 일이 없다.

@mixin respond-to($breakpoint) {
  @if $breakpoint == 'mobile' {
    @media (max-width: 767px) { @content; }
  } @else if $breakpoint == 'tablet' {
    @media (min-width: 768px) and (max-width: 1199px) { @content; }
  } @else if $breakpoint == 'desktop' {
    @media (min-width: 1200px) { @content; }
  }
}

.partner-chip {
  display: inline-flex;
  align-items: center;
  gap: 4px;

  @include respond-to('mobile') {
    font-size: 11px;
    padding: 4px 8px;
  }
}

디자인 원칙이라고 거창하게 써놨지만

실제로는 작업할 때마다 의식적으로 확인하는 체크리스트임.

항목 확인 기준
일관성 색상·폰트·여백이 다른 화면의 동일 컴포넌트와 맞는가
가독성 핵심 수치는 강조, 보조 정보는 한 단계 낮게 처리했는가
반응형 모바일·태블릿·데스크톱 세 해상도에서 깨지는 곳 없는가
대비 텍스트-배경 대비가 WCAG AA 기준(4.5:1) 이상인가

대비는 특히 신경 씀. 브랜드 색상을 쓰다 보면 은근히 대비 비율이 빠듯한 경우가 있다. WebAIM Contrast Checker 같은 툴로 한 번씩 확인하는 게 습관이 돼야 함. 통과 못 하면 그냥 진한 계열로 조금 내리면 되는데, 어렵지 않은데 빠뜨리기 쉬운 부분이라 의식적으로 챙기게 됨.

스타일 작업도 기능 작업이다

사내 서비스를 만들다 보면 기능 하나가 단순히 화면에 버튼 하나 추가하는 것으로 끝나지 않는다는 걸 계속 체감함. SQL 집계, 상태 머신, 예외 처리, 화면 렌더링, 권한 체크가 모두 엮여 있어서 어느 하나만 빠뜨려도 숫자가 맞지 않거나 특정 사용자에게 이상한 화면이 나타남.

스타일 작업도 마찬가지다. 그냥 색이나 여백 조절이라고 가볍게 보면, 반응형 깨짐이나 대비 문제가 나중에 보고됨. 특히 금융/결제 도메인은 UI가 신뢰의 일부임. 숫자가 제대로 읽히지 않거나 정보가 뭉개져 보이면 사용자 입장에선 데이터 자체를 의심하게 된다. "대충 맞는 것 같다"로 넘어가면 반드시 다시 돌아옴.

작업 흐름은 단순하게 유지하려 함.

  • 변경 전에 현재 동작 스크린샷이나 수치를 메모
  • 수정 후 같은 케이스로 다시 확인
  • 연관 화면이 있으면 숫자 cross-check
  • 커밋 메시지는 "무엇을"보다 "왜"를 담으려고 노력

작은 커밋을 자주 하면 문제가 생겼을 때 어느 변경에서 깨졌는지 찾기 훨씬 쉬움. 그래서 논리적으로 독립된 단위로 커밋을 쪼개는 습관을 유지 중. 이번 작업도 레이아웃 정렬, 칩 비주얼, 아이콘, 반응형을 각각 별도 커밋으로 올렸음. 나중에 반응형 부분만 되돌려야 할 일이 생겼을 때 훨씬 깔끔하게 처리할 수 있다.

댓글 0

첫 댓글 달아줘.