온프레미스 상담어시스트 — GPU 제약과 모델 선택의 현실

상담어시스트 시리즈의 마지막 편입니다. 앞선 여섯 편은 모두 "무엇을 만들 것인가"에 대한 이야기였습니다. 마지막으로 남는 질문은 "어디에 올릴 것인가"입니다. 흔히 상담어시스트 사업의 핵심은 기능 설계라고 생각하지만, 실제로는 공공기관·금융사 사업을 준비할 때 더 오래 붙잡게 되는 문제가 인프라였습니다. 클라우드 구독형 아키텍처를 그대로 들고 갈 수 없는 환경에서, 한정된 GPU 위에 어시스트·AutoQA·콜봇·인사이트를 어떻게 올릴 것인가. 이 글은 그 사이징과 모델 선택, 기간계 연동의 현실을 정리합니다.

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

← 이전: 9-6 신입 상담사에게 어시스트가 더 필요한 이유 / 다음 → 10-1 왜 롤플레이 챗봇을 직접 만들었나

전체 목차 펼치기 (63편)

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

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

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편)

9-1 상담어시스트란 무엇인가 — 실시간 STT가 상담사 화면을 바꾸는 구조
9-2 상담어시스트의 뼈대 — STT·인텐트·KMS 파이프라인
9-3 추천의 근거 — KMS·RAG 지식 그라운딩
9-4 통화 중 놓친 고지를 잡는 실시간 필수 안내 체크
9-5 AI가 상담 품질을 자동 채점하는 법 — AutoQA
9-6 신입 상담사에게 어시스트가 더 필요한 이유
9-7 온프레미스 상담어시스트 — GPU 제약과 모델 선택 (현재 글)

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

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

구독형이 통하지 않는 시장 — 왜 구축형으로 가는가

상담어시스트를 포함한 컨택센터 AI 솔루션의 표준 제공 형태는 점점 클라우드 구독형으로 수렴하고 있습니다. 흔히 클라우드 구독형이 업계 표준이라고 생각하지만, 실제로 공공기관·금융사 사업에서는 이 표준이 자주 통하지 않습니다. 상담 데이터에는 개인정보와 계약 정보가 포함되고, 공공·금융은 데이터 외부 반출과 외부망 연결에 강한 제약이 있기 때문입니다. 망분리 환경이라면 클라우드 API를 호출하는 구조 자체가 성립하지 않습니다.

그래서 이 시장의 답은 구축형(서버 설치형)입니다. GPU 서버·모델·STT 엔진·KMS·파이프라인 전부를 고객 데이터센터 안에 설치하는 방식입니다. 벤더 관점에서 이것은 배포 옵션 변경이 아니라 아키텍처의 전면 재설계에 가깝습니다. 클라우드에서 당연했던 오토스케일링과 사실상 무제한의 GPU 풀이 사라지고, 계약 시점에 확정된 GPU 수 장이 전부인 세계가 시작됩니다. 온프레미스와 클라우드의 비용·데이터 주권 비교 자체는 7-2 온프레미스 vs 클라우드: 데이터 주권과 운영 비용에서 콜봇 관점으로 다뤘습니다. 이번 편은 그 다음 단계, 어시스트와 AutoQA가 얹히는 복합 워크로드의 사이징 문제입니다.

GPU 수 장 위의 네 가지 워크로드

구축형 제안에서 고객이 확보할 수 있는 GPU는 대부분 수 장 수준입니다. GPU 서버의 도입 단가와 예산 편성 구조 때문입니다. 문제는 그 위에 올라갈 워크로드가 하나가 아니라는 점입니다. 상담어시스트 사업은 대개 AutoQA, 콜봇, 상담 인사이트(분석)까지 묶인 패키지로 제안됩니다. 각 워크로드의 성격은 다음과 같습니다.

워크로드	실시간성	GPU 점유 패턴	사이징 기준
상담어시스트	실시간 (통화 중)	업무 시간대 상주, 동시 세션 수에 비례	피크 동시 통화 수
콜봇	실시간 (통화 중)	상주, 동시 세션 수에 비례	피크 콜 트래픽
AutoQA	준실시간~배치	콜 종료 후 처리, 야간 배치로 이동 가능	일일 콜 총량
상담 인사이트	배치	야간·유휴 시간대 집중	분석 주기와 데이터량

핵심은 실시간과 배치의 구분입니다. 어시스트와 콜봇은 통화가 발생하는 순간 응답해야 하므로 업무 시간대 내내 GPU를 상주 점유하고, AutoQA와 인사이트는 콜 종료 후 처리해도 되므로 야간으로 밀어낼 수 있습니다. 네 워크로드를 공존시키는 기본 전략이 이 시간대 분리입니다. 낮에는 실시간 서빙에 GPU를 몰아주고, 밤에는 같은 GPU로 배치 평가와 분석을 돌립니다.

여기서 사이징의 의미를 다시 정의해 두겠습니다. 흔히 사이징이라고 하면 GPU를 몇 장 넣을지 정하는 일이라고 생각하지만, 실제로는 워크로드마다 필요한 칩의 급을 구분하는 일에 가깝습니다. STT·TTS 서빙은 CPU만으로도 가능하고 GPU는 학습할 때 필요하며, 요약 같은 후처리는 보급형 추론 GPU 한 장 수준이면 충분합니다. "무조건 대형 GPU"가 아니라 CPU·보급형 추론 GPU·대형 GPU를 워크로드별로 구분해 배치하는 것이 온프레미스 사이징의 출발점입니다.

개발(검증) 환경과 운영 환경의 분리도 현실을 더 빠듯하게 만듭니다. 흔히 검증 환경은 운영 환경과 별개로 넉넉히 두면 된다고 생각하지만, 실제로는 모델·프롬프트 변경의 검증에도 GPU가 필요해 검증 환경을 축소 구성으로 두거나 운영 유휴 시간대를 겸용하는 타협이 흔합니다.

대형 모델의 함정 — KV 캐시, 레이턴시, 그리고 하이브리드

사이징 논의에서 반드시 부딪히는 지점이 모델 크기입니다. 고객은 대개 이름이 알려진 대형 모델, 수십 B급 파라미터 모델을 원합니다. "큰 모델이 더 똑똑하다"는 기대는 자연스럽습니다. 그런데 실시간 상담어시스트에 수십 B급 모델을 올리면 두 가지 문제가 동시에 터집니다.

첫째는 KV 캐시입니다. LLM은 추론 중 대화 컨텍스트를 KV 캐시 형태로 GPU 메모리에 유지하는데, 이 캐시는 모델이 크고 컨텍스트가 길고 동시 세션이 많을수록 커집니다. 수십~수백 명의 상담사가 동시에 통화하는 어시스트 환경에서 대형 모델은 이 캐시가 메모리를 급격히 잠식해 감당 가능한 동시 세션 수가 확 줄어듭니다. 둘째는 레이턴시입니다. 어시스트의 추천은 상담사가 고객과 대화하는 도중 화면에 떠야 의미가 있습니다. 대형 모델의 생성 속도로는 추천이 화면에 도착했을 때 이미 대화가 다음 주제로 넘어가 있는 상황이 생깁니다. 늦게 도착한 정답은 오답과 다르지 않습니다.

그래서 현장의 결론은 경량~중형 모델로 속도와 품질의 균형을 잡는 것입니다. 물론 모델을 줄이면 의도 분류·요약·추천 품질을 도메인 데이터로 검증하는 과정이 따라와야 합니다. 그리고 대부분의 현장이 실제로 도착하는 지점은 하이브리드 구성입니다. 통상적인 흐름은 룰과 경량 분류기가 처리하고, 특정 의도 분석이나 상담 요약처럼 생성 능력이 꼭 필요한 지점에서만 LLM을 제한적으로 호출하는 방식입니다. LLM 호출 횟수 자체를 설계로 통제하면 GPU 소비가 예측 가능해지고, 레이턴시가 중요한 구간에는 아예 LLM을 끼우지 않는 선택도 할 수 있습니다.

흔히 AI 시스템이라고 하면 모델 하나가 전부를 처리한다고 생각하지만, 실제 구성은 "모델 하나로 전부"가 아닙니다. 의도 파악·요약·추천 각각에 적합한 모델을 정확도와 레이턴시의 종합 판단으로 따로 고르고, 멀티에이전트 구조 위에서 오케스트레이션 엔진이 의도를 분류해 담당 에이전트에 배정합니다. 이 컨트롤 자체도 LLM과 룰의 하이브리드입니다.

기간계 연동 — 전부 실시간일 필요는 없다

어시스트가 고객 정보나 계약 상태를 화면에 띄우려면 기간계 시스템과 연동해야 합니다. 그런데 공공·금융의 기간계는 무겁고 보수적인 시스템입니다. AI 워크로드가 통화마다 기간계를 실시간으로 두드리는 구조를 만들면, 기간계 쪽에서 감당하지 못하고 전체 시스템이 불안정해질 수 있습니다. 기간계 장애는 AI 기능 하나가 아니라 업무 전체를 멈추는 사고입니다.

현실적인 답은 AI와 기간계 사이에 API 게이트웨이 계층을 두는 것입니다.

상담어시스트 / AutoQA / 인사이트
            |
            v
      API 게이트웨이
   - 요청 큐잉: 기간계로 가는 부하를 평탄화
   - 배치 병합: 비실시간 요청은 묶어서 처리
   - 캐싱: 반복 조회 결과 재사용
            |
            v
    기간계 시스템 (계정계·정보계)

게이트웨이는 AI 쪽의 요청을 큐에 쌓아 기간계가 감당할 수 있는 속도로 흘려보내고, 통화 중 반드시 최신 정보가 필요한 조회만 준실시간 경로로 통과시킵니다. "전부 실시간"이 아니라 "꼭 필요한 곳만 준실시간, 나머지는 배치"가 온프레미스 기간계 연동의 기본 문법입니다.

같은 논리가 통합 포탈에도 적용됩니다. 고객은 어시스트·AutoQA·인사이트를 하나의 화면으로 완전히 통합해 달라고 요구하는 경우가 많은데, 완전 UI 통합은 공수와 유지보수 부담이 과도합니다. 현실적인 절충은 SSO(통합 인증)로 로그인을 한 번으로 만들고, 포탈에서 각 시스템으로 메뉴 링크로 넘어가는 구성입니다. "한 번 로그인, 한 곳에서 진입"은 지키면서 통합 비용은 크게 낮추는 방법입니다. 덧붙여 화면을 설치형이 아닌 브라우저 기반으로 두면 재택·원격 환경에서도 인터넷만 확보되면 동일 성능이 나옵니다. 온프레미스 서버에 웹 클라이언트를 얹는 조합의 실무 이점입니다.

학습 인프라를 사업 범위에 처음부터 포함하라

한 가지 더 조언을 얹겠습니다. 흔히 GPU 사이징이라고 하면 추론용 GPU만 계산하면 된다고 생각하지만, 실제로는 학습 자원까지 포함해야 하는 문제입니다. 고객사 대부분이 이 함정에 걸려 추론용 GPU만 산정하고 학습 자원은 아예 고려하지 않습니다. 그런데 오답을 수집해 재학습하는 자동 학습, 즉 셀프 피드백 루프도 결국 GPU 비용입니다. 학습 인프라가 빠진 구성은 오픈 후 운영 단계의 품질 개선이 막힙니다. 학습 자원을 사업 범위에 처음부터 포함하시기 바랍니다. 덧붙이면 여기서 말하는 고객사 이야기는 특정 회사를 지칭하지 않는 일반화된 관찰이며, 이 글 전체가 2026년 7월 시점에 공개 가능한 범위의 내용만 담고 있고 계약 수치 같은 특정 정보는 포함하지 않습니다.

리소스에 맞추지 말고 최적 구성을 제안하라

시리즈 전체를 통틀어 다시 정의하고 싶은 것이 하나 있는데, 사이징은 기술 문제가 아니라 협상의 문제라는 점입니다. 구축형 사업에서 벤더는 고객이 이미 확보한 GPU에 맞춰 구성을 욱여넣고 싶은 유혹을 받습니다. 증설 요청은 예산 협의를 다시 여는 부담스러운 일이기 때문입니다. 그런데 한정된 리소스에 맞춰 모델을 줄이고 기능을 깎다 보면 품질이 기준선 아래로 내려가고, 오픈 후 "못 쓰겠다"는 평가의 책임은 결국 구성을 수용한 벤더에게 돌아옵니다.

필자의 원칙: 고객의 현재 리소스에 억지로 맞추지 말고, 워크로드에 필요한 최적 구성을 먼저 제안하라. 리소스가 부족하면 증설을 요청하라. 품질의 기준선은 구성 단계에서 지켜지는 것이지, 오픈 후 튜닝으로 복구되는 것이 아니다.

이 원칙은 고객을 위한 것이기도 합니다. 도입 시점에 증설의 필요성과 판단 근거를 투명하게 제시받는 쪽이, 오픈 후 품질 문제의 원인을 추적하는 것보다 고객에게도 저렴합니다. 상담어시스트는 파이프라인·지식·평가·인프라가 모두 맞물려야 상담사의 화면에서 제 역할을 하는 시스템입니다. 그 마지막 조각인 인프라 사이징까지가 설계의 일부라는 것이, 일곱 편에 걸친 이 시리즈의 결론입니다.

조건	권장 구성
실시간 상담어시스트 + 콜봇만 운영, 피크 동시 통화 50회 이하	경량~중형 모델(7~13B) + 보급형 추론 GPU 1~2장. STT·TTS는 CPU 서빙, 학습용 GPU는 별도 산정.
어시스트 + AutoQA + 인사이트 복합 운영, 피크 동시 통화 100회 이상	실시간 경로(어시스트·콜봇)에 GPU를 낮 시간대 전용 배정, AutoQA·인사이트는 야간 유휴 시간대로 분리. 대형 모델은 야간 배치 경로에만 배치.
도메인 재학습·셀프 피드백 루프 포함	추론 GPU와 별도로 학습용 GPU를 사업 범위에 처음부터 포함. 학습 자원 미산정 시 오픈 후 품질 개선 불가.

사이징은 고객이 보유한 GPU에 맞추는 것이 아니라, 워크로드가 요구하는 최적 구성을 먼저 정의하고 부족하면 증설을 요청하는 순서로 진행하는 것이 맞습니다.

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

6월 13, 2026

자세한 내용 보기

이 블로그 검색

AI에이전트엔지니어링