Anthropic의 동적 워크플로우를 활용한 Claude 에이전트 조정 방법

AI Engineer New York에서 Anthropic은 Unix와 Linux로부터 얻은 교훈을 바탕으로, 개발자들에게 과부하를 주지 않으면서 에이전트들이 더 큰 프로젝트를 수행할 수 있는 방법을 설명했습니다.

CJ Avilla와 Harrison Stall(Anthropic의 Members of Technical Staff)이 AI Engineer NYC에서 발표했습니다.

AI Engineer New York 2026 컨퍼런스는 오늘 아침 일련의 워크숍으로 시작되었으며, Anthropic은 Claude Managed Agents를 어떻게 오케스트레이션하는지 논의했습니다. 특히 금요일에 발표된 '동적 워크플로우(dynamic workflows)'—발표자들이 반복적으로 'flows'라고 부른—라는 완전히 새로운 기능이 큰 관심을 받았습니다.

Flows는 “가장 야심 찬 워크로드(workloads)를 위해 구축된 새로운 유형의 다중 에이전트 오케스트레이션”으로 정의됩니다.

Anthropic의 Members of Technical Staff인 CJ Avilla와 Harrison Stall은 과거 운영 체제 프로젝트들, 즉 Ken Thompson이 최초의 Unix 운영 체제를 만들었던 것부터 Linus Torvalds 한 사람으로부터 시작하여 여러 신뢰할 수 있는 유지 관리자(maintainers)들의 계층으로 발전한 Linux에 이르기까지를 언급하며 논의를 시작했습니다. 그 교훈은 다음과 같습니다: 에이전트들이 Anthropic이 동적 워크플로우를 위해 구상하는 크고 야심찬 프로젝트 유형을 수행하려면 같은 수준의 조직화가 필요하다는 것입니다.

Avilla는 “지금 많은 에이전트를 오케스트레이션하고 관리하는 우리 중 상당수는 너무 많은 PR(Pull Request)을 기여하는 것을 보면서 병목 현상이나 한계점에 도달했다는 느낌을 받기 시작할 수 있습니다”라며, “우리는 GitHub에 앉아 PR을 승인하고 모든 것이 예상대로 작동하는지 확인하려고 애쓰고 있습니다.”라고 말했습니다.

에이전트 로스터에서 동적 워크플로우로

두 사람은 동적 워크플로우가 Claude Code에서 “모든 작업을 위한 하니스(harness)” 개념으로 시작되었다고 언급했습니다. 하지만 flows는 단일 에이전트나 로스터보다 더 오래 실행될 수 있습니다. 기본적인 아이디어는 Claude가 에이전트의 구성을 선택한다는 것입니다.

Stall은 “Flows는 본질적으로 다중 에이전트 오케스트레이션의 다음 버전”이라며, “사용자가 Claude가 자체적인 다중 에이전트 토폴로지 전체를 완전히 오케스트레이션하도록 할 수 있게 해준다”고 말했다.

작동 방식은 선행 에이전트(lead agent)가 작업을 완료하는 방법에 대한 계획을 생성하는 것이다. 그러면 Claude가 오케스트레이션 프로그램(orchestration program)을 작성하여, 에이전트를 실행하고(launches agents), 결과를 수집하며(collects results), 정보 흐름을 관리한다(manages information flow).

이전에 Claude Managed Agents를 사용하려면 개발자가 코디네이터(coordinator)와 서브에이전트 목록(roster of subagents)을 구성해야 했다. 동적 워크플로우(dynamic workflows)를 사용하면, Claude 자체가 작업을 어떻게 분할하고 오케스트레이션할지 결정한다.

Stall은 “다중 에이전트 오케스트레이션의 여러 다른 단계에 걸쳐, 사용자가 이들 간의 연결(interconnections)을 관리할 필요 없이 독립적이고 검증 가능한 작업 단위(discrete, verifiable units of work)를 수행할 수 있다”고 말했다.

그럼에도 불구하고, Avilla는 사용자가 원한다면 전문화된 서브에이전트(specialist sub-agents)를 도입할 수 있다고 언급했다.

“에이전트 설정에서 미리 구성된 서브에이전트를 전달하는 것도 가능하다”고 그는 말했다.

이 모든 것은 Claude Console에서 이용 가능하다. 이는 개발자가 API를 통해 Claude에 접근할 때 사용하는 인터페이스이며, 이것이 바로 Claude Managed Agents의 핵심 목적이다.

발표자들은 이후 주식 관심 목록 스캐너(stock watchlist scanner)라는 비교적 간단한 워크플로우를 보여주었다. 비록 이것이 Anthropic이 장려하는 크고 야심찬 프로젝트와는 거리가 멀었지만, 기본적인 패턴을 잘 보여주었다. 즉, 스캔 단계에서 개별 티커(individual tickers)들을 격리된 컨텍스트(isolated contexts)를 가진 에이전트들에게 분배하고, 나중에 검토 단계에서 발견한 결과들을 검사하여 보고서를 생성하는 방식이었다.

Q&A: 예산 및 자가 개선의 한계
청중과의 질의응답 시간에는 여러 잠재적 문제점들이 제기되었다. 한 청중은 Claude가 작업에 필요한 에이전트 수를 어떻게 결정하는지, 그리고 간단한 티커 스캔이 수백 개의 서브에이전트를 트리거할 수 있는지 질문했다.

Stall은 “정답은 정말로 평가(evals)와 낮은 기본값(lower defaults)입니다”라며, 야심찬 작업들은 일반적으로 명시적으로 더 큰 병렬화(parallelization)를 장려해야 한다고 지적했다.

에이전트 오케스트레이션(agent orchestration)에서 지속적으로 제기되는 우려 사항 중 하나는 토큰 예산(token budget)을 통제하는 것입니다. 누군가 리드 에이전트가 자신이 사용할 수 있는 금액을 알고 있는지 물었습니다.

Stall은 모델이 실행 중에 자신의 예산을 알 수는 없지만, 개발자가 세션 예산(session budget)을 설정할 수 있다고 답했습니다. 그는 모델에게 예산을 알려주는 것이 에이전트를 “조금 불안하게” 만들 수도 있다며 덧붙였고, 이 말에 청중들 사이에서 웃음소리가 터져 나왔습니다.

관련 질문으로는 개발자들이 반복적인 플로우(flow)를 시간이 지남에 따라 어떻게 더 저렴하고 효율적으로 만들 수 있는지에 대한 것이 있었습니다.

Claude에게 발생한 비용을 검토하도록 요청하는 것 외에도, Avilla는 상대적으로 새로운 기능인 드림잉(dreaming)을 사용해 볼 것을 제안했습니다. 문서에서 “드림잉”은 연구 미리보기 기능으로 정의되어 있습니다. 드림은 “기존 메모리 스토어(memory store)와 과거 세션 기록(session transcripts)을 읽은 다음, 중복 항목을 병합하고, ‘오래되었거나 모순되는 항목’을 대체하며, ‘새로운 통찰력’을 표출하는 새로운, 재구성된 메모리 스토어를 생성합니다.”라고 설명됩니다.

Avilla는 플로우 컨텍스트(flow context)에서 드림잉이 해당 세션과 관련된 메모리 스토어를 “결정화하고 기본적으로 개선할 수 있는 것”이라고 설명했습니다.

주식 관심 목록(stock watchlist) 예시의 경우, 누군가 이 관심 목록 플로우가 스스로 개선될 수 있는지 물었습니다. 예를 들어, 자체 스캐닝 모델이 부적절하다는 것을 인식하고 다음 예정된 실행을 변경할 수 있는지에 대한 질문이었습니다.

Stall은 이것이 기본적으로 구현되어 있지는 않지만, 자신과 Avilla는 힐-클라이밍(hill-climbing)과 드림잉을 사용하여 루프를 개선할 수 있다고 제안했습니다.

또 다른 청중 구성원이 하위 에이전트(sub-agents)의 작업에 대한 가시성(visibility)에 대해 질문했습니다.

Avilla는 개발자들이 Claude Console 내부의 그래프 기능(graphing functionality)을 통해 항상 이를 검사할 수 있다고 답했습니다.

“리드 에이전트가 실제로 하위 에이전트에게 무엇을 전달했는지 알 수 있습니다. 이 전체 그래프에서 발생하는 모든 전환에 대해 실제로 무슨 일이 일어나고 있는지 깊이 이해하기 위해 여기에서 페이로드(payload)를 볼 수 있습니다.”

또 다른 흥미로운 질문은 하위 에이전트들이 서로 통신할 수 있는지 여부였습니다.

Stall은 에이전트들이 파일 시스템을 공유하며 이를 통해 정보를 교환할 수 있지만, 개발자가 API를 통해 한 워크플로우 서브에이전트가 다른 서브에이전트에게 메시지를 보내도록 직접 지시할 수는 없다고 말했습니다.

Flows는 비용이 훨씬 많이 들지만, 큰 작업들을 위해 설계되었습니다.
관심 목록 스캐너 비교에서 Avilla는 flows가 단일 에이전트 접근 방식보다 “훨씬 더 많은” 비용이 든다고 했지만, 동시에 “모든 세부 사항을 찾는 데 훨씬 효과적”이었다고 말했습니다.

더 큰 질문은 flows가 실제로 얼마나 야심차게 설계될 수 있느냐는 것입니다. 한 청중은 OpenAI가 최근 발표한 Navier–Stokes 밀레니엄 상 문제에 관한 증명 사례를 언급하며, 동적 워크플로우가 대규모 과학 연구 프로젝트를 구동할 수 있는지 물었습니다.

Stall은 Anthropic이 대규모 과학 문제를 어떻게 계산하는지에 대한 구체적인 내용은 밝히지 않았지만, 일반 사용자들도 그러한 문제들을 다룰 수 있도록 하는 것이 목표라고 말했습니다.

그는 “Flows는 기본적으로 어려운 문제들에 테스트 시간 컴퓨팅(test-time compute)을 투입하여 모델로부터 더 빠르게 역량을 얻어내는 방법입니다. 저희는 특히 API 서비스로서, 이 힘을 해제하는 것이 일반 대중이 이러한 종류의 발견이나 과학적 진보를 폭넓게 수행할 수 있도록 하는 첫 단계라고 생각합니다.”라고 말했습니다.