https://team-edo.github.io/tags/%EB%B9%84%EB%8F%99%EA%B8%B0-%EC%B2%98%EB%A6%AC/Recent content in 비동기 처리 on 얼쑤 · Team EdoHugoko-krSat, 07 Nov 2026 00:00:00 +0900https://team-edo.github.io/posts/2026/11/recording-analysis-retry/Sat, 07 Nov 2026 00:00:00 +0900https://team-edo.github.io/posts/2026/11/recording-analysis-retry/<p>얼쑤에서 사용자가 연주 녹음을 보내면 앱은 분석 접수를 확인하고 결과를 기다립니다. 분석 서버에 일시적으로 연결하지 못해도 원본 파일은 서버에 남습니다. 저는 사용자가 그 녹음으로 분석을 다시 요청할 수 있게 했습니다.</p> <p>이때 같은 세션 안에 시도가 여럿 생깁니다. 첫 시도가 시간 초과로 끝난 뒤 두 번째 시도를 시작했는데 첫 시도의 성공 응답이 도착할 수 있습니다. 두 결과는 세션 ID가 같습니다. 그대로 저장하면 앱이 두 번째 시도를 기다리는 동안 첫 시도의 점수를 보여줄 수 있습니다.</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>https://team-edo.github.io/posts/2026/10/budget-end-to-end-analysis-time/Thu, 29 Oct 2026 00:00:00 +0900https://team-edo.github.io/posts/2026/10/budget-end-to-end-analysis-time/<p>얼쑤의 연주 분석에는 60초 제한이 있습니다. 이 시간은 세션이 <code>PENDING</code>이 된 시각부터 결과를 저장할 수 있는 마감까지 흐릅니다. 실행기에서 대기하는 시간, 녹음 다운로드와 디코딩, 음높이 추정과 채점, DB 쓰기가 모두 같은 예산을 사용합니다. 모델의 처리 시간만 재면 가장 먼저 늦어지는 단계가 어디인지 알 수 없습니다.</p> <h2 id="같은-요청에도-여러-시간-제한이-있다">한 요청에 걸린 여러 제한</h2> <table> <thead> <tr> <th>시간 제한</th> <th>언제부터 재나</th> <th>만료되면</th> </tr> </thead> <tbody> <tr> <td>백엔드의 결과 저장 마감 <strong>60초</strong></td> <td>DB에 기록한 분석 시도 시작 시각부터</td> <td>늦은 결과는 저장하지 않고, 마감이 지난 <code>PENDING</code>은 상태 조회에서 <code>TIMEOUT</code>으로 처리합니다.</td> </tr> <tr> <td>백엔드 HTTP 클라이언트의 읽기 제한 기본 <strong>65초</strong></td> <td>AI 응답을 읽으면서 다음 응답 데이터를 기다릴 때</td> <td>대기 시간을 넘기면 HTTP 읽기가 실패합니다.</td> </tr> <tr> <td>앱의 상태 무응답 제한 <strong>70초</strong></td> <td>상태 조회를 시작하거나 재개한 시점부터, 응답을 받으면 그 시점부터</td> <td>앱이 시간 초과 화면을 표시합니다.</td> </tr> </tbody> </table> <p>HTTP 연결을 맺는 제한은 별도로 <strong>5초</strong>였습니다. 읽기 제한을 저장 마감보다 길게 둬, 느린 응답을 클라이언트가 먼저 끊어 서버 오류로 분류하는 경우를 줄이려 했습니다. HTTP 연결이 끊겨도 이미 실행 중인 AI 연산이 취소되는지는 별도의 문제입니다. 앱의 조회 간격과 무응답 경계는 가상 시계로 확인했습니다. <a href="https://team-edo.github.io/posts/2026/10/recording-analysis-polling/">녹음 업로드 202 이후 앱이 기다리는 것</a></p>