동적 워크플로우, 그 이름에 숨은 함정

기술과 교육의 교차점에서 늘 그렇듯, 새로운 기술이 등장하면 우리는 희망과 우려 사이에서 줄타기를 한다. 최근 앤스로픽이 클로드 코드(Claude Code)에 다이내믹 워크플로우(Dynamic Workflow)라는 기능을 선보였을 때도 그러했다. 복잡한 에이전트 작업을 손쉽게 구조화한다는 발표는 마치 거대한 숙제를 자동으로 해주는 마법처럼 들렸다. 하지만 현장에서 직접 부딪혀본 경험은 때로 달콤한 환상을 차가운 현실로 돌려놓는다. 과연 이 ‘동적’이라는 이름표는 기술의 본질을 정확히 담고 있을까? 나는 의심한다.

이름값 못하는 ‘동적’ 워크플로우의 그림자

처음 다이내믹 워크플로우의 설명을 들었을 때, 카카오 FDE 황민호 님의 메타 하네스(Meta Harness)가 던졌던 질문과 겹쳐 보였다. 단일 프롬프트에 모든 것을 맡기는 대신, 작업을 나누고 역할을 분리하며 검증과 합성을 명시적으로 설계하는 방식. 이것이 에이전트 시스템을 효과적으로 활용하는 길이라는 생각은 많은 이들의 공감을 얻었다. 클로드 코드의 새 기능 역시 다수의 에이전트를 만들고 워크플로우를 구성하며 작업을 병렬로 수행한다는 점에서 유사한 문제의식을 공유하는 듯 보였다. 에이전트 작업의 구조화가 이제 본격적으로 제품 레벨로 들어오기 시작한 것인가 하는 기대감도 분명 있었다.

그러나 황민호 FDE가 직접 다이내믹 워크플로우를 수행하고 그 세부 내용을 들여다본 뒤에는 깊은 실망감을 표했다. 가장 먼저 지적한 부분은 이름과 실제 기능 사이의 괴리였다. ‘동적(Dynamic)’이라는 명칭과 달리, 이 워크플로우는 그다지 동적이지 않았다. 클로드는 실행 초기에 자바스크립트(JavaScript) 스크립트를 한 번 작성하지만, 문제는 이 스크립트가 실제 데이터를 보기 전에 만들어진다는 점이다. 즉, 아직 검색 결과도 모르고, 어떤 주장이 중요한지도 알 수 없으며, 심지어 어떤 방향이 막다른 길인지도 모르는 상태에서 워크플로우의 전체 구조가 먼저 고정된다.

가령 “여섯 개 관점으로 검색하고, 상위 열두 개 주장을 검증한다”는 식의 계획이 초기에 만들어졌다고 가정해보자. 만약 실제 중요한 쟁점이 일곱 번째 관점에서 발견된다면 어떻게 될까? 검증할 주장이 열두 개가 아니라 마흔 개였다면? 중간에 전혀 다른 방향으로 틀어야 할 결정적 단서가 나타났다면? 워크플로우는 이미 작성된 스크립트를 기계적으로 실행하므로 이러한 상황에 적응할 여지가 없다. 황민호 FDE는 이 지점을 메타 하네스와의 본질적인 차이로 본다. 메타 하네스의 관심은 에이전트의 ‘수’가 아니라, 실행 중에 무엇을 배우고 그 배움을 다음 단계의 구조에 어떻게 반영할 것인가에 집중한다. 이는 피드백 루프의 유무라는 근본적인 차이를 만든다. 다이내믹 워크플로우는 초기에 큰 계획을 만들고 그것을 병렬로 실행하는 데 능하지만, 동적인 것은 단지 ‘팬아웃(fan-out)’의 크기일 뿐, 워크플로우의 구조 자체는 고정되어버린다. 검색 결과가 무엇을 말하든, 검증 중에 어떤 이상 신호가 나오든, 큰 형태는 이미 정해진 틀 안에 갇힌다.

우리가 교육 현장에서 기대하는 ‘적응성’과는 거리가 멀다. 학습자의 상황이나 새로운 정보에 유연하게 반응하기보다, 정해진 계획을 대규모로 밀어붙이는 방식에 가깝다. 이는 적응성을 일부 포기하고 결정성과 규모를 얻는 구조로 해석된다.

예측 불가능한 비용과 불확실한 검증

다이내믹 워크플로우를 둘러싼 또 다른 중요한 문제는 바로 비용이다. 황민호 FDE가 진행한 한 실험에서는 약 72만 토큰이 사용되었다고 한다. 이는 단일 패스로 처리했을 때보다 대략 10배에서 15배 많은 수준이다. 처음에는 프롬프트를 더 잘 다듬으면 줄일 수 있는 낭비처럼 보일 수 있지만, 그는 이것이 구조에서 기인하는 비용이라고 단언한다.

팬아웃 구조를 만들면 각 에이전트가 별도의 컨텍스트를 사용한다. 검증자를 붙이면 그만큼 다시 컨텍스트가 늘어난다. 검색하고, 요약하고, 검증하고, 합성하는 단계가 늘어날수록 토큰 사용량은 선형이 아니라 배수로 증가하는 구조다. “더 엄밀하게 하자”는 요구는 “더 많은 에이전트를 돌리자”로 직결되고, 이는 더 빠르게 토큰 제한에 도달하게 만든다. 중요한 것은 이 비용이 기능의 부작용이 아니라 기능의 본질에 가깝다는 점이다. 다이내믹 워크플로우는 많은 작업을 동시에 벌이는 방식으로 신뢰도를 얻으려 하며, 따라서 비용이 커지는 것은 당연한 결과다. 이것을 단순한 튜닝 문제로 보면 안 된다. 학교 현장에서 예산 제약은 늘 현실적인 문제이며, 이처럼 예측 불가능하게 폭증하는 비용 모델은 쉽게 도입하기 어렵다.

게다가 검증 단계의 신뢰성 또한 황민호 FDE에게 큰 의문을 남겼다. 그의 실험 과정에서 열두 개 주장을 검증했는데, 기각된 주장이 하나도 없었다고 한다. 9개가 confirmed, 3개가 partially true였다. 겉으로 보면 많은 검증자가 붙어 좋은 결과를 낸 것처럼 보이지만, 기각률 0%는 오히려 비정상적인 신호다. 문제는 검증자들이 바라보는 정보 생태계가 같다는 점이다. 검증자가 열두 명이라고 해서 자동으로 엄밀해지지는 않는다. 만약 모두가 같은 출처나 관점 안에서 확인 작업을 한다면, 그것은 ‘적대적 검증’이 아니라 ‘순환 검증’에 불과하다. 즉, 서로 다른 오류를 걸러내는 독립적인 검증이 아니라, 이미 공유된 편향을 반복해서 확인하는 작업이 될 가능성이 농후하다.

통제 불능의 규모, 디버깅은 미궁으로

다이내믹 워크플로우는 확장된 규모에서 동작의 투명성 또한 심각하게 훼손한다. 황민호 FDE가 수행한 실험에서는 열두 명의 검증자가 서로 다른 주장을 검증했음에도 불구하고, 라벨은 모두 verify:announcement로 동일했다. 진행 트리를 보더라도 누가 무엇을 검증하고 있는지 분간하기 어려웠다고 한다. 25개 에이전트 규모에서도 이런 문제가 발생한다면, 100개나 1,000개 규모에서는 어떨까? 잘못된 에이전트 하나를 찾아내고, 왜 그런 판단을 했는지 추적하며, 어디서부터 문제가 생겼는지 디버깅하는 일은 거의 불가능에 가깝다.

에이전트 시스템에서 중요한 것은 단순히 많이 돌리는 능력이 아니다. 많이 돌릴수록 더 잘 ‘관측’이 가능해야 한다. 어떤 에이전트가 어떤 입력을 받았고, 어떤 가정을 세웠으며, 어떤 결론을 내렸는지 추적할 수 있어야 한다. 규모가 커질수록 관측성은 부가 기능이 아니라 핵심 기능이 된다. 마치 학교에서 여러 프로젝트가 동시에 진행될 때, 각 프로젝트의 진행 상황과 핵심 의사결정을 투명하게 파악할 수 있어야 하는 것과 같다. 하지만 다이내믹 워크플로우는 규모를 키우는 쪽에는 힘이 있지만, 그 규모를 사람이 이해하고 통제하게 만드는 장치는 아직 부족하다.

재현성 또한 과장된 측면이 있다. 워크플로우가 코드로 표현되기 때문에 재현 가능하다는 말은 절반만 맞다. 특정 스크립트를 저장해두면 구조는 재현할 수 있지만, 결과까지 재현된다고 말하기는 어렵다. 모델 출력은 비결정적이며, 웹 검색 결과 역시 늘 달라질 수 있기 때문이다. 게다가 같은 프롬프트로 클로드에게 워크플로우를 다시 작성하게 하면 스크립트 자체도 달라질 수 있다. 검색 에이전트 수가 바뀌고, 검증할 주장 수가 변하며, 작업 분해 방식도 변경될 수 있다. 재현성은 워크플로우가 생성되기 전이 아니라, 생성된 후 특정 스크립트를 고정했을 때 제한적으로만 확보된다.

더 위험한 것은 ‘실패 비용’이다. 단일 에이전트가 잘못된 방향으로 가면 낭비는 제한적이다. 대화 중에 고치거나, 멈추거나, 다시 시도하면 된다. 하지만 큰 워크플로우가 처음부터 잘못 설계되면 이야기가 다르다. 수십 개, 수백 개의 에이전트가 같은 잘못된 설계 위에서 움직일 때 문제는 기하급수적으로 심각해진다. 공식적인 실행 제약 때문에 중간에 사람이 끼어들 수도 없다. 실행 30분 뒤에야 방향이 틀렸다는 것을 알아도 선택지는 많지 않다. 끝까지 태우거나, 중단하고 지금까지의 작업을 모두 버리거나. 다이내믹 워크플로우가 내세우는 ‘장기 자율 작업’이라는 매력적인 사용 사례는 동시에 가장 위험한 실패 양상을 품고 있는 셈이다. 이는 교사가 학생 프로젝트를 지도할 때, 초기에 잘못된 방향을 잡았다면 전체 프로젝트가 표류할 수 있는 상황과 비슷하다. 중간중간 점검하고 방향을 수정할 수 있는 여지가 반드시 필요하다.

과유불급, 오버 엔지니어링의 유혹

이 기능이 걱정되는 또 다른 이유는 오버 엔지니어링을 유도하기 쉽다는 점이다. 여러 에이전트가 동시에 돌고, 진행 트리가 펼쳐지고, 검증 단계가 붙으면 굉장히 그럴듯해 보인다. 실제로 더 잘하고 있는 것처럼 착각하게 만든다. 하지만 모든 작업이 그런 거대한 구조를 필요로 하는 것은 아니다. 어떤 작업은 단일 에이전트로 충분하다. 어떤 작업은 사람과 모델이 짧게 주고받으며 방향을 잡는 편이 훨씬 효율적이다. 어떤 작업은 작은 메타 하네스 하나면 충분하다.

그런데 ‘워크플로우’라는 형식은 그 자체로 ‘뭔가 있어 보이는’ 효과를 갖는다. “이렇게까지 했으니 더 엄밀하겠지”라는 인상을 자연스럽게 만든다. 특히 울트라코드(ultracode)처럼 실질적인 작업을 기본적으로 워크플로우로 계획하는 모드는 이러한 위험을 키운다. 황민호 FDE는 이를 두고 ‘봉투 한 장을 보내는 데 화물열차를 붙이는 일’에 비유했다. 교육 현장에 비유하자면, 학생들에게 간단한 과제를 내주면서 모든 단계마다 복잡한 협업 도구와 평가 프로세스를 강제하는 것과 같다. 필요 이상의 복잡성은 오히려 본질적인 학습을 방해하고 비용만 늘릴 뿐이다.

국내외 현장의 냉철한 시선

클로드 코드의 다이내믹 워크플로우는 ‘계획을 코드로 옮기는’ 기능으로 요약된다. 사용자가 복잡한 작업을 설명하면 클로드가 자바스크립트 워크플로우를 작성하고, 그 안에서 여러 서브 에이전트를 병렬로 실행한다. 제어 흐름은 코드가 맡고, 에이전트는 판단을 맡는다는 모델은 모델의 컨텍스트 한계를 우회하는 명쾌한 방식으로 소개되었다. 공식적으로는 클로드 코드 v2.1.154+에서 제공되는 리서치 프리뷰(research preview) 기능이며, 동시 최대 16개, 1회 실행당 총 1,000개 에이전트까지 다룰 수 있는 스케일 도구로 제시되었다.

초기 반응은 꽤 극적이었다. 발표 직후에는 “앤스로픽이 내놓은 가장 와일드한 기능”이라는 식의 흥분이 먼저 나왔다. 대규모 조사, 코드베이스 감사, 마이그레이션처럼 한 번에 넓게 훑어야 하는 작업에서는 분명 매력적이라는 평가가 많았다. 일부 실사용 후기에서는 9개 소스에서 17개 항목을 빠르게 모으는 등 병렬 처리의 체감 가치를 강조하기도 했다.

그러나 며칠 지나지 않아 분위기는 회의 쪽으로 기울었다. 가장 큰 불만은 비용이었다. 여러 에이전트를 대량으로 팬아웃하면 토큰을 빠르게 소모한다는 우려가 커졌고, 해커 뉴스(Hacker News)에서는 “토큰맥싱(tokenmaxxing)”이라는 표현까지 나왔다. 깃허브(GitHub)에서도 작은 작업에 과한 멀티 에이전트 워크플로우가 실행되었다는 보고와 함께, 서브 에이전트 모델을 더 저렴한 모델로 지정하고 싶다는 요청, 메모리와 프로세스 폭증 우려가 이어졌다.

더 근본적인 쟁점은 ‘규모’와 ‘정확성’의 충돌이었다. 앤스로픽은 이 기능을 더 큰 범위, 더 빠른 오케스트레이션을 위한 해법으로 제시했다. 반면 회의론자들은 자신들의 병목이 속도나 규모가 아니라 “결과가 맞는가”에 있다고 봤다. 즉, 더 많은 에이전트가 더 빨리 움직이는 것보다, 잘못된 판단을 어떻게 멈추고 교정할 수 있는지가 더 중요하다는 인식이다. 이 축의 불일치가 긍정과 부정이 갈린 핵심 이유로 보인다.

논쟁을 키운 또 하나의 요인은 번 지그(Bun Zig)에서 러스트(Rust)로의 리라이트 데모였다. 이 사례는 다이내믹 워크플로우의 스케일을 보여주는 간판처럼 쓰였지만, 동시에 코드 품질 논쟁의 진앙이 됐다. 언세이프 블록(unsafe block) 수, 리라이트 기간, 실제 워크플로우 기여도, 인간 리뷰 여부를 두고 여러 주장이 엇갈렸다. 검증 결과를 보면 99.8% 테스트 통과처럼 확인된 부분도 있지만, “전 과정 무인”이나 “워크플로우 덕분”이라는 식의 서사는 과장으로 봐야 한다는 의견이 지배적이다.

한국 커뮤니티의 반응은 영어권과는 다소 달랐다. 영어권은 1,000개 서브 에이전트, 대규모 마이그레이션, AI 코드 품질 논쟁에 즉각적으로 달아올랐다. 한국에서는 논의 자체가 적었고, 관심의 중심도 “대단한 스케일”보다는 “토큰 비용이 터지지 않나”, “구독을 어떻게 최적화할 것인가”에 가까웠다. 공개된 한국어 활용 사례도 대규모 엔터프라이즈 마이그레이션보다는 블로그 SEO 점검 같은 개인 생산성 수준에 머무는 경우가 많았다. 이는 한국의 교육 현장이 대규모 AI 시스템 도입보다 비용 효율성과 실용성에 더욱 민감하게 반응하는 현실을 반영한다.

진정한 에이전트 시스템을 향한 질문

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

정말 중요한 것은 실행 중에 배운 것을 다음 구조에 반영하는 능력이다. 검증자가 독립적인 관점과 출처를 가질 수 있게 만드는 능력이다. 사람이 중간에 개입하여 방향을 수정할 수 있는 방식을 고민해야 한다. 실패를 조기에 발견하고 멈출 수 있는 장치가 필요하다. 그리고 규모가 커져도 사람이 이해하고 디버깅할 수 있는 방식이 제공되어야 한다. 메타 하네스가 던졌던 질문도 여기에 가깝다. 에이전트를 몇 개까지 만들 수 있는가가 아니라, 에이전트들이 어떤 구조 안에서 학습하고, 상호작용하고, 검증하고, 실패를 줄일 수 있는가. 다이내믹 워크플로우는 아직 이 본질적인 질문에는 도달하지 못했다.

결국 “정말 에이전트 시스템의 진보가 시작된 건가?”라는 기대는 있었지만, 실제로 들여다본 뒤에는 “아직은 아니다”에 가깝다. 다이내믹 워크플로우는 이름처럼 동적인 사고 시스템이라기보다, 정적인 계획을 크게 만들어 병렬로 실행하는 시스템에 가깝다. 그 차이를 분명히 보지 못하면, 우리는 에이전트 시스템의 진보를 얻었다고 믿으면서 실제로는 비용과 불투명성, 그리고 실패 규모만 키우게 될 수 있다.

교육 현장에 있는 우리는 이러한 기술의 허상과 본질을 명확히 구분해야 한다. 화려한 기술적 구조가 곧 학습의 엄밀함이나 효율성을 보장하지는 않는다. 때로는 작은 AI 도구 하나와 교사의 섬세한 개입이, 거대한 자동화 워크플로우보다 훨씬 더 큰 교육적 가치를 만들어낸다.

당신이 만약 AI 에이전트 시스템을 학교나 수업에 적용하려 한다면, 다음 질문을 반드시 던져야 한다. “이 복잡한 워크플로우가 정말 학습 과정의 불확실성에 유연하게 대응할 수 있는가? 내가 중간에 개입하여 방향을 수정하고, 실패를 조기에 감지할 수 있는가? 만약 실패한다면, 그 비용은 얼마나 감당할 수 있는가?”

출처

• 카카오 FDE 황민호님 (메타 하네스: https://github.com/revfactory/harness)