지난주에 한 SaaS 회사 CTO 분과 점심을 먹었다. 그는 노트북을 열더니 두 장의 견적을 나란히 보여줬다. 한쪽은 월 API 사용료 청구서, 다른 한쪽은 자체 GPU 서버 구축 견적. "800만 원을 넘겼습니다. 매달. 이대로 6개월 더 가면 그 돈으로 서버를 사는 편이 낫지 않냐고 결재판이 되돌아왔어요."
이 질문은 지난 회에서 다룬 PoC 예산의 논의가 자연스럽게 다음 단계로 넘어간 형태다. PoC가 끝나고 서비스가 실제로 트래픽을 받기 시작하면, 그 다음 결재판에는 반드시 이 그림이 올라온다. 자사 LLM을 구축할 것인가, API로 계속 갈 것인가.
가격 구조가 다르다는 것부터
결재판 위에서 두 선택지를 비교할 때 가장 먼저 헷갈리는 지점은, 두 방식이 서로 다른 종류의 지출이라는 사실이다. API는 변동비다. 이번 달에 요청이 두 배 오면 청구서도 두 배가 된다. 자사 구축은 고정비에 가깝다. 서버가 100건을 처리하든 100만 건을 처리하든, GPU가 켜져 있는 한 시간당 비용은 거의 같다.
그래서 손익분기라는 표현이 성립한다. 사용량이 낮을 때는 API가 압도적으로 싸고, 어느 지점을 넘어가면 고정비를 감당할 만큼의 물량이 나와 자체 구축이 이득이 되는 구간이 생긴다. 문제는 그 지점이 사람들이 흔히 상상하는 것보다 훨씬 위쪽에 있다는 것이다.
2026년 현재의 가격 감
구체적인 숫자를 놓고 보자. 2026년 8월 기준으로 주요 API의 100만 토큰당 가격은 대체로 다음과 같다.
- OpenAI GPT-5.5 (프론티어): 입력 5달러 / 출력 30달러
- Anthropic Claude Sonnet 4.6: 3달러 / 15달러
- Claude Haiku 4.5: 1달러 / 5달러
- OpenAI GPT-5.4 Nano (초저가): 0.2달러 / — (초경량 태스크용)
자체 구축 쪽은 어떨까. Llama 3.1 70B급 오픈웨이트 모델을 vLLM으로 8x H100 서버(시간당 약 19.2달러)에서 초당 2,800토큰 처리량으로 돌리면, 이론적으로는 100만 토큰당 1.9달러 수준까지 내려간다. Cloudzy나 GIGAGPU 같은 벤더의 2026년 벤치마크에서 반복적으로 인용되는 수치다.
1.9달러라는 숫자만 보면 자체 구축이 매우 매력적으로 보인다. GPT-5.5의 입출력 평균 대비로는 열 배 넘게 싸다. 그러나 이 숫자에는 큰 전제가 붙어 있다. "GPU가 꽉 차서 돌아갈 때에 한해서"다.
손익분기점의 실제 위치
여러 2026년 분석 자료가 반복해서 언급하는 구간은 다음과 같다. 프론티어 API(GPT-5, Claude Opus급)를 자체 오픈웨이트 70B 모델로 대체할 경우 월 1억 6천만~2억 5천만 토큰이 손익분기 근처다. 저가 API(Haiku, GPT Nano) 대비로는 월 5천만~1억 토큰이 최소선이고, 실제로는 이보다 훨씬 더 많은 트래픽이 있어야 자체 구축이 이득으로 넘어간다.
1억 토큰이라는 숫자는 감이 잘 안 온다. 챗봇 응대 한 건에 평균 3천 토큰이 오간다고 치면, 약 3만 3천 건의 대화다. 하루 1천 건씩 한 달을 채워야 3만 건이니, 웬만한 사내 도구나 초기 서비스는 이 근처에 오지도 못한다. 앞서 800만 원 청구서 이야기를 꺼낸 회사도 실제 소비량을 뽑아보니 월 4천만 토큰 정도였다. 손익분기의 절반 지점이었다.
결재판에 안 적히는 항목들
정직하게 말하면, 위의 계산은 순수 인프라 비용만 놓고 본 것이다. 자체 구축을 결정하면 결재판에는 잘 안 올라가지만 회계 장부에는 반드시 찍히는 항목이 있다.
모델 서빙을 운영하는 엔지니어 인건비. GPU가 죽었을 때 새벽 세 시에 일어날 사람. 오픈웨이트 모델을 프론티어급으로 끌어올리는 파인튜닝 실험 비용. 벤더 API가 자동으로 관리해주던 안전 필터링을 사내에서 새로 구축하는 개발 비용. 데이터 유출 사고에 대비한 보안 감사. 여러 벤더 리포트가 이런 숨은 비용이 TCO를 30~50% 부풀린다고 지적한다.
이 점이 중요하다. 손익분기 계산에서 나온 "월 1억 토큰"이라는 숫자에 이 인건비·운영비를 얹으면, 실제 경제적 손익분기는 대략 두 배 위쪽으로 밀린다. 월 2억~3억 토큰 정도 되어야 자체 구축이 진짜로 싸다는 결론이 나온다는 뜻이다. 이 정도 볼륨을 소화하는 국내 회사는 사실 그리 많지 않다.
그럼에도 자체 구축을 택하는 세 가지 경우
그렇다면 자체 구축은 아직 이르다는 결론일까. 반드시 그렇지는 않다. 손익분기와는 별개의 축에서 자체 구축이 합리적인 경우가 세 가지 있다.
첫째, 데이터가 밖으로 나가면 안 되는 경우. 의료 기록, 미공개 재무 데이터, 미출시 제품의 설계 문서. 이런 데이터를 상용 API에 보내는 것 자체가 규정 위반인 조직이 있다. 여기서는 손익분기라는 개념 자체가 성립하지 않는다. 애초에 API가 선택지에 없다.
둘째, 응답 지연에 극도로 민감한 서비스. 대화당 100ms 안에 답이 나와야 하는 실시간 상호작용은 프론티어 API의 네트워크 왕복 시간을 견디지 못한다. 이 경우 자체 서빙이 성능 요건이지 비용 문제가 아니다.
셋째, 벤더 종속을 피해야 하는 장기 전략. 3년 뒤에도 이 서비스가 살아있을 것이 확실하고, 그때의 API 가격 협상권을 지금부터 확보하고 싶은 회사. 이 경우 초기 2년의 손해는 기꺼이 감수한다.
가장 많이 채택되는 답: 하이브리드
실제 현장에서 결재를 통과한 결정을 여럿 지켜보면, 순수 API도 순수 자체 구축도 아닌 중간 답을 선택하는 회사가 가장 많다. 예측 가능하고 대량으로 처리되며 복잡도가 낮은 태스크(문서 분류, 요약, 정형 데이터 추출)는 자체 호스팅한 오픈웨이트 모델로 보내고, 복잡한 추론이나 갑작스러운 트래픽 폭증은 API로 라우팅하는 방식이다. 이 조합으로 총비용을 30~50% 낮췄다는 케이스 리포트가 여러 벤더에서 반복적으로 나온다.
다만 하이브리드는 겉보기보다 훨씬 복잡한 구조라는 점을 기억해야 한다. 두 시스템 사이의 라우팅 로직, 캐싱 계층, 실패 시 자동 우회 처리를 만드는 데 최소 3~4개월의 엔지니어링 공수가 든다. 결재판에 "하이브리드로 갑니다"라고 적으면 담당자는 반드시 이 초기 개발비를 함께 계상해야 한다.
결재를 통과시키는 판단 프레임
결정 앞에서 헷갈릴 때 실무자들이 쓸 수 있는 간단한 프레임이 있다.
지금 월 API 청구서가 500만 원 이하라면, 자체 구축은 아직 이르다. API에서 최적화할 여지가 훨씬 크다. 프롬프트 캐싱, 저가 모델로의 라우팅, 배치 API 활용만으로 30~40%는 쉽게 줄어든다. 청구서가 1,500만 원을 넘기 시작하면 하이브리드 검토를 시작할 시점이다. 이때부터는 자체 구축 파일럿을 병렬로 돌려볼 가치가 있다. 청구서가 5,000만 원을 지속적으로 넘으면 자체 구축의 손익분기가 손에 잡히기 시작한다.
여기에 데이터 민감성과 응답 지연 요건을 얹어 최종 결정을 내린다. 앞서의 CTO는 그 자리에서 계산기를 두드려보고, 우선 프롬프트 캐싱과 모델 라우팅으로 3개월간 최적화한 뒤 다시 판단하기로 결론을 냈다. 상당수의 회사가 실제로는 이 첫 단계에서 자체 구축의 필요성 자체가 사라지곤 한다.
다음 회 예고
이번 회에서는 도입가와 사용량 기준의 손익분기까지만 다뤘다. 그런데 앞에서 잠깐 언급한 "운영 인력, 재학습, 감시 비용" 같은 지속 비용은 그 자체로 다음 회의 주제다. 도입 첫 달에는 안 보이지만 1년 뒤 결재판에서 반드시 문제가 되는 항목들이다. 다음 회는 "눈에 안 보이는 비용 — 운용·유지보수·재학습"을 이어서 다룰 예정이다.
5years+는 한국과 일본의 중견·중소 기업 대상으로 이런 손익분기 계산과 하이브리드 아키텍처 설계를 지원해왔다. 지금 결재판 위에 자체 구축 견적이 올라와 있다면, 결정을 서두르기 전에 한 시간 정도 함께 계산해보는 상담부터 권한다. 결재판을 지연시키는 것이 결재를 통과시키는 것보다 훨씬 큰 비용을 아끼는 경우가 실제로 많다.