목록으로 돌아왔는데 검색 조건이 왜 초기화돼?

필터를 기억해 달라는 요청부터 나눠 봐

디자인 강좌를 찾는 사람이 지역을 북부로 고르고 2페이지까지 봤어. 포스터 만들기 상세를 읽은 뒤 돌아왔더니 전체 지역의 1페이지가 나와. 이 가상 안건에서 해결할 건 필터 값을 저장하는 일 하나가 아니야. 어떤 조건으로 보던 목록인지, 어디까지 읽었는지, 지금 보여 주는 결과가 그 조건에 맞는지를 함께 맞춰야 해.

처음에는 마지막 조건을 한곳에 저장하면 되겠다고 생각하기 쉬워. 그런데 다른 탭에서 요리 강좌를 찾았다면 어떻게 될까? 두 탭이 하나의 마지막 값을 쓰면 디자인 목록으로 돌아왔는데 요리 조건이 나올 수 있어. 공유한 주소에서도 같은 조건을 열 수 있어야 한다면 화면 안의 저장 값만으로는 부족하고.

그래서 먼저 복원할 대상을 나눠. 적용한 공개 조건, 아직 적용하지 않은 입력, 이번 방문에서 보던 위치야. 이 셋은 남길 곳도, 없어졌을 때 처리도 달라. 아래 표를 기획서에 붙이고 개발·디자인과 같은 기준을 보고 시작해.

주소로 남길 것과 이번 방문에만 쓸 것을 정해

MDN의 History API 설명에서는 기록을 추가하는 pushState와 현재 기록을 바꾸는 replaceState를 구분해. URLSearchParams는 주소의 조건을 읽고 쓰는 도구고. 이 기능들이 복원 정책을 대신 정해 주지는 않아. 어떤 행동을 한 번의 이동으로 볼지는 기획에서 정해야 해.

이 예제에서는 분야·지역·정렬·페이지처럼 공개해도 되는 적용 조건을 URL에 둬. 개인 검색어나 인증 정보는 범위 밖이야. 복귀할 강좌와 위치는 그 목록을 방문한 기록에 연결해. 전역 마지막 값으로 덮지 않고, 새 탭에서는 위치 정보가 없어도 같은 조건을 열 수 있게 만드는 거야.

주소가 같다고 결과까지 영원히 같다는 뜻은 아니야. 강좌가 마감되거나 삭제되면 건수와 순서가 달라져. 그래서 약속은 같은 조건으로 현재 결과를 다시 보여 주는 데까지야. 과거 목록 자체를 보존해야 하는 업무라면 조회 시점과 결과 묶음을 따로 저장하는 설계가 필요해.

적용 버튼 한 번이 방문 기록 몇 개를 만드는지도 써

필터 창에서 지역을 바꿀 때마다 기록을 추가하면 뒤로 가기를 여러 번 눌러야 해. 여기서는 입력 중에는 초안만 바꾸고 적용을 눌렀을 때 한 번 확정해. 분야나 지역, 정렬을 바꾸면 1페이지로 시작해. 지금 적용된 조건과 완전히 같다면 새 기록을 만들지 않아.

페이지 이동에서는 필터와 정렬을 유지해. 뒤로·앞으로 이동은 이미 있는 기록을 읽는 행동이니 다시 기록을 추가하면 안 돼. 해당 URL로 적용 조건과 입력창을 함께 맞춘 뒤 조회해. 적용하지 않았던 초안을 이전 목록에 섞어 놓지 않는 것도 이 규칙에 포함돼.

기본값은 전체 분야·전체 지역·시작일순·1페이지야. 잘못된 지역이나 음수 페이지, 같은 조건 키가 중복된 주소는 해당 항목의 기본값으로 정리하고 바뀐 이유를 보여 줘. 이때는 현재 기록을 교체해. 존재하던 페이지가 결과 감소로 사라진 경우는 형식 오류와 구분하고 다음 절차로 처리할 거야.

돌아왔다는 이유로 예전 응답을 그대로 붙이면 안 돼

상세로 나가기 전에 목록 주소, 보던 강좌, 위치와 입력 방식을 그 방문에 연결해 둬. 같은 탭에서 바로 직전 목록으로 돌아가는 관계가 확인될 때만 뒤로 가기를 써. 상세를 외부 링크로 열었거나 다른 화면을 거쳤다면 검증된 목록 주소로 이동해. 복귀 정보가 없으면 기본 목록 링크를 제공하고 임의의 이전 사이트로 보내지 않아.

복귀한 목록은 현재 조건으로 다시 조회해. 응답의 조건만 비교하면 같은 조건으로 재시도한 오래된 요청이 끼어들 수 있어. 현재 방문과 최신 요청 순번까지 맞아야 반영해. 이전 요청을 취소하는 처리와 별개로 응답을 반영하기 직전에도 검사해야 해.

현재 결과를 그린 뒤에 위치를 복원해. 보던 강좌가 그 페이지에 남아 있으면 해당 항목을 보이게 하고, 키보드로 상세를 열었다면 그 링크에 포커스를 돌려. 없으면 결과 제목으로 돌아가 목록이 달라졌다고 알려 줘. 기다리는 동안 독자가 이미 다른 조작을 했다면 늦은 자동 이동은 취소해. 브라우저와 앱이 각각 스크롤을 복원하지 않도록 담당도 하나로 정해야 해.

항목이 없어졌을 때까지 보여 줘야 설계가 끝나

예전 2페이지가 아직 있다고 해도 보던 강좌는 다른 페이지로 밀릴 수 있어. 모든 페이지를 자동으로 뒤지면 복귀 시간이 늘고 결과가 계속 바뀔 수도 있어. 여기서는 현재 페이지 안에서만 찾아. 없으면 결과 제목으로 보내고 조건은 유지해. 위치를 못 찾았다고 전체 목록으로 초기화하지 않아.

조회가 실패하면 URL과 적용 조건은 남겨 두고 같은 조건으로 다시 시도하게 해. 이전 결과는 숨겨서 새 조건의 결과처럼 보이지 않게 해. 정상적으로 0건이 온 상태와 실패는 다르게 표시해. 결과 감소로 요청한 페이지가 마지막 페이지를 넘었다면 같은 조건의 마지막 유효 페이지로 옮기고 이유를 알려 줘. 0건이면 1페이지의 빈 결과야. 이 보정도 현재 기록만 교체해.

아래 버튼은 조건에 따른 화면 문구를 비교하는 고정 예제야. 실제 강좌 서버를 조회하지 않아. 공유 주소를 새 탭에서 연 경우에는 같은 조건의 현재 결과를 제목부터 보여 주고, 다른 사람의 스크롤이나 포커스까지 따라가지 않게 정했어.

AI에는 저장 방법보다 빠진 이동을 찾아 달라고 해

처음부터 필터 저장 코드를 요청하면 어디에 넣을지부터 답이 나올 수 있어. 먼저 사용자가 들어온 경로, 조건을 확정하는 시점, 복귀할 대상과 실패 정책을 줘. 그 안에서 빠진 이동을 찾아 달라고 범위를 정하는 편이 검토하기 좋아.

예를 들어 제안에 마지막 스크롤 값만 저장하자는 내용이 있다면 다른 탭·삭제된 항목·늦은 응답에서 그 값이 누구의 것인지 다시 물어봐. 모든 상태를 주소에 넣자는 제안이면 공유할 공개 조건과 이번 방문에만 필요한 위치를 나누게 해. 코드가 길다는 이유로 채택하지 말고 결정표와 입력·기대 결과가 맞는지 대조해.

아래는 실제로 실행한 대화가 아니라 질문 예시야. 이어서 요청할 때는 같은 조건 재시도, 상세 직접 진입, 기다리다 필터를 다시 바꾼 경우를 넣어 달라고 하면 돼. 답이 돌아오면 추가된 조건마다 설계서의 어느 이동과 QA의 어떤 검수에 반영할지 연결해서 확인해.

질문 예시: 공개 강좌 목록에서 디자인·북부·시작일순·2페이지를 보다가 상세로 갔다가 돌아와. 적용 조건은 URL, 복귀 위치는 목록 방문별로 보관할 거야. 필터 초안과 적용을 구분하고, 뒤로 가기·새 탭·항목 삭제·같은 조건 재시도에서 빠진 조건을 찾아 줘. 각 경우의 화면 문구, 상태 변경, 개발 전달 조건과 QA 기대 결과를 써 줘. 개인 검색과 무한 스크롤은 제외해.

기획서의 결정이 설계서와 응답까지 이어져야 해

기획서에는 무엇을 복원한다고 약속했는지와 제외 범위를 남겨. 설계서에는 적용·로딩·실패·복귀 화면을 각각 적고, 어떤 상태에서 어떤 문구와 동작이 나오는지 연결해. 저장소 이름만 적고 끝내면 화면은 같은데 뒤로 가기 결과가 다른 구현이 나올 수 있어.

개발과는 정렬도 맞춰야 해. 시작일이 같은 강좌는 고정된 강좌 식별자 순서를 보조 기준으로 써서 응답마다 순서가 흔들리지 않게 해. 그래도 새 강좌 추가나 삭제로 페이지 구성이 바뀔 수 있으니 과거 순서를 보존하는 규칙으로 설명하면 안 돼. 응답에는 적용된 조건과 총건수·페이지 범위를 확인할 수 있는 계약이 필요해.

W3C의 포커스 순서 설명은 키보드 이동에서 의미와 조작 흐름을 유지하라고 해. 이 예제의 항목 링크·결과 제목 복귀는 그 원칙을 고려해 정한 정책이야. 무조건 어느 요소에 포커스를 두라고 정해 주는 표준으로 인용하지 않아. 포커스가 보이는지, 다음 Tab이 이어지는 항목으로 가는지는 실제 화면에서 확인해야 해.

뒤로 가기 한 번 눌러 보고 끝내지는 말자

검수할 때는 URL, 적용된 필터 표시, 실제 결과를 함께 기록해. 필터만 복원됐는데 다른 조건의 결과가 보이는 것도 실패야. 아래 표의 기대 결과는 구현 후 확인할 기준이야. 이 글에서 실제 강좌 서비스를 만들어 연동 검수를 끝냈다는 뜻은 아니고.

PC와 모바일에서 같은 순서로 이동해 보고 키보드로 연 상세의 복귀도 확인해. 로딩을 늦추고 그동안 다른 필터를 적용하면 옛 결과나 포커스가 뒤늦게 끼어들지 않아야 해. 접근 방식이 달라도 같은 조건과 같은 오류 정책을 따라야 재현 가능한 인계가 돼.

가져갈 때는 목록의 약속부터 네 서비스에 맞춰

아래 전달안은 페이지 번호가 있는 공개 강좌 목록에 맞춘 거야. 무한 스크롤이나 개인화 추천, 감사용 과거 목록이라면 복원 범위를 다시 잡아야 해. 특히 특정 시점의 거래나 업무 결과를 그대로 보여 줘야 하는 화면에 현재 결과 재조회 정책을 그대로 붙이지는 마.

적용 전에는 기획·개발·디자인이 같은 예제로 한 번씩 이동을 따라가 봐. 어디서 조건이 확정되는지, 응답이 실패하면 무엇이 남는지, 보던 항목이 없어지면 어디로 가는지를 합의한 뒤 설계서와 QA에 같이 반영해. 문서마다 다른 기본값이 남아 있으면 전달이 끝난 게 아니야.

첫 적용에서는 조건·URL·응답이 어긋나는 실패를 먼저 막아. 문제가 있으면 출시를 멈추고 해당 이동을 고친 다음 같은 순서로 다시 확인해. 배포 뒤에도 삭제·마감으로 페이지가 줄어드는 경우를 운영과 함께 확인하고, 발견한 예외는 결정표·화면 문구·QA를 한 번에 갱신해.

공개 강좌 목록 — 조건 유지와 상세 복귀 전달안
범위: 분야·지역·정렬·페이지 번호가 있는 공개 목록. 개인 검색어·로그인·개인화 추천·무한 스크롤 제외.
예제: 디자인 / 북부 / 시작일순 / 2페이지 / 페이지당 20개. 포스터 만들기 상세를 같은 탭에서 확인한 뒤 돌아온다.
보관: 적용한 공개 조건은 URL에 둔다. 입력 중 초안은 화면 안에만 둔다. 돌아올 항목 식별자·위치·입력 방식은 목록 방문 기록별로 보관하며 공유 URL에 넣지 않는다. 복귀 정보가 없거나 다른 방문의 값이면 쓰지 않는다.
적용: 필터나 정렬을 적용하면 1페이지로 바꾸고 새 기록 1개를 만든다. 현재 적용 조건과 같으면 새 기록을 만들지 않는다. 페이지 이동은 필터·정렬을 유지한다. 기본 진입은 전체 분야·전체 지역·시작일순·1페이지다.
이력 이동: 뒤로/앞으로에서는 해당 URL 조건으로 초안까지 맞추고 조회한다. 새 기록을 추가하지 않는다. 형식 오류는 기본값으로 정규화하고 이유를 알린 뒤 현재 기록만 교체한다. 중복 조건 키는 각 키의 기본값으로 처리한다.
복귀: 같은 탭에서 바로 직전 목록으로 연결된 방문임을 확인할 때만 뒤로 가기를 쓴다. 그 외에는 검증된 목록 주소로 이동한다. 목록 복귀 정보가 없으면 기본 목록 링크를 표시한다. 외부 주소·임의 history.back()을 복귀 링크로 쓰지 않는다.
조회: 현재 방문과 최신 요청 순번이 모두 일치하는 응답만 반영한다. 같은 조건 재시도도 새 순번이다. 실패하면 조건·URL을 유지하고 재시도를 보여준다. 이전 결과는 숨긴다. 0건은 정상 결과로 구분한다.
위치: 최신 결과를 그린 뒤 해당 항목이 현재 페이지에 있으면 그 항목을 보이게 한다. 키보드 진입은 그 링크에 포커스를 둔다. 없거나 복귀 정보가 없으면 결과 제목으로 간다. 기다리는 동안 다른 조작을 시작했으면 늦은 자동 이동은 취소한다. 브라우저 기본 복원과 앱 복원은 중복 실행하지 않는다.
페이지 감소: 현재 마지막 페이지를 넘으면 같은 필터·정렬의 마지막 유효 페이지로 이동하고 현재 기록만 교체한다. 0건이면 1페이지와 빈 결과 안내. 변경 이유를 표시하며 사라진 항목을 찾으려고 모든 페이지를 자동 탐색하지 않는다.
공유: 주소를 새 탭에서 열면 같은 조건의 현재 결과를 제목부터 본다. 과거 순서·건수·스크롤 위치까지 같다고 보장하지 않는다. 시작일 동률에는 고정된 강좌 식별자 순서를 보조 기준으로 쓴다.
책임: 기획은 복원 범위와 예외 결정, 개발은 URL 검증·이력·요청 순번·복원 담당 단일화, 디자인은 조건·로딩·실패·목록 변경 안내와 포커스, QA는 12개 검수 조건, 운영은 삭제·마감·페이지 감소 사례 확인.
출시 전: 기획서의 결정표, 설계서의 전이·문구, API의 정렬·총건수 계약, QA의 입력/기대 결과를 같은 정책으로 대조한다. URL·적용 조건·응답이 어긋나면 출시를 막고 고친다.
검증 범위: 공개 브라우저 문서와 가상 조건으로 만든 설계 예제다. 실제 강좌 서비스의 연동 시험을 완료했다는 뜻은 아니다.

출처와 예제 조건

공개 강좌 목록을 가정한 설계 예제야. 공개 브라우저 자료는 기능과 접근성 원칙의 근거로 썼고, 복귀·기본값·실패 정책은 이 안건에 맞춰 정했어. 실제 강좌 서비스의 연동 시험이나 사용자 성과를 기록한 글은 아니야. AI 질문은 미실행 예시이며 영어·중국어판은 같은 한국어 안건의 현지화야.

MDN — Working with the History API

MDN — URLSearchParams

W3C — Understanding SC 2.4.3 Focus Order