애자일에는 이터레이션이라는 것이 있는데, 고객에게 1-2주 사이로 계속 피드백을 주면서 결과물을 수정해나아가는 방법이다.
보통은 이걸 수행하기 위해서는 '아직 덜 만들어진 것을 보여줄 수 있는 용기' 만 있으면 된다고들 하는데, 오늘 가만히 생각해보니 그것도 아닌것 같다.
물론 저 용기도 있어야 하겠지만..
그것보다 더 중요한 것은 유연한 구조와 설계가 아닌가 싶기도 하다.
프로그램이라는게 .. 유연하게 설계되지 않으면 (고객이 보기에는) 별 거 아닌 수정사항인데도 프로그램의 전반적인 구조를 다 뜯어 고쳐야 하는 경우도 왕왕 발생하기 때문이다.
그런데 반면 이 유연한 설계라는 것이 굉장히 어렵다.
유연한 설계를 한다는 것 차제가 거의 100% 경험에 의존하는 것이기도 하거니와 설계 자체가 너무 어렵다는 것에 기인한다.
왜 그럴까?
개발을 할 때 제약이 많다는 것은 개발자들에게 굉장한 이득을 준다.
여기서 제약이라는 것은 개발 환경의 열악함.. 이런 것을 말하는 것이 아니라, 최종사용자가 사용하는 데 있어서 제약을 주는 것을 뜻한다.
즉 이 경우에는 제약이라기보다는 규칙에 가깝다.
유저가 지켜야 하는 규칙이 많을수록 프로그램 개발은 쉬워지는 것이다.
예를 들어 전화번호를 입력할때 무조건 010-1111-2222 이런 식으로 입력해야 한다고 하면,
01011112222 라고 입력하면 프로그램이 오류가 나오거나 경고를 띄우게 된다.
이런 일련의 규칙들은 개발의 편의성을 더해주고 빠른 개발이 되도록 한다.
반면에 유연하다는 것은 , 반대로 말하면 정말 많은 경우의 수를 생각해야 한다는 것이다.
고객은 전화번호를 010-1111-2222 라고 입력할 수도 있고, 01011112222라고 입력할 수도 있으며, 010-11112222도 가능하고 0 1 0 - 1 1 1 1 - 2 2 2 2 라고 입력도 가능하다. 심지어는 공일공 일일일일일
이이이이 라고 치는 사람도 있을 수 있다.
이런 경우의 수를 모두 고려하게 되면, 프로그램 하나를 사용할 때 하나의 컨텍스트당 몇백개 이상의 시나리오가 나올 수도 있다.
쓰는 사람이 어떻게 쓸 지는 아무도 모르는 것이다!
이런거 다 고려해서 만들려고 하면.. 일단 머리를 쥐어뜯고 시작하는 것은 물론이거니와 그 쥐어뜯은 머리로 나온 결과가 여전히 중요한 무언가를 놓치기도 하게 된다.
100% 유연한 설계 자체가 불가능하다는거다.
즉, 애자일 이터레이션이 성공하려면
1. 아직 덜 만든 프로그램을 보여줄 수 있는 용기가 필요하다.
2. 생각할 수 있는 시나리오에서 가장 유연한 프로그램 설계가 필요하다.
천만 다행이도 고객에게 아직 덜 만들어진 프로그램을 보여주면 고객은 피드백을 줄 테고, 그건 그 나름대로 고객 맞춤형 유연 설계가 탄생할 가능성이 높아진다.
오히려 이쪽이 더 잇점이 아닐까 싶기도 하고..
덧. 1.
(* 위에 예로 든 전화번호 케이스는 사실 쉽게 처리 가능하지만, 그냥 예는 예로써 받아들이자. 복잡한 것은 머리에도 안들어오고 와닿지도 않을테니)
덧 2.
보통의 고객들은 다 만들어질때까지는 보여줘도 아무말 안하고 있다가 다 만들어지고 난 다음에도 아무말을 안하고 정작 쓰다가 불편하거나 마음에 안들면 그 때 되서야 기본 설계를 흔드는 변경을 당연시하게 요구한다.
그러니까 애자일 이터레이션을 너무 믿지 말자.
고객님께서 그렇게 해 달라고 하셨잖아요.. 라고 말해봤자 소용없다는거 .. 잘 알지 않는가?
마치 웰던으로 구워달라고 해 놓고는 막상 먹어보니 너무 익었다며 다시 레어로 돌려달라는 느낌이랄까..
덧 3.
그나저나 우리나라는 1-2주 사이에 웹사이트 하나를 찍어내는데
정말 초고속 이터레이션이 아닌가 싶기도 하고...
그 후 피드백을 받아서 또 1-2주 내에 완전히 바꾸는 걸 보니
초능력자 세상인 것도 같고 ...
2012.09.14. By RL.C
