방법론 엑소더스, 그리고 기민함의 시대로

방법론이란 소프트웨어를 만들어 내기 위해 행하는 모는 것을 의미하며
우리가 속한 그룹이 동의한 약속이다.
따라서 적절한 방법론을 가지고 있다면
체계적인 절차와 적합한 도구 및 기법을 사용하여
효율적으로 소프트웨어를 개발할 수 있게 된다.

그러나 방법론이 모든 문제를 해결하려고 시도하는 순간 자기 모순에 빠지게 된다.
그동안 우리는 모든 개발 문제를 해결해 줄 수 있는
보편적인 개발 방법론이 존재할 수 있으리라는 어리석은 생각에 빠지고 말았다.
방법론을 모든 질병을 치료해줄 만병 통치약으로 착각했던 것이다.

애석하게도 이것은 불가능하다.
다시 말해 방법론이 일반화되면 될수록 그 가치는 더욱 하락한다는 뜻이다.
모든 문제를 해결하기 위한 방법론이 만약 있다면,
역설적이게도 그 방법론은 구체적이고 특수한 문제를 해결하는 데에는
거의 도움을 주지 못할 것이다.

"애자일 동맹 선언"의 핵심은 다음의 4가지 문장으로 압축된다.

- 개인과 상호작용이 프로세스와 툴보다 우선이다.
- 동작하는 소프트웨어가 포괄적인 문서보다 우선이다.
- 고객 협력이 계약 협력보다 우선이다.
- 변화에 대한 반응이 계획을 따르는 것보다 우선이다.

변화의 수용과 즉각적인 피드백이 애자일의 모토로 자리잡으면서
개발 방법 역시 많은 변화를 겪게 되었다.

통합 시 실패에 대한 피드백을 받을 수 있는 방법은 무엇인가?
지속적인 통합(Continuous Integration)을 적용하라.

고객에게 원하는 가치를 제공하고 있는지에 대한
피드백을 받을 수 있는 방법은 무엇인가?
최대한 빨리 배포하고 반복(iteration) 주기를 통해 주기적으로 배포하라.

피드백 주기가 길어지는 사전 설계(Big Up-front Design)대신
피드백 주기가 짧은 TDD(Test-Driven Development)를 적용하라.

그리고 리팩토링(Refactoring)을 통해 설계와 코드를 지속적으로 개선함으로써
코드를 항상 최상의 상태로 유지하라.
점진적인 설계 사이클을 도입함으로써
설계와 구현을 독립적인 활동이 아닌 상호 영향을 주고 받는
유기적인 절차로 바라볼 수 있게 되었다.
따라서 경험을 기반으로 한 지속적인 리팩토링을 통해
최적의 소프트웨어의 설계를 얻을 수 있다.

애자일에서 강조하는 또 하나의 핵심 주제는 문서를 통한 의사소통을
가능하면 배제하고 이해관계자 간의 직접적인 대면과 대화를 통해
의사소통의 효율성을 촉진시키라는 것이다.

이것은 DDD를 지탱하는 두 가지 축 중 하나인 UBIQUITOUS LANGUAGE를 구축하기 위한 핵심 조건이다.