<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>타임아웃 on 얼쑤 · Team Edo</title><link>https://team-edo.github.io/tags/%ED%83%80%EC%9E%84%EC%95%84%EC%9B%83/</link><description>Recent content in 타임아웃 on 얼쑤 · Team Edo</description><generator>Hugo</generator><language>ko-kr</language><lastBuildDate>Thu, 29 Oct 2026 00:00:00 +0900</lastBuildDate><atom:link href="https://team-edo.github.io/tags/%ED%83%80%EC%9E%84%EC%95%84%EC%9B%83/index.xml" rel="self" type="application/rss+xml"/><item><title>연주 분석 60초의 시작점</title><link>https://team-edo.github.io/posts/2026/10/budget-end-to-end-analysis-time/</link><pubDate>Thu, 29 Oct 2026 00:00:00 +0900</pubDate><guid>https://team-edo.github.io/posts/2026/10/budget-end-to-end-analysis-time/</guid><description>&lt;p>얼쑤의 연주 분석에는 60초 제한이 있습니다. 이 시간은 세션이 &lt;code>PENDING&lt;/code>이 된 시각부터 결과를 저장할 수 있는 마감까지 흐릅니다. 실행기에서 대기하는 시간, 녹음 다운로드와 디코딩, 음높이 추정과 채점, DB 쓰기가 모두 같은 예산을 사용합니다. 모델의 처리 시간만 재면 가장 먼저 늦어지는 단계가 어디인지 알 수 없습니다.&lt;/p>
&lt;h2 id="같은-요청에도-여러-시간-제한이-있다">한 요청에 걸린 여러 제한&lt;/h2>
&lt;table>
 &lt;thead>
 &lt;tr>
 &lt;th>시간 제한&lt;/th>
 &lt;th>언제부터 재나&lt;/th>
 &lt;th>만료되면&lt;/th>
 &lt;/tr>
 &lt;/thead>
 &lt;tbody>
 &lt;tr>
 &lt;td>백엔드의 결과 저장 마감 &lt;strong>60초&lt;/strong>&lt;/td>
 &lt;td>DB에 기록한 분석 시도 시작 시각부터&lt;/td>
 &lt;td>늦은 결과는 저장하지 않고, 마감이 지난 &lt;code>PENDING&lt;/code>은 상태 조회에서 &lt;code>TIMEOUT&lt;/code>으로 처리합니다.&lt;/td>
 &lt;/tr>
 &lt;tr>
 &lt;td>백엔드 HTTP 클라이언트의 읽기 제한 기본 &lt;strong>65초&lt;/strong>&lt;/td>
 &lt;td>AI 응답을 읽으면서 다음 응답 데이터를 기다릴 때&lt;/td>
 &lt;td>대기 시간을 넘기면 HTTP 읽기가 실패합니다.&lt;/td>
 &lt;/tr>
 &lt;tr>
 &lt;td>앱의 상태 무응답 제한 &lt;strong>70초&lt;/strong>&lt;/td>
 &lt;td>상태 조회를 시작하거나 재개한 시점부터, 응답을 받으면 그 시점부터&lt;/td>
 &lt;td>앱이 시간 초과 화면을 표시합니다.&lt;/td>
 &lt;/tr>
 &lt;/tbody>
&lt;/table>
&lt;p>HTTP 연결을 맺는 제한은 별도로 &lt;strong>5초&lt;/strong>였습니다. 읽기 제한을 저장 마감보다 길게 둬, 느린 응답을 클라이언트가 먼저 끊어 서버 오류로 분류하는 경우를 줄이려 했습니다. HTTP 연결이 끊겨도 이미 실행 중인 AI 연산이 취소되는지는 별도의 문제입니다. 앱의 조회 간격과 무응답 경계는 가상 시계로 확인했습니다. &lt;a href="https://team-edo.github.io/posts/2026/10/recording-analysis-polling/">녹음 업로드 202 이후 앱이 기다리는 것&lt;/a>&lt;/p></description></item><item><title>1초 늦는 저장소로 SDK 타임아웃 검증</title><link>https://team-edo.github.io/posts/2026/10/storage-sdk-call-budget/</link><pubDate>Wed, 28 Oct 2026 00:00:00 +0900</pubDate><guid>https://team-edo.github.io/posts/2026/10/storage-sdk-call-budget/</guid><description>&lt;p>녹음 업로드 요청은 파일 검사와 객체 저장을 거친 뒤 응답합니다. 코드 리뷰에서 저장소 호출 상한이 &lt;strong>2분&lt;/strong>이라는 점을 확인했습니다. 이 경로에서 Nginx의 응답 읽기 제한은 &lt;strong>60초&lt;/strong>였습니다. 저장소가 느리면 애플리케이션이 오류 형식을 정해 응답하기 전에 프록시가 연결을 끝낼 수 있었습니다.&lt;/p>
&lt;h2 id="재시도까지-하나의-예산으로-묶었다">재시도를 포함한 40초 상한&lt;/h2>
&lt;p>파일 검사 도구에는 10초, 저장소 호출 전체에는 &lt;strong>40초&lt;/strong>를 배정했습니다. 두 설정을 더하면 50초입니다. Nginx의 60초는 연속한 읽기 사이의 대기 제한이고, 50초는 이 경로의 두 주요 작업에 배정한 예산입니다. 둘 다 실제 요청 시간의 측정값은 아닙니다. &lt;a href="https://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_read_timeout">Nginx의 응답 읽기 제한&lt;/a>&lt;/p></description></item></channel></rss>