클로드코드 새 기능 Dynamic Workflow

메타 하네스 스킬(github.com/revfactory/harness)을 두고 많은 의견을 들을 수 있었습니다. 그중 하나는 이런 것이었습니다. “좋은 결과가 나오기 때문에, 결국 이런 방식은 모델이나 제품 안으로 흡수되지 않을까?”

저도 어느 정도는 그렇게 생각했습니다. 하네스가 하는 일은 결국 에이전트를 더 잘 쓰기 위한 구조를 만드는 일이기 때문입니다. 단일 프롬프트에 모든 것을 맡기는 대신, 작업을 나누고, 역할을 분리하고, 검증과 합성을 명시적으로 설계하는 것. 이런 방식이 효과적이라면 언젠가는 제품 레벨에서 자연스럽게 구현될 가능성이 높다고 봤습니다.

그래서 이번에 Anthropic이 Claude Code의 새 기능으로 Dynamic Workflow를 공개했을 때 눈길이 갔습니다. 설명에는 다수의 에이전트를 만들고, 워크플로우를 구성하고, 작업을 병렬로 수행한다는 내용이 담겨 있었습니다. 겉으로 보기에는 하네스가 다루던 문제의식과 꽤 가까워 보였습니다. 정말 이런 방향이 제품 안으로 들어오기 시작한 걸까? 이제 에이전트 작업의 구조화가 본격적으로 시작된 걸까?

하지만 실제로 Dynamic Workflow를 수행해보고, 그 세부 내용을 들여다본 뒤에는 실망이 더 컸습니다.

가장 먼저 걸린 것은 이름입니다. Dynamic Workflow라고 부르지만, 실제로는 그다지 다이나믹하지 않았습니다. Claude는 실행 초기에 JavaScript 스크립트를 한 번 작성합니다. 문제는 이 스크립트가 데이터를 보기 전에 작성된다는 점입니다. 아직 검색 결과도 보지 않았고, 어떤 주장이 중요한지도 모르고, 어떤 방향이 막다른 길인지도 모르는 상태에서 워크플로우의 구조가 먼저 정해집니다.

예를 들어 “여섯 개 관점으로 검색하고, 상위 열두 개 주장을 검증한다”는 식의 계획이 만들어집니다. 그런데 실제로 중요한 쟁점이 일곱 번째 관점에 있었다면 어떻게 될까요. 검증할 주장이 열두 개가 아니라 마흔 개였다면요. 중간에 전혀 다른 방향으로 틀어야 할 단서가 발견됐다면요.

워크플로우는 그걸 모릅니다. 이미 작성된 스크립트를 실행하고 있기 때문입니다.

이 지점이 하네스와의 중요한 차이처럼 느껴졌습니다. 하네스의 관심은 단지 에이전트를 많이 만드는 데 있지 않았습니다. 중요한 것은 실행 중에 무엇을 배웠고, 그 배움을 다음 단계의 구조에 어떻게 반영할 것인가였습니다. 에이전트의 수가 아니라, 피드백 루프가 핵심이었습니다.

Dynamic Workflow는 반대로 보였습니다. 초기에 계획을 크게 만들고, 그 계획을 병렬로 실행합니다. 동적인 것은 팬아웃의 크기일 뿐, 구조 자체는 초기에 고정이 되어버립니다. 검색 결과가 무엇을 말하든, 검증 중에 어떤 이상 신호가 나오든, 워크플로우의 큰 형태는 이미 정해져 있습니다.

공식적인 실행 제약도 이 문제를 키웁니다. 실행 중에는 사용자가 끼어들 수 없고, 에이전트끼리 직접 대화할 수도 없습니다. 어떤 에이전트가 중요한 단서를 발견해도 다른 에이전트에게 “이 관점에서 다시 봐야 한다”고 말할 수 없습니다. 사람도 중간에 들어가 방향을 수정할 수 없습니다.

이것은 우리가 보통 기대하는 에이전트적 적응성과는 다릅니다. 적응성을 얻었다기보다, 적응성을 일부 포기하고 결정성과 규모를 얻은 구조에 가깝습니다. 물론 그런 구조가 필요한 작업도 있습니다. 하지만 그렇다면 이것을 Dynamic Workflow라고 부르기보다는, “사전에 생성된 실행 계획을 대규모로 병렬 수행하는 시스템”이라고 부르는 편이 더 정확합니다.

비용 문제도 있었습니다. 어떤 실험에서는 약 72만 토큰이 사용됐습니다. 단일 패스로 처리했을 때보다 대략 10배에서 15배 많은 수준이었습니다. 처음에는 프롬프트를 더 잘 다듬으면 줄일 수 있는 낭비처럼 보일 수 있습니다. 하지만 실제로는 구조에서 나오는 비용에 가깝습니다.

팬-아웃을 만들면 각 에이전트가 별도의 컨텍스트를 씁니다. 검증자를 붙이면 그만큼 다시 컨텍스트가 늘어납니다. 검색하고, 요약하고, 검증하고, 합성하는 단계가 늘어날수록 토큰은 선형이 아니라 배수로 증가합니다. “더 엄밀하게 하자”는 요구는 곧 “더 많은 에이전트를 돌리자”로 바뀌고, 더 빠르게 제한에 도달합니다.

문제는 이 비용이 기능의 부작용이 아니라 기능의 본질에 가깝다는 점입니다. Dynamic Workflow는 많은 작업을 동시에 벌이는 방식으로 신뢰도를 얻으려 합니다. 그러면 당연히 비용도 커집니다. 이것을 단순한 튜닝 문제로 보면 안 됩니다.

검증 단계도 생각보다 신뢰하기 어려웠습니다. 실험 과정에서 한번은 열두 개 주장을 검증했는데, 기각된 주장이 하나도 없었습니다. confirmed가 아홉 개, partially true가 세 개였습니다. 겉으로 보면 좋은 결과처럼 보입니다. 많은 검증자가 붙었고, 많은 토큰을 썼고, 주장들이 확인된 것처럼 보입니다.

하지만 기각률 0은 오히려 이상한 신호였습니다.

같은 정보 생태계 안에서 여러 번 확인하는 것에 문제가 있었습니다. 검증자가 열두 명이라고 해서 자동으로 엄밀해지지는 않습니다. 검증자들이 바라보는 곳이 같다면, 그것은 적대적 검증이 아니라 순환 검증입니다.

동작을 살펴보는 것도 어려웠습니다. 이번 산출물에서 열두 명의 검증자가 서로 다른 주장을 검증했는데, 라벨은 모두 verify:announcement로 같았습니다. 진행 트리만 봐서는 누가 무엇을 검증하고 있는지 분간하기 어려웠습니다.

25개 에이전트 규모에서 이미 이런 문제가 보인다면, 100개나 1,000개 규모에서는 어떻게 될까요. 잘못된 에이전트 하나를 찾아내고, 왜 그런 판단을 했는지 따라가고, 어디서부터 문제가 생겼는지 디버깅하는 일은 거의 불가능에 가까워집니다.

에이전트 시스템에서 중요한 것은 단순히 많이 돌리는 능력이 아닙니다. 많이 돌릴수록 더 잘 관측이 가능해야 합니다. 어떤 에이전트가 어떤 입력을 받았고, 어떤 가정을 세웠고, 어떤 결론을 냈는지 추적할 수 있어야 합니다. 규모가 커질수록 관측성은 부가 기능이 아니라 핵심 기능이 됩니다.

그런데 Dynamic Workflow는 규모를 키우는 쪽에는 힘이 있지만, 그 규모를 사람이 이해하고 통제하게 만드는 장치는 아직 부족해 보였습니다.

재현성도 과장되어 있습니다. 워크플로우가 코드로 표현되기 때문에 재현 가능하다는 말은 절반만 맞습니다. 특정 스크립트를 저장해두면 구조는 재현할 수 있습니다. 하지만 결과까지 재현된다고 말하기는 어렵습니다. 모델 출력은 비결정적이고, 웹 검색 결과도 달라질 수 있습니다.

게다가 같은 프롬프트로 Claude에게 워크플로우를 다시 작성하게 하면 스크립트 자체도 달라질 수 있습니다. 검색 에이전트 수가 달라지고, 검증할 주장 수가 달라지고, 작업 분해 방식도 바뀔 수 있습니다. 재현성은 워크플로우가 생성되기 전이 아니라 생성된 후, 특정 스크립트를 고정했을 때 제한적으로 생깁니다.

더 위험한 것은 실패 비용입니다. 단일 에이전트가 잘못된 방향으로 가면 낭비는 제한적입니다. 대화 중에 고치거나, 멈추거나, 다시 시도하면 됩니다. 하지만 큰 워크플로우가 처음부터 잘못 설계되면 이야기가 다릅니다. 수십 개, 수백 개의 에이전트가 같은 잘못된 설계 위에서 움직일 때 문제는 심각해집니다.

그리고 중간에 사람이 끼어들 수 없습니다. 실행 30분 뒤에 방향이 틀렸다는 것을 알아도 선택지는 많지 않습니다. 끝까지 태우거나, 중단하고 지금까지의 작업을 버리거나. 장기 자율 작업이라는 Dynamic Workflow의 매력적인 사용 사례가, 동시에 가장 위험한 실패 양상을 품고 있습니다.

이 기능이 걱정되는 또 하나의 이유는 오버 엔지니어링을 유도하기 쉽다는 점입니다. 여러 에이전트가 동시에 돌고, 진행 트리가 펼쳐지고, 검증 단계가 붙으면 굉장히 그럴듯해 보입니다. 실제로 더 잘하고 있는 것처럼 보입니다. 하지만 모든 작업이 그런 구조를 필요로 하는 것은 아닙니다.

어떤 작업은 단일 에이전트로 충분합니다. 어떤 작업은 사람과 모델이 짧게 주고받으며 방향을 잡는 편이 낫습니다. 어떤 작업은 작은 하네스 하나면 됩니다. 그런데 워크플로우라는 형식은 그 자체로 뭔가 있어보이는 효과를 갖습니다. “이렇게까지 했으니 더 엄밀하겠지”라는 인상을 만듭니다.

특히 ultracode처럼 실질적인 작업을 기본적으로 워크플로우로 계획하는 모드는 이 위험을 키웁니다. 봉투 한 장을 보내는 데 화물열차를 붙이는 일이 될 수 있습니다.

그래서 이번 Dynamic Workflow를 보며 느낀 실망은, 이 기능이 아무 의미가 없어서가 아닙니다. 오히려 방향 자체는 중요합니다. 에이전트 작업은 앞으로 더 구조화될 것이고, 단일 모델 호출보다 복잡한 실행 그래프가 필요해질 것입니다. 다수의 에이전트를 만들고, 역할을 나누고, 검증과 합성을 명시하는 흐름도 분명 필요합니다.

하지만 핵심은 “많이 돌리는 것”이 아닙니다.

정말 중요한 것은 실행 중에 배운 것을 다음 구조에 반영하는 능력입니다. 검증자가 독립적인 관점과 출처를 가질 수 있게 만드는 능력입니다. 사람이 중간에 개입해 방향을 수정할 수 있는 방식을 고민해야 합니다. 실패를 조기에 발견하고 멈출 수 있는 장치가 필요합니다. 그리고 규모가 커져도 사람이 이해하고 디버깅할 수 있는 방식이 제공되어야 합니다.

메타 하네스가 던졌던 질문도 여기에 가까웠습니다. 에이전트를 몇 개까지 만들 수 있는가가 아니라, 에이전트들이 어떤 구조 안에서 학습하고, 상호작용하고, 검증하고, 실패를 줄일 수 있는가. Dynamic Workflow는 아직 핵심에는 도달하지 못했습니다.

그래서 제 결론은 이렇습니다. “정말 시작된 건가?”라는 기대는 있었습니다. 하지만 실제로 들여다본 뒤에는 “아직은 아니다”에 가깝습니다.

Dynamic Workflow는 이름처럼 동적인 사고 시스템이라기보다, 정적인 계획을 크게 만들어 병렬로 실행하는 시스템에 가깝습니다. 그 차이를 분명히 보지 못하면, 우리는 에이전트 시스템의 진보를 얻었다고 믿으면서 실제로는 비용과 불투명성, 실패 규모만 키우게 될 수 있습니다.

기대가 컸던 것일까 아쉬운 마음에 글이 길어졌네요.