# OpenRouter 5.5% 수수료, AI 원가는 그다음
> AI 서비스 가격을 정하기 전, 토큰 단가와 플랫폼 수수료에 실제 작업 완료율을 함께 대입하는 방법을 살펴봐요.
- 출처 사이트: 머니피셜 (https://aifficial.net/money/posts/openrouter-success-cost/)
- 발행: 2026-09-11
- 카테고리: AI 사업 · 태그: AI 사업, 수익 구조, OpenRouter, 원가
## 핵심 답변
iMessage용 AI 비서 Olly의 운영자 Mo Moustafa는 2026년 9월 7일, 요청이 정상 처리됐다는 응답을 받고도 고객에게 보여줄 답변이 비었던 경험을 공개했어요. 작은 AI 서비스를 팔 때는 이런 재작업까지 계산해야 해요. OpenRouter 종량제의 플랫폼 수수료는 5.5%이며, 모델 사용료와 지원 비용을 모아 실제 완료된 고객 작업 수로 나누면 판매 가격을 정할 기준이 생겨요.
## 한 장 요약(만화)
## 요약
- iMessage AI 비서 Olly의 운영자 Mo Moustafa는 9월 7일, 정상 처리 코드 HTTP 200을 받고도 답변이 비었던 사례를 공개했어요. 고객에게 결과를 줬는지가 원가 계산의 출발점이에요.
- OpenRouter 종량제 가격표는 플랫폼 수수료 5.5%와 모델별 토큰 사용료를 따로 안내해요. 실제 결제·사용 내역을 대조해 비용을 기록해요.
- 가령 총비용 12달러로 작업 80건을 끝냈다면 건당 원가는 0.15달러예요. 호출 100번으로 나눈 0.12달러와 달라요. 이는 계산 방법을 보여주는 가상 예시예요.
## 핵심 사실
| 항목 | 값 |
|---|---|
| 운영 회고 | 2026-09-07 (Olly 운영자 Mo Moustafa) |
| 플랫폼 수수료 | 5.5% (OpenRouter 종량제 가격표, 2026-09-11 확인) |
| 원가 분모 | 완료된 작업 수 (편집자가 제안하는 관리 기준) |
## 고객은 호출 횟수가 아니라 완성된 결과에 돈을 내요
동네 가게에 상품 설명을 만들어 주는 AI 도구를 판다고 해볼게요. 고객은 사진을 올리고 설명문을 기다려요. 서버가 요청을 받았더라도 설명이 비어 있다면 그 주문은 아직 끝나지 않았어요. 다시 생성하거나 직접 고쳐서 전달하는 일이 판매자에게 남아요.
실제로 iMessage용 AI 비서 Olly를 운영하는 Mo Moustafa는 9월 7일 회고에서 HTTP 200을 받았는데 답변 본문은 비었던 경험을 공개했어요. HTTP(Hypertext Transfer Protocol)는 웹 요청과 응답을 주고받는 규약이고, 200은 요청을 정상 처리했다는 상태 코드예요. 택배 접수증이 나왔다고 상자 안의 물건까지 확인된 것은 아닌 것처럼, 이 코드만으로 고객에게 쓸 수 있는 답변이 도착했는지는 알 수 없어요.
## 같은 모델도 실행을 맡는 곳이 달라요
OpenRouter는 앱이 여러 AI 모델과 실행 제공사에 연결할 수 있게 하는 서비스예요. 모델은 답변을 만드는 학습된 시스템이고, 제공사(provider)는 그 모델을 서버에서 실행하는 사업자예요. 같은 요리법을 여러 주방이 사용하는 장면을 떠올리면 두 역할을 구분하기 쉬워요. 공식 문서는 가동 상태와 가격 등을 고려하는 제공사 선택 방식을 설명해요.
이 그림은 저렴한 모델을 찾은 뒤에도 확인할 일이 있음을 보여줘요. 상품 설명 작성이라면 사진 속 물건을 맞게 읽는지, 고객이 원하는 길이와 형식으로 결과가 나오는지를 직접 시험할 수 있어요. 제공사를 바꾼 뒤에도 같은 작업으로 비교해야 차이를 알아보기 쉬워요.
## 가격표와 청구 내역을 함께 펼쳐요
OpenRouter 종량제 가격표는 플랫폼 수수료 5.5%를 표시하고, 토큰 가격은 선택한 모델에 따라 달라진다고 안내해요. 토큰(token)은 AI가 글을 처리하는 조각이에요. 입력한 문장과 생성된 답변의 양이 모델 사용료에 영향을 줘요. 5.5% 하나를 전체 AI 원가로 읽으면 실제 모델 사용료가 빠져요.
앱은 프로그램 연결 인터페이스(application programming interface, API)를 통해 모델에 작업을 요청하고 답변을 받아요. 실무에서는 고객 작업마다 식별 번호를 붙이고 그 작업에 연결된 요청·재시도·실제 청구액을 모아보세요. 크레딧 구매 비용과 사용량 장부를 맞추면 같은 비용을 중복해서 더하는 일도 줄일 수 있어요. 실패나 재시도라는 이름만으로 과금 여부를 정하기보다 실제 기록을 사용하는 방식이에요.
## 100번 호출했어도 80건만 끝났다면
아래는 특정 서비스의 실적이 아니라 계산을 위한 가상 예시예요. 한 묶음의 고객 작업에서 실제 모델·플랫폼 비용이 10달러, 지원에 쓴 시간을 비용으로 환산한 금액이 2달러라고 가정해요. 호출은 100번이었지만 고객이 쓸 수 있는 결과를 전달한 작업은 80건이에요.
| 같은 총비용 12달러를 나누는 기준 | 계산 | 의미 |
| --- | --- | --- |
| API 호출 100번 | 12 ÷ 100 = 0.12달러 | 호출 한 번당 비용 |
| 완료 작업 80건 | 12 ÷ 80 = 0.15달러 | 고객 작업 한 건을 끝내는 비용 |
이 경우 판매자가 가격에 반영할 출발점은 완료 작업당 0.15달러예요. 여기에 포함하지 않은 결제 수수료·고정 운영비와 원하는 이익도 고려해야 해요. 실제 유료 주문을 받기 전 대표 작업 한 묶음을 시험하고, 완료 기준과 수정 횟수를 기록하면 무제한 요금제와 건별 요금제 중 무엇이 어울리는지도 판단할 재료가 생겨요.
제게 흥미로웠던 것은 정상 처리 표시 뒤에 고객의 일이 그대로 남을 수 있다는 대목입니다. AI를 붙이면 작업이 빨라질 것이라 기대하지만, 빈 답변을 받은 고객이 문의하는 순간에는 운영자가 다시 일을 맡게 됩니다. 작은 AI 상품의 원가는 모델이 쓴 토큰뿐 아니라 그 빈자리를 누가 채우는지에서 드러나는 것 같습니다.
지난 [TypingMind 사례](/money/posts/typingmind-first-week-22k/)에서는 앱 이용권과 AI 사용료를 나눠 누가 비용을 부담하는지 분명히 했습니다. 내 제품이 사용료까지 포함해 받는 방식이라면 반대로 어디까지 책임지고 완성해 줄지를 먼저 정할 필요가 있을 것 같습니다. 예를 들어 상품 설명 초안 한 개를 주는 서비스와 고객이 만족할 때까지 수정해 주는 서비스는 같은 모델을 써도 판매자가 맡는 일이 다릅니다.
가격표를 쓰기 전에 고객 한 사람의 작업을 처음부터 끝까지 따라가 보면 어떨까 싶습니다. 자동으로 끝나는 순간과 사람이 다시 손대는 순간을 구분하면, 무엇을 자동화하고 무엇에 별도 값을 붙일지 더 선명해질 것 같습니다. 여러분의 고객은 어떤 결과를 받아야 이 일이 끝났다고 느낄까요?
## 자주 묻는 질문
**Q. 실패한 요청도 전부 유료인가요?**
오류 코드만으로 실제 청구 여부를 판단하면 안 돼요. 사용 내역의 청구액과 답변 내용을 대조하고, 고객에게 쓸 수 있는 결과가 전달됐는지도 별도로 기록하세요.
**Q. 가장 싼 제공사로 고정하면 되나요?**
대표 작업의 답변 품질과 완료율을 먼저 비교해 보세요. 대체 제공사를 제한하면 장애 때 선택할 수 있는 경로도 줄어들어요.
## 출처
1. [Olly 운영자의 직접 경험 (2026-09-07)](https://mmoustafa.com/blog/so-you-want-to-use-openrouter/) (official)
2. [OpenRouter 공식 가격표](https://openrouter.ai/pricing) (official)
3. [OpenRouter 공식 제공사 선택 문서](https://openrouter.ai/docs/guides/routing/provider-selection) (official)
_이 문서는 머니피셜 편집부가 작성했습니다. 인용 시 출처를 표기해 주세요._