한국 기업들의 Scrum 활용 역사, 현황과 향후 개선방향

2년 전 2023년 Scrum 주제의 컨퍼런스에서 기조강연을 할 때 약 200명이 참석했는데, "회사에서 SW제품 업그레이드를 한달 이내 주기로 꼬박 꼬박 출시하는 분은 손을 들어 보세요" 했더니 딱 한 분이 손을 들었다.

미국에서는 2000년대 초부터 스크럼이 애자일 개발 프로세스로 가장 많이 쓰이기 시작했다. 한국에서는 본 블로그의 저자가 2000년대 중반 삼성SDS CTO로 근무할 때 스크럼을 컨설팅할 직원을 키우기 시작했는데, 국내 일부 대기업들이 스크럼 도입을 추진하기 시작한 건 2010년대 중반쯤이었던 것 같다. 그러니 거의 10년 동안의 노력에도 불구하고 스크럼이 제대로 자리를 잡은 기업이 거의 없는 것이 국내 현실이다. 앞서 언급한 컨퍼런스에서 그렇게 된 근본 원인을 설명하고 향후 개선 방안을 제시하고자 했었다. (아래 링크로 가면 강연 녹화를 볼 수 있다:

https://www.facebook.com/share/v/19jH2cuQ7j/)

오늘 다시 스크럼에 관한 글을 올리는 이유는, 이제는 미국의 선진 SW기업들--Microsoft, Google, Facebook, Amazon, Netflix, Spotify, LinkedIn, Basecamp, Intel 등--은 스크럼을 안쓰고 다른 애자일 개발 프로세스를 쓰기 시작했다는 사실과 그들이 왜 스크럼을 버리게 됐는 지, 또 새로 추구하는 프로세스는 어떤 건지에 대해 공유하고자 함이다.

첫째, 스크럼의 2~4주 정기 스프린트와 스프린트 리뷰 행사는 오늘날 클라우드 네이티브 개발에서 추구하는 지속적 배포(Continuous Delivery: CD)와 안 맞는다. 아마존 경우 마이크로 서비스의 독립적 배포를 통해 릴리즈 사이클을 10초 정도로 단축했고, 대부분 실리콘밸리 SaaS기업들도 하루에 수십번 릴리즈하는데, 무슨 수로 릴리즈마다 스프린트 계획을 세우고 릴리즈 전에 스프린트 리뷰 회의를 열겠는가?

둘째, 스프린트 계획 시 수행하는 플래닝 포커에서 추정하는 스토리 포인트의 부정확성과 계획된 유저스토리들을 스프린트 기한 내에 완수하려는 무리한 노력에서 발생하는 기술부채의 축적이 문제시되기 시작했다. 이 보다는 Kanban 방식을 적용하여, 개발 일정 계획의 수립 없이, 유저스토리들을 균일하고 작은 규모로 자르고, 동시에 개발 중인 유저스토리의 수를 제한하여 개발의 Flow를 최적화하는 프로세스로 전환하였다. 또한 Kent Beck이 Extreme Programming(XP)에서 제시한 테스트 주도 개발, 리팩토링, 지속적 통합(Continuous Integration:: CI)의 철저한 수행을 통해 시간이 좀 걸리더라도 Sustainable SW를 개발하는 바람직한 애자일 개발 방법의 고수가 중요함을 되새기고 있다.

세째, 스크럼은 프로덕트 백로그를 만들어 제공하는 프로덕트 오우너에게 개발 요구명세를 일임함으로써 막상 SW를 창출하는 개발자들의 창의성을 살리지 못했다. 개발자들이 직접 고객과 대화를 하면서 SW제품을 기획하고 기술적 창의성을 맘껏 발휘하는 OKR(Objectives and Key Results) 방식의 팀 운영이 관심을 끌고 있다.

네째, 스크럼의 경직된 프로세스와 강요된 행사(스프린트 계획 회의, 매일 아침 스탠드업 회의, 스프린트 리뷰 회의, 스프린트 리트로스펙트 회의 등)와 같은 형식에 얽매이지 말고, 분석, 객체설계, 코딩, 테스트 자동화, CI/CD, 운영/모니터링 등 다방면에 뛰어난 공학 능럭을 가진 개발자들의 자율적인 문화를 창달하는 게 개발 생산성, 품질에 더 효과적이라는 걸 알았다. 이는 Lean 개발 방식에서 중요시하는 낭비(Waste)의 제거에도 부합한다. 큰 성과 없이 반복되는 형식적인 회의 시간, 고객 피드백의 딜레이로 발생하는 버려야 할 피쳐의 개발, 릴리즈 때까지 기다려야 하는 개발 백로그에 관한 의사결정 등이 적지 않은 낭비를 발생시키고 있다는 것이다.

다섯째, 이미 Lean StartUp을 창시한 Eric Ries가 지적했듯이, 스크럼의 스프린트 리뷰 회의를 통과했다고 해서 릴리즈하는 제품 업그레이드가 시장에서 고객에게 환대받는 건 아니다. 린 스타트업에서 제시하는 MVP(Minimum Viable Product)를 A/B 테스팅 방식으로 시장에 던지고, 시장의 반응을 모니터링하면서 Innovation Accounting에서 제시한 메트릭으로 측정하여 분석하고, 그 결과에 따라 Pivot or Persevere의 제품 개발 방향을 설정하는, DevOps와 같은 보다 시장 반응적 프로세스가 쓰이게 됐다.

이제 우리나라의 SW개발 조직들도 스크럼을 맹목적으로 따라하지 마시고, 팀 구성원들이 Extreme Programming(XP), DevOps, 마이크로서비스 아키텍처, 클라우드 네이티브 개발, 칸반, OKR, Lean Development, 린 스타트업, 또 최근의 AI-Powered 개발 등 다양한 개발 프로세스와 방법을 자율적으로 선택하여 Hybrid하게 적용하면서 지속적으로 개선하여 토착화시켜 나아가길 바란다.