https://team-edo.github.io/tags/%EA%B8%B0%EC%88%A0-%EC%9D%98%EC%82%AC%EA%B2%B0%EC%A0%95/Recent content in 기술 의사결정 on 얼쑤 · Team EdoHugoko-krMon, 02 Nov 2026 00:00:00 +0900https://team-edo.github.io/posts/2026/11/write-conditions-for-deferred-pagination/Mon, 02 Nov 2026 00:00:00 +0900https://team-edo.github.io/posts/2026/11/write-conditions-for-deferred-pagination/<p>곡 목록에 서버 검색과 페이지를 붙일지 검토할 때, 공개한 곡은 단소 네 곡이었습니다. 앱은 목록을 한 번 받은 뒤 제목과 난이도로 거를 수 있었습니다. 당시 구현에서 확인한 화면에는 더보기, 정렬, 악기 필터가 없었습니다. 이 상태에서 서버 페이지를 붙이면 요청·응답 계약과 앱 연결을 함께 바꿔야 했습니다. 우선 화면이 이미 제공하는 검색 방식을 쓰기로 하고 서버 작업을 보류했습니다.</p> <h2 id="기능을-보류하면서-재검토할-신호를-남겼다">페이지 도입을 다시 검토할 신호</h2> <p>그때는 곡 목록이 곡마다 원본 악보를 포함했습니다. 초기 데이터에 들어 있던 네 곡의 악보 JSON을 합치면 <strong>82,212바이트</strong>였습니다. 전체 HTTP 응답 크기와는 별개로, 곡이 늘 때 목록에 포함되는 악보가 얼마나 커질지 가늠할 근거였습니다. 재검토 조건은 구현 변경이나 측정으로 확인할 수 있는 세 가지로 적었습니다.</p>