최근 며칠 사이, 서로 무관해 보이는 세 곳에서 같은 신호를 받았습니다.

arXiv에 올라온 논문 “Bitter Lesson of Tool Calling”(2608.06370v1)은 LLM이 도구를 호출하는 방식에 구조적 한계가 있다고 주장합니다. 툴콜 포맷은 모델이 JSON 명세서를 작성하도록 강제하는 반면, 코드 기반 실행 체이닝(code-act)은 모델이 실제로 실행 가능한 로직을 생성하도록 허용합니다. 실측 결과에서 코드 기반이 툴콜 방식보다 일관되게 우세했습니다.

같은 주에 Cloudflare는 자사 인프라를 “Cloudflare OS — 기업 운영체제”로 포지셔닝했습니다. Azure는 APIM Dedicated AI Gateway를 출시하며 에이전트 트래픽을 게이트웨이 레이어에서 통제하는 표준을 내놨습니다. Agent Plugins 1.0은 공통 컨테이너 규격으로 에이전트 실행 환경을 표준화하려는 시도입니다.

세 신호는 서로 다른 레이어에 있지만, 같은 방향을 가리킵니다.

실행 환경이 제품 본체가 되고 있다.

왜 이것이 설계 문제인가

에이전트를 처음 만들 때 대부분의 팀은 “어떤 모델을 쓸까”부터 생각합니다. 다음은 “어떤 도구를 연결할까”입니다. 실행 환경은 마지막에 결정하는 인프라 세부사항처럼 취급됩니다.

Bitter Lesson of Tool Calling의 함의는 이 순서가 틀렸다는 겁니다. 도구를 어떻게 호출하는가 — 툴콜 JSON이냐 코드 실행이냐 — 가 에이전트 성능의 상한선을 결정합니다. 모델이 아무리 강해도, 실행 방식이 제약이 되면 그 역량은 발현되지 않습니다.

더 직접적으로 말하면: 코드를 실행할 수 없는 에이전트 런타임은 이미 레거시 설계입니다.

Cloudflare OS와 Azure APIM이 보여주는 방향도 같습니다. 에이전트 트래픽은 이제 단순 API 호출이 아닙니다. 인증, 속도 제한, 관측성, 비용 통제, 장기 실행 세션 관리 — 이 모든 것이 실행 환경 레이어에서 처리되어야 합니다. 이 레이어를 누가 설계하느냐가 에이전트 제품의 운명을 결정합니다.

PM 관점에서 다시 보면

2025년까지 AI PM의 핵심 역량은 “모델을 평가하고 프롬프트를 설계하는 것”이었습니다.

2026년, 그 역할이 이동하고 있습니다. 이제 핵심은 실행 환경을 설계하는 것입니다.

구체적으로 무엇이 달라지는가:

기존: 어떤 모델을 쓰고, 어떤 프롬프트를 쓰고, 어떤 도구를 연결할지 정의한다.

지금: 에이전트가 어떻게 실행되는지 — 코드 기반인지 툴콜인지, 상태를 어떻게 관리하는지, 실패 시 fallback 로직이 무엇인지, 비용을 어떤 레이어에서 통제하는지 — 를 설계한다.

Agent Plugins 1.0이 공통 컨테이너 표준을 밀어붙이는 이유가 여기 있습니다. 실행 환경이 표준화되면, 그 위에서 동작하는 에이전트들의 교체 비용이 낮아집니다. 모델과 도구는 교체 가능한 부품이 되고, 실행 환경 자체가 해자(moat)가 됩니다.

반대로: 실행 환경을 설계하지 않고 에이전트를 만든 팀은 표준이 등장할 때마다 처음부터 다시 시작해야 합니다.

설계 기준 세 가지

이 신호들을 종합하면, 지금 에이전트를 설계하는 팀이 반드시 결정해야 할 세 가지가 있습니다.

1. 코드 실행 vs. 툴콜 — 실행 패러다임을 먼저 정해라

Bitter Lesson of Tool Calling이 보여주듯, 이 선택은 에이전트 성능의 상한을 결정합니다. 여러분의 런타임이 코드를 실행할 수 있습니까? Claude Code는 코드 실행 기반입니다. LangGraph는 노드-엣지 구조로 실행을 체이닝합니다. 선택의 근거가 있어야 합니다.

# 툴콜 방식: 모델이 JSON 명세를 생성하면 런타임이 실행
{"tool": "search", "query": "에이전트 실행 환경"}

# 코드 실행 방식: 모델이 직접 실행 가능한 코드를 생성
results = search("에이전트 실행 환경")
if not results:
    results = fallback_search("agent runtime")

두 번째 패턴에서 모델은 조건 분기와 fallback 로직을 스스로 작성합니다. 첫 번째 패턴에서는 런타임이 그 로직을 미리 결정해두어야 합니다.

2. 실행 환경 레이어 — 직접 만들 것인가, 빌릴 것인가

Azure APIM Dedicated AI Gateway나 Cloudflare OS 같은 솔루션이 에이전트 트래픽 관리의 표준을 제시하고 있습니다. 직접 구축할 경우 관측성·인증·비용 통제를 직접 설계해야 합니다. 빌릴 경우 벤더 종속성이 생기지만, 운영 성숙도를 즉시 확보할 수 있습니다.

핵심 판단 기준은 하나입니다: 이 레이어가 차별화 요소입니까, 아니면 기반 인프라입니까? 차별화 요소가 아니라면 빌리는 것이 맞습니다.

3. 상태 관리 — 에이전트는 어디에 무엇을 기억하는가

장기 실행 에이전트의 상태를 어떻게 저장하고 복구하는지가 실행 환경 설계의 핵심입니다. Canva의 S3 공유 상태, LangSmith Gateway의 비용 통제는 이 레이어에 대한 실전 답입니다. “에이전트가 멈추면 어떻게 되는가”를 설계하지 않은 시스템은 프로덕션에서 반드시 부서집니다.

마치며

“어떤 모델을 쓸지”보다 “어떤 실행 환경 위에서 돌릴지”를 먼저 결정하는 팀이 2026년 하반기에 유리한 위치에 있을 겁니다.

여러분의 에이전트는 지금 어떤 실행 환경 위에 있습니까? 그리고 그 선택은 의도한 것입니까?