스크럼은 쓰레기였다 (적어도 나에겐)

애자일 개발 방법론이라는게 있습니다. "애자일(Agile=기민한, 좋은것을 빠르고 낭비없게 만드는 것)"이라는 말 그대로 만들고자 하는 제품을 빠른 속도내에 출시하고 계속해서 발전시키는 형태의 개발 방법론으로 많은 스타트업에서 적용하고 있고 있지요. 저또한 과거일했던 스타트업에서 이 방법론중에 대표격인 "스크럼"이라는 방법론을 선택하고 운용해본적이 있습니다. 우선 결론부터 말하고 시작할게요. 스크럼은 쓰레기였다고요.

어느날 CTO가 스크럼이란 개발 방법론을 들고 함께 해보자고 제안했습니다. 이론적으로 듣기엔 스크럼이란 방법론은 스피디하게 업무를 처리하고, 돌발상황도 빠르게 대처한다고 들었습니다. 모두가 흔쾌히 "알았어. 그럼 배워보고, 적용해보자"라고 했고, 시간과 돈을 들여가며 공부에 열중이었지요. 그리고 실제로 업무에 적용도 해보았습니다. 그런데 그런 이론과는 전혀 다르게 업무가 매우 느려졌고, "비효율적으로 움직였으며, 돌발상황(버그)에도 대처하지 못했습니다. 왜 그랬을까요? 책대로 적용해봤는데, 왜 책에서 나오는 이론과 달랐을까요. 제가 이해도가 낮았던 탓일까요. 후후.

우리는 1스프린트를 2주로 잡았습니다. 제품 백로그를 토대로 스프린트 계획, 스프린트 백로그 등등에 시간을 할애했습니다. 이게 하루 내내 소요됩니다. 다른 업무는 할 수 없습니다. 그게 룰이라고. 일단, 개발팀 인원 5명이라고 하면 5명X8시간 = 40시간이 그냥 날아가는겁니다. (잔업시간을 제외하고) 그럼에도 초반엔 익숙해지기 위한 시간이라고 생각하고, 점점더 나아질꺼라고 믿으며 진행했었고, 데일리 미팅(15분)을 매일매일 넣었고, 2주중에 마지막 2일은 레트로 스펙티브(회고)의 시간과 스프린트 리뷰 및 다시 그 다음의 스프린트를 위한 스프린트 계획을 짜게 됩니다. 

스크럼 방법론의 프로세스

일단 여기서 돌발상황은 바로바로 적용 불가능하다는 사실을 발견했습니다. 당장 처리해야 하는 업무임에도 불구하고 초반 스프린트 계획에 포함되지 않았던 업무이기 때문에 돌발상황을 처리하게 된다면 스프린트 계획의 신뢰도가 떨어지고 언제나 업무가 초과되는 상황이 발생됩니다. 게다가 실제 기능의 릴리즈를 목적으로한 스프린트 계획이었기 때문에 (업무초과로 인한) 스프린트 종료시점에 제품이 릴리즈되지 못하는 상황이 발생되기도 했습니다. 세상에나.

게다가 스크럼은 단어 그대로 모두가 힘을 합쳐 제품을 만드는 것에 집중하고, 맴버 누구에게도 업무량을 달성치 않았던 부분에 대한 책임을 묻지 않았습니다. 왜냐면 모두가 힘을 합치지 못한 결과라고 생각했고, 조금더 서로가 신경쓰지 못했다는 것이 되었으니까요. 저는 이게 가장 이해할 수 없었던 부분입니다. 시간낭비. 생산성 저하. 효율적이지 않은 문제점들이 보이기 시작했지요. 그럼에도 우리는 계속해서 스크럼을 이어갔습니다. 왜냐. CTO가 고집하니까요. 으하하하하하. 그는 아주 학구열이 높았던 "학자형" CTO였던 것 같습니다. 또 어느날은 User Story Mapping이라는 방법론을 가져와서 이거 이해못하는 사람하고는 함께 일하기 싫다고까지 했어요. (그거 배우는데 2주걸렸음, 업무진행못함)

어쩌겠어요. 같은 맴버이고 이 회사 창업맴버인데. 그리고 개발 핵심인력인데. 그 CTO가 없으면 제품이 만들어질 수 없는 상황임을 알고 있었기 때문에 우리는 그가 원하는 업무 방식을 그대로 따라주었습니다. 저는 뭘 했냐고요? 갈수록 지쳐가면서도 CTO의 무의미한 업무진행방식에 대해 비판했습니다. 제 지론은 각자 업무량은 본인 스스로가 가장 잘 알고있어야 하고, 대략적인 스케쥴에 따라 업무를 진행하되 진행상황은 실시간으로 공유(클라우드를 이용하는 등)하는 것이 매우 용이하다고 생각했기 때문입니다. 데일리 미팅에 쏟는 시간조차 아깝죠. 대기업 1달이 스타트업에겐 1주와도 같으니까요. 

또한 갈수록 제가 느끼는 것은 "스크럼"은 시니어 개발자를 위한 방법론이 아님을 느꼈습니다. 시니어를 1이라고 하고 주니어를 0.5라고 했을때 결론적으로 그 팀의 능력치가 1.5가 되는게 아니라 0.5로 다운그레이드 되는 느낌이었습니다. 제 지론은 각자 처리할 수 있는 업무량과 스피드가 존재하고, 인간이기 때문에 스퍼트가 나오는 구간이 다르다고 생각합니다. 하지만 이 방법론은 모두가 같은 스피드로 움직여야 하는 느낌을 받았습니다. 저는 디자인 담당이었기 때문에 일주일만에 사이트 디자인을 다 쳐내도, 개발쪽에서 한달이 걸리는 경우도 있었고, 그 한달 걸리는 동안 기능변화나 익스큐즈 발생으로 인해 디자인을 다시 고쳐야 하는 일이 빈번했기 때문에 개발팀이 처리할 수 있는 업무량에 한하여 디자인을 진행하는 수밖에 없었습니다. 미친짓이었죠. 당시엔 리소스의 한계로 생각했었습니다만, 지금은 "스크럼 자체의 문제점"으로 인식하고 있습니다. 

즉. 회사가 가고자 하는 길, 존재의 목적이 분명했음에도 이 쓰레기 같은 스크럼 때문에 비싼시간을 많이도 버려야했습니다. 지금도 많은 스타트업들, 그리고 일부 스타트업 흉내를 내는 대기업들의 일부 부서에서는 아직도 스크럼을 많이들 도입하고 있어서 솔직히 이런 비판적인 글은 적고 싶지 않았습니다. 그리고 지금 제가 가지고 있었던 문제점을 훌륭하게 소화해서 안정적으로 스크럼이 정착한 회사들도 있을거에요. 그분들에게 비난하고 싶은 마음은 없습니다. 그냥 이건 순수하게 느낀 제 경험상의 이야기 일 뿐이지요.

결국 제 경험상에서는 스크럼을 도입하면서 회사의 움직임이 느려졌고, 그만큼 직원 월급과 리소스의 한계점은 보이는데 우리는 계속해서 스크럼을 유지했습니다. 스크럼을 그만둘 수 없었던 것도 CTO덕분이긴 한데, 어쨌든 결과적으로 디자인 총 책임자였던 제가 조인한지 7-8개월만에 자금부족으로 퇴직할 수 밖에 없었습니다. 실리콘밸리에서도 월급 한두달 밀리는 스타트업이 흔하다고들 하는데요. 저는 월급이 밀리면 않되는 한 가족의 "가장"이고, 그들을 안정적으로 책임져야 하는 의무가 있기 때문에 더이상의 모험은 진행할 수 없었습니다. 지금은 일본 대기업의 그룹산하 신생 계열사에 조인하여 이제 막 업무파악을 하는 중입니다만, 이번 경험을 통해서 느낀건 "자금 앞에 장사 없다"였고, 기왕 모험하는거 "자금"이 확실히 확보된 회사에서 "모험"을 하는 것이 제 미래와 가족들을 위해서라도 타당하다 결론내렸습니다. 아 물론 이 회사도 실적 좋지 않으면 그룹차원에서 처분할 수 있겠죠. (아주 먼 미래의 이야기)

개발 방법론은 다양하고, 그 누구도 스크럼이 완벽하다 말하는 사람은 없습니다. 즉, 해당 기업이 생리적으로 개발 프로세스가 맞지 않는다고 생각된다면 해당 개발 방법론은 그냥 쓰레기이고 다른 개발 프로세스를 찾아서 적용하고 안정화를 시켜야 한다는 말이지요. 지금이라도 저와 같은 상황에 있거나, 정말 스크럼을 진지하게 도입검토하는 팀이 있다면 심사숙고 해보시길 바랍니다. 그리고 아무튼 꼭 살아남으시고, 꼭 성공하시길 바랍니다. 진심으로요.

애자일 개발 방법론에 대한 개인적인 생각 끝.