관리형 에이전트가 에이전트 개발의 다음 큰 흐름인 이유
TMT오늘 Managed Deep Agents를 출시합니다. 프로덕션 에이전트를 만들고, 실행하고, 배포하는 가장 쉬운 방법입니다. 더 자세한 내용이 궁금하시면 정식 출시 블로그와 문서를 참고하세요. 이 글에서는 여기까지 오게 된 여정과, 제가 에이전트 개발의 다음 단계라고 생각하는 이 방향에 왜 이렇게 설레는지 이야기해 보려 합니다.
에이전트 개발에는 뚜렷이 구분되는 몇 개의 시기가 있었다고 생각합니다.
그중 앞선 두 시기를 간단히 짚어 보면 다음과 같습니다.
- 초기 AI 프레임워크와 앱 (2022년 말~2023년 초): LangChain이 2022년 10월에 출시되었고, ChatGPT는 2022년 11월, AutoGPT는 2023년 초에 나왔습니다. 모두 LLM을 처음으로 활용하기 시작한 초기 AI 프레임워크 또는 앱이었습니다.
- LangGraph, Google ADK, Vercel의 AI SDK 같은 더 성숙한 AI 프레임워크는 2024년과 2025년 상반기에 등장했습니다. 이 프레임워크들은 개발자에게 LLM을 더 세밀하게 제어할 수단을 주었습니다. 지금 우리가 생각하는 모습의 에이전트를 만들던 시기는 아니었지만, 그 덕분에 더 복잡한 AI 앱은 만들 수 있었습니다.
2025년 초에서 중반 사이 어느 시점부터, 모델이 오늘날 우리가 생각하는 에이전트를 구동할 만큼 좋아지기 시작했습니다. 바로 루프를 돌며 도구를 호출하는 LLM입니다. 이것이 오늘날의 에이전트를 떠받치는 핵심 기본 요소이자 핵심 알고리즘입니다. Manus, Deep Research, Claude Code 같은 아주 초기의 에이전트 앱들도 모두 이 패턴을 따랐습니다.
모델이 루프를 돌며 도구를 호출하는 것만으로 충분히 잘 동작하게 되자, 이는 그 위에 무언가를 쌓아 올릴 수 있는 더 단단한 토대가 되었습니다. 이 루프에 어떤 도구와 환경을 넣어야 하는지 알아가는 과정에서 Claude Code, Pi, Deep Agents 같은 에이전트 하네스(Agent Harness) 개념이 등장했습니다. 우리는 거의 1년 전에 Deep Agents를 출시했습니다. 애플리케이션 계층에서 관찰한 패턴들을 범용 하네스로 옮겨 오려던 첫 시도 중 하나였습니다.
지난 1년 동안 다음 방향을 결정지은 배움이 두 갈래 있었습니다.
첫째, 이런 에이전트 하네스를 대규모로 운영하는 데 필요한 공통 기본 요소들을 알게 되었습니다. 에이전트 루프 실행을 뒷받침하는 내구성 있는 실행(durable execution)이나, 신뢰할 수 없는 코드를 실행하기 위한 샌드박스 같은 것들입니다. "두뇌와 손을 분리한다"는 것도 흔한 설계 선택이 되었습니다. 이런 에이전트를 운영하는 데 필요한 인프라의 윤곽이 점점 뚜렷해지기 시작했습니다.
둘째, 사용자가 이런 에이전트 하네스를 어떻게 움직여야 하는지에 대한 표준이 등장했습니다. 기본 지침을 담는 AGENTS.md, 다른 시스템과 연결하는 MCP, 컨텍스트를 점진적으로 드러내는 스킬 같은 것들입니다. 이것들이 하네스의 각 부분을 제어하고 움직이는 표준이 되었습니다.
이 두 흐름이 합쳐지면서 "관리형 에이전트(managed agent)" 경험이 떠올랐습니다. 에이전트 하네스는 관리형 인프라 위에서 돌고, 개발자는 이 표준들을 사용해 에이전트의 동작을 조종하는 방식입니다.
저는 이 관리형 에이전트 경험이 프로덕션 에이전트 개발의 새로운 물결을 열어 줄 것이라고 생각합니다. 에이전트를 만들 때는 세 가지 부분이 필요합니다.
- 직접 제공하는 비즈니스 로직(컨텍스트, 도구, 지침)
- 하네스
- 하네스를 프로덕션에서 실행할 인프라
비즈니스 로직은 언제나 직접 가져와야 합니다. Deep Agents 같은 기성 하네스 덕분에 시작하기는 쉬워졌습니다. 하지만 에이전트를 프로덕션에서 돌리려고 하면 마주치는 난관이 한둘이 아닙니다!
- 런타임: 어떻게 안정적으로 실행할 것인가? 실행이 중간에 실패하면 어떻게 이어서 재개할 것인가?
- UX: 이벤트를 UI로 어떻게 스트리밍해 보낼 것인가? 사용자가 이미 있는 곳으로 에이전트를 어떻게 데려갈 것인가?
- 샌드박스: 신뢰할 수 없는 코드는 어디서 실행할 것인가?
- 컨텍스트 관리: 지침, 스킬을 비롯한 컨텍스트는 어디에 둘 것인가? 현업 사용자(또는 도메인 전문가)가 직접 수정하게 할 수 있는가?
- 평가: 프롬프트, 도구, 모델을 바꿨을 때 그 변화를 어떻게 평가할 것인가?
- 메모리: 에이전트는 무엇을 기억하는가?
- 인증: 누가 에이전트를 호출할 수 있고, 무엇을 할 수 있는가? 에이전트가 외부 시스템을 호출할 때는 누구의 자격으로 동작하는가?
고려할 것이 정말 많습니다! 관리형 에이전트 서비스는 하네스와 인프라를 한 묶음으로 제공해서 이 가운데 상당 부분을 덜어 줍니다. 개발자 입장에서는 하네스를 고른 뒤 이 조각들을 하나하나 직접 조립하는 대신, 하네스와 인프라가 묶인 패키지 하나만 고르면 됩니다. 훨씬 쉽죠!
우리가 작업한 초기 버전 하나가 Fleet입니다. 우리의 노코드 에이전트 개발 플랫폼이죠. Fleet은 "관리형"이라는 측면을 극단까지 밀어붙인 제품으로, 비개발자를 위해 만들어졌고 순수하게 UI 기반입니다. 필요하면 에이전트를 코드로 다시 옮기기 쉽도록 AGENTS.md, 스킬, MCP 같은 표준을 사용했습니다.
여기서 의도적으로 택한 것이 하나 있습니다. Fleet 에이전트를 그저 파일 시스템 안의 파일들로 표현하고 정의한 것입니다. 위에서 말한 표준들도 결국 우리 하네스가 로드하는 파일이 되었을 뿐입니다. Fleet 에이전트를 파일 탐색기로 보여 주는 토글까지 있었습니다.
Fleet은 우리에게는 조금 다른 대상, 즉 비개발자를 겨냥한 제품이었습니다. 그런데 워낙 "관리형"인 데다 우리의 주된 사용자층이 대부분 개발자이다 보니, 점점 더 기술적인 기능 요청이 쌓여 갔습니다. 커스텀 미들웨어, 코드로 작성하는 커스텀 도구, API를 통한 프로그래밍 방식의 에이전트 생성 같은 것들이었습니다.
Claude Managed Agents는 그로부터 조금 뒤에 출시되었습니다. 역시 UI 기반 경험을 갖추었지만 그보다는 API 우선에 가까워서 개발자를 훨씬 더 겨냥한 제품이었습니다. API로 에이전트를 아주 쉽게 만들 수 있게 했고, 같은 표준을 상당수 사용했습니다. 에이전트 정의를 파일 시스템의 파일로 다루는 방식에는 상대적으로 덜 기댔습니다. "드리밍(dreaming)" 같은 흥미로운 개념도 선보였습니다.
Vercel은 한 달쯤 전에 Eve를 출시하며 이 대열에 합류했습니다. Eve는 에이전트를 파일로 표현하는 방식에 확실하게 기울어 있고, 같은 표준을 상당수 사용하며, 배포하기 쉽도록 인프라를 함께 묶어 제공합니다.
오늘 우리는 개발자를 위한 우리 버전의 관리형 에이전트, Managed Deep Agents를 출시합니다. Deep Agents 하네스 위에 만들어졌고, 에이전트를 파일로 표현하지만, Fleet보다 훨씬 폭넓게 구성할 수 있습니다. 커스텀 미들웨어와 코드로 작성한 커스텀 도구를 직접 가져올 수 있습니다. 에이전트를 프로덕션에서 쉽게 운영할 수 있도록 인프라도 함께 묶여 있습니다.
- 런타임: LangSmith Deployments
- UX: LangSmith Agent Server의 스트리밍, Channels
- 샌드박스: LangSmith Sandboxes
- 컨텍스트 관리: LangSmith Context Hub
- 평가: Harbor
- 메모리: Deep Agents 위에 정해진 방식으로 제공
- 인증: 인증(AuthN) 내장
이번 출시는 최근 들어 제가 가장 기대하는 것 중 하나입니다. 개발자가 에이전트를 로컬에서 돌려 보는 데 그치지 않고, 프로덕션에서 만들고 배포하는 일이 훨씬 쉬워지리라 생각합니다.
시작해 보고 싶으시면, 제가 촬영한 "20분 만에 이해하는 Managed Deep Agents" 영상이 가장 좋은 출발점이 될 것입니다.
에이전트 개발은 아직 초기 단계라고도 생각합니다. 새로운 인프라 요구 사항이 계속 나타날 것이고, 더 많은 표준이 필요해질 것입니다. 그것들을 여러분과 함께 배우고 함께 만들어 가고 싶으니, 피드백을 편하게 보내 주세요.
