'동작은 하는데 이상하게 생긴' 버그가 가장 무섭습니다
기능 테스트는 다 통과했는데, Safari에서 버튼이 3px 밀려 있다. 의존성 업데이트 이후 폰트 웨이트가 슬그머니 바뀌었다. Figma 시안과 비교해보면 border-radius가 미묘하게 다르다. 이런 버그는 console.error도 안 뜨고, 유닛 테스트도 통과하고, CI도 초록불이다. 그냥 조용히 프로덕션에 배포된다.
사용자 입장에서는 "뭔가 이상한데?"라는 느낌만 남고, 팀 입장에서는 "분명히 QA 했는데?"라는 혼란만 남는다. dev.to에 올라온 Visual Regression Testing 가이드가 정확히 이 지점을 찌른다. CI/CD 파이프라인은 "동작하는가?"에는 잘 답하지만, "여전히 제대로 보이는가?"에는 아무 말도 안 한다는 것.
Visual Regression Testing: 픽셀 비교가 아니라 '의미 있는 변화' 감지
"그럼 스크린샷 찍어서 비교하면 되지 않나요?"라고 물으면, 저도 예전엔 그렇게 생각했습니다. 근데 실제로 해보면 false positive 지옥이 시작된다. OS 업데이트 후 anti-aliasing이 미세하게 바뀌거나, 동적 광고 슬롯이 1px 움직이거나, CPU 부하로 툴팁 애니메이션 타이밍이 달라지면 — 전부 빨간불이 뜬다. 결국 팀이 시각적 테스트 자체를 꺼버리는 경우가 생긴다. 테스트 도구 문제가 아니라 신호 대 잡음 비율의 문제다.
dev.to 기사에서 소개된 SmartUI 같은 AI 기반 비주얼 테스팅 접근법이 흥미로운 건, 픽셀 단위 비교를 넘어 "이 차이가 실제로 의미 있는 변화인가?"를 판단한다는 점이다. 더 나아가 DOM 구조 비교 모드는 스크린샷이 "그럭저럭 비슷해 보여도" flexbox 레이아웃이 틀어졌다거나, 특정 breakpoint에서 컨테이너가 무너졌다는 걸 잡아낸다. 독일어 번역이 영어 대비 40% 길어서 레이아웃이 밀리는 케이스 — 이거 국제화 작업하는 팀이라면 다들 한 번씩 겪어봤을 거다.
Figma-to-Production 갭: 가장 조용한 디자인 버그
Figma에서 볼 때는 완벽했는데, 실제로 구현하면 미묘하게 다르다는 경험, 프론트엔드 개발자라면 너무 익숙하다. 더 심각한 건 처음엔 "거의 맞는 것 같은데"로 머지되고, 이후 5번의 점진적 변경이 쌓이면서 디자인 원본과 완전히 멀어진다는 것. 분기 말 디자인 리뷰 때서야 "어? 이게 언제부터 이랬지?"가 나온다.
이 드리프트를 PR 레벨에서 잡는다는 아이디어 — Figma 프레임을 baseline으로 삼아 실제 프로덕션 화면과 자동 비교 — 는 디자인-개발 협업 워크플로우 관점에서 꽤 실질적인 접근이다. 디자인 토큰 시스템을 갖추고 있는 팀이라면 특히 유효할 것 같다. "맞는 것 같다"는 주관적 판단 대신 자동화된 검증이 들어오는 순간, 디자인 QA의 기준이 달라진다.
React Native + Tailwind: 모바일에서도 디자인 시스템을 이식하는 법
velog에 올라온 React Native 초기 설정 글은 좀 다른 맥락에서 흥미롭다. "테일윈드가 너무 좋아서 바~~~로 NativeWind까지 설치했다"는 문장에서 공감이 절로 나왔는데, 이게 단순한 편의성 이야기가 아니라 디자인 시스템 일관성의 문제이기도 하다.
웹에서 Tailwind로 디자인 토큰을 관리하다가 모바일 앱을 만들 때 StyleSheet로 갈아타면 primary: '#5B0E14' 같은 값을 두 곳에서 따로 관리하게 된다. NativeWind를 통해 tailwind.config.js에 색상 토큰을 중앙화하면 웹과 모바일이 같은 설계 언어를 공유할 수 있다. 물론 복잡한 애니메이션에서는 StyleSheet이 여전히 유리하니 — 이 글에서 제안한 것처럼 — 두 방식을 목적에 맞게 분리하는 게 현실적이다.
프로젝트 구조 면에서 app/과 src/를 분리한 결정도 공감된다. Expo Router가 app/ 폴더를 라우팅으로 고정 점유하는 상황에서, 비즈니스 로직까지 섞으면 나중에 관심사 분리가 정말 힘들어진다. screens/ 폴더 필요 여부처럼 "관습적으로 있던 것"과 "실제로 필요한 것"을 구분하는 시선이 초기 설정의 기술 부채를 결정한다.
Edge-Native i18n: 번들 사이즈와 Core Web Vitals를 동시에 잡는 방법
"번역 JSON 파일을 클라이언트에 내려보내지 마세요." dev.to의 Edge-Native i18n 기사는 이 한 문장으로 요약된다. 그런데 이게 생각보다 급진적인 주장이다.
SPA 시대의 기본 패턴은 클라이언트가 브라우저 언어를 감지하고 50KB짜리 번역 파일을 fetch해서 렌더링하는 것이었다. Astro + Island Architecture 환경에서도 기존 i18n 라이브러리들은 이 패턴을 그대로 답습한다. Cloudflare Workers처럼 번들 사이즈 제한(Free 3MB, Paid 10MB)이 엄격한 환경에서 번역 파일을 JavaScript 번들에 "구워 넣으면" Worker 콜드 스타트가 느려지고, 언어가 하나 추가될 때마다 번들이 불어난다.
이 글이 제안하는 해결책은 구조적으로 역방향이다. Cloudflare KV에 번역 데이터를 저장하고, Astro Middleware가 요청 단계에서 언어를 결정해 SSR 시점에 이미 번역된 HTML을 내려보낸다. 클라이언트의 React Island가 깨어날 때 텍스트가 이미 거기 있다. useEffect도 없고, 로딩 스피너도 없고, hydration mismatch도 없다. Lighthouse의 CLS 점수가 깔끔하게 유지된다.
uiLocale과 translationLocale의 분리: 우아한 장애 처리
이 아키텍처에서 특히 날카로운 부분은 "의도(intent)"와 "데이터(data)"를 분리한다는 개념이다. 사용자가 /ja/about에 접근했는데 일본어 번역이 아직 배포되지 않은 경우, 기존 방식은 302 리다이렉트로 /en/about으로 보내버린다. URL이 바뀌고, 사용자 의도가 무시되고, SEO 신호가 흔들린다.
uiLocale(URL과 <html lang> 제어)과 translationLocale(실제 KV에서 가져올 언어) 을 분리하면 URL은 /ja/를 유지하면서 콘텐츠는 영어로 graceful degradation된다. "undefined is not a function"도 없고 리다이렉트도 없다. 기획자가 "이 언어 페이지 나중에 추가할게요"라고 말했을 때 개발팀이 안전하게 수용할 수 있는 구조다.
시사점: 품질 자동화의 세 축이 가리키는 방향
세 기사를 관통하는 공통점이 하나 있다. "이미 잘 돌아가고 있다고 생각했는데 실제로는 아니었던" 문제들이다.
- 기능 테스트는 통과했지만 UI가 깨진 채 배포됨
- 웹에서 쓰던 디자인 토큰이 모바일에서 중복 관리됨
- i18n 라이브러리가 "동작"하지만 번들 사이즈와 Web Vitals를 갉아먹고 있음
프론트엔드 품질의 기준이 "기능이 동작하는가"에서 "의도한 대로 보이는가", "성능 지표를 유지하는가", "구조가 확장 가능한가"로 이동하고 있다. 이건 도구의 문제가 아니라 파이프라인 설계의 문제다.
전망: 자동화가 커버하지 못하는 마지막 1%
Visual Regression Testing이 고도화될수록, 그리고 Edge 아키텍처가 성능 최적화의 기본값이 될수록 — 아이러니하게도 "자동화가 판단하기 어려운 것"의 가치가 올라간다. AI가 픽셀 diff를 분류해줘도, 이 변화가 실제로 사용자 경험을 개선하는지는 히트맵과 A/B 테스트 데이터가 필요하다. 번들 사이즈를 줄여도, 사용자가 어떤 인터랙션에서 이탈하는지는 수치로 읽어야 한다.
자동화는 "잘못된 것을 막는" 역할을 점점 잘 해내고 있다. 다음 과제는 "더 나은 것을 찾아내는" 루프를 파이프라인에 연결하는 것이다. Lighthouse 점수가 95를 넘겼다고 끝이 아니라, 그다음 1점을 어떤 사용자 데이터로 판단할 것인지가 진짜 질문이 된다.