리서치 답변만 찾는다면 디어플로우(DeerFlow)는 구성이 과할 수 있지만, 모델과 실행 권한을 직접 정해 긴 작업을 맡길 환경이 필요하다면 살펴볼 만합니다. ByteDance의 오픈소스 프로젝트는 조사 보고서를 만드는 1.x에서 하위 에이전트·기억·샌드박스를 묶는 실행 환경으로 확장됐습니다. 2026년 9월 30일 기준 최신 정식 릴리스는 9월 24일의 v2.1.0입니다. (공식 저장소 · 릴리스 목록)

관심의 크기보다 눈여겨볼 부분은 맡긴 일이 실제로 끝났는지 확인하는 방식입니다. 저장소의 평가 토론에는 긴 탐색 중 실행 한도를 소진한 사례가 있고, 2.1은 하위 에이전트의 보고를 실행 기록·산출물과 대조하는 기능을 내세웁니다. 보고서 한 장의 유창함과 여러 단계 작업의 완료를 나눠 판단할 근거가 여기에 있습니다. (평가 RFC #2820 · 2.1 릴리스 설명)

한눈에 보기

궁금한 점 이번 버전의 핵심
어떤 도구인가요? 모델이 도구·파일·하위 에이전트를 이용해 작업을 이어가게 하는 오픈소스 SuperAgent 하네스입니다.
무엇이 달라졌나요? 1.x의 Deep Research에서 전면 재작성한 2.x로 이동했고, 2.1은 실행 검증·작업 분담·운영 관리에 초점을 맞췄습니다.
어떤 일에 맞나요? 자료 조사 뒤 비교표·보고서·코드 등 여러 산출물로 이어지는 작업을 검토할 수 있습니다.
성능은 어떤가요? 내부 평가 제안에는 실패 원인과 평가 설계가 담겼습니다. 현재 버전의 일반 성능을 입증하는 독립 점수는 확인하지 못했습니다.
무료인가요? 코드는 MIT 라이선스이며 모델 호출·검색 서비스·실행 인프라 비용을 따로 계산합니다.
어떻게 시작하나요? 모델 설정을 준비하고 Docker(Compose v2.24 이상) 또는 로컬 개발 경로를 고릅니다. Windows는 Git Bash에서 실행하고, 로컬 평가는 4 vCPU·8GB RAM부터 시작합니다.
기본 한도는요? 설정 문서의 Gateway 실행 재귀 한도는 기본 100, 상한은 기본 1,000입니다. 채널·클라이언트 경로는 구분합니다.
한국에서 쓸 수 있나요? 직접 배포하는 소프트웨어이므로 선택한 모델·검색 제공자의 한국 이용 조건을 확인합니다.
무엇을 관리하나요? 믿을 수 있는 로컬 환경을 전제로 만든 도구라 인증 없이 외부에 열지 않습니다. MCP 등록 권한은 호스트 명령 실행 권한처럼 다루고, 호출 예산과 산출물도 함께 관리합니다.

기능과 기본값은 README, 설정 문서, 릴리스 설명을 따릅니다. 평가 RFC는 저장소 참여자가 공개한 실행 경험과 설계 제안이며, 아래 활용 흐름은 기능을 설명하기 위한 예시입니다. 직접 설치·실행·모델 API 실험이나 유료 계정 생성은 하지 않았습니다.

2025년의 조사 도구와 지금의 2.1은 어떻게 이어지나요?

DeerFlow의 출발점은 Deep Research, 즉 질문을 조사 계획으로 나누고 자료를 찾아 보고서를 만드는 도구였습니다. 2025년 5월 10일 IT之家 보도는 ByteDance GitHub 조직에서 프로젝트가 공개됐다고 전하며, 조사 결과의 편집과 보고서 기반 팟캐스트·슬라이드 생성도 소개합니다. 당시에도 여러 에이전트를 쓰는 구조였으므로, 변화의 핵심을 단순히 “에이전트가 여러 개가 됐다”로 잡으면 이전 기능을 놓칩니다. (초기 공개 보도)

2.0은 기존 연구 도구에 실행 메뉴를 덧붙인 업데이트보다 큰 변화입니다. README와 v2.0.0 설명은 1.x 코드를 공유하지 않는 전면 재작성이라고 밝힙니다. 개발의 중심도 2.0으로 옮겨졌습니다. 예전 설치 후기나 설정 예시는 어느 버전의 이야기인지부터 구분하는 것이 좋습니다. 1.x에서 보고서가 잘 나왔다는 경험만으로 2.1의 파일·권한·메모리 동작까지 판단하면 확인 범위가 넓어집니다. (README의 버전 안내 · v2.0.0)

시기 확인되는 사건 독자가 구분할 점
2025년 5월 Deep Research 프로젝트 공개를 보도했습니다. 1.x의 출발입니다.
2026년 2월 28일 README는 버전 2 공개 뒤 GitHub Trending 1위를 기록했다고 소개합니다. 개발·공개 단계의 기록입니다.
2026년 6월 25일 v2.0.0 정식 릴리스가 올라왔습니다. 2월 기록과 별도 날짜입니다.
2026년 9월 24일 v2.1.0 정식 릴리스가 올라왔습니다. 현재 검토할 버전의 사건일입니다.

이 글의 사건일은 최신 정식 릴리스인 9월 24일, 발행일은 9월 30일로 구분했습니다. Trending 순위는 프로젝트에 관심이 모였다는 기록으로 읽습니다. 코드를 고쳤는지, 보고서의 근거가 정확한지, 특정 모델로 작업을 끝냈는지는 별도 실행 결과로 살펴봅니다. (릴리스 날짜 · Trending 언급)

하네스와 오케스트레이션은 무슨 일을 하나요?

하네스(harness)는 모델이 실제 작업을 하도록 감싸는 실행 환경입니다. 모델이 “자료를 찾아 비교하겠습니다”라고 답하는 데서 멈추지 않고 검색 도구를 호출하고, 파일을 읽고 쓰며, 다음 단계에 상태를 이어가도록 연결합니다. DeerFlow가 소개하는 하네스에는 하위 에이전트, 지속 메모리, 샌드박스 실행, 확장 가능한 스킬·도구가 들어갑니다. 모델은 판단과 지시를 만들고 하네스는 그 지시가 실행되는 경로를 제공합니다. (2.0 구조 설명)

오케스트레이션(orchestration)은 그 안에서 일을 나누고 결과를 모으는 흐름입니다. 주 에이전트가 질문을 하위 작업으로 쪼개고, 하위 에이전트에게 맡기고, 돌아온 파일과 근거를 확인해 최종 답변으로 묶습니다. 모두 같은 모델을 쓰더라도 검색과 코드 실행의 역할·권한을 나누는 의미가 있습니다. 2.0부터 에이전트별로 모델과 생성 설정을 따로 줄 수 있으므로, 예를 들어 검색 정리는 저렴한 모델에, 최종 보고서는 성능이 높은 모델에 맡기는 구성을 검토할 수 있습니다. (2.0의 에이전트별 모델 설정)

예를 들어 “세 제품의 공식 문서를 비교해 근거 링크가 있는 보고서와 발표 초안을 만들어 주세요”라는 요청을 생각해 볼 수 있습니다. 주 에이전트는 먼저 비교 항목과 완료 조건을 잡습니다. 조사 역할은 공식 문서의 해당 대목을 모으고, 파일 작업 역할은 비교표를 정리하고, 코드 실행이 필요한 계산은 샌드박스에서 처리합니다. 마지막에는 보고서 파일과 슬라이드 초안을 모아 누락된 항목과 근거 링크를 확인합니다. 이는 DeerFlow의 기능을 연결한 설명 예시이며 직접 실행한 결과와 구분합니다. (하네스 구성 · 작업 위임·산출물 확인)

이때 완료 조건을 “좋은 보고서”로만 적는 것보다 “세 제품이 모두 들어간 표 파일, 주장별 공식 링크, 발표 초안 파일”처럼 나누면 확인할 지점이 생깁니다. 2.1의 위임 검증은 파일 존재나 기록된 테스트 명령의 종료 상태처럼 기계적으로 판단할 수 있는 조건을 부모 쪽에서 확인합니다. 해석이 필요한 조건은 UNVERIFIED로 표시합니다. 따라서 파일을 만들었다는 확인과 내용이 설득력 있다는 평가는 독자가 나눠 볼 수 있습니다. (2.1 acceptance_criteria)

1.x에서 2.x로 옮기면 무엇이 늘어나나요?

쉽게 말하면, 조사 결과를 답변으로 받는 데서 작업 공간과 실행 상태를 함께 다루는 쪽으로 범위가 넓어집니다. 2.0의 중심에는 지속 메모리, 샌드박스, 스킬·도구와 하위 에이전트가 있고, 2.1은 프로젝트 단위 문서 관리와 대화 분기까지 보강했습니다. 초기 버전에도 보고서와 콘텐츠 생성은 있었지만, 현재 버전은 그것들을 긴 작업의 실행·검증·운영과 연결합니다. (초기 기능 보도 · 2.0 · 2.1)

파일 작업에서는 최종 답변뿐 아니라 작업 공간의 산출물을 봅니다. 2.1은 CSV·TSV를 표로 미리 보고, 실행 파일들을 ZIP으로 내려받으며, 프로젝트의 문서 선반과 작업 파일을 연결하는 기능을 소개합니다. 표를 검토하는 사람에게는 파일의 위치와 형식이 중요하고, 개발자에게는 수정 파일과 테스트 결과가 중요합니다. 두 경우 모두 “완료했습니다”라는 한 문장보다 실제 파일을 열어 확인하는 경로가 가까워집니다. (2.1 Workspace)

기억은 한 대화의 이전 문장과 지속적으로 보관하는 정보를 구분해 봅니다. 2.1은 메모리 백엔드를 바꿀 수 있도록 하고 OpenViking·mem0·Honcho 연결을 소개합니다. 긴 대화에서는 컨텍스트, 즉 모델이 한 번에 참고하는 정보가 압축되면서 중요한 조건이 빠질 수 있습니다. 릴리스는 요약 뒤에도 유지되는 컨텍스트, 선택적인 작업 메모, 이전 대화 참조를 보강했다고 설명합니다. 장기 프로젝트라면 어떤 정보를 저장하고 수정하며 다음 작업에서 다시 읽는지도 설정 범위에 들어갑니다. (2.1 메모리·런타임)

스킬은 특정 일을 수행하는 절차와 자료를 묶는 방식이며, MCP는 외부 도구와 에이전트를 연결하는 공통 규약입니다. DeerFlow의 설정 문서는 MCP 서버와 스킬 활성 상태를 extensions_config.json에서 따로 관리한다고 설명합니다. 메신저 연결은 질문과 진행 상황을 주고받는 입구를 늘립니다. 2.0은 사용자 소유 Slack·Telegram·Discord·Feishu/Lark·DingTalk·WeChat·WeCom 연결을 소개했고, 2.1은 채널 처리와 MCP 작업의 재시작 복구를 보강했습니다. 도구 선택, 메시지 입구, 파일 접근을 각각 설정하는 구조입니다. (설정 문서 · 2.0 채널 · 2.1 MCP·채널)

2.1은 맡긴 일이 끝났는지 어떻게 확인하나요?

핵심은 하위 에이전트의 말과 실행 흔적을 연결하는 것입니다. 2.1 릴리스는 각 도구 호출에 런타임이 기록한 변조 탐지용 실행 증빙을 붙이고, 하위 에이전트의 보고서가 증빙과 산출물 식별자를 인용하도록 설명합니다. 주 에이전트는 그것을 대조합니다. “테스트를 돌렸습니다”라는 보고에 실제 테스트 명령의 기록이 있는지, “보고서를 만들었습니다”라는 답에 열 수 있는 파일이 있는지를 확인하는 방향입니다. (2.1 Verifiable agent execution)

이는 근거를 추적할 수 있게 만드는 변화입니다. 테스트 종료 상태가 성공이라도 테스트가 모든 문제를 덮었는지, 파일이 있어도 출처를 올바르게 읽었는지는 별도 검토에 남습니다. 보고서에서 수치를 옮겨 썼다면 원문과 단위를 맞춰 보고, 코드 변경이라면 요구사항에 맞는 동작을 확인하는 식입니다. 실제 산출물 검토가 필요한 지점을 실행 증빙으로 좁혀 가는 데 의미가 있습니다. (릴리스의 검증 가능한 조건과 UNVERIFIED 처리)

작업 분담 자체에도 관리 기능이 붙습니다. 시스템이 유지하는 위임 장부는 중복 위임을 줄이고, 총 작업 수 제한은 하위 에이전트가 계속 늘어나는 흐름을 묶습니다. 선택적으로 쓰는 batch_task는 서로 독립된 항목을 지속 저장되는 배치 작업으로 처리하며 재시도·일시정지·재개·취소를 다룹니다. 다수의 문서를 같은 기준으로 정리한다면 유용한 구조이지만, 동시에 실행하는 항목 수와 모델 호출 예산을 함께 잡는 것이 좋습니다. (2.1 Subagents at scale)

긴 작업의 상태 저장도 개선했습니다. 릴리스는 대화 체크포인트 저장을 장기 실행에서 거의 선형으로 줄이는 구조와 스트리밍 전달량 개선을 소개합니다. 이는 런타임 운영의 개선으로 읽습니다. 특정 질문의 답이 더 정확해졌다는 성능 점수와는 따로 봅니다. 체크포인트는 중간 상태를 저장해 이어가기 위한 장치이며, 실행 기록을 오래 보관할 때 저장 공간과 관리 비용에도 영향을 줍니다. (2.1 Performance)

설치하려면 무엇을 먼저 정하나요?

먼저 모델 공급자, 웹 검색 방식, 실행 권한을 정합니다. README의 make setup은 모델과 선택적인 검색 제공자, 샌드박스·bash 접근·파일 쓰기 설정을 고르는 초기 마법사로 소개됩니다. 수동 설정 경로로는 make config와 config.yaml 예시를 제공합니다. 설치 뒤의 문제 진단에는 make doctor를 안내합니다. 검색을 뒤로 미루는 선택지도 있지만, 공식 문서를 찾아 읽는 리서치를 맡기려면 검색·가져오기 경로까지 연결해 살펴봅니다. (README의 설정 안내)

공식 Install.md는 Docker가 있고 데몬에 접근할 수 있으면 Docker 경로를 우선합니다. make docker-init은 실행 전 준비, 다음 make docker-start가 서비스 시작 단계입니다. Docker 준비 명령이 끝났다는 결과와 실제로 서버·모델 연결이 작동한다는 결과는 구분됩니다. Docker를 쓰지 않는 로컬 경로는 make check로 전제 도구를 확인하고 make install로 의존성을 설치한 뒤 make dev로 시작하도록 안내합니다. (공식 설치 지침)

로컬 경로에서 확인하는 도구에는 Node·pnpm·uv·nginx가 나옵니다. 단순히 Python 패키지 하나를 추가하는 형태보다 준비할 것이 많습니다. Docker 경로는 Docker Compose v2.24 이상이 필요하고, 그보다 오래된 Compose는 개발용 설정 파일의 선택적 env_file 문법을 읽지 못한다고 README가 안내합니다. 웹 화면, Gateway, 모델 호출, 샌드박스가 각각 연결되는 구조이므로 실행 방식에 따라 확인할 지점도 달라집니다. (Install.md의 로컬 전제 조건 · README)

Windows 사용자는 셸부터 정합니다. README는 로컬 개발 실행을 Git Bash에서 하라고 안내합니다. 서비스 스크립트가 bash 기반이라 기본 cmd와 PowerShell은 지원하지 않고, 일부 스크립트가 Git for Windows의 cygpath 같은 유틸리티에 의존해 WSL에서도 작동을 보장하지 않습니다. 오래 켜 두는 서버라면 Linux와 Docker 조합이 무난한 선택입니다. 필요한 자원은 README의 표를 기준으로 잡습니다. (README의 Windows·자원 안내)

용도 시작 기준 권장
로컬 평가 4 vCPU, 8GB RAM, SSD 여유 20GB 8 vCPU, 16GB RAM
오래 켜 두는 서버 8 vCPU, 16GB RAM, SSD 40GB 16 vCPU, 32GB RAM

이 숫자는 DeerFlow 자체에 필요한 자원입니다. 같은 컴퓨터에서 로컬 LLM까지 돌린다면 그 모델에 필요한 GPU·메모리를 따로 잡아야 한다고 README가 밝힙니다. 하위 에이전트를 여러 개 동시에 돌리면 자원 요구가 빠르게 커진다는 업계 해설도 있습니다. (README · VentureBeat 해설)

기존 사용자는 버전만 올리기보다 설정 변화도 확인합니다. 설정 문서는 config_version이 오래되면 경고하고 make config-upgrade로 기존 값을 보존하며 새 필드를 병합하고 백업을 만든다고 안내합니다. 2.1에서는 메모리 설정의 위치와 저장 경로 의미가 달라지고, 관리되는 스킬 경로와 샌드박스 수 제한도 바뀌었습니다. 호스트 스킬 마운트나 별도 메모리 저장 코드를 쓰던 구성은 릴리스의 Breaking changes를 먼저 읽는 것이 좋습니다. (설정 버전 안내 · 2.1 호환성 변경)

어떤 모델을 붙이고 비용은 어떻게 계산하나요?

DeerFlow 자체를 새 언어 모델로 보면 비용을 이해하기 어렵습니다. 설정 문서의 모델 목록에는 OpenAI·Anthropic·DeepSeek·Xiaomi MiMo, Claude Code OAuth·Codex CLI와 LangChain 호환 공급자가 나옵니다. OpenAI 호환 연결은 base_url과 모델 ID 등을 지정하는 예시도 제공합니다. 어떤 모델에 어떤 접속 경로로 요청을 보내는지가 사용 조건과 청구 단위를 결정합니다. 코드의 라이선스와 모델 공급자의 계정·요금 조건은 각각 살펴봅니다. (모델·공급자 설정)

MIT 라이선스는 소프트웨어를 사용·수정·배포하는 허가를 제공합니다. 재사용 시 저작권·허가 고지 유지 조건이 있고, 코드에는 보증이 붙지 않습니다. 모델 API 토큰이나 외부 검색 요청까지 프로젝트가 일괄 제공하는 구조로 읽으면 비용이 어긋납니다. 웹 검색·페이지 가져오기도 제공자를 골라 붙입니다. 설정 문서 기준으로 API 키 없이 쓸 수 있는 것은 DuckDuckGo이고, Tavily·Brave·Serply·Exa·InfoQuest·Tencent Cloud WSA·Firecrawl·Jina AI 등은 각 제공자의 API 키가 필요합니다. README는 InfoQuest의 무료 온라인 체험도 소개합니다. 무료 체험 조건과 실제 운영에서 쓰는 제공자별 한도·요금은 나눠 확인합니다. 이번 글을 쓰면서 유료 계정을 만들거나 모델·검색 API를 호출해 보지는 않았으므로, 실제 단가는 선택한 공급자의 현재 요금표에서 봅니다. (MIT 원문 · 검색 도구 설정 · InfoQuest 안내)

비용 항목 계산할 사용량 긴 작업에서 보는 지점
모델 호출 모델별 입력·출력 토큰과 적용 단가 주 에이전트·하위 에이전트·보조 모델의 호출을 합칩니다.
검색·페이지 가져오기 검색 요청·크롤링 요청·제공자 요금 같은 자료를 재조회하거나 실패 후 다시 가져오는 양을 봅니다.
실행 환경 서버·샌드박스·저장 공간 사용량 작업 수, 파일 보관 기간과 외부 샌드박스 사용을 나눕니다.
로컬 모델 환경 장비·GPU·전력 등 사용자의 환경 원격 API 비용과 자체 실행 비용을 각각 계산합니다.

예산을 세울 때는 완성된 보고서 하나에 들어간 전체 사용량을 봅니다. 입력·출력 단가를 알고 있다면 각 모델의 토큰 사용량에 단가를 곱해 더하고, 검색·실행 비용을 더하는 방식입니다. 하위 에이전트가 동시에 여러 개 실행되거나 결과를 고치느라 재시도하면 호출량이 달라집니다. 2.0은 실제 모델별 토큰 사용량 추적을, 2.1은 주·하위 에이전트가 함께 쓰는 실행별 토큰 예산을 소개합니다. 날짜별 가격은 선택한 공급자의 요금표에서 확인하고, 먼저 사용량을 기록할 단위를 정하면 비교하기 수월합니다. (2.0 사용량 추적 · 2.1 토큰 예산)

호출 한도와 과금 상한도 따로 봅니다. 설정 문서의 선택적 request_admission은 공급자 계정의 분당 요청을 일정 간격으로 보내도록 조절하며 기본은 꺼져 있습니다. 예시의 60 RPM은 요청을 최소 1초 간격으로 보내는 설정입니다. 이 조절은 프로세스 안에서 작동하므로 여러 서버·워커가 같은 계정을 쓰면 각자의 허용량을 나눕니다. 토큰 한도와 다른 앱의 사용량, 결제 오류는 별도로 영향을 줍니다. (요청 속도 설정)

샌드박스가 있으면 권한 관리는 어떻게 달라지나요?

샌드박스는 코드와 파일 작업의 실행 공간을 구분하는 장치입니다. 2.1은 E2B·BoxLite·Tenki·OpenSandbox 제공자를 추가하고, 로컬 Docker 샌드박스의 외부 네트워크를 격리하거나 도메인 허용 목록으로 제한하는 선택지를 소개합니다. 필요한 사이트만 읽는 조사라면 접근할 외부 도메인과 파일 경로를 좁혀 구성할 수 있습니다. 선택한 제공자·마운트·네트워크 설정에 따라 경계가 달라지므로 그 구성을 함께 봅니다. (2.1 샌드박스 설명)

README는 이 점을 분명히 경고합니다. DeerFlow는 코드를 실행하고 파일에 접근하도록 설계된 만큼 권한이 높고, 믿을 수 있는 로컬 개발·연구 환경을 전제로 만들어졌습니다. 인증과 네트워크 격리 없이 공용 인터넷이나 신뢰할 수 없는 네트워크에 열어 두지 말고, 여러 사람이 쓰는 컴퓨터라면 인증과 IP 허용 목록·리버스 프록시로 접근을 제한하라고 안내합니다. 설정 문서는 /var/run/docker.sock을 컨테이너에 마운트하면 그 컨테이너가 호스트를 root에 준하는 수준으로 제어하게 된다고도 적습니다. 샌드박스라는 이름만 보고 위험이 없다고 여기면 안 되는 이유입니다. (README 보안 안내 · 설정 문서의 Docker 소켓 경고)

서버 공개 범위도 중요합니다. 2.1의 Docker Compose는 기본 공개 포트를 127.0.0.1에 연결해 로컬 신뢰 환경과 맞춥니다. BIND_HOST를 바꿔 다른 인터페이스에 노출할 수 있고, 같은 릴리스는 OIDC·SSO와 역할 기반 접근 제어(RBAC), 범위가 제한된 개인 접근 토큰을 소개합니다. 여러 사람이 쓰거나 외부 접속을 받는다면 누가 모델·도구·샌드박스를 이용하는지 정하는 설정까지 검토 범위에 들어갑니다. (2.1 Docker·인증·권한)

MCP·확장 기능은 접근 범위를 넓히는 연결입니다. README는 웹 화면에서 MCP 서버를 추가하는 일이 그 서버에 호스트 명령 실행 권한을 주는 것과 같다고 설명합니다. 그래서 MCP를 등록할 수 있는 관리자 계정은 서버에 직접 명령을 실행할 수 있는 계정만큼 좁게 나눠 줍니다. 특히 2.1의 외부 Python 확장은 미들웨어·Gateway 서비스·HTTP 라우터를 추가할 수 있습니다. 신뢰할 확장과 자격정보를 고르고, 운영자가 넣은 지시와 문서에서 읽은 내용을 구분해 다루는 것이 좋습니다. 설정 문서는 프롬프트에 운영 지시를 덧붙여도 도구 권한과 실행 한도는 별도로 유지된다고 설명합니다. (2.1 Extensions · 설정 문서의 지시·권한 경계)

긴 작업에는 멈추는 조건도 있습니다. Gateway의 recursion_limit은 LangGraph 실행 단계의 예산이며 기본 100입니다. 요청별 값이 우선하고 기본 상한 max_recursion_limit은 1,000입니다. 이를 단순한 대화 횟수나 모델 성능 점수로 읽기보다 실행 흐름의 한도로 봅니다. 작업이 오래 걸릴 때는 한도와 실제 진행 상태를 함께 확인하고, IM 채널·내장 클라이언트는 각 경로의 기본값을 대조합니다. (재귀 한도 설정)

공개 평가에서 어느 정도까지 확인됐나요?

2026년 5월 9일의 RFC #2820은 DeerFlow 하네스로 GAIA와 SWE-bench를 실행했을 때 같은 과제의 직접 모델 호출보다 낮은 결과를 얻었다고 보고합니다. SWE-bench는 저장소의 문제를 수정하는 평가이고, GAIA는 도구 사용을 포함하는 일반적인 어시스턴트 과제를 다룹니다. 작성자는 특히 SWE-bench에서 재귀 한도 150에 도달해 패치를 내기 전에 끝나는 문제를 짚었습니다. 저장소 탐색·파일 읽기만으로 50~80턴을 소모하는 사례를 들며 한도와 루프 감지의 영향을 설명합니다. (RFC #2820 원문)

이 기록이 유용한 이유는 실패를 “모델이 약하다” 한마디로 처리하지 않기 때문입니다. 정상적인 탐색을 반복으로 잘못 감지해 일찍 중단하는 경우와, 진전 없는 호출을 감지하지 못해 한도를 소진하는 경우를 나눕니다. 일부 작은 모델에서는 불필요한 도구 호출, 잘못된 인자와 도구 선택도 관찰했다고 적습니다. 다만 5월의 실행 경험을 9월 2.1의 현재 성능으로 그대로 옮기기보다 개선 전의 실패 원인을 보여 주는 기록으로 읽습니다. (동일 RFC의 루프·모델 관찰)

7월 11일의 RFC #4083은 평가 플랫폼을 별도 가짜 실행 경로가 아니라 실제 Gateway 실행에 연결하자는 방향을 제시합니다. 입력 과제와 초기 작업 공간, 실행 이벤트, 파일, 검증 결과를 한 근거 사슬로 묶습니다. 제안된 첫 단계에는 파일·명령·이벤트로 결과를 확인하는 구조가 있고, 평가 실행의 재귀 예산 기본값으로 300을 설명합니다. 문서 스스로 이를 엔지니어링 기본값으로 한정하며 일반적인 최적값과 구분합니다. (평가 플랫폼 RFC)

같은 RFC에는 숫자 결과도 하나 나옵니다. 여러 파일에 걸친 코드 수정, 근거를 대야 하는 질의응답, 상태를 이어가는 도구 실행이라는 세 가지 과제를 DeepSeek 모델로 한 번씩 돌렸고, 세 실행 모두 미리 정한 판정 기준을 100% 통과했다고 작성자가 보고했습니다. 문서는 바로 이어서 이 결과가 SWE-bench·GAIA 같은 표준 벤치마크에서 100%를 받았다는 뜻이 아니며, 다른 모델·공급자·환경에서 재현된다는 보장도 아니라고 밝힙니다. 실행 경로가 복잡한 과제 형태를 끝까지 처리할 수 있다는 확인 정도로 읽으면 됩니다. (RFC #4083의 실험 결과)

그 문서는 구현된 부분과 향후 제안도 나눕니다. 전체 오프라인 재현, 모든 다중 턴 실행, 완전한 비교 설정 적용, 신뢰할 선제 취소, 범용 안전 평가 등은 당시 범위에서 빠져 있다고 적습니다. 따라서 평가 플랫폼이 생겼다는 사실과 독립 벤치마크로 일반 성능이 검증됐다는 판단은 별개입니다. 독자가 비교할 때는 같은 모델·입력·도구·실행 예산으로 직접 호출과 하네스를 나란히 실행한 결과, 산출물 검증, 전체 사용량을 요청하면 판단 근거가 구체적입니다. (RFC #4083의 구현 범위)

사용자와 개발자의 반응은 어떤가요? (2026년 9월 30일 기준)

초기 사용자 토론으로는 r/LocalLLaMA의 2025년 5월 1.x 게시글을 참고할 수 있습니다. 오래된 1.x 토론이므로 현재 2.1의 설치·성능 후기와 구분해 봅니다. 당시 토론 링크는 프로젝트의 초기 반응을 찾는 출발점으로 연결합니다.

2.0 공개 뒤의 반응은 VentureBeat의 2026년 3월 23일 해설이 기대와 우려를 함께 정리했습니다. 한 개발자는 지금까지 시험한 어떤 도구보다 낫다며 회사 작업을 로컬 배포로 옮겼다고 말했는데, 이는 개인의 사용 소감입니다. 우려로는 세 가지를 짚습니다. 샌드박스 실행 환경에 대한 독립적인 공개 보안 감사가 아직 없다는 점, Docker·YAML 설정·환경변수·명령줄을 다룰 줄 알아야 설치할 수 있다는 점, 규제 산업의 조직은 ByteDance가 만든 소프트웨어라는 출처 자체를 내부 심사 대상으로 볼 수 있다는 점입니다. 2.1 이전의 기사이므로 2.1에서 추가된 인증·권한 기능과 함께 읽으면 됩니다.

내용을 확인한 개발자 토론에서는 기대하는 방향과 실행 마찰이 함께 드러납니다. #2820 작성자는 긴 작업·도구·하위 에이전트의 결합을 강점으로 보면서도, 당시 평가에서 탐색 예산 소진과 루프 감지가 결과를 낮췄다고 지적합니다. #4083 작성자는 그 문제를 실제 실행 이벤트와 산출물 검증으로 설명하는 평가 체계를 제안합니다. 두 문서는 각각의 작성자가 공개한 관찰과 제안이며 사용자 전체의 의견으로 확대하지 않습니다. (실행 한도 토론 · 평가 방법 토론)

국내 사용자의 직접 설치 후기와 한국어 성능을 판단할 자료는 확인한 출처에서 찾지 못했습니다. 한국어 업무에 적용한다면 제품명·날짜·금액·출처 인용이 들어간 실제 문서를 작은 과제로 삼아 결과를 확인하는 방법을 검토할 수 있습니다. 비교 보고서가 목적이라면 링크가 열리는지와 원문이 표의 주장에 맞는지, 코드 작업이라면 요구한 파일 변경과 테스트가 남았는지를 먼저 봅니다.

한국 독자는 어떤 경우에 검토하면 좋을까요?

공식 서비스를 한국에 출시했는지 묻는 제품보다, 직접 배포하고 모델·도구를 연결하는 오픈소스 프로젝트에 가깝습니다. 한국 결제와 계정 접근성, 데이터를 보내는 경로는 선택한 공급자의 현재 정책으로 확인합니다. 모델 ID를 설정할 수 있다는 사실과 해당 계정에서 그 모델을 호출할 수 있는지도 구분합니다. 공식 설치 지침 역시 적어도 하나의 모델 설정과 해당 환경변수·인증 준비를 시작 조건으로 다룹니다. (공식 설치 지침 · 공급자 설정)

도입 여부는 산출물에서 거꾸로 판단할 수 있습니다. 답변 한 번이면 끝나는 질문에는 준비할 서버·권한·설정이 부담이 될 수 있습니다. 여러 자료를 읽고 표를 고치고 파일을 만들어 검토까지 이어지는 작업에는 실행 기록과 작업 공간이 도움이 될 수 있습니다. 이미 작업 자동화를 운영한다면 한 번에 전체 흐름을 옮기기보다 범위가 작은 과제로 모델 비용, 성공 조건, 실패 후 이어가기와 검토 시간을 비교하는 접근이 어울립니다. 이 판단은 2.1이 제공하는 작업·검증 기능에 근거한 활용 제안입니다. (2.1 기능과 조건)

특히 “완료”를 어떻게 확인할지 먼저 정하면 하네스를 고르는 기준이 분명해집니다. 리서치에는 원문 링크와 근거가 맞는 표, 개발에는 변경 파일과 테스트 결과, 콘텐츠에는 검토 가능한 초안 파일을 요구할 수 있습니다. DeerFlow 2.1을 살펴볼 이유도 바로 이 실행과 확인의 연결에 있습니다. 모델·검색·권한을 직접 관리할 여유와 원하는 산출물이 구체적일수록 기능의 쓸모를 판단하기 수월합니다.

참고한 자료

확인일은 2026년 9월 30일입니다. 변경될 수 있는 main 문서와 정식 릴리스 설명을 구분해 참고했습니다.