안녕한 스프린트를 위하여: 실무 경험과 개선 사례

들어가며.

다양한 회사와 많은 팀들이 개발 방법론 중 하나로 스프린트 개발 방법론을 사용합니다. 대부분의 기술 블로그에서 스프린트 개발 방법론의 장점에 대해 소개를 하고 있는데요, 일반적인 스프린트 장점 소개에서 벗어나 실제 경험을 중심으로 이야기해 보려 합니다.

 

 

스프린트를 경험하다.

도입 배경

팀에서 제로 투 원으로 MVP부터 beta 서비스를 개발하는 데에 스프린트 방법론을 사용하였습니다. Mvp를 빠르게 출시하여 고객의 반응을 확인하고 개선하기 위해 스프린트 방법론을 도입하였는데요, 이 방법론에 대해 잘 모르는 분들이 있을 수 있어 간단히 알아보고 넘어가겠습니다.

 

스프린트란 무엇?

스프린트는 애자일 개발 방법론에서 사용되는 용어로, 짧은 주기 (1주~4주)로 프로젝트를 나누어 집중적으로 작업하는 방식입니다. 단기간에 가치있는 제품을 출시하고, 지속적인 개선과 피드백을 받는 방식입니다.

 

스프린트의 주요 단계는 다음과 같습니다.

1. 계획 : 플래닝, 와이어프레이밍
2. 개발 : 제품 개발 및 QA
3. 검토 및 피드백 : 개발된 내용 리뷰 (시연) 및 피드백
4. 회고 : 스프린트 회고 및 개선 방안 마련

 

스프린트 기간 동안에는 데일리 스크럼을 활용하여 매일 작업 현황과 어려움, 이슈 등을 공유합니다.

 

직접 경험한 스프린트는..

스프린트에 대해 일련의 경험이 있었지만, 제로 투 원을 전부 스프린트로 해본 적은 처음이었습니다. 회사에서 적용했던 스프린트의 프로세스를 소개해보자면..,

 

1. pm, 디자이너 등이 모여 스프린트에 대한 기획을 합니다.

2. 제로 투 원이었기에, 일정 mvp가 되기 까지의 필요한 기능들을 큰 틀에서 먼저 구상합니다.

3. 전반적으로 기획이 정해지면, 스프린트를 몇 단계로 나누어 개발할 지 정합니다.

4. 정해진 배포 예정 날짜에 맞추기 위해 스프린트를 다음과 같이 나누었습니다. 1차: MVP 플래닝 – 핵심 기능 정립, 2차: 기본 기능 구현, 3차~5차: 세부 기능 추가

 

위 스프린트 과정에서 마주한 문제점들과 해결했던 방법을 소개해보겠습니다.

 

1. 개발 공수 산정의 어려움

• 문제: 새로운 기술 (외부 라이브러리) 도입 시 공수 산정이 어려워 예상보다 시간이 오래 걸리는 경우가 많았습니다.
• 해결: 플래닝 전 테크 스펙을 미리 작성하여 세부적으로 개발 공수를 산정하고, 기간 내 불가능한 경우 범위를 줄이는 방식으로 조정했습니다.

 

2. 구현에 집중한 코드, 충분치 못한 설계

• 문제: 짧은 기간 내 요구사항을 맞추기 위해 코드 구현에만 집중하게 되어 충분한 설계를 놓치게 되었습니다.
• 해결: 테크 스펙 단계에서 설계를 추가로 검토하고, PR 리뷰 시에도 설계에 대한 검토를 강화해 시간을 확보하고 코드 품질을 개선했습니다.

 

3. 기술적 한계 혹은 시간 부족으로 인한 요구사항 변경

• 문제: 개발 중간에 요구사항 변경이 발생하거나, 기술적 한계로 요구사항을 만족시키기 어려운 경우가 있었습니다.
• 해결: 미리 테크 스펙과 기술 리서치를 통해 변경 가능성을 평가하고, 플래닝 단계에서 필요 시 기능 축소 또는 변경을 반영하여 작업 시간을 확보했습니다.

 

 

스프린트의 장단점과 내가 느낀 장단점.

스프린트 방법론을 검색하면 나오는, 일반적으로 이야기 하는 장단점은 다음과 같습니다.

 

장점

• 유연성과 적응성이 높음 - 짧은 주기로 개발하여 요구사항 변화에 빠르게 대응
• 고객 만족도 향상 - 지속적인 피드백과 반복 테스트로 제품 품질 개선
• 팀 협업 강화 - 데일리 스크럼 등 정기적인 미팅으로 의사소통 활성화
• 빠른 제품 출시 - 스프린트마다 실행 가능한 결과물 도출
• 투명성 제고 - 스프린트 리뷰 등을 통해 이해관계자들에게 진행상황 공유
• 생산성 향상 - 짧은 주기의 집중 개발로 효율성 증대

단점

• 범위 확대(scope creep) 위험 - 지속적인 변경으로 인한 범위 증가 가능성
• 문서화 부족 - 실행 가능한 소프트웨어에 집중하여 상세 문서 작성 미흡
• 대규모 팀/프로젝트 적용 어려움 - 소규모 팀에 적합한 방식
• 경험 많은 팀원 필요 - 자기 주도적 업무 수행 능력 요구
• 지속적인 참여 필요 - 모든 팀원의 적극적 참여가 필수적
• 예측 불가능성 - 정확한 일정과 비용 산정의 어려움

 

아래는 실제로 경험하면서 느꼈던 장단점입니다.

사실 더 많지만.. 중요하다고 생각했던 부분을 3가지씩 뽑아보았습니다.

 

장점

1. 빠른 배포 주기

스프린트의 핵심이라고 생각하는 부분입니다. 일단 배포 가능한 작은 범위로 나누기 때문에, 배포에 대한 부담이 적습니다. 또한, 충분히 팀 전원이 우선 순위가 낮은 작업을 미루고, 스프린트 목표에만 집중하므로 결과물이 보다 빠르게 나올 수 있습니다. 작은 단위로 배포하면서 성취감을 자주 느낄 수 있는 것도 장점입니다.

 

2. 잦은 커뮤니케이션과 팀 싱크업(sync-up)

데일리 스크럼을 통해 어제 한 일, 오늘 한 일 등을 공유하고 예상되는 문제점이나 겪고 있는 문제점을 충분히 공유합니다. 작업 현황이나 변경 사항 등을 모두가 파악하고 일을 진행하므로, 서로 오해를 하거나 싱크가 맞지 않는 문제를 줄일 수 있습니다.

 

3. 아주 유연함

변경 사항이 발생하면, 즉시 반영할 지 혹은 다음 스프린트에 반영할 지 정해볼 수 있습니다. 변경에 빠른 대응이 가능하기에 잘못 판단했던 부분이 있다면 빠르게 고쳐나갈 수 있습니다.

 

 

단점

1. 시간적 압박

짧은 기간 내에 결과물을 도출해야 하므로 팀원들에게 지속적인 스트레스가 쌓일 수 있습니다. 이를 잘 관리해주지 못한다면 일종의 번아웃이 발생할 수 있습니다. 실제로 회고 때 Exhausted라는 표현이 나올 정도였므로, 스프린트를 하다 보면 스프린트 사이클을 잠시 멈추는 쿨다운 기간은 반드시 필요합니다.

 

2. 커뮤니케이션 과부하

너무 잦은 회의 혹은 많은 회의로 인해 실제 작업 시간이 줄어들어 생산성이 저하될 수 있습니다. 작업시간이 줄어들면 결국 시간적 압박을 느끼게 되고, 개발적으로는 PR 리뷰를 대충 하고 넘어간다거나, QA가 꼼꼼히 진행되지 않고 마무리되어 핫픽스를 하게 되는 경우가 발생할 수 있습니다.

 

3. 너무 유연함

갑작스러운 변경은 필연적으로 스트레스를 유발합니다. 단순하고 작은 변경은 큰 문제가 없지만, 가끔은 꽤 큰 범위의, 설계를 다시 해야하는 수준의 변경도 생깁니다. 개발 일정 도중에 변경사항이 발생하지만, 만약 배포일을 크게 미룰 수 없이 정해진 일자에 반드시 완료해야 한다면..? 변경된 내용을 스프린트 내에 달성하려다 품질 저하로 이어질 수 있습니다.

 

 

앞으로의 스프린트는.

스프린트 방법론은 빠른 피드백 루프와 기능 배포에 큰 장점이 있었지만, 여전히 해결할 과제가 남아 있습니다. 팀원 모두가 각 단계와 역할에 충실해야만 하며, 적절한 스프린트 범위를 선정해야 합니다. 속도에 집착하여 너무 많은 것들을 단기간 내에 수행하려 한다면, 오히려 중요한 것들을 놓칠 수 있게 되므로 주의가 필요한 것 같습니다.

속도가 전부가 아니다.jpg

 

스프린트는 팀과 개인에 맞추어 유연하게 조정해야 효과적이며, 우리의 스프린트 방식을 찾는 과정에서 배운 점들이 많았습니다. 물론 아직도 스프린트를 잘 하는데에 어려움이 있고, 발생하는 문제들을 더 좋은 방향으로 해결해나가려 노력하고 있습니다.

 

이 글을 통해 스프린트 방법론의 실질적 경험이 도움이 되었기를 바라며, 필요에 따라 유연하게 적용할 수 있는 인사이트가 되었으면 좋겠습니다.

 

 

출처

https://www.atlassian.com/ko/agile/scrum/sprints

https://asana.com/ko/resources/what-is-scrum