2017년 7월 15일 토요일

분석 #8 애자일은 죽었다

"애자일"이라고 하면 국내 소프트웨어 업계에서는 보통 "스크럼"으로 알고 있다. 여기서 스크럼을 자세히 설명하는 것은 의미가 없고 대충 설명하자면 10명 정도의 한 팀에서 스프린트라고 불리는 2주일 개발주기로 개발하면서 매일 아침 서서 회의를 한다는 것이다. 필자는 이 말을 듣고 농담하는줄 알았다고 책에서 적은 적이 있다.

하여튼 형식과 체계를 싫어하는 자유로운 영혼의 개발자들에게는 무척 희소식이다. 어차피 아무런 체계없이 주먹구구식으로 계속 개발할 수는 없다. 명분도 없고 어딘가 찜찜할 수 밖에 없다. 그런 와중에 아주 쉽게 적용할 수 있는 애자일이라는 방법이 있으니 반가울 수 밖에 없다. 이제는 자랑스럽게 방법론에 의해서 개발을 하고 있다고 말할 수가 있게 되었다. 일단 주먹구구식에서 벗어났다고는 할 수 있다. 그 길이 옳은지 아닌지는 별개의 문제이다.

"애자일"은 추상적인 단어이고 그 종류가 많지만 이 글에서는 애자일이라는 단어를 방법론 중에서 가장 자유로운 스크럼 방법론이라고 가정하고 진행한다. 그 반대 극단은 한번 결정한 것을 변경하지 않는다는 가장 엄격한 방법론인 폭포수모델이다. 요구사항의 변경을 수용하기 위한 반복적인 개발모델의 필요성이 의논된 것은 소프트웨어의 탄생 얼마 후인 1957년이었다. 지금부터 60년 전이다. 그리고 폭포수모델의 병폐와 애자일 방법론의 필요성에 대한 본격적인 논쟁은 거의 30년 전인 1990년에 출간된 "Wicked Problems and Righteous Solution" 이라는 책에서 벌어졌다. 마치 애자일방법론이라는 비법을 최근에 발견한 것 처럼 착각하는데 스크럼이 탄생한 1995년에도 애자일은 이미 퀘퀘묵은 논쟁이었다. 폭포수모델이 필요한 곳에서는 폭포수모델을 계속 사용할테고 절대 폭포수모델을 사용하지 않는 곳도 있고 너무 당연한 종교적인 논쟁일 뿐이다. 중요한 것은 어떤 방법론이 우리가 개발하는 제품에 적당할 것인가이다.

필자가 실리콘밸리에서 20년 동안 사용한 방법론은 방위산업체에서의 수년간의 폭포수모델과 그 나머지는 애자일 방법론이었다. 물론 애자일이라는 용어가 생겨나기도 전이었기 때문에 스크럼은 당연히 아니고 "빨리 개발하는 방법론" 이라는 의미에서의 애자일방법론이다. 회사마다 빨리 개발하는 방법이 다 달랐다. 당연할 수 밖에 없다. 프로젝트가 다른데 폭포수나 스크럼이 만병통치약이 안되듯이 한 가지 방법론으로 다 통할 수가 없다. 경직도로 봤을 때 폭포수와 애자일 중간에는 수십개의 알려졌던 방법론이 있고 비공식적으로는 회사마다 다른 수만개의 방법론이 있다.

애자일의 공식적인 생애는 1995년 ~ 2014년까지 20년이다. 그래도 다른 방법론에 비하면 오래 생존한 편이다. 애자일을 창시한 사람들이 애자일은 잘못되었다고 선언했다. 인터넷에서 'Agile is dead"를 검색하면 많은 기사들이 많이 나온다. 그렇다고 애자일을 창시한 사람들이 소프트웨어 개발의 근본 원칙을 부정한 것이 아니라 간단한 규칙을 만들어 준 것이었다. 그 규칙을 누가 어떻게 해석하고 이용하는 가에 따라 좋은 것이 될 수도 있고 나쁜 것이 될 수도 있는데 대부분은 애자일을 만든 사람의 의도와는 다르게 사용되었기 때문에 실패했다고 공식적으로 선언한 것이다. 수 많은 방법론의 역사에서 보면 심각한 일도 아니고 하나의 해프닝으로 볼 수 있다.

결국 애자일이 되었던 폭포수가 되었던 수 많은 실리콘밸리회사들이 사용하는 방법론의 원칙을 이해하는 것이 중요하다. 그 진리는 분석, 설계, 구현이다. 이 단계를 잘 이해하고 적용하는 것이 중요하지 방법론의 규칙이 중요한 것이 아니다. 어차피 극히 소수만 사용하는 폭포수방법론이 아닌 경우에는 모두 반복적인 방법론이다. 이미 몇십년 전에 공식적으로 반복적인 방법론이 나왔기 때문에 새로운 것이 아니다. 스크럼이 하나의 방법론으로 눈에 띄기 위해서는 어떤 매력적인 규칙을 정해야 하는데 그 중에 하나가 2주 주기 개발이다. 기존의 방법론과 차별화가 안되니 2주를 강조했다. 거기에다가 Sprint라고 멋진 이름을 붙였다. 또 Daily Standing Meeting이라는 용어를 만들어 냈다. 앉아서 회의를 하면 기존의 방식과 전혀 다를 것이 없으니까 일어서서해야 한다는 것을 강조했다. 결국 스크럼방법론은 이미 기존의 회사들이 하고 있었던 방법과 별로 다를 것이 없는 것이다. 새로운 것도 아니고 나쁜 것도 아니다. 마케팅의 성공일 뿐이다. 그 덕택에 20년간 인기를 누리면서 혜택을 받은 사람들이 있었다.

지금도 어떤 프로젝트에서는 폭포수가 적절할 수도 있고 스크럼이 적절할 수도 있다. 그럼 분석이라는 측면에서 보면 어떤 것이 더 적당할까? 완벽을 추구하는 폭포수나 2주일 만의 기능을 명시하는 스크럼이나 필자가 볼때는 대부분의 프로젝트에서는 적절하지 않다. 그럼 무슨 방법론이 적절할까? 방법론을 찾아서 떠도는 순간 영원히 방법론을 찾지 못할 것이다. 왜냐하면 그런 방법론은 없기 때문이다. 마치 나에게 가장 좋은 음식이 무엇일까를 찾는 것과 같다. 좋은 음식이 사람마다 다른 것 같이 프로젝트마다 다르다. 한 회사 안에서도 프로젝트 마다 다르다. 하나의 틀에 억매이지 않고 원칙을 알고 잘 응용하는 것이 중요하다.

소프트웨어는 외부 고객이건 내부 고객이건 혹은 자기 자신이건 누군가의 요구에 의해서 개발하는 것이다. 이런 고객요구사항이 변하는 것은 소프트웨어 탄생부터 있어 왔던 변하지 않는 현상이다. 이 현상 때문에 폭포수가 잘못되었다고 말할 수는 없다. 그런 환경까지 고려해서 만들어진 것이 폭포수이기 때문이다. 핵심은 고객요구사항이 변하는 상황에서 컨트롤할 수 있어야 한다는 것이다. 그 방법이 한번에 완벽히 작성해서 확인하는 방법일 수도 있고 매일 고객과 물어보면서 작성할 수도 있고 2주일에 한번씩 보여주면서 얘기할 수도 있다. 같은 프로젝트 안에서도 어떤 경우는 매일 의논이 필요하고 어떤 경우는 1달 동안 얘기할 필요가 없는 경우도 있다. 현실에서 벌어지는 모든 프로젝트는 비규칙적이고 반복적인 협의를 필요로 한다.

결국 모든 방법론의 형식은 항상 변화해 왔지만 그 내용이 중요하다. 어떤 방법론에서도 결국 성공하려면 코딩을 잘 해야 하는 것처럼 설계도 잘 해야하고 분석도 잘 해야 한다. "잘" 이라는 용어가 "완벽하게"를 의미하지도 않고 "2주일마다"를 의미하지도 않는다.

드디어 가장 중요한 결론이 나온다. 자연의 불변하는 진리인 열역학 제2의 법칙은 "자연계에서 자발적인 진화방향은 혼란도(엔트로피)가 증가하는 방향으로 진화한다"는 것이다. 즉 열은 뜨거운 곳에서 낮은 곳으로 흐르고 흐르고 반대방향은 일어나지 않는다. 이를 비가역성이라고 한다. 최초에 열을 높은 곳으로 올려 놓는 것은 자연적이 아니라 인위적으로 해야 한다. 폭포수가 가장 안정된 상태이고 주먹구구식이 가장 엔트로피가 높은 상태이다. 자신이 최초에 원하는 수준에 가려면 그 수준을 가진 회사에 가서 배워야 한다. 폭포수를 해 본 사람은 그 아래의 어떤 방법론도 응용해서 할 수가 있다. 할 수 있는 것을 안하는 선택만 하면 된다. 하지만 애자일만 해 본 사람은 폭포수를 절대 할 수가 없다. 해 본 적이 없는 것을 할 수는 없다. 혼란한 곳에서 안정된 곳으로 갈 수 없는 자연의 진리 때문이다.

모든 규칙을 다 터득한 사람은 모든 규칙에서 벗어나 완전한 자유를 누릴 수 있다. 어려운 육체적인 고통의 수행을 거쳐 진리를 깨달은 사람을 해탈했다고 하는 것이 혼란하지 않은 마음의 안정을 얻었기 때문이다. 엔트로피가 가장 낮은 안정된 상태를 만드는 것은 어려울 수 밖에 없고 그래서 가치가 있다. 엔트로피가 가장 높은 방법론인 애자일을 배웠다면 움직일 수 있는 선택의 폭은 그 보다 다 자유로운 주먹구구식방법 밖에 없다. 물은 절대로 거꾸로 흐리지 않는다. 누가 인위적으로 올려다 주기 전에는 아래로만 갈 수 있다.

어떤 프로젝트에도 응용할 수 있는 방법론을 배우려면 가장 엔트로피가 낮은 폭포수모델을 배우는 것이다. 이런 방식이 미국의 60여년의 소프트웨어 역사가 지나온 방향이다. 그렇기 때문에 실리콘밸리에는 다양한 엔트로피를 가진 회사들이 다 존재하고 자신이 일했던 회사보다 엔트로피가 높은 프로젝트는 모두 일할 수 있다. 반면에 한국에는 엔트로피가 안정된 회사들이 없다. 내용은 없고 형식만 흉내내는 혼란스러운 회사가 있을 뿐이다.

소프트웨어 개발을 잘 하기 위해 애자일방법론이 전혀 중요한 것도 아니고 가치도 제한적이라는 것을 이해하는 것이 미래 발전을 위한 첫 걸음이다. 지금 나에게 적절하다고 확신한다면 사용하면 된다. 하지만 맹목적으로 사용하는 것은 파괴적이라고 애자일의 창시자들이 말을 하니 "해봐서 손해 볼 것 없다"는 생각은 금물이다. 엄청난 기회비용을 상실하게 되니 신중하게 결정할 일이다.

애자일로 인해 역사가 되풀이 된다는 것도 알게 되었고 유행에 민감한 국내 개발 환경이 잘못된 리더들에 의해 핵심을 놓치고 미신에 빠져 국내 소프트웨어 발전에 큰 피해가 올 수 있다는 것은 항상 조심할 일이다.

댓글 없음: