1. 핵심 요약
-
Mac 전용 에이전트 IDE
- 로컬에서 레포를 클론하고, 각 에이전트에 격리된 워크스페이스(worktree)를 배정
-
병렬 에이전트 실행
- Claude Code / Codex 에이전트를 여러 개 띄워 “팀처럼” 작업 분배
-
리뷰·머지에 초점
- 어떤 에이전트가 무엇을 고치는지 UI에서 한눈에 보고, 변경사항을 비교·머지
-
git worktree 기반
- 각 워크스페이스 = 새로운 git worktree
→ 기존 브랜치/히스토리와 자연스럽게 연동
- 각 워크스페이스 = 새로운 git worktree
-
결제/액세스는 기존 Claude 계정 재사용
- Claude Code에 이미 로그인/키 설정돼 있으면 그대로 사용
2. 왜 쓸 만한가 (개발자 관점)
2.1 “한 에이전트=한 탭” 시대에서 “여러 에이전트=한 오케스트라”로
기존 코딩 도우미 툴들은 대부분:
- 하나의 에이전트가
- 하나의 워크스페이스에
- 순차적으로 작업
Conductor는:
- 여러 Claude Code·Codex 인스턴스를 동시에 띄우고
- 각자 다른 브랜치(worktree)에서
- 병렬로 태스크를 수행하게 한다.
즉, “한 명의 시니어 개발자 + 여러 주니어 개발자” 모델을,
UI 차원에서 직접 지원하려는 시도다.
2.2 git 브랜치/PR 관리 지옥을 줄여줌
에이전트 여러 개 쓰다 보면:
- 각 에이전트가 바꾼 파일이 어디까지인지
- 무엇이 겹치고, 무엇이 독립적인지
- 어떤 변경이 머지될 준비가 됐는지
를 사람이 수동으로 관리해야 한다.
Conductor는:
- 각 에이전트 작업을 분리된 git worktree로 격리
- UI에서 “에이전트별 작업 단위”로 보여 줌
- 리뷰 후 머지 플로우까지 UI로 정리
→ “에이전트가 바꾼 걸 PR처럼 다루는” 감각에 가깝다.
2.3 완전 로컬 실행
-
사용자가 레포를 추가하면
- Conductor가 Mac 로컬로 클론
- 모든 작업은 로컬에서 수행
-
민감한 소스 코드가 외부 서버로 올라가는 구조가 아님
(물론 에이전트가 통신하는 대상 API/서비스는 별도)
→ 기업/스타트업 코드베이스에 적용할 때 심리적 저항을 줄이는 구조다.
3. 어떻게 동작하는가 (What)
설명 페이지 기준으로 Conductor의 기본 플로우는 다음 세 단계다.
3.1 1단계: 레포 추가(Add your repo)
-
사용자: Git URL 또는 로컬 경로로 레포를 추가
-
Conductor:
- 해당 레포를 로컬에 클론
- 이 클론을 기준으로 여러 worktree를 생성해 에이전트 워크스페이스를 만들 준비
핵심 포인트:
- 원격 레포 구조를 그대로 유지하면서 에이전트별 실험 브랜치(워크스페이스)를 관리한다는 점
3.2 2단계: 에이전트 배치(Deploy agents)
-
지원 에이전트:
- Claude Code
- Codex
(다른 에이전트를 원하면 이메일로 제안하라고 명시)
-
각 에이전트를 하나 띄울 때마다:
- 새로운 git worktree 생성
- 해당 worktree 위에서만 변경 작업 수행
결과적으로:
- “Agent A = 리팩터링 전담”
- “Agent B = 타입 보강”
- “Agent C = 테스트 작성”
같은 식으로 역할을 나눠 동시에 돌리기가 가능해진다.
3.3 3단계: Conduct (오케스트레이션 + 리뷰)
UI에서 제공하는 것:
-
에이전트별:
- 현재 어떤 파일/기능을 작업 중인지
- 어떤 변경이 발생했는지
-
리뷰 플로우:
- diff 확인
- 필요하면 수동 수정
- 최종적으로 메인 브랜치/메인 worktree에 머지
정리하면:
- Conductor는 “에이전트가 만든 변경사항을 보여주는 Git UI + 작업 대시보드” 역할을 한다.
4. 기술적 포인트
4.1 git worktree 기반
FAQ에서 명시:
“Does Conductor use worktrees? Yes, each Conductor workspace is a new git worktree.”
의미:
- 기존 브랜치 기반 워크플로우와 자연스럽게 연결
- 각각의 에이전트 작업은 독립된 worktree → 충돌 감소
- 필요시 각 worktree를 별도 브랜치로 승격하거나, CI에 물리기도 수월
4.2 지원 에이전트 및 결제 방식
지원 에이전트
- Claude Code
- Codex
확장성:
- 다른 에이전트 추가 요청은 이메일로 받는다고 명시
- 초기 버전 기준으로는 에이전트 종류보다 “오케스트레이션 경험”에 더 초점이 있는 상태
결제/인증
“Conductor uses Claude Code however you're already logged in.”
요약하면:
- Claude Code 웹/앱에 로그인 돼 있으면 그 세션을 재사용
- API 키 기반 로그인도 사용 가능
- Claude Pro/Max 플랜도 그대로 활용
즉, Conductor 자체가 과금 엔진이 아니라,
기존 Claude Code 이용권을 위에서 사용하는 클라이언트라는 구조다.
5. UX 방향성 (미래 지향적인 포인트)
페이지에서 반복적으로 강조되는 키워드:
- “agent-first”
- “agent orchestra”
- “agent orchestration”
Conductor가 지향하는 UX는 대략 이렇다:
- 개발자는 직접 코드 한 줄 한 줄 치기보다는,
- 여러 에이전트에게 태스크를 할당·분산하고,
- 결과물을 리뷰·조율하는 지휘자 역할에 집중한다.
기존 IDE가 “코드를 편집하는 도구”였다면,
Conductor는 “코드를 편집하는 에이전트를 지휘하는 도구”라는 포지션에 가깝다.
6. 제약 및 고려사항
-
Mac 전용
- 현재 페이지 기준으로 Mac용 다운로드만 언급
- Windows/Linux는 미지원 또는 향후 계획 단계로 추정
-
Claude/Codex에 종속
-
지금 시점의 설명 기준:
- Claude Code + Codex 중심
- 다른 모델을 쓰려면 별도 도구가 필요
-
-
로컬 환경 의존
- 모든 작업은 Mac 로컬에서 수행
- CI·원격 개발환경과 연결하려면 별도 설계 필요
7. 정리
Conductor는 다음과 같은 상황에 특히 잘 맞는다:
- Mac 환경에서
- Claude Code / Codex를 이미 적극적으로 쓰고 있고
- 하나의 코드베이스에서 여러 태스크를 병렬로 돌리며,
그 결과를 git 단위로 관리·리뷰하고 싶은 경우
즉, “코드 작성은 에이전트, 설계·리뷰는 사람” 구조를 전제로 할 때
IDE 레벨에서 이 역할 분담을 깔끔하게 지원해 주는 도구다.
참고 - Conductor
