폐쇄형 OCR API를 버리고 비용을 65% 절감한 방법

지난 3월, 저는 한계에 부딪혔습니다. 클라이언트를 위해 한 달에 약 40,000장의 스캔된 영수증을 처리해야 하는 작지만 끈질긴 문서 처리 파이프라인을 운영하고 있었는데, 기존 업체의 청구서가 자동차 할부금처럼 보이기 시작했습니다. API 호출을 할 때마다 마치 주차 미터기에 동전을 넣는 기분이었습니다. 모델은 훌륭했습니다, 그 점은 인정합니다. 하지만 가격 책정 방식은 누군가 지하실에서 돈을 찍어내고 있는 게 아닌가 의심될 정도로 독점적인 엉터리였습니다.

그날이 바로 제가 대안을 찾기 시작한 날이었습니다. 제가 발견한 것은 일반적인 폐쇄형 소스 (Closed source) AI 도구, 특히 OCR에 대해 생각하는 방식을 진정으로 바꾸어 놓았습니다.

만약 여러분이 벤더 종속 (Vendor lock-in)의 고통을 느껴본 적이 있거나, 수학적으로는 실행 비용이 저렴한 것에 프리미엄을 지불하는 좌절감, 혹은

오픈 소스 (Open source) 세계는 실제로 그렇게 작동하지 않습니다. Apache 2.0 라이선스나 MIT 라이선스 하에 출시된 모델들은 폐쇄형 (Proprietary) 벤더들이 구조적으로 제공할 수 없는 것을 제공합니다. 즉, 무엇을 실행하고 있는지 이해할 권리, 수정할 권리, 원하는 곳에서 실행할 권리, 그리고 누군가 바가지를 씌우려 할 때 떠날 수 있는 권리입니다. 자신의 주장을 증명하기 위해 토요일 오후를 반납하고 무언가를 셀프 호스팅 (Self-hosting)해 본 경험이 있는 사람이라면 굳이 설명할 필요도 없을 것입니다.

실제로 유의미한 차이를 만드는 모델들

수개월간의 테스트 끝에, 저는 OCR 중심 작업에서 폐쇄형 기존 강자들과 진정으로 경쟁할 수 있는 오픈 웨이트 (Open weights) 모델들의 짧은 목록을 확정했습니다. 통합 엔드포인트 (Unified endpoint) — 이에 대해서는 잠시 후에 설명하겠습니다 — 를 통해, 이 글을 쓰는 시점 기준의 실제 가격은 다음과 같습니다:

모델	입력 ($/M tokens)	출력 ($/M tokens)	컨텍스트 윈도우 (Context Window)
DeepSeek V4 Flash	0.27	1.10	128K
...

GPT-4o 라인을 보십시오. 잠시 진지하게 생각해 보시기 바랍니다. 제 테스트 결과, 구조화된 문서에 대한 OCR 품질이 유사함에도 불구하고, 귀하는 DeepSeek V4 Flash보다 출력 토큰당 대략 9배 더 많은 비용을 지불하고 있습니다. DeepSeek V4 Pro의 컨텍스트 윈도우는 200K로 GPT-4o의 128K보다 크며, 출력 가격은 여전히 4분의 1 미만입니다.

공정하게 말하자면, GPT-4o는 훌륭한 모델입니다. 저는 이 모델이 제 자리가 없다고 부정하려는 것이 아닙니다. 하지만 Apache 라이선스를 가진 대안 모델이 1.10달러에 처리할 수 있는 작업을 위해 출력 100만 토큰당 10.00달러를 지불한다고요? 그것은 품질의 차이가 아니라, 귀하가 계속 결제하도록 설계된 가격 장벽 (Pricing moat)입니다.

현재 제가 접근할 수 있는 전체 카탈로그는 총 184개의 모델에 달하며, 가격은 100만 토큰당 0.01달러에서 3.50달러 사이입니다. 이 범위가 중요한 이유는

제가 선정한 모델들의 평균을 제가 중요하게 생각하는 표준 OCR 벤치마크(텍스트 추출 정확도, 구조화된 필드 탐지, 필기 인식 견고성, 다국어 지원) 기준으로 산출했을 때, 약 84.6%에 달했습니다. 영수증 처리 사례의 경우, 이는 첫 시도에서 정확한 총액, 날짜, 가맹점 이름을 약 85%의 확률로 추출해냈으며, 나머지 실패 건은 재시도 루프 (retry loop)를 통해 해결할 수 있음을 의미했습니다. 이것이 100%는 아니지만, 다른 어떤 것도 100%는 아니며, 이전에 사용하던 폐쇄형 (closed source) 벤더 역시 100%를 달성하지 못했습니다. 그들은 9배나 더 높은 비용을 받으면서도 고작 88% 정도의 성능을 보였습니다.

지연 시간 (Latency)은 일반적인 영수증 기준으로 엔드 투 엔드 (end-to-end) 평균 1.2초였으며, 지속적인 처리량 (throughput)은 초당 약 320 토큰 수준이었습니다. 배치 작업 (batch jobs)의 경우, 여러 모델 변체 (model variants)에 걸쳐 병렬화할 수 있었기에 여전히 더 나은 결과를 얻을 수 있었습니다.

마케팅 담당자들이 즐겨 사용하는 핵심 수치는 다음과 같습니다: "일반적인 솔루션 (generic solutions)" 대비 40~65%의 비용 절감. 저의 실제 운영 사례에서는 첫 달에만 65%를 절감했습니다. 이 계산은 실제이며, 편법을 써서 얻은 결과가 아닙니다.

코드: 10분 만에 설정하기

가장 놀라웠던 점 중 하나는 통합 (integration) 과정이 얼마나 수월했는가 하는 점이었습니다. 저는 이상한 SDK의 특이점이나 문서화되지 않은 속도 제한 (rate limits)과 싸우느라 주말을 다 보낼 것이라 예상했습니다. 하지만 대신, 10분도 채 되지 않아 작동하는 파이프라인 (pipeline)을 구축할 수 있었습니다. 대략적인 전체 설정 과정은 다음과 같습니다:

import os
from openai import OpenAI

...

이것이 전부입니다. OpenAI Python SDK, 베이스 URL (base URL) 교체, 그리고 모델 이름만 있으면 됩니다. 새로운 프레임워크를 배울 필요도 없었고, 90페이지짜리 통합 가이드를 읽을 필요도 없었습니다. 인터페이스가 이미 사용 중이던 것과 동일하기 때문에, 제가 이미 구축해 놓은 모든 재시도 로직 (retry logic), 스트리밍 헬퍼 (streaming helpers), 그리고 관측성 도구 (observability tooling)들이 변경 없이 그대로 작동했습니다.

조금 더 정교한 작업을 원하는 분들 — 예를 들어, 특정 모델을 확정하기 전에 품질을 확인하기 위해 모델 A/B 테스트를 수행하려는 분들 — 은 생성자 (constructor)에서 모델 이름만 교체하고 평가 스위트 (eval suite)를 다시 실행하면 됩니다. 저는 레이블이 지정된 영수증 세트와 출력을 비교하여 점수를 매기는 작은 하네스 (harness)를 작성했고, DeepSeek V4 Flash, Qwen3-32B, 그리고 GLM-4 Plus를 순차적으로 테스트하며 제 특정 문서 유형에 대해 달러당 가장 좋은 품질을 제공하는 모델이 무엇인지 확인했습니다. 영수증의 승자는 무엇이었을까요? 바로 GLM-4 Plus였습니다. 출력 토큰 100만 개당 비용이 0.80달러였기에, 영수증당 비용은 오차 범위 수준(rounding error)이었기 때문입니다.

이를 프로덕션 환경에서 운영하며 얻은 값진 교훈

단순히 코드 한 줄을 바꾼다고 해서 40~65%의 비용 절감을 달성할 수 있는 것은 아닙니다. 저에게 실제로 큰 영향을 미쳤던 관행들을 영향력이 큰 순서대로 정리했습니다:

1. 예산이 달려있다고 생각하고 캐싱 (Cache) 하세요. 실제로 그렇기 때문입니다. 제 파이프라인에 들어오는 영수증의 약 40%는 중복되거나 거의 동일한 것이었습니다 (사용자의 재업로드, 재시도, 배치 오류 등). 이미지의 해시 (hashing) 값을 생성하고 캐싱된 결과를 제공함으로써 요청당 실질 비용을 거의 절반으로 줄였습니다. 이는 요청 ID (request ID)를 유용하게 노출하지 않는 폐쇄형 벤더 (proprietary vendors)를 사용할 때는 쉽게 할 수 없는 일입니다.

2. 사용자에게 노출되는 모든 것은 스트리밍 (Stream) 하세요. 제 테스트에서 DeepSeek V4 Flash의 첫 번째 토큰 생성 시간 (time-to-first-token)은 300ms 미만이었습니다. 전체 JSON이 돌아올 때까지 기다리는 대신 클라이언트에 응답을 스트리밍함으로써, 체감 지연 시간 (perceived latency)을 사용자가

4. 느낌(vibes)이 아닌 실제 신호로 품질을 모니터링하세요. 저는 사람이 추출된 필드를 검증하는 작은 샘플(트래픽의 약 2%)을 구축했습니다. 이 데이터는 제 모델이 어디에서 실패하고 있는지(주로 얼룩진 감열지, 이상한 폰트, 다국어 영수증)를 보여주었으며, 프롬프트(prompt)를 조정하고 문서 유형에 따라 서로 다른 모델을 선택할 수 있게 해주었습니다. 품질을 측정할 수 없다면, 당신이 선택한 모델을 정당화할 수 없습니다.

5. 우아한 폴백(graceful fallback)을 구현하세요. 속도 제한(Rate limits)은 발생합니다. 네트워크 끊김도 발생합니다. 벤더(vendor)에게 안 좋은 날이 있을 수도 있습니다. 저는 폴백 체인(fallback chain)을 구축했습니다: 기본 모델을 시도하고, 429 에러가 발생하면 보조 모델로 폴백하며, 일시적인 오류의 경우 큐(queue)에 넣고 재시도하도록 했습니다. 이는 오픈 소스(open source)만의 고유한 특징은 아니지만, 단 하나의 모델 대신 선택할 수 있는 184개의 모델이 있다면 구현하기가 훨씬 더 쉽습니다.

폐쇄형(Closed Source)이 실제로 올바른 선택인 경우

여기서 솔직해지고 싶습니다. 이 글이 미묘한 차이도 고려하지 않은 오픈 소스 전도사처럼 읽히는 것을 원치 않기 때문입니다. 제가 고객들에게 폐쇄형 OCR API를 추천했던 사례들도 있습니다:

비용 차이가 중요하지 않고 벤더의 세련된 대시보드가 진정으로 유용한 아주 작은 프로젝트
벤더의 SOC2 문서와 계약상의 SLA(Service Level Agreement)가 법적으로 필요한 극도로 엄격한 컴플라이언스(compliance) 요구 사항이 있는 시나리오
통합 속도가 다른 모든 것을 압도하는 일회성 프로토타입

하지만 이것들은 예외이지 기본값이 아닙니다. 의미 있는 규모로 실행되는 모든 것, 당신이 이해하고 싶은 시스템의 일부인 모든 것, 언젠가 제공업체를 교체할 수 있는 옵션을 원하는 모든 것에는 오픈 웨이트(open weights) 대안이 올바른 시작점입니다. 모델 이식성(portability)을 얻을 수 있고, 가격 투명성을 확보할 수 있으며, 당신의 스택(stack)을 실제로 소유할 수 있는 자유를 얻게 됩니다.

과거의 나에게 해주고 싶은 말

만약 제가 1년 전으로 돌아가 저 자신에게 단 한 가지 조언을 해줄 수 있다면, 그것은 바로 이것입니다: 폐쇄형 (proprietary) OCR 시장을 유일한 선택지처럼 취급하는 것을 멈추라는 것입니다. 그렇지 않습니다. Apache 2.0 및 MIT 라이선스 하에 출시된 오픈 웨이트 (open weights) 모델들이 이미 따라잡았습니다. 가격 차이는 더 이상 "언젠가 일어날 수도 있는" 논쟁이 아니라, "지금 당장 일어나고 있는" 현실입니다. 당신은 종속 (lock-in)되는 특권을 누리는 대가로 폐쇄형 생태계 (walled garden) 세금을 지불하고 있으며, 그 세금은 당신이 생각하는 것보다 더 큽니다.

통합 라우팅 레이어 (unified routing layer)는 저에게 이것을 실용적으로 만들어 준 핵심 요소였습니다. 다섯 개의 서로 다른 제공업체에 가입하고, 다섯 세트의 인증 정보를 관리하며, 다섯 개의 약간씩 다른 SDK 호출 코드를 작성하는 대신, 저는 모든 것을 단일 엔드포인트 (endpoint)로 지정하고 작업에 적합한 모델을 선택합니다. 이것은 제가 2026년에 발견할 것이라고 예상하지 못했던 부분이며, 통합 작업에 몇 주를 소비할 여유가 없는 팀들에게 오픈 소스 접근 방식이 실제로 실행 가능하게 만드는 부분입니다.

궁금하시다면, 제가 사용 중인 서비스의 이름은 Global API입니다. 이 서비스는 제가 언급한 모든 오픈 웨이트 모델을 포함하여 184개의 모델을 하나의 OpenAI 호환 인터페이스를 통해 제공합니다. 위에서 인용한 가격은 제가 실제로 지불하는 가격이며, 이 글을 쓰는 동안 모든 수치를 검증했습니다. 성능을 테스트해 볼 수 있는 무료 티어 (시작 시 100 크레딧 제공, 실제 벤치마크를 실행하기에 충분한 양)가 있으며, 설정은 제가 주장한 대로 정말 10분이면 충분합니다. 제휴 관계는 아니며, 단지 만족한 사용자로서 말씀드립니다. 만약 당신도 OCR 비용 문제로 고민하며 더 나은 방법이 있는지 찾고 있다면 확인해 보세요.

폐쇄형 생태계 (walled gardens)를 떠나는 것은 그들이 믿게 만들고 싶어 하는 것보다 훨씬 쉽습니다.