작성일: October 12, 2025
지난 1년간 AI 에이전트를 구축한다는 것은 보통 한 가지를 의미했습니다. while 루프를 설정하고, 사용자 프롬프트를 받아 LLM에 전송하고, 도구 호출을 파싱하고, 도구를 실행하고, 결과를 다시 전송한 뒤 이를 반복하는 것이었습니다. 우리는 이것을 얕은 에이전트 또는 에이전트 1.0이라고 부릅니다.
이 아키텍처는 “도쿄의 날씨는 어떻고 무엇을 입어야 할까?”와 같은 단발성 작업에는 매우 단순하고 효과적이지만, 3일에 걸쳐 50단계가 필요한 작업을 수행하도록 요청받으면 필연적으로 주의가 분산되고, 컨텍스트를 잃어버리고, 무한 루프에 빠지거나, 단일 컨텍스트 윈도우로 처리하기에는 너무 많은 단계가 필요하여 환각을 일으킵니다.
우리는 Deep Agents 또는 에이전트 2.0으로의 아키텍처 전환을 목격하고 있습니다. 이러한 시스템은 단순히 루프에서 반응하지 않습니다. 다단계의 복잡한 문제를 해결하기 위해 에이전트 패턴을 결합하여 계획을 수립하고, 영구 메모리/상태를 관리하며, 전문화된 하위 에이전트에게 작업을 위임합니다.
에이전트 1.0: “얕은” 루프의 한계
우리가 어디로 가고 있는지 이해하려면, 현재 우리가 어디에 있는지를 이해해야 합니다. 오늘날 대부분의 에이전트는 “얕습니다”. 이는 LLM의 컨텍스트 윈도우(대화 기록)에 전적으로 의존하여 상태를 관리한다는 의미입니다.
- 사용자 프롬프트: “애플 주가를 찾아서 좋은 매수인지 알려줘.”
- LLM 추론: “검색 도구를 사용해야겠어.”
- 도구 호출:
search("AAPL stock price") - 관찰: 도구가 데이터를 반환합니다.
- LLM 응답: 관찰 결과를 바탕으로 응답을 생성하거나 다른 도구를 호출합니다.
- 반복: 완료될 때까지 루프를 반복합니다.
이 아키텍처는 상태를 저장하지 않으며 일시적입니다. 에이전트의 전체 “두뇌”는 컨텍스트 윈도우 안에 있습니다. 작업이 복잡해지면, 예를 들어 “10개 경쟁사를 조사하고, 그들의 가격 모델을 분석하고, 비교 스프레드시트를 만들고, 전략 요약을 작성해줘”와 같은 경우 다음과 같은 이유로 실패합니다:
- 컨텍스트 오버플로: 도구 출력(HTML, 복잡한 데이터)으로 히스토리가 가득 차서 지시사항이 컨텍스트 윈도우 밖으로 밀려납니다.
- 목표 상실: 중간 단계의 노이즈 속에서 에이전트는 원래 목표를 잊어버립니다.
- 복구 메커니즘 부재: 토끼굴에 빠지면, 멈추고 되돌아가서 새로운 접근 방식을 시도할 선견지명이 거의 없습니다.
얕은 에이전트는 5-15단계가 필요한 작업에는 훌륭합니다. 500단계가 필요한 작업에는 형편없습니다.
에이전트 2.0(Deep Agents)의 아키텍처
Deep Agents는 계획과 실행을 분리하고 컨텍스트 윈도우 외부에서 메모리를 관리합니다. 이 아키텍처는 네 가지 기둥으로 구성됩니다.
기둥 1: 명시적 계획
얕은 에이전트는 연쇄 사고(chain-of-thought)를 통해 암묵적으로 계획합니다(“X를 해야 하고, 그 다음 Y를 해야겠어”). Deep Agents는 도구를 사용하여 명시적 계획을 생성하고 유지하는데, 이는 마크다운 문서의 할 일 목록일 수 있습니다.
모든 단계 사이에 에이전트는 이 계획을 검토하고 업데이트하여, 단계를 pending, in_progress, completed로 표시하거나 메모를 추가합니다. 단계가 실패하면, 맹목적으로 재시도하지 않고 실패를 수용하도록 계획을 업데이트합니다. 이는 에이전트가 상위 수준의 작업에 집중하도록 유지합니다.
기둥 2: 계층적 위임(하위 에이전트)
복잡한 작업에는 전문화가 필요합니다. 얕은 에이전트는 하나의 프롬프트에서 만능이 되려고 시도합니다. Deep Agents는 오케스트레이터 → 하위 에이전트 패턴을 활용합니다.
오케스트레이터는 작업을 하위 에이전트에게 위임하며, 각 하위 에이전트는 깨끗한 컨텍스트를 가집니다. 하위 에이전트(예: “연구원”, “코더”, “작성자”)는 도구 호출 루프(검색, 오류 발생, 재시도)를 수행하고, 최종 답변을 정리하여, 종합된 답변만 오케스트레이터에게 반환합니다.
기둥 3: 영구 메모리
컨텍스트 윈도우 오버플로를 방지하기 위해, Deep Agents는 파일시스템이나 벡터 데이터베이스와 같은 외부 메모리 소스를 진실의 원천으로 활용합니다. Claude Code와 Manus 같은 프레임워크는 에이전트에게 이들에 대한 read/write 접근 권한을 제공합니다. 에이전트는 중간 결과(코드, 초안 텍스트, 원시 데이터)를 작성합니다. 후속 에이전트는 파일 경로나 쿼리를 참조하여 필요한 것만 검색합니다. 이는 패러다임을 “모든 것을 기억하기”에서 “정보를 어디서 찾을지 아는 것”으로 전환합니다.
기둥 4: 극한의 컨텍스트 엔지니어링
더 스마트한 모델이라고 해서 더 적은 프롬프팅이 필요한 것은 아니며, 더 나은 컨텍스트가 필요합니다. “당신은 도움이 되는 AI입니다.”라고 말하는 프롬프트로는 에이전트 2.0 동작을 얻을 수 없습니다. Deep Agents는 매우 상세한 지시사항에 의존하며, 때로는 수천 토큰 길이입니다. 이러한 지시사항은 다음을 정의합니다:
- 행동하기 전에 멈추고 계획해야 하는 시점을 식별하기.
- 스스로 작업을 수행하는 것 대 하위 에이전트를 생성하는 것에 대한 프로토콜.
- 도구 정의 및 사용 방법과 시기에 대한 예제.
- 파일 명명 및 디렉토리 구조에 대한 표준.
- 휴먼-인-더-루프 협업을 위한 엄격한 형식.
Deep Agents 흐름 시각화
이러한 기둥들이 어떻게 결합될까요? 복잡한 요청을 처리하는 Deep Agents의 시퀀스 다이어그램을 살펴보겠습니다: “양자 컴퓨팅에 대해 조사하고 파일에 요약을 작성해줘.”
결론
얕은 에이전트에서 Deep Agents로(에이전트 1.0에서 에이전트 2.0으로) 이동하는 것은 단순히 LLM을 더 많은 도구에 연결하는 것이 아닙니다. 이는 반응적 루프에서 능동적 아키텍처로의 전환입니다. 이는 모델 주변의 더 나은 엔지니어링에 관한 것입니다.
명시적 계획, 하위 에이전트를 통한 계층적 위임, 영구 메모리를 구현함으로써, 우리는 컨텍스트를 제어할 수 있으며, 컨텍스트를 제어함으로써 복잡성을 제어하여, 단 몇 초가 아닌 몇 시간이나 며칠이 걸리는 문제를 해결할 수 있는 능력을 잠금 해제합니다.
감사의 말
이 개요는 깊이 있는 수동 연구를 통해 작성되었습니다. “Deep Agents” 용어는 특히 LangChain 팀이 이 아키텍처 진화를 설명하기 위해 대중화했습니다.