Sharkly Crews: 리더가 업무를 위임하는 AI 에이전트 팀

팀에 첫 번째 AI 에이전트를 들이면 처리량이 올라갑니다. 문제는 두 번째 에이전트부터입니다. 누군가는 API 변경을 어느 에이전트가 맡을지, 테스트는 누가 작성할지, 리팩터링이 스키마 마이그레이션을 기다려야 하는지, 그리고 사람이 최종 결과를 승인하기 전에 누가 통합 결과를 확인할지 정해야 합니다. 대부분의 팀에서 그 '누군가'는 양손에 터미널을 하나씩 들고 있는 시니어 엔지니어이며, 이런 역할은 확장되지 않습니다.

Sharkly Crews는 바로 이 순간을 위해 존재합니다. Crew는 하나의 리더 에이전트가 조율하는 재사용 가능한 사람과 에이전트의 그룹이며, 에이전트 작업을 공유 태스크 시스템 안에 유지해 주는 플랫폼인 Sharkly 안에 존재합니다. 모든 하위 태스크를 사람이 직접 라우팅하는 대신, 태스크를 Crew에 할당하면 됩니다. 리더 에이전트가 목표를 읽고, 어떤 멤버가 기여해야 할지 판단하고, 그 결과를 팀이 검토할 수 있는 한곳으로 모아옵니다.

이 가이드에서는 Crew가 무엇인지, 언제 단일 에이전트가 더 나은 선택인지, 리더 우선 실행이 실행마다 어떻게 동작하는지, 그리고 3개월 뒤에도 팀이 계속 쓰고 있을 Crew를 어떻게 설정하는지 다룹니다.

TL;DR

Sharkly의 Crew는 하나의 리더 에이전트가 조율하는 재사용 가능한 사람과 에이전트의 그룹입니다. 태스크를 Crew에 할당하면 리더가 먼저 시작해 목표를 해석하고, 에이전트 멤버를 멘션해 각 부분을 위임하고, 그 결과를 태스크에 통합합니다. 에이전트는 조사하고, 실행하고, 테스트하고, 보고합니다. 사람은 방향을 정하고, 권한을 부여하고, 결과를 승인합니다.

Sharkly의 Crew란 무엇인가요?

Crew는 이름이 붙은 재사용 가능한 팀입니다. 즉, 안정적으로 반복되는 특정 종류의 작업을 중심으로 사람과 에이전트를 묶고, 하나의 리더 에이전트가 실행을 조율합니다. 단일 에이전트가 한 가지 역할을 위한 저장된 작업 구성이라면, Crew는 여러 역할이 협업하는 방식을 담아내므로 복잡한 태스크를 단일 실행자 대신 팀에 할당할 수 있습니다.

모든 Crew에는 다음이 포함됩니다.

이름, 설명, 선택적 Crew 지침
Crew를 관리하는 조직 내 사용자인 오너 한 명
리더 한 명(해당 Crew의 스페이스에 속한 에이전트여야 함)
해당 스페이스에 참여할 수 있는 에이전트 및 사람 멤버
소속 스페이스 하나
개인 또는 스페이스 공개 범위
선택적 공유 태스크 디렉터리 설정

무엇보다 먼저 짚어야 할 두 가지 경계가 있습니다.

오너는 리더가 아닙니다. 오너는 Crew의 멤버십, 설정, 공개 범위를 관리하는 사람입니다. 리더는 에이전트이며, 실행을 조율하는 역할도 여전히 맡습니다. 오너를 리더 에이전트의 대체물로 여기는 것은 두 역할을 모두 잘못 이해한 것입니다.

멤버십은 실행이 아닙니다. 사람 멤버십은 누가 Crew에 참여하는지를 기록할 뿐이며, 에이전트 실행을 시작할 수 있는 것은 에이전트 멤버뿐입니다. Crew에 속한 사람은 늘 해오던 방식대로 태스크 댓글, 리뷰, 채팅을 통해 협업합니다. Crew에 합류한다고 해서 사람이 실행 대상이 되는 것은 아닙니다.

리더는 자동으로 멤버로 추가되고 리더 역할을 가지며, Crew를 이끄는 동안에는 제거할 수 없습니다. 다른 멤버에게는 backend, tests, docs처럼 기여 내용을 설명하는 역할 레이블을 붙일 수 있고, 이는 리더가 위임할 때 구체적으로 판단할 근거가 됩니다.

언제 단일 에이전트 대신 Crew를 사용해야 하나요?

이 기준은 Sharkly 문서에서 그대로 가져온 것이며, 문자 그대로 받아들일 가치가 있습니다. 작고 명확하게 정의된 작업이라면 태스크를 단일 에이전트에 바로 할당하세요. 리더가 목표를 해석하고, 다른 에이전트 멤버를 참여시키고, 그 결과를 하나의 태스크나 대화로 모아야 할 때 Crew를 사용하세요.

단일 에이전트가 적합한 경우는 다음과 같습니다.

작업이 하나의 역할에 들어맞을 때. 예를 들어 한 서비스의 버그 수정.
범위가 이미 명확하고 분해가 필요 없을 때.
할당과 리뷰 사이에 움직이는 요소를 최소화하고 싶을 때.
개별 에이전트의 지침을 아직 조정 중이고 명확한 신호를 원할 때.

Crew가 제 역할을 하는 경우는 다음과 같습니다.

목표가 여러 역할에 걸쳐 있을 때. 예를 들어 백엔드, 프런트엔드, 테스트 변경이 모두 필요한 기능.
기여 순서를 누군가 정해야 하는데, 그 역할을 터미널 두 개를 열어둔 사람이 아니라 에이전트가 맡길 원할 때.
새 요청마다 동일한 전문가 조합이 계속 다시 구성될 때.
여러 에이전트의 결과가 개인 세션 곳곳에 흩어지지 않고 하나의 태스크에 모여야 할 때.

팀에서 멀티 에이전트 작업을 구조화할 가치가 있는지 아직 고민 중이라면, AI 에이전트 오케스트레이션 입문 글에서 그 트레이드오프를 기초부터 다룹니다. 요약하자면, 두 번째 에이전트는 값싸지만 관리되지 않는 에이전트 간 조율은 그렇지 않습니다.

리더 우선 실행은 어떻게 동작하나요?

태스크를 Crew에 할당하면 실행은 리더 우선 순서를 따릅니다.

다른 담당자와 마찬가지로 담당자 컨트롤을 통해 태스크를 Crew에 할당합니다.
태스크가 실행 가능한 상태에 있고 리더가 준비되어 있으면 리더 에이전트가 먼저 시작합니다.
리더가 태스크 컨텍스트와 Crew 지침을 읽습니다.
리더는 작업을 직접 처리하거나, 특정 기여를 위해 적합한 에이전트 멤버를 멘션합니다.
멘션된 에이전트 멤버가 동일한 태스크에 대해 실행되고, 결과를 해당 태스크의 채팅에 추가합니다.
리더는 계속 조율하며 결과를 통합합니다.

이 순서의 설계 목표는 절제입니다. 리더 우선 실행은 모든 에이전트 멤버가 한꺼번에 시작하는 것을 막습니다. 또한 리더가 빠진 컨텍스트를 파악하고, 적합한 참여자를 고르고, 작업 순서를 통제할 기회를 줍니다. 리더가 없는 Crew는 그저 팬아웃 버튼일 뿐이지만, 리더가 있으면 작업을 나누기 전에 먼저 생각하는 팀이 됩니다.

백로그는 개별 에이전트의 경우와 동일하게 동작합니다. 백로그에 있는 태스크를 할당해도 리더는 시작되지 않습니다. 백로그는 작업을 준비하는 대기 공간이며, 태스크를 실행 가능한 상태로 옮기는 행위가 Crew를 시작시킵니다. 할당만으로 작업이 갑자기 실행되는 일은 없습니다.

멤버가 만들어내는 모든 것, 즉 실행 상태와 결과, 그리고 그에 대한 논의가 태스크로 돌아옵니다. 이것이 다섯 개의 터미널에 흩어진 팀이 아니라 Sharkly 안에서 팀을 운영하는 이유입니다. 에이전트 하나가 작업했든 네 개가 작업했든, 컨텍스트와 진행 상황, 블로커, 결과, 사람의 리뷰가 요청부터 릴리스까지 계속 눈에 보입니다.

멤버를 병렬로 실행하는 팀을 위한 기술적 참고 사항이 하나 있습니다. 각 에이전트 실행은 기본적으로 자체적인 격리 작업 디렉터리를 할당받으므로, 멤버들이 서로의 파일을 건드리는 일이 없습니다. 격리 모델은 Sharkly가 병합 충돌 없이 에이전트를 병렬 실행하는 방법에서 자세히 다룹니다.

소유권, 공개 범위, 그리고 Crew를 사용할 수 있는 사람

스페이스에서 공유 리소스를 만들 권한이 있는 사람은 그 스페이스에 Crew를 만들 수 있습니다. 모든 Crew는 하나의 스페이스에 속하며, 공개 범위가 누가 Crew를 찾고 사용할 수 있는지를 결정합니다.

공개 범위	접근 및 채팅 가능 대상	관리 또는 할당 가능 대상
개인	오너, 사람 Crew 멤버, 에이전트 멤버의 오너	오너만 Crew를 관리하거나 태스크 담당자로 선택할 수 있음
스페이스	Crew가 속한 스페이스의 멤버, 그리고 조직 오너와 관리자	스페이스 및 조직 권한에 따름

공개 범위는 Crew 자체, Crew 채팅, 태스크 담당자로의 선택에 모두 적용됩니다. 개인 Crew는 오너가 관리하며, 비공개 Crew의 오너가 바뀌면 이전 오너는 관리 권한을 잃습니다. 이 인수인계 규칙은 Crew를 만든 사람이 팀을 옮길 때 중요합니다. 나중에 문제를 발견하는 대신 소유권을 의도적으로 이전하세요.

Crew가 역할을 다했다면 기록을 삭제하는 대신 보관 처리하세요. 보관된 Crew는 새 할당을 받지 않지만 기존 기록은 계속 사용할 수 있습니다. 보관하기 전에 현재 태스크나 자동화가 아직 이 Crew를 사용하고 있는지 확인하고, 그 작업을 먼저 다른 담당자에게 옮기세요. Crew에 속한 에이전트를 보관할 때도 같은 의존성 확인이 필요합니다.

Crew 채팅: 태스크가 생기기 전의 조율

첫날부터 모든 논의가 태스크가 될 필요는 없습니다. Crew 채팅은 작업 항목 이전에 오는 대화, 즉 문제를 탐색하고, 적합한 참여자를 찾고, 계획을 다듬는 자리를 위해 존재합니다.

각 사용자는 Crew와의 지속적인 채팅 세션을 가지며, 리더 에이전트가 첫 대화 상대입니다. 리더는 에이전트 멤버를 멘션할 수 있어 그들의 답변이 같은 채팅에 나타납니다. 따라서 무엇이든 결정하기 전에 팀이 함께 사고하는 과정을 지켜볼 수 있습니다.

경계는 분명하며 외워둘 가치가 있습니다. Crew 채팅은 태스크를 만들지 않습니다. 논의가 구체적인 작업으로 바뀌면 태스크를 만들고 Crew를 할당하세요. 그래야 상태와 댓글, 실행, 승인이 작업 항목에 붙어 있게 됩니다. 채팅 세션에만 존재하는 결론은 팀이 잃게 될 결론입니다. 공유 기록은 태스크이며, 결과는 그곳으로 돌아가야 합니다.

태스크 상세 화면의 헤더 툴바에도 빠른 채팅이 있습니다. 빠른 채팅은 현재 태스크를 컨텍스트로 삼아 선택한 에이전트나 Crew를 태스크 옆의 분할 뷰에서 실행합니다. 정식으로 할당하기 전에 Crew에게 “이걸 어떻게 처리하시겠어요?”라고 물어보는 유용한 방법입니다.

고급 Crew 활용 기법

Crew 전용 에이전트: 다른 곳에서는 일하지 않는 전문가

어떤 에이전트는 자기 팀 안에서만 의미가 있습니다. 다른 멤버 세 명이 존재한다고 전제하는 병합 조정자라든가, 특정 Crew의 관례에 맞춰 조정된 리뷰어는 조직의 일반 에이전트 선택 목록에 나타나서는 안 됩니다. 누군가 그 에이전트에게 애초에 설계되지 않았던 단독 작업을 할당할 수도 있기 때문입니다.

에이전트를 Crew 전용으로 표시하면 해당 Crew로 범위가 제한됩니다. 이 설정을 켜면 다음과 같아집니다.

해당 에이전트는 현재 Crew 안에서만 호출할 수 있습니다.
개인 채팅에 사용하거나 단독으로 태스크를 할당할 수 없습니다.
내 에이전트, 디렉터리, 조직 에이전트 목록, 담당자 선택 목록에서 사라집니다.

전용 설정은 Crew 역할이 아니라 에이전트에 대한 범위 제한입니다. 역할 레이블은 그 멤버가 무엇을 하는지를 설명하고, 전용 설정은 그 에이전트를 어디에서 호출할 수 있는지를 설명합니다. Crew 전용 에이전트는 한 번에 최대 하나의 Crew에만 속할 수 있으므로, 이미 다른 Crew에 들어 있다면 먼저 그곳에서 제거하세요. 전용 설정을 해제하면 일반적인 공개 범위와 할당 가능성이 복원되며, 어느 쪽이든 기존 태스크와 채팅은 그대로 남습니다. 차단되는 것은 새로운 개인 채팅과 새로운 단독 할당입니다.

공유 태스크 디렉터리: 멤버들이 같은 파일 위에서 작업해야 할 때

기본적으로 격리가 원칙입니다. 개별 실행은 각각 별도의 디렉터리를 받습니다. Crew는 이를 의도적으로 완화할 수 있습니다. 공유 태스크 디렉터리 설정을 켜면, 같은 태스크에 대한 이후의 Crew 에이전트 실행이 해당 컴퓨터에서 가장 최근의 적격 디렉터리를 재사용하고, 앞선 멤버가 남긴 로컬 변경을 보존할 수 있습니다.

이를 안전하게 유지하는 두 가지 제약이 있습니다. 첫째, 파일 시스템 상태만 공유할 뿐 이전 에이전트의 프로바이더 세션은 공유하지 않으므로, 각 멤버는 여전히 태스크 기록을 바탕으로 자체적인 추론을 시작합니다. 둘째, 실행이 동일한 Crew 할당 태스크에 속하고 동일한 컴퓨터에서 실행될 때만 적용됩니다.

판단 기준은 이렇습니다. 구현 에이전트 다음에 새 코드를 검증하는 테스트 에이전트가 오는 것처럼, 순차적인 멤버들이 동일한 로컬 변경 위에서 작업해야 할 때는 공유 디렉터리 재사용을 켜세요. 격리가 더 안전하거나 동시 편집이 충돌할 수 있을 때는 꺼두세요. 켠다면 Crew 지침에 의도한 실행 순서를 명확히 밝히세요. 순서가 모호한 공유 디렉터리는 팀 유니폼을 입은 병합 충돌일 뿐입니다.

제대로 작동하는 Crew 지침 작성하기

Crew 지침은 조율을 위한 리더의 운영 매뉴얼입니다. 문서에서는 무엇을 여기에 담아야 하는지 구체적으로 설명합니다. 리더가 다른 에이전트를 참여시킬지 어떻게 판단하는지, 어떤 역할을 사용할 수 있는지, 결과를 어떻게 통합해야 하는지, 언제 사람이 결정을 내려야 하는지입니다.

각 계층은 분리해서 유지하세요. 태스크별 요구 사항은 태스크 설명과 댓글에 둡니다. 여러 에이전트가 공유하는 재사용 가능한 절차는 스킬에 속합니다. 각 멤버 에이전트의 고유 지침은 개별 역할을 담당합니다. Crew 지침은 협업 규칙만 다루며, 그래야 리더가 매 실행마다 따를 수 있을 만큼 짧게 유지됩니다. 모든 멤버의 지침을 Crew에 복제하는 것이 위임을 예측 불가능하게 만드는 가장 흔한 방법입니다.

활용 가능한 기본 골격은 다음과 같습니다.

# Crew: Checkout Feature Crew

## When to delegate
- API or database changes: mention @backend-agent
- UI changes in web/: mention @frontend-agent
- After any code change lands: mention @test-agent

## Order
Backend before frontend when a contract changes.
Tests run last, against the combined changes.

## Combining results
Summarize each member's outcome on the Task,
list open risks, then set the Task to waiting
for human review.

## Escalation
Any schema migration or public API change stops
here: ask the responsible person on the Task
before proceeding.

그 에스컬레이션 블록은 팀 자체에 새겨진 사람-에이전트 계약입니다. 에이전트는 조사하고, 실행하고, 테스트하고, 보고합니다. 사람은 방향을 정하고, 권한을 부여하고, 결과를 승인합니다. Crew는 이 계약을 바꾸지 않습니다. 다만 계약의 에이전트 쪽에 더 많은 손을 붙여줄 뿐입니다.

첫 Crew 설정하기

문서에서는 일반적인 설정 순서를 설명하는데, 에이전트가 이미 준비되어 있다면 약 15분이면 끝납니다.

Crew가 처리할 안정적인 작업 종류를 정의하세요. “모든 것”은 작업 종류가 아닙니다. “결제 흐름 변경”은 작업 종류입니다.
공개 범위와 오너를 정하세요. 조정하는 동안에는 개인으로 시작하고, 이 구성이 재사용될 가치가 생기면 스페이스 공개 범위로 옮기세요.
리더로 쓸 에이전트를 선택하세요. 코드를 가장 많이 작성하는 에이전트가 아니라, 작업을 라우팅할 판단력을 신뢰할 수 있는 에이전트를 고르세요.
작업에 필요한 사람과 에이전트 멤버를 추가하고, 리더가 판단할 수 있는 역할 레이블을 부여하세요. 멤버 페이지에서는 여러 명을 한 번에 추가할 수 있고, 행 메뉴에서 나중에 새 리더를 지정하거나 멤버를 제거할 수 있습니다.
위의 계층화 규칙에 따라 조율과 출력에 관한 Crew 지침을 작성하세요.
공유 태스크 디렉터리의 재사용 동작이 정말 원하는 바일 때만 활성화하세요. 확신이 없다면 꺼두세요.

그런 다음 실제 태스크 하나를 할당하세요. 예를 들어 SH-312: “구독 취소 흐름에 취소 사유 필드 추가, API와 UI 모두, 테스트 포함” 같은 것입니다. 리더가 시작하는 모습을 지켜보고, 어떻게 위임하는지 읽어보고, 태스크로 돌아오는 결과를 검토하세요. 첫 Crew 실행은 사전에 아무리 많이 수정하는 것보다 여러분의 지침에 대해 더 많은 것을 가르쳐줍니다. 각 에이전트 멤버는 Claude Code든 Codex든 팀이 이미 비용을 지불하고 있는 다른 CLI 도구든, 각자 구성된 런타임에서 실행됩니다. Sharkly는 그 도구들을 대체하는 것이 아니라 그 주위를 감싸는 조율 계층으로 남기 때문입니다.

따라 할 만한 Crew 패턴

이것들은 사례 연구가 아니라 구성 패턴이며, 각각 문서화된 동작을 조합한 것입니다.

기능 Crew. 계획을 세우는 리더 에이전트와, 그에 맞는 역할 레이블을 가진 백엔드, 프런트엔드, 테스트 멤버로 구성됩니다. 리더는 요구 사항을 분해하고, 계약이 바뀔 때는 백엔드를 프런트엔드보다 먼저 배치하고, 테스트 멤버는 마지막에 멘션합니다. 위의 설정 골격이 설명하는 패턴이며, 요구 사항이 일상적으로 역할 경계를 넘는 팀에 맞습니다.

트리아지 Crew. 들어오는 버그 리포트를 읽는 리더, 실패를 확인하고 증거를 수집하는 재현 담당 멤버, 재현이 확인되어 태스크로 돌아온 뒤에만 행동하는 수정 멤버로 구성됩니다. 버그 우선순위를 정하는 일은 방향 설정이므로 사람이 멤버로 계속 참여합니다. 계약의 그 부분은 사람의 몫입니다.

리뷰 Crew. 리뷰 관점을 배분하는 리더가 있습니다. 한 멤버는 정확성을, 다른 멤버는 보안에 민감한 경로를, 세 번째 멤버는 테스트 커버리지를 살핍니다. 각자의 발견은 별도 결과로 태스크에 남고, 리더가 이를 요약합니다. 리뷰 멤버에게 기능 작업을 단독으로 할당해서는 안 되므로, 이 패턴은 Crew 전용 에이전트의 자연스러운 자리입니다.

스프린트 지원 Crew. 스프린트 중에 Crew는 반복적이고 범위가 명확한 작업을 처리합니다. 의존성 업데이트, 불안정한 테스트 격리, 문서 불일치 같은 일입니다. 리더의 주된 임무는 범위를 벗어난 작업을 거절하는 것이며, 그래야 Crew의 처리량을 계획할 수 있을 만큼 예측 가능하게 유지됩니다.

어떤 패턴으로 시작하든 하나만 시작하세요. Crew 하나를 잘 운영하는 팀은 두 번째 Crew를 손쉽게 만드는 조율 습관을 익히게 됩니다.

Crew가 답이 아닌 경우

솔직한 경계 목록입니다. 팀이 멀티 에이전트 작업에 등을 돌리게 만드는 가장 빠른 방법은 가치를 깎아내리는 곳에 그것을 쓰는 것이기 때문입니다.

역할이 하나로 명확하다면 에이전트 하나. 태스크가 단일 역할에 맞는다면 Crew는 위임 단계만 하나 늘릴 뿐입니다. 문서에서도 단순한 작업에는 에이전트 하나를, 진정한 조율이 필요한 작업에는 Crew를 권장합니다.

반복 트리거라면 자동화. 판단이 아니라 일정이나 이벤트에 따라 작업이 실행된다면 자동화가 더 적합한 도구입니다. Crew는 결정하고, 자동화는 반복합니다. 둘은 잘 어울리지만 서로 대체할 수는 없습니다.

실행 내 분해라면 런타임 서브에이전트. Claude Code 같은 도구는 한 번의 실행 안에서 서브에이전트를 생성할 수 있습니다. 이는 경쟁 관계가 아니라 상호 보완적입니다. 런타임 서브에이전트는 한 에이전트의 작업을 세션 안에서 나누고, Crew는 별개의 에이전트와 런타임, 결과를 팀이 볼 수 있는 태스크 수준에서 조율합니다. 지금 스크립트와 tmux로 여러 Claude Code 에이전트를 실행하고 있다면, Crew는 그 구성에서 조율 부분을 다음 단계로 끌어올리는 길입니다.

단계만 늘어난 단체 채팅. 원하는 것이 논의라면 Crew 채팅을 쓰고 거기서 멈추세요. 에이전트 하나로 답할 수 있는 질문에 답하는 것이 유일한 임무인 Crew를 만들지 마세요.

이 중 어느 것도 무언가를 다시 구축하라고 요구하지 않습니다. 멤버는 각자의 런타임과 저장소, 구독을 그대로 유지합니다. Crew는 이미 구성해 둔 에이전트 위에 얹는 조율 계층이며, 모델 사용은 그 도구들에 설정된 구독과 API 키를 통해 계속 이루어집니다.

결론

Crew는 첫 에이전트를 성공적으로 도입한 뒤 모든 팀이 마주하는 질문, 즉 사람을 교통정리 담당자로 세우지 않고 여러 에이전트를 어떻게 운영할 것인가에 대한 Sharkly의 답입니다. 그 메커니즘은 문서화된 조율 규칙을 가진 하나의 리더 에이전트, 역할이 분명한 멤버들, 그리고 모든 결과가 돌아가는 하나의 태스크입니다. 절제는 설계에 내장되어 있습니다. 리더 우선 실행, 절대 자동으로 시작되지 않는 백로그, 기본값으로서의 격리, 그리고 마지막에 승인을 쥐고 있는 사람입니다.

구체적인 다음 단계는 작습니다. 컴퓨터 하나를 연결하고, 각각은 이미 신뢰하는 에이전트 두 개를 구성한 뒤, 세 줄짜리 지침 블록과 함께 Crew로 묶으세요. 두 역할이 모두 진짜로 필요한 태스크 하나를 할당하고, 돌아오는 결과를 읽어보세요. Sharkly 문서에서 각 개념을 더 깊이 다루고, Sharkly 시작하기에서 기본 설정을 처음부터 끝까지 안내합니다.

자주 묻는 질문

Sharkly의 Crew란 무엇인가요?

Crew는 하나의 리더 에이전트가 조율하는 재사용 가능한 사람과 에이전트의 그룹입니다. Crew를 관리하는 오너, 하나의 소속 스페이스, 개인 또는 스페이스 공개 범위, 선택적 Crew 지침을 갖습니다. 태스크를 Crew에 할당하면 리더가 어떤 멤버가 기여할지, 결과를 어떻게 통합할지 조율합니다.

언제 단일 에이전트 대신 Crew를 사용해야 하나요?

작고 명확하게 정의된 작업은 에이전트 하나에 바로 할당하세요. 목표를 해석해야 하거나, 여러 역할에 걸쳐 있거나, 여러 에이전트의 결과를 하나의 태스크로 모아야 할 때 Crew를 사용하세요. 요청마다 동일한 전문가 그룹이 계속 다시 구성된다면, 그 반복이 바로 팀을 재사용 가능하게 만들라는 신호입니다.

태스크를 Crew에 할당하면 모든 멤버가 동시에 시작하나요?

아니요. 실행은 리더 우선입니다. 리더 에이전트가 시작해 태스크 컨텍스트와 Crew 지침을 읽고, 특정 기여를 위해 적합한 에이전트 멤버를 멘션합니다. 그런 다음 멘션된 멤버가 동일한 태스크에 대해 실행됩니다. 이는 우르르 몰려드는 상황을 막고 리더가 순서와 참여를 통제할 수 있게 합니다.

사람도 Crew의 멤버가 될 수 있나요?

네. 사람 멤버십은 누가 참여하는지를 기록하며, 개인 Crew의 사람 멤버는 해당 Crew에 접근하고 채팅할 수 있습니다. 다만 에이전트 실행을 시작할 수 있는 것은 에이전트 멤버뿐입니다. 사람은 태스크 댓글, 결정, 리뷰를 통해 기여하며, 이것이 계약의 사람 쪽입니다.

Crew 전용 에이전트란 무엇인가요?

Crew 전용 에이전트는 하나의 Crew로 범위가 제한됩니다. 해당 Crew 안에서만 호출할 수 있고, 개인 채팅이나 단독 태스크 할당을 가질 수 없으며, 조직 전체 에이전트 목록에도 나타나지 않습니다. 역할이 아니라 범위 제한이며, 해제하면 에이전트의 일반적인 공개 범위가 복원됩니다.

Crew 멤버가 태스크 중에 파일을 공유할 수 있나요?

네, Crew가 공유 태스크 디렉터리 설정을 활성화한 경우 가능합니다. 같은 태스크에 대한 이후 멤버의 실행이 동일한 컴퓨터에서 가장 최근의 적격 디렉터리를 재사용해 앞선 로컬 변경을 보존할 수 있습니다. 파일 시스템 상태만 공유하며 이전 에이전트의 세션은 절대 공유하지 않고, 동시 편집에는 격리가 더 안전하므로 기본값은 꺼짐입니다.

Crew 채팅이 태스크를 자동으로 만드나요?

아니요. Crew 채팅은 리더를 첫 대화 상대로 삼아 문제를 탐색하거나 계획을 다듬는 용도입니다. 논의가 구체적인 작업으로 바뀌면 태스크를 만들고 Crew를 할당해, 상태와 실행, 승인이 작업 항목에 붙어 있게 하세요.