Suno SDK 시리즈 02: 폴링과 다운로드의 함정, 404/502에서 audio_url 성공까지
Suno 같은 음악 생성 API에서는 작업이 succeeded가 되어도 최종 파일을 바로 받을 수 있다고 가정하면 안 됩니다. 이번 실측에서는 공개 /content URL이 404/502를 반환했지만, 상위 원시 결과의 audio_url은 정상적으로 다운로드되었습니다.
실측 결과
대상 작업:
task_ac90b23619334516
폴링 결과:
{
"status": "succeeded",
"format": "mp4",
"url": "https://crazyrouter.com/v1/videos/task_ac90b23619334516/content"
}
공개 content URL 검증:
HEAD crazyrouter.com content URL: HTTP 404
HEAD api.crazyrouter.com content URL + Authorization: HTTP 404
GET api.crazyrouter.com content URL + Authorization: HTTP 502
이 결과만 보면 “생성 결과 다운로드가 불가능하다”고 판단하기 쉽습니다. 하지만 작업 원시 결과에는 실제 미디어 URL이 있었습니다.
data.data.resultJson.data[0].audio_url
data.data.resultJson.data[0].image_url
audio_url 검증 결과:
HEAD audio_url: HTTP 200, Content-Type: audio/mp3
GET audio_url: HTTP 200, Content-Type: audio/mp3, 412326 bytes
무엇이 실패했고 무엇이 성공했나
| 항목 | 결과 |
|---|---|
| 작업 제출 | 성공 |
| 작업 폴링 | 성공, succeeded
|
공개 /v1/videos/{task_id}/content
|
실패, 404/502 |
상위 resultJson.data[0].audio_url
|
성공, MP3 다운로드 |
| 실사용 가능 여부 | 생성 결과는 사용 가능. 공개 프록시는 보완 필요 |
이 차이를 로그에 남기지 않으면 문제를 “Suno 생성 실패”로 잘못 분류하게 됩니다. 정확히는 “생성은 성공했지만 공개 content 프록시가 상위 audio_url을 해석하지 못한 것”입니다.
다운로드 처리에서 확인할 것
다운로드 로직에서는 최소한 다음을 확인해야 합니다.
HTTP status: 200 또는 허용한 206
Content-Type: audio/* 같은 미디어 타입
Content-Length 또는 실제 다운로드 크기
필요하면 ffprobe 등으로 재검증
오류 페이지를 .mp3나 .mp4로 저장하는 구현은 반드시 피해야 합니다.
권장 재시도 전략
1차: succeeded 직후 다운로드
2차: 10초 후
3차: 30초 후
4차: 60초 후
마지막: resultJson.data[0].audio_url 재확인
그래도 실패하면 task_failed가 아니라 content_unavailable처럼 분리된 상태로 기록하는 것이 운영에 유리합니다.
정리
이번 테스트의 핵심은 명확합니다.
공개 /content 실패 = Suno 생성 실패
가 아닙니다.
Suno의 실제 미디어는 resultJson.data[0].audio_url에 있었고, 이 URL에서는 정상적으로 MP3를 받을 수 있었습니다. 운영 환경에서는 이 URL을 명시적으로 파싱하고, 필요하다면 자체 스토리지로 옮기는 것이 안전합니다.

Top comments (0)