페이지네이션

목록에 담길 항목이 스무 건이던 시절에는 나눌 이유가 없었습니다. 한 화면에 전부 그려 놓고 사용자가 눈으로 훑으면 끝이었습니다. 문제는 그 목록이 3,000건이 되는 순간부터 시작됩니다.

항목이 많아지면 세 군데가 동시에 막힙니다. 서버는 3,000건을 꺼내느라 응답이 늦고, 네트워크가 그 결과를 보내는 데 시간을 쓰고, 브라우저는 3,000줄을 그리느라 몇 초 멈춥니다. 목록이 열리는 데 8초가 걸리면 사용자는 같은 링크를 두 번 누릅니다.

더 답답한 쪽은 사용자가 정작 필요한 것이 그 3,000건 중 다섯 건이라는 점입니다. 찾는 문서는 대개 위쪽에 있고 아래 2,900건은 열리기만 기다렸다가 버려집니다.

해법은 목록을 끊는 것입니다. 화면에 들어갈 만큼만 가져오고, 사용자가 더 보겠다고 표시하면 그다음 묶음을 가져옵니다. 페이지네이션은 이 끊음을 쪽이라는 단위로 보이게 만든 요소입니다. 지금 몇 번째 쪽이고 전체가 몇 쪽인지가 화면에 드러납니다.

목록을 한 쪽에 담을 개수로 나누고, 화면이 서버에 요청할 때 어느 쪽이 필요한지를 함께 보냅니다. 한 쪽에 20개를 담고 사용자가 3쪽을 눌렀다면 41번째부터 60번째까지를 달라는 요청이 나갑니다.

어디부터 달라고 말하는 방법은 두 가지입니다.

1. 오프셋 방식 — 앞에서 몇 건을 건너뛸지를 숫자로 보냅니다. 3쪽이면 40건을 건너뛰고 20건을 달라고 합니다. 쪽 번호와 숫자가 곧바로 대응하니 7쪽으로 바로 뛰는 버튼을 만들 수 있고, 전체 건수를 세어 두면 몇 쪽인지도 보여 줄 수 있습니다.
2. 커서 방식 — 마지막으로 받은 항목의 위치를 표시로 들고 있다가 그 뒤부터 달라고 합니다. 건너뛰는 일이 없으니 목록이 길어도 속도가 일정하고 경계가 어긋나지 않습니다. 대신 바로 다음과 이전만 알 수 있어 쪽 번호를 붙일 수 없습니다.

오프셋 방식에는 뒤로 갈수록 느려지는 성질이 있습니다. 5,000쪽을 누르면 서버가 앞의 99,980건을 세고 나서 스무 건을 꺼냅니다. 목록이 도중에 바뀌는 문제도 있습니다. 1쪽을 본 뒤 누군가 새 항목을 맨 위에 넣으면 전체가 한 칸씩 밀려서, 2쪽에 1쪽 마지막 항목이 다시 나옵니다.

화면에 놓는 요소는 대개 넷입니다.

1. 쪽 번호 — 지금 쪽을 눈에 띄게 하고 앞뒤 두세 개를 함께 보여 줍니다. 쪽이 300개면 번호를 다 깔 수 없으니 첫 쪽과 마지막 쪽만 양끝에 남기고 가운데를 줄임표로 접습니다.
2. 이전·다음 — 한 칸씩 움직입니다. 첫 쪽에서 이전 버튼은 눌러도 안 되는 상태로 두고 없애지는 않습니다. 자리가 사라지면 나머지 버튼이 옆으로 밀립니다.
3. 전체 규모 — 전체 몇 건 중 몇 번째를 보고 있는지 적습니다. 검색 결과가 4건이면 사용자는 다 보고, 4,000건이면 검색어를 고칩니다.
4. 한 쪽당 개수 — 20·50·100 중에서 고르게 합니다. 훑어야 하는 사람은 100을 고르고, 느린 회선에서는 20을 고릅니다.

접근성은 이 요소에서 자주 빠집니다. 접근성은 장애나 상황에 상관없이 쓸 수 있게 만드는 설계입니다. 번호만 늘어놓으면 화면을 소리로 읽는 사용자에게는 "1, 2, 3" 만 전달되므로, 링크마다 몇 쪽으로 가는지를 적어 둡니다.

목록에서 특정 항목을 찾아 처리해야 하는 화면에 씁니다. 관리자 화면의 사용자 목록, 문의 내역, 결제 기록처럼 테이블 아래에 붙는 자리가 가장 많습니다. 테이블은 행과 열로 데이터를 늘어놓은 요소입니다. 이런 화면에서는 아까 본 항목으로 돌아가는 일이 잦은데, 3쪽이라는 위치가 그 자리를 기억해 줍니다.

카드를 격자로 늘어놓은 목록에도 붙습니다. 이때는 쪽을 넘긴 뒤 화면이 목록 맨 위로 올라가게 해 둡니다. 스크롤을 내린 상태로 로드되면 사용자는 새 쪽 중간부터 보게 됩니다.

안 쓰는 자리도 분명합니다. 타임라인이나 알림함처럼 위에서 아래로 흘려 보는 목록에는 무한 스크롤이 맞습니다. 다 읽는 것이 목적이 아니고 특정 항목으로 돌아갈 일도 드뭅니다. 탭과는 역할이 아예 다릅니다. 탭은 종류가 다른 내용을 오가고 페이지네이션은 같은 종류를 순서대로 오갑니다.

"이 목록 페이지네이션 빼고 무한 스크롤로 갈까요? 아니면 더 보기 버튼?"

쪽 번호를 없애고 이어 붙이는 방식으로 바꾸자는 제안입니다.

"전체 건수는 안 세도 돼요. 커서 방식으로 하고 다음 버튼만 둡시다."

전체 몇 쪽인지 보여 주는 기능을 버리고 속도를 택하자는 말입니다.

"3쪽 열면 2쪽 마지막 항목이 또 나와요. 정렬이 바뀌는 것 같은데요."

오프셋 방식에서 목록이 도중에 바뀌어 경계가 어긋난 증상입니다.

페이지덱의 관리자 화면에서 이 이야기가 한 번 크게 돌았습니다. 기업 고객 계정의 문서 목록이 십만 건을 넘기면서 뒤쪽 쪽을 열 때 응답이 몇 초씩 걸렸고, 태오가 원인을 오프셋 방식으로 짚었습니다. 커서로 바꾸면 쪽 번호와 전체 건수를 포기해야 한다는 조건이 붙었습니다.

민서가 그 화면에서 사람들이 실제로 무엇을 하는지 확인했습니다. 고객 지원 담당자들은 쪽 번호를 눌러 뛰어다니는 게 아니라 검색으로 문서를 찾고 있었고, 뒤쪽 쪽을 여는 요청은 하루에 몇 건 되지 않았습니다. 그래서 쪽 번호를 지우고 이전·다음과 검색을 남겼습니다.

페이지네이션이 낡은 방식이고 무한 스크롤이 그다음 단계라고 읽는 경우가 많습니다. 새로 나온 서비스에서 쪽 번호를 보기 어렵다 보니 그렇게 보입니다. 두 방식은 새것과 헌것이 아니라 용도가 다릅니다. 훑어 내리는 목록에는 무한 스크롤이 맞고, 찾아서 처리하는 목록에는 쪽이 맞습니다. 관리자 화면을 무한 스크롤로 바꾸면 담당자는 아까 본 항목으로 돌아가려고 매번 처음부터 스크롤을 내리게 됩니다.

쪽 번호를 지우면 서버 부담이 줄어든다고 읽는 것도 흔합니다. 화면에서 번호를 없애는 일과 요청 방식을 바꾸는 일은 별개입니다. 버튼만 이전·다음으로 바꿔 놓고 요청을 여전히 오프셋으로 보내면 느린 이유는 그대로 남습니다.