에이전트를 실행하는 것은 이제 기본값이다. 다음 경쟁은 에이전트를 어떻게 쌓느냐에서 벌어진다.

LangChain의 Harrison Chase가 이번 주 Managed Deep Agents를 공개하면서 한 마디를 남겼다. “The goalposts have moved.” 에이전트 오케스트레이션의 골대가 옮겨졌다는 선언이다.

이게 단순한 기능 업데이트처럼 들린다면, 한 단계 더 파고들 필요가 있다.

무엇이 바뀌었는가: 레이어드 스택의 등장

2024년까지의 에이전트 패턴은 단순했다. LLM을 호출하고, 도구를 연결하고, 결과를 받는다. LangGraph가 대화 상태를 관리하고, LangSmith가 실행 로그를 추적한다. 그것으로 충분했다.

Managed Deep Agents는 그 위에 새 실행 레이어를 얹는다.

create agent → invoke → deep agents → LangGraph 흐름 제어

에이전트가 다른 에이전트를 직접 생성하고 조율한다. 실행 결과가 다음 에이전트의 입력이 된다. 관리자(orchestrator)가 하위 실행자(executor)를 동적으로 편성한다. 단일 호출 패턴에서 계층형 실행 패턴으로 기준이 이동한 것이다.

같은 시점에 병렬·격리 실행이 오픈소스 표준으로 굳어지고 있다. Orca의 워크트리 격리, coder의 병렬 실행 환경, 18만 스타를 넘긴 n8n의 워크플로우 오케스트레이터가 한 방향을 가리킨다. 서로 다른 세 곳이 독립적으로 같은 결론에 도달했을 때는 신호가 아니라 패턴으로 봐야 한다.

왜 지금인가: 검증 병목이 실행 속도를 이겼다

Yann LeCun이 반복해서 지적하는 문제가 있다. “행동 전 추론”이 병목이라는 것이다. 에이전트가 빠르게 실행되는 것보다, 실행 전에 올바른 판단을 내리는 것이 더 어렵다. Alpamayo의 VLA(Vision-Language-Action) 연구가 로봇 물리 백본에서도 같은 결론을 내리고 있다. 실행 계층이 아무리 빨라져도, 상위 추론·검증 계층이 병목이 된다.

Managed Deep Agents의 레이어드 구조는 이 문제에 대한 설계 응답이다. 속도를 높이려는 게 아니다. 각 레이어에서 검증을 분리하고, 에이전트가 잘못된 판단을 내렸을 때 다음 레이어에서 잡을 수 있는 구조를 만들려는 것이다.

실제 사례로 보면 직관적이다. 셀렉트스타가 NH농협 데이터 검증 프로세스에 에이전트 스택을 적용했을 때, 기존 60일이 걸리던 작업이 50분으로 줄었다. 이 속도 개선의 핵심은 에이전트 단일 모델이 빨라진 게 아니다. 검증 루프를 각 스텝에서 분리하고, 오류 발생 시 다음 레이어가 감지하고 처리할 수 있는 구조를 설계했기 때문이다.

오케스트레이션은 기술 문제가 아니다. 검증 루프를 어느 레이어에서 닫을 것인지의 설계 문제다.

PM이 지금 해야 할 질문

대부분의 팀이 지금 “에이전트 1개를 어떻게 잘 만드는가”를 고민한다. 맞는 질문이지만 레이어가 하나 낮다.

실제 경쟁은 다음 질문에서 갈린다.

  • 에이전트가 실패했을 때 어느 레이어에서 감지하는가?
  • 병렬 실행 중 드리프트가 발생하면 어떤 에이전트가 교통정리를 하는가?
  • 전체 스택의 관측성(observability)은 누가 책임지는가?

LangSmith가 tracing을 표준화하고, LangGraph가 흐름 제어를 담당하고, Managed Deep Agents가 실행 단위를 계층화한다. 이 3레이어 설계를 PM 레벨에서 책임질 수 있는 팀이 2026년 하반기 에이전트 경쟁에서 앞서 나간다.

Harrison Chase가 “골대가 옮겨졌다”고 선언했을 때, 그 골대는 “얼마나 똑똑한 에이전트를 만드느냐”가 아니라 “얼마나 운영 가능한 스택을 설계하느냐”로 이동했다는 뜻이다.

에이전트를 ‘돌아가게 만드는 것’은 이제 누구나 한다. 에이전트 스택을 ‘운영 가능하게 설계하는 것’은 아직 소수다.

당신의 팀은 지금 어느 레이어에서 경쟁하고 있는가?