LangChain의 DeepAgents 프레임워크

• 기존 LLM 기반 에이전트는 단순히 툴을 반복 호출하는 '얕은(shallow) 에이전트' 구조가 일반적이나, Deep Agents는 복잡하고 장기적인 과업도 깊이 있게 해결하는 계획적·구조적 AI 에이전트임
• Deep Research, Manus, Claude Code와 같은 최신 에이전트들은 더 깊은 주제 탐색과 컨텍스트 관리가 가능한 '딥 에이전트'를 구현
  • 상세 시스템 프롬프트, 계획 도구, 서브 에이전트, 파일 시스템 활용이 '딥 에이전트'의 핵심
• LangChain은 누구나 쉽게 자신의 vertical(도메인)에 맞는 deep agent를 만들 수 있도록 오픈소스 패키지 deepagents 를 배포
  • 커스텀 프롬프트·툴·서브에이전트 설정이 가능하며, 연구·개발 등 다양한 분야에서 응용 가능한 범용 프레임워크 제공

---

기존 LLM 에이전트의 한계와 Deep Agents의 특징

• 전통적 에이전트: LLM이 루프를 돌며 툴만 호출 → 짧은 맥락, 단기·단순 작업에만 적합
• Deep Agents: 장기적 목표, 복잡한 태스크도 스스로 분해·계획·추적·협업 가능

Deep Agents를 구성하는 4가지 요소

1. 상세 시스템 프롬프트

   • Claude Code 등 대표적 사례처럼, 도구 사용법/행동 예시를 자세히 명시한 프롬프트 활용
   • 복잡한 지침과 few-shot 예시로 더 '깊은' 사고와 실행 유도

2. 계획(Planning) 도구

   • 실제 기능이 없어도 'To-Do 리스트' 등 계획 도구를 루틴에 포함시켜, 문맥 관리·실행력 유지
   • no-op(아무 동작 안 하는)이라도 프롬프트에 맥락 제공 효과

3. 서브 에이전트(Sub Agents)

   • 하위 작업별로 서브에이전트 생성·분할, 각 에이전트가 개별적으로 작업 후 결과를 통합
   • 대규모/복잡한 문제도 병렬·분업 구조로 처리

4. 파일 시스템

   • 실제 파일 작업뿐 아니라, 노트·컨텍스트 저장소로서 활용
   • 여러 에이전트·서브에이전트가 파일 시스템을 공유해 협업 및 장기적 문맥 유지

LangChain의 Deep Agents 프레임워크: deepagents

• 오픈소스 Python 패키지(pip install deepagents), 커스텀 프롬프트·툴·서브에이전트 설정 가능
  • Claude Code에서 영감 받은 시스템 프롬프트. 더 제네럴하게 수정
  • no-op ToDo 리스트 플래닝 도구(Claude Code와 같음)
  • 서브에이전트 생성 및 커스텀 지정 가능
  • LangGraph 개념을 이용한 가상 파일 시스템(에이전트 상태를 이용)
• 예제로 deep research agent 샘플을 제공하며, vertical 특화 에이전트 손쉽게 제작 가능

활용 예시와 가치

• 연구·개발, 코드 생성, 리서치, 복잡한 자동화 등 장기·복합적 AI 작업에 최적화
• 상세한 문맥 설계와 분업 구조로 깊이 있는 결과 생성 가능
• 누구나 도메인에 맞는 '딥 에이전트' 구축 가능—AI 활용의 다음 단계 제시

[GN⁺]

Hacker News 의견

• 저자임. 최근에는 claude code, manus, deep research 같은 일련의 에이전트들이 긴 시간 범위 상의 작업을 특히 잘 실행하는 현상이 인상적임. 사실상 내부적으로는 LLM이 루프를 돌면서 툴을 호출함. 그런데 아무 생각 없이 이렇게 하면 LLM이 복잡하거나 긴 작업을 제대로 해내지 못하는 문제 발생함. 그래서 다른 에이전트들은 이걸 어떻게 해내는지 궁금해짐. 공통적으로 발견한 점은 아래와 같음. 1) 플래닝 툴 사용함 2) 서브 에이전트 사용함 3) 파일 시스템처럼 컨텍스트를 오프로딩하는 구조 사용함 4) 디테일한 시스템 프롬프트 설계함(프롬프트 엔지니어링은 여전히 중요함) 각각은 기존에도 있던 방법이지만, 실제로 에이전트 개발할 때 널리 쓰는 방식은 아님. 이 조합이 오히려 중요한 인사이트라고 생각함. 피드백 환영함

• 여러 의견을 생각해보면, deep agents라는 개념도 결국 agent + tool 조합과 크게 다르지 않다는 점에 동의함. 내 기준의 핵심 포인트는 다음과 같음. 1) 기본 지식은 좋은 LLM 사용 필요 2) LLM을 제대로 가이드할 프롬프트 중요(에이전트로 만들기) 3) 별도의 판단이 없는 기능은 툴로 구현 4) agent+tool 플로우가 복잡해지면, 포커싱된 프롬프트와 적은 수의 툴을 갖춘 서브에이전트로 쪼개서 각 도메인을 분리함

  • 결국 최상위 에이전트가 무엇을 해야 할지 선정하고 어떤 에이전트가 그 작업에 적합한지 분배하는 "조정자" 모델로 발전할 것 같음. 이 구조는 재귀적으로 이어질 수 있음(예: 각 프로덕트마다 에이전트가 있고, 그 에이전트가 프론트엔드/백엔드 작업을 담당하는 에이전트로 분기). 이런 구조에서는 실제로 업무를 수행하는 에이전트가 한정된 컨텍스트와 툴만 집중하면 되고, 상위 에이전트는 서브 에이전트가 할 수 있는 일만 파악해두면 됨

• deep agents = 플래닝 추가된 에이전트 + 에이전트 툴 조합이니까 결국 기존 에이전트랑 비슷하다고 생각함. LangChain이 단순한 개념도 항상 복잡하게 포장하고 괜히 새 용어나 개념을 만들어서 홍보하는 것 같아서 아쉬움. 물론 LangSmith를 더 팔려면 어쩔 수 없겠지만

  • 예전엔 이런 컨설팅을 했었음. 완전히 똑같다 할 순 없겠지만, 본질적으로는 흔한 수법임. 평범한 걸 연극처럼 포장하고, 자기만의 용어와 분류법을 만들고, 그걸 파는 전략임. 다음 단계는 자기 개념을 SEO로 도배하는 거임. deep *과 agent 같이 인기 키워드에 얹혀가면 되는데… 이런 일을 생각하다 보면 근본적으로 기업 환경에서 영혼만 빠지는 느낌임

• 내가 기대하던 결과랑 비슷함. 이제 MCP 서버를 직접 짜는 게 별로 안 먹힌다는 게 명확해지면서, 빠르게 대세를 탈 수 있는 새 방법이 필요한 상황임. gemini나 claude code처럼 직접 에이전트 만들어보는 게 요즘 트렌드임. 진입장벽 낮고, 어느 정도 쓸모도 있고, 깊은 AI 전문지식도 필요 없고, 홍보도 쉬움. 마치 “cursor for X” 방식인데, 오히려 더 빨리 제품화할 수 있음. 이렇게 만들어지는 코딩 에이전트가 엄청 많아질 것 같지만, 아직까진 뭔가 새로운 느낌은 별로 없는 것 같음. 그래도 이렇게 빨리 시작할 수 있으면, 직관적으로 만든 claude code 클론의 가치는 곧 0에 수렴하겠다는 데에서 긍정적으로 봄

  • 간단한 openagent를 https://github.com/revskill10/openagent-cli에서 만들었음

• 이 레포의 코드를 계속 따라가면서 분석 중임 https://github.com/ghuntley/claude-code-source-code-deobfuscation 작성자가 Claude Code를 리버스 엔지니어링하고 아키텍처를 잘 설명해줌. 링크를 더 나은 레포로 변경했음

  • 이게 뭘 보여주는지 설명해줄 수 있음? 그냥 엄청 큰 readme랑 시스템 명령어들만 보이는 듯

• rust로 범용 agent cli+library 만들고 있음: https://github.com/fdietze/alors 아직 개발 초기지만, 이미 이 자체를 개발하는 데도 사용 중임. 피드백 환영함

• 내가 보기에는 Jetbrains의 Junie가 제일 먼저 엄청 퀄리티가 높은 to do list 기능을 썼었는데, 그게 가장 마음에 들었음. 유료로 바뀐 뒤로는 안 썼지만, 당시 Junie는 느리고 신중했음. Cursor는 문제 없는 파일도 계속 덮어씌웠고, Claude는 그 중간적 느낌이었음

  • Cursor는 todo list를 위한 전용 UI도 제공하고, 그걸 사용하도록 agent를 유도함(UX 자체는 좋지만, 따로 파일을 직접 볼 수는 없음). amazon의 kiro는 tasks.md에서 해야 할 일과 스펙 둘 다 관리하는 방식을 씀. 툴이 많아지니 자신에게 맞는 걸 골라서 쓰면 됨

• 제일 흥미로운 부분이 완전히 숨겨져 있음. 어떻게 파싱부터 실행까지 툴 콜을 관리하는지가 관건임

• sub agent로 컨텍스트를 분리하는 게 진짜 혁신 포인트임. 나머지는 그냥 langgraph react agent임

  • 이건 가치 있지만, 실제로 완전히 새로운 아이디어는 아님

• todo list 툴이 no-op이라는 부분에 대한 정보가 더 있는지 궁금함. 정확히 어떻게 작동하는지 알고 싶음

  • 코드에서 직접 보고 싶다면, 우리가 만든 Sketch agent는 TODO list툴을 이런 식으로 활용함: https://github.com/boldsoftware/sketch/blob/main/claudetool/todo.go agent가 이걸 쓰게 하는 건 비교적 쉬움. 대부분의 일은 UI에서 보이게 하는 데 들어감
  • 같은 질문임. 무슨 의미인지 잘 모르겠음. 그런데 명확히 Claude Code가 뛰어난 이유로 보임
  • 내 생각엔 그냥 단순한 concat 기능임. 실제로 유용한 프롬프트 기법들은 구현 자체는 대부분 간단함. 그만큼 TODO라는 단순 아이디어가 꽤 멀리 간다는 점이 더 놀라움! (진지한 환경에서 agent 프레임워크는 어렵긴 함. 예: 알맞은 조합과 세팅은 정말 힘들고, 인프라도 멀티 테넌시, 멀티스레딩, 스트리밍, 취소 등 챙길 게 많음). TODO list가 중요한 건 전적으로 동의함. louie.ai의 보안 로그 분석 대회 같은 것도 이 방법 덕에 엄청 속도가 빨라짐. CoT가 턴 몇 번만에 망가지는 걸 방지함. 재밌었던 aha moment는 nested todo (A.2.i...)를 사용하면 좋은데, LLM 입장에선 어차피 선형화되어 있어서 어렵지 않게 처리함. 우린 claude code 대신 내부적으로 이런 식의 플랜 프롬프트로 관리함: https://github.com/graphistry/louie-py/blob/main/ai/prompts/PLAN.md
  • 툴 콜이 있었던 사실만 컨텍스트에 기록됨. 실제로 todo list 데이터 자체를 다시 가져오지는 않음
  • 내 이해로는 그냥 TODO list 작성하라는 프롬프트 정도라고 보면 될 듯