오픈웨이트 모델은 토큰의 29%를 쓰고 비용은 4% 미만이었다

모델 선택을 이야기할 때 보통 품질과 가격표를 먼저 본다. 그런데 실제 서비스 트래픽을 모아 보면 다른 장면이 나온다. Vercel이 공개한 AI Gateway Production Index의 2026년 7월 보고서는 6월 데이터를 기준으로 오픈웨이트 모델이 게이트웨이 토큰의 29%를 처리했지만 지출 비중은 4% 미만이었다고 말한다.

이 숫자는 "오픈웨이트가 더 싸고 무조건 낫다"는 결론이 아니다. 토큰 사용량과 지출은 서로 다른 축이고, Vercel의 집계는 작업 품질이나 고객별 비용을 보여주지 않는다. 그래도 어떤 일을 어떤 모델에 맡길지 다시 나눠 볼 근거는 된다.

Vercel AI Gateway 6월 데이터에서 오픈웨이트 토큰 비중 29%와 지출 비중 4% 미만을 서로 다른 축으로 비교한 도표

그림 1. 토큰량과 지출은 서로 다른 축이다. Vercel의 6월 집계를 같은 비율로 읽으면 안 된다. 출처: vercel.com/blog/ai-gateway-production-index-july-2026.

토큰은 늘었지만 평균 가격은 거의 움직이지 않았다

Vercel에 따르면 AI Gateway의 토큰 사용량은 전월보다 29%, 지출은 27% 늘었다. 두 증가율이 비슷했기 때문에 6월의 토큰당 평균 가격은 거의 평평했다. 5월에는 지출이 사용량보다 두 배 넘게 빠르게 늘면서 토큰당 비용이 약 20% 올랐지만, 6월에는 그 현상이 이어지지 않았다.

이 수치는 모델 가격표의 단순 비교가 아니다. 실제 게이트웨이에서 어떤 모델이 어떤 비중으로 호출됐는지에 대한 집계다. 프롬프트 길이, 캐시, 출력 토큰, 할인 조건이 다른 서비스의 청구서를 그대로 설명해 주지는 않는다.

오픈웨이트의 사용량과 지출 사이에 큰 간격이 있었다

보고서에서 오픈웨이트 모델은 4월 토큰량의 11%에서 6월 29%로 올라갔다. 지출에서는 4% 미만이었다. Vercel은 이 흐름의 큰 부분을 DeepSeek의 성장으로 설명한다. DeepSeek는 6월 토큰량의 22.6%를 차지해 Google의 24%에 근접했고, Anthropic이 가장 큰 비중을 유지했다.

Anthropic, Google, DeepSeek의 AI Gateway 토큰량 비중을 보여주는 가로 막대 도표

그림 2. Vercel은 DeepSeek의 6월 토큰량 비중을 22.6%, Google을 24%로 보고했다. 출처: vercel.com/blog/ai-gateway-production-index-july-2026.

여기서 읽을 수 있는 것은 사용량의 분화다. 기업 트래픽이 하나의 최고가 모델에만 모이지 않고, 비용과 지연시간이 다른 모델들로 나뉘고 있다는 뜻이다. 다만 어떤 요청이 오픈웨이트로 이동했는지, 품질이 같았는지, 고객이 직접 선택했는지는 이 자료만으로 알 수 없다.

운영에서는 모델을 한 줄로 고르지 않는 편이 낫다

오픈웨이트 모델을 배치 작업, 초안 작성, 대량 분류처럼 오류를 다시 검사할 수 있는 일에 배치할 수 있다. 반대로 승인, 외부 시스템 변경, 긴 도구 호출처럼 실패 비용이 큰 작업은 더 비싼 모델을 쓰거나 별도의 검증 단계를 붙일 수 있다.

토큰량과 지출을 측정한 뒤 작업 위험도에 따라 모델을 배치하는 세 단계 의사결정 도표

그림 3. 모델 선택은 가격표가 아니라 작업의 실패 비용과 측정 결과에 맞춰 나눌 수 있다. 출처: vercel.com/blog/ai-gateway-production-index-july-2026.

이런 구분은 모델 이름보다 작업의 실패 비용을 먼저 보게 한다. 높은 토큰량이 곧 낮은 품질을 뜻하지도 않고, 높은 가격이 곧 좋은 결과를 보장하지도 않는다. 자신의 로그에서 토큰 수, 재시도, 지연시간, 사람의 수정량을 같이 봐야 실제 선택이 맞는지 알 수 있다.

집계 지표만으로는 판단할 수 없는 것

Vercel의 지수는 공급자별 사용량과 지출의 흐름을 보여준다. 작업 성공률, 고객별 마진, 응답 지연, 개인정보가 포함된 요청의 비중은 보여주지 않는다. 따라서 이 글의 29%와 4% 미만은 운영 결정을 끝내는 숫자가 아니라 측정을 시작하게 하는 숫자다.

Vercel AI Gateway 집계가 제공하지 않는 작업 품질, 고객별 비용, 인과적 채택 설명의 세 한계

그림 4. 공급자 집계는 질문을 만들지만 작업 품질과 고객별 비용을 대신 측정하지 않는다. 출처: vercel.com/blog/ai-gateway-production-index-july-2026.

실무에서 먼저 할 일은 간단하다. 모델별로 토큰량과 지출을 같은 기간에 묶고, 작업 유형별 성공률과 재시도율을 붙인다. 그 다음에야 값싼 모델을 더 많이 쓰는 것이 이득인지, 검증 비용까지 포함하면 오히려 비싼지 비교할 수 있다.

참고 자료

이 글은 Vercel이 공개한 2026년 7월 지수와 6월 데이터 설명을 바탕으로 작성했다. Vercel의 집계를 독립적으로 재실행하거나 고객별 비용을 재계산한 글은 아니다. 원고 구성과 표현 정리에 AI 도구를 사용했다.

댓글

댓글 쓰기

이 블로그의 인기 게시물

체크아웃은 분리됐는데 Git 상태는 공유된다: Codex 0.154 worktree의 세 경계

이미지
1. --worktree 가 해결하는 충돌은 무엇인가 에이전트 두 개가 같은 저장소에서 동시에 파일을 고치면 가장 먼저 부딪히는 것은 모델이 아니다. 한쪽이 바꾼 작업 트리와 인덱스를 다른 쪽이 읽고, 테스트 산출물이 섞이고, 아직 정리하지 않은 변경을 다음 작업이 자기 입력으로 오해한다. OpenAI는 GitHub 기준 2026년 9월 9일 22:35 UTC, 한국 시각 10일 07:35에 공개한 Codex 0.154.0에 실험적 managed worktree 기능을 넣었다. 새 실행이나 기존 세션의 fork를 --worktree 로 시작할 수 있고, TUI에서는 /worktree 로 새 대화 또는 현재 대화의 fork를 별도 체크아웃에 둘 수 있다. 공식 릴리스 설명은 이를 "isolated checkouts"라고 부른다. 다만 이 표현을 저장소 전체와 외부 환경까지 격리한다는 뜻으로 읽으면 곤란하다. Git worktree가 분리하는 것은 체크아웃의 파일과 작업별 관리 상태다. Git 공식 문서에 따르면 연결된 worktree는 HEAD , index 같은 파일을 따로 갖지만 나머지 저장소 데이터는 공유한다. 따라서 같은 소스 파일을 동시에 편집하는 충돌은 줄일 수 있어도, 같은 원격 브랜치에 push하거나 같은 배포·테스트 데이터베이스를 건드리는 충돌까지 사라지지는 않는다. 그림 1. Codex 0.154 managed worktree는 체크아웃 생성과 thread 소유권을 연결한다. binding 전 실패 시 체크아웃을 보존한다. 출처: github.com/openai/codex/releases/tag/rust-v0.154.0 . 2. Codex는 새 체크아웃을 어떻게 만든다 0.154.0 태그가 가리키는 커밋의 codex-rs/worktree/src/lib.rs 를 보면 생성 순서가 꽤 보수적이다. 먼저 현재 HEAD 를 commit SHA로 확정한다. 그 SHA에서 git worktree add --detach --...
자세한 내용 보기

잠근 작업이 커밋 뒤 다시 나온다: PostgreSQL 에이전트 큐의 소유권 설계

이미지
1. 잠금은 작업을 소비했다는 기록이 아니다 에이전트 작업자를 여러 개 띄웠다. 각 작업자는 PostgreSQL에서 FOR UPDATE SKIP LOCKED 로 작업 하나를 가져온다. 다른 작업자가 잡은 행을 기다리지 않으니 병렬 처리도 잘되는 것처럼 보인다. 그런데 커밋한 뒤 같은 작업이 다시 나온다면 무엇이 빠진 걸까? 핵심은 행을 잠갔다는 사실과 작업을 맡았다는 상태가 서로 다르다 는 점이다. PostgreSQL 공식 문서는 행 잠금이 트랜잭션 종료 때 풀린다고 설명한다. SKIP LOCKED 는 지금 즉시 잠글 수 없는 행을 건너뛰는 옵션이지, 그 작업을 영구히 큐에서 제거하는 명령이 아니다. 공식 PostgreSQL 18.0 소스의 회귀 테스트에도 이 차이가 드러난다. 상태를 바꾸지 않고 조회만 하는 순서에서 세션 A가 작업 1을 잠그면 B는 작업 2를 받는다. A가 커밋한 뒤 B가 다시 조회하면 작업 1이 나온다. 프로젝트가 저장한 기대 출력과 별도로, 이번 글에서는 PostgreSQL 16.2의 격리된 로컬 DB 에서도 이 순서를 실제 확인했다. 문서와 고정 소스는 18 계열, 직접 실행한 엔진은 16.2다. 두 버전을 같은 실험으로 섞거나 최신 버전의 성능 측정이라고 부르지 않는다. 그림 1. 잠금이 해제돼도 작업 상태가 그대로면 같은 작업이 다시 선택된다. 공식 18.0 기대 출력과 별도 16.2 로컬 확인에 근거한 자체 도식. 출처: www.postgresql.org/docs/18/sql-select.html . 조회 결과가 0행일 때도 해석에 주의해야 한다. 모든 후보가 다른 작업자에게 잠겨 있으면 SKIP LOCKED 는 아무것도 반환하지 않을 수 있다. 로컬 확인에서는 일반 조회로 보이는 행이 2개인데 잠금 건너뛰기 조회는 0행이었다. 따라서 “지금 가져올 작업이 없다”와 “큐 자체가 비었다”는 같은 말이 아니다. 공식 문서 역시 이 옵션이 일반적인 일관된 조회에는 적합하지 않고, 큐와 비슷한 테이블의 여러 소비자 사이 경합을...
자세한 내용 보기

코딩 에이전트는 API 문서보다 AGENTS.md를 먼저 읽었다

이미지
코딩 에이전트를 위한 문서를 만든다고 하면 보통 API 레퍼런스나 상세한 개발 가이드부터 떠올린다. 그런데 실제 에이전트의 작업 기록을 분석한 연구에서는 다른 문서가 훨씬 자주 등장했다. AGENTS.md , CLAUDE.md 같은 지시 파일과 계획·작업 노트였다. 2026년 8월 공개된 논문 From Agent Behaviour to Agent-Friendly Documentation 은 공개된 코딩 에이전트 세션과 풀 리퀘스트를 이용해 에이전트가 어떤 문서를 읽고 쓰는지 조사했다. 연구진이 분석한 데이터는 다음과 같다. SWE-chat의 파싱 가능한 세션 557개 개발 이벤트 94,813개 문서 관련 이벤트 3,033개 AIDev의 에이전트 풀 리퀘스트 33,097개 파일·커밋 단위 변경 기록 690,260개 에이전트가 가장 자주 만진 문서 문서 상호작용에서 가장 큰 비중을 차지한 것은 에이전트 지시 파일이었다. 문서 유형 이벤트 수 비중 에이전트 지시 파일 1,074 35.4% 계획·작업 노트 760 25.1% 작업 및 요구사항 문서 301 9.9% 설정 문서 205 6.8% README 197 6.5% API 레퍼런스 40 1.3% 지시 파일과 작업 노트를 합하면 전체 문서 상호작용의 60.5%다. API 레퍼런스는 1.3%에 그쳤다. 지시 파일이 API 레퍼런스보다 약 27배 많이 관찰된 셈이다. 코딩 에이전트의 문서 관련 이벤트 분포. 지시 파일과 계획·작업 노트가 전체의 60.5%를 차지했다. 출처: Gao & Chen, arXiv:2608.20195v1 . 이 수치를 "API 문서는 필요 없다"고 해석하면 곤란하다. 연구가 추적한 것은 저장소 안에서 명시적으로 열린 파일이다. 웹 문서, 모델이 이미 학습한 지식, 코드 주석, 런타임이 자동으로 주입한 문맥은 잡히지 않는다. 정확한 결론은 코딩 에이전트가 저장소 안에서 작업할 ...
자세한 내용 보기