정적 생성

화면을 누가 그리느냐에 따라 값이 달라집니다. 클라이언트 렌더링은 빈 HTML을 먼저 내려 주고 브라우저가 자바스크립트를 받아 실행한 다음에 내용을 그립니다. 브라우저에서 그리니 서버 부담은 적지만, 사용자는 흰 화면을 몇 초 보고 검색 봇은 내용 없는 문서를 가져갑니다.

서버 렌더링은 요청이 올 때마다 서버가 완성된 HTML을 만들어 보냅니다. 첫 화면이 빠르고 봇도 내용을 봅니다. 대신 요청 하나마다 서버가 데이터베이스를 조회하고 문서를 조립합니다.

페이지덱의 도움말 문서에서 이 방식의 낭비가 드러났습니다. 문서가 400개였고 내용은 한 주에 한두 건 고쳐졌습니다. 그런데 방문이 하루 3만 건이었으니, 서버는 같은 문서를 3만 번 다시 조립하고 있었습니다. 3만 번 중 내용이 달랐던 경우는 몇 건도 안 됐습니다.

그래서 시점을 옮겼습니다. 어차피 결과가 같다면 요청이 올 때가 아니라 배포할 때 한 번 만들어 두면 됩니다. 정적 생성은 그 한 번을 빌드 시점에 몰아 두는 방식입니다.

빌드할 때 페이지마다 HTML 파일을 만들어 두고, 요청이 오면 파일을 그대로 보냅니다. 순서는 다섯 단계입니다.

1. 만들 주소 목록을 정합니다. 파일 구조에서 자동으로 뽑거나, 목록을 돌려주는 함수를 적어 둡니다. 도움말 문서 400개라면 여기서 주소 400개가 나옵니다.
2. 주소마다 필요한 데이터를 가져옵니다. 데이터베이스 조회나 외부 서비스 호출이 여기서 일어납니다. 이 단계가 빌드 중에 끝나므로 실제 요청 시각에는 조회가 없습니다.
3. 페이지를 그려 파일로 씁니다. 결과는 완성된 HTML이고, 화면이 나중에 쓸 데이터를 따로 JSON 파일로 함께 남기는 경우가 많습니다.
4. 결과물을 CDN에 올립니다. CDN은 파일을 사용자와 가까운 거점에서 내려 주는 배포망입니다. 정적 파일이라 서버 없이도 배포가 끝납니다.
5. 브라우저가 HTML을 먼저 그리고, 뒤이어 자바스크립트가 붙어 버튼과 입력이 동작하게 됩니다. 이 붙는 과정을 하이드레이션이라고 부릅니다.

여기서 나오는 제약이 하나 있습니다. 내용이 바뀌면 다시 빌드해야 합니다. 오타 한 글자를 고치려고 전체를 다시 굽게 되고, 그 시간은 페이지 수에 거의 비례합니다. 400개면 1분이지만 5만 개면 40분이 넘어갑니다.

빌드가 길어지면 배포가 무서워집니다. 고칠 것이 생겨도 40분을 기다려야 하니 여러 수정을 모아서 한 번에 올리게 되고, 그러면 문제가 생겼을 때 어느 수정 때문인지 가리기 어려워집니다. 이 문제를 겨냥한 방식이 증분 정적 생성입니다.

누가 보든 같은 내용이고 자주 바뀌지 않는 페이지가 대상입니다.

1. 문서와 도움말 — 내용이 사용자마다 다르지 않고, 검색으로 들어오는 비율이 높습니다.
2. 마케팅 페이지와 블로그 — 첫 화면 속도가 곧 이탈률이고, 검색 노출이 유입의 절반을 넘습니다.
3. 용어 사전이나 목록형 자료 — 페이지 수가 많고 각 페이지가 독립적입니다.
4. 제품 소개와 가격 안내 — 분기에 한 번 바뀌는 정도입니다.

테크니컬 SEO 쪽에서 이 방식을 선호하는 이유가 분명합니다. 테크니컬 SEO는 검색 엔진이 사이트를 잘 읽게 만드는 기술 작업입니다. 봇이 받는 문서에 내용이 이미 들어 있으니 자바스크립트 실행을 기다릴 필요가 없고, 수집 여력을 아낄 수 있습니다.

반대로 안 맞는 자리는 사용자마다 화면이 달라지는 곳입니다. 로그인한 사람의 대시보드, 재고나 가격처럼 분 단위로 바뀌는 값, 검색 결과처럼 조건 조합이 무한한 화면이 여기 해당합니다. 미리 만들어 둘 수가 없거나, 만들어 둔 순간 낡기 시작합니다.

실제로는 한 제품 안에서 페이지마다 방식을 다르게 씁니다. 도움말은 정적으로 굽고 대시보드는 요청 때 그리고, SPA처럼 한 화면 안에서 내용을 갈아 끼우는 구간은 브라우저에 맡깁니다.

"도움말은 정적 생성으로 돌리죠. 하루 3만 요청을 매번 그릴 이유가 없어요."

내용이 같은 페이지를 반복해 조립하지 말자는 제안입니다.

"오타 하나 고치는데 빌드가 40분이에요. 이건 다른 방식이 필요합니다."

페이지 수가 많아 재빌드 비용이 감당하기 어려워졌다는 뜻입니다.

"가격 페이지를 정적으로 뺐는데 환율이 반영이 안 되네요."

미리 만들어 둔 값이 낡았다는 지적입니다.

페이지덱은 도움말과 블로그와 템플릿 갤러리를 정적으로 굽고 있습니다. 태오가 처음 옮긴 것은 도움말 400개였고, 서버 응답 시간이 240밀리초에서 20밀리초로 떨어졌습니다. 파일을 그대로 보내는 것이라 서버가 하는 일이 사실상 없어졌기 때문입니다.

문제는 갤러리를 8,000개까지 늘린 뒤에 나왔습니다. 빌드가 14분이 되면서 급한 수정이 있을 때 불편해졌습니다. 현우가 문안 한 줄을 고치는 데 14분을 기다려야 했고, 그 김에 다른 수정까지 모아 올리다 보니 무엇이 무엇을 깼는지 알기 어려워졌습니다. 그래서 갤러리만 필요할 때 다시 굽는 방식으로 옮겼습니다.

정적이라는 말 때문에 동적인 기능을 못 쓴다고 읽는 경우가 가장 많습니다. HTML 파일을 미리 만든다니 움직이지 않는 페이지처럼 들립니다. 하지만 미리 만들어지는 것은 첫 화면의 HTML뿐이고, 그 위에 자바스크립트가 붙으면 검색창도 지도도 장바구니도 그대로 동작합니다. 정적 페이지에서 로그인 상태를 보여 주거나 댓글을 받는 일도 됩니다. 그런 부분만 화면이 뜬 뒤에 따로 불러오면 됩니다.

언제나 가장 빠른 방식이라고 보는 것도 흔합니다. 요청 시각에 할 일이 없으니 그렇게 보입니다. 하지만 이 말이 성립하는 범위는 페이지 수가 관리 가능하고 내용이 자주 안 바뀌는 경우입니다. 페이지가 수만 개를 넘어가면 배포 주기가 길어지는 값을 치르게 되고, 값이 자주 바뀌는 페이지에서는 사용자가 낡은 내용을 보게 됩니다. 빠른 쪽을 고르는 문제가 아니라 페이지마다 무엇을 포기할지 정하는 문제입니다.