앱 목록의 다음 20개는 서버에서 어떻게 불러올까요?

수업·행사 소식을 모아보는 앱을 생각해보겠습니다. 처음에는 전체 소식을 최신순으로 보여주고, 사용자가 수업이나 행사만 골라볼 수 있게 합니다. 한 번에 읽는 수는 20개로 정합니다.

최신순이라는 말도 저장 기준으로 구체화해야 합니다. 이 흐름에서는 작성 시각이 늦은 글부터 읽고, 작성 시각이 같으면 고유 번호가 큰 글을 먼저 읽습니다. 같은 시각의 글에도 순서가 정해져야 다음 목록의 시작점이 흔들리지 않습니다.

이 시연의 정렬은 최신순으로 고정합니다. 앱은 분류와 한 번에 읽을 수를 요청에 담고, 서버는 허용된 조건을 확인한 뒤 정해둔 순서로 조회합니다. 실제 서비스에서 공개 여부나 회원 권한이 필요하면 그 조건도 서버 조회에 함께 적용합니다.

첫 요청에는 아직 이어 읽을 기준이 없습니다. 서버는 선택한 분류의 첫 항목부터 읽습니다. 이 시연에서는 최대 21개를 읽어 앞의 20개까지만 앱에 보냅니다. 하나가 더 있는지 확인해 ‘다음 목록 있음’을 판단하는 방식입니다.

응답에는 게시글 목록과 함께 다음 조회 기준인 커서, 다음 목록의 유무를 넣습니다. 커서는 이번에 보낸 마지막 글의 작성 시각과 번호, 조회 조건을 이어 쓰기 위한 값입니다. 앱은 커서 안의 숫자를 직접 고치지 않고 서버가 보낸 값을 보관합니다.

처음 20개를 받았다면 앱은 그 목록을 표시하고, 다음 목록이 있을 때 ‘더 보기’를 사용할 수 있게 합니다. 자료가 없으면 빈 목록을 안내하고, 마지막 묶음을 받았다면 추가 요청을 끝냅니다.

사용자가 ‘더 보기’를 누르면 앱은 같은 분류와 보관한 커서를 서버에 보냅니다. 서버는 커서가 현재 조회 조건과 맞는지 확인한 뒤, 앞에서 보낸 마지막 글보다 뒤에 있는 항목을 읽습니다.

최신순에서는 작성 시각이 더 이르거나, 시각이 같으면서 번호가 더 작은 글이 다음 대상입니다. 이 두 값을 함께 비교하면 같은 시각에 작성된 글도 일정한 순서로 이어 읽을 수 있습니다.

서버는 다음 묶음과 새 커서, 다음 목록의 유무를 다시 돌려줍니다. 앱은 성공 응답을 받은 뒤 기존 목록 아래에 새 항목을 붙이고 커서를 바꿉니다. 요청을 보냈다는 이유로 먼저 개수를 늘리거나 다음 위치로 넘어가지 않습니다.

목록을 읽는 동안에는 불러오는 중이라는 상태를 보여주고 같은 추가 요청의 반복 실행을 막습니다. 현재 보고 있는 글은 그대로 남겨둡니다.

추가 조회가 실패하면 기존 목록과 마지막으로 성공한 커서를 유지합니다. 다시 시도할 때 같은 위치에서 읽어야 중간 항목을 건너뛰지 않습니다. 시연의 ‘다음 요청 오류’로 이 상태를 확인할 수 있습니다.

목록에 붙일 때는 고유 번호가 같은 항목이 이미 있는지도 확인합니다. 다만 화면에서 중복만 지운다고 서버의 조회 기준이 잘못된 문제가 해결되지는 않습니다. 서버 정렬과 경계, 앱의 추가 처리를 함께 점검해야 합니다.

첫 목록을 읽은 뒤 더 최신 글이 등록될 수 있습니다. 앞에서 몇 개를 읽었는지만 세어 건너뛰면 새 글이 들어온 만큼 위치가 밀려 앞의 글을 다시 받을 수 있습니다. 마지막 글의 작성 시각과 번호를 기준으로 이어 읽으면, 이 예시의 새 글 추가 때문에 같은 경계를 다시 읽는 일을 피할 수 있습니다. 새 글은 처음부터 다시 읽을 때 확인합니다.

이 방식이 모든 변경을 처음 조회 당시의 상태로 고정하는 것은 아닙니다. 기존 글의 정렬 값이나 분류가 바뀌고 글이 삭제되는 경우의 정책은 별도로 정해야 합니다. 이 예시는 작성 시각·고유 번호가 유지되는 글을 최신순으로 읽는 흐름입니다.

전체에서 수업만 보기로 바꾸면 기존 목록과 커서를 비우고 새 조건의 첫 목록을 요청합니다. 이전 전체 목록의 응답이 늦게 도착하더라도 새 수업 목록에 붙이면 안 됩니다. 앱은 요청할 때의 조회 회차를 기억하고, 지금 화면의 회차와 같은 응답만 반영합니다.

시연에서는 처음 64개를 20개·20개·20개·4개로 읽습니다. 단순히 화면에 ‘40개’라는 숫자가 나오는지보다 항목의 고유 번호가 중복되거나 빠지지 않았는지, 마지막 응답에서 추가 조회가 끝나는지를 봅니다.

첫 목록 뒤에 새 글을 등록했을 때 다음 묶음이 기존 경계 다음부터 이어지는지, 추가 조회가 실패해도 목록과 커서가 유지되는지 확인합니다. 응답을 늦게 받는 동안 필터를 바꾸고 이전 조건의 응답이 제외되는지도 확인합니다. 서버가 실제 실행한 조회 조건과 반환 개수는 ‘요청·응답 자세히’에서 읽을 수 있습니다.

페이지 번호로 바로 이동해야 하는 관리자 표에서는 페이지 번호와 건너뛸 수를 사용하는 방식도 선택할 수 있습니다. 커서 방식은 순서대로 이어 보는 목록에 맞으며, 임의의 먼 페이지로 바로 이동하는 기능과는 구현 조건이 다릅니다. 서비스의 탐색 방식에 맞춰 고르고 조회 조건에 맞는 인덱스도 함께 설계합니다.

이처럼 ‘더 보기’는 버튼 하나로 끝나는 기능이 아닙니다. 무엇을 어떤 순서로 읽고, 다음 위치를 어떻게 이어주며, 늦거나 실패한 응답을 화면에 어떻게 반영할지까지 앱과 서버가 같은 기준으로 동작해야 합니다.