ChatDev 2.0(DevAll), 코드 없이 다중 에이전트 시스템을 구성하고 실행하는 방법 | DAKER 커뮤니티

2026년 9월 1일 OpenBMB·칭화대·상하이교통대 등이 ChatDev 2.0(DevAll)을 arXiv에 공개했습니다. 다중 에이전트 시스템을 만들 때마다 오케스트레이션 코드를 새로 짜야 하는지, 아니면 그래프 명세만으로도 충분한지 궁금했다면 지금 읽어볼 만한 소식입니다.

이 논문은 시각적 캔버스 위에서 이종 다중 에이전트 시스템(MAS)을 작성·실행·검사하는 노코드 플랫폼을 제안합니다. 특히 선언적 실행 그래프와 CADET(Cycle-Aware Dynamic Execution Topology)으로 임의 사이클을 다룬다는 점이 핵심입니다.

논문은 2026-09-01 arXiv에 올라왔습니다. 초록은 arXiv:2609.00714에서 확인할 수 있습니다. 영문 제목은 ChatDev 2.0: A No-Code Multi-Agent Platform for Developing Everything입니다. 저자는 Yufan Dang, Shu Yao, Bowen Lai, Chen Qian, Zhiyuan Liu 외 (Tsinghua, SJTU)입니다. PDF는 같은 번호의 pdf이며, 코드는 GitHub OpenBMB/ChatDev에 공개되어 있습니다. 이 글은 제공된 사실과 초록·본문에서 확인한 범위만 옮깁니다.

과제별 오케스트레이션 코드를 새로 쓰지 않고, 그래프 명세만으로 워크플로를 재현하는 것이 DevAll의 문제의식입니다.

노코드로 이종 MAS를 작성·실행·검사합니다

DevAll은 시각 인터페이스를 통해 이종 다중 에이전트 시스템을 작성하고 실행하며 검사하는 플랫폼입니다. 기존 코드 기반 프레임워크는 표현력이 크지만 엔지니어링 비용이 높고, 반대로 기존 노코드 빌더는 미리 정해진 워크플로 경계 안에 에이전트를 가두기 쉽습니다. DevAll은 이 간극을 줄이기 위해 선언적 실행 그래프를 사용합니다.

사용자는 캔버스에 노드를 배치하고 시맨틱 엣지로 연결합니다. 이 시맨틱 엣지는 데이터 흐름과 제어 흐름을 구분하며, 활성화 조건과 데이터 정책, 제어 정책을 함께 담습니다. 에이전트는 로컬 상태를 유지하고 런타임 메시지에서 컨텍스트를 모읍니다. Human 노드에서는 실행이 멈추고, 피드백 이후 다시 이어집니다.

Tutorial·Authoring·Execution·Inspection 화면이 하나의 플랫폼 안에 묶여 있다는 점도 특징입니다. 논문이 제시하는 방향은, 다중 에이전트 파이프라인을 코드 파일이 아니라 실행 그래프 명세로 다루는 방식에 가깝습니다.

CADET이 임의 사이클을 스케줄합니다

다중 에이전트 그래프에 사이클이 포함되면 단순한 위상 정렬만으로는 실행 순서를 정하기 어렵습니다. DevAll은 이를 위해 CADET(Cycle-Aware Dynamic Execution Topology)를 제안합니다.

CADET은 강연결성분(SCC)을 응축해 전역적으로는 DAG처럼 스케줄하고, SCC 내부에서는 범위를 제한한 반복을 수행합니다. 백엣지는 다음 반복으로 미루고, 비백엣지는 현재 반복의 비순환 골격으로 유지합니다. 반복 상한을 두어 종료를 보장한다는 설명입니다.

CADET의 핵심은 사이클이 있는 그래프를 전역적으로는 DAG처럼 다루고, 지역적으로만 반복 실행하는 데 있습니다.

논문에서 제시한 노드 타입은 Agent, Human, Python, Subgraph, Literal, Passthrough, LoopCounter의 일곱 가지입니다. 컴파일 엔진은 YAML을 실행 그래프로 만들고, 실행 엔진은 시맨틱 엣지를 따라 전파합니다. Laboratory 인터페이스와 Python SDK를 통해 배치 평가도 지원합니다.

런타임 오버헤드는 SCC 수를 1에서 16까지 키울 때 대체로 선형적으로 증가했다고 보고합니다. 가장 큰 설정에서 컴파일 중앙값은 16.23ms, 실행 중앙값은 14.46ms, 플래닝은 91.96μs입니다. 논문은 이를 LLM 추론이나 네트워크 지연과 비교해 지역 스케줄 비용이 작다고 해석합니다.

세 벤치마크에서 확인한 수치

논문은 MatPlotBench, DeepResearchBench, SRDD 세 벤치마크에서 결과를 제시합니다. 백본은 GPT-4o로 통일했습니다.

이 수치는 특정 도메인 전문 시스템을 모두 앞선다는 주장이라기보다, 하나의 노코드 플랫폼이 서로 다른 세 도메인의 핵심 워크플로를 재현할 수 있는지 보여주는 데 가깝습니다. 논문은 DeepResearchBench의 경우 LLM 판정 분산이 있어 작은 차이는 평가 노이즈 범위로 읽을 수 있다고 설명합니다. SRDD에서는 완전성은 높고 실행·일관성은 약간 낮아 overall이 거의 비슷하다고 정리합니다.

MatPlotBench에서는 앞서지만, DeepResearchBench와 SRDD overall은 비교 시스템과 가깝거나 약간 뒤에 있습니다.

이 논문을 읽을 때 함께 봐야 할 한계

이 결과를 모든 도메인에서 CoDA·EDR·ChatDev 1.0을 이긴다는 뜻으로 읽기는 어렵습니다. 벤치마크별로 양상이 다르고, 논문도 그런 식으로 주장하지 않습니다.

또한 코드가 전혀 필요 없다는 보증도 아닙니다. 과제별 오케스트레이션 코드를 새로 쓰지 않고 선언적 그래프로 재현했다는 보고이며, 플랫폼 자체와 도구 설정, 백본 설정은 여전히 필요합니다.

CADET의 지연 역시 모든 하드웨어 환경에서 무시할 수준이라고 일반화할 수는 없습니다. 논문이 제시한 값은 SCC 스케일 실험의 중앙값입니다. 마찬가지로 GPT-4o 외 다른 백본에서도 같은 점수가 나온다고 확장해 읽을 수는 없습니다. 실험은 GPT-4o로 통일했다고 적혀 있습니다.

문서화할 때 유용한 관점

이 논문이 실무에 주는 가장 직접적인 힌트는, 에이전트 파이프라인을 코드 파일 중심이 아니라 실행 그래프 명세 중심으로 정리해볼 수 있다는 점입니다. 에이전트 역할, 프롬프트, 도구, 시맨틱 엣지, 그리고 사이클 필요 여부를 선언적으로 남기면 재현성과 설명 가능성이 높아집니다.

Human-in-the-loop 지점을 어디에 둘지 미리 정하는 것도 중요합니다. DevAll은 Human 노드에서 실행을 멈추고 피드백 뒤 이어가는 구조를 포함하므로, 어떤 단계에서 사람 검토가 필요한지 분리해 적는 방식이 잘 맞습니다.

벤치마크 수치를 인용할 때는 논문 수치를 자신의 실측처럼 쓰지 않고, 출처와 함께 비교 열만 옮기는 것이 좋습니다. 특히 MatPlotBench·DeepResearchBench·SRDD의 숫자는 arXiv:2609.00714에 근거한 값이라는 점을 분명히 해야 합니다.

참고 자료

arXiv:2609.00714 — ChatDev 2.0: A No-Code Multi-Agent Platform for Developing Everything (2026-09-01)
PDF
GitHub OpenBMB/ChatDev

여러분은 다중 에이전트 워크플로를 설명할 때 코드보다 그래프 명세가 더 적합하다고 보시는지 궁금합니다.