Conductor 사용법: 맥에서 클로드 코드 병렬로 돌리기

Conductor는 정확히 뭘 해주는 앱인가

Conductor는 Claude Code, Codex, Cursor, OpenCode 같은 코딩 에이전트를 맥에서 "여러 개 동시에" 돌리기 위해 만들어진 macOS 전용 앱이다. Y Combinator 2024 여름 배치 출신 스타트업 Melty Labs가 만들었고, 지금은 10만 명이 넘는 개발자가 쓰고 있다고 밝히고 있다.

터미널에서 claude를 직접 켜서 쓰는 것과 뭐가 다르냐면, 핵심은 "격리"다. Claude Code를 터미널 여러 탭에서 동시에 띄워본 사람은 알겠지만, 같은 프로젝트 폴더에서 에이전트 두 개가 동시에 파일을 건드리면 서로의 변경사항을 덮어쓰거나 diff가 뒤섞이는 문제가 생긴다. Conductor는 작업(task)마다 별도의 git 브랜치와 별도의 작업 디렉터리(워크트리)를 자동으로 만들어줘서, 에이전트 다섯 개를 동시에 돌려도 서로 파일을 침범하지 않는다. 이게 "conductor(지휘자)"라는 이름의 의미다 — 여러 에이전트를 동시에 지휘한다는 것.

설치와 최초 설정

Conductor는 현재 macOS 전용이다. Windows와 Linux는 아직 지원하지 않고, 공식 홈페이지에서 대기자 명단에 이메일을 등록하면 지원 시점에 알려준다.

설치 자체는 단순하다.

Conductor 공식 사이트에서 Download 버튼을 눌러 앱을 받는다.
다운로드된 Conductor.app을 Applications 폴더로 드래그한다.
Conductor를 실행한다.

앱을 처음 열면 필요한 도구와 인증 정보가 갖춰져 있는지 자동으로 점검하는 셋업 체크 화면이 뜬다. 확인하는 항목은 이렇다.

GitHub 인증: 터미널 환경의 GitHub 인증 상태를 확인한다. 직접 확인하려면 터미널에서 gh auth status를 실행하면 된다.
Claude Code 로그인: Claude를 쓸 계획이면 필요하다. 수동으로 로그인하려면 claude /login.
Codex 로그인: Codex를 쓸 경우 codex login.
Cursor API 키: Cursor를 쓸 경우 Settings → Harnesses → Cursor에서 키를 등록한다.

Conductor를 쓰려면 GitHub 인증과 최소 하나의 에이전트 공급자(Claude, Codex, Cursor, OpenCode 중 하나)가 필요하다. 별도의 API 키를 새로 발급받을 필요는 없다 — 이미 갖고 있는 Claude Code 구독이나 Codex 계정을 그대로 붙여서 쓰는 구조(BYO subscription)다.

git worktree로 격리가 이루어지는 원리

Conductor를 이해하는 데 가장 중요한 개념은 git worktree다. git worktree는 하나의 리포지터리에 대해 여러 개의 작업 디렉터리를 동시에 만들 수 있게 해주는 git 자체 기능이다. 리포지터리를 통째로 복사하거나 clone을 여러 번 받는 대신, 같은 .git 객체 데이터베이스(히스토리, refs, remote)를 공유하면서 디스크상의 체크아웃만 워크스페이스별로 따로 갖는 방식이다.

Conductor에서 새 워크스페이스를 만들면 벌어지는 일은 이렇다.

해당 워크스페이스 전용 git worktree가 만들어지고, 그 안에 새 브랜치가 체크아웃된다.
워크스페이스는 보통 ~/conductor/workspaces/<리포지터리 이름>/<워크스페이스 이름> 경로 아래에 생성된다.
에이전트의 파일 수정, 터미널 명령, 셋업/실행 스크립트는 전부 이 워크스페이스 디렉터리 안에서만 일어난다.
채팅 기록, diff, PR 상태, 아카이브 여부는 그 워크스페이스에 그대로 귀속된다.

git은 브랜치 하나를 동시에 두 개의 워크트리에서 체크아웃하는 걸 허용하지 않는다. 즉 워크스페이스 A가 feature-x 브랜치를 쓰고 있으면, 다른 워크스페이스에서 같은 브랜치를 또 체크아웃할 수 없다. 같은 브랜치로 작업을 더 해야 한다면 새 브랜치를 그 브랜치 기준으로 따서 쓰거나, 원래 워크스페이스를 다른 브랜치로 옮긴 뒤에 체크아웃해야 한다.

한 가지 주의할 점은, 새 워크트리는 git이 추적하는(tracked) 파일에서만 시작된다는 것이다. .env.local, 로컬 인증서, 로컬 DB 파일처럼 .gitignore에 들어있는 파일은 자동으로 따라오지 않는다. 이런 파일이 매 워크스페이스마다 필요하면 "Files to copy" 설정(.worktreeinclude 방식의 패턴 매칭)으로 지정해두거나, 의존성 설치·코드 생성·심볼릭 링크 같은 명령이 필요하면 셋업 스크립트를 등록해두면 새 워크스페이스가 생성될 때마다 자동으로 실행된다.

여기서 중요한 오해 하나는 바로잡을 필요가 있다. 워크스페이스 격리는 어디까지나 개발 상태의 격리이지 보안 경계가 아니다. 에이전트와 명령어는 결국 여러분 맥에서 여러분 사용자 권한으로 실행된다. 샌드박스가 아니라 "충돌 방지" 장치라고 이해하는 게 맞다.

실제로 워크스페이스를 만들고 병렬로 돌리는 흐름

Conductor를 설치했다면 다음 순서로 첫 워크스페이스를 만들면 된다.

리포지터리 추가: Open project(로컬 폴더 선택), Open GitHub project(깃허브에서 선택), Quick start(새 리포지터리 생성) 중 하나를 고른다.
워크스페이스 생성: 리포지터리를 추가하면 Conductor가 자동으로 첫 워크스페이스를 만든다. 이후 ⌘⇧N(Command+Shift+N)이나 New workspace 버튼 옆의 ... 아이콘으로 워크스페이스를 추가로 만들 수 있다. 브랜치, PR, GitHub 이슈, Linear 이슈 중 어느 것을 기준으로 시작할지 선택할 수 있다.
실행 가능하게 만들기: 의존성 설치나 .env 파일처럼 git이 추적하지 않는 것들은 셋업 스크립트로 처리하고, 앱/서버/테스트를 띄우는 실행 스크립트를 등록해둔다. 실행 스크립트는 CONDUCTOR_PORT 환경변수를 쓰도록 만들어두면 워크스페이스 여러 개를 동시에 띄워도 포트가 겹치지 않는다.
작업 시작: 워크스페이스 안에서 Claude Code, Codex, Cursor, OpenCode 중 원하는 에이전트와 채팅을 시작한다. 파일, 폴더, 코멘트를 멘션해서 컨텍스트를 붙여주고, 커밋되지 않은 인수인계 메모는 .context 폴더에 남겨둘 수 있다.

여기서부터가 "병렬"의 핵심이다. 이슈 세 개를 동시에 처리하고 싶으면 워크스페이스를 세 개 만들고, 각 워크스페이스에서 서로 다른 에이전트(혹은 같은 에이전트의 다른 세션)를 띄우면 된다. 한 워크스페이스에서는 기능 A를 구현하는 동안, 다른 워크스페이스에서는 버그를 조사하고, 또 다른 워크스페이스에서는 실험적인 리팩터링을 해볼 수 있다. 각각 독립된 브랜치·작업 디렉터리·터미널 상태를 가지므로 서로 방해받지 않는다.

한 워크스페이스에 몰아넣을지, 여러 워크스페이스로 쪼갤지

이게 실무에서 제일 헷갈리는 지점인데, Conductor 공식 문서가 제시하는 판단 기준은 명확하다.

여러 워크스페이스를 쓸 때(독립적으로 진행되는 작업):

서로 독립적인 기능 개발
따로 배포 가능한 버그 수정
GitHub 이슈, Linear 이슈, PR 단위 작업
버릴 수도 있는 실험
별도의 앱 프로세스나 테스트 실행이 필요한 작업

한 워크스페이스를 쓸 때(같은 브랜치·같은 컨텍스트를 공유해야 하는 작업):

한 에이전트가 구현하는 동안 다른 에이전트가 같은 diff를 리뷰
한 에이전트가 코드를 바꾼 뒤 다른 에이전트가 깨진 테스트를 고치는 경우
반드시 함께 배포돼야 하는 프론트엔드/백엔드 변경
같은 브랜치에 대한 멀티 에이전트 리뷰

기준은 단순하다. 결과물이 독립적으로 머지될 수 있으면 워크스페이스를 나누고, 같은 브랜치·같은 최신 파일 상태를 공유해야 하면 한 워크스페이스 안에서 에이전트를 여러 개 굴린다.

이슈에서 PR까지: 실전 워크플로우

Conductor가 그리는 전체 흐름은 "워크스페이스는 위임의 단위, 브랜치와 PR은 통합의 단위"라는 문장으로 요약된다. 실제 진행 순서는 이렇다.

처리할 작업을 리뷰 가능한 단위로 쪼갠다. 한 워크스페이스가 하나의 shippable unit을 갖는 게 이상적이다.
shippable unit마다 워크스페이스를 만든다.
각 워크스페이스에서 에이전트를 독립적으로 돌린다. 프로젝트 전체에 적용되는 규칙은 Repository Settings나 리포지터리에 커밋된 지침 파일로, 작업별 컨텍스트는 채팅과 .context로 관리한다.
⌘⇧D(Command+Shift+D)로 Diff Viewer를 열어 변경된 파일을 검토한다. 특정 줄에 코멘트를 남기면 그게 그대로 에이전트에게 다시 전달되는 컴포저 첨부로 바뀐다. Checks 탭에서 git 상태, CI, 배포, 코멘트, 할 일 목록을 한 번에 확인할 수 있다.
문제가 없으면 ⌘⇧P(Command+Shift+P)로 PR을 연다. Conductor가 PR 설명 초안을 도와주고, 리뷰 코멘트에 응답하거나 실패한 체크를 고치는 것도 도와준다.
PR이 승인되고 체크가 통과하면 머지하고, 다 쓴 워크스페이스는 아카이브한다. 나중에 필요하면 사이드바의 History에서 채팅 기록까지 그대로 복원할 수 있다.

요금제: 로컬만 쓸 거면 사실상 무료

Conductor 요금제는 네 단계다.

Free ($0): 여러 코딩 에이전트를 병렬로 실행, 맥 위에서 도는 로컬 워크스페이스, 기존에 갖고 있는 구독이나 API 키를 그대로 연결해서 사용. 여기까지 지금까지 설명한 워크트리 기반 병렬 작업 전부가 포함된다.
Pro ($50/월): Free의 모든 기능에 더해 Conductor Cloud(클라우드 워크스페이스), Conductor API, 모바일 앱(출시 예정)이 추가된다. 클라우드 워크스페이스는 8코어 CPU/16GB RAM 사양의 격리된 microVM에서 도는데, 맥을 꺼도 작업이 계속 진행된다는 게 로컬 워크스페이스와의 결정적 차이다.
Teams ($60/월/사용자): Pro 기능에 멀티플레이어(워크스페이스를 팀원과 실시간 공유), 관리자 포털, 통합 청구가 추가된다.
Enterprise (맞춤형): DPA, PO 기반 청구, SCIM 프로비저닝, SLA 등 조직용 기능.

즉 "conductor mac에서 무료로 쓸 수 있나"에 대한 답은 명확히 그렇다이다. 로컬 워크트리 기반 병렬 작업만 쓸 거라면 Free 플랜으로 충분하고, 이 글에서 다룬 기능 전부가 Free 범위 안에 있다. 클라우드 샌드박스에서 맥을 끄고도 에이전트를 계속 돌리고 싶을 때만 Pro가 필요해진다.

Conductor vs 그냥 Claude Code, 언제 쓸 가치가 있나

터미널에서 Claude Code 하나만 켜놓고 순차적으로 작업하는 방식과 비교했을 때 Conductor가 확실히 이득인 상황은 이렇다.

동시에 처리할 독립적인 작업이 실제로 여러 개 있을 때. 이슈 트래커에 쌓인 티켓 서너 개를 병렬로 굴리고 싶다면 워크트리 격리 없이는 파일 충돌을 손으로 관리해야 한다.
리뷰-수정 루프를 시각적으로 관리하고 싶을 때. Diff Viewer에서 줄 단위 코멘트를 남기고 그게 그대로 에이전트에게 전달되는 흐름은 터미널만으로는 재현하기 번거롭다.
PR까지의 흐름을 자동화하고 싶을 때. PR 생성, 체크 추적, 머지까지 한 앱 안에서 관리된다.

반대로 Conductor가 오버헤드로 느껴지는 상황도 있다. 작업이 하나뿐이고 순차적으로 진행해도 무방하다면, 그냥 터미널에서 claude를 켜는 쪽이 더 가볍다. git worktree 자체를 수동으로 관리하는 데 이미 익숙한 팀이라면 Conductor 없이도 비슷한 워크플로우를 셸 스크립트로 짤 수 있다. Conductor의 가치는 "그 워크트리 관리 작업을 자동화하고, 여러 에이전트의 상태를 한 화면에서 보여준다"는 데 있지, 워크트리라는 개념 자체를 발명한 게 아니다.

자주 쓰는 단축키와 세부 설정

매번 마우스로 메뉴를 뒤지지 않으려면 아래 단축키 정도는 외워두는 게 좋다.

⌘⇧N (Command+Shift+N): 새 워크스페이스 생성. ... 버튼을 누르면 브랜치, PR, GitHub 이슈, Linear 이슈 중 무엇을 기준으로 시작할지 고를 수 있다.
⌘⇧D (Command+Shift+D): Diff Viewer 열기. 변경된 파일을 좌측 목록에서 옮겨 다니고, 통합(unified) diff 보기나 커밋 단위 필터링도 지원한다.
⌘⇧P (Command+Shift+P): 현재 워크스페이스 변경사항으로 PR 만들기.
⌘⇧C (Command+Shift+C): 워크스페이스 공유 링크 생성. 최근 추가된 멀티플레이어 기능으로, 팀원을 초대해 같은 워크스페이스에서 함께 프롬프트를 보내거나 진행 상황을 지켜볼 수 있다(Teams 플랜부터 제공).

워크스페이스마다 반복해서 설정할 필요 없이 팀 전체가 같은 값을 쓰도록 하려면 셋업 스크립트와 실행 스크립트를 리포지터리 설정(Repository Settings)에서 관리하거나, .conductor/settings.toml 파일에 커밋해서 팀원 전체가 공유하게 만들 수 있다. 만약 프로젝트가 워크스페이스 디렉터리에서 그대로 실행되기 어려운 구조라면(예: 절대 경로에 의존하는 레거시 빌드 스크립트) Spotlight testing이라는 대안 실행 방식도 제공한다.

리뷰 단계에서 신경 써야 할 것들

Diff Viewer는 단순히 변경 파일을 보여주는 창이 아니다. 코드 리뷰에 필요한 체크리스트를 그대로 반영하도록 설계돼 있다. 실제로 머지 전에 확인해야 할 항목은 다음과 같다.

에이전트가 건드린 파일 목록에 의도치 않은 파일이 섞여 있지 않은지
테스트나 문서가 누락되지 않았는지
로컬 코멘트와 GitHub 리뷰 코멘트가 모두 해결됐는지
충돌이 나거나 수동 확인이 필요한 파일이 있는지

특정 줄에 코멘트를 남기면 일반 채팅 메시지보다 훨씬 구체적인 컨텍스트로 에이전트에게 전달된다. GitHub에서 달린 리뷰 코멘트도 Conductor 안에서 그대로 보이고, 처리가 끝나면 스레드를 resolve 표시해두면 Checks 탭에 반영된다. Checks 탭은 git 상태, CI 결과, 배포 상태, 남은 코멘트, 할 일 목록을 한 화면에서 보여주는 역할을 하는데, 머지 버튼을 누르기 전 마지막 점검 지점으로 쓰면 된다.

보안 관점에서 알아둘 점

워크스페이스 격리를 "샌드박스"로 오해하고 민감한 작업을 맡기는 경우가 있는데, Conductor 문서는 이 부분을 명확히 하고 있다. 워크스페이스 격리는 개발 상태(파일, 브랜치, 프로세스)를 나누는 장치이지 시스템 권한을 제한하는 보안 경계가 아니다. 에이전트와 셋업/실행 스크립트는 결국 사용자 계정 권한으로 맥에서 직접 실행된다. 별도의 보안 설정을 걸지 않는 한 에이전트가 로컬 파일 시스템 전체에 접근할 수 있다는 전제로 프로젝트를 셋업하는 게 안전하다. 반대로 Conductor Cloud의 클라우드 워크스페이스는 격리된 microVM에서 도는 별개의 실행 환경이라, 로컬 워크스페이스보다 시스템 접근이 제한적이다.

결론적으로 Conductor는 Claude Code를 대체하는 도구가 아니라, Claude Code(그리고 Codex, Cursor, OpenCode)를 "여러 개 동시에, 안전하게" 돌리기 위한 오케스트레이션 레이어다. 무료 플랜만으로 로컬 병렬 작업의 핵심 기능을 전부 쓸 수 있으니, 동시에 처리할 작업이 두세 개 이상 쌓여있는 사람이라면 설치해서 워크스페이스 두 개만 만들어봐도 차이가 바로 체감될 것이다.