팀에 첫 에이전트를 들이는 건 개인의 생산성 이야기입니다. 다섯 번째 에이전트는 조직의 이야기죠. 그 사이 어디쯤에서 한 그룹은 AI를 쓰는 팀을 넘어 에이전틱 팀이 됩니다. 사람과 에이전트가 같은 보드에서, 같은 작업을 두고, 누군가 문서로 정해 둔 규칙 아래 함께 일하는 팀 말입니다.
흥미로운 질문은 대부분 이 전환점에서 나옵니다. 에이전트가 실행한 작업의 주인은 누구인가? 보드가 스스로 업데이트되는데 스탠드업에서는 무슨 얘기를 하는가? 리뷰어 한 명이 감당할 수 있는 에이전트는 몇 개인가? 이 가이드에서는 에이전틱 팀의 구성, 실제 업무와 부딪혀도 살아남는 역할 분담, 그리고 훔쳐 쓸 만한 협업 규칙을 다룹니다. Sharkly는 이런 형태의 팀을 위해 우리가 만든 플랫폼이며, 아래에 정리한 실패 유형은 이런 팀이 잘못 굴러가는 모습을 지켜보며 얻은 것입니다.
TL;DR
에이전틱 팀이란 사람과 AI 에이전트가 하나의 공유 시스템 안에서 각자 배정된 업무를 맡는 그룹입니다. 방향, 권한, 승인은 사람이 쥐고 있습니다. 에이전트는 조사하고, 실행하고, 테스트하고, 보고합니다. 사람은 방향을 정하고, 권한을 부여하고, 결과를 승인합니다. 실무적으로 필요한 것은 양쪽 모두 읽을 수 있는 작업 기록, 책임자와 분리된 실행 담당자, 누군가에게 도달하는 리뷰 상태, 그리고 에이전트가 추측하지 않아도 될 만큼 충분히 작성된 범위입니다.
에이전틱 팀은 무엇으로 구성되는가
참여자는 세 종류입니다. 각각을 정확히 부르면 이해가 쉽습니다.
사람은 작업을 만들고 갱신하고, 댓글을 달고, 큐 항목을 받고, 업무를 배정받고, 에이전트 결과를 리뷰하고, 자신의 역할이 허용하는 범위에서 설정을 관리합니다. 책임을 질 수 있는 유일한 참여자입니다.
에이전트는 일회성 프롬프트가 아니라 저장된 작업 구성입니다. 지침, Claude Code나 Codex 같은 런타임, 리포지토리, 환경, 실행 설정, 연결된 스킬 등이 여기에 담깁니다. 에이전트는 사람이라기보다 문서화된 역할에 가깝습니다. 하나의 에이전트에 무엇이 들어가는지는 Sharkly Agents 해설 글에서 다룹니다.
Crews는 조율이 필요한 작업을 위해 여러 에이전트를 하나의 리더 에이전트 아래 묶습니다. 실행은 리더 우선 방식입니다. 리더가 작업과 크루 지침을 읽고, 직접 처리하거나 특정 멤버를 투입합니다. 이런 순서는 모든 멤버가 동시에 시작하는 걸 막기 위해 존재합니다. 자세한 내용은 Sharkly Crews 가이드에 있습니다.
그 위에 접근 권한이 층층이 쌓입니다. 조직 역할은 전반적인 관리 권한을 결정하고, 스페이스 멤버십은 어떤 업무 영역에 접근할 수 있는지를 결정합니다. 에이전트도 같은 방식으로 특정 리포지토리와 특정 머신으로 범위가 정해집니다.
실제로 작동하는 역할 분담
Sharkly 자체 계약은 강제할 수 있을 만큼 범위가 좁아서 좋은 기본값입니다. 에이전트는 조사하고 실행하고 테스트하고 보고하며, 사람은 방향을 정하고 권한을 부여하고 결과를 승인합니다.
에이전트가 아무리 뛰어나져도 사람에게 남는 네 가지 책임이 있습니다.
- 방향. 무엇을 할 가치가 있는지, 어떤 순서로 할지 결정합니다.
- 맥락. 에이전트가 실행에 옮길 수 있는 범위를 작성합니다. 이 작업이 왜 중요한지, 무엇이 범위 밖인지, 관련 파일과 제약 조건은 무엇인지, 완료를 어떻게 검토할지 등입니다.
- 승인. 증거를 확인하고 작업이 끝났다고 판단합니다. 실행이 끝난 것과 결과가 승인된 것은 다릅니다.
- 에스컬레이션. 에이전트가 막혔을 때, 잘못됐을 때, 판단이 필요한 질문에 부딪혔을 때 어떻게 할지 결정합니다.
나머지는 모두 조정 가능하며, 특정 종류의 업무에서 특정 에이전트의 실적을 팀이 얼마나 신뢰하는지에 달려 있습니다.
팀 안에서 업무가 흐르는 방식
이 순환은 짧지만 명시해 둘 가치가 있습니다. 한 단계를 건너뛴 팀은 일주일 안에 그 대가를 체감하기 때문입니다.
- 사람이 결과와 승인 기준을 명시해 작업을 작성합니다.
- 작업에는 책임을 맡을 사람 담당자와 실행 담당자로서 에이전트 또는 크루가 지정됩니다. 이 둘은 별개 필드이며, 하나를 바꿔도 다른 하나는 바뀌지 않습니다.
- 작업을 대기 상태의 백로그에서 빼내면, 배정된 에이전트가 준비되는 시점에 실행이 시작됩니다.
- 실행은 연결된 머신의 격리된 디렉터리에서 이루어지고, 진행 상황과 장애 요소는 작업으로 다시 보고됩니다.
- 에이전트는 작업을 사람의 답변 대기 또는 사람의 리뷰 대기 상태로 남기고, 이는 책임자의 에이전트 인박스로 들어갑니다.
- 사람이 트레이스와 diff를 읽고 승인하거나, 댓글로 이어가거나, 다시 배정합니다.
댓글은 지속되는 대화입니다. 준비된 에이전트가 있는 작업에 댓글을 달면 다음 실행이 큐에 들어갈 수 있습니다. 덕분에 리뷰 피드백과 실행이 두 개의 시스템이 아니라 하나의 동작이 됩니다.
효과적인 세 가지 형태
짝을 이룬 개발자. 각 개발자가 반복되는 자기 업무를 위해 에이전트 한두 개를 유지합니다. 테스트 커버리지, 의존성 업데이트, 스무 번은 해본 리팩터링 같은 일이죠. 이 형태의 팀 차원 이점은 에이전트 정의가 공유된다는 점입니다. 새로 합류한 사람이 첫날부터 직접 만드는 대신 이미 작동하는 다섯 개의 구성을 물려받습니다.
공유 크루를 둔 스쿼드. 하나의 크루가 스쿼드 전체가 의존하는 한 갈래의 업무를 맡습니다. 릴리스 준비나 인시던트 트리아지 같은 일입니다. 리더 에이전트가 어떤 멤버가 기여할지 정하고, 사람 한 명이 그 업무 범주를 책임집니다. 리뷰 역량이 한계에 부딪히기 전까지 가장 멀리 확장할 수 있는 형태입니다.
표준화를 맡은 플랫폼 팀. 플랫폼 또는 개발자 경험 조직이 여러 제품 팀을 위한 에이전트 정의, 스킬, 머신 구성을 소유합니다. 제품 팀은 업무를 배정하고, 플랫폼 팀은 런타임과 권한, 지침을 최신 상태로 유지합니다. 이 형태는 자율성을 다소 포기하는 대신 일관성을 얻으며, 대략 엔지니어 30명을 넘어서면 보통 옳은 선택입니다.
세 가지 모두 조직을 재편할 필요가 없습니다. 이들은 에이전트 구성을 누가 소유하는지에 대한 패턴이며, 에이전트 역량이 팀 전체에 축적될지 개인에 머물지를 결정하는 바로 그 질문에 대한 답입니다.
도입할 만한 협업 규칙
작업마다 책임자는 사람 한 명. 에이전트 네 개로 구성된 크루가 일을 처리할 때도 그렇습니다. 오히려 그럴 때 더욱 그렇습니다.
범위는 배정 전에 작성합니다. 결과를 어떻게 확인할지 아무도 말할 수 없다면, 그 작업은 에이전트에게 맡을 준비가 안 된 것입니다. 이 규칙 하나만으로 대부분의 잘못된 실행을 걸러낼 수 있습니다.
리뷰는 남는 시간이 아니라 계획된 역량입니다. 리뷰어마다 하루에 감당할 수 있는 에이전트 작업량을 정하고 그 수를 지키세요. 리뷰되지 않은 에이전트 결과가 쌓여가는 것은 머지되지 않은 풀 리퀘스트와 같은 부채이며, 쌓이는 속도는 더 빠릅니다.
실패한 실행은 재시도가 아니라 원인 진단부터. 실행 로그를 열고 제목과 기술 세부 정보를 먼저 읽으세요. 비슷해 보이는 벤더 오류가 정반대의 해결책을 필요로 하는 경우가 많아서, 습관적인 재시도는 진짜 원인을 가립니다.
에이전트 정의에는 소유자와 검토 일자를 지정합니다. 지침은 낡습니다. 마이그레이션 에이전트를 만든 개발자는 떠나고, 관례는 바뀌는데, 에이전트는 지난 분기 규칙을 자신 있게 계속 적용합니다.
팀이 커질 때 가장 먼저 무너지는 것
언제나 리뷰 역량이 가장 먼저 무너집니다. 두 번째 제약은 머신 역량입니다. 동시 실행 슬롯이나 빈 작업 디렉터리를 기다리느라 실행이 줄을 서고, 컴퓨터는 늘리지 않고 에이전트만 추가한 팀은 보드에서는 보이지 않는 큐를 발견하게 됩니다.
세 번째는 소유권 표류입니다. 여러 에이전트가 관련 작업에 기여하는데 인계 후에도 아무도 담당자 이름을 바꾸지 않으면, 형식상으로는 배정됐지만 실질적으로는 주인이 없는 작업이 생깁니다. 에이전트 담당자가 있고 사람 담당자가 오래된 작업을 일주일에 한 번 훑는 데는 10분이면 충분하며, 이렇게 하면 이 문제가 지저분해지는 걸 막을 수 있습니다. 이런 필드를 이미 분리해 둔 시스템에서 시작하고 싶다면, Sharkly를 다운로드해서 반복되는 작업 한 가지를 일주일 동안 돌려보세요.
FAQ
개발자 한 명당 에이전트 몇 개가 적당한가요? 한두 개로 시작하고 리뷰 처리량이 상한을 정하게 하세요. 적정 수치는 결과가 사람의 결정을 기다리는 시간이 근무일 하루를 넘지 않는 지점입니다.
에이전트도 스탠드업에 참여하나요? 에이전트의 작업은 참여합니다. 상태는 보드가 담고 있으니, 스탠드업은 예외 목록이 됩니다. 실패, 막힌 실행, 사람을 기다리는 결과 같은 것들이죠.
에이전트가 유일한 담당자가 될 수 있나요? 아닙니다. 결과에 대한 책임은 사람에게 두고, 에이전트는 실행 자리에 넣으세요. 규모가 커질수록 이 분리가 왜 더 중요한지는 AI 에이전트 프로젝트 관리 가이드에서 설명합니다.
새 에이전트를 팀에 어떻게 온보딩하나요? 사람을 온보딩하듯 하면 됩니다. 좁은 첫 업무를 주고, 꼼꼼히 리뷰한 다음, 범위를 넓혀 주세요. 잘 작동한 내용은 그 에이전트의 지침과 스킬로 저장해서 다음 팀이 처음부터 다시 알아내지 않도록 하세요.
