전자신문이 8월 6일 전한 OpenRouter 주간 집계에서 DeepSeek V4 Flash 가 주간 7조 2,200억 토큰 호출로 1위에 올랐다. 중국 모델이 14주 연속 강세라는 내용이었다.
이런 순위표를 보면 팀에서 바로 질문이 온다. “우리도 바꿔야 하나요.” 매번 같은 답을 한다. 사용량 순위는 성능 순위도, 적합성 순위도 아니다. 그렇다고 무의미한 것도 아니다. 무엇을 재는 숫자인지 알고 보면 쓸모가 있다.
토큰 호출량이 재는 것과 재지 않는 것
OpenRouter 는 여러 모델을 한 창구로 중계하는 서비스다. 그 집계에서 1위라는 건 그 창구를 지나간 토큰이 가장 많았다는 뜻이다. 여기서 바로 따라 나오는 사실이 하나 있다 — 이 숫자는 답변 품질과 무관하게 커진다.
같은 작업을 해도 컨텍스트를 길게 넣는 사용 패턴이면 토큰이 늘고, 값이 싸면 시험 삼아 돌려 보는 호출이 늘어 또 토큰이 는다. 자동화 파이프라인에 물려 두면 사람이 한 번도 안 읽는 호출도 집계에 잡힌다.
그렇다고 버릴 숫자는 아니다. 사용량이 크다는 건 생태계가 붙는다는 뜻이다. 예제가 쌓이고, 라이브러리가 대응하고, 문제가 생겼을 때 검색해서 나오는 글이 많아진다. 도입 비용에서 이 부분은 생각보다 크다.
업무에 붙일 때 내가 실제로 보는 네 축
모델을 업무에 붙인다는 건 벤치마크 점수를 사는 게 아니라 실패했을 때의 처리 방식까지 사는 것이다. 그래서 나는 순위표 대신 네 가지를 본다.
① 형식 안정성
업무 자동화에서 가장 자주 깨지는 건 문장 품질이 아니라 형식이다. JSON 을 달라고 했는데 앞에 설명을 붙이거나, 표의 열 수가 호출마다 달라지는 식이다. 한 번 깨지면 뒤 공정이 통째로 멈추므로, 나는 평균 품질보다 최악의 출력이 얼마나 나쁜지를 본다.
확인하는 방법은 단순하다. 같은 요청을 서른 번쯤 돌려 놓고 출력이 스키마를 벗어난 횟수를 센다. 평균 품질은 이 시험에서 안 보이지만, 파이프라인을 세우는 건 언제나 그 벗어난 몇 번이다. 실무에서 모델을 되돌린 사례는 대체로 “답이 나빠서”가 아니라 “형식이 흔들려서”였다.
② 데이터가 어디서 처리되는가
이건 성능 문제가 아니라 규정 문제다. 사내 문서를 넣는 순간 그 데이터가 어느 나라 어느 사업자의 인프라를 지나는지가 검토 대상이 된다. 거버넌스와 권한 범위를 정리해 두지 않은 조직일수록 이 질문이 나중에, 그것도 가장 곤란한 시점에 나온다.
③ 응답 지연의 분포
평균 응답 시간은 별로 쓸모가 없다. 사람이 화면 앞에서 기다리는 작업이면 꼬리 지연(가끔 아주 느린 호출)이 체감을 지배하고, 야간 배치라면 평균만 봐도 된다. 같은 모델이 용도에 따라 합격도 되고 불합격도 된다.
재는 방법도 평균이 아니라 분포로 잡는다. 100회쯤 호출해 가장 느린 다섯 번이 몇 초였는지를 본다. 이 값이 사람 기다리는 화면에서는 사실상의 성능이다.
④ 못 쓰게 됐을 때의 대체 경로
가격 정책이 바뀌거나 지역 제한이 걸리면 어떻게 할지를 붙이기 전에 정해 둔다. 대체 경로가 없는 모델은 싸도 싼 게 아니다.
중계 서비스 한 곳만 통해 쓰고 있다면 그 서비스가 곧 단일 장애점이다. 모델 자체는 멀쩡한데 중계가 막혀서 못 쓰는 상황이 실제로 더 흔하다.
단가 비교는 왜 자주 틀리나
모델을 바꿀지 정할 때 가장 먼저 꺼내는 게 100만 토큰당 단가인데, 이 숫자만으로 계산하면 대체로 틀린다. 실제 비용은 세 군데서 더 붙는다.
첫째, 입력 토큰이 출력보다 훨씬 많다. 사내 문서를 넣는 작업이면 입력 대 출력 비율이 수십 대 일까지 벌어진다. 출력 단가가 싼 모델을 고르고 정작 입력 단가를 안 봤다가 예상보다 몇 배가 나오는 일이 흔하다.
둘째, 재시도가 비용이다. 형식이 흔들리는 모델은 검증에서 걸러 다시 부른다. 다섯 번에 한 번씩 다시 부르면 그만큼 단가가 오른 것과 같다. ①번 축이 결국 돈 이야기이기도 한 이유다.
셋째, 사람이 고치는 시간은 어디에도 안 잡힌다. 출력을 사람이 손보는 공정이 남아 있으면 그 시간이 진짜 원가인데, 단가표에는 안 나온다. 나는 이걸 재려고 “손 안 대고 그대로 쓴 비율”을 따로 센다.
네 축으로 다시 세운 비교
구체적인 점수를 매기는 대신, 어떤 상황에서 어느 쪽이 유리한지를 정성으로 정리했다. 특정 제품의 벤치마크 수치를 옮겨 적지 않는 이유는 그 수치가 버전마다 바뀌고, 무엇보다 내 업무 데이터로 잰 값이 아니어서다.
표에서 ‘유형’으로 적은 데는 이유가 있다. 제품 이름을 박아 두면 6개월 뒤에 틀린 글이 되는데, 성향은 그보다 오래간다. 저비용 신규 모델이 형식 안정성을 확보하고 기업 계약 선택지를 갖추는 순간 그 칸은 옮겨 가고, 실제로 지난 2년 동안 몇 번 옮겨 갔다.
상황별로는 이렇게 고른다
- 대량 분류·요약 배치 — 저비용 모델이 유리하다. 형식만 고정되면 단가 차이가 그대로 남는다.
- 사내 문서가 들어가는 작업 — 처리 위치 검토가 끝나기 전엔 어떤 모델도 붙이지 않는다.
- 사람이 기다리는 대화형 — 꼬리 지연을 먼저 재고, 여기서만큼은 단가를 후순위로 둔다.
- 한 번 만들고 오래 두는 파이프라인 — 형식 회귀가 적은 쪽. 나중에 손보는 시간이 단가보다 비싸다.
이 목록에서 눈여겨볼 건 단가가 1순위로 오는 칸이 하나뿐이라는 점이다. 단가는 조건이 같을 때 갈라 주는 값이지 조건을 정하는 값이 아니다. 순위표가 위험한 것도 같은 이유다 — 조건을 안 정한 상태에서 답부터 주기 때문이다.
덧붙이면 이 선택은 배타적이지 않다. 같은 조직에서 용도별로 다른 모델을 쓰는 게 정상이고, 그때 필요한 건 순위표가 아니라 도구를 고르는 절차다.
이 비교의 한계
위 표는 유형별 성향이지 특정 제품의 측정값이 아니다. DeepSeek V4 Flash 를 포함해 개별 모델의 형식 안정성·지연 분포는 내 업무 데이터로 직접 재 보지 않으면 알 수 없고, 그 값은 버전이 바뀌면 같이 바뀐다.
한 가지만 덧붙이면, 재 보는 비용 자체는 생각보다 싸다. 실제 업무 요청 서른 개를 모아 두고 후보 모델에 한 번씩 돌리는 데 반나절이면 충분하고, 그 반나절이 순위표를 읽는 시간보다 훨씬 많은 것을 알려 준다. 남이 잰 숫자로 내 업무를 정하려니까 순위표에 자꾸 기대게 되는 것이다.
그래서 이 글의 결론은 ‘무엇을 써라’가 아니라 ‘무엇을 재고 나서 정하라’에 가깝다. 순위표는 후보를 좁히는 데까지만 쓰고, 좁힌 다음에는 위 네 축을 자기 데이터로 한 번 돌려 보는 편이 결국 빠르다.
이 글에 쓴 근거
- 전자신문(2026. 8. 6.) OpenRouter 주간 AI 모델 사용량 순위 보도 https://www.etnews.com/20260806000140
- 네 축(형식 안정성·데이터 처리 위치·지연 분포·대체 경로)과 유형별 비교표는 저자의 도입 검토 기준이며 특정 제품의 측정값이 아니다.
필자는 AI 솔루션 공급사에 재직 중이다. 이 글은 개인 견해이며 소속사 입장과 무관하다. 언급한 모델·서비스와 금전적 이해관계는 없다.
관련 글
실무에서 검증한 AI 활용 기록, 계속 받아보기
이 글에서 다룬 판단 기준과 실패담을 카테고리별로 더 모아뒀습니다.
댓글
0