TDD, Agile, DDD, MSA - 1

“트랜디한 IT 단어들의 나열”로 볼 수도 있지만 최근 내 경험을 바탕으로 보면 위 키워드는 모두 “비즈니스 지향 관점”이라는 하나의 점으로 모인다. 이들은 모두 어느날 갑자기 새로운 기법으로 발견, 발명된 것이 아니다. 이제 겨우 70년 정도밖에 안되었지만 소프트웨어 역사 그 처음부터 나타나 지속적으로 해왔던 활동이다. 그 활동을 방법론으로 정리해서 위와 같은 것들이 나타난 것이라고 생각한다. 오늘은 TDD에 대한 경험을 공유하려한다. 나의 경험상 TDD는 팀 내에서 나 혼자 하더라도 충분히 도움이 되고, 꼭 해야할 활동이다. 주니어에게는 반드시 추천하는 활동이고, 주니어 매니징이 쉽지 않은 시니어에게도 추천한다. 다음 중 하나라도 해당하는 사람들에게 TDD를 추천한다. a. 내 코드를 수정하는데, 회귀버그에 대한 걱정이 있다. b. 코어 모듈을 개발, 개선, 유지보수 하는데 안전장치가 필요하다. c. 코드를 작성하기 전, 나의 설계(해결방법)가 요구사항(문제)을 만족하는 지 리뷰 할 때 더 정확한 커뮤니케이션을 하고 싶다. d. 코드를 짜면서 처음 생각했던 코드보다 점점 비대해지며 코드가 산으로 가는 모습을 본 적이 있다. ( 코드를 작성하며 예상하지 못했던 케이스들이 점점 떠오른다. ) 내가 TDD를 하는 목적은 2가지다. 1. 새로 추가한 코드가 기존 코드에 영향을 주지 않는 다는 것을 확실할 수 있다. => 위 a,b 케이스에 대한 해결책이 되어준다. 2. 내가 해결하고자 하는 문제를 해결하고 있다고 확신할 수 있다. => 위 c,d 케이스에 대한 해결책이 되어준다. 1번의 것은 나 혼자만 테스트 코드를 작성한다고 가정할 때, 최소단위의 기능에 대해서는 '나'만이 작업해야 한다. 그 기능을 수정해야 할 경우, 나에게 인풋이 발생해서 내가 책임을 갖고 내가 해결할 수 있어야 한다. 1번은 테스트 코드가 주는 여러가지 이점 중 하나로 너무나도 많은 TDD 관련 글들에서 강조하고 설명하는 내용으로 스킵한다. 내가 정말 중요하게 생각하는 것은 2번이다. 내 주변에서 발생하는 문제 중 하나는 코드까지 다 작성해서 결과 리뷰 받고 나서 아예 코드를 엎어버리는 경우다. 앞의 일이 발생하는 이유는 실행자(코드를 작성하는 사람)가 문제를 잘못 이해했거나, 결정자(문제를 정의한 사람)가 지시를 구체적으로 하지 못해서 발생했을 것이다. 상황을 좀 더 분석해보자. 실행자 입장에서는 자연어로 풀어진 요구사항 ( userstory )을 제대로 이해하지 못했을 것이다. 그 요구사항에 대해서 가장 잘 이해하고 있는 사람은 프로덕트 오너와 같은 결정자가 될 것이다. 그러나 결정자는 시스템 설계가 그 문제를 제대로 해결하는 것인지 파악하는 것이 쉽지 않을 것이다. 이러한 상황에서 결정자는 요구사항을 전달했고, 실행자는 전달받은 요구사항을 바탕으로 시스템을 설계하고 코드를 작성했다. 그 결과를 보니 결정자가 원하던 모습이 아니게 되면, 둘의 시선차이가 있었음에도 그 차이를 인지하지 못하고 지나친 결과다. 이 시선의 차이를 매꿀 수 있는 것이 테스트 케이스 ( acceptance criteria )다. 실행자는 자신이 이해한 요구사항을 바탕으로 구체적인 테스트 케이스를 제시한다. 결정자는 해당 테스트 케이스를 통과하면 자신의 요구사항을 해결할 수 있는지만 판단한다. 이에 서로 테스트 케이스에 대해 동의하는 절차를 진행한다. IT에 처음 진입한 주니어들은 대부분 코드만 작성하면 될 줄 안다. 요구사항을 잘 이해하는 것 부터가 업무의 시작이라는 사실을 인지하기에는 약간의 시간이 걸린다. 이러한 주니어를 매니징해야하는 시니어에게는 주니어가 요구사항을 제대로 이해하고 있는지 파악하는 것부터 어려울 것이다. 이러한 상황에 위와 같이 테스트 케이스를 제공( 위에서는 실행자가 테스트 케이스를 제공한다고 했지만... 많은 이들에게는 이조차 버거운 태스크 일 것이다 )하고 테스트 케이스를 만족시키는 코드를 작성하도록 하면 주니어 매니징이 도움이 되지 않을까 한다. 테스트 케이스에 대해 실행자와 결정권자 간에 동의절차를 거친다면 c의 문제에 대한 해결책이 될 수 있지 않을까 한다. 그렇다면 남은 d 문제는 TDD가 어떻게 해결해 줄 것인가? d와 같은 현상은 대부분의 주니어들이 접하게 된다. 이와 같은 현상이 발생하는 이유는 당연히 경험과 역량 부족으로 코드를 짜다보니, 짜기 전에는 생각하지 못했던 것들이 떠오르기 때문이다. 여기서 문제는 떠오르는 것들 중 대부분은 원래 해결하고자 하던 문제에 해당하지 않을 것이다. ( 있으면 좋겠지만, 지금 당장 필요하지 않은 것들.. ) 이런 경우 생각이 떠오를 때마다 테스트 케이스를 추가하면 된다. 추가하고 테스트 케이스에 대한 리뷰를 받는다. 그리고 이전 테스트 케이스를 모두 충족시키고 추가해서 충족시킬 수 있도록 코드를 '개선'한다. 만약 새로 추가된 케이스 때문에 코드 전체를 엎어야 한다면, 시스템 설계에서 메인 문제를 놓친 것이기에, 시스템 설계부터 다시 하는 것이 맞을 것이다. 주절주절 말이 길었지만, 어쨌든 TDD는 나에게 매우 도움이 되었고, 되고 있고, 앞으로도 계속해서 할 생각이다. V자 모델, 나선형 모델, 에자일 등 개선되어온 개발 방법론에서 테스트 코드의 역할들을 생각해보면, 테스트 코드를 작성하지 않는 것이 이상하다는 생각이 된다. "개발자를 갈면(?) 안 된다던 것도 시간 안에 된다." 라는 문장이 있다. 이에 문장에는 다음과 같은 답이 있다. "해야할 일을 안 하면 가능하다." 테스트 코드는 꼭 작성해야하지만 작성하지 않아도 시스템은 돌아단다. 이러한 특성 때문에 납기일보다 위의 것이 없는 소프트웨어 시장에서 개발 방법론 중 "테스트 코드 작성" 단계가 생략되었을 것이다. 그러나 이대로는 안된다라는 생각을 가진 고수님들께서 테스트 코드에 대한 중요성을 다시 강조하기 위해 트렌디한 용어인 TDD 라는 이름을 통해 부활시킨 것이 아닐까 한다.