<?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/%EC%A0%80%EC%9E%A5%EC%86%8C/</link><description>Recent content in 저장소 on 얼쑤 · Team Edo</description><generator>Hugo</generator><language>ko-kr</language><lastBuildDate>Mon, 02 Nov 2026 00:00:00 +0900</lastBuildDate><atom:link href="https://team-edo.github.io/tags/%EC%A0%80%EC%9E%A5%EC%86%8C/index.xml" rel="self" type="application/rss+xml"/><item><title>녹음 재생 API가 내부 주소를 반환한 이유</title><link>https://team-edo.github.io/posts/2026/11/playback-url-store-boundary/</link><pubDate>Mon, 02 Nov 2026 00:00:00 +0900</pubDate><guid>https://team-edo.github.io/posts/2026/11/playback-url-store-boundary/</guid><description>&lt;p>얼쑤의 녹음 다시 듣기 API에 기존 저장소의 읽기 주소 발급 기능을 연결했습니다. 로컬 저장소에서는 분석 컨테이너가 쓰는 내부 주소가 HTTP 200 응답에 들어왔습니다. 테스트는 그 주소의 호스트를 테스트 프로세스가 접근할 수 있는 주소로 바꿔 읽었기 때문에 성공했습니다. 휴대폰은 응답에 들어 있는 주소 그대로 접속하므로 같은 결과를 기대할 수 없었습니다.&lt;/p>
&lt;h2 id="주소를-받을-쪽을-기준으로-연결을-나눴다">앱이 접근할 주소만 발급&lt;/h2>
&lt;p>DB의 &lt;code>recording_url&lt;/code>에는 녹음 원본을 찾는 객체 키를 저장합니다. 앱에 넘길 임시 주소는 그 키로 다시 듣기를 요청할 때 따로 만듭니다. 그래서 같은 세션의 객체 키를 읽어도 연결한 저장소에 따라 앱이 사용할 주소를 발급할 수 있는지가 달랐습니다.&lt;/p></description></item></channel></rss>