서버 렌더링

화면을 브라우저에서 그리는 방식이 한동안 기본이었습니다. 서버는 거의 빈 문서와 스크립트만 내려 주고, 브라우저가 그 스크립트를 실행해 데이터를 받아 화면을 채웁니다. 화면을 옮겨 다닐 때 페이지가 새로 뜨지 않아 앱처럼 매끄럽게 움직이는 것이 이 방식의 값어치입니다.

대신 첫 화면에서 값을 치릅니다. 사용자는 스크립트를 내려받고 실행하고 데이터를 받아 오는 동안 빈 화면을 봅니다. 회사 노트북과 빠른 연결에서는 0.4초라 아무도 눈치채지 못하는데, 몇 년 된 휴대폰과 느린 연결에서는 같은 화면이 3초 넘게 비어 있습니다. 검색 봇이 그 빈 문서를 읽고 지나가는 문제도 함께 있었습니다. 검색 결과에 제목만 걸리고 내용이 없는 상태가 이렇게 생깁니다.

서버 렌더링은 그 순서를 뒤집은 방식입니다. 요청이 올 때 서버가 데이터를 넣어 문서를 완성해 보내므로, 브라우저는 받은 즉시 글자를 보여 줄 수 있습니다. 스크립트는 그다음에 내려와 동작을 입힙니다.

요청마다 서버가 화면을 그려 보내고, 브라우저가 그 위에 동작을 얹습니다. 순서는 넷입니다.

1. 브라우저가 주소를 요청합니다. 서버는 그 화면에 필요한 데이터를 데이터베이스에서 꺼내 문서 안에 넣고, 글자와 구조가 다 들어간 문서를 만들어 보냅니다.
2. 브라우저가 받은 문서를 그대로 그립니다. 이 시점에 사용자는 내용을 읽을 수 있습니다. 가장 큰 콘텐츠가 그려지기까지 걸린 시간을 재는 LCP가 짧아지는 이유가 여기 있습니다.
3. 스크립트가 내려와 동작을 입힙니다. 서버가 그린 화면에 눌림과 입력을 붙이는 이 과정을 하이드레이션이라고 합니다.
4. 그 이후의 화면 이동은 브라우저가 처리합니다. 첫 화면만 서버에서 그리고 나머지는 브라우저 쪽에서 도는 형태가 실무의 기본값입니다.

2번과 3번 사이에 구간이 하나 생깁니다. 글자는 보이는데 버튼은 아직 눌리지 않는 상태입니다. 사용자가 그 사이에 누르면 아무 일도 일어나지 않고, 이것이 서버 렌더링을 도입한 뒤 가장 자주 들어오는 문의입니다. 스크립트 크기를 줄이거나 화면 일부만 먼저 동작하게 나누는 방식으로 이 구간을 좁힙니다. 누르면 반응이 오도록 버튼을 잠시 비활성으로 두는 쪽을 택하는 팀도 있습니다.

값도 함께 따라옵니다. 요청마다 서버가 데이터베이스를 읽고 문서를 만들어야 해서 서버 비용과 응답 시간이 늘어납니다. 사람마다 다르지 않은 화면은 한 번 만든 결과를 저장해 두고 재사용하는 쪽으로 이 부담을 줄입니다. 방문자가 몰리는 페이지일수록 이 저장이 서버 비용을 크게 깎습니다.

검색에서 사람이 들어오는 페이지가 첫째입니다. 소개 페이지와 블로그 글, 가격 페이지처럼 검색 결과에서 눌려 들어오는 자리입니다. 검색 결과에서 잘 잡히게 사이트를 다듬는 검색 엔진 최적화를 하는 페이지라면 내용이 문서 안에 들어 있는 편이 안전합니다.

둘째는 첫 화면 속도가 결과에 바로 붙는 자리입니다. 광고를 눌러 들어온 사람은 빈 화면을 3초 보는 동안 절반이 나갑니다. 광고비를 쓰는 페이지에서 이 방식을 먼저 적용하는 이유가 여기 있습니다. 클릭당 800원을 내고 데려온 사람이 화면을 보기 전에 나가면 그 돈은 그대로 사라집니다.

셋째는 사람마다 내용이 다른 화면입니다. 로그인한 사용자의 문서 목록처럼 요청 시점에야 무엇을 보여 줄지 정해지는 화면은 미리 만들어 둘 수 없습니다. 빌드 때 페이지를 만들어 두는 방식으로는 다룰 수 없고, 요청마다 그리는 이 방식이 그 자리를 맡습니다.

반대로 맞지 않는 자리도 분명합니다. 로그인 뒤에만 쓰는 사내 관리 도구는 검색과 무관하고, 한 화면에서 값을 계속 바꿔 가며 쓰는 성격이라 브라우저 쪽에서 그리는 편이 단순합니다. 이때 서버 렌더링을 얹으면 서버 비용과 구조의 복잡함만 늘어납니다. 얻는 것이 없는 자리에 값을 치르는 셈입니다.

"이 페이지는 서버 렌더링으로 가죠. 유입의 절반이 검색이에요."

검색 유입이 근거라는 판단입니다.

"하이드레이션 전에 누르면 아무 일도 안 일어나요."

보이는 시점과 눌리는 시점이 다르다는 지적입니다.

"서버 렌더링으로 바꾼 뒤 서버 비용이 40퍼센트 올랐어요."

속도를 얻는 대가가 어디로 갔는지 보고하는 말입니다.

페이지덱이 소개 페이지와 블로그를 서버 렌더링으로 옮긴 것은 현우가 검색 유입 자료를 가져온 뒤였습니다. 검색으로 들어온 사람의 첫 화면이 채워지기까지 2.8초가 걸리고 있었고, 그중 3분의 1이 화면을 보기 전에 나가고 있었습니다.

태오는 두 영역만 옮기고 로그인 뒤 화면은 그대로 두었습니다. 옮긴 뒤 첫 화면 시간은 0.9초가 됐고 이탈은 눈에 띄게 줄었습니다. 서버 비용은 올랐지만, 사람마다 다르지 않은 페이지라 결과를 저장해 재사용하는 방식으로 그 증가분의 대부분을 걷어냈습니다. 같은 방식을 로그인 뒤 화면에 적용할 수는 없었습니다.

서버 렌더링이 언제나 더 빠르다고 읽는 경우가 가장 많습니다. 첫 글자가 빨리 보이는 것은 사실이라 그렇게 느껴집니다. 하지만 빨라지는 것은 보이기까지의 시간이고, 눌리기까지의 시간은 오히려 늦어질 수 있습니다. 서버가 그린 문서 위에 같은 양의 스크립트를 다시 내려 동작을 입히기 때문입니다. 지표를 하나만 보고 판단하면 사용자가 겪는 것과 어긋난 결론이 나옵니다.

검색 문제의 해답으로 보는 것도 흔합니다. 봇이 빈 문서를 읽는 사례가 알려져 있어 자연스러운 기대입니다. 그런데 요즘 주요 검색 봇은 스크립트를 실행해 화면을 채운 뒤 읽습니다. 순위가 오르지 않는 이유가 내용이 얇거나 같은 주제의 페이지가 겹쳐 있는 것이라면 렌더링 방식을 바꿔도 달라지지 않습니다. 이 방식이 확실히 돕는 것은 봇이 실행을 건너뛰는 경우와 링크 미리보기처럼 스크립트를 돌리지 않는 자리입니다.