OpenAI 통합 코드를 재작성하지 않고 AI API 비용을 절감한 방법

LLM으로 애플리케이션을 구축한다면, 모델 자체는 종종 가장 쉬운 부분입니다.

골치 아픈 부분은 나중에 찾아옵니다.

처음에는 하나의 제공업체로 시작합니다. 그러다가 다른 모델도 테스트해보고 싶어집니다. 곧 여러 개의 API 키, 다양한 가격 구조, 다른 엔드포인트, 별도의 청구 계정, 그리고 프로젝트 전반에 걸쳐 여기저기 흩어진 제공업체별 코드를 갖게 됩니다.

저 역시 AI 애플리케이션을 구축하면서 정확히 이런 문제에 직면했습니다.

여러 AI 제공업체를 사용하는 것의 문제점

애플리케이션이 여러 모델 패밀리에 접근해야 한다고 가정해 봅시다:

• 일반적인 추론 및 코딩에는 GPT
• 긴 형식 작업에는 Claude
• 다른 가격/성능 옵션으로는 Gemini
• 저렴한 워크로드로는 DeepSeek

각 제공업체를 직접 사용하면 여러 통합을 유지해야 함을 의미할 수 있습니다.

API가 비슷해 보여도 인증, 모델 이름, 엔드포인트, 청구 및 가용성은 다를 수 있습니다.

또한 두 번째 문제점인 비용이 있습니다.

실험, 에이전트, 대량의 토큰을 처리하는 애플리케이션의 경우 API 비용은 놀라울 정도로 빠르게 상당해질 수 있습니다.

그래서 저는 두 가지를 원했습니다:

1. 여러 모델 제공업체를 위한 하나의 인터페이스.
2. 애플리케이션을 재작성하지 않고도 더 저렴한 모델이나 경로를 선택할 수 있는 능력.

OpenAI 호환성이 이를 훨씬 쉽게 만듭니다

유용한 접근 방식은 OpenAI API 형식으로 표준화하는 것입니다.

제공업체를 변경할 때마다 애플리케이션 로직을 바꿀 필요 없이, 본질적으로 동일한 요청 구조를 유지하고 기본 URL과 모델만 변경하면 됩니다.

예를 들어, OpenAI Python SDK를 사용하는 애플리케이션은 대략 다음과 같을 수 있습니다:

from openai import OpenAI

client = OpenAI(
...

중요한 부분은 몇 줄의 코드가 아닙니다.

애플리케이션이 더 이상 단일 모델 제공업체에 강하게 결합될 필요가 없다는 점입니다.

결국 저는 이것을 MandAPI로 만들었습니다

이 문제를 해결하는 과정에서, 저는 OpenAI와 호환되는 멀티 모델 API 게이트웨이인 MandAPI를 구축했습니다.

아이디어는 의도적으로 간단합니다:

하나의 API 형식, 하나의 API 키로 여러 AI 모델 패밀리 이용.

개발자들은 GPT, Claude, Gemini, DeepSeek과 같은 다양한 모델 패밀리의 모델들을 OpenAI와 호환되는 인터페이스를 통해 접근할 수 있습니다.

이는 가격 실험을 훨씬 용이하게 만듭니다.

만약 특정 워크로드가 가장 비싼 모델을 필요로 하지 않는다면, 애플리케이션을 재설계하지 않고도 더 저렴한 모델로 전환할 수 있기 때문입니다.

AI API 비용 측면에서 이것이 중요한 이유

흔히 하는 실수는 모든 요청에 가장 성능이 뛰어난(capable) 모델을 사용하는 것입니다.

실제 애플리케이션에서는 워크로드가 보통 혼합되어 있습니다.

어떤 요청은 강력한 추론(reasoning) 능력을 필요로 합니다.

다른 요청들은 단순 추출, 분류(classification), 재작성, 요약 또는 대화형 작업입니다.

더 나은 아키텍처는 다음과 같을 수 있습니다:

복잡한 추론
        ↓
고성능 모델
...

여러 모델이 호환되는 인터페이스를 공유하게 되면, 이 방식으로 워크로드를 라우팅하는 것이 훨씬 쉬워집니다.

토큰 사용량이 많은(high-token) 애플리케이션의 경우, 그 차이는 상당할 수 있습니다.

모델을 헤드라인 가격만으로 비교하지 마세요

토큰 가격은 중요하지만 유일한 변수는 아닙니다.

AI API를 비교할 때, 저는 이제 다음 사항들을 고려합니다:

• 입력 토큰 가격(input token price)
• 출력 토큰 가격(output token price)
• 컨텍스트 제한(context limits)
• 모델 품질(model quality)
• 지연 시간(latency)
• 스트리밍 지원(streaming support)
• 호환성(compatibility)
• 가용성(availability)
• 결제 마찰도(payment friction)
• 내 워크로드에 대한 실제 비용(actual cost for my workload)

서류상 가장 저렴한 모델이 애플리케이션에 가장 저렴한 모델인 것은 아닙니다.

수용 가능한 답변을 생성하는 데 두 배의 시도가 필요한 모델은 실제로는 더 많은 비용이 들 수 있습니다.

멀티 모델 API는 추상화 계층(abstraction layer)으로도 유용합니다

쉽게 과소평가되는 또 다른 이점이 있습니다: 제공업체 종속성(provider lock-in)을 피하는 것입니다.

사용자의 애플리케이션이 특정 제공업체에 맞춰 설계되기보다는 인터페이스와 통신하게 됩니다.

이는 다음 작업을 더 쉽게 만듭니다:

• 새로운 모델 벤치마킹(benchmark)
• 가격 변동 시 모델 변경
• 폴백 경로 추가(add fallback routes)
• 더 저렴한 대안 테스트
• 워크로드 마이그레이션
• 모델 라우팅 시스템 구축(build model-routing systems)

이러한 방식은 AI 모델의 가격 책정 및 기능이 매우 빠르게 변화함에 따라 더욱 유용해집니다.

다음 개발 계획

저는 MandAPI를 API 게이트웨이이자 모델/가격 연구 프로젝트로서 계속 작업하고 있습니다.

제가 특히 관심을 가지고 있는 분야 중 하나는 투명한 LLM 가격 비교입니다.

이에 따라 기본적인 개발자 리소스와 가격 연구 내용을 GitHub에 공개적으로 게시하기 시작했습니다:

MandAPI Developer Kit

목표는 개발자들이 마케팅 페이지가 아닌 실제 API 경제성을 기반으로 모델을 비교하는 것을 더 쉽게 만드는 것입니다.

또한, 브라질을 포함하여 국제 결제가 불편할 수 있는 시장에서 AI API를 구매하고 사용하는 과정을 더 쉽게 만드는 데도 특히 관심이 있습니다.

마지막 생각

다른 제공업체(provider)와 실험하기 위해 반드시 여러분의 AI 애플리케이션 전체를 재작성할 필요는 없습니다.

OpenAI와 호환되는 추상화 계층(abstraction layer)을 사용하면 모델 전환이 놀라울 정도로 간단해질 수 있습니다.

그리고 모델 전환이 간단해지면, 가격은 고정된 것이 아니라 지속적으로 최적화할 수 있는 요소가 됩니다.

만약 상당한 API 사용량을 가진 AI 제품을 구축하고 있다면, 처음부터 모델 이식성(model portability)을 고려하여 설계하는 것이 가치가 있습니다.

다른 개발자들은 다중 모델 라우팅(multi-model routing)과 API 비용을 어떻게 처리하고 있는지 듣고 싶습니다.