오늘의 AI 글: Claude Code 동적 워크플로가 보여준 에이전트 오케스트레이션의 다음 단계

왜 이 글인가

오늘 고른 글은 Claude Code의 dynamic workflows를 단순한 새 기능 소개가 아니라, AI 코딩 에이전트가 어디로 이동하고 있는지를 보여주는 신호로 읽는다. 지금까지 코딩 에이전트의 핵심 경험은 대체로 “대화형 작업”이었다. 사용자가 목표를 말하면 에이전트가 파일을 읽고, 변경하고, 테스트하고, 다시 수정한다. 이 방식만으로도 충분히 강력하지만, 작업이 커질수록 병목이 분명해진다. 하나의 에이전트가 모든 맥락을 들고 순서대로 처리하면 긴 작업에서는 컨텍스트가 비대해지고, 탐색 폭은 좁아지며, 사용자는 중간 판단을 계속 감시해야 한다.

Medium 원문이 주목한 dynamic workflows는 이 병목을 “더 긴 대화”가 아니라 “오케스트레이션”으로 풀려는 시도다. 사용자가 큰 작업을 설명하면 Claude Code가 JavaScript 기반의 워크플로 스크립트를 만들고, 그 스크립트가 수십에서 수백 개의 하위 에이전트를 조율한다. 각 에이전트는 작은 문제를 맡고, 서로의 결과를 검토하거나 비교하며, 사용자는 중간의 세부 실행을 모두 보지 않고 최종 산출물을 받는다. 말하자면 AI 코딩이 한 명의 똑똑한 페어 프로그래머에서, 작업을 쪼개고 검증하는 작은 에이전트 조직으로 확장되는 장면이다.

이 글이 오늘 읽을 가치가 큰 이유는 숫자가 꽤 강렬하기 때문이다. 원문은 Anthropic 발표를 인용해 Bun 런타임을 Zig에서 Rust로 이식한 사례를 언급한다. 약 75만 줄의 Rust 코드, 기존 테스트 스위트 99.8% 통과, 첫 커밋부터 병합까지 11일이라는 결과다. 이런 수치는 과장 광고처럼 보일 위험도 있지만, 동시에 개발팀이 앞으로 어떤 종류의 일을 AI에게 맡기게 될지 상상하게 만든다. 작은 함수 작성이나 테스트 보강이 아니라, 언어 포팅, 대규모 마이그레이션, 반복 검토, 병렬 리뷰처럼 과거에는 팀 단위로만 가능했던 작업이 에이전트 워크플로의 대상이 되고 있다.

또 하나 중요한 점은 원문이 Claude Code만 칭찬하는 글로 끝나지 않는다는 것이다. Cursor의 /multitask, GitHub Copilot의 /fleet, OpenAI Codex의 병렬 서브에이전트처럼 주요 도구들이 모두 비슷한 방향으로 움직이고 있다고 본다. 차이는 “여러 에이전트를 띄운다”가 아니라, 그 에이전트들을 얼마나 재사용 가능하고 검증 가능한 절차로 묶느냐에 있다. 따라서 이 글의 핵심 질문은 특정 도구 순위가 아니다. 앞으로 개발자는 AI에게 코드를 맡기는 사람이 아니라, AI 작업을 설계하고 감시하고 통합하는 운영자가 되어야 하는가라는 질문에 가깝다.

접근 측면에서는 공개 웹 fetch로 원문의 제목, 부제, 도입부, 핵심 사례와 일부 비교 구도까지 확인할 수 있었지만, 전문 전체는 제한적으로만 확인됐다. 아래 해설은 공개적으로 확인 가능한 원문 내용과 Anthropic 발표의 공개 메타데이터, 그리고 Claude Code·Codex·Cursor·Copilot 계열 에이전트 운영에 대한 일반적인 실무 관점을 바탕으로 재구성했다. 원문 문장을 길게 옮기지 않고, “동적 워크플로는 병렬 에이전트를 재사용 가능한 오케스트레이션으로 바꾼다”는 논지를 한국어로 풀어낸다.

핵심 요약

• 원문이 말하는 dynamic workflows의 핵심은 사용자가 직접 모든 단계를 지시하지 않아도 Claude Code가 작업용 스크립트를 생성하고, 그 스크립트가 여러 하위 에이전트를 조율한다는 점이다. 기존 대화형 에이전트가 한 흐름 안에서 읽고 고치고 테스트했다면, dynamic workflows는 큰 작업을 여러 하위 작업으로 쪼개 동시에 실행하고 결과를 다시 모으는 방식에 가깝다.

• 이 기능이 흥미로운 이유는 “병렬 실행” 자체보다 “워크플로가 코드로 남는다”는 데 있다. 사람이 매번 프롬프트로 같은 절차를 설명하는 대신, 에이전트가 만든 JavaScript 오케스트레이션이 반복 가능한 작업 절차가 될 수 있다. 조직 입장에서는 잘 만든 워크플로를 마이그레이션, 리뷰, 테스트 생성, API 변경, 문서 업데이트 같은 반복 작업에 다시 적용할 여지가 생긴다.

• Bun의 Zig-to-Rust 포팅 사례는 상징적이다. 약 75만 줄 규모, 99.8% 테스트 통과, 11일이라는 수치는 단순 자동완성이나 작은 리팩터링의 범위를 넘어선다. 물론 이런 사례가 모든 팀에서 그대로 재현된다는 뜻은 아니다. Bun처럼 테스트가 촘촘하고 목표가 명확한 프로젝트, 그리고 결과를 검토할 수 있는 숙련된 인간 운영자가 있을 때 의미 있는 성공 사례가 된다.

• 원문은 Claude Code의 dynamic workflows를 Cursor, Copilot, Codex의 병렬 에이전트 기능과 같은 흐름 위에 놓는다. 이제 경쟁의 축은 “어느 모델이 한 번에 더 좋은 코드를 쓰는가”에서 “어느 도구가 많은 에이전트의 작업을 안전하게 분배하고 검증하고 통합하는가”로 이동하고 있다. 모델 성능은 여전히 중요하지만, 운영 레이어가 점점 더 중요해진다.

• 개발자에게 중요한 변화는 프롬프트 작성 능력보다 작업 분해 능력이다. 큰 작업을 작은 단위로 나누고, 각 단위의 입력과 출력, 성공 기준, 검증 방법을 정하는 능력이 생산성을 좌우한다. AI가 코드를 쓰는 속도가 빨라질수록, 무엇을 동시에 실행해도 안전한지 판단하는 사람이 더 중요해진다.

• dynamic workflows는 에이전트에게 “많이 시키는” 기능이 아니라 “절차를 맡기는” 기능으로 이해해야 한다. 무작정 수백 개의 서브에이전트를 띄우면 비용과 혼란이 커진다. 좋은 워크플로는 각 에이전트가 좁은 범위를 맡고, 결과가 비교 가능하며, 마지막 통합 단계에서 버릴 것과 채택할 것을 구분할 수 있어야 한다.

• 이 흐름은 코드 리뷰의 의미도 바꾼다. 사람이 모든 라인을 직접 쓰지 않는다면, 리뷰는 구현자의 의도를 확인하는 절차에서 생성된 변경의 근거, 테스트 커버리지, 실패 가능성, 되돌리기 전략을 점검하는 절차로 이동한다. 에이전트가 만든 대규모 diff일수록 리뷰는 더 체계적이어야 한다.

• 원문의 실용적 메시지는 “Claude Code가 최고다”보다는 “AI 코딩의 다음 병목은 오케스트레이션이다”에 가깝다. 단일 에이전트의 성능 경쟁은 계속되겠지만, 실제 팀 생산성은 작업 분해, 격리, 검증, 재사용 가능한 워크플로를 얼마나 잘 설계하느냐에 달릴 가능성이 크다.

• OpenAI Codex 관점에서도 이 글은 참고할 만하다. Codex가 병렬 서브에이전트나 백그라운드 작업을 잘 지원하더라도, 사용자가 작업을 명확히 나누지 못하면 결과는 쉽게 산만해진다. 반대로 Claude Code의 dynamic workflows가 강력해도 테스트와 리뷰 기준이 약하면 위험한 자동화가 된다. 결국 도구보다 운영 습관이 승패를 가른다.

원문의 논지를 단계별로 풀어보기

첫 번째 단계는 기존 AI 코딩 경험의 한계를 보는 것이다. 하나의 에이전트에게 “이 기능을 구현해줘”라고 맡기면, 에이전트는 저장소를 탐색하고 관련 파일을 찾고 코드를 수정하고 테스트를 실행한다. 작은 작업에서는 이 흐름이 매우 효율적이다. 하지만 큰 마이그레이션이나 프레임워크 전환, 언어 포팅처럼 작업 범위가 넓어지면 한 세션이 모든 것을 순차적으로 처리하는 방식은 비효율적이다. 에이전트는 너무 많은 맥락을 들고 있어야 하고, 한 번의 잘못된 가정이 넓은 영역으로 퍼질 수 있다.

두 번째 단계는 병렬화의 필요성이다. 인간 개발팀이 큰 프로젝트를 나눠 맡듯이, 에이전트도 큰 작업을 여러 작은 작업으로 나눠 맡을 수 있다. 예를 들어 한 에이전트는 타입 변환 규칙을 찾고, 다른 에이전트는 테스트 실패를 분류하고, 또 다른 에이전트는 특정 디렉터리만 마이그레이션한다. 이렇게 하면 탐색과 실행을 동시에 진행할 수 있다. 단일 세션의 긴 대화보다, 좁은 목표를 가진 여러 세션이 더 빠르고 명확할 때가 있다.

세 번째 단계는 “병렬화만으로는 부족하다”는 깨달음이다. 여러 에이전트를 동시에 띄우면 속도는 빨라질 수 있지만, 조율이 없으면 결과가 충돌한다. 두 에이전트가 같은 파일을 다른 방식으로 고치거나, 서로 다른 규칙으로 변환하거나, 같은 테스트 실패를 서로 다른 원인으로 해석할 수 있다. 따라서 병렬 에이전트 운영에는 분배, 격리, 중간 검토, 결과 통합이 필요하다. 이것이 dynamic workflows가 단순한 멀티태스킹 기능보다 흥미로운 지점이다.

네 번째 단계는 워크플로를 코드로 표현하는 것이다. Claude Code가 JavaScript 오케스트레이션 스크립트를 만든다는 점은 작지 않은 차이다. 프롬프트는 대화 안에서 흩어지기 쉽고, 재현하기 어렵고, 어떤 단계가 실제로 실행됐는지 추적하기 어렵다. 반면 워크플로가 코드 형태를 가지면 절차를 읽고 수정하고 재사용할 수 있다. 물론 그 코드 자체도 검토 대상이 되어야 하지만, 적어도 작업 방식이 “감”이 아니라 명시적인 실행 계획으로 이동한다.

다섯 번째 단계는 하위 에이전트 간 검증이다. 원문 도입부는 dynamic workflows가 여러 서브에이전트를 조율하고, 서로의 작업을 확인하게 만들 수 있다고 설명한다. 이 부분이 중요하다. AI가 만든 결과를 AI가 다시 검토한다고 해서 자동으로 안전해지는 것은 아니지만, 독립적인 시도와 비교는 오류를 줄이는 데 도움이 된다. 특히 대규모 변환 작업에서는 한 에이전트가 만든 규칙을 다른 에이전트가 샘플 파일에 적용해보거나, 리뷰 에이전트가 변환 후 테스트 실패를 분류하는 방식이 유용하다.

여섯 번째 단계는 대표 사례의 의미를 해석하는 것이다. Bun의 Zig-to-Rust 포팅 사례는 “AI가 이제 모든 대규모 포팅을 알아서 해준다”는 결론으로 읽으면 위험하다. 더 현실적인 해석은, 테스트가 잘 갖춰진 코드베이스와 명확한 목표, 그리고 강한 인간 리뷰가 있을 때 에이전트 오케스트레이션이 반복적이고 방대한 변환 작업을 크게 가속할 수 있다는 것이다. 즉 성공의 주인공은 모델 하나가 아니라, 목표·테스트·워크플로·검토 체계의 조합이다.

일곱 번째 단계는 다른 도구들과의 비교다. Cursor의 멀티태스크, Copilot의 fleet, Codex의 병렬 작업은 모두 같은 문제를 겨냥한다. 개발자는 더 이상 한 채팅창에서만 AI를 쓰지 않는다. 여러 작업을 동시에 맡기고, 백그라운드에서 진행시키고, 결과를 비교해 선택하려 한다. 따라서 앞으로의 도구 경쟁은 IDE 통합, 터미널 통합, GitHub 통합 같은 표면 차이를 넘어, 병렬 작업의 관측 가능성, 비용 통제, 권한 관리, 리뷰 경험으로 확장될 것이다.

여덟 번째 단계는 인간 역할의 변화다. dynamic workflows가 강력해질수록 개발자는 모든 코드를 직접 쓰는 사람에서 작업 시스템을 설계하는 사람으로 이동한다. 좋은 개발자는 “이 함수를 이렇게 고쳐”보다 “이 마이그레이션은 어떤 단위로 쪼개야 하고, 어떤 검증을 통과해야 하며, 어느 지점에서 사람이 승인해야 하는가”를 잘 정한다. 이것은 코딩 능력이 덜 중요해진다는 뜻이 아니다. 오히려 코드를 이해하지 못하면 워크플로가 만든 결과를 검증할 수 없다.

아홉 번째 단계는 리스크 관리다. 에이전트가 수십 개의 작업을 동시에 수행하면 잘못된 지시의 피해도 커진다. 잘못된 규칙 하나가 수백 파일에 적용될 수 있고, 테스트가 부족한 영역에서는 그럴듯하지만 틀린 코드가 대량으로 생길 수 있다. 따라서 dynamic workflows를 실무에 적용하려면 권한 범위, 파일 범위, 최대 변경량, 중간 체크포인트, 되돌리기 전략을 미리 정해야 한다. 빠른 도구일수록 브레이크가 좋아야 한다.

열 번째 단계는 재사용 가능한 운영 지식이다. 좋은 워크플로는 한 번 쓰고 버리는 스크립트가 아니라 팀의 작업 자산이 될 수 있다. 예를 들어 “API 응답 타입 변경 워크플로”, “테스트 실패 분류 워크플로”, “레거시 컴포넌트 마이그레이션 워크플로”, “릴리스 전 문서·예제 동기화 워크플로”처럼 반복 가능한 패턴을 만들 수 있다. 원문이 말하는 변화의 핵심도 여기에 있다. AI 코딩은 점점 개인의 프롬프트 묘기에서 팀의 작업 운영 체계로 이동하고 있다.

일반 독자에게 중요한 포인트

• AI 코딩 도구는 이제 단순히 “코드를 대신 써주는 도구”를 넘어 “작업을 나누고 조율하는 도구”가 되고 있다. 이것은 개발 생산성의 중심이 개인의 속도에서 작업 시스템의 설계로 이동한다는 뜻이다.

• 대규모 자동화 사례는 인상적이지만 그대로 복제 가능한 마법은 아니다. Bun 사례가 의미 있으려면 기존 테스트 스위트, 명확한 목표, 결과를 판별할 수 있는 사람이 함께 있었다는 점을 봐야 한다. AI가 빨라질수록 검증 기반이 더 중요해진다.

• 여러 AI를 동시에 쓰는 것은 여러 사람을 동시에 고용하는 것과 비슷하다. 역할이 명확하면 빠르지만, 목표가 흐리면 혼란이 커진다. “많이 실행하기”보다 “잘 나누기”가 핵심이다.

• 워크플로가 코드로 남는다는 점은 투명성과 재사용성 측면에서 중요하다. 좋은 절차는 반복할 수 있고, 나쁜 절차는 수정할 수 있다. 대화창 안에서 사라지는 프롬프트보다 팀이 함께 검토할 수 있는 워크플로가 더 안전한 운영 단위가 될 수 있다.

• AI가 만든 결과를 AI가 검토하는 구조는 도움이 될 수 있지만, 최종 책임을 대체하지는 않는다. 독립 검토 에이전트는 오류를 줄이는 보조 장치이지, 제품 품질에 대한 인간의 판단을 없애는 장치가 아니다.

• 앞으로 좋은 개발팀은 “어떤 모델을 쓰는가”뿐 아니라 “어떤 작업은 자동화해도 되고, 어떤 작업은 반드시 사람이 승인해야 하는가”를 문서화할 것이다. 모델 선택보다 운영 규칙이 더 오래 남는 경쟁력이 될 수 있다.

적용 아이디어

• 먼저 반복되는 대형 작업을 하나 고른다. 예를 들어 타입 마이그레이션, 테스트 보강, 문서 동기화, API 클라이언트 갱신처럼 패턴이 분명하고 검증 기준이 있는 일을 선택한다. dynamic workflow류 기능은 모호한 창작 작업보다 반복 구조가 있는 작업에서 효과를 보기 쉽다.

• 작업을 “탐색”, “변환”, “검증”, “리뷰”, “통합” 단계로 나눈다. 한 에이전트가 모든 것을 하게 하기보다 각 단계의 산출물을 분명히 둔다. 탐색 단계는 규칙과 위험 목록을 만들고, 변환 단계는 제한된 범위의 diff를 만들고, 검증 단계는 테스트와 타입체크 결과를 정리하게 한다.

• 에이전트별 파일 범위를 제한한다. 예를 들어 src/api/**만 수정 가능, tests/**는 추가만 가능, 설정 파일은 건드리지 말 것처럼 경계를 둔다. 병렬 에이전트 운영에서 가장 흔한 실패는 목표보다 변경 범위가 넓어지는 것이다.

• 중간 체크포인트를 둔다. 100개 파일을 바꾼 뒤 한 번에 리뷰하지 말고, 5개 샘플 파일 변환 후 규칙 검토, 20개 파일 변환 후 테스트 실행, 전체 적용 전 사람 승인 같은 단계를 둔다. 자동화가 빠를수록 작은 단위로 멈출 수 있어야 한다.

• 결과 비교 방식을 정한다. 여러 에이전트가 같은 문제를 다른 방식으로 풀었다면, 단순히 먼저 끝난 결과를 채택하지 말고 diff 크기, 테스트 결과, 유지보수성, 롤백 난이도, 기존 스타일과의 일관성을 기준으로 비교한다.

• 워크플로 자체를 버전 관리한다. Claude Code든 Codex든 Cursor든 반복 가능한 에이전트 절차를 만들었다면 저장소의 문서나 스크립트로 남긴다. 프롬프트, 파일 범위, 검증 명령, 금지 사항, 종료 조건을 함께 기록하면 다음 작업의 품질이 올라간다.

• 비용과 시간 예산을 정한다. 수십 개의 서브에이전트를 실행하는 방식은 강력하지만 토큰 비용과 실행 시간이 커질 수 있다. “최대 N개 파일”, “최대 N회 재시도”, “테스트 실패가 같은 원인으로 2회 반복되면 중단” 같은 한계를 두는 편이 안전하다.

• 최종 통합자는 반드시 지정한다. 사람이 직접 하든 메인 에이전트가 보조하든, 여러 결과를 합칠 책임자가 필요하다. 병렬 작업의 성패는 각 에이전트가 얼마나 열심히 했는지보다, 마지막에 무엇을 채택하고 무엇을 버렸는지에 달려 있다.

읽기 우선순위

이 글은 Claude Code를 이미 쓰고 있거나, Codex·Cursor·Copilot 같은 코딩 에이전트를 업무에 붙이기 시작한 개발자라면 우선순위가 높다. 특히 “에이전트가 작은 일은 잘하는데 큰 작업에서는 산만해진다”고 느꼈다면 원문을 읽을 만하다. dynamic workflows는 그 문제를 해결하는 한 가지 방향, 즉 큰 일을 더 긴 프롬프트로 밀어붙이는 대신 작은 에이전트와 검증 절차로 쪼개는 방향을 보여준다.

반대로 아직 AI 코딩 도구를 가볍게 자동완성이나 짧은 함수 작성 정도로만 쓰는 독자라면, 원문 전체보다 위의 적용 아이디어를 먼저 보는 편이 낫다. 핵심은 특정 기능 이름이 아니라 작업을 나누고, 파일 범위를 제한하고, 검증 루틴을 세우는 습관이다. 원문은 그 습관이 앞으로 도구 차원에서 어떻게 제품화될지 보여주는 좋은 사례다.

원문을 읽을 때는 Bun 사례의 숫자에만 끌려가지 않는 것을 추천한다. 더 중요한 질문은 “우리 팀의 반복 작업 중 워크플로로 만들 수 있는 것은 무엇인가”, “어떤 검증이 있어야 에이전트 결과를 믿을 수 있는가”, “병렬 실행이 오히려 위험해지는 경계는 어디인가”다. 이 질문에 답할 수 있다면 dynamic workflows는 단순한 신기능이 아니라, AI 시대의 개발 운영 방식을 설계하는 힌트가 된다.