Data URL 대 Presigned URL 지연 벤치마크

원문은 동료와의 대립에서 출발해 작성자가 직접 벤치마크를 실행한 과정과 결과를 공유한 형태다. 작성자는 실험 설계와 만난 이슈들을 명시했고 블로그로 상세 데이터를 연결해 독자의 검증을 유도했다. 댓글을 통해 방법론 세부를 추가로 설명하겠다고 밝혀 토론과 피드백을 수용할 의사를 보였다.

• 벤치마크를 구축할 때는 cache_control과 같은 HTTP 캐시 설정이 실험 결과에 영향을 줄 수 있어 각 경로의 캐시 누수를 차단하고 재현 가능한 환경을 구성해야 한다. 작성자는 Claude에서 관찰한 cache_control 특이 사례를 보정하는 등 캐시 관련 함정을 제거한 뒤 비교를 수행했다는 점을 강조했다. 이러한 사전 조정 없이 수집한 지연은 잘못된 결론을 낳을 수 있다.
• Presigned URL을 실험하거나 운영에 도입할 경우 서명 재생(replay)과 서명 회전(rotation) 정책을 설계해 재현성 있는 비교를 확보해야 한다. 작성자는 presigned 서명을 재생할 때 서명이 회전하도록 설정해 동일한 서명이 캐시나 중복 전송에 미치는 영향을 제거했다. 또한 모델별로 외부 리소스 처리 방식이 다른 만큼 여러 모델에서 측정해 평균적 경향을 확인할 필요가 있다.

데이터 URL(Data URL)

— 이미지 파일을 Base64로 인코딩해 HTTP 요청 본문이나 prompt에 직접 포함시키는 방식으로, 별도 업로드·서명 과정 없이 바로 전송한다. 전송이 단순해 운영 부담이 적지만 대화 히스토리가 길어질수록 동일한 Base64 바이트를 반복 전송해 페이로드가 커진다. 이로 인해 전송 비용과 대기시간이 증가할 가능성이 있어 벤치마크가 요구된다.

사전 서명 URL(Presigned URL)

— 이미지 파일을 스토리지에 업로드하고 그 객체에 접근 가능한 임시 서명 URL을 생성해 전송하는 방식으로, 각 요청에서는 URL만 전달해 본문 크기를 작게 유지한다. 반복 전송 시에는 동일한 이미지 바이트를 재전송하지 않아 네트워크 부담과 latency를 줄일 수 있다. 대신 서명 URL을 재발급하거나 만료 관리를 해야 하므로 운영 로직이 추가된다.

Base64 인코딩(Base64)

— 이진 데이터를 텍스트로 안전하게 전송하기 위해 6비트 단위로 인코딩하는 표준 방식으로, HTTP 본문이나 JSON 안에 이미지를 포함할 때 자주 사용된다. 인코딩 결과가 원본보다 약 33% 커지는 특성이 있어 대화 히스토리로 누적되면 전송량과 지연이 늘어난다. 벤치마크에서는 Base64 바이트 재전송 여부가 지연에 미치는 영향을 확인하는 것이 중요하다.

Cache-Control 헤더(cache_control)

— HTTP에서 응답의 캐싱 동작을 제어하는 표준 헤더로, 응답이 프록시·클라이언트에 얼마큼 저장되는지와 재사용 가능성을 결정한다. LLM 호출과 연동된 이미지 전송에서는 cache_control 설정에 따라 캐시 공유나 캐시 누수(cache bleed)가 발생할 수 있으며, 벤치마크 결과의 공정성에 영향을 줄 수 있다. 특정 모델·엔진에서는 cache_control 특성이 구현별로 다르게 동작해 주의가 필요하다.

Claude

— Anthropic이 공개한 대화형 LLM으로, 외부 이미지·리소스 핸들링과 캐시 동작에서 구현 차이가 있을 수 있다. 원문에서는 Claude에서 cache_control 특이 사례를 만났다는 언급이 있어 실험 환경별 편차 점검이 필요하다. 모델별로 외부 리소스 처리 지연이 다르게 나타날 수 있으므로 여러 모델을 대상으로 비교했다는 점이 핵심이다.