크로스 브라우저

브라우저는 웹 문서를 받아 화면으로 그려 주는 프로그램인데, 같은 문서를 받고도 결과가 서로 달랐습니다. 여백을 계산하는 방식이 달랐고, 어떤 브라우저에만 있는 기능이 있었고, 표준에 적힌 대로 만들지 않은 부분도 많았습니다. 그래서 한 곳에 맞춰 만든 화면이 다른 곳에서는 글자가 겹치거나 버튼이 눌리지 않았습니다.

이 불편은 "제 컴퓨터에서는 되는데요" 라는 한 문장으로 요약됐습니다. 개발자가 자기 브라우저에서 확인하고 완료했다고 말하면, 다른 브라우저를 쓰는 기획자가 화면을 열고 깨진 모습을 캡처해 보냈습니다. 어느 쪽도 거짓말을 하지 않았고 둘 다 자기 화면을 정확히 보고 있었습니다. 한쪽에서는 결제 버튼이 화면 밖으로 밀려나 있었고 다른 한쪽에서는 멀쩡했습니다.

당시의 대응은 브라우저마다 다른 코드를 따로 쓰는 것이었습니다. 이 브라우저면 이렇게, 저 브라우저면 저렇게 갈라 둔 분기가 쌓이면서 코드는 금세 읽기 어려워졌고, 새 브라우저가 나올 때마다 분기가 하나씩 늘었습니다. 표준이 자리 잡고 브라우저들이 그 표준을 따르면서 이 분기는 많이 줄었지만, 문제가 사라지지는 않았습니다. 지금은 표준의 어느 부분을 언제 구현했는지가 브라우저마다 달라서 생기는 차이가 남아 있고, 그 차이를 다루는 일이 크로스 브라우저입니다.

브라우저를 다 맞추는 대신 맞출 범위를 먼저 정하고, 그 범위 안에서 차이가 나는 곳만 찾아 메웁니다. 네 단계로 돕니다.

1. 지원 범위를 정합니다. 접속 기록을 열어 실제 사용자가 어느 브라우저를 쓰는지 보고 기준을 긋습니다. 점유율이 1퍼센트에 못 미치는 옛 버전을 지원 목록에서 빼면 그만큼 일이 줄어듭니다. 이 결정을 미뤄 두면 모든 브라우저를 다 맞춰야 한다는 막연한 부담만 남습니다.
2. 쓰려는 기능이 그 범위에서 되는지 확인합니다. CSS의 새 배치 속성이나 자바스크립트의 새 문법은 브라우저마다 지원 시점이 다릅니다. 기능별로 어느 버전부터 되는지 정리해 둔 표를 찾아보는 것이 코드를 쓰기 전에 할 일입니다.
3. 차이를 메웁니다. 세 가지 방법이 있습니다. 없는 기능을 대신 채워 주는 코드인 폴리필을 넣거나, 새 문법을 옛 문법으로 번역해 내보내거나, 안 되는 곳에서는 조금 단순한 모습으로 보이게 두는 것입니다. 셋째가 가장 싸게 먹힙니다. 둥근 모서리가 각지게 나오는 정도는 대부분 그냥 둬도 되고, 결제가 안 되는 것만 반드시 메우면 됩니다.
4. 실제 브라우저에서 확인합니다. 화면 크기를 줄여 보는 것으로는 잡히지 않습니다. 브라우저마다 그리는 엔진이 달라서 같은 폭에서도 결과가 다르기 때문입니다. 주요 흐름은 E2E 테스트, 그러니까 사용자 흐름 전체를 실제처럼 돌려 보는 테스트를 브라우저별로 돌려 자동으로 확인합니다.

이 네 단계에서 실제로 시간이 걸리는 곳은 1번입니다. 지원 목록은 개발팀이 혼자 정할 수 없습니다. 사용자 3퍼센트가 쓰는 브라우저를 버릴지 말지는 그 3퍼센트가 누구인지에 따라 달라지고, 기업 고객사의 표준 브라우저가 거기 섞여 있으면 숫자만 보고 결정할 수 없습니다.

차이가 자주 드러나는 자리는 정해져 있습니다.

• 입력 양식 — 날짜 선택이나 파일 첨부처럼 브라우저가 자체 화면을 띄우는 요소는 모양과 조작법이 제각각입니다. 어떤 곳은 달력을 띄우고 어떤 곳은 빈칸만 내놓습니다.
• 높이 계산 — 화면 전체 높이를 기준으로 잡은 영역이 모바일에서 주소창에 가려집니다. 아래쪽 버튼이 잘리는 사고가 여기서 납니다.
• 글꼴과 줄바꿈 — 같은 글꼴을 지정해도 자간과 줄 높이가 미세하게 달라서, 두 줄로 맞춰 둔 제목이 한쪽에서만 세 줄이 됩니다.
• 미디어와 알림 — 동영상 자동 재생이나 알림 권한처럼 브라우저가 정책으로 막아 둔 기능은 허용 조건이 서로 다릅니다.
• 아이폰 — 아이폰에서는 어느 브라우저를 깔아도 화면을 그리는 엔진이 같아서, 그 엔진에서 나는 차이는 앱을 바꿔 봐도 그대로입니다.

페이지덱에서 이 문제가 가장 크게 불거진 것은 문서 공유 링크를 처음 열 때였습니다. 민서가 만든 화면이 크롬에서는 의도대로 나왔는데 사파리에서는 본문 영역이 화면 아래로 밀려 첫인상이 빈 화면이었습니다. 공유 링크는 처음 오는 사람이 여는 자리라 이 차이가 곧바로 이탈로 이어졌습니다. 태오가 원인을 찾아 고친 뒤로 팀은 공유 링크 화면만큼은 배포 전에 브라우저 세 개에서 열어 보는 절차를 넣었습니다.

"이거 사파리에서 확인해 보셨어요?"

한 브라우저에서만 보고 완료로 넘기지 말자는 뜻입니다.

"지원 브라우저는 최신 두 버전까지로 잡았습니다."

어디까지 맞출지 범위를 정해 두고 그 밖은 보지 않겠다는 선언입니다.

"그 기능 아직 지원 안 돼서 폴리필 넣어야 합니다."

목록에 있는 브라우저 중 일부에 없는 기능이라 대신 채우는 코드가 필요하다는 말입니다.

배포 전 확인에서 이 이야기가 나오면 페이지덱은 두 가지를 나눠 봅니다. 눌러도 아무 일이 일어나지 않는 것은 그 자리에서 고치고, 여백이 2픽셀 다른 것은 기록만 남기고 넘어갑니다. 이 구분을 해 두지 않으면 확인 절차가 한없이 길어져서, 다음번에는 아예 건너뛰게 됩니다.

요즘 브라우저는 다 표준을 따르니 이 일이 끝났다고 보는 경우가 많습니다. 옛 브라우저 이야기로 들려서 그렇습니다. 실제로는 차이의 성격이 바뀌었을 뿐입니다. 예전에는 표준을 안 지켜서 달랐고 지금은 표준의 새 부분을 구현한 시점이 서로 달라서 다릅니다. 새 기능일수록 격차가 크고, 프론트엔드가 새 문법을 빨리 쓸수록 이 문제를 자주 만납니다.

모든 브라우저에서 화면이 똑같아야 한다는 생각도 흔합니다. 이렇게 잡으면 목표가 끝나지 않습니다. 실제 기준은 같은 그림이 아니라 같은 일을 할 수 있는가입니다. 그림자 모양이 조금 다른 것은 아무도 두 브라우저를 나란히 놓고 보지 않으므로 문제가 되지 않고, 가입 버튼이 눌리지 않거나 결제 금액이 가려지는 것은 한 명에게도 치명적입니다. 픽셀을 맞추는 데 이틀을 쓰는 대신 그 시간을 주요 흐름 확인에 쓰는 편이 낫습니다.