콜봇 SLM: 30B vs 70B 트레이드오프 — 속도와 정확도 사이

콜봇을 설계할 때 모델 크기 선택은 의외로 사후에 처리되는 경우가 많습니다. 먼저 기능과 시나리오를 확정하고, 모델은 "일단 가장 좋은 것"으로 결정하는 방식입니다. 그러나 콜봇에서 모델 크기는 레이턴시와 직결되며, 레이턴시는 통화 경험의 핵심입니다. 70B 모델이 30B보다 약 2배 느리다는 것은 단순한 수치가 아닙니다. 고객이 침묵을 참는 임계값이 1.5초 안팎이라는 점을 감안하면, 모델 크기 선택은 UX 설계 초반에 함께 결정해야 할 사항입니다. 이 글은 콜봇 구축 경험을 바탕으로 30B와 70B의 트레이드오프를 정리하고, 콜봇 유형별 사이징 가이드와 실무 체크리스트를 제시합니다.

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

← 이전: 8-4 TTFT 1.5초, 콜봇 스트리밍 파이프라인 설계 / 다음 → 8-6 PoC와 본사업 사이의 성능 괴리

8-3 금융 콜봇에서 소수점이 중요한 이유
8-4 TTFT 1.5초, 콜봇 스트리밍 파이프라인 설계
8-5 콜봇 SLM: 30B vs 70B 트레이드오프 (현재 글)
8-6 PoC와 본사업 사이의 성능 괴리
9-1 상담어시스트란 무엇인가 — 실시간 STT가 상담사 화면을 바꾸는 구조

전체 목차 펼치기 (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편)

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

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

콜봇에서 모델 크기가 레이턴시에 미치는 영향

그림 1. 30B는 빠르지만 정확도가 낮고, 70B는 느리지만 정확도가 높다 — 콜봇 유형에 맞춰 선택해야 한다.

LLM 기반 콜봇에서 모델 크기는 레이턴시의 가장 직접적인 결정 변수 중 하나입니다. 같은 하드웨어 환경에서 30B 모델의 첫 토큰 생성 시간(TTFT)은 70B 모델 대비 약 2배 빠른 수준으로 측정됩니다. 수치 자체보다 중요한 것은 맥락입니다. 통화 중 고객은 침묵을 짧게만 허용하고, 1.5초를 넘어서면 "먹통이 됐나"라고 인식하기 시작합니다. 70B 모델이 이 임계값 안에 들어오려면 더 강력한 GPU와 스트리밍 파이프라인이 동시에 요구됩니다.

단순히 "30B가 70B보다 빠르다"는 결론에서 끝나면 안 됩니다. 속도 차이는 하드웨어 스케일과 배치 크기에 따라 줄어들기도 합니다. 그래서 콜봇 설계 단계에서 모델 크기를 선택할 때는 "현재 인프라에서 각 모델이 실제로 몇 ms를 찍는가"를 파일럿으로 직접 측정하는 것이 전제가 되어야 합니다. 벤더나 논문의 벤치마크 수치는 참고 자료이지, 우리 환경의 실측값이 아닙니다.

콜봇 유형별 SLM 사이징 가이드

콜봇은 설계 목적에 따라 크게 세 가지 유형으로 나뉩니다. 각 유형마다 적합한 모델 크기가 다릅니다.

콜봇 유형	권장 모델 크기	우선 가치	비고
단순 룰 기반 콜봇	30B 이하	속도 우선	정해진 시나리오 내 분기·응답. 정확도 마진 작아도 됨
에이전트형 콜봇	70B	정확도 우선	DB 조회·복잡 추론·다단계 판단 필요. 레이턴시 타협
상담사 어드바이저	30B → 4B 가능	경량화 우선	상담사가 참고하는 보조 도구. 실시간 통화 외 흐름

단순 룰 기반 콜봇은 시나리오 트리를 따라 분기하는 구조이므로, LLM에 요구하는 추론 깊이가 낮습니다. 이 경우 30B 이하 모델로도 충분한 정확도를 확보할 수 있고, 속도에서 확실한 이득을 얻습니다. 반면 에이전트형 콜봇은 실시간으로 데이터베이스를 조회하거나, 고객의 복잡한 상황을 여러 단계로 추론하면서 응답해야 합니다. 이때 30B 모델의 추론 한계가 오류 유발 요인이 되고, 그 오류가 통화 중 노출되는 비용은 레이턴시보다 훨씬 큽니다.

상담사 어드바이저는 콜봇과 다른 흐름입니다. 상담사가 고객과 통화하는 동안 화면 한쪽에 추천 답변을 실시간으로 제안하는 보조 도구이므로, 응답이 0.3~0.5초 늦어도 상담사가 읽는 데 큰 문제가 없습니다. 이 경우 4B 수준의 경량 모델도 실용적인 선택이 될 수 있으며, GPU 자원을 절약할 수 있습니다.

온프렘 vs 클라우드 API에서의 모델 크기 선택 기준

동일한 70B 모델이라도 온프렘 직접 서빙과 클라우드 API 호출 방식은 운영 특성이 다릅니다. 이 차이가 모델 크기 선택에 영향을 줍니다.

온프렘에서는 GPU 용량이 직접적인 제약 조건입니다. 70B FP16 모델은 A100 80GB 기준 최소 2장이 필요하며, 동시 세션이 늘면 더 많은 카드가 필요합니다. 초기 투자와 운영 비용이 크다는 뜻입니다. 반면 30B 모델은 단일 GPU에서도 서빙이 가능하고, 같은 하드웨어로 더 많은 동시 세션을 처리할 수 있습니다. 온프렘에서 모델 크기 선택은 "GPU 몇 장으로 목표 동시 세션을 감당할 수 있는가"라는 용량 설계 문제와 묶여 있습니다.

클라우드 API 방식은 GPU 제약을 사업자에게 위임하는 대신, 네트워크 왕복 레이턴시가 새로운 변수로 들어옵니다. 온프렘에서는 로컬 추론으로 제거했던 네트워크 지연이 클라우드에서는 매 요청마다 발생합니다. 따라서 클라우드 API를 쓸 때 70B와 30B의 실질적인 레이턴시 차이는 온프렘보다 작아질 수 있습니다. 이 경우 정확도가 더 높은 70B를 선택하는 것이 합리적일 수 있습니다. 결론적으로 온프렘은 "자원 대비 속도"를, 클라우드는 "성능 대비 비용"을 축으로 판단해야 합니다.

양자화(Quantization) 효과와 30B 파인튜닝 전략

모델 크기를 줄이지 않고도 레이턴시를 개선할 수 있는 두 가지 접근이 있습니다. 양자화와 파인튜닝입니다.

양자화는 모델 가중치의 정밀도를 낮춰 메모리 점유와 추론 속도를 개선하는 기법입니다. 70B FP16(16비트 부동소수점) 모델을 Q4(4비트 양자화)로 변환하면 메모리 사용량이 약 4분의 1 수준으로 줄어들고, 추론 속도도 그에 비례해 빨라집니다. 그러나 양자화는 정확도를 일부 희생합니다. 일반 지식 질답에서는 Q4 품질 저하가 눈에 띄지 않을 수 있지만, 금융 상품 설명이나 소수점 포함 수치 처리처럼 정밀도가 중요한 콜봇 업무에서는 오류율이 올라갈 수 있습니다. 양자화를 적용할 때는 반드시 실제 업무 시나리오 기반으로 정확도를 재검증해야 합니다.

파인튜닝은 다른 방향의 전략입니다. 30B 범용 모델을 특정 도메인 데이터로 파인튜닝하면, 그 도메인 안에서는 70B 범용 모델에 준하는 정확도를 달성할 수 있습니다. 콜봇이 다루는 업무 범위가 좁고(특정 금융 상품, 특정 서비스 안내 등), 그에 맞는 학습 데이터를 확보할 수 있다면 파인튜닝은 매우 효과적입니다. 속도는 30B 수준을 유지하면서 정확도를 끌어올리는 것이 목표이므로, 온프렘 환경에서 비용 대비 성능을 최대화하려는 경우에 적합한 선택입니다.

모델 크기를 놓고 고민하는 순간을 떠올려보면, 대개 스펙 시트나 벤치마크 표를 들여다보는 데서 시작하지 않습니다. 오히려 "이 콜봇은 침묵이 1.5초를 넘기면 안 된다"는 운영 조건 하나에서 출발하는 경우가 많습니다. 그 제약을 먼저 못 박아 두면, 30B냐 70B냐는 취향의 문제가 아니라 계산 가능한 문제로 바뀝니다. 여러 사이징 결정을 겹쳐 보면, 결국 GPU 예산과 허용 침묵 시간이라는 두 숫자가 모델 크기를 사실상 결정짓는 경우가 대부분입니다.

실무에서 모델 크기 결정 체크리스트

이론적인 비교를 실제 의사결정으로 연결하려면 아래 질문들을 순서대로 검토하는 것이 유용합니다.

1. 이 콜봇이 주로 처리하는 업무의 추론 복잡도는 어느 수준인가?
단순 FAQ 분기이면 30B 이하로 시작합니다. 다단계 조회·판단이 필요하면 70B를 기준선으로 설정합니다.

2. 목표 TTFT는 얼마이고, 현재 인프라에서 각 모델이 실측치로 그것을 달성하는가?
벤치마크가 아닌 실측 기준으로 판단합니다. 파일럿에서 30B와 70B를 실제 GPU에서 돌려 비교합니다.

3. 온프렘인가, 클라우드 API인가?
온프렘이면 GPU 용량 대비 동시 세션 계산이 선행됩니다. 클라우드라면 네트워크 레이턴시를 포함한 end-to-end 측정이 필요합니다.

4. 양자화를 적용할 경우 실제 업무 시나리오에서 정확도가 허용 범위 안에 드는가?
수치·단어 정밀도가 중요한 업무(금융·의료·법률)에서는 Q4 양자화 후 반드시 재검증합니다.

5. 도메인 특화 파인튜닝을 위한 학습 데이터 확보가 가능한가?
파인튜닝은 데이터 품질이 전부입니다. 수집·정제·관리 체계 없이 파인튜닝 효과를 기대하기는 어렵습니다.

6. 상담사 어드바이저처럼 실시간 통화 외 흐름이 포함된다면 별도 모델로 분리했는가?
콜봇 응답 모델과 어드바이저 모델을 단일 GPU에 묶으면 서로의 레이턴시를 잡아먹습니다. 역할에 따라 분리 배치하는 것이 원칙입니다.

콜봇 유형별 SLM 선택 기준 요약

상황	권장 선택
단순 시나리오 분기·FAQ 응답 중심, 속도 최우선, 온프렘 GPU 자원 제한	30B (또는 파인튜닝 30B)
다단계 추론·DB 조회 포함, 오류 노출 비용이 레이턴시보다 클 때	70B
상담사 어드바이저(보조 화면 제안), 클라우드 API 방식, 도메인 집중 파인튜닝 가능	30B 파인튜닝 또는 클라우드 70B

어느 경우든 벤치마크 수치가 아니라 실제 업무 시나리오와 인프라 환경에서 직접 측정한 결과로 판단하는 것이 출발점입니다. 이 비교표 역시 공개 자료와 업계 일반론에 현장에서 얻은 관점을 더해 2026년 7월에 정리한 참고 기준일 뿐, 최종 결론은 각자의 측정 결과가 대신해야 합니다.

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

6월 13, 2026

자세한 내용 보기

이 블로그 검색

AI에이전트엔지니어링