# 1 / OT. TDD 란 무엇인가.

NEXTSTEP 에서 진행하는 Tdd,Cleancode with JavaScript 5기를 수강하게 되었다. 사내 동료 프론트 개발자분이 이 과정을 수강하면 실력 폭풍 성장 100% 보장한다고 하셔서 내돈내고 듣는다. ㅋㅋ 더 많이 얻어가려면 스스로 열심히 해야되니까 과정에 참여하는동안 간단하게라도 기록을 남겨보려고 한다.

 

오늘 라이브 세션은 OT 여서, 이 과정에서 무엇을 얻어갈 수 있는지 또 어떤 방식으로 진행되는지에 대한 내용 위주로 진행되었다. 

이 과정은 TDD 방식을 자바스크립트로 경험해보는 것이 주된 내용이다. TDD는 Test Driven Development 그러니까 테스트 주도 개발이라는 개발 방법론이다. TDD 정말 좋다, 도입해야한다, 공부해야한다 말은 많이 들어봤지만 이를 실무에서 도입하기란 쉽지가 않은 것이 사실이다. 당장 우리 회사 코드만 보더라도, 테스트 주도는 커녕 변화되는 요구사항에 맞춰 개발하기에 바빠 실제 테스트로 커버되는 영역이 그리 많지가 않다는 점이 아쉬운 점이다. 그리고 나는 테스트 코드를 작성해본 경험도 거의 없다. 

 

오늘 세션 중 가장 의외였던 부분은, TDD 방법론이 '요구사항이 변하기 쉬운 상황에 대응하기에 유리하다' 라는 내용이었다. "요구사항이 변하기 쉬우면, 그에 맞춰 테스트 코드도 바뀌어야 하고, 그러면 더 귀찮아지는거 아냐?" 라고 벌써부터 생각이 드는데 말이다. 변화될 수 있는 모든 요구사항에 맞춰 테스트코드를 짠다면 정말 귀찮은 일이 되겠지만, TDD 의 핵심은 테스트코드가 아니라 '피드백'에 있다는 점에 주목해야 한다. 

 

TDD 의 의의를 두 가지로 요약할 수 있을 것 같다. 1. 피드백 2. 핵심을 파악하는 능력.

두 가지를 종합하면, 핵심적인 기능에 대해서 (TDD를 통해) 빠른 피드백을 받을 수 있으므로, 결정된 내용에 대해 검증하고 수정하기에 용이하다. 여러가지 요구사항이 있을 때 그 중에서 핵심적인 요구사항은 사실 잘 변하지 않는다. 그래서 요구사항이 변하기 쉬운 상황이라면, 우선 가장 핵심이 되는 요구사항에 대해 빠르게 구현 및 피드백을 받고 올바른 결정인지 혹은 수정이 되어야 하는지 검증을 할 수 있기 때문에 유리하다는 것이다.

 

이 과정에서 "피드백" 이란 단순히 테스트코드에 국한되는 것이 아니라는 설명이 있었다. 빨리 만들어서 유저에게 피드백을 받을 수 있다면 그 또한 '핵심' 그리고 '피드백' 이라는 측면에서 TDD 의 의의에 부합하는 것이다. 테스트코드의 장점은, 리팩토링을 할 때 코드의 기능이 깨지지 않도록 방어를 할 수 있고, 미래의 나 혹은 다른 개발자가 코드의 기능과 역할을 파악하기 쉽다는 부가적인 기능이 있다는 것이다. 

 

사실 '요구사항'의 관점에서 TDD 의 의미가 100% 와닿지는 않는다. 이건 실제로 과제를 통해 경험하며 체득하는 과정이 필요하다고 생각된다. 그 외에 나머지, '핵심' 과 '피드백' 은 정말 좋은 내용인 것 같다. TDD 에서는 핵심을 파악하고 거기에서 출발해 내용을 붙여가는 방식으로 개발을 하도록 먼저 요구사항을 분해하고 다시 구조화 하는 과정을 거치게 된다. 사실 테스트코드를 차치하고서라도 이러한 방식의 분석 과정을 통해 더 구조화되고, 더 나은 프로그램을 작성하는데 큰 도움이 될 것 같다. 

 

또 최근에 읽은 '함께 자라기 - 애자일로 가는 길' 이라는 책에 대한 언급이 중간에 나와서 반가웠다. 이 책에서 등장하는 '의도적 수련' 또한 의미있는 피드백의 중요성을 강조한다. 테스트 역시 내가 작성한 코드에 대한 빠른 피드백이기 때문에 개인과 팀의 성장에 있어서도 TDD 가 주는 의미가 클 것이라 기대된다. 

 

결론, 코드리뷰 열심히 해야지!