서론

Microsoft Agent Framework의 오케스트레이션 패턴이 1.0에 도달했다고 발표되었습니다.

본 시리즈에서는 5가지 오케스트레이션 패턴을 하나씩 Microsoft.Agents.AI.Workflows 1.13.0으로 실제로 구동하며 확인하고 있습니다.

이번에는 Group chat orchestration 패턴입니다.

Group chat은 여러 에이전트의 대화를 관리자(manager)가 제어하는 패턴입니다.

Sequential처럼 '정해진 순서대로 한 번씩' 진행되는 것이 아니라, 리뷰가 통과될 때까지 여러 차례 주고받는 등의 사용이 가능합니다.

본 기사에서 알 수 있는 내용:

• RoundRobinGroupChatManager를 사용하여 여러 에이전트를 순차적으로 호출하는 방법 - 대화 기록을 보고 계속할지 종료할지를 관리자가 판단하는 메커니즘
• 승인이 나올 때까지 여러 턴에 걸쳐 진행되는 실제 동작 사례
• LM Studio의 실LLM (google/gemma-4-12b)으로 Writer와 Reviewer를 대화시킨 실제 동작 결과

환경

항목	내용
검증일	2026년 7월 9일
...	Microsoft.Agents.AI 1.13.0 / Microsoft.Agents.AI.Workflows 1.13.0
검증 프로젝트	OrchestrationPatternsValidation

검증 코드 전문은 MAF_OrchestrationPatterns_Samples에서 공개하고 있습니다.

본 기사에서 시도할 내용

이번에 준비한 것은 아래의 2가지 케이스입니다.

케이스	내용	확인하고 싶은 점
simple	Writer와 Reviewer	Reviewer가 APPROVED로 종료하는지
complex	Planner, Risk, Editor	3자를 round-robin으로 순환시키고, Editor의 두 번째 APPROVED에서 종료하는지

Group chat에서는 고정된 순서로 할당된 에이전트가 한 번씩 처리를 수행한 후,
관리자(manager)가 대화 기록을 확인하여 계속할지 종료할지를 판단합니다.

구현 코드

simple 케이스에서는 Writer가 짧은 초안을 제시하고, Reviewer가 승인합니다.

static Workflow CreateGroupChatSimpleWorkflow()
{
AIAgent writer = new CountingAgent(

=== group-chat/complex ===
update:Planner:企画: FAQ検索から限定公開。
update:Risk:リスク: 権限と誤回答時の連絡導線を明記。
...

첫 번째 Editor는 `APPROVED`를 반환하지 않고, 두 번째 순회(2巡目)에서야 비로소 종료 조건을 충족했습니다.

대화 기록을 기반으로 한 종료 판정이 의도대로 작동하고 있음을 알 수 있습니다.

## LM Studio에서 실행

여기까지는 호출된 횟수에 따라 응답을 변경하는 스텁(stub)으로 종료 판정 메커니즘을 확인했습니다.

다음으로는 Group chat을 LM Studio 상의 LLM으로 확인합니다.

| 항목 | 내용 |
|---|---|
| 검증일 | 2026년 7월 10일 |
| ... | 
종료 판정은 전반부와 동일하게 '기록에 `APPROVED`가 포함되는지'입니다.

LLM의 경우, 이 종료 조건을 instructions에서 명시해 두어야 합니다.

Reviewer에게는 '충분한 품질이라면 문말에 APPROVED라고 적는다'라는 규칙을 부여했습니다.

AIAgent writer = CreateAgent(chatClient, "Writer",
"캐치프레이즈를 만드는 담당자.",
"당신은 카피라이터입니다. 요청에 맞는 일본어 캐치프레이즈를 1개만 제안해 주세요. 서두는 필요 없습니다. 리뷰에서 지적이 있으면 수정안을 1개 내주세요.");
...

실행 결과는 다음과 같습니다.

=== group-chat ===
prompt: 예산을 낮춘 전동 자전거의 짧은 일본어 캐치프레이즈를 1개 만들어 주세요.
agent:Writer: 현명하게 고르는, 전동의 경쾌함.
...

이번에는 Writer의 첫 번째 안을 Reviewer가 승인하여 한 순회(1巡) 만에 종료했습니다(약 48초).

스텁 검증의 '두 번째 순회에서 승인'과는 다른 전개이지만, 이는 몇 순회로 끝날지는 LLM의 판단에 위임된 동작입니다.

이 판단은 언제 끝날지 알 수 없으므로 `MaximumIterationCount`와 같은 상한을 반드시 병용해야 합니다.

## 파악한 것

- Group chat은 여러 역할이 대화를 나누면서 내용을 다듬어 나가는 처리에 적합합니다. Sequential과 달리, 종료 조건을 관리자 측에 둘 수 있다는 것이 큰 차이점입니다.
- 이번 complex 케이스에서는 Editor의 첫 번째 응답에서 멈추지 않고, 두 번째 `APPROVED`로 종료했습니다. 대화 기록 기반의 종료 판정이 실제로 기능하고 있음을 확인할 수 있었습니다.
- 검증에서는 `RoundRobinGroupChatManager`를 사용했지만, 이 부분을 자체 참가자 선택 방식(独自の参加者の選び方)으로 대체함으로써 더욱 세밀하게 제어할 수도 있습니다.
- LM Studio의 `google/gemma-4-12b`를 연결한 LLM 검증에서는 Reviewer가 첫 번째 순회에서 `APPROVED`를 반환하여 종료했습니다. 몇 순회로 끝날지는 모델에 따라 다르므로, `MaximumIterationCount`와 같은 상한은 필수입니다.

## 참고

### Discussion

![](https://static.zenn.studio/images/drawing/discussion.png)