툴을 완벽하게 다루지 않더라도 쓸모가 있을 수 있다. 어떤 툴은 대략 다루는 정도로도 큰 쓸모가 있을 수 있다.
테스트 주도 개발(Test-driven development)라고 부르는 TDD가 그렇다. 소프트웨어는 유동적이고 예측하기 어렵다. 시장이 어떤 방식으로 변할지 모르기 때문에, 변화에 대응하면서 짧은 주기로 완성된 소프트웨어를 시장에 내놓을 수 있어야 한다. 기존의 개발 방식은 계획을 수립하고 설계를 완성한 다음에, 설계문서에 따라서 코드를 만들면 됐다. 테스트는 코드의 개발이 다 끝난 다음에 테스트만을 전문으로 하는 팀으로 넘긴다. 테스트에 실패하면 해당 내용을 개발팀에 넘기고.. 이렇게 몇번 공을 주고 받은 다음에, 테스트가 끝났다고 생각하면 서비스를 오픈한다. 이러한 개발방식이 나쁜 방식은 아니다. 시장을 장기적인 관점에서 예측 할 수 있다면, 만전을 기해서 제품을 내놓는 것도 좋은 방법일 것이다. 그리고 여전히 이러한 방식이 유효한 산업 분야도 있다.
하지만 지금의 인터넷 소프트웨어 시장에 적합한 방식은 아니다. 기존 방식으로 했다가는 설계가 끝난 시점에서, 변화된 시장의 요구를 반영하기 위해서 설계를 전면 재검토 해야 하는 상황이 닥칠 수도 있다. 그래서 완벽한 설계를 지향하는 기존의 모델(폭포수 모델이라고 부르는)을 버리고, 초기의 설계비용을 줄이고 작은 소프트웨어를 빠르게 개발해서 시장에 내놓은 다음 그 것을 보완해 나가는 나선형 모델을 도입하게 된다.
나선형 모델은 변화하는 시장에의 빠른 적응을 도와주지만, 모델 고유의 문제점 또한 가지고 있다. 빠르게 적응한다는 이야기는 소프트웨어의 기능의 추가, 삭제, 변경이 수시로 일어날 수 있다는 것을 의미한다. 소프트웨어 모델조차도 변할 수 있다. 보통 소프트웨어 개발자들은 기능의 추가나 변경에 대해서 극도로 민감해하기 마련이다. 간단해 보이는 요구사항이라고 하더라도 많은 부분에서의 변화가 있을 수 있기 때문이다. 특히 설계가 중요한 폭포수 모델에서 설계에 영향을 줄 수 있는 기능의 변경은 소프트웨어 개발 기간과 품질에 나쁜 영향을 끼치는 경우가 대부분이다.
하지만 인터넷 서비스에서 기능의 변경은 일상적이다. 애초에 나선형 모델은 시장을 예측 할 수 없고, 계획대로 개발이 흘러가지 않는 것을 상수로 두고 있는 개발 모델이다. 개발 중 소프트웨어의 기능과 방향에 변화가 생기면 소프트웨어의 품질을 유지하기가 힘들어진다. 이건 나선형 모델이라고 해도 마찬가지다.
따라서 유연한 설계와 기능의 변경, 잦은 출시(잦은 출시라는게 결국 기능추가나 변경을 자주 하겠다는 이야기니까.)
... 계속
Contents
TDD
참고 문서들
Recent Posts
Archive Posts
Tags