애자일 디자인에 대한 일반적 오해들

John Ousterhout이 한 유튜브 대담에서 애자일 디자인 및 테스트 주도 개발 비판했는데, 근본적인 의견 차이가 있다기보다는 오해에서 비롯된 허수아비 비판이라고 생각한다. 비판의 내용은 본인의 저서(The philosophy of software design) 19장에서와 크게 다르지 않다. 이 대담이 애자일 디자인에 대한 흔한 오해 몇 가지를 잘 드러내고 있는 것 같아서 정리를 해봤다.

TDD를 하면 설계를 안한다

저자는 테스트를 작성하고 이를 하나씩 구현하는 게 TDD의 전부이며, 이런 방식으로는 좋은 설계를 얻어낼 수 없을 뿐 아니라 오히려 설계에 방해가 된다고 주장한다.

하지만 이는 TDD에 대한 오해다. 테스트를 작성하는 과정에는 반드시 설계가 수반되며(어떤 모듈에 어떤 함수가 있어야 하는지, 그 인터페이스는 어떻게 생겨야 하는지 등을 클라이언트 관점에서 고민하기), 테스트가 통과한 뒤에 리팩토링을 하는 과정도 설계이다.

하지만 작은 테스트 단위로 하는 설계나 작은 코드를 리팩토링하며 얻어내는 설계라는 건 너무 소소하다고 여길 수 있다. 하지만 이는 “가장 작은 스케일의 TDD가 TDD의 전부”라고 여기는 다른 오해에 기반한다.

가장 작은 스케일의 TDD가 TDD의 전부다

애자일 방법론의 여러 실천법은 프랙탈 구조로 설계되어 있고 TDD도 마찬가지다. 가장 작은 스케일에서 테스트 코드를 먼저 작성한 뒤 이를 만족시키는 구현 코드를 만드는 방식은, 큰 스케일에서 시장의 요구에 의해 소프트웨어의 기능을 유도해내는 린 생산의 Pull system과 동일하다. 작은 스케일에 “녹색 막대”가 있다면 큰 스케일에는 “비즈니스 가치 창출”이 있다.

중간 단계에는 ATDD가 있다. 사용자 스토리에 큰 수준의 인수 테스트를 먼저 적는 방식. Ward Cunningham이 2002년에 만든 Framework for integrated test는 자동화된 ATDD 프레임워크다.

이렇게만 쓰면 “가장 작은 스케일의 TDD”와 “중간 단계의 ATDD” 사이에 아무 것도 없는 것으로 오해할 수 있는데 그렇지 않다. Test-driven development: by example에서 “짧은 보폭”을 보여준 이유는 그 보폭이 모범적이기 때문이 아니라, 가장 짧은 보폭에 익숙해져야 보폭을 다양하게 조절할 수 있기 때문이다. 그런데 많은 사람들은 가장 짧은 보폭의 TDD만이 제대로 하는 TDD인걸로 착각을 하곤 한다. (참고: TDD 주기의 보폭)

애자일 방법론은 선행 설계를 하지 않는다

유사한 범주의 또다른 오해가 있는데 애자일 방법론은 선행 설계(upfront design)를 하지 않는다는 오해다. 애자일 방법론은 항시 선행 설계를 한다. 애자일 방법론에서 반대하는 방법은 비대한 선행 설계(BIG upfront design 또는 BIG design upfront)일 뿐이다.