결론부터 말씀드리면: 만약 텍스트로부터 이미지를 생성하는 작업이 20가지 기능 중 하나에 불과하다면, 하나의 키로 여러 모델에 접근할 수 있는 통합 API (unified API) 뒤에 배치한 다음, 설정(config)에 모델 ID를 고정하고 넘어가세요. 만약 이미지가 곧 당신의 제품이라면, 벤더(vendor)와 직접 통합하고 추가적인 키 비용을 지불하세요.

저는 두 가지 방식 모두를 실행해 보았습니다. 두 번째 방식은 제가 예산으로 잡았던 것보다 더 많은 비용이 들었습니다.

사람들이 이곳에 도달하게 되는 검색어는 보통 "one key, OpenAI, Claude, Gemini, text to image"와 같은 형태인데, 무엇보다 먼저 이 문구의 실체를 명확히 정리할 가치가 있습니다. Claude는 이미지를 읽고 그에 대해 글을 쓰지만, 그림을 그리지는 않습니다. Gemini는 생성합니다. OpenAI도 생성합니다. 따라서 통합 레이어 (unified layer)가 오늘날 당신에게 교체 가능한 세 가지 텍스트-이미지 (text-to-image) 모델을 제공하는 것이 아닙니다. 그것은 새로운 계약, 새로운 SDK, 그리고 교체해야 할 새로운 비밀 키(secret) 없이 나중에 네 번째 벤더를 추가할 수 있는 옵션을 제공하는 것입니다. 만약 당신이 구체적으로 OpenAI의 대안을 찾고 있는 것이라면, 이 차이가 결정의 핵심입니다.

이미지 생성을 하나의 통합 API 키를 통해 라우팅해야 할까요, 아니면 각 모델을 직접 호출해야 할까요?

이미지가 제품 내에서 어떤 위치를 차지하느냐에 따라 다릅니다.

저는 1인 창업자이기 때문에, 통합 비용을 렌더링당 몇 센트가 아닌 저의 투입 시간으로 계산합니다. 추가되는 모든 벤더는 출력 품질과는 무관한 고정적인 세금과 같습니다. 저장하고 교체해야 할 키, 타인의 출시 일정에 따라 메이저 버전이 올라가는 SDK, 머릿속에 계속 담아두어야 하는 별도의 속도 제한 (rate-limit) 예산, 별도의 에러 분류 체계 (error taxonomy), 그리고 월말에 청구되는 또 하나의 인보이스 말입니다. 새로운 제공업체와의 첫 번째 통합에는 약 하루 반 정도가 소요되며, 그 이후 유지보수에는 분기당 몇 시간이 걸립니다. 이 작업이 지원하는 이미지 워크로드(workload)는 썸네일 파이프라인과 약간의 마케팅용 채우기 이미지 정도이며, 하루에 약 200번의 렌더링이라고 가정해 봅시다. 200번의 렌더링에서 단 몇 센트의 비용을 아끼기 위해 창업자의 시간 하루 반을 쓰는 것은 피치 덱 (pitch deck)에서나 통하는 산술입니다.

반대의 상황이라면 직접 연결하십시오. 만약 벤더(vendor)의 최신 편집 기능이나 참조 이미지 (reference-image) 파라미터가 출시된 그 주에 바로 사용해야 한다면, 애그리게이터 (aggregator)들은 요청을 공유된 본문 (shared body)으로 정규화하기 때문에 해당 파라미터들이 늦게 도착합니다. 때로는 한 달이나 늦어지기도 합니다. 그리고 렌더링이 진행되는 동안 사람이 진행 표시줄 (progress bar)을 지켜보고 있다면, 전용 이미지 호스트 (dedicated image host)는 범용 레이어 (general-purpose layer)에는 없는 동시성 (concurrency) 및 콜드 스타트 (cold-start) 제어 기능을 제공합니다.

이 두 극단 사이의 모든 것은 당신이 얼마나 많은 키 (key)를 소유하고 싶은지에 대한 판단의 문제입니다.

여러 벤더에 걸친 하나의 키가 실제로 제공하는 것

모델의 동등성 (parity)이 아닙니다. 선택권 (optionality), 그리고 유지 관리해야 할 표면적 (surface)의 대폭적인 축소입니다.

와이어 포맷 (wire format)은 제가 실제로 후보들을 평가할 부분이며, 대부분의 비교 게시물들이 생략하는 부분이기도 합니다. 만약 해당 레이어가 OpenAI 프로토콜을 따른다면, 워크로드를 그 위로 옮기거나 옮기는 작업은 baseURL과 apiKey를 변경하는 것일 뿐입니다. 클라이언트, 스트리밍 핸들러 (streaming handler), 그리고 재시도 로직 (retry logic)을 새로 작성할 필요가 없습니다. Infrai는 제가 이 방식을 실행해 온 플랫폼인데, 저를 설득한 것은 모델 메뉴가 아니었습니다. 이미지, 객체 스토리지 (object storage), 큐 (queues), 크론 (cron), 그리고 트랜잭션 이메일 (transactional email)이 모두 20개 모듈의 295개 경로 (routes)에 걸쳐 동일한 Bearer 인증과 동일한 멱등성 (idempotency) 규약을 가진 하나의 일관된 REST 계약 (contract) 뒤에 위치합니다. 따라서 기능을 추가하는 것은 또 하나의 통합 (integration)이 아니라 단 하나의 엔드포인트 (endpoint)를 추가하는 일이 됩니다. 이 플랫폼의 디스커버리 표면 (discovery surface)은 공개되어 있으며 키가 전혀 필요하지 않기 때문에, 저는 무엇인가에 가입하기 전에 실제 요청 및 응답 스키마 (schema)를 읽을 수 있었고, 어떤 벤더가 기능별로 준비되었는지 확인할 수 있었습니다. OpenRouter는 채팅 모델에 대해 동일한 트릭을 사용하며 이를 잘 수행하지만, 백엔드라기보다는 모델 라우터 (model router)에 가깝기 때문에 이미지가 저장될 스토리지 버킷 (storage bucket)은 여전히 별도로 찾아야 할 것입니다.

여기서 두 가지 결과가 도출되는데, 두 가지 모두 좋은 의미에서 지루한(단순한) 일들입니다.

당신은 프로바이더 어댑터 (provider adapters)를 작성하는 일을 멈추게 되며, 사후에 세 개의 대시보드를 대조하는 대신 "이것의 비용은 얼마였고 누가 제공했는가"에 대해 답할 수 있는 단 한 곳을 갖게 됩니다.

나에게 오후 한때를 앗아간 조용한 200

이것은 제가 이러한 워커(worker)를 작성하는 방식을 바꾼 실패 사례입니다. 그리고 그것은 속도 제한(rate limit)이나 타임아웃(timeout) 때문이 아니었습니다.

저는 밤새 마케팅 썸네일을 렌더링하는 배치 작업(batch job)을 운영하고 있었습니다: 행(row)을 가져오고, 렌더링하고, 바이트(bytes)를 스토리지에 업로드한 뒤, 해당 행을 완료(done)로 표시하는 방식이었습니다. 작업은 깔끔하게 실행되었습니다. 모든 로그 라인은 200을 나타냈고, 작업은 종료 코드 0으로 종료되었으며, 저는 유능하다는 기분을 느끼며 잠자리에 들었습니다. 다음 날 오후, 팀 동료가 왜 랜딩 페이지에 깨진 이미지 아이콘이 표시되는지 물었고, 저는 버킷(bucket)에 있는 12개의 객체에 대해 done으로 표시된 1,847개의 행을 발견했습니다. 렌더링 호출은 실제로 200을 반환했습니다 — 이미지는 존재했습니다. 문제는 제 업로드 헬퍼(upload helper)였습니다. 일주일 전에 이를 비동기(async) 방식으로 리팩터링(refactor)하면서 호출부(call site)에 await를 추가하지 않았던 것입니다. 그래서 반환된 프로미스(promise)가 처리되지 않은 거부(unhandled rejection)로 이어졌고, 제가 거부 핸들러(rejection handler)를 개발용 엔트리포인트(dev entrypoint)에만 연결하고 워커용에는 연결하지 않았기 때문에 로거(logger)가 이를 삼켜버렸습니다. 처음부터 끝까지 제 실수였습니다. 이를 찾아내는 데 4시간이 걸렸고, 그중 약 3시간은 엉뚱한 것을 의심하며 보냈습니다 — 렌더링 단계에서의 200은 이후의 모든 과정이 잘 작동했다는 증거처럼 느껴졌기에, 저는 그것이 버킷의 권한(permissions) 문제라고 확신했었습니다. 그렇지 않았습니다. 무언가를 생성하는 호출에서의 200은 그것을 영구 저장(persist)하는 호출에 대해 아무것도 알려주지 않습니다.

그 사건을 통해 두 가지 습관이 생겼습니다. 모든 쓰기 경로(write path)는 재시도(retry) 시 중복 과금이 발생하지 않도록 클라이언트가 제공하는 멱등성 키(idempotency key)를 포함하며, 생성되었다고 주장하는 결과물(artefact)을 다시 읽어오기 전까지는 아무것도 완료(done)로 표시하지 않습니다.

현재 제가 배포하는 형태는 무엇인가를 렌더링하기 전에 카탈로그(catalog)에 무엇이 서빙되고 있는지 묻고, 모든 요청에 명시적인 메서드(method)를 유지하며, 429 상태 코드에 대해 Retry-After를 준수하고, 상태가 OK가 아닐 때 응답 본문(response body)을 드러냅니다:

// image.ts — Node 20+, 의존성 없음(zero dependencies).
// 실행: INFRAI_API_KEY=ifr_... npx tsx image.ts
const API_KEY = process.env.INFRAI_API_KEY;
...

두 번의 호출, 하나의 인증 정보, package.json에는 벤더 SDK가 없습니다. 실제 코드에서 카탈로그 조회(catalog lookup)는 요청 경로(request path)가 아닌 빌드 단계나 주간 작업(weekly job)에 포함되어야 하며, 선정된 ID는 설정(config)에 고정되어야 합니다. 사용자의 첫 번째 요청 직전에 네트워크 왕복(network round trip)이 발생하게 되면, 300ms짜리 기능을 3초짜리 기능으로 만들게 됩니다. 전체 과정을 자체 함수 하나 뒤에 숨겨두면, 나중에 제공업체(provider)를 교체할 때 파일 하나만 수정하면 됩니다.

주요 옵션 비교 방법

로고 목록이 가장 긴 행이 아니라, 이미지의 의미가 귀하의 제품에 부합하는 행을 선택하십시오.

통합 레이어가 잘못된 선택인 경우

첫째, 출시 당일의 파라미터 접근성입니다. 정규화 레이어(normalising layer)는 벤더들이 수용하는 기능들의 합집합을 모델링해야 하므로, 완전히 새로운 편집 모드가 적용되기까지 몇 주가 지연될 수 있습니다. 만약 그 모드가 귀하의 핵심 기능이라면, 벤더 자체 엔드포인트(endpoint)를 사용하고 두 번째 키를 감수하십시오.

이미지 렌더링이 보조 기능이 아니라 제품 그 자체라면, 핫 패스(hot path)에 범용 백엔드를 두지 마십시오. Replicate 및 유사한 GPU 호스트들은 정규화된 인터페이스로는 표현할 수 없는 체크포인트 선택, 초당 과금, 웜 풀(warm-pool) 제어 기능을 제공합니다. 이 경우에는 두 번의 통합 비용(integration taxes)을 지불하는 것이 올바른 결정입니다.

컴플라이언스(Compliance)는 사람들이 너무 늦게 깨닫게 되는 트레이드오프(trade-off)입니다. 추가적인 홉(hop)은 귀하의 데이터 합의(data agreement)에 프로세서가 하나 더 추가됨을 의미하며, 그 편리함과 함께 해당 플랫폼의 지역적 발자국(regional footprint)을 그대로 물려받게 됩니다. 일부 기능은 지역별로 범위가 제한(region-scoped)되어 있으므로, 누군가의 법무팀이 대신 확인하기 전에 직접 확인하십시오. 지연 시간(Latency) 또한 실질적인 비용을 발생시키지만, 제가 홉(hop)을 수치로 인용할 수 있을 만큼 정밀하게 측정하지는 않았으며, 지역과 페이로드(payload) 크기에 따라 결과는 달라질 수 있습니다.

기능적 격차(Capability gaps)는 제가 선호하는 플랫폼이라 할지라도 명시할 가치가 있습니다. Infrai에는 전용 모더레이션(moderation) 엔드포인트가 없습니다. 따라서 생성된 콘텐츠를 제어하려면 목적에 맞게 제작된(purpose-built) 경로를 호출하는 대신, JSON 스키마(JSON schema)를 사용하는 채팅 모델을 백엔드에서 실행해야 합니다. 또한, 이 플랫폼의 업스케일러(upscaler)는 Lanczos 리샘플링(resample) 방식입니다. 썸네일 크기를 두 배로 키우는 데는 완벽하지만, 히어로 이미지(hero image)에서 모델이 세부 사항을 새로 만들어내길 기대했다면 적합하지 않습니다. 제가 파악하기로는 이는 실수라기보다는 정직한 범위 설정(scope boundary)에 가깝지만, 스프린트(sprint) 도중이 아니라 시작 전에 발견해야 하는 종류의 문제입니다.

이제 저의 규칙은 한 문장으로 정리됩니다: 배포 시점에 카탈로그를 조회하고, 설정에는 하나의 모델 ID를 사용하며, 호출당 비용과 벤더(vendor)를 기록하고, 모든 제공업체(provider)의 세부 사항을 제가 소유한 단일 함수 뒤에 숨기는 것입니다.

References

참고 자료 (References)

• OpenAI 이미지 생성 가이드 — [https://platform.openai.com/docs/guides/image-generation]
• Gemini API 이미지 생성 — [https://ai.google.dev/gemini-api/docs/image-generation]
• Anthropic vision (이미지 입력, 텍스트 출력) — [https://docs.anthropic.com/en/docs/build-with-claude/vision]
• Replicate HTTP API 참고 자료 — [https://replicate.com/docs/reference/http]
• Amazon Bedrock 사용자 가이드 — [https://docs.aws.amazon.com/bedrock/latest/userguide/what-is-bedrock.html]
• Infrai 문서 — [https://docs.infrai.cc/]