더 보기 후 글을 읽고 돌아왔을 때: 목록 주소와 위치 복원

더 본 글 목록으로 돌아갈 수 있어야 합니다

카테고리에서 ‘더 보기’를 두 번 누르고 마음에 드는 글을 열었습니다. 뒤로 돌아왔더니 처음 열두 개만 남고, 방금 보던 글은 다시 버튼을 눌러 찾아야 합니다. 목록을 덧붙이는 기능은 성공했지만 탐색은 이어지지 않은 것입니다. 더 보기의 품질은 항목이 추가되는 순간뿐 아니라 글을 읽고 돌아왔을 때와 주소를 공유했을 때 드러납니다.

이 글은 가상의 48개 글 목록을 한 번에 12개씩 보여주는 구조를 예로 사용합니다. 실제 detailry의 목록 기능을 측정한 결과는 아닙니다. 목표는 페이지 번호를 반드시 없애는 것이 아니라, 목록을 불러오는 방식이 달라져도 독자가 현재 범위와 돌아갈 위치를 잃지 않도록 만드는 것입니다.

각 묶음을 직접 열 수 있는 주소부터 준비합니다

기본 목록은 /guides/?page=1, 두 번째 묶음은 /guides/?page=2처럼 직접 열 수 있는 주소로 구분할 수 있습니다. 주소를 새 탭에서 열거나 JavaScript 없이 요청했을 때도 해당 묶음의 글과 앞뒤 이동 링크가 있어야 합니다. 더 보기 기능은 이 기본 탐색에 화면 안 추가 동작을 얹는 방식으로 설계할 수 있습니다.

Google의 페이지 나누기 안내는 검색 크롤러가 보통 버튼을 클릭하지 않으므로 href를 가진 링크와 페이지별 URL을 제공하도록 설명합니다. 이 구조는 색인이나 순위를 보장하지 않습니다. 사람이 클릭하지 않아도 다음 묶음으로 이어지는 문서 관계를 제공하는 것이 핵심입니다.

<nav aria-label="글 목록 페이지">
  <a href="/guides/?page=1" aria-current="page">1</a>
  <a href="/guides/?page=2">2</a>
  <a href="/guides/?page=3">3</a>
  <a href="/guides/?page=4">4</a>
  <a href="/guides/?page=2" rel="next">다음 12개 글</a>
</nav>

예제의 주소는 이 글에서 실제 제공하는 페이지가 아닙니다. 링크 이름은 목적지를 설명하며, 현재 페이지 표시는 실제 서버 결과와 맞아야 합니다. 모든 페이지의 대표 주소를 첫 페이지로 지정하면 다른 묶음이 독립된 문서라는 설계와 충돌할 수 있습니다. 같은 공식 안내가 설명하듯 페이지별 대표 주소도 그 페이지의 콘텐츠를 기준으로 정합니다.

페이지 번호와 누적해서 본 범위를 혼동하지 않습니다

두 번째 묶음을 첫 번째 아래에 붙인 화면에는 24개가 보입니다. 그런데 주소는 ?page=2이고 새로고침하면 13~24번만 나온다면 같은 주소의 의미를 설명해야 합니다. ‘2페이지를 보고 있다’와 ‘1페이지부터 2페이지까지 펼쳤다’는 다른 상태입니다. 처음부터 하나를 정하지 않으면 뒤로가기 코드가 임시로 쌓이기 쉽습니다.

설계	주소의 의미	돌아올 때 필요한 것
페이지 교체	현재 묶음 한 개	그 페이지와 목록 안 위치
누적 더 보기	정한 현재 페이지 + 별도 펼침 상태	불러온 범위와 기준 글
누적 범위를 URL에 표현	예: through=3은 1~3 묶음	서버도 같은 범위를 재현하는 규칙

세 번째 방식은 가능한 설계 예시일 뿐 권장 검색 URL 규칙은 아닙니다. 범위를 무한히 늘릴 수 있게 만들면 무거운 응답과 중복 주소가 늘 수 있습니다. 기본 페이지 주소는 단순하게 유지하고 누적 상태는 현재 탭의 기록에 보관하는 편이 적합한 목록도 있습니다. 다만 이 경우 주소를 다른 사람에게 보내면 어느 범위가 열리는지 명확해야 합니다.

기록을 추가할지 현재 기록을 고칠지 정합니다

MDN History API 안내에서 pushState는 세션 기록을 하나 추가하고 replaceState는 현재 항목을 바꿉니다. 더 보기를 누를 때마다 기록을 추가하면 뒤로가기가 36개, 24개, 12개 상태를 차례로 거칩니다. 현재 목록 상태를 교체하면 뒤로가기를 눌렀을 때 목록 이전 화면으로 나가는 설계가 됩니다. 어느 쪽이 사용 과업에 맞는지 먼저 결정해야 합니다.

기록에 넣을 자료는 예를 들어 카테고리, 정렬 기준, 불러온 마지막 페이지, 기준 글 ID입니다. 아래 코드는 현재 상태를 저장하는 자료 모양만 보여줍니다. 글을 추가로 불러오거나 이전 화면을 복구하는 완성 코드는 아닙니다.

history.replaceState({
  view: "guide-list",
  category: "web",
  sort: "newest",
  loadedThrough: 3,
  anchorArticleId: "demo-27"
}, "", location.href);

주소가 바뀌었다고 목록이 자동으로 복구되지는 않습니다. 같은 문서의 기록 이동을 처리하는 경우 popstate에서 필요한 묶음을 확보한 뒤 화면을 구성해야 합니다. 실제 페이지 이동 뒤 돌아오는 경우에는 브라우저가 기존 화면을 복원했는지도 고려해야 합니다. 저장 상태를 무조건 덧붙이면 이미 복원된 36개 뒤에 같은 글을 다시 붙일 수 있습니다.

돌아갈 위치는 픽셀보다 글의 식별값을 중심으로 잡습니다

스크롤 값을 2400px로 저장해도 나중에 이미지 높이나 글 제목의 줄 수가 달라지면 같은 글을 가리키지 않을 수 있습니다. ‘demo-27이라는 글을 기준으로 돌아간다’는 관계를 먼저 저장하고, 필요한 콘텐츠가 그려진 뒤 해당 항목 주변 위치를 복원하는 방식을 검토할 수 있습니다. 정확한 스크롤 수치는 보조값으로 사용합니다.

정렬과 필터가 바뀌면 이전 글이 그 목록에 없을 수 있습니다. 예를 들어 웹디자인에서 마케팅으로 바꾼 뒤 이전 웹디자인 글의 위치를 찾는 것은 맞지 않습니다. 이런 경우 새 조건의 첫 묶음으로 이동하고 표시 범위와 다음 페이지를 초기화합니다. 목록 제목과 선택한 필터가 같은 조건을 설명하는지도 함께 봐야 합니다.

이미지 높이 변화로 복원 위치가 흔들린다면 이미지 공간을 미리 확보하는 방법이 관련됩니다. 복원 코드를 복잡하게 만드는 것보다 카드 높이가 예측 가능하도록 만드는 일이 먼저일 수 있습니다.

실패한 더 보기는 현재 목록을 지우지 않습니다

13~24번을 요청하다 실패했다면 이미 읽을 수 있는 1~12번은 그대로 둡니다. 버튼에는 재시도 경로를 남기고 다음 페이지 링크도 유지합니다. 요청이 진행 중일 때 같은 요청을 반복하지 않도록 처리하되, 실패 후 계속 비활성 상태로 남는 일은 없어야 합니다. 늦게 도착한 이전 필터의 응답이 새 목록 뒤에 섞이는 문제도 요청 조건을 비교해 막아야 합니다.

추가가 완료되면 ‘12개 추가, 현재 24개 표시’처럼 짧은 상태를 전달할 수 있습니다. W3C 상태 메시지 설명은 초점을 받지 않는 상태 변화도 보조기술이 알 수 있도록 만드는 원칙을 다룹니다. 목록 전체를 매번 읽히게 하는 것보다 추가된 범위를 설명하는 짧은 메시지가 목적에 맞을 수 있습니다.

새 항목 뒤로 밀려난 더 보기 버튼에 초점이 남으면 키보드 사용자가 추가된 글을 지나칠 수 있습니다. 버튼의 위치를 유지할지, 추가 묶음의 시작으로 초점을 옮길지, 새 글로 이동하는 경로를 제공할지 결정하고 실제 Tab 흐름을 확인합니다. 단순히 스크롤만 올려놓는 것은 초점 문제를 해결하지 않습니다.

글을 열고 돌아오는 한 번의 탐색으로 확인합니다

기본 목록에서 두 묶음을 더 읽고, 세 번째 묶음의 글을 열고, 뒤로 돌아와 다음 글을 선택하는 흐름을 따라가 보세요. 이어서 같은 목록 주소를 새 탭에서 열고 JavaScript를 사용할 수 없는 상황의 다음 링크도 확인합니다. 화면 추가, 주소, 기록 복원은 이 흐름에서 서로 맞아야 합니다.

이동 링크와 실행 버튼을 구분하는 기본 원칙은 링크를 누르기 전에 알려야 할 정보에도 이어집니다. 기본 문서 탐색이 남아 있으면 추가 로딩이 실패해도 독자는 다음 글로 갈 수 있습니다. 더 보기의 목적은 페이지 번호를 감추는 것이 아니라, 읽던 목록을 끊김 없이 이어주는 데 있습니다.