진짜 TDD를 못하는 이유가 있어요.

요구사항과 구현이 동적으로 바뀌기 때문이지요.
프로그래밍이란 문제를 해결하는 과정에 비견 될 수 있습니다.
TDD는 문제가 잘 해결되었는지 사전검증하면서 문제를 해결해 나갑니다.
우리 속담에 돌다리를 두들기면서 건너는 식이겠지요.

그런데 문제는 담당자가 '자신이 필요한 것이 무엇인지는 알아도 정작 어떻게 해야 할지는 모르는'데 있습니다.
그에 따라 담당자는 옷가게에서 옷 고르듯이 요구사항을 내놓게 됩니다. 그 과정에서 테스트가 깨지는 요구사항이
나오게 되고 결국 불쌍한 개발자들은 테스트 코드를 고치고 그에 따라 또 코드를 고치게 되지요.

결국 TDD에서는 작성해야 할 코드가 2배로 늘어나게 되나 그에 따라 자신이 볼 이득은 전혀 없는 셈 입니다.
개발과 유지보수를 동시에 맡는다면 논란이 좀 있겠지만
개발따로 유지보수 따로인 환경에서는 자기 밥그릇 챙기기 바쁠 수 밖에 없지요.

요구사항을 사전에 정립해놓으면 된다고는 하지만
글쎄요.. 제 경험으로는 어떤 프로젝트든 그렇게 깔끔하게 끝난 적이 없었던 거 같습니다.
끝나면 어떤 식으로든 피드백이 왔었죠.

그것을 게으름과 의지 부족이라고 보신다면 할 말 없지만
결국 자신에게 돌아오는 것이 있어야 투자와 노력을 할 수 있는 것이 범부, 범인이지요.