AI 이미지 캡셔닝(Image Captioning)을 위해 폐쇄적 생태계(Walled Garden)를 벗어난 방법

지난 3월, 저는 한계에 부딪혔습니다. 저희 팀은 하루에 약 50,000장의 이미지에 대해 캡션(Caption)을 자동으로 생성해야 하는 미디어 플랫폼을 구축하고 있었는데, 특정 폐쇄형 소스(Closed-source) 제공업체로부터 날아오는 청구서가 저희의 전환율(Conversion rates)보다 더 빠르게 상승하고 있었습니다. API는 분명 훌륭하게 작동했지만, 매 요청마다 가격을 변경하거나, 엔드포인트(Endpoint)를 중단시키거나, 혹은 마음대로 속도 제한(Throttle)을 걸 수 있는 벤더(Vendor)에게 작은 양보를 하고 있다는 기분이 들었습니다. 저는 그 주말 내내 식어버린 커피 한 잔과 해당 제공업체에 보낼 반쯤 작성된 사직서를 옆에 둔 채, 더 나은 대안을 찾기로 결심하며 시간을 보냈습니다.

제가 발견한 것은 AI 인프라(Infrastructure)에 대한 제 생각을 완전히 바꾸어 놓았습니다. 이것은 제가 어떻게 오픈 모델(Open models)을 중심으로 캡셔닝 파이프라인(Captioning pipeline)을 재구축했는지, 그리고 그렇게 한 이후 왜 밤에 잠을 훨씬 더 잘 잘 수 있게 되었는지에 대한 이야기입니다. 만약 여러분이 벤더 계약을 체결할 때마다 가려운 느낌(불안함)을 느끼는 엔지니어라면, 이 글이 도움이 될 것입니다.

2026년의 현실: 184개의 모델, 그리고 계속 늘어나는 중

대형 마케팅 팀이 여러분이 알기를 원치 않는 사실이 하나 있습니다. 바로 현재 Global API는 단일 통합 엔드포인트(Unified endpoint)를 통해 184개의 서로 다른 AI 모델을 노출하고 있으며, 가격은 100만 토큰(Tokens)당 0.01달러에서 3.50달러까지 다양하다는 점입니다. 이 숫자 하나만으로도 "우리의 독점 모델(Proprietary model)이 필요합니다"라는 영업 방식이 분기마다 점점 설득력을 잃어가고 있다는 것을 알 수 있습니다.

제가 이 문제에 이토록 깊이 신경을 쓰는 이유는 실용적인 이유 이전에 철학적인 이유 때문입니다. 모델이 독점 API 뒤에 감싸여 있을 때, 여러분은 진정한 고객이 아니라 세입자(Tenant)에 불과합니다. 제공업체가 가중치(Weights)를 소유하고, 로드맵(Roadmap)을 소유하며, 속도 제한(Rate limits)을 소유하고, 가격 결정 위원회를 소유합니다. 그 위에 의미 있는 워크로드(Workload)를 구축하는 순간, 여러분은 단기적인 편의를 위해 아키텍처의 자유(Architectural freedom)를 맞바꾼 것입니다. 저는 이 패턴에 충분히 데인 적이 있기에, 이제는 가능할 때마다 기본적으로 오픈 웨이트(Open weights) 모델을 선택합니다.

Apache 2.0 및 MIT 라이선스를 가진 모델들 — 즉, 원한다면 다운로드하고, 검사하고, 미세 조정(fine-tune)하고, 자체 호스팅(self-host)할 수 있는 모델들 — 은 이미지 캡셔닝(image captioning)을 포함한 대부분의 작업에서 폐쇄형 소스(closed-source) 모델들과 대등하거나 이를 능가할 수 있을 정도로 성숙했습니다. 이것은 파격적인 주장이 아닙니다. 벤치마크(benchmark) 결과입니다.

내가 단일 벤더 파이프라인(Single-Vendor Pipelines)을 신뢰하지 않게 된 이유

제가 한계점에 도달했던 상황을 설명하겠습니다. 당시 우리는 단일 폐쇄형 제공업체를 통해 한 달에 약 120만 건의 캡셔닝 요청을 처리하고 있었습니다. 모델 자체는 괜찮았습니다. 문서(documentation)도 적절했습니다. 대시보드(dashboard)도 예뻤습니다. 하지만 어느 화요일 오후, 해당 제공업체에 지역적 장애(regional outage)가 발생했을 때, 저의 전체 인제스션 큐(ingestion queue)가 6시간 동안 밀려버렸습니다. 저에게는 폴백(fallback)도 없었습니다. 미러(mirror)도 없었습니다. 대응할 수 있는 수단도 없었습니다. 상태 페이지(status page)에는 결국 "완화됨(mitigated)"이라고 표시되었고, 그것이 대화의 끝이었습니다.

같은 주에, 저는 한 주요 제공업체가 30일 전 통보하고 가격 계층(pricing tiers)을 변경하여, 영향을 받은 회사가 새로운 컨텍스트 윈도우(context window)에 맞추기 위해 프롬프트 템플릿(prompt templates)을 재작성하느라 허둥지둥해야 했던 유사한 사건을 설명하는 블로그 포스트를 읽었습니다. 오늘 당신이 의존하고 있는 폐쇄형 소스 모델은 내일이면 지원이 중단된(deprecated) API 엔드포인트가 될 수 있습니다. 이것은 비관론이 아닙니다. 제가 지금까지 함께 일해온 모든 독점 플랫폼(proprietary platform)의 역사입니다.

오픈 웨이트(Open weights) 모델은 이 상황을 뒤집습니다. 만약 모델이 Apache 2.0 라이선스로 Hugging Face에 있다면, 저는 특정 커밋(commit)을 고정(pin)할 수 있습니다. 테스트를 위해 로컬에서 실행할 수 있습니다. 양자화(quantize)할 수 있습니다. 포크(fork)할 수 있습니다. 제가 원하는 것은 무엇이든 할 수 있으며, 아무도 새벽 2시에 저를 뒤통수칠(rug-pull) 수 없습니다. 그러한 주권(sovereignty)은 벤치마크 정확도의 단 1% 포인트보다 더 가치가 있습니다.

우리 CFO를 미소 짓게 만든 비용 수치들

이제 구체적인 내용을 살펴보겠습니다. 저는 수십 개의 SDK를 번갈아 사용할 필요가 없도록 Global API를 통합 진입점으로 사용하여, 제가 접근할 수 있는 모델들 간의 캡셔닝 비용을 신중하게 비교했습니다. 아래의 모든 수치는 100만 토큰당 입력/출력 가격입니다:

DeepSeek V4 Flash: $0.27 / $1.10, 128K 컨텍스트 (context)
DeepSeek V4 Pro: $0.55 / $2.20, 200K 컨텍스트 (context)
Qwen3-32B: $0.30 / $1.20, 32K 컨텍스트 (context)
GLM-4 Plus: $0.20 / $0.80, 128K 컨텍스트 (context)
GPT-4o: $2.50 / $10.00, 128K 컨텍스트 (context)

GPT-4o 열을 보십시오. 잠시만 들여다보세요. GLM-4 Plus와 비교했을 때 입력 비용은 약 9배, 출력 비용은 9배 더 지불하고 있습니다. 캡셔닝 (Captioning) 워크로드 — 즉, 중요한 이미지뿐만 아니라 모든 이미지에서 실행될 수 있을 만큼 충분히 저렴해야 하는 작업 — 의 관점에서 볼 때, 이러한 가격 차이는 단순한 반올림 오차 수준이 아닙니다. 이는 실행 가능한 제품과, 누군가가 "정말로 이게 필요한 게 맞습니까?"라고 묻는 분기별 이사회 회의 사이의 차이입니다.

대량 처리 경로(bulk path)에는 DeepSeek V4 Flash를, 긴 컨텍스트 검토 경로(long-context review path)에는 Qwen3-32B를 혼합하여 사용하는 방식으로 전환한 후, 월간 지출이 58% 감소했습니다. 500개의 무작위 샘플에 대한 간단한 인간의 스팟 체크 (spot-check)로 측정한 품질 차이는 오차 범위 내에 있었습니다. 품질이 완전히 동일했다면 100% 승리라고 불렀겠지만, 실제로는 긴 형식의 캡션 (long-form captions)에서 품질이 아주 미세하게 향상되었습니다. 더 큰 컨텍스트 윈도우 (context window) 덕분에 요청당 모델에 더 많은 메타데이터 (metadata)를 제공할 수 있었기 때문입니다.

800줄의 벤더 글루 (Vendor Glue) 코드를 대체한 코드

현재 생태계에서 제가 좋아하는 점 중 하나는 통합 코드가 얼마나 지루해졌는가 하는 점입니다. 여기 제가 프로덕션에 배포한 실제 캡셔닝 클라이언트가 있습니다. 특정 제공업체의 특이 사항을 처리하기 위한 맞춤형 재시도 로직 (retry logic)도, 서명된 요청 형식 (signed request formats)도, 독점적인 스트리밍 프로토콜 (proprietary streaming protocol)도 없습니다. 그저 순수한 OpenAI 호환 호출일 뿐입니다.

import openai
import os
import base64
...

이것이 클라이언트의 전부입니다. 저는 대량 처리 경로를 위해 이를 비동기 래퍼 (async wrapper)를 통해 실행하며, 데이터베이스 쓰기 작업을 포함해도 전체 파이프라인은 약 200줄 정도입니다. 예전에 사용했던 800줄의 벤더 글루 (vendor glue) 코드와 비교해 보십시오. 그 코드의 절반은 예고 없이 변경되는 속도 제한 헤더 (rate limit headers)를 처리하기 위해 존재했습니다.

더 풍부한 출력이 필요한 긴 컨텍스트 배치 작업 (long-context batch jobs)의 경우, 단 하나의 파라미터 변경만으로 더 큰 모델로 교체합니다:

import openai
import os

...

핵심은 이 모델들이 독보적으로 놀랍다는 것이 아닙니다. 핵심은 추상화 계층(abstraction layer) — 즉, HTTP API 규약(contract) — 이 특정 벤더의 분기별 수익 전략이 아닌, 개방형 표준(open standard)에 의해 소유되고 있다는 점입니다. 저는 클라이언트를 다시 작성하지 않고도 호출하는 모델을 변경할 수 있습니다. 원한다면 언제든 자체 호스팅하는 vLLM 인스턴스에 대해 동일한 코드를 실행할 수도 있습니다. 그 선택권(optionality)이야말로 실제 제품입니다.

고생하며 배운 다섯 가지 사항

이 시스템을 프로덕션(production) 환경에서 6개월간 운영한 결과, 실제로 우리에게 유의미한 변화를 가져다준 관행들은 다음과 같습니다. 이론적인 수치 대신 현실적인 수치를 누군가 미리 알려주었으면 하는 바람에서, 실제 적중률(hit-rate) 수치를 포함했습니다.

공격적으로 캐싱(Cache)하세요. 우리의 특정 워크로드(workload)에서 40%의 적중률을 달성했습니다. 많은 사용자가 거의 중복된 이미지를 업로드하며, 지각 해시(perceptual hash) 매칭을 통해 저장된 캡션을 즉시 반환합니다. 그 40%는 곧바로 비용 절감으로 이어집니다. 캐시 자체는 MIT 라이선스 서버에서 실행되는 Redis 클러스터일 뿐이며, 특정 벤더에 대한 의존성은 없습니다.
대화형 UI를 위해 응답을 스트리밍(Stream)하세요. 제가 테스트한 모델들의 평균 지연 시간(latency)은 초당 약 320 토큰의 처리량(throughput)과 함께 약 1.2초였습니다. 스트리밍은 체감 지연 시간을 극적으로 줄여줍니다. 사용자는 200ms 이내에 첫 단어들을 보게 되며, 나머지 부분은 눈치채지 못합니다. 이것은 성능 향상 기술이 아니라 UX 트릭이며, 제가 시도한 모든 모델에서 효과가 있었습니다.
단순한 쿼리는 더 저렴한 모델로 라우팅(Route)하세요. 저희는 경량 분류기(classifier)를 사용하여 "이 제품 사진을 설명해줘"와 같은 요청은 GLM-4 Plus로 보내고, 정말 복잡한 장면을 위해서만 더 큰 모델을 예약해 둡니다. 이러한 단순한 라우팅 결정 덕분에 쉬운 경로에서의 요청당 비용을 약 50% 절감했습니다. 단순한 제품 사진에서의 품질 차이(quality delta)는 구별할 수 없을 정도였습니다.
품질을 지속적으로 모니터링하세요. 저희는 사용자가 수정한 캡션을 암묵적인 품질 신호(quality signal)로 추적합니다. 특정 이미지 카테고리에 대해 사용자가 생성된 캡션을 30% 이상의 빈도로 직접 다시 작성한다면, 이는 프롬프트(prompt)나 모델을 조사해야 한다는 신호입니다.

벤치마크(benchmark)만 믿지 마세요 — 실제 벤치마크는 바로 당신의 사용자입니다.

실제 폴백 체인(fallback chain)을 구축하세요. 이는 대부분의 팀이 생략하는 부분입니다. 기본 모델이 속도 제한(rate-limited)에 걸리거나 5xx 에러를 반환하면, 우리는 자동으로 다른 모델로 재시도합니다. OpenAI 호환 인터페이스(OpenAI-compatible interface) 덕분에 이 작업은 매우 간단합니다. 폐쇄형 소스(closed-source) 환경에서는 각 제공업체가 서로 다른 SDK와 서로 다른 에러 의미론(error semantics)을 사용하기 때문에 이것이 불가능한 경우가 많습니다. 표준화는 그 자체로 하나의 기능(feature)입니다.

수치가 실제로 말해주는 것

여러분이 이곳에 온 이유가 무엇인지 알기에, 주요 수치들을 한곳에 모아 정리해 보겠습니다. 제가 2026년에 실행 중인 워크로드(workload) 전반에서, Global API를 통한 오픈 웨이트(open-weight) 친화적인 경로는 다음과 같은 결과를 제공하고 있습니다:

교체 전 폐쇄형 소스 기준점(baseline) 대비 40-65% 비용 절감
초당 320 토큰 처리량(throughput)에서 평균 지연 시간(latency) 1.2초
캡셔닝 평가 스위트(captioning evaluation suite) 전반에서 평균 84.6% 벤치마크 점수
통합 SDK를 통해 초기 설정부터 첫 요청까지 10분 미만 소요

그 84.6%라는 점수에 대해서는 부연 설명이 필요합니다. 이것은 "지구상 최고의 점수"는 아닙니다. 하지만 품질이 더 이상 차별화 요소가 되지 않을 만큼 충분히 높은 점수이며, 이는 곧 비용, 지연 시간, 그리고 자유도가 차별화 요소가 된다는 것을 의미합니다. 이것들이 바로 오픈 생태계가 승리하는 차원이며, 그 격차는 좁혀지는 것이 아니라 오히려 벌어지고 있습니다.

더 큰 철학적 관점은 제가 특정 기술에 종속(locked in)되지 않았다는 점입니다. 만약 다음 달에 더 나은 오픈 모델이 출시된다면, 저는 오후 한때 만에 그것을 채택할 수 있습니다. 만약 Global API의 가격 정책이 변경된다면, 저는 동일한 웨이트(weights)를 사용하는 셀프 호스팅(self-hosted) 인스턴스로 경로를 전환할 수 있습니다. 만약 더 나은 경제성을 가진 새로운 애그리게이터(aggregator)가 출시된다면, 설정(config) 변경만으로 전환할 수 있습니다. 그러한 선택권(optionality)은 실질적인 재무적 가치를 지닙니다. 이는 언제든 어떤 계약으로부터든 벗어날 수 있는 옵션이며, 이는 기반이 되는 모델들이 오픈되어 있기 때문에 가능한 일입니다.

제가 영업사원처럼 들릴 수도 있는 부분 (하지만 진심입니다)

대부분의 개발자 블로그 게시물에 스며들어 있는 강요적인 "우리 것을 사용하세요"라는 분위기를 싫어하기 때문에, 이 부분에서는 조심스럽게 말하고 싶습니다. 그러니 제가 실제로 어떻게 생각하는지 그냥 말씀드리겠습니다.

만약 당신이 2026년에 이미지 캡셔닝 (Image Captioning)을 평가하고 있다면, 단일 벤더 (single-vendor)와 계약하기보다는 최소한 멀티 모델 게이트웨이 (multi-model gateway)를 대상으로 테스트해 보는 것이 스스로를 위한 도리입니다. 긴 평가 끝에 제가 선택한 것은 Global API였으며, 가입 시 제공되는 100개의 무료 크레딧은 제 실제 워크로드 (workload)로 실제 프로덕션 스타일의 파일럿 (pilot)을 실행하기에 진정으로 충분했습니다. 저는 현재의 모델 조합을 한 분기가 아닌 단 한 오후 만에 결정했습니다. 이러한 종류의 빠른 피드백 루프 (feedback loop)가 바로 개방형 생태계 (open ecosystems)가 지향해야 할 모습입니다.

원하신다면 한번 확인해 보세요. global-apis.com입니다. 가격 페이지는 정직하고, SDK는 OpenAI와 호환되므로 아무것도 다시 작성할 필요가 없으며, 약 10초 안에 184개의 모델 카탈로그를 확인할 수 있습니다. 만약 귀하의 워크로드에 맞지 않더라도, 이 글을 읽는 데 걸린 시간 외에는 잃을 것이 없습니다. 만약 잘 작동한다면, 벤더 종속 (vendor lock-in)에 대한 불안감이 어깨에서 사라져 저처럼 숙면을 취할 수 있게 될지도 모릅니다.

오늘 당신이 의존하고 있는 폐쇄형 소스 (closed-source) 모델은 내일이면 지원이 중단된 엔드포인트 (deprecated endpoint)가 될 수 있습니다. 그에 따라 현명하게 선택하십시오.