인간-AI 하이브리드 팀을 위한 스프린트: Sharkly의 스프린트 운영 방식

스프린트 계획은 늘 조용한 가정 하나에 기대 왔다. 용량이란 인원수에 타임박스를 곱한 값이라는 가정이다. 작업을 추정하고, 지난 주기에 팀이 끝낸 양과 비교한 뒤, 거기에 맞는 범위를 약속한다.

여기에 AI 코딩 에이전트를 팀에 투입하는 순간 그 방정식은 더 이상 현실을 설명하지 못한다. 에이전트는 태스크가 준비되는 즉시 가져갈 수 있고, 다른 모든 에이전트와 병렬로 작업하며, 그것을 논의하려던 스탠드업이 열리기도 전에 diff와 테스트 결과를 들고 돌아온다. 실행 용량은 극적으로 부풀어 오른다. 그럴듯한 대응은 더 많은 범위를 약속하는 것이지만, 그렇게 하는 팀은 대개 첫 주기가 끝날 무렵 실패 모드를 발견한다. 스프린트는 완성된 코드는 잔뜩 쌓였는데, 아무도 받아들일 시간이 없었던 리뷰되지 않은 변경 사항의 벽만 남긴 채 마감된다.

이 글의 주장은 이것이다. 팀에 에이전트가 있으면 실행은 더 이상 스프린트의 제약이 아니고, 사람의 리뷰가 스프린트의 제약이 된다. 코드를 얼마나 많이 생산할 수 있는지가 아니라 승인 처리량을 기준으로 계획하라. 여기서는 Sharkly의 스프린트를 구체적인 메커니즘으로 삼고, 계획에 관한 논증과 제품 사실을 명확히 분리해 설명하겠다.

TL;DR

Sharkly의 스프린트는 하나의 스페이스가 소유하는, 타임박스가 정해진 태스크 묶음이다. 태스크는 실행과 논의의 원천으로 남고, 스프린트는 여기에 일정, 범위, 리포팅을 더한다. 스프린트는 선택 사항이며 두 가지 모드 중 하나로 운영된다. Sharkly가 일정을 관리하고 미완료 작업을 다음으로 넘겨주는 자동 주기(Automatic cadence), 또는 사람이 스프린트를 직접 생성하고 시작하고 완료하는 수동(Manual) 모드다. 리포팅은 범위, 시작된 작업과 완료된 작업, 완료율, 용량, 번업 이력을 다룬다. 사람과 에이전트가 섞인 하이브리드 팀에서 계획의 전환점은 이것이다. 에이전트는 실행 용량을 부풀리지만 승인은 사람의 몫으로 남는다. 따라서 정직한 스프린트 약속은 에이전트가 얼마나 많이 생산할 수 있는지가 아니라, 리뷰어가 완성된 작업을 얼마나 많이 승인할 수 있는지에 의해 제한된다.

Sharkly에서 스프린트란 무엇인가

스프린트는 하나의 스페이스가 소유하는, 타임박스가 정해진 태스크 묶음이다. 팀이 집중할 범위를 계획하고, 진행 상황을 추적하며, 타임박스가 끝났을 때 미완료 작업을 어떻게 처리할지 정하도록 돕는다. 태스크는 실행과 논의의 원천으로 남고, 스프린트는 그 위에 일정, 범위, 리포팅을 더한다.

문서에서 쓰는 '스프린트'라는 용어는 업계에서 통용되는 의미 그대로다. 스크럼 가이드는 스프린트를 아이디어가 가치로 바뀌는 고정 길이의 컨테이너로 설명하는데, Sharkly의 스프린트도 그 계보를 잇는다. Sharkly가 바꾸는 것은 그 시간창 안에서 누가 실행을 맡는가다.

개념을 명확하게 유지하는 세 가지 경계가 있다.

• 스프린트는 정확히 하나의 스페이스에 속한다. 태스크를 스프린트에 넣어도 소유권은 바뀌지 않는다.
• 스프린트는 선택 사항이며 스페이스 단위로 활성화한다. 연속 흐름(continuous flow) 방식으로 일하는 스페이스는 아예 켜지 않아도 된다.
• 스프린트는 프로젝트도 아니고 뷰도 아니다. 특정 타임박스 안에 무엇을 완료해야 하는지가 문제라면 스프린트를 쓴다. 여러 스프린트나 스페이스에 걸칠 수 있는 결과물이라면 프로젝트를 쓴다. 태스크를 살펴보는 방식을 저장해 두고 싶다면 뷰를 쓴다.

마지막 구분은 하이브리드 팀에서 실제로 중요한 역할을 한다. 프로젝트는 결과물을 담고, 스프린트는 단기 약속을 담고, 뷰는 각자가 일상적으로 필요로 하는 조각을 담는다.

자동 주기 모드와 수동 모드

스페이스에서 스프린트를 활성화하면 두 가지 라이프사이클 모드 중 하나를 고른다. 이 선택은 라이프사이클 동작을 바꿀 뿐, 태스크 소유권은 바꾸지 않는다.

자동 주기 모드는 달력을 Sharkly에 맡긴다. 스프린트 기간, 선택 사항인 쿨다운, 시작 요일, 앞으로 몇 개의 스프린트를 유지할지, 타임존, 그리고 태스크가 지정한 상태 카테고리에 들어오면 자동으로 추가하는 규칙을 설정한다. 그러면 Sharkly가 향후 스프린트를 만들고, 일정에 맞춰 시작하고 완료하며, 미완료 작업을 다음으로 넘긴다. 예정된 스프린트를 앞당겨 시작하면 현재 스프린트가 먼저 완료되고, 그 미완료 작업이 새로 시작하는 스프린트로 넘어간다.

수동 모드는 라이프사이클 제어권을 팀에 남겨 둔다. 필요할 때 사람이 계획된 스프린트를 만들고, 설정된 날짜를 바꾸지 않고 시작하며, 여러 개의 활성 스프린트를 동시에 운영하고, 완료 시 미완료 태스크가 어디로 갈지 직접 고른다. 자동 생성, 이월, 쿨다운, 상태 기반 추가 규칙은 수동 모드에서 작동하지 않는다.

솔직한 선택 기준은 이렇다. 팀이 꾸준한 리듬으로 일하고 그 운영을 대신 관리받고 싶다면 자동 주기를 쓴다. 주기가 불규칙하거나, 달력이 아니라 릴리스가 기간을 정하거나, 활성 스프린트 두 개를 동시에 돌려야 한다면 수동을 쓴다. 수동으로 전환하면 기존 스프린트는 유지되지만 자동 스케줄링은 멈춘다. 스프린트를 완전히 비활성화하면 활성 스프린트는 완료되고 예정된 스프린트는 삭제되며, 완료된 데이터는 리포팅을 위해 보존된다.

태스크가 스프린트에 들어오고, 나가고, 건너뛰는 방식

스프린트는 다섯 가지 표시 상태로 나타난다. 현재(Current), 예정(Upcoming), 계획됨(Planned), 완료됨(Completed), 취소됨(Canceled). 완료 및 취소된 스프린트는 활성 계획 목록을 어지럽히지 않도록 스페이스 아카이브로 이동한다.

태스크는 스프린트 필드를 통해서, 태스크 목록에서, 또는 스프린트 계획 중에 추가하거나 옮긴다. 두 가지 규칙은 보기보다 중요하다.

첫째, 태스크는 스프린트가 아예 없을 수 있다. 백로그 작업과 어떤 타임박스에도 약속되지 않은 태스크가 기본적으로 머무는 자리다.

둘째, 태스크를 스프린트에 추가해도 상태는 바뀌지 않는다. 하이브리드 팀이 반드시 체득해야 할 규칙인데, Sharkly에서 백로그 상태 카테고리는 대기 상태이기 때문이다. 태스크를 만들거나 에이전트를 배정하더라도 태스크가 백로그에 있는 동안에는 실행이 시작되지 않는다. 태스크를 백로그에서 꺼내 준비 상태로 옮겨야 배정된 에이전트가 실행을 시작할 수 있다. 즉 스프린트 계획과 실행 개시는 서로 별개의 레버다. 월요일에 에이전트 배정까지 마친 채 스프린트 전체를 계획해 두고, 각 태스크를 의도적으로 준비 상태로 옮기기 전까지는 아무것도 실행되지 않게 할 수 있다. 이후 상태 변경 자동화로 표준화하고 싶은 전환을 처리하면 된다.

이력을 보호하는 규칙이 하나 더 있다. 이전 스프린트에는 완료된 태스크만 추가할 수 있다. 미완료 작업을 이미 닫힌 기간에 넣지 않고도 과거를 정정할 수 있게 해준다.

날짜의 경우, 계획된 스프린트는 시작일과 종료일 모두 편집할 수 있지만, 활성 스프린트는 시작일이 고정되고 종료일만 변경할 수 있다.

스프린트 리포팅이 알려주는 것

스프린트 리포팅에는 태스크 수와, 스페이스에서 추정치(estimates)를 활성화한 경우 추정 포인트 합계가 포함되며, 이를 여섯 가지 지표로 보여준다. 범위, 시작된 작업, 완료된 작업, 완료율, 용량, 번업 이력이다.

용량은 더 자세히 볼 가치가 있다. 계획 논의가 매달리는 숫자가 바로 이것이기 때문이다. Sharkly는 충분한 이력이 있으면 최근 완료된 스프린트의 벨로시티에서 용량을 도출하고, 그렇지 않으면 스페이스 규모에 기반한 추정치로 대체한다. 문서에서는 이를 보장이 아니라 계획 입력값으로 다루라고 권하는데, 하이브리드 팀에게 이 단서는 상투적인 문구가 아니다. 사람만으로 구성된 집단에서 측정한 벨로시티는 에이전트 세 개를 투입한 그 주부터 아무것도 예측하지 못한다. 번업 이력이 더 많은 것을 말해 줄 때가 많다. 범위가 초반에 몰려 완료되다가 선이 평평해진다면, 에이전트는 실행을 끝냈고 리뷰어들이 남은 스프린트 기간 내내 따라잡느라 시간을 보냈다는 뜻이다.

하이브리드 팀의 제약: 실행이 아니라 리뷰를 기준으로 계획하라

이 섹션의 내용은 모두 계획에 관한 논증이며, 제품 기능이 아니다. Sharkly는 위에 설명한 스프린트 메커니즘을 제공할 뿐이고, 스프린트에 얼마나 실을지는 판단의 몫이다.

역할 분담에서 출발하자. 에이전트는 조사하고, 실행하고, 테스트하고, 보고한다. 사람은 방향을 정하고, 권한을 부여하고, 결과를 승인한다. 에이전틱 코딩에서는 방향 설정과 승인 사이의 모든 것을 위임할 수 있지만, 승인은 사람의 몫으로 남는다. 태스크를 끝낸 에이전트는 스프린트가 완료로 셀 만한 어떤 의미에서도 그것을 끝낸 것이 아니다. diff, 검증 결과, 알려진 한계가 태스크로 돌아오고, 사람이 여전히 그것을 읽고 승인하거나, 수정을 요청하거나, 병합 여부를 결정해야 한다.

이제 계산을 해 보자. 다섯 명 팀에 에이전트를 추가해 실행 처리량이 세 배가 되었다고 하자. 리뷰 처리량은 세 배가 되지 않았다. 같은 다섯 명이 감당해야 하고, 승인하는 변경 하나하나에 실제로 주의력이 든다. 실행 용량을 기준으로 스프린트를 계획하면 그 잉여는 출시되는 가치가 되지 못한다. 리뷰되지 않은 작업의 대기열이 되고, 리뷰되지 않은 변경은 진전이 아니라 재고다. 더 나쁜 것은, 스프린트가 막바지에 다다르면 리뷰어들이 에이전트 중심 개발을 위험하게 만드는 바로 그 지름길로 밀린다는 점이다. 읽지 않고 결과를 승인하는 것이다.

그러니 계획의 질문을 뒤집어 보자. 팀이 2주 동안 얼마나 많은 작업을 실행할 수 있는지가 아니라, 사람이 2주 동안 얼마나 많은 완성된 에이전트 작업을 승인할 수 있는지 물어야 한다. 실제로 이는 네 가지 습관을 바꾼다.

1. 구축 비용만이 아니라 리뷰 비용을 추정한다. 에이전트가 실행하기에는 사소한 태스크라도 승인하기에는 비쌀 수 있다.
2. 완료됐지만 승인되지 않은 작업의 동시 처리량에 상한을 둔다. 리뷰어 한 명이 스프린트당 실제로 승인할 수 있는 태스크 수를 정하고, 그 합계를 넘겨서는 계획하지 않는다. 이는 Sharkly 설정이 아니라 팀의 작업 합의지만, 완료 지표가 초과했다는 사실을 알려 줄 것이다.
3. 실행 개시를 의도적으로 조절한다. 백로그가 실행을 대기시키므로, 완성된 작업이 둘째 날에 한꺼번에 몰리지 않고 리뷰어가 소화할 수 있는 속도로 도착하도록 시작 시점을 분산할 수 있다.
4. 완료율을 리뷰 지표로 읽는다. 에이전트가 놀고 있는데 번업이 평평해진다면, 제약이 스스로를 드러낸 것이다. 이는 에이전트를 더 추가하라는 신호가 아니라, 리뷰어를 늘리거나 더 적게 약속하라는 신호다.

이 중 어느 것도 에이전트의 속도를 늦추지 않는다. 방향을 잡아 줄 뿐이다. 승인 처리량을 기준으로 계획한 스프린트는 약속한 것을 모두 출시하고, 사람에게 읽을 시간이 없었던 코드를 승인하라고 요구하지 않는다.

하이브리드 스프린트 계획하기, 단계별로

1. 스페이스에서 스프린트를 활성화하고 모드를 고른다. 팀 리듬이 꾸준하다면 자동 주기, 릴리스 중심 작업이라면 수동이 적합하다.
2. 범위를 구성한다. 스프린트 계획이나 스프린트 필드를 통해 후보 태스크를 예정된 스프린트로 가져온다. 약속하지 않은 작업은 스프린트 없음 상태로 둔다.
3. 각 태스크의 양쪽 역할을 모두 배정한다. Sharkly는 사람의 책임과 에이전트의 실행을 분리한다. 사람은 담당자 세트에 들어가고, 에이전트나 크루는 단일 실행 슬롯에 들어간다. 한쪽을 바꿔도 다른 쪽은 바뀌지 않는다.
4. 에이전트가 실행할 수 있는 태스크를 작성한다. 설명에는 새로 합류한 사람이나 에이전트가 진행하는 데 필요한 목표, 제약 조건, 승인 기준이 담겨야 한다.
5. 리뷰 속도에 맞춰 작업을 풀어 준다. 리뷰어의 여력이 생기는 대로 태스크를 백로그에서 꺼낸다.
6. 의도를 가지고 마무리한다. 수동 모드에서는 미완료 태스크마다 어디로 갈지 정한다. 자동 주기에서는 무엇이 이월됐는지 확인하고, 범위를 너무 크게 잡았는지 아니면 리뷰가 너무 느렸는지 따져 본다.

이런 방식으로 일을 운영하는 더 넓은 규율은 AI 에이전트 프로젝트 관리 필러 글에서 다룬다. 스프린트는 그 시스템에서 타임박스로 잘린 한 조각이다.

지금 스프린트가 Jira에 있다면

이걸 한번 해보겠다고 프로세스를 새로 만들 필요는 없다. Sharkly의 Jira 연동은 Jira 스프린트 데이터를 가져올 수 있고, 스프린트 가져오기를 활성화하면 대상 스페이스를 Jira 스프린트 모드로 전환할 수 있어 팀이 이미 돌리는 주기를 그대로 가져올 수 있다. 제로에서 시작하지 않아도 된다. Jira 티켓을 AI 에이전트에 배정하는 방법 안내에서는 같은 아이디어를 티켓 한 건 수준에서 보여 주고, Sharkly 문서에서는 스프린트 구성과 Jira 연동을 깊이 있게 다룬다.

마이그레이션보다 작게 시작하자. 스페이스 하나에서 스프린트를 켜고, 리뷰어의 실제 승인 여력을 기준으로 2주짜리 기간을 하나 계획한 뒤, 지난번 사람만 있던 주기와 번업을 비교해 보라.

자주 묻는 질문

Sharkly에서 스프린트를 꼭 써야 하나요?

아니요. 스프린트는 선택 사항이며 스페이스 단위로 활성화합니다. 연속 흐름을 선호하는 스페이스는 아예 켜지 않아도 되고, 스프린트를 활성화한 경우에도 태스크에 스프린트가 없을 수 있는데, 이는 백로그 작업의 일반적인 상태입니다.

스프린트가 끝나면 미완료 태스크는 어떻게 되나요?

자동 주기에서는 Sharkly가 일정에 맞춰 스프린트를 완료하고 미완료 작업을 다음 스프린트로 이월합니다. 수동 모드에서는 완료 흐름에서 미완료 태스크를 어디로 보낼지 묻습니다. 스프린트 없음, 다른 활성 또는 예정 스프린트, 새로 만든 스프린트 중에서 고르면 됩니다.

에이전트가 스프린트 태스크를 자동으로 처리할 수 있나요?

태스크의 실행 담당자로 지정된 에이전트나 크루는 작업을 실행할 수 있지만, 스프린트에 속해 있다는 사실만으로 무언가가 시작되지는 않습니다. 백로그는 대기 상태이므로 백로그 태스크에 에이전트를 배정해도 실행이 시작되지 않습니다. 태스크를 준비 상태로 옮겨야 실행이 시작될 수 있습니다. 이 분리 덕분에 스프린트 전체를 먼저 계획하고, 리뷰어가 소화할 수 있는 속도에 맞춰 실행을 풀어 줄 수 있습니다.

Sharkly는 스프린트 용량을 어떻게 계산하나요?

용량은 충분한 이력이 있으면 최근 완료된 스프린트의 벨로시티를 사용하고, 그렇지 않으면 스페이스 규모에 기반한 추정치로 대체합니다. 문서에서는 이를 보장이 아니라 계획 입력값으로 다루라고 권하는데, 이는 하이브리드 팀에서 두 배로 중요합니다. 벨로시티는 내부의 리뷰 병목이 아니라 전체 시스템을 측정하기 때문입니다.

이미 끝난 스프린트에 태스크를 추가할 수 있나요?

완료된 태스크만 이전 스프린트에 추가할 수 있습니다. 기간 안에 끝났지만 기록되지 않은 작업을 반영하는 등 과거를 정정할 수 있으면서도, 미완료 작업을 이미 닫힌 기간에 넣는 일은 없습니다.