인간-에이전트 팀의 스프린트 계획은 실행 속도가 아니라 리뷰 역량을 기준으로 계획할 때 제대로 작동한다. 에이전트는 리뷰어가 승인할 수 있는 것보다 더 많은 Task를 가져가서 끝낼 수 있다. 따라서 한 사이클의 실제 한계는 코드가 얼마나 많이 작성되는지가 아니라, 사람이 얼마나 많은 완료된 변경 사항을 검토하고 병합할 수 있는지다. 이 가이드는 계획 방법을 단계별로 살펴보고, 각 단계에서 나타나는 실패 유형을 짚은 뒤, 다음 스프린트 전에 실행할 수 있는 체크리스트로 마무리한다.
전통적인 스프린트 계획은 엔지니어가 코드를 작성할 수 있는 시간이 희소 자원이라고 가정한다. 여기에 코딩 에이전트를 더하면 그 가정은 무너진다. Claude Code, Codex, Gemini CLI는 여러분이 앞선 Task를 아직 읽고 있는 동안에도 각자 Task를 맡아 동작하는 diff를 내놓을 수 있다. 실행은 더 이상 병목이 아니다. 승인이 병목이 된다.
이러한 변화는 평범한 계획을 조용히 망가뜨린다. 개발자-일(developer-day) 기준으로 2주 사이클을 산정하면, 에이전트는 사흘 만에 백로그를 태워버리고, 완료됐지만 리뷰되지 않은 변경 사항이 병합을 승인할 수 있는 한두 명의 사람 뒤에 쌓인다. 스프린트는 빨라 보이지만 끝은 느리다.
Sharkly는 이 가이드가 계획을 세우는 작업 공간이다. 여러분에게는 이미 코딩 에이전트가 있다. Sharkly는 모든 Task와 그 진행 상황, 블로커, 결과, 사람의 리뷰를 여러 터미널에 흩어놓지 않고 하나의 공유된 장소에 모아둠으로써 이들을 하나의 팀으로 만들어준다. Sharkly의 스프린트는 하나의 Space가 소유하는, 시간이 정해진 Task 집합이다. 아래 방법은 화이트보드에서 실행하든 제품 안에서 실행하든 동일하지만, 작업이 공유 보드로 돌아오면 실패 유형을 더 쉽게 발견할 수 있다.
에이전트가 실행을 맡으면 무엇이 달라지는가
인간-에이전트 팀의 스프린트 계획은 팀이 얼마나 많은 코드를 생산할 수 있는지가 아니라, 사람이 완료된 에이전트 작업을 얼마나 많이 검토하고 승인할 수 있는지를 기준으로 사이클의 범위를 정하는 실무다.
에이전트는 조사하고, 실행하고, 테스트하고, 보고한다. 사람은 방향을 정하고, 권한을 부여하고, 결과를 승인한다. 이 역할 분담이 곧 계획의 전부다. 에이전트의 처리량은 탄력적이다. 셋을 돌릴 수도, 열을 돌릴 수도 있다. 반면 리뷰 처리량은 diff를 읽고 변경 사항을 실행해보고 출시 여부를 결정할 수 있는 사람 수에 의해 고정된다. 에이전트 출력이 5배 늘었다고 해서 출시되는 작업이 5배가 되는 경우가 드문 이유는 리뷰 역량 산정법을 참고하라.
따라서 계획할 때 가장 먼저 잡아야 할 숫자는 스토리 포인트가 아니다. 리뷰 슬롯, 즉 각 리뷰어가 하루에 승인할 수 있는 완료된 Task 수 × 리뷰어 수 × 사이클 일수다. 나머지 모든 것은 이 상한 아래에 들어가야 한다.
스프린트를 단계별로 계획하기
1. 리뷰 상한을 먼저 정하라. 리뷰어가 하루에 실제로 승인할 수 있는 완료된 Task 수를 추정하라. 사소하지 않은 변경을 제대로 리뷰하는 데는 30~60분이 걸린다. 여기에 리뷰어 수와 스프린트 일수를 곱하라. 실패 유형: 이 단계를 건너뛰고 에이전트 역량을 기준으로 계획을 세우면 과도하게 약속하게 되고, 사이클이 끝날 때 스프린트 자체보다 긴 리뷰 큐를 마주하게 된다.
2. Task를 실행이 아니라 리뷰에 맞춰 크기를 정하라. 각 Task가 한 사람이 머릿속에 담을 수 있는 diff를 만들어내도록 작업을 쪼개라. 실패 유형: 에이전트는 아홉 개 파일에 걸친 2,000줄짜리 변경을 기꺼이 내놓지만, 아무도 그것을 한 슬롯 안에 승인할 수 없고, 결국 보드 맨 아래에서 썩어간다.
3. 할당 전에 수용 기준을 작성하라. 각 Task에는 무엇을 만들지, 무엇이 "올바른" 상태인지, 무엇을 건드리지 말아야 하는지에 대한 검증 가능한 완료 정의가 필요하다. 실패 유형: 범위가 모호하면 에이전트가 추측하고, 리뷰어가 되돌려보내고, Task 하나가 리뷰 슬롯 두 개를 태운다.
4. 의도적으로 단일 에이전트 또는 Crew에 할당하라. 작고 잘 정의된 작업에는 에이전트 하나를 사용하라. 리더 에이전트가 목표를 해석하고 다른 멤버를 끌어들이며 그 결과를 하나의 Task로 되가져와야 할 때는 Crew를 사용하라. 실패 유형: 사소한 작업에 Crew를 동원하면 나중에 리뷰해야 할 움직이는 부품만 늘어난다.
5. 진행 중인 작업 수를 제한하라. 칸반의 WIP 제한이 작동하는 방식대로, "리뷰 중" 칼럼에 놓일 수 있는 Task 수에 상한을 두라. 실패 유형: 상한이 없으면 에이전트가 사람이 처리하는 속도보다 빠르게 리뷰 칼럼을 범람시키고, 병목은 마지막 날까지 보이지 않는다.
6. 여유 버퍼를 남겨두라. 재작업과 되돌려보낼 변경 요청을 위한 리뷰 슬롯을 남겨두라. 실패 유형: 100%까지 계획하면 첫 번째 "수정해주세요"가 들어갈 자리가 없다.
스프레드시트나 티켓만으로 운영할 때 확장이 멈추는 지점
첫 스프린트는 스프레드시트로 돌릴 수 있다. Task 목록 탭, 담당자 칼럼, 상태 칼럼. 한 사람이 한 저장소에서 에이전트 두 개를 돌리는 동안에는 이 정도로 유지된다.
실행과 추적이 분리되는 순간 작동을 멈춘다. 에이전트의 실행, diff, 테스트 출력, 논의는 터미널에 있고, 스프레드시트에는 낡아빠진 "진행 중"만 남는다. 누군가 손으로 행을 업데이트하거나, 아무도 하지 않는다. 두 번째 저장소에 세 번째 에이전트를 추가하면 보드는 하루 안에 현실과 어긋난다. 그러면 계획이 의존하는 단 하나의 질문에 답할 수 없게 된다. 무엇이 끝났고, 무엇이 나를 기다리고 있는가?
이런 용도로 만들어진 태스크 보드는 실행과 기록을 함께 유지한다. 작업, 진행 상황, 블로커, 결과가 개인 세션 속으로 사라지는 대신 Task로 돌아온다. Sharkly에서는 에이전트가 준비된 Task를 가져가고, 병렬 변경이 충돌하지 않도록 격리된 워크트리에서 실행되며, 변경 요약과 검증 결과, 알려진 한계가 Task 타임라인으로 돌아와 사람이 승인하거나 되돌려보낼 수 있다. 이것이 여러분이 직접 유지하는 상태와 스스로 유지되는 상태의 차이다. 또한 다음 계획 세션에 실제 데이터를 넘겨준다. 지난 사이클에 에이전트가 완료한 작업과 리뷰 시간이 어디로 갔는지 말이다.
솔직한 경계: 한 저장소에서 에이전트 하나를 돌리며 그때그때 리뷰한다면 태스크 보드나 Sharkly가 필요 없다. 터미널 하나와 체크리스트면 충분하다. 방정식은 여러 에이전트, Task, 저장소, 사람에 걸쳐 계획을 세울 때 달라지며, 바로 그 지점에서 스프레드시트가 두 번째 일자리로 변한다. Sharkly는 후자의 경우를 위해 만들어졌다. 스프레드시트가 거짓말을 하기 시작하면 다운로드하라.
다음 스프린트 전에 점검할 체크리스트
계획을 확정하기 전에 다음을 실행하라:
- [ ] 리뷰 상한(리뷰어 수 x 하루 승인량 x 일수)을 계산하고 이를 스프린트의 실제 역량으로 삼았는가.
- [ ] 모든 Task가 한 슬롯 안에 리뷰할 수 있을 만큼 작은가.
- [ ] 모든 Task에 검증 가능한 수용 기준과 명확한 "건드리지 말 것" 경계가 있는가.
- [ ] 각 Task가 기본값이 아니라 의도적으로 단일 에이전트 또는 Crew에 할당되었는가.
- [ ] "리뷰 중" 칼럼에 WIP 상한이 있는가.
- [ ] 재작업과 변경 요청을 위해 여유를 남겨두었는가.
- [ ] 모든 Task의 병합 및 릴리스 결정을 사람이 소유하는가.
- [ ] 진행 상황, 블로커, 결과가 개인 터미널이 아니라 공유 보드로 돌아오는가.
여덟 가지를 모두 체크하면 에이전트 실행은 팀이 끝낼 수 있는 계획 안에 머문다. 첫 번째를 놓치면 나머지가 여러분을 구해주지 못한다.
FAQ
에이전트가 코드 대부분을 작성하는데도 스프린트 계획이 여전히 유용한가? 그렇다. 다만 제약이 옮겨간다. 스프린트는 엔지니어링 시간의 그릇이기를 멈추고 리뷰와 승인의 그릇이 된다. 사람이 검토할 수 있는 완료된 작업의 양을 기준으로 사이클을 계획하면 에이전트가 그것을 채운다. 스크럼 가이드는 여전히 이 의식을 정의한다. 바뀌는 것은 역량 산정뿐이다.
인간-에이전트 팀의 역량은 어떻게 추정하는가? 에이전트가 아니라 리뷰어에서 시작하라. 한 사람이 하루에 정직하게 승인할 수 있는 완료된 Task 수를 세고, 리뷰어 수와 스프린트 일수를 곱하라. 에이전트 수는 그 상한을 넘을 때까지만 중요하다. 그 이후에는 에이전트가 늘어날수록 큐만 길어진다.
스프린트 중에 에이전트가 스스로 Task를 고르게 해야 하는가? 이미 수용 기준을 갖춘 준비된 Task를 가져가게 하라. 그러면 디스패처 없이도 병렬 작업이 진행된다. 사람은 방향, 권한, 병합에 집중하게 하라. 이렇게 하면 휴먼 인 더 루프가 판단이 필요한 곳에 남고 나머지 모든 곳에서는 자동화된다.
일반적인 프로젝트 관리와 무엇이 다른가? 의식은 비슷해 보이지만 병목이 다르다. AI 에이전트 프로젝트 관리는 실행이 더 이상 희소 자원이 아니기 때문에 개발자 가용성이 아니라 리뷰 처리량과 변경 격리를 기준으로 계획한다.
새 도구가 필요한가, 아니면 Jira를 확장할 수 있는가? 팀이 이미 이해하는 시스템을 유지해도 된다. 차이는 티켓 도구가 사람이 타이핑하는 상태를 추적할 뿐, 기계가 실행하는 실행 자체를 추적하지 않는다는 점이다. 그 차이가 언제부터 아프기 시작하는지는 인간-에이전트 팀을 위한 Jira 대안을 참고하라.
