에이전트형 AI는 지능의 한계에 부딪히기 전에 인프라의 한계에 부딪힐 것이다

모델의 발전 속도가 모델에 요구되는 작업을 처리할 수 있는 역량의 발전 속도보다 빠르다.

AI 에이전트의 향방을 둘러싼 논의는 대부분 에이전트의 역량에 관한 것이다. 모델이 안정적으로 계획을 세울 수 있는가? 스스로 저지른 실수를 바로잡을 수 있는가? 결과를 초래하는 행동을 맡겨도 믿을 수 있는가?

이는 분명 중요한 질문이다. 하지만 앞으로 몇 년간 에이전트가 대규모로 배포될지를 결정할 질문은 아니다. 더 가까운 곳에 제약 요인이 있고, 그 제약은 더 빠르게 다가오고 있기 때문이다. 에이전트는 운영 비용 측면에서 처리하기 까다로우며, 모두가 추가하고 싶어 하는 바로 그 역량이 늘어날수록 이런 어려움도 커진다.

챗봇과 에이전트는 서로 다른 작업 부하다

대화형 요청은 한 번의 왕복으로 끝난다. 프롬프트를 입력하고 토큰을 출력한 뒤 연결을 닫는다. 요청을 묶어 처리하고, 접두부를 캐시하며, 처리량을 단일 수치로 파악할 수 있다.

에이전트 요청은 하나의 세션이다. 도구를 호출하고, 기다렸다가, 결과를 읽고, 다음에 할 일을 결정한 뒤, 다른 도구를 호출하고, 결국 답변한다. 간단한 작업도 모델을 여섯 번이나 여덟 번 호출하고, 그 사이사이에 기다리는 과정이 있을 수 있다.

이 차이는 지능과는 전혀 다른 이유로 중요하다. 단계 사이사이에 에이전트는 상태를 유지한다. 대화 내용, 도구 출력, 지금까지 쌓인 추론이 여기에 포함된다. 서빙 과정에서 이 상태는 GPU 메모리에 KV 캐시 형태로 저장되며, 세션이 진행되는 내내 메모리를 차지한다. 여기에는 에이전트가 여러분이 제공하지 않는 API의 응답을 기다리는 시간도 포함된다.

따라서 용량을 나타내는 단위는 더 이상 ‘초당 요청 수’가 아니라 ‘메모리에 상주하는 동시 세션 수’가 된다. 초당 대화형 요청 1,000건을 여유 있게 처리하던 시스템도 같은 하드웨어로는 동시 에이전트 세션을 수십 개 정도밖에 처리하지 못할 수 있다.

비용이 많이 드는 건 기다리는 시간이다

불편하지만 중요한 점이 있다. 도구를 호출하는 동안 에이전트는 아무 일도 하지 않는다. 토큰을 생성하지도, 연산을 수행하지도 않는다. 하지만 GPU 메모리는 여전히 점유되어 있다. 해당 컨텍스트를 메모리에서 내보냈다가 다시 계산하는 비용이 그대로 유지하는 비용보다 크기 때문이다.

가장 비싼 하드웨어가 데이터베이스 쿼리를 기다리는 요청에 할당된 채로 묶여 있다.

기존 분산 시스템에서는 이 문제를 오래전에 해결했다. 리소스를 해제한 뒤 응답이 도착하면 작업을 다시 이어서 처리하면 된다. 모델 서빙에서 같은 방식을 적용하려면 KV 캐시를 호스트 메모리나 디스크로 내보냈다가 복원해야 하는데, 전송 비용이 너무 커서 대부분의 시스템은 그렇게 하지 않는다. 바로 이 문제에 관한 연구가 활발히 진행 중인 것도 비용이 크기 때문이다.

순차 실행은 불필요하게 문제를 키운다

거의 모든 에이전트 프레임워크는 도구 호출을 하나씩 순서대로 실행한다. 모델이 날씨를 조회해 달라고 요청하고, 결과를 받은 다음, 일정을 확인해 달라고 요청하고, 그 결과를 받은 뒤, 항공편을 검색해 달라고 요청하고, 다시 결과를 받는다.

이 세 가지 호출은 서로 의존하지 않는 경우가 많다. 동시에 실행할 수 있었던 작업이다. 순차적으로 실행하면 지연 시간은 각 작업에 걸린 시간의 합이 된다. 동시에 실행하면 가장 오래 걸린 작업의 시간만큼만 지연된다.

이는 에이전트에만 해당하는 새로운 관찰이 아니다. 하나의 지연 시간 예산 안에서 여러 모델이나 서비스를 실행하는 모든 시스템에 적용되는 구조적 문제다. 전체 지연 시간은 모든 단계의 시간을 더한 값이 아니라 종속성 그래프에서 가장 긴 경로를 기준으로 해야 한다. 에이전트에서 이 문제가 더 중요한 이유는 세션이 전체 시간 동안 GPU 메모리에 상주하기 때문이다. 따라서 실제 경과 시간을 줄이면 사용자 경험이 개선될 뿐 아니라, 같은 하드웨어에 더 많은 세션을 수용할 수 있다.

세션 시간을 절반으로 줄이면 모델을 바꾸지 않고도 같은 GPU에서 동시 처리 용량을 대략 두 배로 늘릴 수 있다.

아무도 설계하지 않은 방식으로 누적되는 재시도

에이전트 프레임워크는 기반이 되는 HTTP 라이브러리의 기본 재시도 설정을 그대로 물려받는다. 대개 세 번 시도한다.

모델도 나름의 방식으로 재시도한다. 도구가 쓸모없는 결과를 반환하면 추론 모델은 다른 접근법을 시도하는 경우가 많다. 누군가 설정한 것은 아니지만, 이것도 재시도다.

이 두 가지가 겹치면 세 번의 시도를 적용한 정책에 모델이 독자적으로 추론해 찾아낸 세 가지 접근법이 더해져, 아무도 문서화하지 않은 아홉 번의 시도 정책이 만들어진다. 각각의 시도는 별도의 토큰과 GPU 사용 시간을 소모하는 완전한 모델 호출이다.

의존 서비스가 느려지면 이런 증폭 현상이 성능 저하를 장애로 바꾼다. 게다가 시도당 비용은 재시도되는 REST 호출보다 몇 자릿수나 더 높다.

한계는 실제로 어떤 모습일까

역량의 한계가 아니다. 파일럿에서 실제 운영으로 넘어가는 단계에서 프로젝트를 멈춰 세우는, 훨씬 더 현실적인 단위 경제성 문제다.

파일럿은 잘 돌아간다. 사용자는 10명이고, 지연 시간은 감당할 만하며, 비용은 반올림 오차 수준이다. 그러다 누군가 사용자가 1만 명일 때를 추산해 보면 필요한 GPU 규모가 현실성이 없다. 모델이 느려서가 아니라, 각 동시 세션이 전체 세션 시간 동안 메모리를 점유하고, 그 시간에는 대기 시간도 포함되기 때문이다.

유망한 내부 데모 상당수가 조용히 멈추는 단계가 바로 이 지점이다.

한계를 움직이는 요인

특별할 것 없는, 모델링이 아닌 인프라 차원의 방법들이다.

독립적인 도구 호출을 동시에 실행한다. 오늘 당장 적용할 수 있고 새로운 하드웨어도 필요 없는 방법 가운데 단일 효과가 가장 크다.

세션 지속 시간을 용량 지표로 삼는다. 초당 토큰 수가 아니다. GPU 사용률도 아니다. 상태가 얼마나 오래 메모리에 상주하는지, 그리고 세션을 몇 개나 수용할 수 있는지가 중요하다.

호출별이 아니라 시스템 전체에 걸쳐 재시도를 제한한다. 전체 트래픽에서 재시도 비율을 낮게 유지하도록 전역 상한을 두면 앞서 설명한 연쇄적인 문제가 방지된다. Google의 SRE 관행인 과부하 처리와 Envoy의 재시도 예산은 모두 AI 스택 외부에서 이 아이디어를 구현한다.

추론과 실행을 분리한다. 계획에는 대형 모델을, 정형적인 단계에는 훨씬 더 작은 모델을 사용한다. 에이전트가 수행하는 작업 대부분에는 최첨단 모델이 필요하지 않다.

컨텍스트를 저렴하게 비울 수 있도록 한다. 양자화된 KV 캐시, 페이지드 어텐션, 그리고 유휴 세션을 위한 오프로드 경로를 활용한다. 지금 가장 흥미로운 서빙 기술 개발이 이뤄지는 분야다.

모델은 계속 개선될 것이다. 그 점은 확실해 보인다. 에이전트가 인프라가 될지, 아니면 데모에 머물지는 덜 화려한 문제에 달려 있다. 대기 중에도 값비싼 메모리를 점유하는 워크로드를 처리할 수 있는지, 그리고 전체 실행 경로의 시간이면 충분한데도 일련의 작업에 걸리는 시간을 모두 합한 만큼 비용을 치르는 상황을 멈출 수 있는지에 달려 있다.

단일 지연 시간 예산 안에서 서로 의존하는 모델 호출을 동시에 실행하는, 앞서 언급한 실행 모델을 「머신러닝 시스템의 모델 라우팅을 위한 비동기 추론 그래프 실행」이라는 제목으로 International Journal of Computer Trends and Technology 72(10), 2024년 10월호에 발표했다. 특히 생성형 모델을 지연 시간 제약이 있는 의사결정 시스템에 통합하는 문제는 「LLM으로 강화된 거래 및 의사결정 플랫폼: 생성형 지능과 금융 의사결정 시스템의 연결」, Journal of Information Systems Engineering and Management 11(1s), 2026을 참조하면 된다.