https://team-edo.github.io/tags/api/Recent content in API on 얼쑤 · Team EdoHugoko-krSun, 08 Nov 2026 00:00:00 +0900https://team-edo.github.io/posts/2026/11/song-list-payload-and-gzip/Sun, 08 Nov 2026 00:00:00 +0900https://team-edo.github.io/posts/2026/11/song-list-payload-and-gzip/<p>얼쑤의 곡 목록 API를 Swagger UI에서 열었더니 <code>Could not render responses</code>가 표시됐습니다. 브라우저 콘솔에는 <code>Maximum call stack size exceeded</code>가 남았습니다. 응답을 살펴보니 111곡을 담은 JSON이 약 1.76 MB였고, 그중 약 99%가 곡마다 붙은 <code>score</code>였습니다. 곡 하나를 고르는 화면에서 111곡의 악보까지 받고 있었습니다.</p> <h2 id="곡을-고를-때-필요한-필드만-목록에-남겼다">목록에서 악보 본문 분리</h2> <p>곡 하나당 메타데이터는 평균 189바이트였고, 악보는 평균 약 16 KB였습니다. 악보가 들어간 응답 타입을 목록과 상세에서 함께 쓴 결과였습니다. 곡이 늘면 각 곡의 악보 크기만큼 목록 응답도 함께 커지는 구조였습니다.</p>https://team-edo.github.io/posts/2026/11/playback-url-store-boundary/Mon, 02 Nov 2026 00:00:00 +0900https://team-edo.github.io/posts/2026/11/playback-url-store-boundary/<p>얼쑤의 녹음 다시 듣기 API에 기존 저장소의 읽기 주소 발급 기능을 연결했습니다. 로컬 저장소에서는 분석 컨테이너가 쓰는 내부 주소가 HTTP 200 응답에 들어왔습니다. 테스트는 그 주소의 호스트를 테스트 프로세스가 접근할 수 있는 주소로 바꿔 읽었기 때문에 성공했습니다. 휴대폰은 응답에 들어 있는 주소 그대로 접속하므로 같은 결과를 기대할 수 없었습니다.</p> <h2 id="주소를-받을-쪽을-기준으로-연결을-나눴다">앱이 접근할 주소만 발급</h2> <p>DB의 <code>recording_url</code>에는 녹음 원본을 찾는 객체 키를 저장합니다. 앱에 넘길 임시 주소는 그 키로 다시 듣기를 요청할 때 따로 만듭니다. 그래서 같은 세션의 객체 키를 읽어도 연결한 저장소에 따라 앱이 사용할 주소를 발급할 수 있는지가 달랐습니다.</p>https://team-edo.github.io/posts/2026/10/map-use-case-results-to-http/Thu, 29 Oct 2026 00:00:00 +0900https://team-edo.github.io/posts/2026/10/map-use-case-results-to-http/<p>연주 평가를 조회하는 요청은 평가가 있는지, 다른 회원의 세션인지, 아직 분석 중인지에 따라 답이 달라집니다. 분석을 다시 요청할 때도 아직 작업을 시작할 수 없는 경우가 여러 가지입니다. 두 기능에서 예상되는 업무 결과를 이름 있는 값으로 표현하고, HTTP 상태와 응답 본문은 컨트롤러에서 정했습니다.</p> <h2 id="평가-조회는-누가-무엇을-판단하는가">평가 조회의 판단 경계</h2> <p>컨트롤러는 인증을 마친 토큰에서 회원 ID를 읽어 세션 ID와 함께 넘깁니다. 유스케이스는 조회 계약을 통해 소유한 세션을 찾고, 완료된 세션에서만 평가와 음표 결과를 읽습니다. 세션과 음표 결과는 같은 읽기 전용 트랜잭션에서 조회합니다. 그 계약을 구현한 MyBatis 어댑터는 조회 행을 업무 코드가 읽을 값으로 바꿉니다.</p>