결제 화면 포함 CSS와 SCSS 원본 불일치 해소

스타일 빌드 파이프라인이 분리돼 있다 보니 이런 일이 생긴다. SCSS 원본은 바뀌었는데 실제 배포 CSS는 예전 상태 그대로인 상황. 오늘 커밋 하나로 해소했는데, 작업 자체보다 "왜 여기까지 왔나"를 정리해두고 싶어서 길게 씀.

SCSS 빌드 파이프라인 분리가 낳는 드리프트

SCSS를 쓰는 이유는 하나다. 변수, 중첩, 믹스인으로 유지보수를 편하게 하고, 원본 하나만 관리하면 컴파일 결과는 자동으로 따라오게 하는 것. 그 전제가 깨지는 순간 SCSS는 부채가 된다. "SCSS 고쳤는데 왜 화면이 안 바뀌지?" → "아, CSS 직접 고쳐야 하나?" 이 생각이 팀에 퍼지기 시작하면 돌이키기 어려워진다.

이번에 어긋남이 누적된 경로는 두 가지였음.

첫 번째는 환경 설정 문제라 잡기 쉽다. 두 번째가 진짜 골치다. 디자이너 입장에서는 "빌드 기다릴 시간이 없었다", "컴파일 방법을 몰랐다" 같은 이유가 있었을 텐데, 그 결과로 CSS에 수정분이 들어가고 SCSS는 그냥 놔뒀던 것. 다음 빌드 한 번이면 그 수정이 통째로 날아가는 구조였음.

대상 파일이 공통 시트, 신규 테마 시트, 이커머스 결제 플랫폼 화면 시트 셋이었는데, 결제 화면 시트가 포함된 게 찜찜했다. 공통이나 테마 시트야 시각적 어긋남 정도로 끝나지만, 결제 화면은 UI 오차가 UX 신뢰 문제로 직결된다. "버튼이 이상하다", "입력창이 잘린다" 같은 피드백이 들어오면 원인 찾는 데만 시간이 꽤 걸리고, 그 시간 동안 전환율 얘기가 나온다.

정리 순서와 역포팅 작업

작업 자체는 단순한데, 순서를 한 번 잘못 잡으면 변경분이 다 날아가니 신중하게 밟았음.

1. SCSS 원본을 현재 상태로 컴파일 → 임시 결과물 확보
2. 임시 결과물 vs 현재 배포 CSS 줄 단위 diff
3. diff 중 SCSS에 없는 라인(디자이너 직접 수정 추정) → SCSS로 역포팅
4. 역포팅 완료 후 다시 컴파일 → 최종 CSS 덮어씌우기

3번, 역포팅이 시간을 제일 많이 잡아먹었다. 컴파일된 CSS를 보고 "이게 어느 SCSS 블록에 들어가야 하는 건지" 추적해야 했는데, 셀렉터 우선순위 때문에 위치가 애매한 케이스가 꽤 있었음. 변수로 뽑혀야 할 값인데 하드코딩으로 들어간 것들도 보였고. 그냥 CSS에 넣을 수도 있지만, 그렇게 하면 다음 변수 수정 때 또 어긋나니 귀찮아도 SCSS 변수 구조에 맞춰서 역포팅했음.

간단한 예를 들면, CSS에서 이렇게 들어온 라인이 있을 때:

.payment-btn {
  background-color: #1a73e8;
  border-radius: 4px;
  padding: 12px 24px;
}

이걸 CSS 끝에 그냥 붙이는 게 아니라 SCSS에서 이렇게 처리하는 게 맞음:

// _variables.scss
$btn-primary: #1a73e8;
$btn-radius: 4px;

// _payment.scss
.payment-btn {
  background-color: $btn-primary;
  border-radius: $btn-radius;
  padding: 12px 24px;
}

이 판단을 파일마다, 셀렉터마다 해야 하니까 diff 줄 수가 많으면 오래 걸린다. 하드코딩 값이 기존 변수에 대응하는 게 맞는지, 아니면 새 변수를 뽑아야 하는지도 판단해야 하고. 셀렉터 우선순위나 변수 치환 흔적 보고 어디서 갈라졌는지 추적하는 게 이 작업의 핵심이었음.

다음에 안 하려면

동기화 자체는 끝났지만 이게 또 생기지 않으려면 두 가지가 필요하다.

첫째, SCSS 빌드 스텝 강제화. 환경마다 있다 없다 하는 게 문제였으니, 빌드 스크립트나 CI에서 SCSS 컴파일을 필수 단계로 박아야 한다. 로컬 개발 환경에서 "빌드 안 됨" 소리가 나와도 통과 기준을 낮추지 않는 게 포인트임. 불편함을 허용하기 시작하면 그 불편함을 우회하는 방식이 또 생긴다.

둘째, 디자이너 워크플로 합의. "배포 CSS 직접 수정 금지"를 문서 한 줄로 끝내면 실효가 없다. SCSS 파일 위치 안내, 로컬 빌드 방법, 급할 때 변경 요청할 채널 같은 실제 대안까지 같이 정리해줘야 지켜진다. 규칙만 있고 대안이 없으면 안 지켜지고, 안 지켜지면 몇 달 뒤 또 이 짓 반복이다.

TODO 파일도 이 흐름에 맞춰 정리했음. 처리 완료 항목은 잘라내고, 이번 동기화에서 새로 보인 잔여 이슈를 추가. 작업요약 문서도 같이 갱신해서 다음 사람이 맥락 잡기 쉽게 해뒀음.

chore 커밋이라 가벼워 보이지만 실제로는 빌드 파이프라인 일관성 문제였음. 원본과 결과물이 어긋나기 시작하면 그 위에 쌓이는 모든 변경이 점점 흔들린다. 어느 시점부터는 "SCSS가 진짜 원본인지, CSS가 진짜 원본인지" 모르게 된다. 그 상태에서 리팩터 들어가면 어디서 무엇이 깨질지 예측하기 어려워진다. 이번 동기화로 일단 기준점을 맞췄고, 다음은 빌드 표준화까지 가야 진짜 끝이다.