폴리필

웹에서는 만드는 쪽이 실행 환경을 고를 수 없습니다. 같은 코드가 사용자의 브라우저에서 돌고, 그 브라우저가 무엇인지는 사용자가 정합니다. 새 기능이 표준에 들어가도 브라우저들이 그것을 구현하기까지 몇 년이 걸리고, 이미 구현된 뒤에도 옛 버전을 그대로 쓰는 사람이 한참 남습니다.

그래서 선택지가 둘뿐이었습니다. 하나는 새 기능을 아예 쓰지 않는 것입니다. 안전하지만 같은 일을 열 줄로 쓰게 되고 몇 년 전 방식으로만 코드가 쌓입니다. 다른 하나는 브라우저마다 다른 길을 코드에 박아 두는 것입니다. 이쪽은 곧 무너집니다. 같은 기능을 세 가지 방식으로 나눠 쓴 조건문이 파일 열두 곳에 흩어지고, 새 브라우저가 나오면 그 열두 곳을 다 찾아 고쳐야 합니다.

폴리필은 세 번째 길입니다. 없는 기능을 우회하는 대신 직접 구현해 원래 있던 것처럼 채워 넣습니다. 그러면 나머지 코드는 브라우저를 신경 쓰지 않고 그 기능을 그냥 씁니다. 분기가 한 곳으로 모이고 나머지 열두 곳이 깨끗해집니다.

없는 기능을 있는 것처럼 만들어 두는 일이 전부이고, 그 덕에 나머지 코드가 조건문을 들고 있지 않아도 됩니다. 절차는 넷입니다.

1. 있는지 없는지를 기능으로 확인합니다. 브라우저 이름이나 버전으로 판단하지 않습니다. 이름으로 갈래를 짜면 새 브라우저가 나올 때마다 고쳐야 하지만, 기능이 있는지 물어보는 방식은 목록이 필요 없습니다.
2. 없으면 같은 이름으로 구현해 끼워 넣습니다. 이름과 동작을 표준과 똑같이 맞춰야 합니다. 이름은 같은데 동작이 다르면 지원하는 브라우저와 그렇지 않은 브라우저에서 결과가 갈립니다.
3. 나머지 코드는 분기 없이 그 기능을 씁니다. 여기가 이 도구의 값입니다. 브라우저 대응이 파일 한 곳에 모이고, 자바스크립트로 쓴 나머지 코드는 표준 문서만 보고 짜면 됩니다.
4. 지원이 충분해지면 걷어냅니다. 필요 없어진 폴리필은 지워야 할 코드이고, 이 마지막 단계를 빼먹는 팀이 많습니다.

내려받는 양이 늘어난다는 대가가 붙습니다. 폴리필 묶음이 60킬로바이트면 모든 사용자가 그만큼 더 받습니다. 실제로 필요한 사용자가 전체의 2퍼센트라면 98퍼센트가 쓰지 않을 코드를 받는 셈이고, 이 차이는 화면이 뜨는 속도에 그대로 나타납니다. 그래서 웹 성능을 볼 때 이 묶음이 자주 지목되고, 필요한 브라우저에만 따로 내려보내는 방식을 함께 씁니다.

메울 수 없는 것도 분명합니다. 새로 생긴 문법은 이 방식으로 채우지 못합니다. 브라우저가 그 문법을 읽지 못하면 폴리필이 담긴 파일 자체를 읽다가 멈추기 때문입니다. 문법은 코드를 옛 형태로 바꿔 쓰는 쪽이 맡습니다.

대안은 넷이고, 무엇을 포기하는지로 갈립니다.

첫째는 문법을 옛 형태로 바꿔 쓰는 것입니다. 새 문법으로 쓴 코드를 빌드할 때 옛 문법으로 옮겨 내보냅니다. 여러 파일을 배포용으로 묶는 번들러가 대개 이 일을 함께 하니, 설정에 지원 대상 브라우저를 적어 두면 나머지는 자동입니다. 폴리필과 겹치지 않고 짝으로 씁니다. 문법은 이쪽이, 기능은 폴리필이 맡습니다.

둘째는 그 기능을 쓰지 않는 것입니다. 가장 싸고 가장 자주 맞는 답입니다. 새로 나온 편한 기능 대신 10년째 모든 브라우저가 지원하는 기능으로 같은 일을 하면, 내려받는 양도 늘지 않고 나중에 걷어낼 코드도 남지 않습니다.

셋째는 없는 쪽을 그대로 두는 것입니다. 환경이 열악해도 핵심 기능은 남게 만드는 방식을 그레이스풀 디그러데이션이라 하고, 옛 브라우저에서는 부드러운 전환이나 자동 저장 같은 곁가지만 빠지게 둡니다. 문서를 읽고 쓰는 일은 그대로 되니, 2퍼센트를 위해 98퍼센트가 무거운 파일을 받는 상황을 피할 수 있습니다.

넷째는 지원 목록을 좁히는 것입니다. 접속 기록에서 해당 브라우저 비율이 0.3퍼센트 아래로 떨어졌다면 지원을 끊는 결정이 가능합니다. 필요한 것은 기술 판단이 아니라 숫자와 합의입니다.

"이건 폴리필로 못 메워요. 문법이라서 빌드에서 바꿔야 합니다."

기능과 문법이 다른 문제라는 지적입니다.

"이 묶음 60킬로바이트인데 필요한 사용자가 2퍼센트예요."

받는 비용과 혜택 보는 비율이 어긋난다는 말입니다.

"3년 전에 넣은 폴리필이 아직 들어 있어요. 지금은 다 지원합니다."

걷어내는 단계를 빼먹었다는 뜻입니다.

페이지덱 프론트엔드에서 태오가 이 목록을 반년에 한 번 정리합니다. 접속 기록에서 브라우저 비율을 뽑아 지원 목록을 갱신하고, 필요 없어진 폴리필을 지웁니다. 지난번에는 넷 중 셋이 빠져 내려받는 양이 48킬로바이트 줄었습니다.

남긴 하나는 기업 고객 때문입니다. 보안 정책으로 브라우저를 올리지 못하는 고객사가 한 곳 있었고, 계약 금액이 커서 끊을 수 없었습니다. 태오가 그 폴리필만 조건에 맞는 브라우저에서 따로 내려받도록 고쳐, 나머지 사용자는 받지 않게 했습니다.

폴리필이 브라우저 사이의 모든 차이를 메워 준다고 읽는 경우가 가장 많습니다. 이름 그대로 빈 곳을 채운다는 뜻이니 자연스러운 오해입니다. 실제로 채울 수 있는 것은 함수나 객체처럼 코드로 구현할 수 있는 기능뿐입니다. 문법은 앞에서 본 대로 못 채우고, 화면을 그리는 방식의 차이도 마찬가지입니다. 새로 생긴 배치 규칙을 지원하지 않는 브라우저에서 그 배치를 폴리필로 되살리는 일은 사실상 불가능하고, 그 영역은 크로스 브라우저 작업으로 따로 다룹니다. 다 메워질 것으로 보고 새 기능을 자유롭게 쓴 팀은 배포 직전에 절반을 다시 짜게 됩니다.

넣어 두면 끝이라고 보는 시각도 자주 나옵니다. 한 번 넣으면 조용히 동작하고 아무 문제도 일으키지 않으니 잊힙니다. 그런데 이 코드의 수명은 브라우저 지원 현황에 매여 있고, 현황은 1년이면 크게 바뀝니다. 3년 전에 넣은 폴리필 네 개가 지금은 전부 필요 없는 상태인데도 모든 사용자에게 내려가고 있는 일이 드물지 않습니다. 반년이나 1년에 한 번 지원 목록을 다시 뽑아 필요 없어진 것을 지우는 일정을 잡아 두는 편이 낫습니다. 정리를 하지 않으면 내려받는 양이 해마다 늘기만 합니다.