AI VIDEO BRIEFING

동적 워크플로란? 멀티에이전트 오케스트레이션 코드를 AI가 직접 작성하는 오픈핸즈 SDK 사례

멀티에이전트 시스템을 만들 때 개발자가 손으로 짜던 오케스트레이션 루프를, 모델이 도구를 받아 직접 코드로 작성하게 하는 동적 워크플로 방식과 오픈핸즈 SDK의 딥리서치 실행 과정, 트레이스 확인까지 정리했다.

오케스트레이션 코드를 모델이 직접 쓴다: 오픈핸즈 SDK의 동적 워크플로 영상 대표 이미지

핵심 메시지

  • 멀티에이전트 시스템에서 지금까지 개발자가 직접 짜던 것은 루프, 노드, 엣지, 상태 같은 오케스트레이션 코드였다.
  • 동적 워크플로는 미리 정해둔 절차 메뉴가 아니라, 에이전트가 상황에 맞는 로직을 스스로 코드로 써서 실행하게 하는 도구다.
  • 스킬이 '언제 워크플로를 쓸지'를 알려주고, 웹 검색·팩트체크·종합 같은 서브에이전트는 미리 정의된 역할 풀로 준비된다.
  • 발표자는 오케스트레이션 코드가 25줄에서 몇 줄로 줄었다고 밝히며, 실제 딥리서치 질의를 실행해 모델이 map/reduce 구조를 스스로 작성하는 과정을 보여준다.
  • 실행 후에는 관측 도구로 트레이스를 확인해 어떤 서브에이전트가 무엇을 했는지 역추적하는 것이 권장된다.

쉽게 이해하기

발표자는 딥리서치 에이전트를 직접 만들어 본 경험을 들며, 멀티에이전트 시스템 구축의 실제 부담이 어디에 있는지부터 짚는다. 서브에이전트들이 조사를 나가고, 돌아와 결과를 공유하고, 그것을 압축해 정리하는 흐름을 개발자가 일일이 손으로 짜야 했다는 것이다. 루프, 노드, 엣지, 상태 관리까지 붙으면 오케스트레이션 코드만으로도 상당한 분량이 된다.

동적 워크플로는 이 부담의 방향을 뒤집는다. 개발자가 오케스트레이션 코드를 쓰는 대신, 에이전트에게 오케스트레이션 코드를 직접 쓸 수 있는 도구를 쥐여주는 방식이다. 발표자는 이것이 미리 정의된 워크플로나 선택지 메뉴가 아니라는 점을 강조한다. 에이전트가 적절하다고 판단한 로직을 그때그때 작성한다는 뜻이다. 앤트로픽이 클로드 코드에 동적 워크플로를 내놓은 것이 이번 주 화제가 되었고, 오픈소스 쪽에서는 같은 팀의 그레이엄이 오픈핸즈 SDK에 같은 기능을 더했다고 소개한다.

구성 요소는 세 층으로 나뉜다. 맨 위의 스킬은 모델에게 언제 워크플로를 써야 하는지 알려주는 지시문에 해당한다. 예컨대 '조사를 요청받으면 깊이 생각하고, 여러 각도를 찾아내고, map 에이전트와 reduce 에이전트를 도구로 쓰라'는 식이다. 그 아래 서브에이전트는 웹 검색, 팩트체크, 종합처럼 미리 정의해 둔 역할들이며, 에이전트는 이 풀에서 필요한 것을 꺼내 문제를 푼다. 실제 사용은 워크플로 도구와 스킬을 붙여 에이전트를 만드는 몇 줄이면 끝난다.

발표자는 깃허브 저장소에 수작업 오케스트레이션으로 짠 스크립트와 워크플로 방식 스크립트를 나란히 두고, 후자를 도커 안에서 실행해 보인다. 맥에서 여러 에이전트를 동시에 돌릴 때는 컨테이너 안이 훨씬 깔끔하다는 이유에서다. 질의는 'AI 코딩 어시스턴트 시장 규모는 얼마인가'였고, 시스템 프롬프트에 실린 스킬과 지시가 지나간 뒤 오케스트레이터가 조사 각도를 나누고 map·reduce를 쓰겠다고 스스로 정리하는 대목이 나온다. 이 내용을 만든 주체가 개발자가 아니라 모델 자신이라는 점이 핵심이다.

실행 결과 모델은 에이전트를 부채꼴로 펼쳐 조사시키고, 교차 확인을 거쳐, 하나로 종합하는 코드를 작성해 1분 남짓 만에 최종 보고서를 만들어 냈다. 발표자는 이 구조 자체가 대단히 새로운 것은 아니며 많은 개발자가 비슷한 것을 손으로 만들어 봤을 것이라고 인정한다. 달라진 점은 그 구조를 모델이 알아서 짜게 했다는 것이다.

마지막으로 발표자는 코드를 돌린 뒤에는 반드시 트레이스를 확인하라고 권한다. 오픈소스 관측 도구 라미나를 예로 들며, 한 번의 실행이 81초·18만 4천 토큰을 썼다는 식으로 단계별 상호작용을 들여다볼 수 있다고 설명한다. 트레이스를 언어 모델에 넘겨 설명을 받는 기능도 소개되는데, 원본 코드가 아니라 출력만 보고 메인 에이전트의 계획, 웹 검색 담당, 팩트체크 담당, 종합 단계를 역추적해 낸다는 점을 강조한다.

주요 인사이트

  • 동적 워크플로의 본질은 자동화의 대상이 '작업'에서 '작업을 조율하는 코드'로 한 단계 올라갔다는 데 있다. 모델이 손대는 영역이 결과물에서 제어 흐름으로 옮겨간 셈이다.
  • 미리 정의된 워크플로와의 차이는 유연성이다. 선택지 메뉴에서 고르는 것이 아니라 상황에 맞는 로직을 새로 쓰기 때문에, 예상하지 못한 요청에도 구조를 바꿔 대응할 수 있다.
  • 모델에게 자유를 주는 대신 역할은 좁혀 둔다. 웹 검색·팩트체크·종합처럼 서브에이전트를 미리 정의해 두는 구조가 무제한 자유와 통제 사이의 절충점 역할을 한다.
  • 제어 흐름을 모델이 만들면 코드를 읽어서는 실제 동작을 알 수 없다. 관측 도구로 트레이스를 확인하는 일이 선택이 아니라 기본 절차가 되는 이유다.
  • 발표자는 이 흐름을 '모델이 우리가 손으로 쓰던 오케스트레이션 코드를 잠식하기 시작했다'고 요약한다. AI 엔지니어의 작업 대상이 무엇인지 다시 묻는 변화다.

자주 묻는 질문

동적 워크플로는 기존 워크플로와 무엇이 다른가요?

미리 정해 둔 절차를 실행하거나 선택지 메뉴에서 고르는 방식이 아닙니다. 에이전트에게 오케스트레이션 코드를 쓸 수 있는 도구를 주고, 에이전트가 적절하다고 판단한 로직을 그때그때 직접 작성해 실행하게 하는 방식입니다.

개발자가 준비해야 할 것은 무엇인가요?

언제 워크플로를 쓸지 알려주는 스킬(지시문)과, 웹 검색·팩트체크·종합처럼 미리 정의된 서브에이전트 역할들입니다. 그다음에는 워크플로 도구와 스킬을 붙여 에이전트를 생성하는 몇 줄의 코드면 실행할 수 있습니다.

실행 후 무엇을 확인해야 하나요?

트레이스입니다. 발표자는 관측 도구로 실행 시간과 토큰 사용량, 단계별 상호작용을 확인하라고 권합니다. 오케스트레이션 코드를 모델이 작성했기 때문에 실제로 어떤 서브에이전트가 무엇을 했는지는 출력 기록을 통해 확인해야 합니다.

원문과 출처

이 글은 원본 영상의 자막을 바탕으로 한국어 독자를 위해 요약했습니다. 전체 맥락과 최신 정보는 원문에서 확인하세요.

YouTube 원본 영상 보기 ↗

관련 AI 소식