Chrome이 거짓말을 한다는 걸 알면서도 우리는 왜 계속 쓰는가
프론트엔드 개발자 대부분의 워크플로우는 암묵적으로 고정되어 있다. Chrome에서 빌드하고, Lighthouse로 점수를 확인하고, Firefox에서 빠르게 훑은 뒤 Safari는 QA에서 버그가 날아올 때 마지못해 연다. 이 흐름이 익숙한 이유는 단 하나—Chrome이 너무 관대하기 때문이다. 잘못된 CSS도 그럭저럭 렌더링해주고, 무거운 JS도 삼켜주고, 포커스 스타일이 엉망이어도 '그런대로 괜찮아 보이게' 만들어준다.
그런데 dev.to에 올라온 Richard Lemon의 글 "Why I Still Test In Safari First"는 이 관성에 정면으로 반박한다. 그의 주장은 단순하다. Safari를 첫 번째 테스트 환경으로 삼는 순간, 코드 품질이 구조적으로 올라간다는 것이다.
Safari는 엄한 선생이다
Safari의 특성을 한 문장으로 요약하면 '스펙에 충실한 완고함'이다. Chrome이 개발자의 의도를 추측해서 렌더링을 보정해줄 때, Safari는 그냥 스펙대로 거부한다. 이것이 왜 자산인가?
Lemon이 경험한 사례가 명확하게 설명해준다. CSS Grid, 가변 폰트, 스크롤 연동 애니메이션으로 구성된 에디토리얼 레이아웃을 Chrome과 Firefox에서는 완벽하게 확인했다. 그런데 iPad Safari에서 열자마자 주 그리드 컬럼이 방향 전환 시 40%로 무너졌다. 원인은 세 가지가 복합적으로 작용했다—퍼센트 기반 minmax() 트랙, 실험 후 방치된 flex 래퍼, 그리고 모바일 Safari의 동적 툴바와 충돌하는 height: 100vh. Chrome은 이 셋을 모두 조용히 무마했다. Safari는 세 문제를 한 번에 터뜨렸다.
결과적으로 Lemon은 불필요한 flex 래퍼를 제거하고, 100vh를 논리 단위와 calc로 교체하고, min/max 값을 정리했다. 코드가 단순해졌고, 모든 브라우저에서 레이아웃이 더 견고해졌다.
CSS 작성 습관 자체가 바뀐다
Safari 퍼스트가 만들어내는 가장 흥미로운 변화는 테스트 결과가 아니라 설계 질문의 변화다. Chrome에서 시작하면 자연스럽게 '이 새로운 CSS 기능을 어떻게 쓸까'를 먼저 묻게 된다. Safari에서 시작하면 질문이 달라진다.
**"이 경험을 만들기 위한 가장 작고, 가장 지루한 CSS는 무엇인가?" **
이 질문은 스펙 탐방(spec tourism)을 줄이고, 인트린식 사이징과 콘텐츠 흐름에 의존하는 레이아웃으로 자연스럽게 유도한다. 고정 높이와 마법의 숫자(magic number) 대신, 브라우저가 렌더링 엔진을 바꿔도 살아남는 코드가 남는다. 지루해 보이지만 깨지지 않는 코드—이게 프로덕션에서 진짜 필요한 것이다.
폼과 접근성: Chrome이 절대 알려주지 않는 영역
Safari 퍼스트의 효과가 가장 두드러지는 곳은 폼이다. Chrome은 잘못된 타입, 엉성한 포커스 스타일, 불완전한 속성에도 '그런대로 동작하는' 결과를 돌려준다. Safari는 그렇지 않다.
Lemon이 경험한 구체적인 케이스가 있다. 커스텀 포커스 링, 접근성 색상 대비, 트랜지션까지 세심하게 설계한 입력 폼이었다. Chrome에서는 완벽했다. Safari에서 탭 키로 이동하자 포커스 아웃라인이 깜빡이고, border-radius가 포커스 중에 흔들리고, 일부 입력 요소는 링이 아예 사라졌다. 원인은 브라우저 기본 아웃라인을 불일치하게 제거한 채 Chrome의 포커스 휴리스틱에 의존했기 때문이었다.
오토필 + 다크 모드 조합도 마찬가지다. Chrome은 배경색과 텍스트 색이 살짝 어긋나도 넘어가지만, Safari는 가독성이 무너지는 상태를 그대로 노출한다. Safari에서 먼저 수정하면 Chrome은 자동으로 더 나아진다.
성능의 진실은 모바일 Safari가 말해준다
데스크톱 Chrome은 성능에 관한 한 거짓말쟁이다. 무거운 JS, 리페인트가 잦은 트랜지션, 패럴랙스를 쏟아부어도 60fps를 유지해준다. 그걸 보고 '성능 좋은 제품'이라고 착각한 채 출시하면, 오래된 iPhone을 든 사용자가 배터리가 타는 경험을 하게 된다.
Lemon의 관찰은 직접적이다. 스크롤 연동 애니메이션은 Chrome에서 부드러웠지만 Safari에서 끊겼다. 대형 요소의 그림자와 블러 효과는 데스크톱에서 예뻤지만 모바일 Safari의 GPU를 죽였다. 서드파티 스크립트가 크리티컬 패스에 있을 때 Chrome은 버텼지만 모바일 Safari는 눈에 띄게 멈췄다.
그래서 그의 기준은 이렇다. 중간급 iPhone에서 부드럽게 느껴지면, 그때 Chrome에서 디테일을 더한다. 순서를 뒤집지 않는다.
iOS 뷰포트 문제: 늦게 만날수록 비싸진다
100vh가 iOS Safari에서 주소창 뒤로 잘린다는 건 이제 상식이다. 하지만 Chrome-First 워크플로우에서는 이 문제를 항상 늦게 만난다. 콘텐츠가 채워지고, 디자인 피드백이 끝나고, 이해관계자가 특정 시각적 결과에 애착을 가진 뒤에—클라이언트가 회의에서 iPhone 스크린샷을 보여줄 때 비로소 마주친다.
Safari 퍼스트는 이 문제를 '예외 케이스'가 아니라 '베이스라인'으로 만든다. 동적 뷰포트를 처음부터 전제하면 자연스럽게 콘텐츠 중심의 수직 레이아웃을 택하게 되고, 100vh 대신 현대적인 뷰포트 단위와 폴백을 의도적으로 사용하게 된다. 폼 마크업을 바꾸기 쉬울 때 키보드와 포커스 흐름을 테스트하게 된다.
시사점: 엄격한 제약이 더 나은 코드를 만든다
Safari 퍼스트 전략이 제안하는 것은 단순한 테스트 순서 변경이 아니다. 제약을 의도적으로 당기는 설계 철학이다. 가장 관대한 환경에서 시작하면 문제를 가장 늦게 발견한다. 가장 엄격한 환경에서 시작하면 문제를 가장 일찍 발견하고, 그 과정에서 코드가 더 단순하고 견고해진다.
이 논리는 접근성 개발 원칙과 정확히 맞닿는다. 스크린 리더와 키보드 내비게이션을 처음부터 테스트하면 마크업 구조가 좋아지는 것처럼, Safari를 처음부터 열면 CSS 설계가 좋아진다. 가장 어려운 사용자를 먼저 고려할수록 모든 사용자의 경험이 올라간다.
전망: 브라우저 다양성이 줄어들수록 이 전략의 가치는 올라간다
Chromium 기반 브라우저가 시장을 지배하는 지금, Safari는 사실상 웹의 유일한 대안 렌더링 엔진이다. Blink가 표준을 사실상 주도하는 흐름 속에서 WebKit의 '고집'은 오히려 웹의 건강성을 지키는 마지막 방어선 역할을 한다.
AI 코딩 도구가 빠르게 확산되는 지금, 생성된 코드의 품질을 검증하는 기준이 더욱 중요해졌다. AI가 짜준 레이아웃 코드를 Chrome에서만 확인하면, 보정된 결과를 보고 안전하다고 착각하기 쉽다. Safari 퍼스트는 그 착각을 구조적으로 막는 워크플로우다. 빠르게 만들되, 제대로 검증하는 루프—그 루프의 첫 번째 게이트로 Safari를 두는 것이 단순하면서도 강력한 선택이다.