bytedance가 공개한 'SuperAgent 하네스', deer-flow가 흥미로운 이유

bytedance/deer-flow의 자기소개는 한 문장이다. 'open-source long-horizon SuperAgent harness that researches, codes, and creates.' 영리한 단어 선택이다. 요즘 모두가 'agent'를 만들 때, 이쪽은 그 앞에 'long-horizon'을, 그리고 그 뒤에 'harness'를 붙였다. 모델 자랑이 아니라, 분이 아니라 시간 단위로 도는 작업을 끝까지 끌고 가기 위한 골격을 만들고 있다는 선언이다. 공개된 구성 요소는 여섯 개다. sandbox, memory, tools, skill, subagent, message gateway. 비슷해 보이는 단어가 두 쌍 들어 있는 게 의도적으로 보인다. tools와 skill, 그리고 subagent와 message gateway. tools가 단발 호출이라면 skill은 여러 tool 호출을 엮은 재사용 가능한 절차다. subagent가 실행 단위라면 message gateway는 그 단위들이 서로 어떻게 말하는지를 통제하는 통신 평면이다. 단순한 multi-agent 프레임워크가 흔히 섞어 쓰는 책임을 일부러 갈라놓은 셈이다. 왜 이런 분리가 필요한가. 에이전트가 30분을 넘기는 순간 보통 두 곳에서 깨진다. 첫째, 누적되는 컨텍스트가 압축되며 처음의 의도가 닳아 사라진다. 둘째, 서브에이전트가 늘어날수록 메시지 흐름이 사실상 N×N 그래프로 폭발해 디버깅 불가능 상태가 된다. memory는 첫 번째 실패에, message gateway는 두 번째 실패에 정면으로 대응하는 컴포넌트다. sandbox 역시 단순한 코드 실행 박스가 아니라, 한 step의 부수효과가 다음 step을 오염시키지 못하도록 잘라주는 격리 경계이자, 실패한 분기를 깔끔히 되돌릴 수 있는 롤백 지점으로 읽어야 한다. 수치로 보면 Python 기반, GitHub 트렌딩 14위, 오늘 하루 별 328개. 화려한 데모 없이도 이 정도 속도가 나오는 이유는 사람들이 같은 통증을 겪고 있기 때문이라고 본다. 진짜 어려운 건 '한 번 잘 답하는 에이전트'가 아니라 '몇 시간 동안 살아남는 에이전트'다. deer-flow가 흥미로운 건 정답을 주장해서가 아니라, 그 어려움을 6개의 분리된 추상화로 풀어보자고 제안하기 때문이다. 평가는 실제 코드와 예제에서 다시 해야겠지만, 적어도 문제 정의는 정직하다.