곡 목록에 서버 검색과 페이지를 붙일지 검토할 때, 공개한 곡은 단소 네 곡이었습니다. 앱은 목록을 한 번 받은 뒤 제목과 난이도로 거를 수 있었습니다. 당시 구현에서 확인한 화면에는 더보기, 정렬, 악기 필터가 없었습니다. 이 상태에서 서버 페이지를 붙이면 요청·응답 계약과 앱 연결을 함께 바꿔야 했습니다. 우선 화면이 이미 제공하는 검색 방식을 쓰기로 하고 서버 작업을 보류했습니다.

페이지 도입을 다시 검토할 신호

그때는 곡 목록이 곡마다 원본 악보를 포함했습니다. 초기 데이터에 들어 있던 네 곡의 악보 JSON을 합치면 82,212바이트였습니다. 전체 HTTP 응답 크기와는 별개로, 곡이 늘 때 목록에 포함되는 악보가 얼마나 커질지 가늠할 근거였습니다. 재검토 조건은 구현 변경이나 측정으로 확인할 수 있는 세 가지로 적었습니다.

  • 앱에서 단소 외 악기의 곡을 게시한다.
  • 목록 응답이 500 KB를 넘는다.
  • 화면에 더보기, 정렬, 악기 필터 중 하나가 필요해진다.

500 KB는 다시 검토할 시점을 잡기 위한 기준입니다. 당시 악보가 곡당 약 20 KB라는 가정에서 25곡 정도를 예상했습니다. 악보의 구성이 달라지거나 응답 필드를 바꾸면 그 곡 수는 달라집니다. 관련 앱 연결 작업도 함께 보류하고, 이후 검토할 때는 서버 검색·필터·페이지와 목록 필드 경량화를 같이 살피기로 했습니다.

후속 점검에서 111곡을 담은 목록 응답이 약 1.76 MB로 500 KB 기준을 넘었습니다. 먼저 응답 크기에 가장 크게 영향을 준 필드를 찾았고, 곡을 고를 때 필요하지 않은 악보 본문을 목록에서 분리했습니다. 1.76MB 곡 목록에서 악보 덜어내기

화면에서 악기별 목록이 필요해졌을 때는 별도로 서버에 악기 필터를 넣었습니다. 필터를 붙이기 전에는 형식이 잘못된 악기 ID를 보낸 검사에서 400을 기대했지만 200을 받았습니다. 입력 검사를 구현한 뒤 같은 요청이 400으로 거절되는 것을 확인했습니다. 응답 크기가 커진 상황에서는 목록 필드를 조정했고, 악기별로 곡을 찾아야 하는 상황에서는 필터를 추가했습니다.