며칠은 붙잡고 있어야 할 리팩토링, 코드베이스 구석구석에 숨은 버그 잡기. 이런 일을 클로드가 에이전트 수십 개를 한꺼번에 풀어서, 서로 검증까지 해가며 몇 분 만에 끝내버립니다.
열심히 코드 짜다가 토큰이 오링 나서 작업이 뚝 끊기고, 한참 멍하니 손가락만 빨아본 적 있으시죠. 큰 작업일수록 더 그렇고요. 오늘 소개할 기능이 바로 그 지점을 건드립니다. 이름은 다이나믹 워크플로우(Dynamic Workflow)예요.
저도 처음엔 "또 에이전트 여러 개 돌리는 건가" 하고 넘겼습니다. 그런데 며칠 써보니 생각이 확 바뀌었어요. 단순한 기능 하나가 아니라, 클로드 코드가 어디로 가고 있는지를 보여주는 신호였거든요. 오늘은 이게 뭔지, 어떻게 쓰는지, 그리고 왜 큰 흐름의 신호인지를 처음부터 끝까지 정리해보겠습니다.
크게 세 덩어리예요. 첫째, '하네스'가 뭔지. 둘째, 다이나믹 워크플로우가 정확히 뭐고 어떻게 쓰는지. 셋째, 이 기능이 왜 "클로드 코드가 거대한 하네스가 되는 중"이라는 신호인지. 사실 세 번째가 오늘 진짜 하고 싶은 이야기입니다.
하네스(Harness)가 뭐였냐면요
먼저 '하네스'부터 짚을게요. 이 단어를 모르면 오늘 이야기가 안 풀리거든요.
예전에 클로드 코드나 커서 같은 AI 코딩 도구를 쓸 때, 도구 자체는 그냥 똑똑한 신입 직원 한 명이었습니다. 일은 잘하는데, 혼자서 큰 프로젝트를 통째로 굴리기엔 좀 버거운 거죠.
그래서 사람들은 그 위에 자꾸 뭔가를 붙였어요. 플러그인 붙이고, 스킬 붙이고, 외부 오케스트레이션 툴 붙이고. 여러 에이전트를 줄 세워 한꺼번에 돌리는 별도 프레임워크도 정말 많이 나왔습니다.
이렇게 를 하네스라고 불렀습니다. 똑똑한 신입 한 명에게 매니저를 붙이고, 결재 라인을 만들고, 매뉴얼을 쥐여주는 관리 체계 전체라고 보시면 됩니다.
그런데 요즘 강하게 느끼는 흐름이 하나 있어요. 바깥에 붙이던 그것들이 하나둘씩 클로드 코드 안으로 빨려 들어오고 있다는 겁니다. 오늘 이 이야기를 계속할 거예요.
다이나믹 워크플로우가 뭐냐면요
이제 오늘의 주인공을 제대로 보겠습니다.
다이나믹 워크플로우는, 클로드가 자바스크립트 스크립트를 하나 쓰는 데서 출발합니다. 그 스크립트가 수십, 수백 개의 하위 에이전트를 지휘하는 '지휘서' 역할을 해요. 그리고 이 스크립트를 별도의 런타임이 백그라운드에서 알아서 돌려줍니다.
여기서 백그라운드라는 게 중요합니다. 워크플로우가 뒤에서 돌아가는 동안, 우리는 클로드 코드로 다른 작업을 계속할 수 있거든요.
쉽게 말해, 예전엔 우리가 바깥에서 직접 짜던 그 '에이전트 줄 세우기' 코드를 이제는 클로드가 직접 써서 자기 안에서 돌리는 겁니다. 바깥일이 안쪽일이 된 거죠.
핵심은, 누가 '계획'을 들고 있느냐예요
여기에 진짜 중요한 차이가 하나 있습니다. 다른 건 다 잊어도 이거 하나는 가져가셔도 돼요.
기존에 에이전트를 여러 개 돌리거나 스킬을 쓸 때, 계획을 들고 있던 건 클로드 본인이었습니다. 매 턴마다 "음, 다음엔 뭘 시키지?" 하고 그때그때 머릿속으로 정했거든요.
그런데 워크플로우는 그 계획을 아예 코드 안에 박아넣습니다. 반복문이든 분기든 중간 결과든, 전부 스크립트가 들고 있어요. 클로드 머릿속이 아니라요. 매니저가 머릿속으로 기억하던 진행 순서를 아예 매뉴얼로 박아둔 셈입니다. 까먹어도 매뉴얼만 보면 다음에 뭘 할지 정확히 나와 있죠.
그래서 좋은 점이 하나 더 생깁니다. 중간에 멈춰도 이어서 할 수 있어요. 이미 끝난 에이전트는 저장된 결과를 그대로 쓰고, 안 끝난 것만 다시 돌립니다. 단, 같은 세션 안에서만요. 클로드 코드를 완전히 껐다 켜면 처음부터 다시 시작합니다. 이 점은 기억해두세요.
그래서 이게 왜 좋냐면요
계획을 코드에 박아넣는 게 왜 그렇게 좋은지, 두 가지로 풀어드릴게요.
첫째, 기억력 문제입니다. AI 에이전트는 적을 수 있는 공간이 정해져 있어서, 일이 길어지면 앞에 적은 게 지워집니다. 이걸 '컨텍스트 윈도우'라고 불러요. 기존 방식대로 에이전트 50개를 돌리면 그 50개 결과가 전부 클로드에게 와르르 쌓여서 금방 꽉 찼습니다. 반면 워크플로우는 중간 결과를 '스크립트 변수'에 담아두기 때문에, 최종 답 하나만 깔끔하게 올라옵니다. 클로드 머릿속이 더러워지지 않는 거죠.
둘째, 품질입니다. 이 부분이 좀 멋있는데요. 워크플로우는 에이전트끼리 서로 검사를 시킬 수 있습니다. 한 에이전트가 "이거 버그예요" 하고 찾아오면, 다른 에이전트가 "진짜 맞아? 내가 반박해볼게" 하고 따져보게 만드는 거예요. 혼자 만들고 혼자 검사하는 것보다 훨씬 믿을 만하죠. 그러니까 단순히 에이전트를 많이 돌리는 게 아니라, 더 정확한 답을 만들어내는 구조라는 게 핵심입니다.
그럼 직접 어떻게 쓰냐면요
말로만 하면 와닿지 않으니 실제 사용법을 보겠습니다.
가장 쉬운 건 클로드 코드에 기본으로 들어 있는 /deep-research예요. 질문 하나 던지면, 클로드가 웹 검색을 여러 각도로 쫙 펼친 뒤 찾은 자료들을 서로 교차 검증합니다. 한 자료가 맞다고 한 걸 다른 자료들과 대조하는 거죠. 마지막엔 검증을 통과하지 못한 주장을 싹 걸러내고, 출처까지 단 보고서 하나를 줍니다. 턴마다 주절주절 보고하는 게 아니라 결과 하나로 깔끔하게요.
내 작업에 맞는 워크플로우를 만들고 싶다면 방법이 정말 간단합니다. 프롬프트에 "워크플로우(workflow)"라는 단어를 넣으면 돼요. 예를 들어 "src 폴더 밑 모든 API 엔드포인트에 인증 빠진 데 없는지 워크플로우로 점검해줘" 이렇게요. 그럼 클로드가 알아서 스크립트를 짜고, 실행해도 되냐고 한 번 물어봅니다.
진행 상황을 보고 싶으면 /workflows를 칩니다. 단계마다 에이전트가 몇 개 돌고 있는지, 토큰을 얼마 썼는지, 시간이 얼마 지났는지 다 보여줘요.
한번 마음에 들게 돌아간 워크플로우는 저장할 수 있습니다. 그 화면에서 s키를 누르면 나만의 슬래시 명령어로 박제돼요. 다음부터는 명령어 하나로 똑같은 작업이 돌아갑니다. 매번 브랜치 올릴 때마다 똑같은 리뷰를 돌린다거나 할 때 진짜 편해요.
설정 팁도 하나 있습니다. /effort ultracode를 켜두면, 내가 "워크플로우"라고 말하지 않아도 클로드가 알아서 "이건 워크플로우 쓸 만한 일이네" 하고 판단해서 짜줍니다. 좀 큰 작업 위주로 할 때 켜두면 편한 모드예요.
이게 무슨 신호냐면요
여기서부터가 오늘 진짜 하고 싶었던 이야기입니다.
저는 이 다이나믹 워크플로우를 보면서 큰 흐름 하나를 읽었어요. 앞에서 했던 하네스 이야기로 돌아가 봅시다.
생각해보세요. 여러 에이전트를 병렬로 돌리는 거, 원래 바깥에서 별도 프레임워크로 하던 일이었습니다. 백그라운드에서 작업을 돌려놓고 세션은 따로 쓰는 거, 그것도 바깥 도구가 하던 일이었고요. 결과를 교차 검증해서 품질을 올리는 거, 그것도 사람들이 직접 파이프라인을 짜서 손으로 만들던 거였습니다.
이게 전부 다 지금 클로드 코드 안으로 쏙 들어왔습니다. 바깥에 덕지덕지 붙이던 하네스가 본체 안으로 흡수되고 있는 거예요.
비유하자면 스마트폰 초창기와 똑같습니다. 처음엔 손전등 앱, 녹음 앱, QR 앱을 따로따로 깔았잖아요. 지금은요? 다 기본 기능으로 들어와 있어서 굳이 따로 안 깝니다. 클로드 코드도 지금 정확히 그 길을 가고 있어요. 바깥 앱들이 본체 기능이 되는 길이요.
그래서 저는 앞으로 흐름이 이렇게 갈 거라고 봅니다. 외부 기능을 잔뜩 붙여 쓰는 방식보다, 순정 클로드 코드 위주로 쓰는 게 점점 자연스러워질 거예요. 어쩌면 거의 강제되는 흐름이 올 수도 있고요. 본체가 이미 다 품고 있는데, 굳이 바깥 걸 또 붙일 이유가 줄어드니까요.
한 명에서 여러 명으로
또 하나 큰 흐름이 있습니다. 일하는 방식 자체가 바뀌고 있어요.
예전엔 에이전트 한 명에게 일을 시키고 끝날 때까지 기다렸습니다. 한 명짜리 작업이었죠. 이제는 여러 명을 동시에 풀어놓고 일을 끝내는 방식으로 넘어가고 있어요.
다이나믹 워크플로우는 그 흐름의 가장 또렷한 신호입니다. 숫자로 보면 확 와닿아요. 한 번에 최대 16개씩 에이전트가 동시에 돌고, 한 작업에 최대 1,000개까지 에이전트를 굴릴 수 있습니다. 천 개요.
여기에 오퍼스(Opus) 같은 강력한 모델이 지휘자로 앉으면 꽤 무서운 조합이 됩니다. 똑똑한 한 명이 머리 싸매고 다 하는 게 아니라, 똑똑한 한 명이 똑똑한 여러 명을 지휘하는 구조로 바뀌는 거예요. 실력 좋은 목수가 혼자 집 짓던 데서, 현장 소장이 되어 목수 수십 명을 감독하는 걸로 바뀐 거죠. 같은 시간에 훨씬 큰 집을 짓고요. 일의 규모 자체가 달라지는 겁니다.
근데 공짜는 아니에요
좋은 얘기만 할 순 없죠. 직접 써보고 느낀 단점도 솔직하게 짚겠습니다.
일단 토큰을 진짜 무지막지하게 먹어요. 이건 각오하셔야 합니다. 에이전트를 수십, 수백 개 돌리니까 같은 작업을 그냥 대화로 푸는 것보다 몇 배는 더 씁니다. 아무 작업에나 막 갖다 쓰면 통장 잔고 녹는 소리가 들려요.
그리고 솔직히 모든 일에 다 잘하는 건 아니더라고요. 호불호가 좀 갈립니다.
별로였던 쪽부터요. 리서치나 계획 짜기, 자료 조사는 기대보다 별로였어요. 토큰은 토큰대로 무지막지하게 먹는데 결과물이 그 값을 못 하는 느낌이었습니다. 여러 에이전트가 제각각 찾아온 걸 합치다 보니, 깊이 있게 파고들기보다 넓게 훑고 마는 느낌이랄까요. 차라리 한 대화로 차근차근 시키는 게 나을 때도 많았어요.
그런데 여기서부터가 반전입니다. 코드 쪽 일은 진짜 잘해요. 특히 리팩토링과 버그 픽스. 이건 감탄했습니다. 코드베이스 전체에 흩어진 버그를 한꺼번에 잡아낸다거나, 똑같은 패턴을 수백 군데에서 싹 갈아엎는 리팩토링이라거나. 에이전트들이 동시에 달라붙어 서로 검증까지 해주니, 사람 혼자 며칠 걸릴 일을 뚝딱 해냅니다. 여기선 토큰값이 아깝지 않아요.
정리하면, 리서치·조사 쪽은 아껴 쓰고, 리팩토링·버그 픽스 같은 큰 코드 작업에 꺼내 쓰는 게 진짜 제값을 합니다.
마지막으로, 아직 리서치 프리뷰 단계라는 점도 알아두세요. 완성된 기능이 아니라는 뜻입니다. 유료 플랜에서 설정을 켜야 쓸 수 있고요. 작업 중간에 사람이 끼어들어 "잠깐, 이건 이렇게 해" 하고 입력하는 건 안 됩니다. 단계별로 사람 승인을 받고 싶다면 각 단계를 따로따로 워크플로우로 쪼개야 해요. 이런 제약을 알고 쓰셔야 덜 당황합니다.
이렇게 시작해보세요
처음 써보시는 분들을 위해 단계별로 정리했습니다. 이대로만 따라 하시면 돼요.
1단계. 일단 가볍게 /deep-research부터 써보세요. 평소 궁금했던 거 아무거나요. "노드 20이랑 22 사이에 뭐가 바뀌었어?" 같은 거요. 워크플로우가 어떻게 돌아가는지 감을 잡는 게 먼저입니다.
2단계./workflows 화면을 열어 에이전트들이 단계별로 일하는 걸 눈으로 직접 보세요. 어떤 에이전트가 뭘 찾았는지 하나씩 눌러볼 수 있어요. 이걸 보면 "아, 이렇게 일을 나눠서 하는구나" 하고 확 이해됩니다.
3단계. 이제 내 프로젝트에 적용해보세요. 평소 손으로 하던 반복 작업 중 규모가 큰 걸 하나 골라, 프롬프트에 "워크플로우"라는 단어를 넣어 시켜봅니다. 클로드가 짜준 스크립트를 한번 읽어보고 실행을 허락하면 돼요.
4단계. 잘 돌아간 워크플로우는 s 키로 저장하세요. 그럼 내 전용 도구가 하나 생깁니다. 이렇게 하나둘 모으다 보면 나만의 작업 자동화 세트가 만들어져요. 단, 시작 전에 모델이 뭔지 한 번 확인하세요. 큰 작업은 토큰을 많이 쓰니까요.
마치며
제가 이 기능을 계속 들여다보는 이유가 여기 있습니다. 결국엔 클로드 코드 자체가 거대한 하나의 하네스가 되는 거예요. 바깥 껍데기가 필요 없는, 그 자체로 완성된 작업 환경이요.
여러분은 어떻게 보세요? 외부 도구를 붙여 쓰는 쪽이 더 편한가요, 아니면 순정으로 가는 게 맞다고 보시나요? 이 레터에 답장으로 의견 들려주시면 다음 레터에서 같이 읽어볼게요. 진짜 궁금합니다.
워크플로우 실전 세팅이나 토큰 덜 쓰면서 영리하게 굴리는 노하우 같은 건 따로 더 깊게 나누고 있어요. 혼자 헤매지 마시고, 관심 있으면 아래 링크로 들어오세요.
그리고 솔직히 고백하면, 저도 이 워크플로우 기능을 아직 다 파악한 건 아닙니다. 쓰면서 계속 새로 알아가는 중이에요. 그래서 다음 레터에서는 이 워크플로우를 실제로 하나 제대로 만들어, 제 프로젝트에 처음부터 끝까지 돌려보는 과정을 통째로 보여드릴게요. 잘 되든 안 되든 솔직하게요.
