OpenAI Realtime API vs 오픈소스 S2S 모델: 비용·인프라·안정성 비교

실시간 음성 에이전트를 만들기로 했다면, 코드를 한 줄 쓰기도 전에 스스로에게 물어봐야 할 질문이 있습니다. OpenAI Realtime API 같은 상용 서비스를 호출해서 빠르게 올릴 것인가, 아니면 오픈소스 Speech-to-Speech(S2S) 모델을 직접 GPU에 띄워 운영할 것인가? 둘 다 "실시간 음성"이라는 결과는 같지만, 비용이 발생하는 방식도, 책임져야 할 인프라도, 장애가 났을 때 누가 새벽에 일어나야 하는지도 전혀 다릅니다. 정답은 "환경에 따라 다르다"이지만 정작 중요한 것은 그 환경을 무엇으로 판단하느냐이며, 이 글에서는 비용 구조·인프라 요구사항·운영 안정성이라는 세 축으로 두 선택지를 비교하고 환경·예산별 선정 가이드를 정리합니다.

[시리즈] S2S·LLM 음성 에이전트 엔지니어링 63편 · 현재 2-2편

← 이전: 2-1 End-to-End S2S 작동 원리 / 다음 → 2-3 음성 토큰(Audio Token)이란

1-4 RAG 병목과 오디오 버퍼링 제어
2-1 End-to-End S2S 작동 원리
2-2 OpenAI Realtime API vs 오픈소스 S2S (현재 글)
2-3 음성 토큰(Audio Token)이란
2-4 감정·톤 조절이 CS를 바꾸는 이유

전체 목차 펼치기 (63편)

Part 1 — 음성 AI가 느린 이유: 레이턴시 진단 (4편)

Part 2 — 텍스트를 넘어: End-to-End S2S의 원리 (4편)

2-1 End-to-End S2S 작동 원리
2-2 OpenAI Realtime API vs 오픈소스 S2S (현재 글)
2-3 음성 토큰(Audio Token)이란
2-4 감정·톤 조절이 CS를 바꾸는 이유

Part 3 — 실시간 대화와 에이전트화: 인터럽트·MCP·도구 (5편)

Part 4 — 인프라·세션·보안: 프로덕션 백엔드 (5편)

Part 5 — 운영·품질·평가: 에이전틱 워크플로우와 신뢰성 (7편)

Part 6 — 음성 경험 고도화·실전 통합: 한국어·UX·전화망·엣지 (5편)

Part 7 — S2S 도입 전략·구매 의사결정 (4편)

Part 8 — LLM 콜봇 PoC 현장 (6편)

Part 9 — 상담어시스트: 상담사 화면을 바꾸는 실시간 AI (7편)

Part 10 — 직접 만든 롤플레이 챗봇: RAG 에이전트 구축기 (8편)

Part 11 — KMS 실무 — 지식관리시스템의 설계와 운영 현실 (8편)

두 갈래의 선택지: 상용 API와 구축형 S2S

먼저 용어를 정리합니다. 상용 Realtime 계열 API는 음성 입력을 보내면 음성 출력이 돌아오는 종단 간 서비스를 네트워크 호출 하나로 제공합니다. 내부적으로 음성 인식, 추론, 음성 합성이 어떻게 묶여 있든 사용자는 신경 쓸 필요가 없습니다.

반면 오픈소스 S2S 모델을 직접 구축한다는 것은, 가중치를 내려받아 추론 서버에 올리고 오디오 스트리밍 파이프라인까지 직접 책임진다는 뜻입니다. 여기에는 진정한 의미의 단일 S2S 모델을 올리는 경우도 있고, 오픈소스 STT·LLM·TTS를 조합해 파이프라인으로 묶는 경우도 포함됩니다. 핵심 차이는 모델 종류가 아니라 "운영 주체가 누구인가"입니다. 상용 API는 벤더가 운영하고, 구축형은 내가 운영합니다. 이 한 문장이 이후의 모든 비용과 책임을 가릅니다.

비용 구조: 사용량 과금 vs 고정비

가장 큰 오해가 "어느 쪽이 더 싼가"를 단일 숫자로 답할 수 있다는 생각입니다. 두 모델은 비용이 쌓이는 방식 자체가 다릅니다.

상용 API는 통상 오디오 입출력 토큰(혹은 분 단위)에 비례하는 종량제입니다. 초기 투자가 사실상 0에 가깝고, 트래픽이 없으면 비용도 없습니다. 대신 사용량이 늘수록 비용이 선형으로 따라 올라갑니다.

구축형은 반대입니다. GPU 임대 또는 구매, 추론 엔진 튜닝, 운영 자동화에 적지 않은 고정비를 먼저 투입합니다. 그 대신 이미 켜둔 GPU 위에서 호출이 늘어날수록 통화 한 건당 단위원가는 떨어집니다. 즉 사용량이 적을 때는 종량제가, 일정 규모를 넘으면 고정비 모델이 유리해지는 손익분기(break-even)가 존재합니다. 실무에서는 보통 동시 통화 규모가 작고 트래픽이 들쭉날쭉할 때는 API가, 충분히 크고 예측 가능한 상시 트래픽이 깔릴 때는 구축형이 경제적이라고 봅니다.

흔히 상용 API는 호출당 단가만 보면 부담이 크지 않다고 생각하기 쉽지만, 실제로 비용을 비교해 보면 생성형 음성 AI는 GPU 토큰 비용이 운영 단계에서 생각보다 가파르게 누적된다는 점을 자주 마주합니다. 기능 검증용 짧은 PoC만 돌려도 청구 금액이 만만치 않게 나오는 게 현실이라, "검증 단계니까 비용은 신경 안 써도 된다"는 가정은 위험합니다. 그래서 상용 API를 택할 때는 호출당 편의만 볼 게 아니라, 트래픽이 조금만 늘어도 누적되는 운영 비용을 출시 전부터 함께 추정해 두는 편이 안전합니다.

비용 항목	상용 API	구축형(오픈소스 S2S)
초기 투자	거의 없음	GPU·엔지니어링 선투자 큼
변동비	사용량에 선형 비례	사용량과 약하게 연동(전력·확장분)
숨은 비용	벤더 가격 정책 변동	MLOps·온콜·모델 업데이트 인력
비용 예측성	트래픽만 알면 명확	사용률에 따라 단위원가 변동

여기서 자주 놓치는 것이 구축형의 "숨은 비용"입니다. GPU 청구서만 보면 싸 보여도, 모델을 패치하고 장애에 대응하는 엔지니어링 시간은 회계상 잘 드러나지 않습니다. TCO(총소유비용)는 인프라 비용이 아니라 사람 비용까지 더한 값이라는 점을 기억해야 합니다.

인프라 요구사항: 무엇을 책임져야 하는가

비용 다음으로 갈리는 것은 운영 책임의 범위입니다.

상용 API를 쓸 때 직접 책임지는 것은 사실상 네트워크 연결, 인증 키 관리, 그리고 일시적 오류에 대한 재시도 로직 정도입니다. GPU는 한 장도 만질 필요가 없습니다.

구축형은 이야기가 완전히 다릅니다. 모델을 올릴 VRAM 용량 산정, 추론 서버, 오디오를 끊김 없이 흘려보내는 스트리밍 파이프라인, 그리고 트래픽에 맞춰 인스턴스를 늘리고 줄이는 오토스케일링을 전부 직접 설계해야 합니다. 특히 음성은 텍스트와 달리 하나의 세션이 통화 시간 내내 살아 있습니다. 요청이 짧게 들어왔다 빠지는 것이 아니라, 통화가 끝날 때까지 GPU 슬롯을 점유한다는 뜻입니다. 그래서 동시성 산정이 핵심이 됩니다.

필요 GPU 인스턴스 수
  = 올림( 피크 동시 통화 수 / 인스턴스당 동시 세션 슬롯 )

여기에 콜드스타트 회피용 예열 인스턴스와
장애 대비 여유분을 더한다.

이 계산을 보수적으로 하지 않으면, 피크 시간대에 슬롯이 모자라 통화가 큐에 밀리거나 끊기는 일이 생깁니다. 반대로 너무 넉넉하게 잡으면 유휴 GPU 비용이 새 나갑니다.

안정성과 운영: SLA, 지연 변동성, 통제권

세 번째 축은 안정성입니다. 여기서도 장단이 분명히 갈립니다.

상용 API의 강점은 벤더의 SLA와 자동 확장에 올라탈 수 있다는 점입니다. 트래픽이 갑자기 튀어도 벤더 쪽 인프라가 흡수합니다. 다만 외부 의존이라는 본질적 리스크가 있습니다. 가격이나 모델 정책이 바뀔 수 있고, 사용 가능한 리전이 제한될 수 있으며, 벤더 장애 시 내가 할 수 있는 일은 기다리는 것뿐입니다. 같은 이유로 이 글의 비용·스펙 비교도 2026년 6월 시점의 공개 정보 기준이라, 실제 선택 시점에는 최신 조건을 다시 확인해야 합니다.

구축형의 강점은 완전한 통제권입니다. 데이터가 외부로 나가지 않게 잔류시킬 수 있고, 모델 버전을 원하는 시점에 고정할 수 있으며, 음색이나 응답 스타일을 깊이 커스터마이즈할 수 있습니다. 대가는 명확합니다. 장애가 나면 그것이 곧 내 책임이고, 지연의 꼬리값(p95·p99)과 콜드스타트를 직접 길들여야 합니다. 체감 응답 지연은 잘 튜닝된 경우 통상 1초 안팎이며, 구축형은 STT·LLM·TTS를 파이프라인으로 묶으면 단계마다 지연이 더해질 수 있습니다. 어느 쪽이든 안정성을 가르는 것은 평균이 아니라 p95·p99 꼬리값입니다. 참고로 이 편에서 말하는 콜드스타트는 인프라·모델 로딩 차원의 지연으로, 04편에서 다룬 검색 캐시와는 별개입니다.

지연 관점에서 한 가지 더 짚어 두면, 모든 처리를 클라우드로 보내는 것이 항상 빠른 길은 아닙니다. 흔히 클라우드 인프라가 물리 위치와 무관하게 항상 더 빠를 거라 생각하기 쉽지만, 특히 STT처럼 실시간성이 핵심인 처리는 실제로 비교해 보면 멀리 있는 클라우드보다 가까운 물리 서버(온프레미스)에서 돌릴 때가 왕복 구간이 짧아 응답이 유의미하게 빠른 경우가 있습니다. 통제권뿐 아니라 순수 속도만 놓고 봐도 온프레미스가 답이 되는 구간이 존재한다는 뜻입니다.

여기서 한발 더 들어가면, 생성형 방식 자체의 응답 속도와 안정성 한계도 함께 따져야 합니다. 생성형은 자연스러움을 주지만 응답이 늘 일정 시간 안에 돌아온다고 보장하기 어렵고, 그 변동성이 곧 통화 품질을 흔듭니다. 그래서 반응 속도가 임계치 안에 들어온다는 보장이 서지 않으면, 정해진 흐름을 빠르고 예측 가능하게 처리하는 룰 베이스가 여전히 현실적인 선택지로 남습니다. 바꿔 말하면 생성형으로의 전환은 "품질이 더 좋아서"만으로 정당화되지 않고, 요구되는 응답 속도를 안정적으로 보장할 수 있다는 전제가 먼저 깔려야 합니다.

환경·예산별 선정 가이드

이제 결론입니다. 다음 여섯 가지 기준에 답해 보면 방향이 잡힙니다. (1) 트래픽 규모와 예측 가능성, (2) 데이터 민감도와 규제, (3) 커스터마이즈 필요도, (4) 팀의 MLOps 역량, (5) 출시 속도 요구, (6) 비용 구조에 대한 회계적 선호(고정비 vs 변동비).

상황	권장	이유
PoC·아이디어 검증	상용 API	초기비용 0, 가장 빠른 출시
초기 SaaS(트래픽 변동 큼)	상용 API	종량제가 변동 트래픽에 적합
대규모 상시 인바운드	구축형	손익분기 넘으면 단위원가 우위
데이터 잔류·규제 산업	구축형	통제권·데이터 거버넌스 확보
깊은 음색·스타일 커스터마이즈	구축형	모델 수준 제어 가능
위 조건이 혼재	하이브리드	트래픽·민감도 기준 라우팅

예를 들어 개인 토이 프로젝트로 음성 비서를 만든다고 가정해 봅니다. 동시 통화는 한두 건이고 트래픽도 들쭉날쭉합니다. 이때는 상용 API로 시작하는 편이 거의 항상 맞습니다. GPU를 상시 켜둘 이유가 없고, 사용자가 말을 걸지 않는 시간에는 비용도 들지 않기 때문입니다. 반대로 음성을 항상 받아 처리하는 상시 서비스라면, 트래픽이 충분히 깔린 뒤에는 구축형의 단위원가 우위가 커집니다. 즉 같은 기술이라도 "얼마나 자주, 얼마나 예측 가능하게 부르는가"가 방향을 가릅니다.

API냐 구축형이냐 둘 중 하나를 확정해야 한다고 생각하기 쉽지만, 실제로 가장 현실적인 답은 종종 하이브리드입니다. 일반 트래픽은 상용 API로 빠르게 받고, 민감 데이터나 대량 정형 통화만 구축형으로 라우팅하는 식입니다. 처음부터 한쪽에 올인하기보다, API로 검증하며 규모를 키우다가 손익분기가 보이면 핵심 트래픽을 구축형으로 옮기는 단계적 전환이 위험을 가장 잘 줄입니다.

한 가지 덧붙이면, 보이스봇이 외부 기능을 호출하는 도구 호출(function calling)과 그것을 표준화하는 인터페이스 이야기는 이 글의 범위를 넘어섭니다. 이 주제는 10편에서 자세히 다룹니다.

자주 묻는 질문

Q. 구축형으로 옮기면 비용이 무조건 절감되나요?
아닙니다. GPU 비용만 보면 싸 보여도 운영 인력과 온콜 부담이라는 숨은 비용이 큽니다. 사용률(GPU가 실제로 일하는 비율)이 낮으면 오히려 종량제보다 비쌀 수 있습니다.

Q. 두 방식을 같은 음성 품질로 맞출 수 있나요?
모델 선택에 따라 다릅니다. 상용 API는 평균적으로 안정적인 품질을 보장하지만, 구축형은 좋은 오픈소스 모델과 튜닝이 받쳐 줄 때 특정 도메인에서 더 자연스러울 수 있습니다. 구조 차이도 참고할 만합니다. 단일 통합 S2S는 감정·억양 보존에 유리하고, 파이프라인 구성은 각 단계 모델을 교체·튜닝하기 쉽습니다. 품질을 비교하려면 동일한 시나리오로 직접 평가해 보는 것이 정확합니다.

전환은 한 번의 결정이 아니라, 트래픽과 비용 데이터를 보며 단계적으로 옮겨 가는 과정입니다.

AI 보이스봇이 답답한 이유: Cascaded 구조 레이턴시 완전 분석

6월 13, 2026

자세한 내용 보기

이 블로그 검색

AI에이전트엔지니어링