엔터프라이즈용 에이전트형 AI의 인프라 교훈과 용량 설계

이 요약은 AI가 원문을 분석해 생성했습니다. 정확한 내용은 원문 기준으로 확인하세요.

TL;DR

엔터프라이즈용 에이전트형 AI는 단순한 LLM 추론이 아니라 다단계 워크플로 오케스트레이션, 데이터 접근, 도구 실행, 메모리와 텔레메트리 관리 등 전체 시스템 성능에 의해 가치가 결정된다. 인텔은 수천 건의 워크로드 실험과 Terminal-Bench의 기록-재생 확장을 통해 LLM 응답 변동을 제거하고 에이전트 실행에서 발생하는 시스템 병목을 분리해 측정했으며 그 결과 용량 계획은 에이전트 수가 아닌 vCPU당 에이전트 밀도로 수립해야 하고 작업 지연을 중심으로 모니터링해야 한다는 결론을 도출했다. 따라서 대부분의 플랫폼은 기본적으로 스케일 아웃을 채택하고 에이전트당 계산 요구가 큰 경우에만 스케일 업을 고려해야 하며 이 접근은 비용 예측과 운영 안정성 확보에 직접적으로 기여한다.

섹션별 상세

에이전트형 AI는 단순한 LLM 추론 문제를 넘어 기업의 워크플로 전체를 자동화하는 시스템 아키텍처 문제로 자리잡았다. 에이전트는 목표 기반으로 다단계 계획을 세우고 도구를 호출하며 결과를 읽고 실패 시 재시도하는 일련의 작업을 수행하므로 단일 모델의 응답 시간 외에도 오케스트레이션, 데이터 접근, 도구 실행, 메모리 관리 등 여러 구성요소가 병목을 만들 수 있다. 인텔은 수천 건의 워크로드 실험을 통해 이 점을 확인했으며, 따라서 플랫폼 설계는 추론만이 아니라 전체 시스템 성능을 측정하는 방향으로 전환되어야 한다.

엔터프라이즈 환경에서 유용한 성능 관점은 모델 중심 지표를 넘어 작업 성공률, 작업당 비용, 작업 시간, 작업 처리량, vCPU당 에이전트 밀도, 지연 시간 등 여섯 가지 지표로 구성된다. 입력으로는 에이전트의 작업 유형과 동시 실행 수가 들어오고 처리 과정에서는 각 작업의 I/O·계산 패턴을 측정해 위 지표들을 산출하며 출력은 운영자가 시스템이 기대대로 동작하는지와 얼마나 많은 에이전트를 지속적으로 수용할 수 있는지에 대한 판단이다. 이러한 지표 집합은 용량 계획과 비용 최적화, 사용자 경험 보장이라는 실무적 요구에 직접적으로 응답하는 근거가 된다.

에이전트 플랫폼 성능을 정밀하게 파악하기 위해 인텔은 Terminal-Bench라는 오픈소스 벤치마크 하네스를 확장해 프로파일링·텔레메트리·재생 기능을 도입했다. 핵심 방법론은 LLM 응답을 deterministic하게 기록해 동일한 응답을 여러 번 재생함으로써 LLM의 변동성을 제거하고 에이전트 실행에서 발생하는 시스템 비용과 지연을 분리해 측정하는 것이다. 실험에서는 컴파일, 테스트, 데이터베이스 연산, 레이 트레이싱, 비디오 트랜스코딩 등 다양한 작업 믹스를 포함해 엔터프라이즈 현실을 반영한 워크로드를 사용했다는 점이 근거로 제시된다.

근거

인텔은 수천 건의 에이전트형 AI 워크로드 실험을 수행하고 Terminal-Bench를 기록·재생 기능으로 확장해 LLM 변동성을 분리했다. — 본문 내 'Intel performed thousands of agentic AI workload experiments' 및 Terminal-Bench 확장 설명 단락

용량 계획은 단순한 에이전트 수 기반이 아니라 vCPU당 에이전트 밀도(agent density)를 기준으로 수행해야 한다는 결론이 도출되었다. 실제로 에이전트마다 요구하는 CPU와 I/O 패턴이 달라 동일한 수의 에이전트를 다른 하드웨어에서 운용하면 전혀 다른 성능을 보이므로, 입력으로 각 에이전트의 평균 CPU 사용량을 측정하고 이를 vCPU 단위로 환산해 배치하는 방식이 권장된다. 이 접근은 시스템의 확장성과 비용 예측을 명확하게 만들며 수평 확장 전략을 수립하는 기초가 된다.

에이전트의 Think/Plan/Act/Reflect 단계와 각 단계별로 요구되는 컴퓨트(CPU 또는 CPU/GPU)를 매핑한 아키텍처 다이어그램이다. — Diagram이미지는 에이전트 흐름의 각 단계별로 서로 다른 컴퓨트 프로파일이 존재함을 시각적으로 전달한다. Think 단계는 CPU 또는 CPU/GPU 조합을 필요로 할 수 있고 Plan/Act/Reflect 단계는 주로 CPU에 의존하는 구간으로 표시되어 있어 용량 계획에서 단계별 자원 분배가 중요함을 보여준다. 이 다이어그램은 본문에서 주장한 '각 단계가 다른 컴퓨트 요구를 가짐'과 vCPU 기반 용량 계획 권고를 시각적 근거로 보강한다.

근거

용량 계획은 에이전트 수가 아니라 vCPU당 에이전트 밀도(agent per vCPU)로 수행해야 한다. — 본문 중 'Plan capacity is done using agents per virtual CPU (vCPU) density, not agent count' 문장과 관련 단락

운영 관점에서는 평균 CPU 사용률만 모니터링하는 것을 넘어 개별 에이전트 작업 지연(task latency)을 추적해야 한다는 실무적 권고가 강조되었다. 관찰 가능한 텔레메트리를 통해 도구 호출 대기, 외부 데이터 접근 지연, 재시도 빈도 등 세부 지표를 수집하면 사용자 경험과 처리량 저하 원인을 정확히 파악할 수 있다. 또한 기본 확장 전략으로는 에이전트 호스팅 시스템에서 스케일 아웃을 우선 적용하고, 에이전트당 계산량이 크거나 아키텍처적 제약이 있는 경우에만 스케일 업을 예약하는 방식이 비용·성능 균형에 효과적이라는 결론이 실험으로 뒷받침되었다.

근거

운영자는 평균 CPU 이용률뿐 아니라 에이전트 작업 지연(task latency)을 모니터링해야 한다. — 본문 중 'Monitor agent task latency, not just average CPU utilization' 문장과 관련 단락

용어 해설

Agent Density: — 에이전트 밀도는 가상 CPU(vCPU) 하나당 동시에 실행 가능한 에이전트 수를 의미한다. 입력으로는 에이전트의 평균 CPU 사용량과 동시성 요구가 들어오고 처리 과정은 각 에이전트의 실행 주기와 I/O 대기 시간을 고려해 vCPU로 분배하는 방식이며 출력은 단위 vCPU 당 유지 가능한 에이전트 수이다. 이 값은 용량 계획과 비용 예측을 위해 에이전트 기반 워크로드의 수평 확장 지표로 중요하다.
Terminal-Bench: — Terminal-Bench는 에이전트 워크로드를 재현하고 프로파일링하기 위한 벤치마크 하네스이다. 이 글에서는 LLM 응답을 기록·재생(replay)하는 기능을 추가해 에이전트 성능을 LLM 변동성에서 분리했다는 점이 핵심 작동 방식이다. 벤치마크는 다양한 엔터프라이즈 작업 믹스를 실행해 시스템 병목과 인프라 요구를 평가하는 데 쓰인다.
Record-Replay: — 기록-재생은 한 번의 실행에서 생성된 LLM 응답을 고정된 기록으로 저장하고 이후 실험에서 동일한 응답을 재생하는 방식이다. 이 방식은 반복 실험 간 응답 변동을 제거해 에이전트 플랫폼의 시스템적 성능 차이를 명확히 식별할 수 있게 한다. 재현 가능성이 중요한 성능 비교와 용량 측정에서 핵심적이다.
vCPU: — vCPU는 가상화된 중앙처리장치 리소스 단위로서 에이전트 워크로드의 계산 용량을 계량하는 기준으로 사용된다. 에이전트 수용력 평가에서는 vCPU 단위로 에이전트 밀도를 산정해 수평 확장(스케일 아웃) 계획과 비용 산정의 근거로 삼는다. 물리적 CPU와의 매핑, 스케줄링 대기와 I/O 패턴이 성능에 큰 영향을 준다.

기술

Terminal-Bench
vCPU

활용 사례

엔터프라이즈 워크플로 자동화
다단계 도구 호출을 포함하는 작업의 대규모 배치 실행