빠르게 개발하기(Agile)

그리 Agile분야에 대해 깊은 경험은 없지만 그래고 읽고 보고 생각한 것들의 정리.

전통적인 패키지 소프트웨어의 개발의 경우 한번 릴리징이 되면 패치를 내거나 새 버전을 만드는 것이 어렵다. 요즘 온라인 업데이트를 할 수 있게 되어 많이 쉬워진 편이지만 그래도 적당한 마일스톤을 요구하게 된다. 이러한 릴리징 특성상 릴리징 전의 개발 과정에서 치밀한 계획, 개발, 검증이 필요하며 전통적인 개발방법론이 적용될 것이다. 현재까지의 많은 웹 어플리케이션(서비스)도 이런 전통을 이어 받아 1년에 한두번 정도 대대적인 업데이트를 하게 되며 이는 마치 기존 패키지 소프트웨어의 배포(deploy)와 비슷한 성향을 가지고 있다.

최근에 Agile이 대두되기 시작한 것은 우선 웹어플리케이션의 경우 실시간 적인 반영이 가능하고, 또한 닷컴버블 이후 실체를 빨리 대중에게 보여주어야 하는 요구사항 때문인것 같다. 따라서 원자력 발전소나 화성 탐사선에 들어갈 소프트웨어에는 피해야 할 방법이며 실시간 적인 적용과 피드백이 가능한 상황일 수록 적용도를 높여야 할 것이다. 패키지 소프트웨어라면 전통적인 마일스톤 Release 위에 중간 과정에서 부분부분 Agile적 요소를 가미하는 것이 좋을것이고 웹어플리케이션이라면 극단적인 Agile을 추구하는 것도 방법일 수 있다.

http://www.ringblog.net/1202 : 아이디어를 죽이는 조직 by 링블로그

직접적인 관계가 있지는 않지만, 아무튼 Agile의 가장 큰 적은 조직 그 자체일 것이다. 조직은 태생적으로 자신을 유지하려는 특성을 가지고 있는데(관성?) Agile의 기민하게 움직여야 하는 특성에 장애가 될 것이다. 서비스를 만드는 닷컴기업이 순식간에 붕괴한 이유중 하나는 주식을 공개하면서 주주의 의견을 반영하거나 그들에게 보여주어야 했고 얼토당토하지 않은 아이디어를 시도해 보기보단 실적위주의 시도, 보여주기식 시도를 하게 되거나 구성원들이 책임을 져야 해서 무거워 지거나 회피하는 행동을 하게 된 것이 아닐까 한다.

처음 모인 몇사람들이 회사를 창업하면 한동안은 의기투합해서 마구마구 굴러가지만 조직이 세워지는 순간 경직된다. 전통적인 회사 모델에서는 겪어야 하는 진통중 하나이기도 하다. 전에 다녔던 벤처회사가 상장기업이 되고 그 이후를 겪으면서 느낀 부분이기도 하다. 그리고 벤처에서 시작하였으나 지금 거대 기업이 된 후 변해버린 회사의 특성이 이해가 가게되는 부분이기도 하다.

최근의 서비스들이 원하는 것은 기본적으로는 지속적인 주목일 것이다. 사람들이 끊임없이 바라봐 주길 바란다. 단방에 1위 자리를 차지하기도 힘들고 상위권에 들지 못하면 돈벌기도 힘들다 보니 지속적인 혁신을 통해 이목을 계속 받아 성장해 나가길 바랄것이다. 따라서 6개월 혹은 1년마다의 서비스 변화는 문제가 되고 좀더 간격을 단축시키기 위해 Agile에 열을 올릴 것이다. 작은 개발 조직, 작은 개발 사이클, 지속적인 혁신, 계속되는 피드백, 끊임없는 팬들의 성원.

여기서 유의할 것은 Agile이 개발 기간을 단축하거나 개발 자체의 성공가능성을 올려주는 아니라는 것이다. 효율적이란 단어들이 많이 나오지만 결국은 위와 같은 환경 변화때문에 체질 개선을 한 것이지 새로운 은총알(Silver bullet)이 아니라는 것이다. 닷넷기업(포스트 닷컴기업을 비꼰 말?)들이 세상에 지속적인 이목을 끌어야 하다보니 전에는 상상도 못할 무식한 도박을 하는 것이 Agile이라고도 할 수 있다. 작은 시도등을 통해 직전 릴리즈의 기능은 흔적도 없이 폭파될 수 있는것이 Agile이다. 전통적인 개발에선 있을 수도 없는 일 아닌가(물론 그당시에는 폭파를 시키기 힘들었지만;). 각종 Agile 책에서는 약장사 마냥 빨리 고객의 요구사항을 정확히 찾아낼 수 있다거나 불필요한 노력을 없앨 수 있다고 하지만 그것은 이상적인 상황이다. 결과적으로는 부산에서 서울을 가려는데 일본에 배타고 갔다가 미국 들러서 비행기 타고 올수도 있다.

그럼 Agile의 도박 확률을 높이기 위해선? 높이는 방법은 나도 잘 모른다. 하지만 낮추는 방법은 안다. Agile을 외치면서 조직이나 개인이 기존처럼 움직이는 것이다. Waterfall 모델에서 최초 요구사항 수집 단계를 나중에 다시 피드백 받으면 되지 하면서 대충 해버리게 되면 원사이클에서 아마 흔적도 없이 회사는 폭발할 것이다. 기존의 많은 어플레이케이션들이 시도했던 마구잡이식 기능 추가의 경우 Agile을 잘못 만나면 "일단 넣고봐"가 되는데 이런 경우 다른 프로세스들이 매우 경직되게 되고 전체적인 흐름이 잘 돌지 못하게 되거나 다음 턴에서 Chaos(혼란)에 빠지게 된다.

Agile을 하면서 Analysis를 소흘히 하는 경우가 있는데 절대 안될 말이다. waterfall에서는 초반에 하고 땡이었다지만 Agile은 반대로 항상 분석하고 예측한다. Feedback이 오기 전에 Feedback에 따라 어떤 방향들이 있는지 미리 생각해야 한다. 정확히는 어떤 결정을 위해 지금 이 기능을 시도해 보는지가 필요한 것이다. 단순히 넣어봐서 사용자 증가하면 OK, 줄면 빼는 것이 아니라는 것이다. 기능을 넣고 사용자의 어떤 반응을 분석해서 다음 턴에 반영할 것인지 계획이 서야 한다. 또한 추가되는 기능셋은 가능한 범위내까진 분석이 된 것이다. 전통적인 방법들이 예측하기 힘든 부분까지 결정해야 해서 문제가 되니 최근에는 늦게 결정할 것은 미루자는 것인데 이것이 결코 결정을 대충 하자는 것이 아니라는 점이다. 기존에는 yes or no였다면 이제는 yes or no or "more information" 3가지로 분류하는 것이다. 특히 어떤 inforamtion이 필요한지 명확히 찾아야 한다. (잘 모를때는 그것을 알 수 있게 하는 information이 뭔지)

많은 Agile 책들이 자신의 상황에 맞게 점점 변해보라고 서두에 밝히고 있지만 반대로 말하면 프로젝트 몇개 말아먹을 각오 해라는 게 아닐까 한다. 적어도 Agile은 은총알-모든 고민을 단방에 해결해 줄 만병통치약은 아니라는 것은 확실할 것이다. 그저 세상에 이름을 한번 올릴 수 있는 기회를 줄지도 모를 환상의 단어일 뿐이다. 실제적인것은 실제로 개발 프로세스가 어떻게 되는 가와 운과 미국 주식시장(?)에 달려있다. 할 수 있는것은 모든 것을 버리고, 발가 벗고 뛰는게 아닐까 한다.