다크테마 사라진 버그 수정하고 인터랙션 강화하기

한 주쯤 전에 메인 페이지와 결과 조회 화면에서 다크테마가 갑자기 안 보인다는 신고를 받았다. 일부 사용자들만 영향을 받는 것처럼 보여서 초반엔 캐시 문제로 의심했는데, 알고 보니 CSS 쇼트핸드 프로퍼티 하나가 배경색을 의도치 않게 초기화해버린 거였다. 이걸 수정하면서 동시에 핵심 페이지들에 2D 애니메이션과 톤 조정을 함께 진행했는데, 이 과정에서 스타일 시스템과 팀 리뷰의 중요성을 다시 한번 느꼈다.

쇼트핸드의 예상 밖 동작

문제는 globals.css에서 background 쇼트핸드를 썼다는 거였다. CSS에서 background는 생각보다 강력한데, 색상뿐 아니라 이미지, 위치, 반복, 첨부 방식까지 한 번에 초기화한다.

/* 나쁜 예 */
background: linear-gradient(/* ... */);
/* 이건 사실 다음과 같음 */
/* background-color: transparent;
   background-image: linear-gradient(...);
   background-position: 0 0;
   background-repeat: repeat;
   ... */

우리 경우에는 starfield 애니메이션을 쇼트핸드로 적용하면서, 다른 곳에서 명시적으로 설정한 배경색(다크 테마 검은색)을 덮어써버렸다. 미디어 쿼리에서 다크 모드 감지는 되는데, 그 색이 나중에 쇼트핸드 background 한 줄로 다 초기화되니까 사용자는 배경이 투명하거나 기본값으로만 보이는 것처럼 느껴진 것.

/* 옳은 방법 */
background-image: linear-gradient(/* starfield */);
background-color: var(--dark-bg);
/* 또는 background-color를 먼저 선언하고 background-image만 따로 */

왜 이런 일이 생기는가

팀 입장에서 생각해보니, 몇 가지 근본 원인이 있었다.

먼저 CSS 쇼트핸드의 위험성을 코드 리뷰에서 충분히 잡아내지 못했다. 쇼트핸드는 편하지만, 특히 이미 정의된 스타일과 섞일 때는 예상 밖의 캐스케이딩이 일어날 수 있다. 복잡한 CSS 구조라면 더더욱.

다음으로, 다크 모드 스타일링의 우선순위 체계가 명확하지 않았다. globals.css vs 컴포넌트 레벨 스타일 vs CSS 변수 사용 — 어느 것이 언제 우선되는지 문서화되지 않았고, 따라서 새 기능을 추가할 때도 기존 스타일과의 상호작용을 예측하기 어려웠다.

수정과 함께 UX도 다듬기

다행히 이 버그를 잡으면서, 더 나은 상황으로 만들 기회가 생겼다. 단순히 배경색을 복구하는 것에 그치지 말고, 애니메이션과 카피 톤을 함께 개선하기로 결정했다.

추가한 2D 애니메이션들:
- 트윙클: starfield의 별들이 깜빡거리면서 생명력 더하기
- 플로팅: 카드나 주요 요소가 미묘하게 위아래로 움직이기
- 페이드업: 초기 로딩 시 요소들이 아래에서 위로 나타나기
- 글로우: 포커스나 호버 상태에서 은근한 빛 효과
- 샤인: 텍스트나 버튼을 쓸어가는 빛의 윤기

이런 애니메이션은 단순한 눈요깃감이 아니라, 사용자에게 "이 시스템이 반응하고 있다"는 피드백을 준다. 특히 비동기 작업 (예: 결과 조회) 중에 이런 미니 애니메이션이 있으면, 로딩 경험이 한결 부드럽고 자연스러워진다.

카피 톤 조정은 문체와 어조를 맞춘 것인데, 기술적인 메시지를 좀 더 친근하게, 또는 상황에 맞게 다듬었다. 예를 들어 오류 메시지는 무조건 딱딱한 기술 용어보다, 사용자가 이해할 수 있는 자연어로.

팀 차원에서의 교훈

이 작업을 통해 팀에 남긴 것:

1. CSS 쇼트핸드 리뷰 체크리스트: PR에서 background, margin, padding 같은 쇼트핸드를 쓸 때는 "기존 스타일과의 충돌 가능성"을 명시적으로 확인하자.

2. 다크 모드 스타일 우선순위 가이드: 어느 레벨에서 색을 정의하는지, 그리고 그게 다른 곳에서 언제 오버라이드될 수 있는지 문서화.

3. 애니메이션은 의도와 함께: 애니메이션을 추가할 때는 "이게 사용자 경험의 어느 부분을 개선하는가"를 동료들과 먼저 논의. 단순 장식이 되지 않으려고.

실제로 이 변경을 한 후 팀 채널에 스크린샷을 올렸더니, 개발자뿐 아니라 디자인 팀도 "톤이 훨씬 일관되고, 상호작용이 더 명확하다"고 피드백했다. 버그 수정에 그치지 않고 전체 경험을 함께 개선한 덕분이라고 본다.

다음번부터는 쇼트핸드 CSS 변경할 때 한 번 더 신경 쓰고, 리뷰어도 그 부분을 적극적으로 지적하기로 팀과 약속했다.

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

• 기계식키보드 쿠팡에서 보기 →
• 모니터암 쿠팡에서 보기 →
• 커피머신 쿠팡에서 보기 →

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