AICC(AI Contact Center) 콜봇 도입을 검토하는 조직에서, 개발 역량이 있는 팀일수록 같은 질문에 부딪힙니다. "이 정도면 우리가 직접 만들 수 있지 않나?" STT는 오픈소스 모델이 있고, LLM은 API를 붙이면 되고, TTS도 여러 벤더가 있습니다. 각 조각을 따로 보면 전부 손에 잡힐 것처럼 보입니다.
문제는 콜봇이 이 조각들의 '합'이 아니라 '실시간 파이프라인'이라는 데 있습니다. 고객이 말을 끝내는 순간부터 봇이 답을 시작하기까지의 지연, 통화 중간에 끼어드는 발화(바지-인) 처리, 24시간 무중단 운영, 상담 로그와 KPI 집계까지 — 개별 기술이 아니라 이것들을 하나의 통화 흐름으로 묶는 오케스트레이션이 진짜 난제입니다.
이 글은 "무조건 사서 써라"라고 말하지 않습니다. 자체 개발이 명백히 유리한 경우가 실제로 존재하고, 그 경계를 흐리는 건 정직하지 못합니다. 대신 Build와 Buy를 구성요소·비용·기간·리스크 축으로 나눠 저울질하고, 둘 사이의 현실적인 제3안까지 짚습니다.
Build vs Buy, 정확히 무엇을 비교하는가
먼저 오해를 걷어내겠습니다. Build vs Buy는 "코드를 짜느냐 마느냐"의 문제가 아닙니다. 솔루션을 도입해도 시나리오 설계·연동·운영은 우리 몫으로 남고, 자체 개발을 해도 STT/LLM/TTS 엔진 자체는 대개 외부에서 조달합니다. 순수하게 밑바닥부터 짜는 조직은 거의 없습니다.
그래서 비교의 핵심은 "음성 파이프라인의 어느 레이어까지 우리가 소유할 것인가" 입니다. 레이어는 크게 세 층으로 나뉩니다.
- 엔진 레이어: 음성인식(STT), 언어모델(LLM), 음성합성(TTS) — 학습 데이터와 GPU가 필요한 영역
- 오케스트레이션 레이어: 발화 감지, 턴 관리, 지식 검색(RAG), 대화 상태 관리
- 운영 레이어: 텔레포니 연동, 상담 이관, 로그·KPI, 배포·모니터링
Buy는 세 층을 모두 벤더에게 맡기고 시나리오만 설계하는 방식, Build는 세 층을 직접 소유하는 방식, 그리고 뒤에서 다룰 하이브리드는 엔진은 API로 조달하되 오케스트레이션을 직접 갖는 방식입니다.
자체 개발의 5대 구성요소와 실제 난이도
자체 개발을 결정했다면 최소 다섯 개 블록을 책임져야 합니다. 각 블록의 '겉보기 난이도'와 '실제 난이도'는 상당히 다릅니다.
| 구성요소 | 겉보기 | 실제 난제 | 필요 역량 |
|---|---|---|---|
| STT(음성인식) | 오픈소스 모델로 시작 | 실시간 스트리밍 인식, 통화 음질(8kHz)·소음·사투리 정확도 | 음성 ML, 도메인 튜닝 |
| LLM(대화) | API 호출이면 끝 | 문서 그라운딩(환각 제어), 대화 상태 유지, 프롬프트 운영 | 백엔드, LLM 엔지니어링 |
| TTS(음성합성) | 벤더 붙이면 됨 | 첫 음절 지연, 자연스러운 한국어 억양, 스트리밍 청크 | 저지연 인프라 |
| 텔레포니 | SIP 연동 문서대로 | 바지-인, 에코 제거, 통화 품질, 상담원 이관 | 통신/인프라 |
| 운영툴 | 로그만 쌓으면 됨 | 실시간 대시보드, KPI, 시나리오 버전관리, 무중단 배포 | 데브옵스, 프론트 |
여기서 자체 개발 팀이 가장 자주 과소평가하는 세 가지가 있습니다.
첫째, 저지연 스트리밍입니다. 사람은 통화에서 0.5초만 침묵이 흘러도 "여보세요?"라고 되묻습니다. 대화가 자연스럽게 이어지려면 아래 누적 지연을 1초 안쪽으로 눌러야 합니다.
STT 인식(0.2~0.3초) + LLM 응답 생성(0.3~0.5초) + TTS 첫 음절(0.3초 내외)
≈ 누적 0.8~1.1초
세 단계 중 어느 하나만 늘어져도 예산이 무너지므로, 특히 병목이 되기 쉬운 TTS 첫 음절 지연을 얼마나 눌러 두느냐가 관건입니다. 참고로 휴멜로의 음성합성 엔진 DIVE는 0.35초 실시간 스트리밍 합성과 48kHz 음질을 제공해, 이 구간을 설계 단계에서 흡수합니다.
둘째, 한국어 통화 음질입니다. 표준 발음 데이터로 학습한 모델은 데모에서 잘 들리지만, 실제 통화망의 좁은 대역과 억양·감정 표현에서 무너집니다. 한국어 특화 파운데이션 모델과 스튜디오급 합성 품질을 자체 학습으로 확보하려면 상당한 데이터·시간·GPU가 든다는 점을 감안해야 합니다.
셋째, 문서 기반 지식관리입니다. 콜봇의 답변 품질은 결국 "우리 회사 규정·상품·FAQ를 얼마나 정확히 근거로 답하느냐"에서 갈립니다. 이걸 직접 RAG로 구축하면 문서 파싱·임베딩·검색·환각 억제를 모두 운영해야 합니다. 이 레이어를 통째로 위임하고 싶다면, 문서를 등록하면 콜봇이 그 문서를 근거로 답하는 문서 그라운딩형 콘솔(예: 휴멜로 프로소디 콘솔의 '스킬북')을 활용하는 선택지도 있습니다.
비용·기간 비교표
수치는 특정 실적이 아니라 국내 시장에서 통용되는 인건비·기간 범위로 계산한 것입니다. 조직 규모와 시나리오 복잡도에 따라 편차가 크다는 전제로 봅니다.
| 항목 | 자체 개발(Build) | 솔루션 도입(Buy) | 하이브리드 |
|---|---|---|---|
| 초기 구축 기간 | 통상 9~18개월 | 4~10주 | 6~12주 |
| 핵심 인력 | 음성ML·백엔드·인프라·프론트 4~6인 | PM 중심 1~2인 | 백엔드·PM 2~3인 |
| 초기 비용 | 인건비 중심, 수억 원대 | 구독/도입비 | 중간 수준 |
| 월 유지보수 | 전담 인력 상시 필요 | 벤더 SLA 내 포함 | 오케스트레이션만 자체 |
| 커스터마이징 | 무제한 | 벤더 제공 범위 내 | 상당 부분 자유 |
| 리스크 소재 | 우리 팀 | 벤더 종속 | 분산 |
인건비를 간단히 눌러 보면 감이 잡힙니다. 음성 ML·저지연 백엔드·통신 인프라를 아우르는 4~6인 팀을 1년간 유지한다고 가정하면, 통상 1인당 인건비(제반비 포함)를 보수적으로 잡아도 연간 수억 원 규모의 고정비가 발생합니다. 이들은 채용 자체가 어렵고 비싸며, 구축이 끝난 뒤에도 모델 재학습·통신망 변화 대응·시나리오 업데이트를 위해 팀을 계속 유지해야 합니다. 자체 개발의 진짜 비용은 '만드는 비용'이 아니라 '유지하는 비용'입니다.
자체가 유리한 경우 / 솔루션이 유리한 경우
Buy가 항상 정답은 아닙니다. 아래 조건에 여럿 해당하면 자체 개발을 진지하게 검토할 만합니다.
자체 개발이 유리한 경우
- 콜봇이 핵심 제품이거나, 음성 기술 자체가 사업 경쟁력인 경우
- 폐쇄망·규제로 외부 API 호출이 원천 차단되고 완전 온프레미스가 필수인 경우
- 이미 음성 ML 팀과 GPU 인프라를 보유해 한계비용이 낮은 경우
- 표준 솔루션으로는 불가능한 극단적 커스터마이징이 필요한 경우
솔루션 도입이 유리한 경우
- 콜봇이 '지원 채널'이지 사업의 본질이 아닌 경우(대다수 기업)
- 빠른 출시와 검증이 우선이고, 실패 비용을 낮게 가져가야 하는 경우
- 음성 ML·통신 인프라 전담 채용이 현실적으로 어려운 경우
- 상담 품질·KPI 운영에 집중하고 싶고, 엔진 유지보수는 위임하고 싶은 경우
경계는 결국 "음성 기술이 우리 사업의 해자(moat)인가"라는 질문으로 수렴합니다. 그렇다면 Build, 아니라면 Buy 쪽으로 무게가 실립니다.
제3안: 하이브리드(API 조립형)
극단적 선택만 있는 건 아닙니다. 실무에서 가장 현실적인 답은 종종 그 사이에 있습니다. 엔진(STT·LLM·TTS)은 검증된 API로 조달하고, 오케스트레이션과 운영 로직만 자체 소유하는 방식입니다.
이 접근은 자체 개발의 가장 무거운 부분(음성 ML 학습, GPU 운영, 저지연 인프라)을 벤더에게 넘기면서도, 우리 업무 흐름에 맞춘 대화 로직·연동·데이터 소유권은 지킵니다. 앞서 짚은 자체 개발의 3대 난점 — 저지연 스트리밍, 한국어 음질, 문서 지식관리 — 은 이미 상용 엔진이 해결한 영역이므로, 이걸 다시 만드는 대신 조립합니다.
- 저지연·음질이 필요한 TTS는 스트리밍 합성 API로
- 문서 그라운딩은 지식관리형 콘솔로
- 그 위에서 우리 CRM·상담 이관·KPI 규칙만 직접 구현
이렇게 하면 초기 기간은 자체 개발보다 짧고, 커스터마이징 자유도는 순수 Buy보다 높습니다. 벤더 종속 리스크도 엔진 레이어에 국한됩니다. 다만 여러 API를 엮는 통합 책임은 우리에게 남으므로, 이를 감당할 백엔드 역량은 전제됩니다.
마무리
Build vs Buy는 기술력 자랑의 문제가 아니라 자원 배분의 문제입니다. 우리 팀의 시간과 사람을 '음성 엔진을 만드는 데' 쓸 것인가, '고객 경험과 상담 품질을 설계하는 데' 쓸 것인가. 음성 기술이 사업의 해자라면 자체 개발이 답이고, 그렇지 않다면 검증된 엔진을 조달해 오케스트레이션에 집중하는 편이 대부분 합리적입니다.
가장 흔한 실수는 데모의 쉬움을 프로덕션의 쉬움으로 착각하는 것입니다. 조각을 붙이는 데 2주, 프로덕션 품질로 끌어올리는 데 1년이 걸립니다. 결정 전에 반드시 "우리가 이걸 3년간 유지보수할 수 있는가"를 자문하길 권합니다.
