피드로 돌아가기
Part 2: what changed when I stopped treating my multi-agent system as an idea and started running it for real
Dev.toDev.to
Backend

agentflow가 개념적 설계에서 실제 실행 중심의 런타임으로 전환하면서 권한 관리, 프로바이더 호환성, 오케스트레이션 차이 같은 구체적 문제들 발견

Part 2: what changed when I stopped treating my multi-agent system as an idea and started running it for real

Ricardo Lara2026년 3월 28일8advanced

Context

멀티-에이전트 시스템을 다이어그램과 설명으로만 설계했을 때는 책임 분리, 단계별 모델 사용, 인간 승인 같은 개념적 장점이 명확했으나, 실제 실행 단계에서 권한, 프로바이더 간 동작 불일치, 대화형 프로세스, 설정 劣化, 오케스트레이션 결정 등이 문제로 드러났다.

Technical Solution

  • 파이프라인 중심 사고를 런타임 중심으로 전환: 설정이 생성해야 할 것에서 각 역할이 어떻게 실행되는지(프로바이더, 모델, 샌드박스, 프롬프트)를 명시하도록 변경
  • Claude 어댑터의 권한 플래그 매핑 수정: workspace-write를 --dangerously-skip-permissions로, read-only를 --permission-mode plan으로 번역
  • 복잡도 기반 분류 역할 추가: 작은 작업은 전체 파이프라인을 거치지 않고, 중간/큰 작업만 전체 검토 루프와 모델 조정을 적용
  • CLI 모드와 대화형 세션의 오케스트레이션 분리: 자동화/CI용 결정적 실행과 인간 승인이 필요한 대화형 세션을 다른 방식으로 처리
  • 부트스트랩 스킬 강화: 에이전트가 작업 분류, 계획 제시, 승인 대기, 컨텍스트 기반 진행 판단을 할 수 있도록 문맥 제공

Key Takeaway

멀티-에이전트 아키텍처는 설계가 완성되었을 때가 아니라 기본 기능들이 실제로 작동할 때 준비된 것이며, 이론이 아닌 실제 실행을 통해 권한, 프로바이더 호환성, 오케스트레이션 같은 구체적 격차를 발견하고 수정해야 한다.


멀티-에이전트 시스템을 설계할 때, 다양한 AI 프로바이더(Claude, Codex, OpenCode 등)와 통합하는 팀은 각 프로바이더가 CLI 플래그, 권한 모델, 샌드박스 기능을 다르게 구현한다는 점을 미리 파악하고, 각각의 어댑터에서 이를 정규화해야 권한 요청 반복, 오케스트레이션 실패 같은 런타임 문제를 줄일 수 있다.

원문 읽기
Part 2: what changed when I stopped treating my multi-agent system as an idea and started running it for real | Devpick