클라이언트 렌더링

초기의 웹에서는 화면을 만드는 일이 전부 서버 몫이었습니다. 주소를 누르면 서버가 완성된 HTML 문서를 통째로 만들어 내려보내고, 브라우저는 받은 것을 그대로 펼쳐 보여 줬습니다. 문서를 읽는 용도라면 모자란 점이 없는 구조입니다.

문제는 화면 안에서 무언가를 조작하면서 드러났습니다. 댓글 하나를 달면 페이지 전체가 다시 그려졌습니다. 바뀐 것은 목록 한 줄인데 머리글도 옆 메뉴도 이미 읽은 본문도 전부 다시 받았습니다. 화면은 하얗게 비워졌다 다시 채워지고 읽던 위치는 맨 위로 돌아갔습니다. 지도를 조금 끌어 움직일 때마다 이 일이 벌어진다고 생각하면 서버가 화면을 만드는 방식으로는 만들 수 없는 제품이 있다는 것이 분명해집니다.

클라이언트 렌더링은 그리는 일을 서버에서 브라우저로 옮긴 방식입니다. 서버는 완성된 화면 대신 재료만 보냅니다. 화면을 구성할 줄 아는 자바스크립트 코드와 거기 채워 넣을 데이터이고, 조립은 브라우저가 합니다. 그러면 댓글이 하나 늘었을 때 새 댓글 한 건만 요청해 목록 부분만 고쳐 그립니다. 화면이 비워지는 구간도, 스크롤이 튀는 일도 없습니다.

브라우저가 문서를 받고 코드를 내려받아 실행한 다음, 데이터를 요청해 화면을 그리는 순서로 진행됩니다. 실제로 일어나는 일은 다섯 단계입니다.

1. 서버가 거의 비어 있는 문서를 내려보냅니다. 본문에는 내용을 채워 넣을 빈 자리 하나와, 불러올 코드 파일의 주소만 적혀 있습니다. 이 시점에 화면에는 아무것도 없습니다.
2. 브라우저가 그 코드 파일을 내려받습니다. 화면을 만드는 규칙 전체가 여기 들어 있어서 크기가 수백 킬로바이트에서 수 메가바이트에 이릅니다.
3. 내려받은 코드를 실행합니다. 이 코드가 DOM, 즉 브라우저가 문서를 코드로 다룰 수 있게 만들어 둔 구조를 조작해 화면 요소를 하나씩 만들어 붙입니다.
4. 필요한 데이터를 서버에 따로 요청합니다. 문서 목록, 로그인한 사람의 정보처럼 사람마다 다른 값은 이 단계에서 받아 옵니다. 받아 온 값으로 빈 자리를 채우면 그제야 화면이 완성됩니다.
5. 이후의 화면 이동은 서버에 문서를 다시 요청하지 않습니다. 필요한 데이터만 받아 바뀐 부분을 고쳐 그립니다. 한 문서 안에서 화면을 갈아 끼우는 이 방식이 SPA입니다.

1번에서 4번까지가 끝나야 사용자가 뭔가를 봅니다. 회선이 느리면 이 구간이 3초를 넘기고, 그동안 화면에는 흰 바탕이나 회전하는 표시만 있습니다. 첫 진입의 값을 치르고 그 뒤의 이동을 빠르게 얻는 맞바꿈입니다.

값을 줄이는 방법은 코드 파일을 쪼개는 것입니다. 코드 스플리팅은 전체 코드를 처음에 다 주는 대신 각 화면에 들어갈 때 그 몫만 나눠 받게 합니다. 설정 화면에 한 번도 들어가지 않는 사용자가 그 코드까지 첫 로딩에 받는 일을 막아 줍니다.

로그인 뒤에서 오래 머무르며 조작이 잦은 화면에 잘 맞습니다. 관리자 도구, 대시보드, 문서 편집기, 지도처럼 한 번 들어와 30분을 머물면서 수십 번 화면을 옮기는 곳입니다. 첫 진입에 2초를 더 쓰고 이후 수십 번의 이동에서 0.5초씩 아끼면 전체 경험은 낫습니다. 검색 노출을 고려할 필요가 없다는 점도 맞아떨어집니다.

반대로 세 가지 상황에서는 한계가 드러납니다.

1. 첫 화면의 속도가 곧 성과인 곳. 광고를 눌러 들어온 사람은 2초가 넘어가면 상당수가 뒤로 갑니다. 상품 상세나 마케팅 페이지가 여기 해당합니다.
2. 검색과 공유가 중요한 곳. 검색 엔진의 수집기가 자바스크립트를 실행하기는 하지만 순서가 뒤로 밀리고 결과가 매번 같지 않습니다. 메신저의 링크 미리보기는 문서의 첫 내용만 읽으므로, 빈 문서를 내려보내면 제목도 이미지도 잡히지 않습니다.
3. 기기 성능이 고르지 않은 곳. 코드를 실행하는 주체가 사용자 기기라서, 서버를 아무리 늘려도 4년 된 보급형 휴대폰에서 느린 것은 그대로입니다.

그래서 실제 제품은 한 방식으로 통일하지 않고 화면마다 다르게 고릅니다. 공개된 소개 페이지는 빌드 시점에 미리 만들어 두는 정적 생성으로, 자주 바뀌는 목록 페이지는 바뀐 것만 다시 굽는 증분 정적 생성으로, 로그인 뒤의 작업 화면은 클라이언트 렌더링으로 두는 식입니다.

"이 화면은 로그인 뒤에만 보이니까 클라이언트 렌더링으로 갑시다."

검색 노출을 포기해도 되는 자리라 첫 화면 지연을 감수하자는 말입니다.

"번들이 1.8메가예요. 첫 화면 뜨는 데 4초 걸립니다."

내려받고 실행할 코드가 너무 커졌으니 쪼개자는 뜻입니다.

"링크 미리보기에 제목이 안 떠요. 빈 문서를 내려보내고 있어서요."

화면을 브라우저가 그리는 탓에 문서만 읽는 쪽에서는 내용이 보이지 않는다는 말입니다.

페이지덱에서 이 선택이 갈린 자리는 문서 공유 링크였습니다. 편집 화면은 처음부터 클라이언트 렌더링입니다. 문단을 고칠 때마다 서버를 다녀올 수는 없기 때문입니다. 그런데 문서를 외부에 공개하는 링크를 열자, 현우가 메신저에 붙여 본 링크에 제목도 미리보기도 뜨지 않았습니다.

태오가 확인한 원인은 간단했습니다. 공유 링크가 편집 화면과 같은 빈 문서를 내려보내고 있었고, 메신저는 코드를 실행하지 않고 문서만 읽었습니다. 편집 화면은 그대로 두고 공유 화면만 서버가 미리 그려 내려보내도록 바꿔 해결했습니다.

클라이언트 렌더링이 느린 방식이라고 뭉뚱그려 읽는 경우가 가장 많습니다. 첫 화면이 늦게 뜨는 것을 직접 겪으면 그렇게 느껴집니다. 하지만 느린 것은 첫 진입 한 번이고, 그 뒤의 화면 이동은 서버를 다녀오지 않으니 오히려 빠릅니다. 이 구분을 놓치면 30분씩 머무는 관리자 도구를 첫 화면 0.3초 때문에 서버 렌더링으로 옮기고, 하루에 수십 번 겪는 화면 전환을 매번 느리게 만듭니다.

검색 노출이 아예 불가능하다고 아는 것도 흔합니다. 한동안 사실이었기에 남은 인식입니다. 지금은 주요 검색 엔진의 수집기가 코드를 실행해 그려진 결과를 읽습니다. 다만 실행은 첫 수집 뒤로 미뤄지고, 코드가 오래 걸리거나 중간에 실패하면 그 페이지는 빈 채로 기록됩니다. 불가능한 것이 아니라 결과를 보장할 수 없는 상태에 가깝습니다. 노출이 매출과 직결되는 페이지라면 그 불확실성을 떠안을 이유가 없습니다.