HydraFusion과 동적 워크플로우: 생성 시 모델 선택이 품질에 미치는 영향

제가 궁금한 점은 GitHub Copilot으로 동적 워크플로우를 만들 때, 상위 모델로 에스컬레이션되는 것처럼 보인다는 것입니다. 저는 그 움직임이 결과물의 품질에 영향을 주고 있다고 느낍니다. 이는 먼저 관찰을 통해 세운 가설입니다.

지금까지 GitHub Copilot을 사용할 때는 Plan(작업 계획)을 만든 후에 실행하는 경우가 많았고, Plan의 질이 실행 결과의 품질에도 반영된다고 느껴왔습니다. 이번에는 동적 워크플로우가 Plan부터 실행까지를 코드로 연결하고, Copilot에 의한 자동화를 한 단계 더 발전시켜 줄 것이라고 생각합니다.

공식 문서에는 동적 워크플로우의 생성만을 특별 취급하여 항상 상위 모델로 전환하는 메커니즘은 설명되어 있지 않습니다. 따라서 상위 모델로의 전환을 사양으로 단정할 수는 없습니다.

반면, HydraFusion은 작업에 따라 실행 패턴을 선택하고, 필요하다면 더 강력한 모델로 진행합니다. 동적 워크플로우의 생성도 대화 세션에 대한 요청이지만, 그 요청에 HydraFusion이 적용되는지는 별개의 문제입니다. 이 글에서는 확인된 사양, 조건부 추론, 그리고 저의 관찰을 나누어 생각하겠습니다🧭

만약 생성 시 상위 모델이 사용되었다고 해도, 그것만으로 품질 차이의 원인이라고 할 수는 없습니다. 요구사항의 명확성이나 우연한 차이도 고려할 수 있습니다. 반면, 워크플로우의 절차나 조건은 코드로 저장되며 재사용 시에도 계승됩니다. 즉, Plan에 해당하는 설계의 질은 재사용될 수 있지만, 생성 모델이 품질을 높였다는 인과관계는 아직 가설입니다.

서브 에이전트와의 역할 분담은 이전 글인 'Custom Agents와 Subagents로 시작하는 자율 오케스트레이션 입문'에서 정리했습니다. 이번에는 모델 선택과 워크플로우의 생성 및 실행 차이에 초점을 맞춥니다.

본 글은 2026년 10월 9일자 공개 정보를 기반으로 합니다. HydraFusion과 동적 워크플로우는 각각 research preview, public preview이며, Copilot SDK의 Dynamic Workflows API는 experimental입니다. 따라서 여기서 정리한 내용은 작성 시점 기준입니다.

HydraFusion, Auto, 동적 워크플로우는 에이전트가 작업을 진행하는 방식 중 서로 다른 부분을 제어합니다. 먼저 역할을 나누어 보는 것이 중요합니다.

동적 워크플로우의 생성 요청이 HydraFusion 경로를 거치는지 여부는 공개 정보로는 확인할 수 없습니다. 아래 그림은 해당 경로가 적용되었을 경우를 가정한 개념도입니다.

그림의 실선은 공개 자료에서 확인 가능한 워크플로우의 생성 및 등록, 그리고 후속 실행, HydraFusion의 일반적인 실행 패턴을 보여줍니다. 점선은 생성 요청에 어떤 모델 경로가 적용되는지 확인할 수 없기 때문에 후보로 나누어 표시한 것입니다. HydraFusion, Auto, 고정 모델 중 무엇이 사용될지, 또는 생성을 전용으로 하는 에스컬레이션 기능이 있는지 여부는 공개 정보로는 확인할 수 없습니다.

HydraFusion은 서브 에이전트와 별개로 작동하며, 서브 에이전트를 구동하지 않습니다 (공식 문서). 따라서 HydraFusion이 동적 워크플로우의 서브 에이전트를 직접 오케스트레이션한다고는 할 수 없습니다.

Copilot SDK의 Dynamic Workflows API에서는 ctx.agent마다 model을 지정할 수 있습니다. 공정 구성과 각 서브 에이전트의 모델 지정은 별도의 설정입니다. 모델을 생략했을 경우의 상속처는 공개 문서에서 확인할 수 없습니다.

GitHub Copilot SDK의 공개 소스에서는 defineWorkflow()가 run 함수와 메타데이터를 가진 핸들(handle)을 정의하여 반환합니다 (workflow.ts의 정의 처리). 여기서 확인할 수 있는 것은 우선 워크플로우의 정의입니다.

SDK 예시에서는 이 핸들을 joinSession({ workflows: [...] })로 등록하고, 나중에 session.workflow.run()으로 실행합니다 (정의 및 등록, 실행 API). SDK의 API 역시 등록과 실행을 분리하고 있습니다.

서브 에이전트를 위한 WorkflowAgentOptions에는 model과 reasoningEffort가 선택 항목으로 정의되어 있으며, ctx.agent()의 옵션은 session.workflow.agent의 RPC로 전송됩니다 (workflow.ts, session.ts). 즉, SDK는 호출 시점별 모델 지정 정보를 전달합니다.

다만, SDK의 공개 소스에서 실제로 해결되는 모델이나 HydraFusion이 생성 요청을 어떻게 처리하는지는 알 수 없습니다. SDK는 호출 측의 구현체이며, 라우팅이나 품질 게이트 판단 로직은 보여주지 않습니다.

생성형(Generative)이라는 용어를 언급한 것은 SDK가 이벤트로서 무엇을 표현할 수 있는지를 보여주기 위함입니다. 타입에는 single / cascade / critique 패턴, judge / repair 등의 페이즈(phase), judgeModel / repairModel 등의 항목이 있습니다 (session-events.ts의 페이즈 타입, 라우팅 결과 타입). FusionScores에는 codeGen, debugging, reasoning, toolUse 항목도 있습니다 (타입 정의).

이들은 이벤트의 타입일 뿐이며, HydraFusion의 구현체는 아닙니다. 품질 게이트의 기준, 점수 계산 방법, 생성 요청과의 연결은 이 타입 정의만으로는 알 수 없습니다.

SDK의 E2E 테스트에서도 /model/fusion에 대한 응답은 테스트용 핸들러가 고정된 플랜으로 대체하고 있습니다 (hydrafusion_max.e2e.test.ts). 이 테스트가 보여주는 것은 SDK 클라이언트의 동작일 뿐, 실제 라우팅 판단이 아닙니다.

워크플로우를 생성할 때는 요청 분할, 공정 병렬화, 결과 전달, 실패 시 지속/중단 등을 설계합니다. 즉, 생성 시 결정하는 것은 단순히 텍스트뿐만 아니라 실행 프로세스의 구조입니다.

생성 모델의 추론력이 높으면, 공정 간 의존 관계나 실패 경로를 더 적절하게 설계할 수 있을 가능성이 있습니다. 그 판단이 코드에 남아 있다면, 워크플로우 재사용 시에도 계승될 수 있습니다. 다만, 재사용되는 것은 프로세스 정의일 뿐이며, 실행 결과는 실행 당시의 모델, 입력, 환경 등에도 좌우됩니다. 따라서 설계 개선이 후속 실행으로 이어질 가능성은 있지만, 결과 품질 향상까지 보장되지는 않습니다.

반면, 생성 요청이 일반적인 HydraFusion 경로를 거치는지, 아니면 생성 전용 에스컬레이션 메커니즘이 있는지 여부는 공개 정보로는 확인할 수 없습니다. 따라서 관찰된 품질 차이를 HydraFusion이나 Auto의 작동에 귀속시킬 수는 없습니다.

생성 시 모델 선택이 워크플로우 실행 시의 모델 선택을 결정하지는 않습니다. 실행 시에 사용되는 모델은 공정별 설정이나 실행 환경과 관련되며, HydraFusion 자체도 서브 에이전트를 구동하지 않습니다. 즉, 설계 시와 실행 시의 모델 경로는 분리하여 생각할 필요가 있습니다.

생성된 품질만으로는 어떤 모델이나 경로가 사용되었는지 특정할 수 없습니다. 공개 자료는 Auto를 모델 선택으로, HydraFusion을 실행 패턴 및 모델 선택으로 설명하고 있지만, 이 둘 사이의 내부적인 관계까지는 보여주지 않습니다 (HydraFusion, Auto). 따라서 비교할 수 있는 것은 사용자에게 보이는 선택지의 동작이며, 내부의 라우팅 구조가 아닙니다.

생성 요청 경로를 조사할 때는 먼저 세션 설정을 기록하고, UI나 로그에 실제로 표시되는 정보를 확인해야 합니다. HydraFusion 문서에 따르면, CLI에서는 실행 패턴이나 각 단계를 확인할 수 있으며, /collect-debug-logs 명령어로 상세 로그를 수집할 수 있습니다. Copilot app과 Auto에서는 응답에 사용된 모델을 확인할 수 있습니다. 확인 가능한 표시가 없다면, 설정만으로 경로를 단정해서는 안 됩니다.

품질 차이를 조사하려면, 생성 시와 실행 시를 나누어 평가해야 합니다. 동일한 요구사항에서 생성 조건을 바꿔 여러 워크플로우를 만들고, 모델 이름을 가린 채 설계 품질을 평가합니다. 그 후, 동일한 입력과 실행 시 모델 설정으로 구동하여 실행 품질을 비교합니다. 이를 통해 모델 선택의 영향을 설계와 실행에 나누어 생각할 수 있습니다.

현재 시점에서는 동적 워크플로우 생성 시의 품질 차이를 HydraFusion이나 Auto의 에스컬레이션과 연결할 수 있는 공개적인 증거는 없습니다. 저의 관찰은 시스템 구조와 모순되지 않지만, 원인은 확인되지 않았습니다.

한편, 코드로화된 절차나 조건은 워크플로우와 함께 재사용됩니다. 제 추측으로는, 동적 워크플로우는 'Plan을 만든 후 실행한다'는 사용 방식을 코드로화하고, 이를 실행까지 연결함으로써 자동화를 더욱 진전시키는 흐름입니다. 생성 시의 모델 선택과 실행 시의 모델 선택은 나누어 평가해야 합니다.

중요한 것은 어떤 판단을 설계 시에 고정하고, 어떤 판단을 실행 시에 위임할 것인가입니다. 동적 워크플로우의 가치는 판단을 재사용 가능한 프로세스로 남길 수 있다는 점에 있습니다🧭

공식 문서와 공식 블로그는 2026년 10월 9일에 확인했습니다. Copilot SDK의 소스 코드는 아래 링크에 기재된 커밋에 고정되어 있습니다.

• Using HydraFusion

• Dynamic workflows

• Using dynamic workflows

• About Copilot auto model selection

• Project HydraFusion: frontier quality via multi-model orchestration

• HydraFusion in VS Code and the GitHub Copilot app

• Dynamic workflows in Copilot CLI and the Copilot app

• Dynamic Workflows — GitHub Copilot SDK documentation

• GitHub Copilot SDK:
  workflow.ts

• GitHub Copilot SDK:
  session.ts

• GitHub Copilot SDK: generated
  session-events.ts

• GitHub Copilot SDK:
  hydrafusion_max.e2e.test.ts

• Custom Agents와 Subagents로 시작하는 자율 오케스트레이션 입문