Molayo

© 2026 Molayo

Dev.to헤드라인2026. 06. 15. 10:34

4개의 에이전트 > 1: Argus가 단일 에이전트 대신 PM/SE/AP 팀을 사용하는 이유

요약

Argus는 단일 에이전트의 과도한 자기 신뢰 문제를 해결하기 위해 PM, SE, AP, Monitor라는 4개의 특화된 에이전트 팀 구조를 채택합니다. 각 에이전트가 기획, 실행, 검증, 감시 역할을 분담하여 코드 품질을 높이고 오류를 최소화하는 협업 프로세스를 제공합니다.

핵심 포인트

  • 단일 에이전트의 한계를 극복하기 위한 역할 분담(Separation of Concerns) 적용
  • PM(기획), SE(구축), AP(승인), Monitor(감시)의 4단계 협업 구조
  • AP(Approver)의 독립적인 리뷰와 거부권(Veto power)을 통한 품질 보증
  • 작업 복잡도에 따라 실행 경로를 최적화하는 경량 모드 지원

4 agents > 1: Argus가 단일 에이전트 대신 PM/SE/AP 팀을 사용하는 이유

제가 시도해 본 모든 AI 코딩 에이전트는 동일한 문제를 가지고 있습니다: 자기 자신을 너무 과하게 신뢰한다는 점입니다.

에이전트는 코드를 작성하고, 실행하고, 컴파일되는 것을 확인한 뒤 "완료!"라고 말합니다. 심지어 그 코드에 예외 케이스(edge cases)가 있거나, 에러 처리(error handling)가 누락되었거나, 사용자가 설명한 문제를 실제로 해결하지 못했을 때조차 말이죠. 제2의 의견도, 리뷰 프로세스도, 품질 게이트(quality gate)도 없습니다.

Argus는 다른 접근 방식을 취합니다. 하나의 에이전트가 모든 것을 수행하는 대신, 소규모 엔지니어링 팀처럼 함께 작동하는 4개의 특화된 에이전트를 사용합니다.

4가지 역할

┌─────────────────────────────────────────────────────┐
│                    Argus Core                        │
│                                                     │
...

PM (Project Manager) — 기획자

PM은 요청을 전달받아 세 가지 일을 수행합니다:

  1. 작업의 무게를 결정합니다 — 이것이 간단한 작업(featherweight)인지, 복잡한 작업(lightweight+)인지 판단합니다.
  2. 가벼운(featherweight) 작업의 경우: 도구(write_file, exec 등)를 사용하여 직접 실행합니다.
  3. 복잡한 작업의 경우: 요구사항을 세분화하고, SE에게 할당하며, SE의 결과물을 리뷰합니다.

PM은 복잡한 작업에 대해 직접 코드를 작성하지 않습니다. 대신 계획을 세우고 리뷰를 합니다. 이러한 관심사의 분리(separation of concerns)는 의도적인 것입니다. PM은 새로운 시각으로 SE의 작업물을 평가합니다.

SE (Software Engineer) — 구축자

SE는 PM의 작업 설명을 전달받아 이를 실행합니다. 파일을 작성하고, 명령어를 실행하며, 의존성(dependencies)을 설치하고, exec 명령어를 통해 자신의 작업물을 검증합니다.

SE는 실무를 담당하는 일꾼이지만, 단독으로 신뢰받지는 않습니다. SE가 완료한 모든 작업은 리뷰 과정을 거칩니다.

AP (Approver) — 승인자

AP는 시스템에서 가장 중요한 역할입니다. AP는 다음과 같은 역할을 수행하는 독립적인 리뷰어입니다:

  • SE가 작성한 코드를 읽습니다.
  • 직접 컴파일/테스트를 실행합니다 (SE의 검증을 신뢰하지 않습니다).
  • 실제 결과에 기반하여 승인 또는 거절을 결정합니다.

AP는 **거부권 (veto power)**을 가집니다. 만약 AP가 거부하면 작업은 다시 SE에게 돌아가며, PM은 이를 무시할 수 없습니다. 이러한 3단계 검증(SE 자체 테스트 → PM 검토 → AP 승인)은 단일 에이전트 (single-agent) 시스템이 놓치는 버그를 잡아냅니다.

C (Monitor) — 감시자 (watchdog)

C는 LLM을 사용하지 않습니다. C는 다음과 같은 역할을 수행하는 백그라운드 프로세스입니다:

  • PM 또는 SE가 멈췄을 때(30초 이상 응답 없음) 감지
  • 실패한 작업을 자동 복구
  • 파일 변경을 감지하고 커밋 (commit) 제안
  • 시스템이 멈추지 않도록 안전망 제공

실제 작동 방식

사용자: "/health 엔드포인트가 있는 Go REST API를 생성해줘"
  ↓
PM: 요구사항 분석
...

이 프로세스는 단일 에이전트보다 단계는 더 많지만, 각 단계가 품질을 더합니다. 실제로 간단한 작업의 경우 PM은 SE/AP 체인을 완전히 건너뛰고 직접 실행합니다 (경량 모드 (featherweight mode)). 복잡한 작업의 경우, 전체 파이프라인을 통해 검토 없이 배포되는 것이 없도록 보장합니다.

공유 메모리 (shared memory) 문제

이 아키텍처에서 가장 어려운 부분은 모든 역할이 동일한 정보를 공유하도록 유지하는 것이었습니다. 초기 버전에서는 각 역할에 고유한 메모리를 부여했습니다. 즉, PM은 자신의 계획을 저장하고, SE는 코드를 저장하며, AP는 검토 내용을 저장한 뒤 메시지를 통해 이를 동기화했습니다. 이는 지속적인 컨텍스트 손실 (context loss)을 야기했습니다.

현재의 V2 아키텍처는 **공유 메모리 (shared memory)**를 사용합니다. 즉, 네 가지 역할 모두가 동일한 컨텍스트 윈도우 (context window)에서 읽고 씁니다. PM은 SE가 작성한 내용을 정확히 볼 수 있습니다. AP는 PM의 검토 노트를 볼 수 있습니다. 메시지 전달도, 동기화 문제도 없습니다.

V1 (구버전):                     V2 (현재):
┌──────┐  ┌──────┐            ┌──────────────────┐
│ PM   │  │ SE   │            │  Shared Memory    │
...

이를 통해 V1 대비 코드를 80% 줄였으며, 한 역할이 다른 역할이 수행한 내용을 알지 못해 발생하는 일련의 버그들을 제거했습니다.

멀티 에이전트 (multi-agent) 오버헤드가 가치 있는 경우

추가적인 검토 단계는 지연 시간 (latency)을 발생시킵니다. "이 오타를 수정해줘" 또는 "이 명령어를 실행해줘"와 같은 작업의 경우, 단일 에이전트 경로가 더 빠를 것입니다. Argus는 이러한 케이스를 감지하고 검토 체인을 우회하기 위해 경량 분류 시스템을 사용합니다.

하지만 복잡한 작업 — 다중 파일 변경, 새로운 기능 구현, 검증이 필요한 버그 수정 — 의 경우, 검토 프로세스가 실제 문제들을 잡아냅니다. 저희 테스트 결과에 따르면, AP(Application Programmer)는 PM(Product Manager)이 이미 승인한 SE(Software Engineer) 작업의 약 15%를 잡아냅니다. 이는 단일 에이전트 시스템이었다면 그대로 배포되었을 버그들입니다.

이것이 사용자에게 의미하는 바

  • AI 에이전트가 제대로 완료하지 않았음에도 "완료되었습니다"라고 말하는 것에 지쳤다면, Argus의 검토 파이프라인(review pipeline)이 신뢰를 제공합니다.
  • AI가 어떻게 코드를 도출하는지 확인하고 싶다면, 역할 분리(role separation)가 각 단계를 가시화해 줍니다.
  • 직접 멀티 에이전트 시스템(multi-agent systems)을 구축하고 있다면, 공유 메모리 패턴(shared-memory pattern)을 연구할 가치가 있습니다.

트레이드오프(tradeoff)는 품질을 위한 속도의 희생입니다. 단순한 작업은 빠릅니다 (경량 모드(featherweight mode)는 오버헤드를 건너뜁니다). 복잡한 작업은 더 오래 걸리지만 더 신뢰할 수 있는 결과를 생성합니다.

Argus는 github.com/ArgusTek/Argus 에서 이용 가능한 오픈 소스 (MIT)입니다. releases에서 데스크톱 앱을 다운로드하거나 소스에서 직접 빌드하세요.

질문이나 피드백이 있으신가요? GitHub Issues: https://github.com/ArgusTek/Argus/issues
Discussions: https://github.com/ArgusTek/Argus/discussions

AI 자동 생성 콘텐츠

본 콘텐츠는 Dev.to AI tag의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.

원문 바로가기
0

댓글

0