DeerFlow 2.0 장기 실행 AI 에이전트 하네스 운영 체크표

2026년 5월 15일 기준 DeerFlow 2.0은 ByteDance의 오픈소스 super agent harness로, sub-agents, memory, sandboxes, skills를 묶어 수 분에서 수 시간 걸리는 작업을 처리하는 구조를 내세운다.

처음 보면 “또 하나의 AI 에이전트 프레임워크인가?” 싶다. 그런데 README와 backend 문서를 같이 보면 포인트가 조금 다르다. DeerFlow 2.0은 모델을 한 번 더 감싸는 라이브러리라기보다, 에이전트가 오래 일할 때 필요한 실행 환경을 한꺼번에 묶은 쪽에 가깝다.

이 글은 DeerFlow를 직접 설치해서 쓴 후기가 아니다. 공식 README, backend README, GeekNews 요약을 기준으로 내가 .claude/agents, .claude/skills, 로컬 하네스 운영 구조와 비교한다면 무엇부터 볼지 정리한 운영 체크표다. 설치 버튼 누르기 전에 지도부터 펴는 글이라고 보면 된다. 길 잃고 나서 지도 앱 켜면 이미 살짝 늦다.

지금 판단은 이렇다. DeerFlow 2.0은 “에이전트가 똑똑한가”보다 “에이전트가 오래 일해도 망가지지 않게 실행층을 갖췄는가”를 보는 글감이다. 그래서 TECHTAEK에서는 사용법보다 스킬, 샌드박스, 메모리, MCP, 관측, 보안 기준으로 읽는 게 더 맛있다.

DeerFlow 2.0이 하네스라고 불리는 이유

DeerFlow README는 2026년 2월 28일 version 2 출시 뒤 GitHub Trending 1위를 기록했다고 설명한다. 2026년 5월 15일 GitHub 화면 기준으로는 67.7k stars가 보였다. 숫자 자체보다 중요한 건 관심의 방향이다. 개발자들이 단순 챗봇이 아니라 장기 실행 에이전트의 실행 기반을 찾고 있다는 신호로 읽을 수 있다.

DeerFlow 2.0은 v1 Deep Research 프레임워크와 코드를 공유하지 않는 ground-up rewrite라고 밝힌다. 이 문장이 중요하다. 기존 리서치 도구를 조금 고친 수준이 아니라, 리서치, 코딩, 콘텐츠 생성, 슬라이드, 웹 페이지 같은 복합 작업을 처리하는 실행체로 다시 잡았다는 뜻이기 때문이다.

README 기준 DeerFlow 2.0은 LangGraph와 LangChain 위에 구축되어 있고, filesystem, memory, skills, sandbox-aware execution, sub-agent planning과 spawning을 기본 구성으로 둔다. backend README도 Gateway API가 models, MCP, skills, memory, uploads, artifacts, threads, runs, streaming을 다룬다고 설명한다. 이 정도면 “프롬프트 묶음”보다 “작업 런타임”이라고 부르는 게 더 자연스럽다.

내 로컬 자동화 구조와 비교하면 눈에 들어오는 부분도 여기다. .claude/skills가 작업법을 담고, .claude/agents가 역할을 나누고, 하네스 코드가 health check와 상태 복구를 담당한다면 DeerFlow는 그 조각들을 한 제품형 런타임 안에서 묶으려는 시도에 가깝다. 바로 갈아탈 대상이라기보다, 내 구조가 빠뜨린 운영 요소를 점검하는 거울로 쓸 수 있다.

운영 체크표: 스킬, 샌드박스, 메모리, 관측

DeerFlow에서 제일 먼저 볼 것은 스킬 시스템이다. README는 Agent Skill을 Markdown 파일로 된 구조화된 capability module로 설명하고, research, report generation, slide creation, web page, image/video generation 같은 built-in skills와 custom skill을 언급한다. TECHTAEK 관점에서는 이게 Claude Code나 Codex의 skill 운영과 얼마나 호환되는지, 그리고 필요한 순간에만 컨텍스트에 올리는 방식이 실제로 토큰 절약에 도움이 되는지가 포인트다.

두 번째는 샌드박스다. DeerFlow는 작업별 execution environment와 filesystem view를 제공하고, backend README는 LocalSandboxProvider와 AioSandboxProvider를 나눈다. 특히 LocalSandboxProvider에서는 bash가 기본 비활성화되고, 격리된 shell access는 AioSandboxProvider 쪽을 쓰라는 설명이 나온다. AI 에이전트가 파일을 읽고 쓰고 명령을 실행한다면, 이 차이는 기능 문제가 아니라 사고 표면 문제다.

세 번째는 메모리다. backend README는 memory system이 conversation에서 user context, facts, preferences를 추출하고 structured storage에 저장하며, top facts와 context를 prompt에 주입한다고 설명한다. 이건 편하지만 동시에 관리 대상이다. 오래 기억하는 에이전트는 편한 비서가 될 수도 있고, 오래된 오해를 계속 끌고 다니는 자동화가 될 수도 있다.

네 번째는 관측이다. DeerFlow는 LangSmith와 Langfuse tracing을 지원한다. backend README 기준 LangSmith는 LLM calls, agent runs, tool executions, middleware processing을 trace로 볼 수 있고, Langfuse도 LangChain-compatible runs 관측을 지원한다. 장기 실행 에이전트에서 trace는 장식이 아니다. 실패했을 때 “왜 그랬는지”를 다시 볼 수 없으면, 자동화는 빨랐던 사고가 된다.

체크 축	DeerFlow 2.0에서 볼 부분	내 로컬 운영에 가져올 질문
Skills	Markdown Agent Skill, built-in/custom skills	내 스킬은 필요한 순간에만 로드되는가
Sandbox	LocalSandboxProvider, AioSandboxProvider, filesystem	bash와 file-write 권한을 어디까지 열 것인가
Memory	user context, facts, preferences, prompt injection	오래된 기억을 어떻게 갱신하고 폐기할 것인가
Sub-agents	lead agent가 scoped context로 병렬 실행	병렬 작업이 실제로 독립적인가
MCP	stdio/SSE/HTTP transports와 OAuth token flow	토큰 저장과 승인 경계를 어디에 둘 것인가
Tracing	LangSmith, Langfuse	실패 원인을 재현할 로그가 남는가

Claude Code나 Codex 워크플로와 비교하면

Claude Code와 Codex를 이미 쓰고 있다면 DeerFlow를 “대체재”로만 보면 헷갈린다. Claude Code는 개발자가 repo 안에서 코딩 작업을 밀고 가는 경험이 강하고, Codex는 작업 단위로 구현과 검증을 맡기는 흐름에 잘 맞는다. DeerFlow는 그보다 넓게, 메시지 채널, 스킬, 메모리, 샌드박스, MCP, 관측을 묶어 장기 실행 런타임을 만들려는 쪽으로 보인다.

예를 들어 Claude Code에서 claude-to-deerflow skill을 설치하면, 실행 중인 DeerFlow instance에 터미널에서 research task를 보내고 상태를 확인할 수 있다고 README가 설명한다. default URL도 <http://localhost:2026으로> 안내한다. 이건 흥미롭다. Claude Code가 작업 지시 콘솔이 되고, DeerFlow가 오래 도는 작업 실행층이 되는 그림이기 때문이다.

다만 이 구조는 멋있어 보이는 만큼 권한이 겹친다. Claude Code 자체도 파일을 읽고 쓰고 명령을 실행할 수 있는데, DeerFlow도 샌드박스와 MCP와 파일 작업을 가진다. 둘을 같이 쓰면 편해지는 지점도 있지만, 누가 어떤 권한으로 어떤 파일을 만졌는지 더 흐려질 수도 있다.

그래서 내가 운영한다면 바로 메인 vault에 붙이지 않는다. 빈 repo에서 DeerFlow를 띄우고, Claude Code skill 연동, MCP config, memory 저장 파일, sandbox provider, trace provider를 하나씩 확인한다. 특히 token이 .env에 어떻게 들어가는지, OAuth flow가 어디에 저장되는지, upload와 output이 어떤 경로로 남는지부터 본다. 자동화는 먼저 설거지 동선을 봐야 한다. 주방이 커지면 접시도 같이 늘어난다.

도입 전에 막히는 지점

첫 번째 막힘은 설치가 아니라 운영 범위다. README의 make setup wizard는 provider, web search, sandbox mode, bash access, file-write tools 설정을 약 2분 안에 만든다고 설명한다. 빠른 시작은 좋지만, 빠르게 켜지는 도구일수록 “무엇을 허용했는지”를 더 천천히 봐야 한다.

두 번째 막힘은 sub-agent 기대치다. backend README는 subagent delegation을 설명하면서 built-in agents와 concurrent execution을 다루고, concurrency는 turn당 최대 3개, timeout은 15분으로 적는다. 이 숫자는 무한한 에이전트 군단이 아니라, 제한된 병렬 실행 구조라는 뜻이다. “여러 개가 돈다”와 “아무렇게나 던져도 된다”는 완전히 다른 말이다.

세 번째 막힘은 보안이다. README의 security recommendations는 local trusted network 배포를 강하게 권하고, cross-device나 cross-network 배포가 필요하면 IP allowlist, authentication gateway, network isolation 같은 조치를 제안한다. 이건 선택 팁이 아니라 경고에 가깝다. command execution과 file read/write가 가능한 agent endpoint를 외부에 열면, 편의보다 위험이 더 빨리 커질 수 있다.

네 번째 막힘은 메모리 품질관리다. 장기 메모리는 멋있지만, 자동 추출된 preference와 fact가 틀리면 agent 행동이 계속 빗나갈 수 있다. 내 vault 기준으로도 hot/warm/cold memory를 나누는 이유는 전부 같은 무게로 기억하면 운영이 지저분해지기 때문이다. DeerFlow를 본다면 memory reload, confidence, 폐기 기준, prompt injection 범위를 같이 확인해야 한다.

실수 TOP 5

실수	왜 위험한가	먼저 할 일
GitHub stars만 보고 바로 설치	인기도와 운영 적합성은 다르다	별도 테스트 repo에서만 실행
Local sandbox와 Docker sandbox 차이를 안 봄	host file/bash 권한 경계가 달라질 수 있다	provider별 권한표 작성
MCP OAuth를 대충 붙임	token 저장과 scope가 장기 리스크가 된다	`.env`, config, refresh flow 확인
sub-agent를 많이 띄우면 무조건 빨라진다고 봄	중복 조사와 충돌이 늘 수 있다	독립 작업만 병렬화
tracing을 나중에 켜려 함	실패 뒤에는 원인을 재구성하기 어렵다	첫 실험부터 LangSmith/Langfuse 중 하나 연결

이 중에서 제일 흔한 실수는 “강력한 도구니까 내 작업도 강해지겠지”라는 기대다. 실제로는 강력한 도구일수록 권한, 상태, 로그, 복구 기준이 더 중요해진다. 작은 자동화는 실패해도 귀찮은 정도지만, 장기 실행 에이전트는 실패도 오래 실행할 수 있다.

내 기준의 첫 실험은 작게 잡는 게 맞다. “자료 3개를 읽고 비교표 1개와 Markdown 보고서 1개를 outputs에 남긴다” 정도가 좋다. 이 작업 하나로 skills loading, file output, sub-agent 분해, memory 기록, trace, sandbox 권한을 대부분 확인할 수 있다. 처음부터 웹앱 생성, 슬라이드, 코드 수정, Slack 알림까지 다 붙이면 어디서 망했는지 찾기 어렵다.

언제 써볼 만하고, 언제 안 써도 되나

DeerFlow는 리서치, 코드 작성, 문서 생성, 슬라이드나 웹 페이지 같은 산출물을 여러 단계로 나눠 처리하고 싶은 사람에게 검토 가치가 있다. 특히 작업이 한 번의 프롬프트로 끝나지 않고, 중간 파일과 상태를 남겨야 하며, 여러 sub-agent가 서로 다른 각도를 조사해야 한다면 하네스 구조가 의미를 가진다.

반대로 단순한 코드 수정, 짧은 요약, 일회성 블로그 초안 정도라면 과할 수 있다. Claude Code, Codex, 작은 스크립트, cron, Obsidian direct write로 충분한 작업도 많다. 플랫폼을 붙이는 순간 설치, 업데이트, 보안, 로그, 비용, 권한이라는 새 숙제가 생긴다.

팀이나 개인 운영체계에 붙인다면 기준은 하나다. “이 도구가 내 일을 대신해주나”가 아니라 “실패했을 때 내가 복구할 수 있는 구조를 제공하나”를 봐야 한다. DeerFlow 2.0의 진짜 흥미는 똑똑한 답변보다, 오래 걸리는 일을 파일시스템, 샌드박스, 메모리, trace 안에 넣으려는 설계에 있다.

FAQ

DeerFlow 2.0은 Claude Code 대체제인가?

대체제라기보다 다른 층에 가깝다. Claude Code는 개발자가 repo 안에서 코딩 작업을 진행하는 경험이 강하고, DeerFlow는 sub-agents, memory, sandbox, skills, message gateway를 묶은 장기 실행 agent harness를 지향한다. 둘을 연결하는 claude-to-deerflow skill도 README에 나온다.

DeerFlow 2.0을 바로 메인 작업공간에 설치해도 되나?

추천하기 어렵다. 파일 읽기/쓰기, bash, MCP, memory, OAuth token, tracing이 모두 엮일 수 있어서 먼저 빈 테스트 repo에서 생성 파일과 권한을 확인하는 편이 안전하다. 특히 sandbox provider와 .env 저장 방식을 먼저 봐야 한다.

GitHub Trending 1위와 star 수는 얼마나 중요하게 봐야 하나?

관심 신호로는 볼 만하지만 도입 근거로는 부족하다. 2026년 5월 15일 확인 기준 GitHub 페이지에는 67.7k stars가 보였지만, star는 운영 안정성이나 보안 적합성을 보장하지 않는다. 실제 판단은 설치 범위, 권한, trace, memory 관리 기준에서 해야 한다.

DeerFlow의 스킬 시스템은 Claude Code 스킬과 같은가?

둘 다 Markdown 기반 workflow module이라는 점에서 비교할 만하다. 다만 실제 경로 구조, 로딩 방식, sandbox 안에서의 resource 접근, custom skill 배포 방식은 다를 수 있다. TECHTAEK 글감으로는 이 호환성 검증이 꽤 좋은 후속 실험이 된다.

LangSmith나 Langfuse tracing은 꼭 켜야 하나?

첫 실험부터 하나는 켜보는 편이 좋다. 장기 실행 agent에서 trace가 없으면 실패 원인과 tool call 흐름을 나중에 되짚기 어렵다. 다만 tracing provider 자체도 credentials가 필요하므로 .env와 배포 환경에서 secret 관리가 같이 따라와야 한다.

DeerFlow는 개인 자동화에도 맞을까?

가능은 하지만 모든 개인 자동화에 맞지는 않는다. 여러 단계 리서치, 파일 산출물, sub-agent 분해, 장기 메모리, 메시지 채널이 필요한 작업이면 검토 가치가 있다. 단순 URL 요약이나 짧은 코드 수정이면 기존 스크립트나 Claude Code/Codex 단일 작업이 더 가볍다.

DeerFlow 2.0은 왜 장기 실행 AI 에이전트 하네스라고 부를까 2026 – 스킬 샌드박스 메모리 체크표