압축

회선이 좁던 시절에 화면이 늦게 뜨는 이유는 단순했습니다. 보낼 것은 많고 길은 좁았습니다. 그런데 보내는 것을 뜯어 보면 낭비가 눈에 띄었습니다. 웹 페이지를 이루는 파일은 대부분 글자로 되어 있습니다. 화면의 뼈대를 적은 문서, 색과 간격을 적은 스타일 파일, 동작을 적은 스크립트가 모두 사람이 읽고 고치라고 만든 글자 덩어리입니다. 그리고 그 안에는 같은 말이 수백 번씩 되풀이됩니다. 스타일 파일 하나에 margin 이라는 단어가 삼백 번 들어가는 일이 예사입니다.

받는 쪽이 원래 글자를 되살릴 수만 있다면, 되풀이되는 자리를 짧은 기호로 바꿔 보내도 결과는 같습니다. 이 착안에서 나온 것이 압축입니다. 보내기 직전에 줄이고 받자마자 되돌리기 때문에 사용자는 줄여서 보냈다는 사실조차 모릅니다.

이 말을 모르는 팀에서는 지금도 같은 장면이 되풀이됩니다. 페이지덱에서 태오가 스크립트 용량을 줄이려고 코드에서 지울 것을 찾다가 하루를 씁니다. 1.2메가바이트를 1.1메가바이트로 만들어 놓으면 다음 기능을 붙이는 순간 다시 1.2메가바이트가 됩니다. 그동안 지현은 왜 아직도 느리냐고 묻습니다. 정작 그 파일은 코드를 한 줄도 고치지 않고 서버 설정 한 줄로 300킬로바이트가 될 수 있었습니다.

붙이는 순서는 재고, 고르고, 어디서 줄일지 정하고, 다시 재는 네 박자입니다. 코드를 고치는 일이 아니라 서버나 배포 설정을 바꾸는 일이라서, 개발자 한 명이 반나절이면 끝내는 작업에 속합니다.

1. 지금 무엇이 얼마나 오가는지 잽니다. 브라우저의 개발자 도구에서 네트워크 탭을 열면 파일마다 실제로 전송된 크기가 나옵니다. 응답에 따라온 content-encoding 표시가 있으면 이미 압축되어 나가는 중이고, 없으면 원본 그대로 나가고 있는 것입니다.
2. 방식을 고릅니다. gzip 은 어디서나 통하는 기본값이고, brotli 는 같은 파일을 15에서 20퍼센트쯤 더 줄이는 대신 줄이는 데 시간이 더 듭니다.
3. 어디에서 줄일지 정합니다. 바뀌지 않는 파일은 배포할 때 미리 줄여 두고, 사용자마다 달라지는 응답은 내보내는 순간에 줄입니다. 앞쪽은 배포 시간만 늘어나므로 압축률을 최대로 올려도 되고, 뒤쪽은 요청마다 계산이 붙으므로 중간에서 멈춥니다.
4. 대상을 정합니다. 글자로 된 파일만 목록에 넣고 사진이나 동영상은 뺍니다. 이유는 다음 절에 있습니다.
5. 다시 재서 확인합니다. 전송 크기가 줄었는지, 그리고 요청 후 첫 바이트가 도착하기까지 걸린 시간인 TTFB가 늘지 않았는지 함께 봅니다. 크기는 줄었는데 첫 바이트가 늦어졌다면 3번에서 압축률을 너무 높게 잡은 것입니다.

페이지덱의 실제 숫자로 보면 이렇습니다. 여러 파일을 배포용으로 묶어 주는 도구인 번들러가 내놓은 스크립트가 1.1메가바이트였고, gzip 을 켜자 320킬로바이트, brotli 로 바꾸자 270킬로바이트가 되었습니다. 느린 모바일 회선에서 7초쯤 걸리던 내려받기가 2초 안쪽으로 줄었고, 가장 큰 덩어리가 그려지기까지 걸린 시간인 LCP도 함께 내려갔습니다.

잘 듣는 자리는 글자로 된 파일입니다. 스크립트, 스타일, 문서, 서버가 돌려주는 데이터 응답이 여기 속하고 대체로 원래 크기의 4분의 1에서 3분의 1까지 내려갑니다.

거의 듣지 않는 자리도 분명합니다. 사진과 동영상은 그 형식 자체가 이미 압축된 결과물이라 한 번 더 줄일 여지가 남아 있지 않습니다. 그래서 이미지 용량을 줄이는 일은 여기가 아니라 이미지 최적화가 따로 맡습니다.

한계는 셋입니다.

1. 아주 작은 파일은 대상이 아닙니다. 몇백 바이트짜리는 줄여 봐야 아낀 양이 처리 비용보다 작습니다. 보통 1킬로바이트 미만은 건드리지 않게 걸러 둡니다.
2. 계산 비용이 듭니다. 사용자마다 달라지는 응답은 요청이 올 때마다 줄여야 하고, 그 시간만큼 첫 바이트가 늦어집니다. 한 번 만든 결과를 저장해 두고 재사용하는 캐싱이나 자원을 사용자 가까운 거점에서 내려 주는 CDN과 함께 쓰면 같은 응답을 반복해서 줄이는 낭비를 없앨 수 있습니다.
3. 보낼 것 자체를 줄여 주지는 않습니다. 아무도 쓰지 않는 코드 300킬로바이트는 압축해도 90킬로바이트가 되어 함께 실려 갑니다. 안 쓰는 것을 빼는 일과 당장 필요 없는 것을 나중에 부르는 지연 로딩은 여전히 따로 해야 합니다.

"이거 압축 걸린 거 맞아요? 응답 헤더에 아무것도 안 보이는데요."

서버가 원본을 그대로 내보내고 있다는 지적입니다. 설정 한 줄이 빠졌을 가능성이 큽니다.

"brotli 로 바꾸면 50킬로바이트는 더 줄어요. 대신 빌드가 2분 늘어납니다."

압축률과 배포 시간을 맞바꾸자는 제안입니다. 받아들일지는 배포를 하루에 몇 번 하는지에 달려 있습니다.

"이미지는 압축해 봐야 소용없어요. 그쪽은 다른 방법으로 가야 합니다."

파일 종류를 구분하지 않고 설정을 걸어 둔 상황을 바로잡는 말입니다.

페이지덱에서는 첫 화면이 느리다는 이야기가 나올 때마다 이 순서를 밟습니다. 지현이 지표를 들고 와서 모바일에서 화면이 뜨는 데 5초가 걸린다고 말하면, 태오가 네트워크 탭을 열어 무엇이 가장 큰지부터 봅니다. 스크립트가 1메가바이트를 넘는데 압축 표시가 없으면 그날 안에 켭니다. 이미 켜져 있으면 다음 후보로 넘어갑니다.

압축하면 내용이 나빠진다고 생각하는 경우가 가장 많습니다. 사진을 줄이면 흐려지는 경험이 있으니 자연스러운 오해입니다. 하지만 웹에서 파일을 보낼 때 쓰는 압축은 되돌리면 원본과 한 바이트도 다르지 않은 방식입니다. 이 오해를 그대로 두면 켜면 되는 설정을 위험하다고 여겨 미뤄 두게 됩니다.

전송 크기가 줄었으니 무거운 화면 문제가 풀렸다고 보는 것도 흔합니다. 네트워크 탭의 숫자가 1.1메가바이트에서 320킬로바이트로 바뀌니 그렇게 보입니다. 그러나 브라우저는 받은 것을 되돌린 뒤 1.1메가바이트어치를 해석하고 실행합니다. 줄어든 것은 길 위에 있던 시간이지 기기가 하는 일이 아닙니다. 그대로 두면 회선이 빠른 사무실에서는 멀쩡한데 낡은 휴대폰에서는 눌러도 반응이 없는 상태가 남습니다.