https://team-edo.github.io/tags/kotlin-multiplatform/Recent content in Kotlin Multiplatform on 얼쑤 · Team EdoHugoko-krThu, 29 Oct 2026 00:00:00 +0900https://team-edo.github.io/posts/2026/10/verify-kmp-without-android-sdk/Thu, 29 Oct 2026 00:00:00 +0900https://team-edo.github.io/posts/2026/10/verify-kmp-without-android-sdk/<p>얼쑤의 녹음 업로드에는 두 종류의 코드가 있습니다. 연결이 끊긴 녹음을 다시 보낼지, 언제 보관 기록을 지울지는 공통 로직입니다. 녹음을 앱의 보관 디렉터리로 실제 이동하는 일은 플랫폼마다 다릅니다. 개발 환경에 Android SDK가 없었을 때도 업로드 판단을 검증할 수 있도록 두 부분을 분리했습니다.</p> <h2 id="업로드-판단은-브라우저의-공통-테스트에서-확인했다">Wasm에서 공통 업로드 로직 검사</h2> <p>공통 코드는 파일의 보관·존재 확인·삭제를 <code>RecordingFiles</code> 인터페이스로 호출합니다. 전송도 인터페이스로 받습니다. Wasm에서 실행한 공통 테스트는 두 인터페이스의 가짜를 넣어, 연결 실패 뒤 기록이 남는지와 같은 세션의 재전송 결과를 확인합니다. 플랫폼의 파일 구현을 불러오지 않아도 테스트가 실행되는 이유입니다.</p>https://team-edo.github.io/posts/2026/10/recording-analysis-polling/Thu, 29 Oct 2026 00:00:00 +0900https://team-edo.github.io/posts/2026/10/recording-analysis-polling/<p>얼쑤에서 연주 녹음을 보낸 사용자는 평가 화면을 기다립니다. 앱 입장에서는 파일을 서버에 전달했는지, 평가를 받을 수 있는지 두 가지를 확인해야 합니다. 둘을 한 요청에서 처리하면 파일을 저장한 뒤에도 분석이 끝날 때까지 업로드 연결을 유지해야 합니다. 저는 녹음을 접수한 뒤 <code>202 Accepted</code>로 답하고, 앱이 같은 연습 세션의 상태를 따로 조회하도록 연결했습니다. <a href="https://www.rfc-editor.org/rfc/rfc9110.html#section-15.3.3">RFC 9110의 202 Accepted</a></p> <h2 id="서버가-접수했다고-답하는-시점">서버의 접수 시점</h2> <p>백엔드는 앱이 보낸 파일을 검사해 R2에 원본을 저장합니다. DB에 원본 키와 녹음 정보를 기록하고 세션을 <code>PENDING</code>으로 바꾼 뒤, 저장이 커밋되면 업로드를 <code>202</code>로 응답합니다. 분석 제출은 같은 커밋을 기준으로 이벤트 리스너가 따로 시도합니다.</p>