Anthropic이 특정 모델의 API 가격 체계를 조정한다는 공지가 뜬 날, 한 1인 번역 에이전시 대표는 당장 할 수 없는 일이 생겼습니다. 클라이언트에게 보낸 견적은 그 모델의 토큰 비용을 기준으로 계산했고, 대안 모델이 무엇인지는 알았지만 그 모델로 같은 품질을 내려면 프롬프트를 새로 조정해야 했습니다. 며칠이 걸릴 작업이었습니다. 그동안 클라이언트에게 어떻게 설명할지도 따로 문제였습니다.
이런 상황을 한 번도 겪어보지 않은 사람은 운이 좋았거나, 아직 겪기 전입니다.
결제 인프라 회사 Stripe가 AI 모델 라우터 OpenRouter를 인수한다는 보도가 나왔습니다. OpenRouter는 Claude, GPT-4, Gemini, Llama 같은 여러 AI 모델 사이로 트래픽을 분산하는 서비스입니다. 개발자가 모델을 직접 고르는 대신, 비용이나 성능 기준을 설정하면 그 조건에 맞는 모델로 요청이 자동 배정됩니다. Stripe가 이 회사를 원한 이유는 하나의 베팅으로 읽힙니다. AI 모델이 전기처럼 거래되는 상품이 되면, 그 흐름을 제어하는 라우터가 장기적으로 가격 결정권을 갖는다는 것입니다.
전기를 쓰는 사람은 어느 발전소에서 전기가 왔는지 신경 쓰지 않습니다. 가격과 안정성만 보면 됩니다. AI 모델이 그 방향으로 가고 있다는 신호가 쌓이고 있습니다. 2023년 초 GPT-3.5 수준의 작업을 처리하는 데 1,000토큰당 0.002달러가 들었습니다. 지금 동급 성능의 오픈소스 모델은 같은 작업을 10분의 1 이하 비용으로 처리합니다. 특정 영역에서는 오픈소스 모델이 상용 모델을 앞지르기 시작했고, 독점적 우위를 유지하는 범위는 점점 좁아지고 있습니다.
이 방향에서 개인 사업자에게 실질적인 판단을 요구하는 질문이 있습니다. 지금 쓰는 AI 공급자를 교체할 수 있는가?
어떤 업무가 특정 공급자에만 작동하는지 파악합니다
락인이란 특정 공급자를 교체하는 비용이, 그 공급자의 조건을 받아들이는 비용보다 커지는 상태입니다. AI 사용에서 이 상태는 프롬프트와 연동이 늘어날수록 쌓입니다.
가장 흔한 경로는 프롬프트 방언입니다. 특정 모델의 응답 패턴에 맞게 조정된 프롬프트는 다른 모델에서 같은 결과를 내지 못합니다. Claude는 지시 형식이 명확한 프롬프트에 잘 반응하고, GPT-4는 맥락을 길게 줬을 때 더 나은 결과를 내는 경향이 있습니다. 이 차이에 맞게 프롬프트를 최적화하다 보면, 수십 개가 쌓였을 때는 공급자를 바꾸는 순간 그 전부가 재작업 목록이 됩니다. 처음엔 며칠이면 될 것 같지만, 그 프롬프트들이 실제 워크플로에 연결돼 있으면 영향 범위가 달라집니다.
다음은 API 형식 의존입니다. 특정 공급자의 API 구조에 맞춰 연동을 짜두면, 다른 공급자로 옮길 때 연동 코드 수정이 따릅니다. 직접 코드를 다루지 않는 경우에도 같은 문제가 생깁니다. AI 기능이 탑재된 SaaS 도구를 쓴다면, 그 도구가 내부적으로 어떤 모델에 의존하는지 대부분 명시되지 않습니다. 도구를 바꿀 때 공급자도 함께 바뀌는 구조인지, 도구만 바꾸면 되는지 확인해 두는 것이 먼저입니다.
단가 계산도 점검해야 합니다. "이 작업은 건당 얼마"라는 기준이 특정 모델의 토큰 비용으로 고정돼 있으면, 그 모델의 가격이 오를 때 수익 구조 전체가 영향을 받습니다. 반복 작업을 대량으로 처리하는 경우, 단가 기준 하나가 바뀌면 마진 계산이 통째로 다시 필요합니다.
지금 쓰는 AI 기반 업무 중에서, 내일 공급자를 교체한다고 가정했을 때 멈추는 것이 어디인지 목록으로 적어 보십시오. 이 목록을 의존 지도라 부릅니다. 목록이 비어 있다면 의존이 없거나, 아직 확인을 안 한 것입니다.
교체 압박이 고착을 비용으로 바꾸는 시점
고착 자체가 문제는 아닙니다. 지금 당장 충분히 싸고 충분히 잘 작동하면 상관없습니다. 판단이 필요한 것은 그 상태가 언제까지 유지되는가입니다.
가격 인상은 예고 없이 옵니다. AI API 가격은 지난 2년간 전반적으로 내려갔지만, 전체 추세와 개별 상품은 다릅니다. OpenAI는 GPT-4 출시 이후 특정 기능 가격을 단계적으로 조정해 왔고, Anthropic도 Claude 버전별로 가격 정책이 달라졌습니다. 지금 쓰는 기능이 무료나 저렴한 요금제에 포함돼 있다면, 그 정책이 바뀔 때 어떻게 대응할지 미리 생각해 두어야 합니다.
성능 격차도 바뀝니다. 지금은 A 모델이 특정 작업에서 분명히 낫지만, 6개월 뒤에는 달라질 수 있습니다. 한국어 처리나 코드 생성 같은 영역에서 오픈소스 모델이 빠르게 따라잡고 있습니다. 비싼 공급자를 계속 쓰는 이유가 성능 차이라면, 그 차이가 줄어드는 시점이 교체 타이밍이 됩니다. 이걸 확인하려면 지금 쓰는 모델의 작업을 대안 모델로 주기적으로 테스트해 봐야 합니다.
서비스 중단이나 정책 변화가 가장 예측하기 어렵습니다. 공급자가 특정 기능을 없애거나, 사용 패턴을 제한하거나, 서비스가 수 시간 중단될 때 대안이 없으면 그 시간이 그대로 손실입니다. 2024년에는 주요 AI API 서비스가 일시적으로 중단된 사례가 여러 건 있었습니다. 이런 상황에서 즉시 전환할 수 있는 대안이 있는지 없는지는, 미리 테스트해 본 적이 있느냐에 달려 있습니다.
이런 압박 중 하나라도 생겼을 때 전환 비용이 높으면, 고착이 실제 비용으로 드러납니다.
대안 모델을 써보기 전까지 전환 비용은 추정일 뿐입니다
OpenRouter 같은 라우터를 직접 연동하거나, 멀티모델 아키텍처를 구성하는 것은 지금 당장 1인 사업자에게 현실적인 선택이 아닐 수 있습니다. 하지만 그 이전에 할 수 있는 일이 있습니다.
의존 지도에서 가장 비중이 크거나 바꾸기 어렵다고 생각되는 업무 하나를 골라, 대안 모델로 같은 작업을 실제로 돌려 보십시오. 목적은 당장 옮기는 것이 아닙니다. 두 가지를 측정하는 것입니다.
하나는 결과 품질 차이입니다. 지금 쓰는 모델과 대안 모델의 결과가 실제로 얼마나 다른지, 그 차이가 재작업이 필요한 수준인지 아닌지를 눈으로 확인합니다. "B 모델은 이 작업에 안 맞다"는 막연한 인상이 아니라, "B 모델로 하면 이 부분에서 재작업이 X만큼 필요하다"는 구체적인 근거가 있어야 합니다.
둘은 재조정 범위입니다. 프롬프트 몇 개를 바꿔야 하고, 연동 코드에서 어느 부분을 수정해야 하고, 단가 계산은 어떻게 달라지는지를 직접 추적해 보면 전환 비용의 실제 규모를 알 수 있습니다.
전환이 생각보다 쉽다는 것을 알게 될 수도 있습니다. 예상보다 훨씬 복잡하다는 것을 알 수도 있습니다. 어느 쪽이든 지금 아는 것이 낫습니다. 전환 비용을 모르는 상태에서 조건이 바뀌면, 대응이 아니라 수습이 됩니다.
