Bland 최고정보책임자 Juan E. Riojas 인터뷰

Juan E. Riojas는 Bland의 최고정보책임자로, 기업 IT, 데이터 관리, 분석, 운영 및 디지털 트랜스포메이션 분야를 두루 거친 풍부한 경험을 갖춘 기술·데이터 경영진이다. 2025년 12월 Bland에 합류하기 전에는 Twilio와 Rackspace Technology에서 최고정보책임자를 역임했으며, 그에 앞서 Informatica의 최고데이터책임자와 Gogo의 데이터 관리 및 분석 부문 부사장으로 일했다. Dell, Accenture, Expeditors International, OfficeMax, AxonGroup에서도 고위 운영 및 관리직을 맡아 대규모 조직 전반의 기술 및 데이터 이니셔티브를 관리하는 폭넓은 경험을 쌓았다.

Bland는 기업용 음성 AI 기업으로, 수신 및 발신 전화 응대, 고객 지원, 일정 관리, 접수, 라우팅 및 기타 복잡한 업무 흐름을 처리할 수 있는 AI 에이전트를 개발한다. Bland는 기반 기술 스택을 직접 제어하는 데 중점을 두고 자체 음성, 언어 및 음성 합성 모델을 개발·운영하며, Bland Cloud, 프라이빗 가상 사설 클라우드, 완전한 자체 호스팅 및 에어갭 방식의 기업 환경을 통한 배포를 지원한다. 특히 규제 대상이거나 보안에 민감한 활용 사례에 주력하며, 대화 경로, 기존 전화 시스템과의 통합, 설정 가능한 데이터 보존, 역할 기반 접근 제어, 기업 규정 준수 기능 등을 제공한다.

Twilio와 Rackspace에서 최고정보책임자를 맡고 Informatica에서 최고데이터책임자로 일하셨으며, 경력의 상당 부분을 통신 인프라와 기업 데이터 분야에서 보내셨습니다. 이러한 경험을 통해 기업이 AI를 도입할 때 직면하는 장벽에 대해 무엇을 알게 되셨으며, 그 경험은 현재 Bland에서 구축 중인 자체 호스팅 플랫폼에 어떤 영향을 미쳤나요?

Twilio, Rackspace, Informatica에서의 경험을 통해 기업용 AI의 가장 큰 장벽은 기술이 아니라 신뢰와 통제, 그리고 대규모 환경에서도 안전하게 운영할 수 있는 능력이라는 점을 배웠습니다. 기업은 데이터가 어디에 저장되는지, 누가 데이터를 제어하는지, 그리고 수년간 구축해 온 보안 및 거버넌스 프레임워크 안에 AI를 적용할 수 있는지를 알아야 합니다. 이러한 경험을 바탕으로 Bland는 기업이 인프라나 데이터에 대한 통제권을 포기하지 않고도 AI의 강력한 기능을 활용할 수 있도록 자체 호스팅 플랫폼을 제공하고 있습니다.

Bland는 유일한 자체 호스팅 음성 AI 플랫폼입니다. 따라서 음성을 텍스트로 변환하는 기술, LLM 추론, 텍스트 음성 변환 등 AI 오케스트레이션의 모든 계층을 직접 소유하게 됩니다. Bland는 왜 이런 방식을 택했으며, 음성 AI 스택 전체를 직접 소유하면서 겪은 가장 어려운 기술적 과제는 무엇이었나요?

자동 음성 인식(ASR)부터 대규모 언어 모델(LLM)의 추론, 텍스트 음성 변환(TTS)까지 모든 계층을 자체 호스팅하고 직접 소유하기로 한 데에는 세 가지 이유가 있습니다. 1초 미만의 대화 지연 시간, 엄격한 데이터 개인정보 보호 경계, 높은 운영 안정성입니다.

서로 다른 외부 공급업체의 서비스를 줄줄이 연결하면 지연 시간이 누적됩니다. 왕복 네트워크 홉, 각기 다른 대기열 지연, 콜드 스타트가 차례로 더해집니다. 그 결과 부자연스러운 침묵이 생겨 대화의 흐름이 끊깁니다.

모델을 통합 런타임 안에 함께 배치하고 타사 API 의존성을 없애 이러한 네트워크 홉을 제거했습니다. 또한 데이터를 완전히 주권적으로 관리할 수 있어 민감한 음성 스트림과 대화 기록이 외부 프런티어 모델 제공업체로 유출되지 않습니다.

가장 어려운 기술적 과제는 지연 시간 오케스트레이션, 스트리밍 동기화, 높은 동시성을 처리하는 GPU 스케줄링이었습니다. 실시간 양방향 음성 처리를 위해서는 토큰을 끊김 없이 스트리밍 방식으로 생성해야 합니다. TTS 엔진은 LLM이 문장 생성을 마치기도 전에 오디오 합성을 시작해야 합니다.

이를 구현하기 위해 맞춤형 추론 엔진, 저지연 추측 디코딩 파이프라인, 음향 모델 조정을 개발했습니다. 이러한 구성 요소는 GPU 메모리를 포화시키지 않으면서 음성 끊김을 방지하고, 발화 순서를 관리하며, 사용자의 끼어들기에 자연스럽게 대응합니다.

많은 음성 AI 플랫폼은 서로 다른 타사 제공업체의 서비스를 조합해 전사, 추론, 음성 생성을 처리합니다. Bland가 스택의 더 많은 부분을 직접 소유하고 운영하면 어떤 이점과 엔지니어링상의 상충점이 있나요?

가장 큰 이점은 엔드투엔드 지연 시간을 제어할 수 있다는 것입니다. ASR, LLM, TTS 사이에 네트워크 오버헤드가 전혀 없으므로 통합 스트리밍 파이프라인을 운영하고, 계층 간 최적화를 수행하며, 첫 바이트가 도착하는 시간도 엄격하게 관리할 수 있습니다. 각 구성 요소를 서로 다른 공급업체에서 제공받는다면 이런 수준의 제어는 불가능합니다.

두 번째 이점은 보안 및 규정 준수 경계를 통합할 수 있다는 것입니다. 데이터가 당사가 통제하는 환경을 벗어나지 않으므로 고객의 오디오와 대화 기록은 검증된 보안 경계 안에 머뭅니다. 이를 통해 타사 하위 처리업체에 따른 위험을 없애고 HIPAA, SOC 2, PCI DSS 준수도 훨씬 간편해집니다. 공급업체 보안 심사를 거쳐 본 사람이라면 이것이 얼마나 중요한지 알 것입니다.

세 번째는 비용을 예측할 수 있다는 점입니다. 외부 기반 모델 API에 토큰당 또는 분당 추가 요금을 지불하지 않으므로 기업 규모에서도 단위 경제성을 예측할 수 있습니다. 또한 모델을 직접 소유하고 있기 때문에 음향 특성, 운율, 특정 작업에 맞춘 추론 가중치를 직접 미세 조정할 수 있습니다.

하지만 이 모든 것에는 비용이 따릅니다. 이 접근 방식은 인프라와 GPU 자본 투입이 많이 필요합니다. 전용 GPU를 대규모로 운영하려면 정교한 스케줄링과 오케스트레이션, 여러 리전에 걸친 장애 조치가 필요하며, 하드웨어 오버헤드도 큽니다.

모델 유지 관리와 특화에 따르는 부담도 저희가 직접 맡습니다. 최첨단 연구를 외부 업체에 맡길 수는 없습니다. 대신 다양한 억양과 배경 소음 환경, 여러 언어를 아우르는 자체 모델을 학습하고 평가하며 유지 관리하는 지속적인 엔지니어링 작업을 수행합니다.

저희에게는 그만한 가치가 있는 절충입니다.

Bland는 8월에 FedRAMP 20x Class A 인증을 획득했으며, 이 인증을 보유한 최초의 음성 AI 플랫폼이라고 밝혔습니다. 대부분의 독자는 20x가 기존 FedRAMP와 어떻게 다른지 모를 것입니다. Class A란 무엇이며, 인증을 받으려면 실제로 무엇을 입증해야 했나요?

FedRAMP 20x는 FedRAMP 2026년 통합 규칙(CR26)에 따라 도입된 현대화된 클라우드 네이티브 프레임워크입니다. 기존 절차에서는 모든 항목을 FIPS 199 영향 수준(낮음, 보통, 높음)으로 분류했으며, 서류 작업이 지나치게 많기로 악명이 높았습니다. 20x는 이를 A, B, C, D의 문자 등급 인증 클래스로 대체합니다.

Class A는 입문 단계의 등급입니다. 이미 성숙한 보안 프로그램을 운영하고 있으며 연방 시장에 진출하려는 상업용 클라우드 서비스 제공업체(CSP)를 위해 특별히 마련됐습니다. 이를 최종 목적지가 아닌 진입로라고 생각하면 됩니다. FedRAMP 프로그램 관리실(PMO)이 직접 발급하는 공식 프로그램 인증을 획득한 뒤, 2년 안에 Class B, C 또는 D로 전환해야 합니다.

이를 위해 저희는 네 가지 사항을 입증해야 했습니다. 첫째, 보안, 기밀성, 가용성의 핵심 원칙을 다루는 최신 SOC 2 Type II 심사를 받고 검증을 완료해야 했습니다. 둘째, 음성, SMS, 채팅 서비스를 포함하는 연방 클라우드 서비스 경계를 명확히 정의하고 논리적으로 격리해야 했습니다.

셋째, 필수 FedRAMP 20x 핵심 보안 지표(KSI)를 기본 수준으로 구현하고 지속적인 모니터링 준비를 갖춰야 했습니다. 여기에는 취약점 검사, 사고 대응 절차, 접근 제어 시행, 기계 판독이 가능한 지속적 보안 보고가 포함됩니다.

네 번째 요건에서는 저희가 기술 스택을 직접 보유한 것이 큰 도움이 됐습니다. 모든 전사, 추론, 음성 합성이 Bland의 승인된 컨테이너 경계 안에서만 실행되며, 검증되지 않은 제3자 최첨단 AI 제공업체에 연방 데이터를 전송하지 않는다는 점을 확인해야 했습니다. 외부 업체의 기술을 이어 붙여 만든 플랫폼이라면 이를 입증하기가 매우 어렵습니다.

Bland는 프라이빗 클라우드 VPC부터 전용 온프레미스 GPU 인프라까지 다양한 배포 방식을 지원합니다. 특히 지연 시간, 확장성, 인프라 요구 사항 측면에서 배포 모델에 따라 아키텍처는 어떻게 달라지나요?

간단히 말하면, 온프레미스에 가까워질수록 지연 시간이 줄고 제어력이 높아지는 대신, 탄력성은 낮아집니다.

먼저 지연 시간을 살펴보겠습니다. 온프레미스와 전용 VPC 배포는 모두 기업의 내부 전화망 트렁크 및 SIP 게이트웨이 바로 옆에 위치하므로 외부 네트워크를 거치는 구간을 최소화합니다. 예를 들어 AWS나 GCP의 프라이빗 클라우드 VPC에서는 리전 내부 네트워킹과 클라우드 상호 연결이 지연 시간을 좌우합니다. 전용 베어메탈 온프레미스 하드웨어는 여기서 한발 더 나아갑니다. 하이퍼바이저 가상화 계층과 공용 인터넷 라우팅을 완전히 제거해 음향 지터를 가능한 한 가장 낮은 수준으로 줄여 줍니다.

확장성에서는 절충점이 드러납니다. 클라우드 VPC에서는 클라우드 GPU 인스턴스를 기반으로 하는 Kubernetes 클러스터의 자동 확장과 같은 탄력적 오케스트레이션을 이용해 수평 확장하므로, 통화량이 급증하면 용량을 동적으로 조정할 수 있습니다. 온프레미스는 그렇지 않습니다. 물리적 GPU 용량이 고정된 한도 안에서 운영해야 하므로, 최대 동시 통화량을 기준으로 엄격한 접속 제어와 대기열 정책을 적용하고 하드웨어를 미리 정적으로 구성해야 합니다. 가장 바쁜 날을 기준으로 사전에 계획을 세워야 합니다.

인프라 요구 사항도 상당히 다릅니다. 프라이빗 VPC 배포에서는 관리형 클라우드 스토리지, 기본 제공 IAM, 클라우드 관리형 비밀 정보 서비스를 활용할 수 있습니다. 온프레미스 설치에는 전용 랙 장착형 GPU 클러스터(예: NVIDIA 엔터프라이즈 가속기), 고대역폭 로컬 네트워크 패브릭, 하드웨어 보안 모듈(HSM) 또는 로컬 키 보관소, 로컬 원격 측정 수집기가 필요합니다. 또한 이 모든 요소는 외부 네트워크와 완전히 차단되거나 외부 송신이 제한된 환경에서도 운영할 수 있는 엔터프라이즈 컨테이너 런타임에서 실행되어야 합니다.

Bland를 사용하면 기업이 릴리스 시점을 제어하고, 별도의 테스트 환경을 유지하며, 새 버전을 실제 통화의 일부에 먼저 적용한 뒤 더 넓은 범위로 배포할 수 있습니다. AI 에이전트가 고객을 직접 응대하는 프로덕션 환경에 도입되면서 기존 소프트웨어 릴리스 관행이 특히 중요해지는 이유는 무엇인가요?

AI 에이전트는 기존 엔터프라이즈 소프트웨어처럼 동작하지 않기 때문입니다.

결정론적 소프트웨어는 매번 똑같이 작동합니다. 생성형 AI 에이전트는 확률적이고 비결정론적입니다. 프롬프트를 조금 수정하거나 모델 가중치를 업데이트하거나 처리 경로를 바꾸는 것만으로도 대화 품질 저하, 환각 또는 규정 준수 정책 위반이 의도치 않게 발생할 수 있습니다. 변화 자체만으로는 그런 일이 일어날 것을 미리 알 수 없는 경우가 많습니다.

그래서 기존의 릴리스 원칙은 덜 중요해진 것이 아니라 오히려 지금 더 중요합니다. 격리된 스테이징 환경과 과거 통화 데이터에 대한 엄격한 회귀 테스트를 거치면 실제 서비스에 적용하기 전에 많은 문제를 잡아낼 수 있습니다. 카나리 배포를 적용하면 한 단계 더 나아갈 수 있습니다. 새로운 버전을 실제 통화 중 관리되는 일정 비율에 배포한 뒤 감정 점수 하락, 목표 달성률, 지연 시간 급증, 상담원 연결 또는 인계 트리거와 같은 실시간 지표를 살펴보는 것입니다. 이 모든 과정은 더 많은 고객에게 새 버전이 노출되기 전에 이루어집니다.

이 문제를 반드시 해결해야 하는 이유는 실패의 대가가 크기 때문입니다. 고객 서비스, 보험금 청구 또는 계정 관리에서 발생한 장애는 규제 리스크나 심각한 브랜드 이미지 손상으로 이어질 수 있습니다. 엄격한 카나리 배포 기준을 적용하고 즉시 롤백할 수 있어야 잘못된 업데이트가 부정적인 뉴스로 번지는 것을 막을 수 있습니다.

은행, 의료기관, 보험사, 정부 기관은 다른 기업보다 생성형 AI를 도입하는 데 훨씬 높은 장벽에 부딪히는 경우가 많습니다. 이러한 기관들과 대화해 보셨을 때, 오늘날 음성 AI 도입을 더디게 하는 실제 요인은 무엇인가요? 보안, 데이터 주권, 신뢰성, 통합의 복잡성, 조달 절차, 아니면 다른 요인인가요?

압도적인 차이로 보안과 데이터 주권이 가장 큰 걸림돌이고, 그다음은 통합의 복잡성과 레거시 아키텍처입니다. 은행, 의료, 보험, 정부 분야에서 나눈 대화에서도 일관되게 확인된 문제입니다.

보안 측면에서 규제가 엄격한 조직은 민감한 음성 스트림, 보호 대상 건강정보(PHI), 비공개 개인정보가 외부 API 경계를 넘어가거나 제3자 모델 제공업체가 학습 목적으로 보관하는 아키텍처를 결코 용인할 수 없습니다. 이러한 고객에게 감사 가능성, 데이터 미보관 보장, HIPAA, FedRAMP, PCI DSS와 같은 엄격한 규정 준수 경계는 있으면 좋은 선택 사항이 아닙니다. 이는 기본적으로 갖춰야 할 필수 조건입니다. 이를 충족하지 못하면 대화는 대개 거기서 끝납니다.

다음 장벽은 통합입니다. 이러한 대기업 중 상당수는 여전히 구형 온프레미스 PBX 시스템, 복잡한 IVR, 그리고 분산된 핵심 기록 시스템을 사용합니다. 의료 분야의 Epic이나 Cerner, 은행의 메인프레임 핵심 시스템이 그 예입니다. 이러한 환경 전반에서 대화 흐름을 실시간 저지연 양방향 읽기·쓰기 API 액세스와 연결하려면 상당한 통합 작업이 필요합니다.

그다음은 신뢰성과 환각 위험입니다. 법무, 리스크, 조달팀이 자율형 음성 에이전트가 부정확한 금융·의료·규제 관련 조언을 할 수 있다고 우려하는 것은 당연합니다. 이들이 실제 운영 규모로의 확대를 승인하려면 세밀한 안전장치, 결정론적 대화 대체 경로, 명확한 사람 상담원 연결 절차가 필요합니다.

훌륭한 인터뷰에 감사드립니다. 더 자세히 알고 싶은 독자는 Bland를 방문해 주세요.