기업용 에이전트 AI 환경 구축을 위한 실무 가이드
인텔이 수천 회의 워크로드 실험을 통해 기업용 에이전트 AI(Agentic AI) 환경 구축을 위한 핵심 인사이트를 제시합니다. 에이전트 AI는 단순한 LLM 추론을 넘어 시스템 전체의 문제이므로, CPU 밀도(agent density)와 작업 지연 시간(latency) 등 실질적인 성능 지표를 중심으로 용량을 계획하고 확장해야 합니다.
원문 제목: 기업용 에이전트 AI 환경 구축하기 출처: 블로그 본문: 스폰서 제공 (Intel)
기업에게 있어 에이전트 AI(Agentic AI)의 가능성은 단순히 더 나은 챗봇 그 이상입니다. 이는 사람, 비즈니스 워크플로우, 데이터 및 시스템에 걸쳐 비즈니스 작업을 종단간(end-to-end) 실행하는 소프트웨어 에이전트를 의미합니다. 에이전트를 실행하는 데 가장 적합한 플랫폼은 적절한 CPU 용량, 유연한 데이터 액세스, 정책을 고려한 도구 사용, 관측 가능성(Observability), 메모리 관리, 그리고 에이전트를 예측 가능하게 계획하고 확장할 수 있는 기능을 갖추고 있습니다. 이러한 의존성들을 더 잘 이해하기 위해, 인텔은 수천 번의 에이전트 AI 워크로드 실험을 수행했습니다. 당사의 초기 연구 결과는 기업 리더들을 위한 5가지 실용적인 교훈을 도출하고 이를 뒷받침합니다.
- 에이전트 AI는 단순한 추론의 문제가 아닌, 더 큰 시스템의 문제입니다.
- 기존의 대부분 에이전트 AI 테스트 도구(harness)는 제한적이며 전체 시스템 성능을 측정하지 못합니다.
- 용량 계획은 에이전트 수가 아닌 vCPU(가상 CPU) 당 에이전트 밀도를 사용하여 이루어져야 합니다.
- 단순한 평균 CPU 활용률뿐만 아니라 에이전트 작업 지연 시간(latency)을 모니터링해야 합니다.
- 에이전트를 호스팅하는 시스템은 기본적으로 스케일 아웃(Scale-out)을 채택하십시오. 에이전트 당 더 많은 컴퓨팅 성능이 필요하거나 아키텍처적 제약이 있는 워크로드의 경우에만 스케일 업(Scale-up)을 예약적으로 사용하십시오.
추론 그 이상: 워크플로우 자동화로서의 에이전트 에이전트 AI는 단순한 대형 언어 모델(LLM) 추론 그 이상입니다. 기업 가치는 전체 시스템, 작업 오케스트레이션, 데이터 액세스, 도구 실행, 지연 시간 관리, 거버넌스 및 확장 가능한 인프라에 달려 있습니다. 에이전트는 목표 지향적이고 자동화된 기업 워크플로우 프로세스입니다. 이는 다단계 작업을 계획하고, 도구를 호출하며, 결과를 읽고, 실패 시 재시도합니다. 따라서 기업용 에이전트는 단순한 추론의 문제가 아니라 시스템의 문제입니다.
바람직한 상태 정의하기 대부분의 에이전트 AI 지표는 사용되는 LLM을 평가하는 데 초점을 맞추고 있습니다. 하지만 플랫폼 팀은 또한 작업에 얼마나 많은 시간이 걸리는지, 시스템 클러스터가 몇 개의 에이전트를 지원할 수 있는지, 실행 프로세스가 끝날 때 사용자가 어떤 경험을 하는지, 그리고 더 많은 에이전트가 동시에 작동할 때 비용이 어떻게 변하는지 알아야 합니다. 보다 유용한 기업적 관점의 6가지 지표는 다음과 같습니다:
- 작업 성공률 (Task success rate)
- 작업당 비용 (Cost per task)
- 작업당 소요 시간 (Time per task)
- 작업 처리량 (Task throughput)
- 에이전트 밀도 (vCPU 당 에이전트 수)
- 지연 시간 (Latency)
이러한 지표들은 기업 AI 운영자가 중요하게 생각하는 질문에 대한 해답을 제공합니다. 시스템이 예상대로 작동하고 있는가? 시스템이 몇 개의 에이전트를 유지할 수 있는가? 더 많은 에이전트를 지원하기 위해 어떻게 확장해야 하는가?
탄탄한 기반 위에서 구축하기 에이전트 AI 워크로드 성능에 대한 더 깊은 통찰력을 얻기 위해 인텔은 프로파일링, 원격 측정(telemetry), 재생(replay) 기능으로 AI 에이전트를 평가하는 오픈 소스 벤치마크 도구인 Terminal-Bench를 확장했습니다. 이를 통해 에이전트가 LLM 추론 외부의 다른 곳에서 시간을 소비하는 위치를 파악할 수 있었습니다. 이 벤치마크 확장은 LLM 응답의 결정론적 기록-재생(record-replay)을 사용하여 LLM 자체의 가변성과 에이전트 성능을 분리했습니다. LLM 응답은 한 번 기록되고 여러 실행에 걸쳐 동일하게 재생되어 실행 간 분산을 줄이고 비교를 위한 보다 신뢰할 수 있는 기준을 마련했습니다.
사용된 Terminal-Bench 작업 조합은 의도적으로 폭넓게 구성되었습니다. 여기에는 컴파일, 테스트, 데이터베이스 작업, 부울 논리, 인터프리팅, 레이 트레이싱, 압축, 선형 대수, 비디오 트랜스코딩 및 머신 러닝 학습이 포함되었습니다. 이러한 광범위한 종류의 작업들은 연구 결과를 실제 기업 환경에 더욱 적용 가능하게 만들었습니다.
3차원으로 접근하는 에이전트 AI 에이전트 AI 배포는 3단계로 접근해야 합니다: 에이전트 수가 아닌 에이전트 밀도 측면에서 계획하기: 첫 번째 규모 산정 규칙은 가용한 컴퓨팅을 기준으로 에이전트 수를 정규화하는 것입니다. vCPU 당 에이전트 수로 측정되는 에이전트 밀도는 시스템 포화 상태를 나타내는 핵심 신호입니다. 예를 들어, 밀도가 동일하다면 8개의 vCPU 시스템에서 작동하는 10개의 에이전트와 16개의 vCPU 시스템에서 작동하는 20개의 에이전트는 유사하게 작동합니다. 이는 아키텍트에게 다양한 인스턴스 크기와 프로세서 세대 간의 용량을 비교할 수 있는 이식 가능한 방법을 제공합니다. 적절한 밀도는 비즈니스 목표에 따라 달라집니다. 응답 시간이 중요한 대화형 코파일럿 및 사용자 대면 어시스턴트는 더 낮은 밀도를 선호해야 합니다. 반면 IT 워크플로우와 같은 배치 워크로드는 종종 더 높은 밀도에서 실행될 수 있습니다. 이를 통해 팀은 서비스 수준 목표(SLO)와 총비용(Total cost)을 중심으로 클러스터를 실용적으로 조율할 수 있습니다.