에이전트 하나로 안 될 때 여럿을 붙이면 생기는 일: 멀티에이전트와 추론 인프라

약 14분developer-tools
#멀티에이전트#추론 인프라#GPU#레이턴시#휴먼 인 더 루프#AI 에이전트#용어 사전
※ 편집 원칙: 아래 업무 상황과 인물은 용어 이해를 돕기 위한 가상 시나리오입니다. 실제 저자 경험이나 특정 회사의 사건을 재현한 내용이 아닙니다.
가상의 스타트업 운영팀이 고객 문의 자동 응답을 에이전트 하나로 돌리다가, 답이 자꾸 엉키자 분석과 검색, 검수 셋으로 나눈 상황을 생각해 보겠습니다.
답변 품질은 눈에 띄게 좋아졌습니다. 그리고 월말에 모델 API 청구서가 도착했습니다.

에이전트를 셋으로 나눴더니 청구서가 세 배가 됐을 때

text
12026-08 usage summary
2  agent:analyze    1.9M tokens
3  agent:retrieve   2.4M tokens
4  agent:review     1.7M tokens
5  total            6.0M tokens   (2026-07: 2.1M)
청구서가 원인까지 알려 줬습니다. 에이전트마다 같은 고객 문의 원문과 앞선 에이전트의 결과를 다시 읽으니, 문의 한 건에 모델 호출이 세 번이 아니라 여섯 번 넘게 나갔습니다.
에이전트를 나누면 일이 나뉘는 게 아니라 맥락이 복제됩니다. 각 에이전트가 자기 몫의 프롬프트와 도구 설명, 이전 단계의 결과를 따로 받기 때문입니다.
무엇이 곱해졌는지 정확히 보려면 이 구조의 이름부터 짚어야 했습니다.

여러 에이전트가 한 목표를 나눠 맡는 구조, 멀티에이전트 시스템

검색, 분석, 검수처럼 특정 작업에 맞춘 에이전트 여럿을 한 팀처럼 굴려, 단일 에이전트가 감당하기 어려운 목표를 완수하는 방식이 멀티에이전트 시스템입니다. 단일 에이전트는 단계가 많아질수록 지시를 잊거나 환각을 일으킬 확률이 높아지는데, 그 위험을 역할 분리로 낮추는 대신 조율 비용을 치릅니다.
오케스트레이터와 워커가 역할을 나누는 구조 자체는 Orchestrator·Worker·MCP 편에서 다뤘으니, 여기서는 굴릴 때 곱해지는 것만 보겠습니다. 토큰은 에이전트 수만큼, 왕복 지연은 단계 수만큼, 실패 지점은 둘의 곱만큼 늘어납니다.
오케스트레이터가 분석, 검색, 검수 세 에이전트에 원문과 지시를 보내고 결과를 되받는 메시지 흐름, 화살표마다 맥락이 다시 실려 나가는 그래프
문의 한 건이 에이전트 사이를 오가며 여섯 번의 호출로 늘어나는 흐름
그 여섯 번의 호출이 어디로 갔는지는 청구서 다음 줄에 적힌 엔드포인트 주소가 알려 줬습니다. 자체 서빙 서버였습니다.

그 요청을 실제로 받아내는 곳, 추론 인프라라는 밑바닥

text
114:02:11.020  gw    accept       req=a91  model=qwen3-32b  queue=7
214:02:11.512  gw    batch        req=a91  batch_id=b17     size=8
314:02:12.940  gpu0  start        batch=b17
414:02:14.105  gpu0  first_token  req=a91  (TTFT 3.08s)
서버 로그를 다시 보니 요청이 모델에 닿기 전에 대기열에서 0.5초, 배치 묶음에서 1.4초를 기다렸습니다. 모델이 느린 게 아니라 모델 앞이 막혀 있었습니다.
학습을 마친 모델이 실제 요청에 실시간으로 답하도록 받쳐 주는 GPU 하드웨어와 서빙 소프트웨어, 그 앞의 게이트웨이와 배치 계층의 총체가 추론 인프라입니다. 용어사전 기준으로 2026년 AI 인프라 지출의 55% 이상이 학습이 아니라 이 운영 구간에서 나갑니다.
관리형 API 만 쓸 때는 이 층이 보이지 않습니다. 월간 토큰이 수천만 개를 넘어 자체 서빙을 검토하는 순간부터 대기열과 배치 크기가 내 문제가 됩니다. 이 층을 서버 하나로 묶어 주는 도구로는 SIE 가 있습니다.
요청이 게이트웨이의 대기열, 배치 묶음, GPU 서빙 런타임, 모델 순으로 내려가는 계층 구조와 각 층에서 걸린 시간
요청이 모델에 닿기까지 지나는 층. 시간은 위 로그의 값
어두운 서버실 통로에서 녹색 상태등이 늘어선 랙 앞에 클립보드를 들고 서 있는 사람
대기열이 원인이라는 걸 알고 나서도 어디까지가 인프라 탓이고 어디부터가 모델 탓인지 선을 긋기 어려웠습니다. 그 선을 그어 준 것은 옆자리 동료의 한마디였습니다.

응답이 느린 게 모델 탓이 아닐 때: 추론 성능, 레이턴시, GPU 대기열

"첫 토큰 시간이랑 초당 토큰 수를 따로 재 봐." 동료가 알려 준 두 지표로 나눠 보니 그림이 달라졌습니다.
추론 성능은 모델이 입력을 받아 결과를 내는 속도와 효율이고, 첫 토큰이 나오기까지의 시간(TTFT)과 초당 토큰 수(TPS)로 잽니다. 레이턴시는 사용자가 요청을 보낸 순간부터 첫 응답이나 전체 결과까지 걸린 시간 전체라, 네트워크와 대기열, 배치가 전부 들어갑니다.
이 사례에서 초당 토큰 수는 정상이었고 첫 토큰 시간만 3초를 넘겼습니다. 생성은 문제가 없고 시작이 늦은 것이니, GPU 를 더 붙이는 대신 배치 대기 시간을 줄이는 쪽이 답이었습니다.
실시간 응대 에이전트라면 첫 토큰 200밀리초 이내가 기준선이고, 문서 요약처럼 기다려도 되는 작업이면 단가가 낮은 서버리스 GPU 로 돌리는 편이 맞습니다. 같은 인프라라도 작업의 성격이 기준을 정합니다.
대기열, 배치 대기, 첫 토큰 계산, 생성 구간을 가로 막대로 이어 붙이고 첫 토큰 시간이 어디까지 누적되는지 표시한 타임라인
지연이 누적되는 구간. 첫 토큰 시간은 생성이 시작되기 전까지의 합
속도를 잡고 나니 다음 문제는 품질이 아니라 책임이었습니다. 검수 에이전트가 승인한 답변이 고객에게 그대로 나갔고, 그중 하나가 환불 약속이었습니다.

사람을 어디에 세울지 정하는 문제, 휴먼 인 더 루프

text
1# 2026-03 운영 메모
2- 환불/계약 변경은 사람이 승인  -> 아직 미구현
3- 자동 승인 임계값 0.8 은 임시값
반년 전 자신이 남긴 메모를 뒤늦게 찾았습니다. 사람 승인 단계는 계획에만 있었고, 임시 임계값이 구현되지 않은 채 그대로 운영값이 돼 있었습니다.
AI 의 판단 과정에 사람의 개입 지점을 설계해, 저신뢰도 결과나 되돌리기 어려운 행동을 사람이 승인하거나 수정하게 하는 방식이 휴먼 인 더 루프입니다. 모든 단계에 사람을 세우면 자동화의 이유가 사라지므로, 세울 자리는 되돌리기 어려운 행동 직전 하나로 좁힙니다.
멀티에이전트에서는 그 자리가 에이전트 사이가 아니라 마지막 에이전트와 외부 세계 사이입니다. 검수 에이전트가 승인해도 환불 API 호출 직전에는 사람이 서야 합니다. 누가 언제 승인했는지는 감사로그 편에서 다룬 기록이 맡습니다.
에이전트 결과가 되돌릴 수 있는 행동인지 묻는 분기에서 자동 실행과 사람 승인으로 갈라지고 둘 다 감사로그로 이어지는 흐름
개입 지점을 정하는 분기. 되돌리기 어려운 행동 앞에만 사람을 둔다
승인 단계를 넣자 이번에는 다른 숫자가 튀었습니다. 검색 에이전트의 도구 호출 횟수였습니다.

도구 호출이 폭발할 때 제동을 거는 방법

text
1retrieve.search   calls=41   (avg 4/req, req=c07: 41)
2  query: "환불 규정"          -> 0 results
3  query: "환불 규정 2026"     -> 0 results
4  query: "refund policy"      -> 0 results
5  ...
같은 실패가 며칠 반복되고서야 패턴이 보였습니다. 검색 결과가 비면 에이전트가 검색어를 조금씩 바꿔 가며 다시 호출했고, 한 문의에서 41번까지 늘어났습니다.
모델이 요청을 해석해 미리 등록된 함수나 API 를 골라 인자를 채워 호출하도록 연결하는 기능이 Function Calling입니다. 모델은 호출할 함수와 인자만 구조화된 형식으로 내놓고 실행은 애플리케이션이 맡습니다. 그래서 제동도 모델이 아니라 애플리케이션 쪽에 걸어야 합니다.
AI 에이전트는 사고, 계획, 실행, 관찰 루프를 스스로 반복하는 구조라, 관찰 결과가 0건이면 루프는 멈출 이유를 찾지 못합니다. 호출 횟수 상한과 같은 검색어 재시도 금지를 코드로 두면 41번은 4번에서 끝납니다. 정책을 프롬프트가 아니라 코드에서 집행하는 도구로는 Agent Governance Toolkit 이 있고, 9월 12일 개발도구 목록에 올라갑니다.
어두운 책상 위 노트북 옆에 달린 커다란 정지 버튼에 손을 올린 장면, 옆에 종이 카드 몇 장
에이전트를 셋으로 나눈 결정은 틀리지 않았습니다. 틀린 것은 나누면 비용과 지연, 실패 지점도 함께 곱해진다는 사실을 청구서가 올 때까지 몰랐다는 점입니다. 곱해지는 자리를 미리 알면 어디에 대기열을, 어디에 사람을, 어디에 상한을 둘지가 정해집니다.

자주 묻는 질문

멀티에이전트가 항상 단일 에이전트보다 낫나요?

아닙니다. 역할이 실제로 분리되는 작업에서만 오류율이 내려가고, 대신 토큰과 왕복 지연, 조율 실패 지점이 에이전트 수만큼 늘어납니다. 단일 에이전트가 단계를 잊는 문제가 관측되지 않았다면 아직 나눌 이유가 없습니다.

추론 인프라는 자체 구축해야 하나요?

월간 토큰이 수천만 개 미만이면 관리형 API 가 대체로 유리하고, 그 이상이거나 데이터가 외부로 나갈 수 없을 때 자체 서빙을 검토합니다. 자체 서빙이라면 SIE 처럼 게이트웨이와 오토스케일링까지 묶인 스택으로 시작하면 대기열과 배치를 직접 짜지 않아도 됩니다.

휴먼 인 더 루프는 어느 단계에 두나요?

되돌리기 어려운 행동 직전 한 곳입니다. 환불, 계약 변경, 외부 발송처럼 실행 뒤 취소가 어려운 호출 앞에 승인을 두고, 나머지는 자동으로 흘려보내되 감사로그로 남깁니다.

이 글은 용어사전의 멀티에이전트 시스템과 추론 인프라 항목을 보강하며 쓴 글입니다. 역할 구조 설명은 Orchestrator·Worker·MCP 편과 겹치지 않게, 여럿을 굴릴 때 비용과 지연이 곱해지는 지점만 다뤘습니다.

참고·근거

vLLM 문서 · SGLang 문서 · SIE 저장소 · Agent Governance Toolkit 저장소 · OpenAI Function calling 가이드 · NIST AI Risk Management Framework

관련 글

Subagent·Hook·Slash Command: AI 코딩 도구에서 자주 만나는 확장 개념

AI 코딩 도구를 쓰다 마주치는 서브에이전트, 훅, 슬래시커맨드를 가상 업무 시나리오로 풀어 설명합니다.

권한 프롬프트·Sandbox·Checkpoint: AI 에이전트의 실행 경계 이해하기

AI 코딩 도구를 쓰다 마주치는 권한 프롬프트, 샌드박스, 체크포인트 등 5개 용어를 가상 업무 시나리오로 풀어 설명합니다.

Kill Switch·Backoff·Runtime: 실행을 멈추고 복구하는 기본 장치

AI 코딩 도구를 쓰다 마주치는 킬 스위치, 백오프, 레포지토리 등 5개 용어를 가상 업무 시나리오로 풀어 설명합니다.