배경 및 맥락

multi-agent 시스템이 늘어나면서 실제 현장에서는 모델 성능보다 에이전트 사이를 어떻게 연결하고 검증 가능한 형태로 운영할지가 더 큰 문제로 떠오르고 있다. 코드 리뷰 파이프라인, 리서치 후 요약, 문서 생성 후 검토 같은 작업은 대체로 단계 구조가 이미 정해져 있는데도, 많은 팀이 planner agent를 하나 더 두고 동적으로 다음 단계를 정하게 만들었다.

이 접근은 탐색적 작업에는 유용하지만, 반복 가능한 업무에서는 토큰 비용과 latency를 늘리고 재현성을 떨어뜨린다. Microsoft가 공개한 Conductor는 바로 이 지점에서 orchestration을 다시 소프트웨어 정의 문제로 끌어온다.

---

핵심 내용

공식 글에 따르면 Conductor는 Microsoft org에서 공개된 MIT 라이선스 오픈소스 CLI다. 핵심 아이디어는 multi-agent workflow를 코드 대신 YAML로 선언하고, agent 간 라우팅을 deterministic하게 고정하는 것이다. 조건 분기와 변수 삽입은 Jinja2 템플릿과 expression evaluation으로 처리하며, orchestrator 자체는 LLM 호출을 하지 않는다.

Microsoft는 이런 설계가 code review pipeline, research-then-synthesize, plan-then-implement 같은 구조화된 흐름에 특히 적합하다고 설명한다. 또한 workflow 정의를 diffable artifact로 관리할 수 있어 CI/CD 파이프라인처럼 버전 관리와 리뷰, human oversight 단계를 명시적으로 넣기 쉽다는 점도 강조했다.

---

경쟁 구도 / 비교

최근 agent 프레임워크 다수는 orchestrator도 agent로 두는 방식을 선호한다. 이 방식은 유연하지만, 어느 경로로 실행됐는지 설명하기 어렵고 테스트 재현성이 떨어질 수 있다. Conductor는 반대로 orchestration은 deterministic하게 두고, 실제 reasoning이 필요한 부분만 각 agent에 맡기는 구조를 제안한다.

이는 Databricks나 IBM처럼 enterprise control plane을 넓게 묶는 흐름과는 층위가 다르다. 그들 제품이 조직 수준 governance를 다룬다면, Conductor는 개발팀이 workflow 자체를 코드 자산처럼 다루는 쪽에 더 가깝다.

---

의미

기술적으로는 agent engineering이 프롬프트 설계 중심에서 workflow architecture 설계 중심으로 이동하고 있음을 보여준다. 산업적으로는 반복 업무 자동화에서 더 똑똑한 planner보다 더 검증 가능한 orchestrator가 구매 포인트가 될 수 있다는 신호다.

실무적으로는 운영팀과 플랫폼팀이 agent workflow를 앱 코드처럼 리뷰하고 테스트하는 체계를 갖출 필요가 있다. 앞으로 경쟁력은 단일 agent의 성능보다, 여러 agent를 얼마나 예측 가능하고 비용 효율적으로 엮을 수 있는지에서 갈릴 가능성이 크다.