왜 스프린트가 부서졌는가

Source: Dev.to

위 링크에 있는 글의 전체 내용을 제공해 주시면, 해당 텍스트를 한국어로 번역해 드리겠습니다. (코드 블록, URL 및 마크다운 형식은 그대로 유지됩니다.)

Introduction

많은 엔지니어링 팀이 생각하고 있지만 입 밖으로 내지 못하는 말을 하겠습니다: 스프린트는 더 이상 효과가 없습니다.

모두에게 해당되는 것은 아니며, 모든 상황에 적용되는 것도 아닙니다. 2주 주기로 실제로 생산성을 내고 구조를 유용하게 활용하는 팀도 여전히 존재합니다. 하지만 현대적인 도구, AI‑지원 개발, 복잡한 제품 문제를 다루는 엔지니어링 조직이 늘어날수록 스프린트 모델은 실천이라기보다 퍼포먼스로 전락하고 있습니다. 의식은 계속되고, 포인트는 추정되며, 벨로시티는 추적됩니다. 그런데 그 모든 것 아래에서 실제 작업은 스프린트 구조가 포착하지 못하고 오히려 방해가 되는 완전히 다른 리듬으로 진행되고 있습니다.

이 글은 애자일 철학을 비난하기 위한 것이 아닙니다. 애자일의 핵심 아이디어—반복적인 개발, 변화에 대한 대응, 긴밀한 협업, 작동하는 소프트웨어의 지속적인 제공—는 타당하고 여전히 유효합니다. 여기서 말하고자 하는 것은 2000년대에 대부분의 팀이 채택하고 그 이후로 계속 운영해 온 구체적인 구현 방식이며, 그 구현이 오늘날 실제 소프트웨어가 구축되는 방식과 점점 더 맞지 않게 되는 이유입니다.

1. 스프린트 모델이 등장한 배경

스크럼과 2주 스프린트

스크럼과 2주 스프린트는 특정 상황에서 등장했습니다. 팀들은 긴 워터폴 사이클로 소프트웨어를 개발하고 있었으며, 요구사항은 몇 달 전에 고정되었습니다. 그리고 소프트웨어가 실제로 배포될 때쯤이면, 그때 해결하려던 문제는 이미 변했거나 완전히 사라진 경우가 많았습니다. 스프린트는 이러한 상황을 바로잡기 위한 메커니즘이었습니다. 팀에게 매 2주마다 시연 가능한 결과물을 내도록 강제함으로써, 워터폴이 제공하지 못했던 피드백 루프를 만들었습니다. 6개월짜리 계획 단계에 숨을 수 없었습니다. 정기적으로 작업물을 보여주고, 배운 점에 즉시 대응해야 했습니다.

그것은 실제로 큰 가치를 제공했습니다. 그 맥락에서 스프린트는 올바른 도구였습니다.

2. 상황이 어떻게 변했는가

새로운 피드백 루프

• 하루에 여러 번 배포합니다.
• 기능 플래그를 사용해 실험을 진행합니다.
• 분석, 세션 녹화, 지속적인 리서치를 통해 사용자 피드백을 얻습니다.

두 주 단위 사이클을 유용하게 만든 강제 요소—즉, 원래는 없던 인위적인 체크포인트를 만들 필요성—는 프로세스 자체가 더 연속적으로 변하면서 덜 필요해졌습니다.

더 복잡해진 작업

오늘날 엔지니어링 팀이 해결하고 있는 문제는 다음과 같습니다:

• 더 복잡하고 상호 연결되어 있습니다.
• 전형적인 CRUD 애플리케이션 작업 스프린트 방법론이 최적화된 상황보다 더 모호합니다.

작업을 명확하고 추정 가능한 개별 작업으로 분해할 수 있을 때는 2주 스프린트가 비교적 잘 작동합니다. 그러나 탐색적 기술 작업을 수행하거나, 상당한 unknown unknowns 를 포함한 시스템을 구축하거나, 올바른 해결책이 시도 과정의 중간에야 비로소 드러나는 문제에 직면했을 때는 그 효율성이 크게 떨어집니다.

3. AI 차원

LLM은 엔지니어링을 단순하고 선형적으로 더 쉽게 만들지는 않았습니다. 대신 특정 작업 범주의 소요 시간을 압축했습니다—보일러플레이트 구현, 테스트 생성, 문서화, 직관적인 기능 개발—다른 범주는 크게 변하지 않거나 경우에 따라 더 복잡해졌습니다.

• 인지 작업 (문제를 깊이 이해하고, 올바른 시스템을 설계하며, 아키텍처 트레이드오프를 수행하고, 생성된 출력을 비판적으로 검토하는 것)은 빨라지지 않았습니다.
• 어떤 면에서는 더 어려워졌습니다. 생산되는 코드 양은 증가했지만, 이를 신중히 고민할 수 있는 시간은 늘어나지 않았기 때문입니다.

결과적인 비대칭

2년 전에는 구현 작업에 3일이 걸리던 작업이 이제는 구현 작업에 3시간만 걸리지만, 여전히 사고, 범위 정의, 검토에 동일한 2일이 필요합니다. 구현 시간을 주요 작업 단위로 삼았던 스프린트 모델은 이를 적절히 반영할 방법이 없습니다.

스토리 포인트는 언제나 노력의 부정확한 대리 지표였지만, 최소한 실제와 연관성이 있었습니다. 구현 시간이 전체 작업을 대표하지 않게 되면서 그 연관성이 무너지게 되었습니다.

4. 리듬 문제

2주 스프린트는 작업이 2주 단위에 깔끔하게 들어간다고 가정하는 리듬을 만듭니다. 일부 작업은 그렇지만, 많은 중요한 작업은 그렇지 않습니다.

• 중요한 아키텍처 조사에는 소규모 팀이 집중해서 6주가 필요할 수 있습니다.
• 진정으로 새로운 기능은 구축, 학습, 재구축의 사이클이 필요하며, 이는 고정된 스프린트 경계에 맞추어지지 않을 수 있습니다.

팀이 이러한 작업을 2주 단위에 억지로 맞추려 하면 두 가지 상황 중 하나가 발생합니다:

1. 인위적인 범위 설정 – 작업이 컨테이너에 맞게 잘려서 팀이 전체 문제를 다루지 못합니다.
2. 스필오버 – 작업이 스프린트 경계를 넘어 퍼져 스프린트 구조가 계획 도구로서 의미를 잃게 됩니다.

5. 의식 오버헤드

일반적인 스프린트에는 다음이 포함됩니다:

• 계획
• 데일리 스탠드‑업
• 스프린트 중간 체크‑인
• 리뷰
• 회고

엔지니어 8명으로 구성된 팀의 경우, 스프린트당 4~6시간 정도의 동기식 회의 시간이 쉽게 소요되며, 티켓 업데이트, 스프린트 보고서 작성, 백로그 유지와 같은 비동기적 작업을 포함하지 않은 수치입니다. 일부 팀에서는 의식(회의)과 실제 엔지니어링 작업 사이의 비율이 실제로 놀라울 정도로 높습니다.

6. 협업 및 회고 재고

나는 협업과 회고가 가치가 없다고 주장하는 것이 아니라—당연히 가치가 있다는 것을 인정한다. 내가 주장하는 것은 스프린트 방법론에서 이러한 활동이 취하는 구체적인 형태가 커뮤니케이션 도구, 배포 인프라, 그리고 개발 툴링이 현재 대부분의 팀에 제공되는 상황을 전혀 고려하지 않고 설계되었다는 점이다. 현대 엔지니어링 환경에서 그 오버헤드는 창출하는 가치에 비해 비례하지 않는다.

마무리 생각

스프린트 모델이 실제 작업 방식과 더 이상 맞지 않는다면, 이제 물어볼 때다: 무엇이 그것을 대체할 것인가? 답은 아마도 지속적인 배포 파이프라인, 가벼운 비동기 협업, 그리고 현대 소프트웨어 개발의 새로운 리듬을 존중하는 결과‑중심 계획의 조합이 될 것이다.

The Estimation Problem

추정 문제는 그 자체로 별도의 순간을 가질 가치가 있습니다. 왜냐하면 이곳이 기능 장애가 가장 뚜렷하게 드러나고 가장 사기를 꺾는 곳이기 때문입니다. 스토리 포인트 추정은 팀과 이해관계자에게 스프린트에 얼마만큼의 작업이 들어갈 수 있는지에 대한 감을 주고, 시간에 따라 속도를 추적하기 위해 존재합니다. 실제로는 오해를 불러일으킬 정도로 신뢰할 수 없으면서도, 의미가 있는 듯한 정밀함을 가진 숫자를 만들어냅니다.

엔지니어들은 이를 잘 알고 있습니다. 그들은 자신의 추정이 종종 틀리며, 추정을 틀리게 만드는 요인들이 대부분 자신들의 통제 밖에 있다는 것, 그리고 그 추정으로부터 도출된 속도 지표가 이해관계자에 의해 실제 데이터가 뒷받침하지 않는 결정을 내리는 데 사용되고 있다는 것을 압니다. 그 결과, 계획에 대한 조용한 냉소가 엔지니어링 팀 전체에 퍼지고, 프로세스에 진정으로 참여하기가 점점 더 어려워집니다.

Why Estimation Is Hard

추정과 관련된 근본적인 문제는 엔지니어들이 추정을 못한다는 것이 아닙니다. 소프트웨어 추정 자체가 어떤 방법론도 완전히 해결하지 못하는 방식으로 진짜로 어렵기 때문입니다.

• 가장 정확하게 추정하기 쉬운 작업은 이전에 수행한 작업과 가장 유사한 작업입니다.
• 가장 중요한 작업—새로운 문제, 아키텍처 결정, 탐색적 조사—은 정의상 이전에 해본 적이 없기 때문에 가장 추정하기 어렵습니다.

익숙하고 분해 가능한 작업에 최적화된 추정 프로세스를 강제로 적용하면, 별로 의미가 없는 자신감 넘치는 숫자가 만들어집니다.

더 나은 모델은 어떤 모습일까

“이 작업은 얼마나 걸릴까?” 라고 묻는 대신, “이 문제에 대해 우리는 얼마나 큰 욕구를 가지고 있나요?” 라고 물어보세요.

• 언젠가 할 수도 있는 모든 일을 백로그에 채워 넣는 대신, 다음 사이클에서 가장 중요한 일에 대해 명확한 베팅을 하세요.
• 구조적인 여유 없이 2주 스프린트를 연속으로 달리는 대신, 팀이 실제로 생각하고, 정리하고, 리셋할 수 있는 시간을 마련하세요.

이 아이디어는 Basecamp에서 개발하고 Ryan Singer가 정리한 Shape Up 방법론에서 비롯되었습니다. 완벽한 시스템은 아니며 모든 팀에 맞는 것도 아니지만, 복잡한 소프트웨어 작업이 실제로 어떻게 이루어지는지에 대한 보다 솔직한 가정에서 시작하고, 스프린트 방법론보다 시간, 범위, 품질 사이의 관계를 더 현실적으로 모델링합니다.

검토해야 할 기본 가정

가장 신중히 검토할 가치가 있는 가정은 엔지니어링 작업이 근본적으로 생산 프로세스라는 생각입니다—즉, 정의된 요구사항의 백로그를 받아 가능한 한 효율적으로 처리해 배포된 소프트웨어로 만드는 것이 작업이라는 생각입니다.

• 그 모델에도 쓰임새와 적용 상황이 있습니다.

• 그러나 대부분의 엔지니어링 조직에서 가장 중요한 작업 유형에는 부합하지 않습니다:

  • 무엇을 만들어야 할지 올바르게 파악하기,
  • 명확한 해답이 없는 문제 해결하기,
  • 단순히 완성되는 것이 아니라 시간이 지나면서 진화해야 하는 시스템 구축하기.

스프린트는 이전 방식보다 크게 개선된 방법이었습니다. 중요한 질문은 스프린트가 그 당시 좋은 아이디어였는가가 아니라—그렇습니다—현재 대부분의 팀이 수행하는 작업에 여전히 적합한 도구인가 하는 것입니다. 점점 더 많은 팀에게 솔직한 답은 아니오입니다.

앞으로 나아가기

그것을 인식하는 것이 첫 번째 단계입니다. 더 나은 모델을 구축하는 것이 작업입니다.

시리즈 다음 편: Shape Up – 복잡한 소프트웨어 작업이 실제로 수행되는 방식에 대한 보다 솔직한 가정에서 시작하는 계획 방법론에 대한 실용적인 소개.