Claude Squad vs Conductor vs tmux: DIY 에이전트 설정 비교

코딩 에이전트 하나가 너무 느려서 두 개를 동시에 돌리기 시작했습니다. 이제는 다섯 개를 돌리고 있죠. 그런데 어려운 건 에이전트를 띄우는 게 아닙니다. 어느 터미널에 어떤 에이전트가 있는지, 각자가 무엇을 바꿨는지, 어느 브랜치를 병합해도 안전한지, 그리고 40분 전에 조용해진 녀석이 끝난 건지 멈춰버린 건지 기억하는 일이 어렵습니다. 병렬 실행은 손쉬운 승리였습니다. 그걸 계속 추적하는 건 그 이후로 매일 치르는 세금이죠.

DIY 병렬 에이전트 도구들이 줄이려는 게 바로 이 세금입니다. Conductor, Claude Squad, 그리고 직접 짠 tmux와 git worktree 스크립트는 모두 같은 첫 번째 문제를 해결합니다. 각 에이전트에 독립된 워크스페이스를 줘서 여러 실행이 서로의 파일을 건드리지 않고 동시에 움직일 수 있게 하는 것이죠. 이걸 잘 해내고, 한 대의 머신에서 혼자 일하는 개발자라면 이것만으로 충분할 수도 있습니다. 이 글은 각 도구가 무엇을 하는지, 어디서 멈추는지, 그리고 창 관리가 조용히 팀 문제로 바뀌는 경계선이 어디인지 솔직하게 정리합니다.

그 경계선에서 Sharkly가 등장하고, 이 글에서 안내할 워크플로가 바로 그것입니다. Sharkly는 Claude Code나 Codex, 또는 어떤 DIY 러너를 대체하는 게 아닙니다. 이미 쓰고 있는 도구들 주위에 공유 Task, Computer, 컨텍스트, 리뷰 계층을 얹어서, 에이전트 작업이 개인 터미널 속으로 사라지지 않고 요청부터 릴리스까지 계속 보이게 만듭니다. 아직 화면 하나에 다 들어오는 환경이라면 그대로 쓰세요. 몇 주 전부터 안 들어오기 시작했다면, 이 글의 후반부가 바로 당신을 위한 겁니다.

TL;DR

Conductor, Claude Squad, 그리고 순수 tmux에 git worktree를 조합하는 방식은 여러 AI 코딩 에이전트를 자신의 머신에서 병렬로 돌리는 세 가지 방법입니다. Conductor는 혼자서 로컬 실행을 하도록 만들어진 무료 Mac 앱입니다. Claude Squad는 tmux 세션과 git worktree 위에 전환기를 얹은 크로스 플랫폼 터미널 앱입니다. 순수 tmux에 worktree 스크립트를 더하면 완전한 통제권과 제로 추상화를 얻습니다. 세 가지 모두 병렬 실행을 완벽하게 해냅니다. 하지만 어느 것도 팀에 공유 가시성이나 리뷰, 인수인계를 제공하도록 만들어지지 않았고, 바로 그 지점에서 Sharkly 같은 오케스트레이션 계층으로 넘어가게 됩니다.

진짜 병목은 병렬성이 아니다

격리는 이미 해결된 문제입니다. git worktree를 쓰면 하나의 리포지토리에서 여러 브랜치를 동시에 별도 디렉터리로 체크아웃할 수 있어서, 각 에이전트가 자기만의 코드 사본을 편집하고 자기 브랜치에 커밋합니다. 공유 워킹 트리도 없고, 반쯤 적용된 diff가 충돌할 일도 없습니다. 이 비교에 등장하는 모든 도구가 이 동일한 원시 기능 위에 서 있습니다. 작동 원리를 자세히 알고 싶다면 AI 코딩 에이전트와 git worktree 가이드에서 명령어와 주의사항을 다룹니다.

그렇다면 격리가 공짜라면, 왜 여러 에이전트를 돌리는 게 여전히 혼란스러울까요? 에이전트가 만들어낸 결과물은 사람이 찾고, 읽고, 판단하고, 조치할 수 있는 어딘가로 가야 하기 때문입니다. 한 대의 머신에서 그 '어딘가'는 자신의 단기 기억과 스크롤백 버퍼뿐입니다. 에이전트 두 개까지는 버팁니다. 다섯 개가 되면 흐트러지기 시작하죠. 두 번째 사람이 당신 에이전트가 뭘 했는지 알아야 하는 순간 무너집니다.

중요한 구분이 여기 있습니다. 에이전트를 병렬로 돌리는 건 런타임 문제입니다. 프로세스를 띄우고, 격리된 디렉터리를 넘겨주고, 일하게 두면 됩니다. 그들이 만들어낸 걸 리뷰하고 조율하는 건 워크플로 문제입니다. 결과물이 어디에 살고, 누가 승인하고, 멈춘 것들은 어떻게 되는지 말이죠. DIY 도구들은 첫 번째 문제에 탁월합니다. 아래 세 섹션에서 각 도구를 나름의 기준으로 평가하고, 그다음 설정이 커지면서 두 번째 문제가 어떻게 되는지 살펴봅니다.

Conductor: 혼자서 병렬 실행하는 무료 Mac 앱

Conductor는 여러 Claude Code 에이전트를 나란히 돌리기 위한 네이티브 Mac 데스크톱 앱입니다. 리포지토리를 지정하고 변경 사항을 설명하면, git worktree를 기반으로 한 각자의 워크스페이스에서 실행을 띄웁니다. 터미널 탭을 이리저리 다루는 대신 창으로 나뉜 뷰를 얻습니다. 에이전트마다 한 칼럼씩, 각자 대화와 diff, 상태를 갖습니다. 채팅을 오가듯 클릭해서 넘나들면 됩니다.

이 앱이 잘하는 건 한 사람을 위한 터미널 부기를 없애주는 것입니다. tmux 명령어를 칠 필요도 없고, 어느 팬이 뭔지 기억할 필요도 없습니다. 앱이 워크트리를 추적하고, 실제 diff 뷰어에서 diff를 보여주며, 위치를 잃지 않고 에이전트 사이를 오갈 수 있게 해줍니다. 하나의 코드베이스에서 Claude Code 세션 서너 개를 돌리면서도 정신을 붙잡고 있고 싶은 Mac의 혼자 개발자라면, 깔끔하고 마찰 없는 답입니다. 무료로 내려받을 수 있고, 서버가 없으니 서버에서 설정할 것도 없습니다.

한계는 이런 강점의 이면입니다. Conductor는 macOS 전용이라 Linux를 쓰는 동료는 당신의 설정을 공유할 수 없습니다. 에이전트를 섞는 게 아니라 Claude Code를 런타임으로 삼는 데 집중해 있습니다. 그리고 단일 사용자 데스크톱 앱입니다. 워크스페이스와 diff, 결정이 전부 당신의 Mac에 살죠. 다른 엔지니어가 당신의 Conductor를 열어 에이전트가 뭘 하는지 볼 수 없고, 누가 어떤 변경을 승인했는지 공유 기록도 없습니다. 이건 결함이 아니라 범위입니다. Conductor는 파일럿 한 명을 위한 조종석입니다.

Conductor를 쓸 때 Mac에서 Claude Code를 돌리는 혼자 개발자로서 '여러 터미널'에서 '차분한 창 하나'로 가는 가장 빠른 길을 원할 때 쓰세요. 다른 걸 찾아야 할 때 두 번째 사람이 그 실행들을 보고, 리뷰하거나, 넘겨받아야 할 때입니다.

Claude Squad: tmux와 worktree 위에 TUI를 얹다

Claude Squad는 격리된 워크스페이스에서 여러 에이전트를 관리하는 오픈소스 터미널 애플리케이션입니다. 내부적으로는 꼼꼼한 엔지니어가 손으로 스크립트를 짤 때 하는 일을 똑같이 합니다. 에이전트마다 git worktree를 만들고 각 에이전트를 자체 tmux 세션 안에서 실행한 다음, 그 위에 텍스트 UI를 얹어서 에이전트 목록을 보고, 아무거나 골라 들어가고, 어떤 게 작업 중인지, 대기 중인지, 끝났는지 확인할 수 있게 합니다. 크로스 플랫폼이라 macOS와 Linux에서 돌아가고, 단일 런타임에 묶여 있지 않습니다. Claude Code, Codex, Aider 및 다른 CLI 에이전트를 구동할 수 있어서 여러 도구를 섞어 쓰는 개발자들에게 인기입니다. 소스는 GitHub의 Claude Squad 리포지토리에 있습니다.

매력은 신뢰하는 원시 요소를 숨기지 않으면서도 진짜 도구의 사용성을 준다는 점입니다. worktree와 tmux가 그대로 남아 있어서 마법 같은 건 없고 모든 게 들여다볼 수 있지만, 접착 코드를 손으로 짜는 일은 그만둬도 됩니다. 새 에이전트를 띄우는 건 키 입력 한 번이지, 세 개 명령어를 치는 의식이 아닙니다. 에이전트를 일시정지하면 자원을 확보하면서 브랜치를 보존합니다. 이미 터미널에서 살고 있고 탭으로 넘겨볼 에이전트 함대를 원한다면, Claude Squad는 순수 스크립트와 데스크톱 앱 모두 놓치는 지점을 정확히 찌릅니다. 여러 Claude Code 에이전트를 병렬로 실행하는 방법 워크스루에서 이 도구가 자동화하는 것과 같은 tmux와 worktree 패턴을 볼 수 있습니다.

한계는 이 도구가 살고 있는 터미널의 한계입니다. 상태는 당신의 머신과 셸에 국한됩니다. 세션을 닫으면 공유된 그림도 함께 닫힙니다. 매니저가 열어볼 타임라인도 없고, 당신 아닌 리뷰어가 변경을 승인하거나 거절할 자리도 없고, 동료가 다음 작업을 가져갈 큐도 없습니다. Claude Squad는 뛰어난 단일 운영자 지휘 센터입니다. 팀의 기록 시스템이 되려 한 적은 없고, 그걸 요구하는 건 잘못된 도구에 요구하는 것입니다.

Claude Squad를 쓸 때 터미널 우선 개발자로서 한 대의 머신에서 여러 에이전트를 섞어 돌리고, worktree와 tmux를 포기하지 않으면서 빠른 전환기를 원할 때 쓰세요. 다른 걸 찾아야 할 때 실행을 다른 사람에게 할당하거나, 당신의 키보드 앞에 앉아 있지 않은 누군가가 리뷰해야 할 때입니다.

순수 tmux + git worktree: 당신이 소유하는 스크립트

가장 솔직한 DIY 설정은 가장 오래된 것이기도 합니다. worktree를 만들고 에이전트마다 tmux 창을 여는 셸 스크립트 몇 개입니다. 대략 이렇게 생겼습니다.

# one worktree and one branch per parallel unit of work
git worktree add ../app-auth    -b feature/auth
git worktree add ../app-billing -b feature/billing

# a named tmux window per agent, launched in its worktree
tmux new-window -n auth    -c ../app-auth    'claude'
tmux new-window -n billing -c ../app-billing 'claude'

기능마다 명령어 두 줄이면 격리된 에이전트들이 각자 자기 브랜치에서 병렬로 돌아가고, 키 입력 한 번으로 넘어갈 수 있는 라벨 붙은 창에 각자 들어갑니다. 이걸 루프로 감싸면 열 개도 띄울 수 있습니다. 당신과 도구 사이에 아무것도 끼어들지 않습니다. 모든 줄을 읽고, 뭐든 바꾸고, 작성하는 시간 말고는 비용이 들지 않죠.

어떤 부류의 개발자에게는 이게 영원한 정답이고, 누군가를 말리는 대신 존중할 가치가 있습니다. 직접 썼으니 뭐가 실행되는지 정확히 압니다. 벤더도 없고, 흐름을 깨뜨리는 업데이트도 없고, 엉뚱한 순간에 새는 추상화도 없습니다. 요구가 안정적이고 개인적이라면, 빌려 쓰는 도구보다 소유한 스크립트가 낫습니다.

비용은 설정이 커지면서 나타나고, 기능이 아니라 유지보수로 나타납니다. 정리는 당신 몫입니다. 오래된 worktree가 쌓여서 git worktree prune과 tmux kill-session 청소가 일과가 될 때까지요. 이름 충돌도 당신 몫입니다. 죽은 에이전트는 죽은 창과 반쯤 끝난 브랜치를 남기고, 그걸 알아채는 것도 당신 몫입니다. 그리고 이 모든 게 당신 머신을 벗어나지 않으니, 동료가 "이번 주에 네 에이전트가 뭘 내놨냐"고 묻는 순간 유일한 답은 스크롤백 속에만 있습니다. 스크립트는 처리량을 확장합니다. 결과를 공유하는 능력은 확장하지 못합니다.

순수 tmux와 worktree 스크립트를 쓸 때 완전한 통제를 원하고, 자기 도구를 소유하는 걸 즐기며, 작업의 대상이 자기 자신일 때 쓰세요. 다른 걸 찾아야 할 때 상태 추적, 정리, 인수인계 로직을 다시 만들고 있는 자신을 발견하고, 그게 의도치 않게 제품처럼 되어갈 때입니다.

나란히 비교: 각 DIY 설정이 잘하는 것

마지막 두 행은 흠이 아닙니다. 패턴입니다. 이 도구들은 하나같이 한 대의 머신에서 한 명의 운영자를 위해 만들어졌고, 그 범위 안에서는 좋음에서 탁월함까지 갑니다. 비어 있는 칼럼은 세 도구 모두 똑같고, 작업이 더 이상 당신 혼자만의 것이 아니게 되는 날 중요한 칼럼이 바로 그것입니다. 이 범주의 더 넓은 지도를 보려면 AI 에이전트 오케스트레이션 개요를 참고하세요.

졸업선: 창 관리가 더 이상 문제가 아닐 때

알아채는 신호가 있습니다. "에이전트를 어떻게 더 많이 동시에 돌리지"라고 묻기를 멈추고, DIY 도구가 답할 수 없는 질문을 하기 시작할 때입니다.

• 내 에이전트의 변경 중 누가 리뷰한 게 있나?
• 내가 병가를 내면 동료가 진행 중인 걸 보고 넘겨받을 수 있나?
• 이 diff는 승인하고 저 diff는 거절한 이유에 대한 기록이 어디 있나?
• 어떤 실행이 무엇 때문에 막혀 있고, 얼마나 오래 막혀 있나?

이건 워크플로 질문이지 런타임 질문이 아닙니다. 더 나은 전환기나 더 예쁜 diff 뷰어가 답하지 못하는 이유는, 빠진 조각이 당신 화면에 있지 않기 때문입니다. 작업이 살아갈 공유 공간인 거죠. 이것이 졸업선입니다. 병목이 창 관리에서 가시성, 리뷰, 인수인계 관리로 옮겨가는 날 말입니다.

Sharkly는 그 선의 반대편을 위해 만들어졌습니다. 컨텍스트, 진행 상황, 블로커, 결과, 사람의 리뷰를 요청부터 릴리스까지 보이게 유지하며, 개인 터미널에 흩어지는 대신 하나의 공유 워크플로에 담습니다. 역할 분담은 의도적입니다. Claude Code, Codex 같은 도구는 실행을 수행하고, Sharkly는 그 도구들 전반에 걸쳐 팀 단위 할당, 연결된 Computer, 작업 컨텍스트, 진행 상황, 블로커, 결과, 사람의 리뷰를 관리합니다. 이미 신뢰하는 런타임과 worktree는 그대로 유지하세요. 둘 이상의 사람이 작업을 보고 방향을 잡을 수 있게 하는 계층을 더하는 겁니다.

안심시키는 부분은 메커니즘만큼 중요합니다. Sharkly를 도입한다고 해서 프로세스를 재구축하거나 도구를 버리라는 요구는 없습니다. 구독은 각자 가져옵니다. 모델 사용량은 팀이 이미 돌리는 도구에 설정된 구독이나 API 키를 통해 계속됩니다. Computer를 연결하고, Sharkly가 같은 리포지토리를 가리키게 하고, 아무것도 허물지 않고 작업 라우팅을 시작하면 됩니다. 이걸 로컬 보드와 저울질하고 있다면, Vibe Kanban 대안 글에서 같은 '가지고 있는 걸 유지하는' 경로를 다룹니다.

같은 병렬 워크플로가 Sharkly에서는 어떻게 보이는가

DIY 도구는 각 에이전트에 worktree와 창을 줍니다. Sharkly는 각 작업 단위에 Task를 주고, 에이전트가 같은 방식으로 격리된 worktree에서 실행하게 합니다. 한 가지 차이가 있습니다. 결과가 스크롤백에 남는 대신 Task로 돌아옵니다.

Task는 Sharkly의 주요 작업 단위입니다. 목표, 범위, diff, 논의, 리뷰를 하나의 공유 기록에 담습니다. Task를 에이전트에게 할당하면 에이전트가 그걸 가져가고, 자체 격리된 worktree에서 작업하고, 타입체크와 테스트, 빌드를 실행한 뒤 변경 요약과 검증 결과, 알려진 한계를 그 Task에 다시 붙입니다. 다음에 보는 사람은 당신의 터미널이 필요 없습니다. Task를 열면 됩니다.

가장 작은 유용한 버전은 일부러 지루합니다. Computer 하나를 연결하고, 에이전트 하나를 만들고, 위험도 낮은 Task 하나를 할당하세요. 첫 Task 워크스루에서 설정하는 방식 그대로입니다. 거기서부터 병렬 이야기는 당신 스크립트가 원했던 방식으로 확장됩니다. 여러 에이전트가 준비된 Task를 가져가 동시에 작업하고, 각자 격리되며, 프런트엔드, 백엔드, 버그 수정, 테스트 커버리지가 병렬로 움직입니다. tmux 창이 가득한 벽과의 차이는 모든 실행을 사람에게 할당할 수 있고, 당신 아닌 누군가가 리뷰할 수 있고, 사후에 추적할 수 있다는 점입니다.

사람-에이전트 계약은 리뷰 계층이 제 역할을 하는 지점입니다. 에이전트는 조사하고, 실행하고, 테스트하고, 보고합니다. 사람은 방향을 정하고, 권한을 부여하고, 결과를 승인합니다. 자동화는 팀의 판단이 필요한 곳에서 멈추고, 완전한 컨텍스트와 검증 가능한 증거를 갖춘 결과물을 돌려줍니다. DIY 설정은 에이전트를 돌릴 수 있습니다. 하지만 그 계약을 지탱할 수는 없습니다. 당신 아닌 사람이 승인하거나 거절할 공유 공간이 없기 때문입니다. 그 게이트의 작동 원리를 알고 싶다면 Cursor 백그라운드 에이전트에 대한 글에서 비슷한 리뷰 흐름을 다룹니다.

팀들이 쓰는 형태의 예시를 들어봅시다. SH-312 같은 작업이 "공개 API에 레이트 리미팅 추가"라고 말합니다. 에이전트가 범위를 잡고, 자기 worktree에서 작업하고, 테스트를 돌리고, 요약과 diff를 Task에 반환합니다. 리뷰어가 SH-312를 열고, 증거를 읽고, 승인하거나 변경을 요청합니다. 혼자일 때는 이 전체 루프가 머릿속과 터미널 하나에 살았습니다. 이제는 팀이 볼 수 있는 어딘가에 살고, 그게 졸업의 전부입니다.

누가 남아야 하고, 누가 이미 넘어섰는가

위로만 권하는 비교는 정직하지 않으니, 솔직한 버전을 말하겠습니다. 많은 사람이 옮기지 말아야 하고, 위의 도구들이 그들에게는 맞는 집입니다.

• Conductor에 남으세요. 혼자 하는 Mac 개발자로서 병렬 Claude Code 실행을 차분한 창에서 원하고, 다른 누구도 그걸 볼 필요가 없다면요. 그 일을 깔끔하게 해내고 서버에 아무것도 요구하지 않습니다.
• Claude Squad에 남으세요. 터미널에서 살고, 여러 런타임을 섞어 쓰고, 자기 작업을 위해 worktree와 tmux 위에 빠른 전환기를 원한다면요. 강력한 단일 운영자 지휘 센터입니다.
• 순수 tmux와 worktree 스크립트에 남으세요. 완전한 통제를 중시하고, 워크플로가 안정적이고, 결과물의 유일한 대상이 자기 자신이라면요. 요구가 개인적일 때는 소유한 도구가 빌린 도구를 이깁니다.
• 이제 Sharkly로 졸업하세요. 작업이 더 이상 당신 혼자만의 것이 아니게 됐을 때, 동료가 실행을 리뷰해야 할 때, 당신이 없는 동안 누군가 넘겨받아야 할 때, 매니저가 무엇이 막혀 있는지 봐야 할 때, 혹은 상태와 인수인계 로직을 손으로 다시 만들고 있다는 걸 알아챘을 때입니다. 오케스트레이션 개요에서 계층들이 만나는 지점을 정리했습니다.

이 범주 전체의 결정 쌍은 짧습니다. 제약이 자기 머신과 자기 시간이라면 DIY 도구를 쓰세요. 제약이 에이전트가 뭘 했는지에 대한 팀의 공유 이해라면 오케스트레이션 계층을 쓰세요. 대부분의 개발자는 왼쪽에서 시작해서, 작업에 두 번째 사람의 이름이 나타나는 주에 넘어옵니다.

실제 시나리오

그대로 남는 혼자 하는 빌더. 프리랜서 개발자가 Mac에서 Claude Code 에이전트 서너 개로 고객 기능을 출시합니다. Conductor나 Claude Squad가 전부이고, 팀 계층을 더하는 건 이득 없이 무게만 늘리는 일입니다. 남는 게 맞는 선택입니다.

막 선을 넘은 두 사람 팀. 창업자와 첫 엔지니어가 각자 자기 tmux 스크립트를 돌리고 있었습니다. 서로 화면 공유 없이는 상대의 에이전트 작업을 리뷰할 수 없었죠. 실행을 Sharkly의 공유 Task로 옮기자, 둘 다 상대의 diff를 열고, 승인하고, 병합할 수 있게 됐습니다. 둘 다 이미 쓰던 런타임은 바꾸지 않고 말입니다.

팀을 표준화하는 리드. 엔지니어 다섯을 거느린 테크 리드가 보니 모두 조금씩 다른 worktree 스크립트를 쓰고 있었고 공유 리뷰는 없었습니다. 공유 Agent와 공통 Task 흐름이 다섯 개의 개인 설정을 팀이 재사용할 수 있는 하나의 워크플로로 바꿔줬고, 모든 엔지니어는 각자의 Computer와 모델 구독을 그대로 유지했습니다.

자주 묻는 질문

Claude Squad와 Conductor의 차이가 뭔가요? Claude Squad는 tmux와 git worktree 위에서 에이전트를 관리하고 여러 런타임을 지원하는 크로스 플랫폼 터미널 앱입니다. Conductor는 창 인터페이스에서 Claude Code 실행에 집중하는 macOS 데스크톱 앱입니다. 둘 다 각 실행을 자체 worktree에 격리하고, 차이는 터미널 대 네이티브 앱, 그리고 크로스 플랫폼 대 Mac 전용입니다.

이미 git worktree를 쓰고 있으면 Claude Squad나 Conductor가 필요한가요? 꼭 그렇진 않습니다. 둘 다 같은 worktree 원시 기능 위에 얹은 편의입니다. tmux와 git worktree 명령어 몇 개를 쓰는 게 편하다면, 순수 스크립트가 더 많은 통제와 함께 같은 격리를 줍니다. 이 도구들이 사주는 건 사용성과 정리이지 새로운 능력이 아닙니다.

이 DIY 도구들이 팀 리뷰를 처리할 수 있나요? 아니요. 그리고 그렇다고 주장하지도 않습니다. Conductor, Claude Squad, tmux 스크립트는 모두 한 대의 머신에서 한 명의 운영자를 위해 상태를 유지합니다. 공유 리뷰, 타인의 승인, 결정에 대한 지속 기록은 로컬 러너가 아니라 오케스트레이션 계층에 사는 워크플로 기능입니다. 그 구분에 대해서는 Vibe Kanban 대안 글을 참고하세요.

Sharkly가 Claude Code나 Claude Squad를 대체하나요? 아닙니다. Sharkly는 Claude Code, Codex, 또는 다른 실행 도구를 대체하지 않습니다. 팀이 이미 쓰는 도구들 주위에 공유 Task, Computer, 컨텍스트, 통제, 리뷰 계층을 더합니다. 런타임과 worktree는 그대로 두고 그 위에 팀 단위 가시성을 얻습니다.

Sharkly로 옮기면 git worktree를 포기해야 하나요? 아닙니다. Sharkly도 에이전트를 격리된 worktree에서 실행하므로, 믿고 쓰던 격리는 그대로 유지됩니다. 바뀌는 건 결과가 가는 곳입니다. 개인 터미널 버퍼 대신 공유 Task로 돌아갑니다.

전환할 때 모델 사용량과 비용은 어떻게 유지하나요? 구독은 각자 가져옵니다. 모델 사용량은 팀이 연결한 도구에 설정된 구독이나 API 키를 통해 계속되고, 모델 할당량은 그 도구와 플랜, API 계정에 따릅니다. Sharkly는 조정 계층을 더하는 것이지 새로운 결제 관계를 만들지 않습니다.

선을 넘을 준비가 됐나요? Sharkly를 내려받아 Computer를 연결하고, 실제 요구사항 하나를 에이전트 한 명에게 할당하세요. 이미 신뢰하는 런타임과 worktree는 유지하고, 작업이 팀 전체가 볼 수 있는 곳으로 돌아오게 하세요. 각 개념은 docs.sharkly.ai에서 더 깊이 다룹니다.