사업용 AI 음성 에이전트 직접 만들기 vs 완성된 AI 전화 비서 쓰기

주말 하나면 우리 사업체용 AI 음성 에이전트를 직접 만들 수 있습니다. 다만 그것이 월요일 아침에 진짜 고객과 맞붙어도 멀쩡할지는 전혀 다른 문제죠. 시연과 믿고 맡길 수 있는 물건 사이의 그 간극이, 직접 만들 것인가 사서 쓸 것인가 하는 이야기의 전부입니다.

터미널이 편한 사장님이라면 솔깃할 만한 생각입니다. 부품은 이미 다 나와 있으니까요. 음성 인식은 저렴한 API 호출 한 번이면 되고, 대규모 언어 모델은 기꺼이 우리 가게 안내 데스크 역할을 연기해 줍니다. 음성 합성은 이제 섬뜩할 만큼 사람 같습니다. 셋을 이어 붙이고 전화번호만 연결하면 월급의 몇 분의 일 값에 로봇이 우리 회선을 받아 주는 셈이죠. 이게 그 홍보 문구이고, 틀린 말은 아닙니다. 그저 절반만 말했을 뿐이죠.

이 글은 그 나머지 절반, 솔직한 버전입니다. “당신은 절대 못 한다”는 얘기가 아닙니다. 할 수 있고, 어떤 사람에게는 정말로 그게 정답이니까요. 대신 이렇게 짚겠습니다. 직접 만드는 AI 음성 에이전트에 정확히 무엇이 들어가는지, 품은 실제로 어디에 숨어 있는지, 실전에서는 무엇이 깨지는지, 그리고 이번 주말을 만드는 데 쓰는 게 나은지 그냥 신청하는 데 쓰는 게 나은지 어떻게 판단할지. 구체적으로 가겠습니다. 두루뭉술한 조언이야말로 한 번에 끝낼 생각이던 프로젝트에 여섯 주말을 갈아 넣게 만드는 원인이니까요.

직접 만드는 AI 음성 에이전트가 그토록 솔깃한 이유

그 매력은 진짜입니다. 그러니 복잡한 얘기를 꺼내기 전에 먼저 인정하고 갑시다. 직접 만들면 모든 결정이 내 것입니다. 인사말은 딱 내가 원하는 그 인사말이 되고, 에이전트는 우리 가게의 사정을 압니다. 화요일은 예약 없이 방문만 받는다는 것, 파란 승합차 얘기로 전화하는 사람은 고객이 아니라 거래처라는 것, 전화로는 절대 가격을 알려 주지 않는다는 것까지요. 이미 쓰고 있는 캘린더나 CRM에 그대로 연결할 수도 있습니다. 게다가 운영비는 서류상 API 요금 몇 개의 합이라, 통화량이 적은 회선이라면 거의 공짜처럼 보이기까지 하죠.

배움도 있습니다. 이런 시스템이 실제로 어떻게 돌아가는지 제대로 이해하고 싶다면 — 모델이 예약을 잡을지 메시지를 남길지 어떻게 정하는지, 지연이 어디서 스멀스멀 끼어드는지, 에이전트가 왜 가끔 전화 건 사람의 말을 자르고 들어오는지 — 하나 만들어 보는 편이 한 달치 독서보다 주말 이틀에 더 많은 걸 가르쳐 줍니다. 기술적 호기심이 있는 사장님이라면 나중에 그 프로젝트를 통째로 버리게 되더라도 그 배움 자체에 값어치가 있습니다.

그러니 이 글은 자체 구축을 깎아내리려는 글이 아닙니다. 그 길을 직접 걸어 본 사람들이 그린 지형도에 가깝습니다. 질문은 “당신이 할 수 있느냐”가 아닙니다. 끝까지 다듬어 믿고 쓸 수 있는 버전이 실제로 치르는 값어치를 하느냐죠. 그리고 그 값은 시연에서 눈에 보이는 부분이 거의 아닙니다.

직접 만든다면 필요한 것들, 하나씩 뜯어보기

AI 음성 에이전트는 하나의 파이프라인입니다. 전화 건 사람이 말을 하면, 무언가가 그걸 텍스트로 바꾸고, 무언가가 무슨 말을 돌려줄지 정하고, 무언가가 그 답을 다시 음성으로 만들고, 이 모든 게 전화망 위에서 돌아갑니다. 각 단계가 곧 우리가 고르고, 붙이고, 요금을 내고, 관리해야 하는 부품입니다. 하나씩 해부해 보죠.

전화망: 통화를 내 코드까지 끌어오기

주말 개발자들이 가장 많이 얕보는 대목입니다. 실시간 오디오 스트림을 내 소프트웨어로 넘겨주고 우리 응답을 다시 흘려보낼 수 있는 전화번호가 필요합니다. 그것도 양방향으로, 1초도 안 되는 지연으로요. 그러려면 전화망 사업자, 미디어 스트림(보통 원시 오디오를 실어 나르는 웹소켓), 그리고 사람이 말하는 동안 그 연결을 안정적으로 붙들어 두는 배관 작업이 필요합니다. 오디오 코덱과 샘플링 레이트와 씨름하게 되고, 전화 오디오는 책상 위 마이크와는 비교도 안 되게 압축되고 잡음이 섞여 있다는 사실도 마주하게 됩니다. 여기서 조금이라도 어긋나면 전화 건 사람에게는 말끝을 잘라먹거나, 한 박자 늦게 반응하거나, 문장 중간에 뚝 끊기는 로봇이 들립니다.

음성 인식: 전화 건 사람의 말 알아듣기

전화 통화를 받아쓰는 일은 깨끗한 녹음을 받아쓰는 일보다 훨씬 어렵습니다. 사람들은 웅얼거리고, 바람 부는 데 서 있고, 라디오를 켠 채 운전하고, 어느 사전에도 없는 이름을 말합니다. 그래서 전화 건 사람이 문장을 다 끝내기 전에 응답할 수 있도록 스트리밍 방식의 인식이 필요하고, 상대가 진짜로 말을 마친 것인지 잠깐 생각하느라 멈춘 것인지 가려내는 로직도 있어야 합니다. 이 멈춤을 잘못 판단하면 에이전트는 남의 말을 자르거나, 3초쯤 어색한 침묵을 남깁니다. 둘 다 친절하게 들리지 않죠.

판단 계층: 무슨 말을 할지 정하기

언어 모델이 자리 잡는 곳이자, 실제 솜씨의 대부분이 들어가는 곳입니다. 여기서 하는 일은 챗봇에 프롬프트를 던지는 수준이 아닙니다. 정해진 선을 벗어나지 않고, 우리 사업 정보에서 맞는 사실을 꺼내 오고, 가격을 지어내지 않고, 언제 예약을 잡고 언제 메시지를 남길지 알고, 물어보면 절대로 사람인 척하지 않는 전화 응대 에이전트를 만드는 일입니다. 그러려면 시스템 프롬프트, 에이전트가 호출할 수 있는 도구 모음(일정 확인, 예약 저장, 문자 발송), 그리고 상당한 양의 안전장치가 필요합니다. 비용과 지연이 함께 쌓이는 단계이기도 합니다. 대화가 한 번 오갈 때마다 모델까지 다녀와야 하니까요.

음성 합성: 목소리 그 자체

전화 건 사람이 가장 먼저 평가하는 건 목소리입니다. 요즘 음성 합성은 훌륭하게 들립니다 — 전화번호, 주소, 소수점, 외국 이름을 만나기 전까지는요. 그 순간 아주 자신 있게 틀린 소리를 내놓을 수 있습니다. 발음을 다듬고, 우리 브랜드에 어울리는 목소리를 고르고, 여기서도 지연과 싸우게 됩니다. 응답을 빠르게 하고 싶을수록 음성이 다 만들어지기 전에 흘려보내야 하는데, 이건 그 자체로 만만찮은 엔지니어링 과제입니다.

접착제: 상자와 상자 사이의 모든 것

이 부품들은 상자에서 꺼내자마자 서로 대화하지 않습니다. 오케스트레이션은 우리가 직접 짜야 합니다. 듣고, 받아쓰고, 판단하고, 말하고, 끼어들기를 처리하고, 대화 내내 상태를 관리하고, 무슨 일이 있었는지 기록하고, 에이전트가 감당하지 못할 때 깔끔하게 사람에게 넘기는 루프 말이죠. 데모가 제품으로 바뀌는 자리가 바로 이 접착제이고, 에이전트가 살아 있는 내내 우리가 손봐야 할 코드이기도 합니다.

데모와 실전 사이의 간극

실력 있는 엔지니어가 걸려드는 함정이 여기 있습니다. 돌아가는 데모는 금방 나오고, 그 순간 다 됐다는 느낌이 듭니다. 내 번호로 전화를 걸어 영업시간을 물어보고 예약을 잡아 보면 훌륭하게 작동하죠. 스스로가 꽤 대견할 텐데, 그럴 만합니다. 진짜 진전이 맞으니까요. 문제는 데모란 내가 이미 걸 줄 아는 전화라는 점입니다. 실전은 내가 각본을 쓰지 않은 모든 전화고요.

작은 미용실 하나가 금요일에 손수 만든 에이전트를 실제 회선에 올렸다고 해 봅시다. 그다음 한 주 동안 진짜 전화가 들어옵니다. 인식기가 자꾸 뭉개는 억센 사투리를 쓰는 사람, 로봇이 자기를 안다는 듯 “늘 하던 걸로”라고 말하는 사람, 통화 중간에 끼어들어 예약을 바꾸는 사람, 잘못 걸린 전화, 거래처, 몇 초마다 신호가 끊기는 기차 안의 발신자, 그리고 사장님이 답을 준비해 둘 생각조차 못 한 질문 — 이를테면 웨딩 단체 시술도 하느냐 — 을 던지는 사람까지요. 이 하나하나가 버그이고, 그 버그마다 진짜 고객이 실제로 나쁜 경험을 하는 동안 우리는 실전 회선에서 디버깅을 하고 있는 겁니다.

고약한 점은, 음성에서의 실패는 작정하고 찾아보지 않으면 눈에 보이지 않는다는 것입니다. 우리 에이전트 때문에 나쁜 경험을 한 사람은 버그 리포트를 쓰지 않습니다. 그냥 끊고, 다시 걸지 않고, 우리는 그런 일이 있었다는 사실조차 영영 모릅니다. 텍스트 앱이라면 망가진 대화를 읽어 볼 수라도 있지만, 전화 회선에서는 실패가 조용히 문밖으로 걸어 나갑니다. 에이전트를 만드는 건 이 일의 눈에 보이는 절반이고, 언제 실패하고 있는지 알아채기 위한 관측 체계를 만드는 건 아무도 블로그에 쓰지 않는 나머지 절반입니다.

유지보수: 끝나지 않는 비용

밀어붙여서 정말로 탄탄한 에이전트를 띄웠다고 해 봅시다. 축하합니다 — 이제 그건 우리 것입니다. 주말 프로젝트라는 표현이 통째로 감춰 버리는 부분이 바로 여기입니다. 이 비용은 만드는 그 주말이 아니라, 그 뒤로 이어지는 모든 주말에 발생하니까요.

• 모델 교체. AI 제공업체는 자기들 일정에 맞춰 모델을 바꾸고 중단시킵니다. 완벽하게 작동하던 프롬프트가 기반 모델이 업데이트되면서 어긋날 수 있는데, 그 사실을 변경 로그가 아니라 고객에게서 듣게 됩니다.
• API 변경. 전화망, 음성 인식, 음성 합성 업체 모두 각자 인터페이스를 바꿔 나갑니다. 3월에 붙여 놓은 것이 9월에 멈추는데, 그 이유는 우리 코드와 아무 상관이 없습니다.
• 우리 사업 자체의 변화. 새 가격, 바뀐 영업시간, 새로 추가한 서비스, 직원 교체, 명절 휴무. 이 하나하나가 곧 에이전트를 손봐야 한다는 뜻이고, 정보를 프롬프트에 박아 넣었다면 그건 설정 변경이 아니라 코드 변경입니다.
• 비용 증가. 통화량이 늘거나, 두 번째 언어를 추가하거나, 대화가 길어질수록 API 요금은 올라갑니다. 그 상승은 선형적이지도 않고, 청구서가 도착하기 전까지는 잘 보이지도 않습니다.
• 가동률. 저녁 8시에 서버가 딸꾹질을 하면 그 회선은 내 회선입니다. 문의를 넣을 지원 창구는 나 자신뿐이고, 전화 건 사람은 지금이 주말이든 말든 상관하지 않습니다.

이 중 어느 것도 만들지 말라는 이유는 아닙니다. 다만 “AI 음성 에이전트를 만들어 봤다”와 “내 사업이 의존하는 AI 음성 에이전트를 운영한다”가 전혀 다른 문장이라는 걸 솔직하게 인정하자는 겁니다. 앞의 것은 프로젝트입니다. 뒤의 것은 사업을 굴리는 데 쓰고 싶은 바로 그 집중력을 두고 다투는, 계속 이어지는 책임입니다.

완성된 서비스란 실제로 무엇인가

Vunoon 같은 완성형 AI 전화 비서도 결국 같은 파이프라인입니다. 전화망, 음성 인식, 판단, 음성 합성, 오케스트레이션. 다만 그 파이프라인이 이미 만들어져 있고, 수천 통의 실제 통화로 검증됐고, 그것을 돌아가게 하는 일만 하는 사람들이 관리한다는 점이 다르죠. 우리가 얻는 건 부품이 아닙니다. 완성된 제품에 더해, 운영 책임을 어깨에서 내려놓는 것입니다.

구체적으로는, 주말을 통째로 쏟아야 할 설정 작업이 짧은 마법사 하나로 바뀝니다. 가입하고, 우리 사업을 설명하고 — 서비스, 영업시간, 알려 주길 원하는 가격, 전화를 어떻게 처리했으면 하는지 — 진짜 고객에게 닿기 전에 그 자리에서 직접 통화하며 시험해 봅니다. 마음에 들게 들리면 번호를 착신 전환하면 끝입니다. 25개 이상의 언어로 연중무휴 24시간 전화를 받고, 예약과 메시지를 받아 두고, 통화마다 요약본과 전체 대화록을 보내 주니 회선에서 무슨 일이 있었는지 짐작할 필요가 없습니다.

직접 만들었다면 필요하다는 사실조차 잊기 쉬운 부분들도 함께 처리됩니다. 감당하기 어려운 상황에서는 허세를 부리는 대신 매끄럽게 넘깁니다 — 메시지를 남기거나 다시 전화하도록 조율하죠. 전화 건 사람이 물으면 사람인 척하지 않습니다. 기반 모델이 바뀌면 알아서 업데이트되니 어긋난 프롬프트를 쫓아다닐 일도 없습니다. 그리고 전화번호, 주소, 까다로운 이름의 발음 문제는 이미 다른 누군가가 대신 씨름해 둔 뒤입니다.

솔직하게 나란히 놓고 보기

어떤 표도 자체 구축이냐 구매냐를 대신 결정해 주지는 못합니다. 다만 축을 나란히 놓아 보면 내 우선순위가 어디에 떨어지는지는 보이죠. 양쪽 모두에서 마케팅 광택을 벗겨 낸 맞바꿈은 이렇습니다.

마지막 줄을 눈여겨보세요. 대부분의 경우를 결정짓는 줄이니까요. AI 음성 에이전트를 만들면 AI 음성 에이전트에 대해 배우게 됩니다. 그런데 사업을 굴리는 일은 이미 그 자체로 전업이죠. 자체 구축이냐 구매냐 밑에 깔린 진짜 질문은 이겁니다. 이미 하고 있는 사업 위에, 음성 AI 인프라라는 또 하나의 사업까지 떠안고 싶은가?

직접 만드는 쪽이 정말로 맞는 경우

자체 구축이 이기는 실제 상황도 분명히 있고, 아닌 척하는 건 이 글이 피하려는 바로 그 불성실함일 겁니다. 다음과 같다면 직접 만드세요.

• 배우는 것 자체가 목적일 때. 음성 AI를 깊이 이해하고 싶고 에이전트는 그 수단일 뿐인 경우죠. 만들어 띄우고, 배우고, 남기든 버리든 — 그 배움이 곧 수익입니다.
• 요구사항이 정말로 특이할 때. 어떤 제품도 열어 주지 않는 동작이 필요한 경우입니다. 기묘한 라우팅 규칙, 레거시 소프트웨어와의 맞춤 연동, 전화 비서라기보다 맞춤형 음성 애플리케이션에 가까운 업무 흐름 같은 것들이요.
• 엔지니어링 시간이 무기한으로 남아돌 때. 비어 있는 주말 하나가 아니라, 에이전트가 살아 있는 내내 매달 고정으로 떼어 둘 수 있는 시간 말입니다. 그게 있고 우리 통화량에서 대안보다 싸게 먹힌다면, 자체 구축도 계산이 맞아떨어질 수 있습니다.
• 실패해도 잃을 게 적을 때. 그 회선이 사업에 결정적이지 않은 경우입니다. 에이전트가 통화 하나를 망쳐도 고객이나 예약을 잃지 않는다면, 실제 손실 없이 열어 놓고 고쳐 나갈 수 있습니다.

그냥 완성된 서비스를 쓰는 게 나을 때

대부분의 작은 사업체에 솔직히 권할 답은 사서 쓰는 쪽입니다. 이유는 능력이 아니라 시간이고요. 진료 의자 두 대짜리 치과를 떠올려 보세요. 놓친 전화 한 통이 신규 환자일 수도, 스케일링 예약 변경일 수도 있습니다. 원장은 치과의사이지 시스템 엔지니어가 아니고, 그에게 희소한 자원은 집중력입니다. 그 집중력을 코덱의 별난 성질과 프롬프트 흔들림에 쓰는 건 환자에게 쓰는 것과 견주면 형편없는 거래죠. 매주 놓치는 전화 열 통이 저마다 예약이 될 수 있었다면 그건 셀 수 있는 진짜 손실이고, 그 구멍을 가장 빨리 막는 길은 저장소가 아니라 오늘 오후부터 돌아가는 회선입니다.

구매 쪽 논거가 가장 강한 경우는 이렇습니다. 전화가 정말로 매출에 직결될 때, 내 시간이 인프라보다 본업에 쓰이는 편이 나을 때, 인상적으로 돌아가는 것보다 믿음직하게 돌아가길 원할 때, 그리고 모델 제공업체가 변경 사항을 내보내는 일요일 저녁 8시에 깨어 있는 사람이 내가 아니라 다른 누군가이길 바랄 때요. 자체 구축이냐 구매냐를 우리에게 물어오는 사장님 대다수가 여기에 해당합니다. 그중에는 충분히 만들 능력이 있으면서도 그저 그걸 떠안고 싶지 않다고 결론 내린 분들도 많고요.

오후 한나절이면 결정하는 법

탭이 열두 개 달린 스프레드시트는 필요 없습니다. 필요한 건 몇 가지 질문에 대한 솔직한 답, 그리고 그 답을 믿을 각오뿐입니다.

1. 1
   시간 예산을 솔직하게 적기

   만드는 주말 말고, 앞으로 영원히 유지보수에 쏟을 월 몇 시간을 말합니다. 그 숫자가 솔직히 0이라면 답은 이미 나온 것이고, 그건 자체 구축이 아닙니다.
2. 2
   그 회선이 얼마나 중요한지 매겨 보기

   통화 하나를 망치는 것이 곧 고객이나 예약을 잃는 일이라면, 통제권보다 안정성이 필요합니다. 이건 구매 쪽으로 강하게 밀어붙이는 요인이죠.
3. 3
   여기서 진짜 원하는 게 뭔지 묻기

   돌아가는 전화 비서인가요, 아니면 그게 어떻게 돌아가는지에 대한 지식인가요? 둘 다 정당하지만 서로 다른 결정으로 이어집니다. 그러니 솔직하게 답하세요.
4. 4
   빠른 길을 먼저 시험해 보기

   완성된 서비스를 몇 분 만에 설정하고 직접 통화해 보세요. 그러면 구체적인 기준선이 생기고, 내가 만들 버전이 주말들을 갈아 넣을 만큼 이보다 나을지 물어볼 수 있습니다.

마지막 단계가 솔직한 결정타입니다. 자체 구축 버전은 아직 머릿속에만 있을 때 낭만적으로 보이기 쉽습니다. 실제로 돌아가는 에이전트를 먼저 눈앞에 놓아 보고, 그다음에 내 맞춤 버전이 계속 드는 비용을 정당화할 만큼 충분히 더 나을지 판단하세요. 대안을 직접 귀로 듣고 나면 답은 대체로 “아니오”이고, 그건 한 달을 아껴 준 아주 괜찮은 결말입니다.