코드 스플리팅

예전에는 웹사이트의 자바스크립트가 페이지마다 따로 있었습니다. 자바스크립트는 버튼을 눌렀을 때 무엇이 열리는지처럼 브라우저에서 일어나는 동작을 만드는 언어입니다. 페이지를 옮길 때마다 문서를 통째로 다시 받았으니 받는 코드도 그 페이지 것뿐이었습니다.

SPA가 퍼지면서 이 구조가 뒤집혔습니다. SPA 는 문서 하나를 받아 두고 그 안에서 화면만 갈아 끼우는 방식이라 이동할 때 깜빡임이 없습니다. 대신 그 하나에 모든 화면의 코드가 들어갑니다. 서른 개 화면짜리 서비스라면 로그인만 하려는 사람도 관리자 설정과 통계 차트와 결제 내역 코드를 함께 받습니다.

페이지덱에서도 같은 일이 벌어졌습니다. 기능이 늘수록 첫 로딩 파일이 커졌고, 어느 시점부터 지하철에서 접속한 사용자는 빈 화면을 4초 넘게 봤습니다. 태오가 안을 들여다보니 그중 절반이 문서 안에 그래프를 넣을 때만 쓰는 차트 라이브러리였습니다. 전체 사용자의 3퍼센트만 쓰는 기능이 모두의 첫 화면을 붙잡고 있던 겁니다. 코드 스플리팅은 이 지점을 겨냥합니다. 받는 총량을 줄이는 대신 받는 시점을 나눕니다.

무엇이 큰지 재는 데서 시작합니다. 번들러는 수백 개로 나뉜 파일을 브라우저가 받기 좋은 몇 개로 묶어 주는 도구인데, 대부분 묶음 안에서 어느 코드가 몇 킬로바이트를 차지하는지 그림으로 보여 주는 기능을 함께 갖고 있습니다. 감으로 나누기 전에 이것부터 봅니다.

1. 첫 화면 묶음의 구성을 확인합니다. 보통 상위 서너 개가 전체의 절반을 넘게 차지합니다.
2. 가를 선을 정합니다. 기본은 경로 단위입니다. 설정 화면에 들어갈 때 설정 화면 코드를 받게 하는 식이고, 사용자가 화면을 옮기는 순간과 코드를 받는 순간이 겹쳐서 추가로 기다리는 느낌이 덜합니다.
3. 그 자리의 불러오기를 동적 형태로 바꿉니다. 코드 맨 위에서 미리 불러오던 것을 실제로 필요해지는 함수 안으로 옮기는 작업이고, 번들러는 이 표시를 보고 그 부분을 별도 파일로 떼어 냅니다.
4. 기다리는 동안 보여 줄 것을 정합니다. 조각을 받는 사이 화면이 비면 사용자는 눌린 게 맞는지 의심합니다. 자리를 잡아 둔 회색 틀이나 진행 표시를 넣습니다.
5. 받아 오지 못했을 때를 정합니다. 배포 직후에 옛 파일 이름을 들고 있던 브라우저는 조각을 못 찾습니다. 이때 화면이 멈추지 않도록 다시 시도하거나 새로고침을 안내하는 처리를 넣습니다.
6. 다시 잽니다. 첫 화면 전송량이 900킬로바이트에서 320킬로바이트로 줄었는지, LCP가 4.1초에서 2.3초로 내려왔는지 확인합니다. LCP 는 화면에서 가장 큰 요소가 그려지기까지 걸린 시간으로, 사용자가 체감하는 첫인상에 가장 가까운 값입니다.

화면이 많고 사용자가 그중 일부만 들르는 서비스에 가장 잘 맞습니다. 페이지덱처럼 문서 편집 화면에 대부분의 시간이 몰려 있고 설정·청구·관리자 화면은 가끔 열리는 구조가 전형적입니다. 무겁고 드물게 쓰는 기능도 좋은 후보입니다. 차트 라이브러리나 이미지 편집기처럼 큰 덩어리는 그 기능을 켜는 순간에 받게 두면 됩니다.

반대로 전체 묶음이 이미 작으면 효과가 없습니다. 200킬로바이트짜리를 넷으로 나누면 첫 화면은 조금 가벼워지지만 요청이 세 번 늘고, 그 왕복 시간이 아낀 시간을 대부분 먹습니다. 거의 모든 사용자가 곧장 들어가는 화면을 떼어 내는 것도 마찬가지입니다. 어차피 다 받을 코드를 두 번에 나눠 받게 만든 셈이 됩니다.

한계는 두 가지입니다. 하나는 잘게 자를수록 요청 수가 늘어난다는 점입니다. 조각을 60개로 만들면 화면 하나에 파일 열두 개를 순서대로 받아야 하고, 앞의 것을 받아야 뒤의 것을 요청할 수 있어서 기다림이 줄줄이 이어집니다. 다른 하나는 이동할 때마다 생기는 빈 순간입니다. 첫 화면에서 아낀 2초를 화면 전환마다 0.4초씩 돌려주는 모양이 되면 더 답답하게 느껴집니다. 그래서 다음에 갈 가능성이 높은 화면의 조각을 미리 받아 두는 처리를 함께 겁니다. 메뉴에 마우스를 올린 순간에 그 화면 조각을 받아 두면 실제로 누를 때는 이미 와 있습니다.

"첫 로딩에 차트 라이브러리가 통째로 들어가 있어요. 그래프 쓰는 사람만 받게 떼어 내죠."

전체 사용자가 소수만 쓰는 코드를 함께 받고 있으니 그 부분을 갈라 내자는 제안입니다.

"경로 단위로는 이미 나눠져 있고, 더 쪼개면 요청만 늘 것 같아요."

지금 구조에서 추가로 나누는 이득이 늘어나는 왕복 비용보다 작다는 판단입니다.

"쪼개는 건 좋은데 로딩 중에 뭘 보여 줄지부터 정하고 가시죠."

코드를 가르면 기다림이 화면에 드러나므로 그 자리의 표시를 먼저 설계하자는 말입니다.

페이지덱에서는 이 작업이 웹 성능 이야기의 첫 단계로 붙습니다. 지현이 "첫 화면이 느리다" 는 문의를 들고 오면 태오는 원인을 서버 쪽과 받는 코드 양 쪽으로 나눠 보고, 코드 양이 문제면 가장 큰 덩어리부터 떼어 냅니다.

이때 지현이 보는 것은 줄어든 킬로바이트가 아니라 사용자가 겪는 순서입니다. 첫 화면은 빨라졌는데 문서를 열 때마다 0.5초짜리 빈 화면이 새로 생겼다면 개선이 아니라 이동입니다. 두 사람의 대화는 대개 어느 화면의 기다림을 어느 화면으로 옮길지를 정하고 끝납니다.

받는 코드의 총량이 줄어든다고 읽는 경우가 가장 많습니다. 첫 화면 숫자가 900에서 320으로 떨어지니 그렇게 보입니다. 실제로 줄어드는 것은 처음 한 번에 받는 양뿐이고, 사용자가 모든 화면을 다 돌면 결국 900킬로바이트를 다 받습니다. 총량을 줄이는 것은 트리 셰이킹처럼 안 쓰는 코드를 걷어 내는 쪽이고 이건 시점을 나누는 쪽입니다. 둘을 섞으면 "나눴는데 왜 총 전송량이 그대로냐" 는 엉뚱한 진단이 나옵니다.

나누면 무조건 빨라진다고 읽는 것도 흔합니다. 성능 개선 기법으로 소개되니 자연스러운 기대입니다. 그런데 나누는 순간 요청 수와 화면 전환의 기다림이라는 새 비용이 생기고, 원래 묶음이 작거나 조각을 너무 잘게 냈다면 이 비용이 이득보다 큽니다. 재지 않고 나눈 팀은 첫 화면 0.3초를 줄이는 대신 화면 이동마다 0.4초를 새로 만들어 놓고, 문의가 늘어난 뒤에야 되돌립니다. 나누기 전후를 같은 조건에서 재는 것까지가 이 작업입니다.