왜 여러 AI 코딩 에이전트를 실행하면 혼돈이 발생하는가 (그리고 우리가 이를 해결하는 방법)

Source: Dev.to

꿈: 병렬 AI 코딩

복잡한 작업이 있습니다 — 인증 모듈을 리팩터링해야 하는데, 이 모듈은 API, 프론트엔드, 테스트, 문서 전반에 걸쳐 12개의 파일을 건드립니다.

단일 AI 에이전트(Claude, Copilot, Cursor)는 20‑30분이 걸립니다. 컨텍스트 제한에 걸릴 수도 있고 파일을 순차적으로 처리합니다.

그래서 생각합니다: “터미널 5개를 열고 작업을 나눠서 할 거야.”

현실: 5분간의 혼돈

• Terminal 1: auth.rs 리팩터링 시작

• Terminal 3: 역시 auth.rs 편집 시작 → ❌ 파일 충돌. 하나가 다른 것을 덮어씀.

• Terminal 4: api.rs의 함수를 임포트하는 테스트 작성

• Terminal 2: 아직 그 함수를 작성하지 않음 → ❌ 의존성 실패.

• Terminal 5: /auth/login 엔드포인트 문서화

• Terminal 3: 이를 /auth/signin으로 이름 변경 → ❌ 구식 참조.

조정 없이 병렬 AI 코딩은 순차 작업보다 더 나쁩니다. 실행 시간은 절약하지만 충돌 해결에 시간을 잃게 됩니다.

기존 솔루션이 맞지 않는 이유

• 멀티‑에이전트 프레임워크 (AutoGen, CrewAI, LangGraph):
  에이전트 간 대화를 조정하는 데는 좋지만 파일 잠금, 의존성 순서, 코드베이스 수준 충돌 방지는 하지 못합니다.

• 수동 조정:
  스케줄러가 되어 어떤 터미널이 어떤 파일을 작업할지, 충돌을 확인하고 의존성을 관리해야 합니다. 결국 병목이 됩니다.

• 단일 에이전트:
  안전하지만 느림. 병렬성이 없고 큰 작업에서는 컨텍스트 제한에 걸립니다.

실제로 필요한 것

• 작업 분해: 모호한 요청을 구체적이고 병렬화 가능한 하위 작업으로 나누기.
• 의존성 관리: 어떤 작업이 다른 작업보다 먼저 완료돼야 하는지 파악하기.
• 파일 잠금: 두 작업자가 동시에 같은 파일을 편집하지 못하도록 방지하기.
• 모니터링: 모든 작업자가 실시간으로 무엇을 하고 있는지 보기.
• 복구: 수동 개입 없이 실패를 처리하기.

이 요구사항들은 지능이 아니라 결정론적 오케스트레이션을 필요로 합니다.

우리의 접근법: Jupiter

우리는 Jupiter를 만들고 있습니다 — 병렬 AI 코딩 에이전트를 위한 Rust 기반 오케스트레이션 엔진. 한 번의 명령. N개의 워커. 충돌 제로.

핵심 통찰: 오케스트레이션에는 AI가 필요 없다. 스케줄링, 잠금, 모니터링, 라우팅은 모두 Rust(토큰 0)로 구현하는 결정론적 작업입니다. Claude는 계획 수립과 코드 작성을 위해서만 사용됩니다.

추가 아키텍처 상세는 이번 주에 공개될 예정입니다.

Website:
Discord: