스크럼은 '우리가 잘 모른다'는 것을 관리하는 프레임워크였다
솔직하게 말하자. 스프린트, 스탠드업, 리파인먼트, 스파이크—우리가 Agile이라 불러온 이 의식들은 사실 '계획의 공백'을 반복적 구현으로 메우는 구조였다. dev.to에 올라온 Giovanni의 글 The Post-Scrum Era는 이걸 직설적으로 짚는다. "우리는 이터레이션이라고 불렀지만, 사실은 계획을 제대로 안 한 것에 그럴듯한 이름을 붙인 것일 수 있다."
이 말이 불편하게 들린다면, 아마 맞는 말이기 때문이다.
병목이 이동했다
AI 코딩 에이전트가 등장하면서 개발 속도의 구조가 바뀌었다. 구현 자체—코드를 타이핑하는 행위—가 더 이상 느린 구간이 아니다. Cursor와 에이전트 스택을 쓰는 개발자가 2일 만에 이전 2주치 작업을 끝낸다면, 2주 스프린트는 무엇을 보호하고 있는 걸까?
병목은 구현에서 계획과 명세로 이동했다. 그런데 대부분의 팀은 아직 스프린트 구조를 그대로 두고 AI 도구만 얹고 있다. 그건 F1 머신에 일반 도로 제한속도를 적용하는 것과 같다.
리파인먼트가 '검증'으로 바뀌는 순간
Post-Scrum Era 기사에서 실제로 일어난 일이 흥미롭다. 팀이 "CSV 내보내기 버튼"이라는 단순해 보이는 티켓을 AI gap analyzer에 돌렸더니—설계 시스템, 서비스 아키텍처, 연관 티켓을 전부 컨텍스트로 먹인—2분 만에 숨어있던 문제가 터져나왔다. 동기 API의 30초 타임아웃 한계, 수천 행 데이터에서의 무음 실패, 저장된 뷰 기능 파괴 가능성. 티켓 2개가 9개짜리 에픽이 됐다.
구현 3일 차에 개발자가 스테이징에서 타임아웃을 맞닥뜨리며 욕이 나올 뻔한 상황을 계획 단계에서 잡은 것이다.
이게 핵심이다. 리파인먼트의 성격이 달라진다. "이 티켓이 뭔가요?"를 토론하는 자리가 아니라, "에이전트가 플래그한 세 가지 질문의 소유자가 누구인가?"를 확인하는 자리로. 협상이 아니라 검증.
스탠드업을 '방어'에서 '공격'으로
기술적 블로커를 스프린트 시작 전에 대부분 해소했다면, 매일 아침 스탠드업은 무엇을 위한 자리인가?
스탠드업은 원래 방어적이었다. 상태 보고, 블로커 탐색, "블로커 없습니다"라고 말하면서 속으로는 익사 중인 그 의식. AI가 기술적 안개를 걷어내면 이 블로커들은 대부분 사라진다.
그 자리를 공격적으로 써야 한다. "어제 에이전트한테 흥미로운 패턴을 쓰게 해봤는데, PR 봐" 같은 혁신 공유의 공간. 모든 것이 에이전트 속도로 움직일 때, 함께하는 동기 시간은 희소 자산이 된다. 마이크로매니징에 낭비하기엔 너무 아깝다.
결정론적 프롬프트가 없으면 에이전트 속도는 가짜다
그런데 여기서 현장의 냉정한 현실을 하나 짚어야 한다. 에이전트가 빠르게 코드를 뱉는다고 해서 팀이 빨라지는 게 아니다. 프롬프트가 불안정하면 같은 요청에 다른 출력이 나오고, 예상치 못한 파일이 바뀌고, 동작을 추론하기 어려워진다. 소규모 프로젝트에선 감당할 수 있지만, 시스템이 커지면 리스크가 된다.
dev.to의 또 다른 글 Exploring a more deterministic approach to AI-assisted code generation에서 제안하는 방향이 실용적이다. 프롬프트를 소스코드처럼 다루는 것—명시적이고, 재사용 가능하고, 컴포저블하게. 저자가 만든 SVI(Structured Vibe Coding) 툴처럼 .svi 명세 파일에서 최종 프롬프트를 결정론적으로 구성하면, 어떤 프롬프트가 어떤 파일을 생성했는지 추적 가능하고, 더 작은 모델로도 예측 가능한 결과를 낼 수 있다.
"AI에게 채팅하는" 워크플로우에서 "시스템 아키텍처를 설계하는" 워크플로우로의 전환. 이건 유연성을 일부 포기하는 트레이드오프지만, 대형 코드베이스에서는 그 포기가 충분히 값어치를 한다.
에이전트 오케스트레이션 실험: 두 번째 신호
I Made Kimi Build Its Own Tiny Coding Team 기사는 개인 실험 수준이지만, 방향성을 읽기에 충분하다. 단일 AI 어시스턴트에 오케스트레이션 레이어를 씌워 DAG 기반 실행, 워크트리 격리, evidence gate를 갖춘 '작은 코딩 팀'을 만든 시도다.
핵심 교훈은 도구가 아니라 구조에 있다. 에이전트 출력을 텍스트 그대로 믿지 말고, 상태·로그·증거·재현 가능성으로 검증하라는 것. npm test가 통과했는지, 파일이 실제로 존재하는지를 evidence gate로 확인하는 방식은 AI 생성물을 팀 워크플로우에 안전하게 통합하는 기초 설계다.
그래서 무엇이 달라져야 하나
정리하면 에이전트 시대의 개발 리듬은 세 가지 축으로 재설계된다.
첫째, 계획을 앞으로 당기되 AI에게 계획 자체를 시켜라. gap analyzer, spec-driven planning, structured prompting—구현 전에 기술적 불확실성을 최대한 제거하는 것이 새로운 리파인먼트의 목표다. 스파이크는 "우리가 모른다"는 고백이 아니라, "에이전트가 플래그한 것 중 여전히 사람이 판단해야 할 것"이 되어야 한다.
둘째, 프롬프트를 코드처럼 관리하라. 팀 전체가 동일한 프롬프트 구조를 공유하고 버전 관리하지 않으면, 에이전트 속도는 개인 생산성에 머무른다. 재현 가능성과 추적 가능성이 없는 AI 생성 코드는 기술 부채를 빠르게 쌓는다.
셋째, 스탠드업과 동기 시간의 목적을 바꿔라. 에이전트가 기술적 블로커를 줄인 자리에 문화적 캘리브레이션을 채워라. 어떤 패턴이 효과적이었는지, 어떤 edge case를 에이전트가 놓쳤는지, 팀이 함께 학습하는 공간.
스크럼에 AI를 볼트로 박지 마라
이것은 스크럼을 더 빠르게 돌리는 얘기가 아니다. Post-Scrum Era 기사의 표현이 정확하다. "Agile은 인간의 무지와 예측 불가능성을 관리하는 프레임워크였다. AI-First 개발은 그 전제를 뒤집는다." 구현을 통해 무엇이 잘못인지 발견하는 방식에서, 계획을 철저히 해서 빌드가 거의 기계적이 되게 만드는 방식으로.
팀이 여전히 2주 스프린트를 돌리면서 Cursor와 Claude Code를 끼워 넣고 있다면, 그건 도구 도입이 아니라 도구 낭비다. 프로세스 자체가 달라져야 한다. 스프린트는 코드를 타이핑하는 레이스가 아니라, 대부분의 엔지니어링 작업이 첫 번째 코드 라인 생성 전에 끝난 상태에서 그것을 딜리버리하는 운반체가 되어야 한다.
그게 스크럼은 아니다. 아직 이름이 없는 무언가다. 그리고 그 이름을 짓는 것, 지금 테크리드의 일이다.