TDD, 일명 테스트 주도 개발이 업계에 나온지 10년이 지났다. 익스트림 프로그래밍 움직임의 일부로 시작했지만, 스크럼을 포함한 사실상 모든 애자일 방법론에서 테스트 주도 개발을 받아들였다. 애자일을 사용하지 않는 팀조차 TDD는 적용한다.

내가 처음 테스트 우선 개발(Test First Programming) 이라는 말을 들었을땐 회의적이었다. 사실 누구라도 그럴 것이다. 단위 테스트를 먼저 만들라니? 그딴 얼빠진 짓을 하는 사람은 대체 누구란 말인가?

하지만 프로 개발자로 수십년 일하는 동안 수많은 것들이 업계에서 나타났다 사라지는 모습을 보았다. 세상 물정을 알게 되자 어떤 것이든 곧장 내팽개치면 안 된다는 사실을 알게 됐다.

한때 TDD를 집중적으로 연습할 때가 있었다. 인터프리터 언어에서는 빌드시간이 없어서 한 줄을 더한뒤 바로 실행했다. 반복 주기가 매우 빨리 돌았다. 따라서 그런 언어는 매우 생산적이다.

하지만 실제 프로그래밍에서는 그런 반복 시간은 말이 안 된다. 실제 프로그래밍에서는 한참 코딩한 후 컴파일하느라 한참을 더 쓴다. 그 후 오류를 잡는데 더 많은 시간을 쓴다. 난 c++ 프로그래머였다. c++는 빌드와 링크를 하는데 몇분 때로는 몇 시간이 필요했다. 30초 반복 시간은 상상할 수 없었다.

얼마전 나온 Go는 인터프리터 언어와 컴파일 언어의 장점을 적절히 섞은 환상적인 언어다. c++에서는 십만줄의 코드에 단 한줄만 추가해도 처음부터 컴파일 해야 하지만 Go언어는 백만줄의 코드가 있더라도 수정한 부분만이 컴파일에 추가되어 잘 작동하게 한다. 분명히 성능이 매우 빨라야 하는곳은 여전히 c와 c++가 쓰이지만 추후 Rust가 점점 빨라지는 컴퓨터를 무기로 이 자리를 70%가량 대체할 수도 있다. 왜냐하면 러스트는 이미 c++와 같은 속도로 근접했기 때문이다.

그 반면 Go는 자바나 파이썬을 최소 50% 가까이 대체할 수 있다. 퍼포먼스와 생산성의 조화가 미쳤다고 할수 있으며 c++나 러스트만큼의 속도가 필요한 곳엔 쓰기 힘들지만 거의 웬만한 회사에서는 이 언어를 주력으로 쓸때 무수히 많은 비용을 절감할수 있다. 무엇보다 아까 말한 수정한 만큼의 시간만 들어가기 때문에 백만줄 천만줄의 코드를 다시 몇시간씩 들여 컴파일하는 일은 생기지 않는다.