Niklas Falk과 Tobias Winczer가 제시한 현재 AI 인프라의 위치와 에이전트 스택 구조 분석

Niklas Falk과 Tobias Winczer는 현재 AI 인프라가 실제로 어디에 자리 잡고 있는지 매핑했으며, 그들의 에이전트 인프라 스택(agent infra stack) 분석에는 대부분의 오케스트레이션 프레임워크 논의에서 간과되는 세부 사항이 숨어 있습니다. 바로 운영체제 자체가 에이전트의 종단 간 지연 시간(end to end latency)의 56%에서 74%를 차지한다는 점입니다. 이는 Stevens Institute가 컨테이너 콜드 스타트(container cold starts)에 대해 수행한 연구 결과입니다. 표준 서버리스 환경에서 다섯 번의 호출 순차적 콜드 스타트는 에이전트가 유용한 작업을 수행하기 전에 약 6초의 순수 테일 지연 시간(pure tail latency)을 발생시킵니다.

Firecracker microVM은 메모리 오버헤드가 약 5MB에 불과한 상태로 125~200밀리초 만에 부팅함으로써 이 문제를 해결했습니다. 이것이 Blaxel, Modal 그리고 일련의 샌드박싱 스타트업들이 Lambda가 원래 설계되지 않은 작업을 위해 개조하는 대신, 에이전트 워크로드만을 위해 컴퓨트를 재구축하고 있는 이유입니다. Falk과 Winczer가 제시한 여섯 가지 계층(context, tool use, orchestration, deployment, self improvement, observability)은 Blaxel의 자체 기술 문서에서 별도로 설명된 내용과 일치합니다: LangGraph의 그래프 기반 오케스트레이션 대 CrewAI의 역할 기반 오케스트레이션, 이미 Salesforce, SAP, Google, Microsoft, OpenAI에 걸쳐 채택되고 있는 MCP(Multi-Cloud Platform), 그리고 작년 말 기준 월 수백만 건에 달하는 MCP SDK 다운로드 횟수입니다.

제가 주목한 점은 이 모든 것들에 비해 observability 계층이 여전히 얼마나 빈약하냐는 것입니다. Blaxel의 말처럼 에이전트를 위한 평가 프레임워크(evaluation frameworks)는 초기 단계이며, 도구 호출 버스트(tool call bursts) 동안 최대 평균 메모리 비율은 15배를 초과합니다. 이러한 수치는 제품 데모에서는 절대 보여지지 않지만 클라우드 청구서에는 빠르게 나타나는 종류의 숫자입니다. 팀들은 오케스트레이션 계층을 먼저 구축했습니다. 왜냐하면 그것이 눈에 보이는 계층이기 때문입니다. 그 아래 깔린 microVM, 메모리 지속성(memory persistence), 그리고 비용 제어는 실제로 더 어려운 엔지니어링이 이루어지는 곳이며, 저는 다음 AI 인프라 자금 조달 흐름은 또 다른 오케스트레이션 프레임워크가 아닌 바로 이 하부 계층으로 향할 것이라고 확신합니다.

Agent infra is here!

인프라는 항상 워크로드(workload)의 함수입니다. 에이전트 채택률(agent adoption)이 2025년 12월부터 급증함에 따라, 우리는 새로운 인프라 스택(infra stack)이 등장하는 것을 목격하고 있습니다.

아래에 제가와 토비아스(Tobias)가 무엇이 일어나고 있는지에 대한 생각을 정리했습니다! https://t.co/WSGbRmtAVF