애자일 프로젝트 관람기
기획자에게 가혹한 애자일
이제는 오래된 개념이지만 애자일 방법론에 대한 IT업계의 짝사랑은 식지가 않는다. 서비스 운영이 길어질수록 기억도 안나는 주석처리된 소스조차 지워도 되는지 겁이 나는 상황이 반복된다면 '스파게티 소스'란 단어를 한번쯤 들어봤을 것이다.
웹의 역사가 20년쯤 되면서 몇번의 리뉴얼과 재구축을 겪었지만 그때마다 뼈아픈 오류를 겪어야했고 2010년도에 만들어진 프레임에 계속 새로운 소스를 얹어가는 일은 어불성설이다. 한숨만 나올 뿐.
그런 곪아터진 이야기가 나올때마다 나오는 애자일방법론에 대한 이야기는 굉장히 매력적으로 다가온다.
여럿이 동등하게 힘을 합쳐 진행하는 짝프로그램이라든가 스크럼 단위로 작업을 진행해서 스프린트가 끝날때 프로토타입을 만들어낸다든가 하는 이야기는 정말 매력적이다. 게다가 포스트잇이니 그래프니 얼마나 외국 프로젝트같은 비주얼까지 멋진지. 마음이 괜히 '진짜 IT인'이 된 거같은 생각도 든다.
그리고 어른들은 어디서 애자일 방법론을 도입하면 '빠르다'라는 이야기만 듣고 오신다. 대부분 결정적인 도입 계기는 선두를 빼앗긴 뼈아픈 경험들인 경우가 많다.
하지만 우리의 애자일은?
그러나 국내에서 도입했단 이야기는 들려도 엄청 큰 성과를 보이며 잘해냈다는 이야기는 잘 들리지 않는다. 우리나라 조직에서는 아직 무리인걸까? 일부 소규모 스타트업에서나 한다는 이야기가 들릴 뿐. 그나마도 개발에 관한 이야기였다.
기획자로 살아오면서 야심차게 도입한 애자일에서 기획자가 버둥대는 상황을 몇차례 관람했다. 게다가 한번은 놀랍게도 크게 망하는 것을 직접 봐야만 했다. 잠시 그 때의 기억을 되새기며 문제점을 되새겨보려고 한다.
프로젝트 목표는 멀쩡했다
우리의 RFP에 따라서 애자일 전문가를 포함한 기획, 개발, 디자인이 모두 포함된 에이전시 프로젝트그룹이 사내에 들어왔다.
그들은 애자일을 이야기했고 경험이 없던 우리는 모두 설레였다.
이미 RFP를 작성하면서 인하우스 기획자들은 요구사항을 작성해서 전달이 되었고 내용리뷰를 진행했다. 그들은 스크럼 마스터를 중심으로 '데일리 15분 미팅'을 진행했고 일단 앞의 2주를 첫번째 스프린트 기간으로 산정했다.
애자일이 궁금했던 우리는 데일리 미팅에 참석하고자 했지만 스크럼 마스터는 '갑'회사의 멤버들이 들어오면 부담스러우니 회의의 참석하지 말라고 했다. 우리는 2주간 외주기획자가 물어볼 때만 대답이나 해주면서 어서 스프린트가 끝나기를 기다렸다.
물론 마음 한구석에는 왜 질문도 하나 없나 의문스럽긴했다.
스프린트가 미니 폭포수?
그리고 2주가 지난 뒤 첫번째 스프린트를 통해서 얻은 메인화면 프로토타입을 받았다.
'헐!'
껍데기는 분명 있었다. 하지만 정상적인 작동이 어려운 화면이었다. 이게 뭐냐고했더니 프로토타입이라 그럴수 있다는 말이 돌아왔다. 모바일 전면 프로젝트기간에서 2주나 사용했는데 메인도 백오피스없이 껍데기만 있다니 우리는 당황했다. 게다가 퀄리티도 마음에 들지 않았다. 당연히 사업부도 아닌 인하우스 기획자와 상의조차 하지 않았으니 내부의 분위기와 기조가 반영될리 만무했다.
기능은 더 한심했는데 겉보기에는 멀쩡했지만 정책으로 명시된 보이지 않는 기능들은 아예 제외되어있었다. 왜 이러냐고 물어보니 SB에 없었단다.
스프린트에서 적용한 SB를 검수했다. 내용이 껍데기에만 해당했고 기존 소스에 스파게티처럼 들어간 기획내용들은 당연히 없었다. 외주 기획자도 딱히 묻지도 않았고 개발도 기존소스 분석을 할 시간없이 바로 스프린트에 도입했기 때문이었다.
진짜 애자일방법론에서는 요구사항을 기반으로 '백로그'가 탄탄히 준비되어 있어야한다. UI는 스프린트에서 나오지만 모든 정책은 백로그에 이미 적혀 있어야한다. 그리고 이 과정은 Product Owner라고 불리는 일종의 기획책임자(기획자이자 정책 결정권이 있는 사람)가 작성한다.
제대로 된 백로그 작성을 하려면 구현필요한 기능 내용도 모두 알아야하고 이런 리뉴얼 프로젝트라면 기존 정책과 예외처리 사항까지 모두 알았어야 했다. 다른 말로 하면 일종의 기획은 첫번째 스프린트가 나오기 전에 전체적인 윤곽이 다 나와있어야 한다. 그래야만 스프린트 단위도 나누고 스크럼도 결정할 수 있다.
하지만 폭포수 방식에 익숙한 갑회사가 요구한 기간은 애자일의 전제조건에 적합하지 않았다. 그리고 애자일 경험이 있다는 을 회사도 그렇다는 사실 굳이 이야기하지 않았다.
결과는 '스프린트별 쪽SB'가 등장해 버렸다. 드라마도 쪽대본이 나오면 아침 일일드라마처럼 배우들이 항상 차렷자세로 어정쩡하듯이 프로젝트도 그런 느낌이었다. 애자일을 해달라고 했는데 스프린트 단위의 미니 폭포수가 되어버렸다. 영향도와 케이스에 대한 깊은 이해는 시간이 부족했고 스프린트 단위로 산출물이 따로 놀고 완성도도 낮아질 수밖에 없었다.
결국 프로젝트 중도에 폭포수 방법론으로 전향할 수밖에 없었다.
커피 타는 거 빼고 다하는 기획자
또 다른 사례는 더 빡셌다.
백로그의 작성부터 정책까지 빠듯하게 정의해놓는 것까지는 역할대로 진행하는데 너무 많은 것을 요구받는 경우도 있었다.
원래 폭포수 방법론에서 개발인력의 관리는 온전히 개발 PL의 역할이었다. 상하 계층이 있고 기획자와 개발자의 구분이 명백했기 때문이다. 하지만 애자일 방법론의 사상에서는 개발자도 디자이너도 UX와 비즈니스에 대해 명확히 이해하는 독립적인 존재가 된다. 스크럼마스터라는 직책이 있지만 어디까지나 '퍼실리에이터'의 개념일 뿐 기존 개념의 일정관리자는 아니다.
그 프로젝트에서는 PO(Product owner)에게 개발자의 관리역할까지 돌아왔다. 감정을 관리하고 개발자의 의욕을 돋우는 심리적 역할, 즉 애자일 컨설턴트의 역할까지 해야했다.
'애자일의 신'이라는 책에서 애자일은 방법론이 아니라 기본적으로 협업 사상이라고 강조한다. 모두가 동일한 사상적 배경이 이루어지지 않는다면 애자일이 효과를 보이기 어렵다. 특히 프로젝트 참여자 모두가 뼈속 깊이 폭포수방법론이 익숙하고 정해준 일을 하는 것에 스스로 생각하고 제안하며 일하는 것보다 더 익숙하다면 애자일을 시작하긴 어렵다.
꾸역꾸역 방법론만 도입한다면 누군가는 일을 덩어리로 책임질 수밖에 없어지니까. 게다가 SB대신에 스케치로 디자인과 UI설계의 역할까지 통합해서 하라고 한다면 기획자는 너무나 힘들어진다. 그리고 잘해내긴 더 어려워진다.
기획자를 위한 애자일은 없다
짝프로그래밍이나 스프린트 방법론은 원래 개발자를 위한 방법론이다. 전문가처럼 적극적이고 UX와 비지니스까지 모두 이해한 의욕적인 개발자들의 이상적인 프로세스다. 비주얼 디자이너까지는 같이 섞일 수 있어도 기획자 단독으로 할 수 있는 일이 아니다.
기획자는 PO가 되는 순간부터 스프린트 밖의 사람이 되어야한다. 필요할 때만 정확히 결정하고 책임져줄 수 있는 사람이 되어야 맞다.
하지만 우리나라의 프로젝트는 아직 PO라는 이름만 주고 기획자의 역할을 요구하거나 그 이상을 요구하고 결정권한도 주지 않는다.
LeanUX도 애자일한 사상이지만 이것이 꼭 폭포수를 써서는 안된다는 조건은 없다. 그건 빨리 내고 빨리 개선하고 판단하는 출시에 관련된 사상일뿐이다. 기획자가 하는 일이 UX만을 의미하지는 않기 때문이다.
결국 애자일이든 폭포수든 기획자는 기획을 해놔야한다. 전체적인 목표와 윤곽과 서비스에 대한 정책과 같은 비지니스를 기획해야한다. 그리고 가급적이면 기능과 로직, UX사상도 포함되어야한다.
그런 것들이 잘 정리되어 있을 때 UI와 개발소스가 정말 애자일하게 혁신적으로 진행이 가능할 것이다.
그러니까 부디 어설픈 목표와 두루뭉수리한 요구사항으로 애자일을 요구하지 말자. 애자일은 마법의 주문도 아니고 준비와 각오가 충분히 되어있어야 하는 사상이다
이미 대한민국 애자일 개발 역사에 이런 뼈아픈 경험들은 얼마든지 찾아볼 수 있다. 그리고 부디 꼭 의사결정자들은 알아줬으면 좋겠다,
제대로 만들려면 개발방법론에 관계없이 기획자든 PO든
충분히 기획을 고민할 시간을 주어야 한다!
