애자일의 시대는 끝나야 한다.
Source:
슬랭이 많아서 비속어가 좀 섞여있을 수 있습니다.
스타트업들이 운영적 효율성에 집중하면서, 20년이 넘는 기간동안 애자일 방법론은 테크 업계에서 꼭 지켜야하는 불문율처럼 여겨져왔다. 그렇게, 치명적인 단점을 가지고 있는 애자일 방법론은, 우리를 괴롭혀왔다.
1960년, TPS(Toyota Production System)의 등장
일본 토요타는 40년대부터 70년대동안 자동차 제조업체로서 경쟁 우위를 지키기 위해 TPS를 발전시켜왔다. TPS는 낭비(waste), 불일치(inconsistency), 부담(overburden)을 제거하여 제조 과정을 효율화시키는 데에 집중한다.
그 중에서도 '낭비의 제거'는 가장 중요하게 여겨져 집중적으로 문서에 서술되어있다. 8가지의 낭비 유형 중, 가장 치명적으로 여겨지는 낭비는 '초과 재고'다. 예를 들면, 안 팔린 상품, 남은 원자재, 가동되지 않는 기계들과 같이 말이다. 즉, '돈을 벌고 있지 않은 것'에 투자한 것들 말이다. 토요타의 해결책은 본질적으로 물류학적으로 전개된다.
"원자재를 '적시에' 생산 라인에 넘기고, 수요가 생기는 '적시에' 처리한다."
TPS와 함께 언급되는 짝꿍은 '토요타 방식(The Toyota Way)'이다. 이 방식은 지속적인 개선에 집중하고 있으며, 장기적인 관점을 가지고 두 가지 요소에 집중한다. '운영의 혁신'과 '실제 장소, 실제의 것'이다. '실제 장소, 실제의 것'은 "직접 가서 보고, 결정할 것"을 의미한다. 즉, 직위에 상관없이 모든 직원들과 이해관계자로부터 인사이트를 얻어 바텀업 방식으로 개선을 이끌어내는 것이다.
1970년, 린(Lean)의 등장
미국은 토요타 방식을 들여왔고, '적시에' 생산하는 방식은 미국 전역에 걸쳐 적용되기 시작했다.그리고 이걸 1988년 '린(Lean)'이라고 리브랜딩했다.
린과 TPS은 물리적인 제품을 생산하는 데 있어서 최고의 방식이다. 특히, 경쟁자가 꽤 있는 제품들이 있거나, 제품 자체가 거의 완성형이 되어 시장이 발달한 경우 말이다. 린의 방식은 수요와 공급이 예측 가능한지에 매우 크게 좌지우지된다. 이러한 특성들 때문에, 제조업자들이 새로운 상품을 만들 때 R&D 부서 내에 있는 다양한 절차들에 의존하는 경우가 많았다. 이로 인해 이 과정은 꽤 직선적으로 단계별로 진행된다. 예를 들어, 신제품 개발 전에 리서치와 시장 분석의 기간을 오랜 기간 가지는 것처럼 말이다.
워터폴(Waterfall), 희생양의 등장
소프트웨어 업계가 급성장하면서, 자연스럽게 제조업자들의 방법론을 따르게 됐다. 그리고 이 방식이 자연스럽게 '워터폴'로 칭하게 됐다. 워터폴 방식은 완성된 소프트웨어를 출시하기 위해 거치는 직선적인 단계의 여러가지 방식들을 칭하는 짬통(catch-all)이 되었다. 워터폴의 명확한 단점은 들이는 노력에 비해 결과물이 사업의 성공을 보장하지 못한다는 점이다. 그렇게 워터폴은 '빠른 반복을 통해 검증하지 못한다.'라는 이유로 찐따취급을 당한다.
1990년대로 접어들면서 실무자들은 린 방식을 디지털 제품에 적용시키려는 방법을 찾기 시작했다. 안타깝게도, 처음에 어떤 문제가 발생할지 예측하지 못한채로 말이다. '시장에 출시할 타이밍(Time to market)'은 중요하긴 하지만, 여기에 너무 치중하게 되면 현금적인 문제에 시달릴 가능성이 너무 크다. 특히 스타트업이라면 더더욱이나. 린을 옹호하는 제품의 부모님들은 갓 태어난 아기 제품들을 세상에 던져버리기 시작했다. 스크럼과 애자일 선언이 리서치나 전략에 대해 아무 언급을 하고 있지 않다는 것에 주목해야 한다. 디자인은 그렇게 무지성 제작과 출시 사이에서 갈려나가기 시작한다.
이 시기에 린 옹호자들과 워터폴 옹호자들 사이에서 한바탕 치열한 싸움이 있었다. 왜냐하면 둘다 유저 니즈를 찾는데에 폭망해서, 그저 남탓하며 멸망전에 돌입한 것이다.
시장에 출시된 제품을 반복적으로 검증하며 개발해나가는 것은 배가 부른 소리다. '린'이 의미가 있었던 제조업체들에서는 최소한 생산 라인과 도구가 한순간에 바뀌어야 하는 경우는 없었다. 하지만 소프트웨어 제품에서는 한번의 결정으로 모든 것을 다 헤집어 엎어야 하는 경우가 많다. 소프트웨어 제품도 제조업 상품들과 마찬가지로 특정 목표를 위해 완전한 상품으로 만들어져야 한다. 성공하기 위해서는 리서치, 디자인, '실제 장소, 실제의 것'들이 필요하다.
애자일이냐 워터폴이냐 싸우고 앉아있는 건 의미없는 이분법에 휘말려 드는 일이다. 사업은 장기적인 전략을 가지고 있는 동시에, 제품을 점진적이고 반복적인 방식으로 개선해나가면서 출시해야한다.
스크럼, 30년간 고쳐지지 않은 오류
PO와 엔지니어들이 소프트웨어 개발에 린 방식을 채택하다가, 제조 생산 라인의 방식을 적절하게 섞을 방법을 발견했다. 요구사항들이 '적시에' 정해진 후, 교차기능조직 팀이 스프린트를 뛰는 것이다. 이렇게 '스크럼'이 나왔다. 스크럼은 럭비팀이 공을 앞뒤로 왔다갔다 던지며 돌진하는 것을 일컬으며, 소프트웨어 개발 방식도 럭비처럼 난잡하게 진행됐다.
- 시장에 내놓을 특정 기간인 '스프린트'를 기반으로 반복한다.
- '스프린트 기획'은 가장 최신의 인사이트를 파악한다는 이유로 스프린트 '직전'에 진행된다.
- '데일리 스탠드업'으로 대충 진행 상황을 공유한다. (일반적으로 개발자들만 얘기하게 된다.)
- 스프린트가 끝나면 뭐가 됐고 뭐가 안 됐는지, 뭐가 개선이 필요한지를 파악하는 '리뷰'를 가진다.
- 산출물을 더 많이 만들어내기 위해, 어떻게 진행되었는지 '회고'를 진행하기도 한다.
- 그런 결과로, 스프린트에서 유기된 쓰레기들과 그 쓰레기들로 만들어진 인공물이 '백로그'다.
이렇게만 봐도 스크럼은 이미 앞뒤가 안 맞고 난장판이 될 거라는 게 보인다.
스크럼을 만들어낸 사람들은 린 방식을 만들어낸 사람들과 모여, 애자일 매니페스토(선언문)를 만들어냈다. 그 선언문은 공산주의 서적처럼 쓰여있었고, 굉장히 불순한 의도가 다분했다. 마치 실무자들이 자율적으로 제품에 대한 소유권을 가지고 만들어나갈 수 있다는 착각을 심는 것 말이다.
선언문에는 이렇게 쓰여져 있다.
- 절차나 수단보다는 개인과 상호작용을 중시한다
- 개발의 끝단계라도, 요구사항의 변화를 환영한다.
- 일이 끝날 때까지 믿고 기다려준다.
- 작동하는 개발물이 진보의 척도다.
- 단순함이 최고다.
- 최고의 아키텍처, 요구사항, 디자인은 스스로 조직된 팀으로부터 나온다.
그리고 실무에서 이렇게 적용된다.
- 절차나 수단보다는 개인과 상호작용을 중시한다 (= 응, 내 마음대로 할거야)
- 개발의 끝단계라도, 요구사항의 변화를 환영한다. (= 응, 내 마음대로 바꿀 수 있어)
- 일이 끝날 때까지 믿고 기다려준다. (= 니가 뭔데 방해임?)
- 작동하는 개발물이 진보의 척도다. (= 개발했으면 끝아님?)
- 단순함이 최고다. (= 응, 최대한 조금 일할거야)
- 최고의 아키텍처, 요구사항, 디자인은 스스로 조직된 팀으로부터 나온다. (= 다시 말하지만, 건드리지 마라)
이렇게 자연스럽게 '요구사항'은 '제안사항'이 되어버리고, '디자인'은 '해석이 가미된 무언가'가 되어버렸으며, 개발물은 작동만 하면 된다는 문화가 정착됐다. 애자일과 스크럼 방식만을 혼합한 스타트업의 업무는 재앙과도 같은 방식으로 진행된다.
그렇게, 애자일과 스크럼은 '낭비'를 줄이기보다 '낭비'만을 만들어내는 방식으로 거듭난다. 스트레스는 스트레스대로 받으며 번아웃이 오고, 기술 부채와 디자인 부채는 쌓여만 가고, 백로그는 미친듯이 늘어나며, 하드 코딩 로직이 온갖 곳에 자리잡고, 이런 것들의 최종 보스 '리팩토링'을 기다리게 된다.
그럼, 우린 어떡해야 하나?
스크럼을 멈추면 된다.
고객 중심의 제품은 스프린트에 억지로 쑤셔박는 건 불가능하다.
다음과 같은 방식을 거칠 필요가 있다.
1. 무엇을 만들어야 하는지에 대해 명확히 한다.
2. 미래의 확장성과 검증성을 위한 최선의 방법은 무엇인지 결정한다.
3. 위의 사항들이 결정되면, 적절한 시간을 배정하여 만들기 시작한다.
4. '산출물'이 아닌 '성과'에 대해 보상한다.
5. 개발적인 부채를 없앨 수 있는 것들(디자인 시스템, 아키텍쳐 등)에 투자한다.
6. UX에 투자하여 기능의 폭과 깊이에 대해 고민한다.
7. 인력을 쥐어짜는 건 운영 효율이 아니다.
이게 싫다면, 제품이 흥하길 기대하지 말아야 한다.
