개발 slecs

전체 페이지 UI를 한 번에 묶어 다듬은 이유와 CSS 일관성 확보 전략

목차

한꺼번에 여러 페이지를 묶어서 UI를 다듬었다. about, contact, courses, course-detail, index 다섯 개 템플릿과 공통 styles.css 까지, 사실상 사용자가 보는 화면 전체를 한 번에 손댄 커밋이다.

왜 이걸 한 번에 묶었나

페이지별로 찔끔찔끔 PR을 올리다 보면 CSS가 뒤섞이는 타이밍이 생긴다. 특히 공통 styles.css를 여러 브랜치에서 동시에 건드리면 머지 충돌이 꽤 골치 아프고, 리뷰어 입장에서도 "이 클래스가 어느 페이지에서 쓰이는 건지" 맥락을 파악하기 어렵다. 그래서 UI 정리 작업은 가급적 한 사이클에 묶어서 올리는 편이 낫다고 판단했다.

물론 커밋 단위가 커지면 리뷰 비용도 올라간다는 반론도 있다. 트레이드오프를 정리하면 이렇다.

방식 장점 단점
페이지별 개별 커밋 롤백 단위 명확 CSS 충돌 위험, 리뷰 맥락 분산
한 번에 묶음 커밋 일관성 유지, 충돌 최소화 커밋 diff가 넓어짐

이번엔 "UI 일관성"이 핵심 목적이었기 때문에 묶음 쪽을 선택했다.

작업 내용

각 파일이 담당하는 역할과 이번에 건드린 포인트를 간단히 정리하면:

  • index.html — 랜딩 페이지. 첫인상이니까 레이아웃 여백, 타이포 크기를 기준점으로 잡았음
  • about.html — 소개 페이지. 텍스트 중심이라 line-height, 문단 간격이 핵심
  • contact.html — 폼 UI. 인풋 박스 스타일, 버튼 정렬 다듬기
  • courses.html — 강좌 목록. 카드 레이아웃 간격, hover 상태
  • course-detail.html — 강좌 상세. 가장 정보가 많아서 섹션 구분선, 계층 구조 신경 씀
  • styles.css — 위 변경 사항들을 실제로 반영하는 공통 스타일 시트

공통 CSS를 먼저 건드리고 각 템플릿에서 검증하는 순서로 진행했다. 반대로 하면 "이 스타일이 어디서 왔지?"를 역추적하는 시간이 생겨서 흐름이 끊긴다.

/* 예시: 카드 컴포넌트 일관성 확보 패턴 */
.card {
  border-radius: 8px;
  padding: 1.5rem;
  box-shadow: 0 2px 8px rgba(0, 0, 0, 0.08);
}

.card:hover {
  box-shadow: 0 4px 16px rgba(0, 0, 0, 0.14);
  transition: box-shadow 0.2s ease;
}

이런 식으로 컴포넌트 단위로 CSS를 모아두면 나중에 다른 팀원이 새 페이지를 만들 때도 .card 하나만 붙이면 통일된 느낌이 나온다. 스타일을 "규칙"이 아닌 "재사용 가능한 부품"으로 다루는 게 핵심이다.

리뷰와 유지보수 관점 회고

이런 UI 정리 커밋을 팀에서 리뷰할 때 자주 놓치는 부분이 있다. 로직 변경이 없으니 "대충 봐도 되겠지" 하고 빠르게 approve 하는 경우인데, 사실 CSS 리팩터링이 누적되면 클래스명 충돌이나 specificity 지옥이 생각보다 조용하게 쌓인다.

그래서 나는 이런 커밋의 리뷰 포인트를 팀에 공유할 때 아래 기준을 제안한다.

  • 기존에 쓰던 클래스명을 삭제/변경했는가 (다른 페이지에서 참조 중일 수 있음)
  • 인라인 스타일이 줄었는가, 늘었는가
  • CSS 선택자의 specificity가 불필요하게 높아지지 않았는가
  • 반응형 breakpoint가 기존 기준과 맞는가

기능 커밋보다 오히려 꼼꼼히 봐야 할 때가 있다. UI는 "동작"이 아니라 "느낌"으로 회귀 테스트를 하기 때문에 자동화하기 어렵고, 나중에 문제가 생겨도 어느 커밋에서 어긋났는지 추적이 불편하다. 그 부분을 팀원들과 계속 이야기하면서 맞춰가는 중이다.

끝.


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

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

댓글 0

첫 댓글 달아줘.