Sharkly vs. Conductor: 팀이 커질 때 병렬 에이전트는 어디서 실행될까

여러 코딩 에이전트를 동시에 실행하는 이야기가 나오면, 대부분의 사람들이 가장 먼저 떠올리는 도구가 Conductor입니다. 그럴 만한 자격이 있습니다. 네이티브 Mac 앱, 격리된 워크스페이스에서 실행되는 에이전트, 깔끔하게 검토할 수 있는 diff, 그리고 예전에는 이 방식에 필요했던 tmux 곡예가 전혀 필요 없습니다.

따라서 유용한 비교는 "어느 쪽이 병렬 에이전트를 실행하는가"가 아닙니다. 둘 다 합니다. 핵심은 작업이 더 이상 개발자 한 명의 오후 작업으로 끝나지 않을 때 벌어지는 일입니다. 두 번째 사람이 실행 결과를 봐야 할 때, Windows를 쓰는 동료가 합류할 때, 에이전트가 노트북이 아닌 머신을 필요로 할 때, 그리고 계획이 워크스페이스 목록이 아닌 다른 곳에 있어야 할 때 말이죠. 이 가이드는 그 경계선을 짚고, Sharkly가 오답인 지점을 분명히 밝힙니다.

TL;DR

Conductor는 macOS의 격리된 워크스페이스에서 Claude Code, Codex, Cursor 에이전트를 병렬로 실행합니다. 무료 티어에서는 구독과 키를 직접 가져오면 되고, 유료 티어에서는 Conductor Cloud, API, 팀을 위한 실시간 협업, 엔터프라이즈 ID 제어 기능이 추가됩니다. 문서에 따르면 아직 Windows나 Linux에서는 사용할 수 없습니다. Sharkly는 원격 서버와 컨테이너를 포함해 직접 연결한 Computer에서 macOS, Linux, Windows 전반에 걸쳐 에이전트를 실행하고, 이를 Task, Project, Sprint, Crew, 양방향 Jira 동기화라는 업무 시스템으로 감쌉니다. 팀 전체가 macOS를 쓰고 가장 완성도 높은 네이티브 경험을 원한다면 Conductor가 훌륭한 답입니다. 반대로 실행이 노트북을 벗어나야 하거나 계획이 실행과 함께 있어야 한다면, 그 지점에서 Sharkly가 이어받습니다.

Conductor가 제대로 해낸 것

Conductor는 이제 업계 전체가 당연하게 여기는 사실을 입증했습니다. 병렬 에이전트 작업에는 격리와 검토 화면이 필요하고, 둘 다 셸 의식 같은 절차가 아니라 클릭 한 번으로 해결되어야 한다는 것입니다.

홈페이지에는 제품이 명확하게 소개되어 있습니다. "Mac의 격리된 워크스페이스에서 Claude Code, Codex, Cursor 에이전트를 병렬로 실행하세요." 각 에이전트는 자체 워크스페이스를 부여받으므로, 두 에이전트가 같은 파일을 편집해도 병합 참사가 일어나지 않습니다. 워크스페이스를 만들고, 에이전트를 할당하고, 그 결과로 나온 diff를 검토하는 일은 외워야 하는 명령이 아니라 인터페이스 동작입니다.

가격 정책은 런타임 관계를 솔직하게 반영합니다. 무료 티어는 구독과 키를 직접 가져오는 방식인데, 이는 모델 자체를 실행하지 않는 계층에 맞는 올바른 태도입니다. 유료 티어에서는 Pro에 클라우드 워크스페이스 시간과 Conductor API가 포함된 Conductor Cloud가 추가되고, Teams 티어에는 규모에 관계없는 팀을 위한 실시간 협업, 중앙 집중식 결제, 관리자 포털이 더해집니다. Enterprise에는 데이터 처리 계약, SAML SSO, SCIM, 전담 지원이 포함된 SLA가 추가됩니다.

공정한 비교를 위해서는 마지막 부분이 중요합니다. "Conductor는 개인용 도구"라는 예전 인식은 더 이상 유효하지 않기 때문입니다. 협업과 관리 제어 기능을 갖춘 팀 티어가 있습니다. 이 점을 빼놓은 비교는 뭔가를 팔려는 것입니다.

로컬 러너의 전체 지형이 궁금하다면, Claude Squad, Conductor, tmux 비교 글에서 이런 접근 방식이 실제로 어떻게 다른지 다룹니다.

Mac 네이티브 앱이 한계에 부딪히는 지점

설계에서 비롯되는 세 가지 한계가 있으며, 그중 기능에 관한 것은 하나뿐입니다.

플랫폼. Conductor 설치 문서에는 "Conductor는 아직 Windows나 Linux에서 사용할 수 없습니다"라고 명시되어 있습니다. 전원 Mac인 팀에게는 문제가 되지 않습니다. 하지만 Windows 개발자, Linux 워크스테이션, 또는 CI에 가까운 빌드 머신이 있는 팀이라면 기능 비교를 시작하기도 전에 결론이 나버립니다.

실행 호스트. 워크스페이스는 앱이 실행되는 곳에서 돌아갑니다. Conductor Cloud가 유료 티어에 호스팅 워크스페이스 시간을 추가해 이 점을 다소 완화하지만, 로컬 모델은 여전히 개발자 머신을 중심으로 합니다. VPN 경로, 시드된 데이터베이스, GPU가 있는 머신이 필요한 에이전트 작업에는 다른 종류의 호스트가 필요하며, 그건 보통 노트북이 아닙니다.

작업 단위. 워크스페이스는 세션입니다. "이 에이전트, 이 브랜치, 이 diff"에는 좋은 추상화입니다. 하지만 백로그 항목은 아닙니다. 우선순위, 스프린트 소속, 인수 조건, 다른 사람이 해결해야 할 블로커, 3주 전에 리뷰어가 내린 결정의 이력을 담지 못합니다. 그런 것이 필요한 팀은 이를 다른 곳에 보관하게 되고, 결과적으로 계획과 실행이 서로 어긋나는 두 시스템에 나뉘어 존재하게 됩니다.

이 중 어느 것도 결함이 아닙니다. 집중된 로컬 도구의 형태일 뿐이고, 그 집중 덕분에 사용하기 즐거운 것입니다.

선택 기준 두 가지

Conductor를 쓰세요 — 모두가 macOS를 쓰고, 원하는 에이전트가 Claude Code, Codex, Cursor이며, 작업이 개발자 머신이나 호스팅 워크스페이스 시간으로 충분히 돌아가고, 계획이 이미 만족스러운 트래커에 자리 잡고 있을 때입니다. 실시간 협업이 있는 네이티브 앱은 업무 시스템보다 가볍고, 가벼움 자체가 장점입니다.

Sharkly를 쓰세요 — 실행이 노트북 밖에서, 또는 여러 플랫폼에 걸쳐 이루어져야 할 때, 혹은 팀이 계획, 실행, 검토를 하나의 기록 안에서 관리하고 싶을 때입니다.

차이를 만들어내는 정의는 이렇습니다. Sharkly의 Computer는 에이전트 작업을 위한 실행 호스트를 제공하며, 로컬 컴퓨터, 원격 서버, 컨테이너, 또는 지원되는 클라우드 호스트가 될 수 있습니다. 작은 로컬 서비스가 Computer를 Sharkly에 연결하고, 사용 가능한 Runtime을 감지하고, 작업을 받아, 태스크 디렉터리를 준비하고, 선택된 Runtime을 시작한 뒤 진행 상황을 다시 스트리밍합니다.

이 분리가 설계의 전부입니다. Agent는 작업을 어떻게 처리할지 정의합니다. Computer는 호스트와 로컬 리소스를 제공합니다. Runtime은 실제 에이전트 세션을 수행합니다. Task는 팀을 위한 공유 기록으로 남습니다.

업무 시스템이 더하는 것

병렬 격리에 이미 만족하고 있다면, 이 섹션이 계속 읽을 유일한 이유입니다.

작업에는 세션보다 오래 살아남는 집이 생깁니다. Task는 주요 작업 단위입니다. Organization과 Space에 속하며, Project나 Sprint에 속할 수도 있습니다. 목표와 설명, 상태, 우선순위, 날짜, 레이블, 작업 유형, 담당자, 실행을 맡은 Agent 또는 Crew, 댓글과 첨부 파일, 에이전트 실행 상태와 트레이스, 결과를 기록합니다. 실행이 멈추면 그 멈춤은 Task에 남아, 내일 이어받을 사람이 찾을 수 있습니다.

에이전트 설정이 팀 자산이 됩니다. Agent는 일회성 프롬프트가 아니라 저장된 작업 구성입니다. 지침, Runtime, Skill, 저장소, 환경, 실행 설정이 포함됩니다. 팀은 코드 변경, 리뷰, 테스트, 문서화, 운영 트리아지를 위한 별도의 Agent를 유지하면서 매번 같은 지침을 다시 작성할 필요가 없습니다. 코딩 에이전트 Skill이 무엇인지 다룬 해설에서 재사용 가능한 지침 부분을 확인할 수 있습니다.

조정이 필요할 때 구조가 생깁니다. Crew는 한 명의 리더 Agent가 조율하는 재사용 가능한 People과 Agent의 그룹으로, 역할 기반 협업, 순서 제어, 또는 다음에 어떤 Agent가 행동할지 리더가 결정하는 것이 도움이 되는 작업에 쓰입니다. Agent 하나로 충분할 때는 하나만 쓰세요. Crews 가이드는 언제 Crew를 꺼내지 말아야 하는지 분명히 설명합니다.

트래커는 계속 연결되어 있습니다. Sharkly의 Jira 연동은 Jira Cloud와 Jira Server 또는 Data Center를 지원하며, 가져오기, 단방향 동기화, 양방향 동기화로 Jira 프로젝트를 Space에 연결할 수 있습니다. Jira를 떠날 수 없는 팀은 떠나지 않아도 됩니다.

Runtime은 확장 가능합니다. 로컬 서비스가 원하는 실행 기능을 감지하지 못하면 Computer 상세 화면에서 사용자 정의 ACP Runtime을 추가할 수 있습니다. 아이콘, 이름, 시작 명령을 설정하고 저장한 뒤 Test connection을 선택하면 됩니다.

구체적인 사례

12명 규모의 팀이 웹 앱과 사내 데이터 서비스를 운영합니다. 개발자 8명은 Mac을, 2명은 Windows를 쓰고, 나머지 2명은 데이터 파이프라인이 있는 Linux 서버에서 SSH로 대부분의 작업을 합니다.

Mac을 쓰는 8명은 로컬에서 병렬 에이전트를 실행하는 데 만족했습니다. 나머지 4명은 합류할 수 없었고, 그것이 진짜 문제였습니다. 도구가 팀이 일하는 방식이 아니라 8명이 일하는 방식을 설명하고 있었던 것입니다.

이들은 하드웨어를 통일하는 대신 Computer를 연결했습니다. 노트북 여러 대와, 이미 파이프라인 환경과 스테이징으로 가는 네트워크 경로가 갖춰진 Linux 서버를 함께 연결한 것입니다. 파이프라인이 필요한 작업은 그곳에서 돌아갑니다. 개발자의 로컬 설정이 필요한 작업은 해당 노트북에서 실행됩니다. Windows 개발자도 같은 방식으로 연결합니다.

각 실행에는 여전히 격리된 워크트리가 주어지는데, 이는 이들이 포기하지 않으려던 부분입니다. 격리된 워크트리에서 병렬 에이전트를 실행하는 방법을 다룬 가이드에서 동시 실행을 안전하게 만드는 원리를 확인할 수 있습니다.

달라진 것은 리뷰어가 보는 화면입니다. 누군가의 머신에서 diff가 튀어나오는 대신, Task가 목표, 실행한 Agent, 실행된 Computer, 트레이스, 블로커, 논의를 보여줍니다. 스탠드업에서는 8개의 개별 워크스페이스 목록이 아니라 스프린트를 봅니다.

Sharkly vs Conductor: 공정한 비교

흔한 실수

병렬성만 놓고 비교하기. 둘 다 병렬 실행을 잘 격리합니다. 그 기능만으로 결정하면 아무것도 알 수 없습니다. 플랫폼 지원 범위, 실행 호스트, 그리고 계획이 실행과 함께 있어야 하는지를 기준으로 결정하세요.

낡은 "개인용 도구" 프레임 사용하기. Conductor에는 실시간 협업과 관리자 포털이 있는 Teams 티어가 있습니다. 누군가 팀에는 쓸 수 없다고 한다면, 최근에 확인해보지 않은 것입니다.

필요하지 않은 업무 시스템 추가하기. 모두가 macOS를 쓰고, 계획이 트래커에서 잘 돌아가고, 에이전트가 노트북에서 문제없이 실행된다면 업무 계층은 부담일 뿐입니다. 도입하지 마세요.

도구에 맞춰 하드웨어 통일하기. 도구가 돌아가게 하려고 Mac을 구매하는 결정은 실행하기 전에 따져볼 가치가 있습니다. 특히 일부 작업이 어차피 서버에 속한다면 더욱 그렇습니다.

결론

Conductor는 집중된 아이디어의 최고 형태입니다. 병렬 에이전트, 격리된 워크스페이스, 깔끔한 리뷰, Mac 네이티브, 그 위에 팀 티어까지 갖췄습니다. 팀이 macOS 안에 머물고 계획이 이미 자리를 잡고 있다면, 그 집중은 장점이며 더 무거운 무언가와 맞바꿀 필요가 없습니다.

Sharkly는 다른 질문에 답합니다. 에이전트 작업이 서버에 속할 때 어디에서 실행되는가, 여러 플랫폼이 섞인 팀은 어떻게 합류하는가, 계획이 실행 트레이스 및 사람의 결정과 같은 기록에 어떻게 남는가입니다. Sharkly는 Claude Code, Codex 또는 다른 실행 도구를 대체하지 않습니다. 팀이 이미 쓰는 도구 주위에 공유 Task, Computer, 컨텍스트, 제어, 리뷰 계층을 더해줍니다.

병렬 에이전트 구성이 팀의 일부에만 통한다면, 그것이 바로 빈틈입니다. Sharkly로 시작해서 노트북이 아닌 Computer 하나를 연결하고, Task 하나를 할당해보세요.

FAQ

Conductor는 Windows나 Linux에서 동작하나요? 설치 문서에는 Conductor가 아직 Windows나 Linux에서 사용할 수 없다고 명시되어 있으며, 알림 신청을 안내하고 있습니다. 결정하기 전에 최신 문서를 확인하세요.

Sharkly도 Conductor의 워크스페이스처럼 격리된 워크트리에서 에이전트를 실행하나요? 네. 병렬 에이전트가 충돌하지 않도록 실행이 격리되며, 그 격리는 로컬 워크스페이스 목록이 아니라 공유 Task에 연결됩니다.

Conductor를 계속 쓰면서 Sharkly를 추가할 수 있나요? 네. 다만 작업 건마다 한쪽을 홈으로 정하는 편이 보통 더 깔끔합니다. 개인 작업은 로컬 병렬 실행으로, 팀이 보고 할당하고 리뷰해야 하는 작업은 Sharkly로 나누는 방식이 흔합니다.

Sharkly는 어떤 에이전트를 지원하나요? 연결된 Computer에서 로컬 서비스가 감지하는 모든 Runtime, 그리고 아이콘, 이름, 시작 명령으로 직접 구성한 사용자 정의 ACP Runtime을 지원합니다.

각각 모델 사용료는 누가 부담하나요? 둘 다 사용자에게 맡깁니다. Conductor의 무료 티어는 구독과 키를 직접 가져오라고 안내하고, Sharkly는 해당 도구에 구성된 구독이나 API 키를 통해 모델 사용이 계속된다고 밝히고 있습니다.

Sharkly에 전용 서버가 필요한가요? 아니요. Computer는 노트북이어도 됩니다. 핵심은 꼭 노트북일 필요가 없다는 점이며, 특정 환경이 필요한 작업은 그 환경이 이미 존재하는 곳에서 실행할 수 있습니다.