Anthropic이 멀티 에이전트 시스템 설계 패턴 5가지를 정리한 글을 공개했습니다. 읽기 전에는 “이걸 왜 이렇게 따져서 골라야 하지?” 했는데, 다 읽고 나니 조금 이해됐습니다💡패턴을 잘못 고르면 복잡성만 늘고 손해를 볼 수 있다고 합니다. 내용을 정리해봤습니다.
———
✅ Generator-verifier
하나가 만들고 하나가 검증하는 구조입니다. 고객 응대 이메일을 생성하면, 다른 에이전트가 내용과 말투를 체크한 뒤 피드백을 돌려보내는 방식입니다. 핵심은 검증 기준을 명확히 정해두는 것이라고 합니다. “잘 됐는지 확인해”라고만 하면 그냥 통과시켜버리고, 기준이 없으면 검토 자체가 의미 없어진다고 합니다.
✅ Orchestrator-subagent
한 에이전트가 전체 계획을 세우고 나머지에게 역할을 나눠주는 구조입니다. 코드 리뷰를 예로 들면, 보안 검토, 테스트 확인, 코드 스타일을 각각 맡기고 결과를 모아 정리하는 방식입니다. 단점은 조율하는 에이전트가 병목이 된다는 점입니다. 한 에이전트가 발견한 문제가 다른 작업에도 영향을 줄 때 전달 과정에서 맥락이 빠질 수 있다고 합니다.
✅ Agent teams
작업이 끝나도 리셋되지 않고 계속 살아서 맥락을 쌓아갑니다. 오래 걸리는 작업일수록 유리하다고 합니다. 다만 팀원들이 서로 독립적으로 일할 수 있어야 합니다. 같은 파일이나 자원을 건드리는 구조라면 충돌이 생긴다고 합니다.
✅ Message bus
어떤 상황이 올지 예측할 수 없을 때 적합한 구조입니다. 이벤트가 오면 적합한 에이전트에게 자동으로 넘기는 방식이라, 새로운 상황이 생겨도 기존 흐름을 바꾸지 않아도 된다고 합니다. 단, 중간에서 잘못 분류되면 조용히 실패하기 때문에 어디서 막혔는지 추적하기 어렵다고 합니다.
✅ Shared state
에이전트들이 공용 저장소를 함께 읽고 쓰며 협력하는 구조입니다. 한 에이전트가 발견한 내용이 즉시 다른 에이전트의 방향을 바꿀 수 있습니다. 종료 조건을 반드시 설계해야 한다고 합니다. A가 쓰고 B가 반응하고 A가 다시 반응하는 루프가 생기면 끝나지 않고 계속 돌아가기 때문입니다.
———
프로젝트를 진행할 때마다 멀티 에이전트 구성에 대해 클로드에게 항상 질문합니다. 그런데 결과가 늘 다르더군요. 이제야 조금 이해가 됩니다. Orchestrator-subagent 구조를 기준으로 상황에 따라 변화를 줬던 것 같은데, 권장 사항이라고 하니 그동안 질문을 잘하고 있었다는 생각도 듭니다😊
출처: Claude Blog