지금까지 나온 개발방법론은 100개가 넘는다. 대부분 잠깐 동안의
유행으로 사라지고 남아 있는 것은 몇 개 없다. 개념적으로는 존재하지만 개발방법론이라고 하는 것은 실제로는
존재하지 않는다고 보는 것이 더 정확하다. 그러니 어떤 개발방법론을 사용할 것인가 하는 것을 의논하는 것은
이미 바람직한 상황이 아니다. 이전 기사에서 프로젝트관리시스템이 필요 없다고 하는 것과 비슷하다.
있으나 없으나 별로 변할 것도 없다. 돈과 시간만 낭비하기 딱 좋다.
잘나가는 회사는 특정한 방법론이라는 것을 따라 하지도 않거니와 상식적이고 합리적인 수준에서 잘 개발할 수 있다.
그런 것을 전문가의 특징인 암묵적 지식이라고 한다.
잘 되는 회사에서는 현재 개발관행을 바꿀
필요도 없지만 하여튼 뭔가 안되니까 방법론이라도 바꿔보자는 발상을 당연히 하게 된다. 혹은 개발자들의 호기심에서 시작하기도 한다. 혹은 경영진이 바뀌면
뭔가 해야 하니까 합리화하기 좋은 상용 아이템이기도 하다. 방법론 외에도 프로세스를 도입해 보자 혹은 조직을
바꿔보자 같은 것도 마찬가지이다. 메뉴만 변했지 몇 십 년이 지나도 전형적으로 반복되는 케케묵은 아이템들이다.
이렇게 쉽고 뻔히 눈에 보이는 방식으로 좋은 결과를 기대하는 것은 복권당첨을 바라는 것과 같다. 이런 식으로 쉽게 내가 잘 할 수 있다면 "개나 소"의 범주에 들어간다. 구글이나 애플이 방법론이나 프로세스를 잘 사용해서 성공한 것이 아니다.
선수들의 역량이 높아서 성공하는 것이다. 이런 주변 것들은 성공과는 인과관계가 없는
행위이다.
국내에서는 CMMI 같은 프로세스로 한때 비법인 양 소란을 떨었지만 지금쯤이면 대부분
돈과 시간만 낭비했다는 것을 깨달았을 것이다. 그 당시는 아무리 얘기해도 유행을 깨뜨리기는 불가능하다.
그래도 회사 홍보에 사용한 좁쌀만한 이익은 있었을지 모른다. 개발방법론은 오래된
이슈이고 지금 한국에서는 애자일 중에서도 수 많은 다른 애자일 방법론은 거들떠 보지도 않고 유독 “Scrum방법론”에 광신하고 있다. 시금치가 몸에 나쁜 것은 아니지만
특별히 좋을 것도 없다. 애자일을 사용하려는 사람들이면 일단 유튜브나 인터넷에서 “Agile
is dead” 라는 것을 검색해 보기 바란다. 항상 그렇듯이 성공사례도 없는 것은
아니다. 하지만 애자일 관련 장사꾼의 소리는 가짜 뉴스이니 배제하고 들어야 한다.
경영진이 결정했던, 혹은 개발자들이 주장했던 아직 살아 남은 애자일 Scrum
방식을 도입하기로 했다고 하자. 여기서부터 어떤 일이 벌어지는지가 이 기사의 주제이다.
처음에는 아주 아름답게 보인다. 전통적인 문제인 요구사항이 변하는 상황을 잘 대처하는
것이 중요하다는 정의로움을 내 세우며 시작한다. 똑 같은 소리가 이미 1960년도에 소프트웨어 업계의 가장 큰 걱정거리였다. 지금까지 계속되는 논쟁거리이기도 하다.
전혀 새로운 상황이 아니지만 하여튼 이제 마음 잡고 잘 개발해 보겠다고 하는 데 말리기 어렵다. 이제 고생 끝 행복 시작이라고 생각하기도 한다. 이런 인간의 단순한 무지와 집착에 대해서는
경험해 보기 전에는 어떤 충고도 먹히지 않는다.
이제 시작이다. 기존의 폭포수 방법론에서 요구되던 코딩 전의 문서를 작성하기도 싫은데 Scrum에서는 진행하면서 조율한다는 것이 너무 행복하다. 지금까지도 요구사항 문서를 제대로 적은 적이
없었지만 그것보다도 훨씬 더 적게 적어도 된다. 심지어는 무엇을 개발할 지 비전 정도만 있는 상태에서 코딩을
시작하는 용감무쌍한 경우도 있다. 사실 이 세상의 99.9%의 소프트웨어
회사는 어떤 형태이든 반복적인 방법론(Iteration)을 사용한다. 하여튼 마치 폭포수 모델을 아는 것처럼 얘기하지만 분석->설계->구현->테스트로 진행하는 것을 폭포수모델이라고 착각한다면 반대로 Scrum을 제외한 모든 방법론은 폭포수 모델일 것이다. “착하게 살라”는 실현 불가능한 교훈 한마디 듣고 세상 사는 법을 깨달은 것 같은 착각이다.
모든 것의 핵심은
내용의 충실도 이다. 하여튼 이런 엉터리 폭포수모델 조차도 하기 싫으니 더 자유로운 세상인 Scrum
놀이터에서 놀아보자는 설렘으로 시작한다. 이력서에 자랑스럽게 한 줄 추가할 수도
있다. 갑자기 내 역량이 높아진 것 같이 착각한다. 이런 경력이 취직에
도움이 된다는 국내 소프트웨어 업계가 한심스럽다. 필자 같으면 Jira라는 이슈관리시스템에서 Scrum View를 이용해 한 두 시간 놀아보면 이력서에 한 줄 적을
수 있다. 이게 무슨 의미가 있는지 모르겠지만 하여튼 국내 현실은 그렇다.
일단 Scrum을 시작은 했고 앞 단에서 미리 할 일이 적으니 코딩 시작은 빠르다.
어차피 계속되는 조율 작업이 있을 텐데 앞 단에서 시간을 많이 들일 필요가 없다고 생각한다. 그래도 시작하면 뭔가 구체적인 일 할 항목이 있어야 하는데 충실할 리가 없다. 우리는
Scrum이니 걱정할 것 없다. Scrum 방식답게 해야 할 일을
Daily 회의에서 구체화하든지 새로 만들든지 해서 일 할 이슈 항목을 만들어 낸다. 그리고 통상 2주마다 있는 스프린트 종료 시 구동되는 제품을 만들어 내야 하니 그에 필요한
항목을 정리한다. 그 외는 Backlog라는 창고에 쌓아둔다.
그런 상태에서 다음 날 모두 다시 만난다. 매일 만나야 되니 당연히 많은 개발자들이 필요한 대규모 개발의 경우에는
불가능하다. 이 Daily 회의에서 어제 무슨 일을 했고 오늘은 무슨
일을 할 것이고 계획에 변경이 있는지를 전광석화처럼 확인하고 15분 만에 회의를 끝낸다. 이런 통상 15분짜리 Daily 회의가 매일 진행된다.
그게 Scrum의 원칙이다. 이 회의는
Standup Meeting이라고 해서 서서 해야 한다는 웃기는 규칙도 있다.
그런데 행복할 줄 알았던 개발자의 입장에서
보면 매일 보고를 하면서 진행한다는 것이 지옥일 수 있다. 일용직 인부의 할당량을 검사하는 것이나 다름 없다. 그러니까 방식을 변경하기 시작한다.
매일 만나는 것은 의미가 없으니 일주일에 한번 만나자고 하면 일단 개발자는 모두가 찬성한다. 관리자는 관리가 어려워 지니 당연히 싫다. 하지만 모든 개발자들이 우겨대면 방법이 없다.
이렇게 Daily 회의가 Weekly 회의로
일단 변경된다. 그러면 또 규칙을 어긴 문제가 생기니 우리는 효율성을 위해 필요할 때마다 따로 만나서 조율한다고
그럴듯한 변명거리는 미리 만들어 놓는다.
이렇게 시간이 흘러 2주 만의 스프린트가 종료되면서 뭔가 구동할 수 있는 것이 나와야 한다.
그러면 고객 혹은 기획자 등 소위 Stakeholder라고 하는 사람에게
Demo를 시연해야 한다. 그게 스크럼의 가장 중요한 원칙이다. 그런데 계획한 대로 2주 마다 나오지 못하는 경우도 있고 Stakeholder가 시간을 낼 만큼 한가한 사람이 아닐 수도 있다. Stakeholder가 없으면 개발자들이
하고 싶은 대로 진행한다. 당연히 모든 것들이 개발자들이 편한 방식으로 진행한다. 진행하면 할 수록 귀찮은 존재가 되는 Stakeholder의 참견을 배제할 수 있도록 열심히
노력한다.
요구사항이 최초에도 대충 정해서 시작했는데
이렇게 되면 제품은 산으로 가기 시작한다. 이것을
Fake Agile이라고 한다. 보통 Scrum 팀의 규모를 2명에서 5명 정도가 적당하다고 하는데 그럼
6명은 안 되는 것인가? 그러니 또 9명까지는
괜찮다고 하는 사람도 있다. 이런 숫자 노름부터가 웃기는 규칙이다. 2명으로 한다면 Scrum 팀 수가 많아져 Stakeholder는 여기저기 뛰어 다니느라 시간이 없을 것이다. 팀을 9명으로 한다면 15분의 Daily회의도 어렵고 관리하기가
어려울 것이다. 이렇게 하든 저렇게 하든 우스꽝스러운 규칙들에서 문제가 생긴다.
국내 환경에서 통상 그렇듯이 Stakeholder가 그렇게 상세하게 검토할 시간이 없기 때문에 설렁설렁
끝까지 간다. 그래서 5번째가 되었던 10번째가 되었던 마지막 Sprint까지 그냥 간다. 어떤
경우는 Stakeholder가 한번도 보지 않을 수도 있다. 개발 중인
중간 제품을 시간을 내서 사용해 보고 싶어하는 Stakeholder는 거의 없다. 10번의 Sprint를 진행하면서 매번 중복된 것을 시연해 보고 검수한다는 것은 정말 지겨운 일이다.
마지막까지 가면 그 때는 심각한 상황이니 Stakeholder가 자세히 들여다 본다.
잘못된 지적과 새로운 요구사항들이 쏟아져 나온다. 폭탄이다. 국내 SI 사업이 진행하는 관행과 동일하다. 이전의 가짜
폭포수모델보다 더 열악한 상황으로 갈 수 있다. 시작은 대충하고 중간에 Stakeholder의 충실한 검수 과정도 없고 개발자들은 마지막에 폭탄이 터질 때까지는 편하게 삶을 즐길 수 있다.
그 때까지 윗사람에게 보고는 적당히 둘러
댈 수 있다. 결국 윗사람 들에게 추궁 당하는 것은
마지막 한 번뿐이다. 항상 다음 Sprint에서 잘 할 수 있다고 계속
뒤로 미룬다. Scrum이 원래 그런 것이니 이의를 제기할 수도 없다. 물론 처음부터 이런 상황을 고의로 하지는 않는다. 그렇다면 범죄자이지 개발자가 아니다.
하지만 환경이 그렇게 만들고 진행하다 보면 얼마든지 합리화를 할 수 있다.
결국은 Scrum이라고 해서 시작하지만 중요한 본질은 다 사라지고 껍데기 한두 개만
남은 가짜가 된다. 가짜가 생존할 수 있는 이유는 다수인 개발자들이 편하게 변형되었기 때문이다.
개발자들의 관리를 타이트하게 하려고 만든 Scrum이 변질된 가짜
Scrum의 우산 아래 마지막 순간까지는 편하게 개발을 할 수 있다는 것이 딜레마이다.
필자가 꼭 보고 싶은 것은 Scrum의 원칙인 매 Sprint마다
Stakeholder가 참여해서 심각하게 시연하고 검토를 하고 협의를 해야 한다는 것이다. 이런 고객 참여가 Fake Agile인지 아닌지를 판별하는 가장 핵심 지표이다.
그런데 보통의 소프트웨어 제품들이 Scrum 처럼 진행 중에 요구사항을 변경하거나
결정해도 되는 제품은 드물다. 당연히 홈페이지 제작할 때는 Scrum방식이 나쁘지 않다.
위의 시나리오가 Scrum을 할 때 통상적으로 벌어지는 시나리오이다. Scrum을 제대로 수행하고 있다면 필자가 진심으로 존경을 표할 것이다. 그런 팀이 있다면 계속해서
Scrum을 하기 바란다. 현실은 기존의 가짜 폭포수방식보다 훨씬 어렵다.
솔직히 개발자로서의 입장에서 보면 제대로 된 Scrum은 절대 하고 싶지 않다.
생각만 해도 회사에 가기도 싫어진다. 그러니 누가 억지로 Scrum을 시킨다면 수 많은 편법을 동원하려는 것은 고통을 싫어하는 인간의 본능일 것이다.
댓글 없음:
댓글 쓰기