Testors.Net

사실 내가 스피드를 즐긴다거나, 레이싱이 엄청나게 재밌다거나.. 뭐 그런 이유는 아니다. -.-

어제 R튠이 끝났다고 해서 오늘 윰하고 손잡고 용인 KMSA 에 들러서 가져왔다. 간단히 몰아본 소감을 적어 보자면...

1. 무게는 쎄라토보다는 무겁고 젠쿱보다는 가벼운것 같다.
2. 전자식 악셀레이터는 여전히 적응하기 어렵다. 클러치감이 젠쿱보다는 감이 좋은것 같긴 하다만....
3. 3단 기어 물리자 마자 차가 뒤로 축 처지는 느낌. -_-;;; 그래서 서울 도착하자 마자 스펙을 뒤져보니 제길, 엄청난 롱기어다. 2단에서 3단 기어비 차이가 쎄라토보다1 30% 나 길다. 개인적으로 고속주행은 그다지 즐기지 않고 숏기어의 짧게 치고나가는 맛을 좋아하는데 완전 안습. 2단 레드존에서 변속해 보아도 RPM 이 4000 밑으로 떨어진다. 아이고.. oTL 그래서 3단 올릴때마다 매우 불쾌하다.
4. 아무래도 신형이다 보니 여러가지 편의장비들이 좋다. 블루투스는 원츄.. DMB 네비게이션 옵션을 넣지 않은걸 후회하고 있다.
5. 순정 시트는 직접 타보니 완전 안습... 가운데 재질이 꽤 미끄러워서 몸이 좌우로 요동친다. 거기다 시트고도 너무 높아... 왠만하면 걍 써볼까 했는데 필히 버킷시트로 바꿔줘야 할것 같다.

총평 : 쎄라토 유로가 몹시 그립다.. 그거 정말 좋은 차였구나.. 흑흑

덧. 윰을 내년 내구레이스에 출전시키려고 했는데 G 변화에 너무 민감해하는것 같다. 막 멀미난다고.... 어떡하지.. 아냐 아마 신차 냄새때문에 어지러웠던걸꺼야.. -.-;;;

나는 TDD 의 장점이 두 가지가 있다고 생각한다.

 

우선 첫 번째는… 살다 보면 예전에 만들어둔 코드가 이후의 수정 때문에 문제가 생기는 경우가 가끔 있다. 그런데 TDD 로 개발해 왔다면 이전에 작성해 둔 테스트를 활용 할 수 있기 때문에 이런 문제 발견이 쉬워진다. 대신, 코드 인터페이스 변경 시에는 기존의 테스트들도 고쳐주는 수고를 감수해야 할 것이다.

 

두 번째로, TDD 는 결합도(coupling) 낮은 디자인을 유도한다. 코드를 테스트 가능하게 만들려면 인터페이스가 명확해야 하고 어떻게든 다른 모듈과의 관계를 제거하거나 줄여야만 한다. 일반적으로 결합도가 낮은 코드는 좋은 디자인일 확률이 높기 때문에 모든 코드를 테스트 가능하게 유지하다 보면 전체적인 코드 수준도 좋아진다.

 

위와 같은 이유로, 기존의 프로젝트에 TDD 를 적용하는 것은 불가능하다고 본다. TDD 는 좋은 디자인을 ‘유도’ 할 뿐이지 이미 존재하는 나쁜 디자인을 좋은 디자인으로 ‘변화’ 시키지는 않기 때문이다. 켄트 벡은 기존 프로젝트에 TDD 를 어떻게 적용하냐는 질문에 책에서 ‘그것은 책 한권으로 설명해야 하는 분량이다’ 라는 답을 한것 같은데 내 생각에 기존 코드를 테스트 가능하게 만드는 방법은 없다. 그냥 새로 짜는게 빠르고 효율적일거다.

 

그렇다면 Testors는 모든 것을 TDD 로 개발하느냐..? 그렇지 않다. 나는 에반젤리스트도, 방법론자도 아니다. 뭔가가 새로 나오면 그것이 필드에서 실제로 동작하는걸 확인하지 않는 이상은 도입을 꺼린다. 좋은 방법론 1~2년쯤 늦게 도입한다 해서 프로젝트가 망하지는 않는다. 구지 리스크를 감수할 필요 없이 나 빼고 남들이 다 써서 긍정적인 효과가 명백히 드러날때에 써도 늦지 않다.

 

만약 내가 엔진이나 라이브러리나 웹, 혹은 비즈니스 로직을 주로 다루는 프로그래머였다면 대부분을 TDD 로 작성했을지 모르겠다. 하지만 나는 온라인 게임 프로그래머이고(였고) 게임에서 발생하는 상황에 대한 테스트 케이스를 작성하는 것은 쉽지 않다. 이건 숫자들의 합을 더하는 수준의 문제가 아니다. 결합도를 없애는 것만이 능사가 아니며 효율을 위해 어느정도의 관계는 분명히 유지시켜야 한다.

 

사실 TDD 라는 용어를 접하기 전부터 길찾기라던가 기타 게임 개발에 필요한 기하 문제들을 풀때는 항상 테스트를 작성했었다. input & output 이 명확한 이런 문제들을 테스트를 작성하지 않고 작업하는 사람이 정말 근성가이라고 본다.

 

3년쯤 전인가 회사의 UI 엔진을 스크립팅 가능하게 리뉴얼 하는 작업을 한 적이 있었다. 기존의 엔진은 폼 디자이너 툴만이 제공되었는데 이걸 기존 C++ 코드 & 리소스들과의 하위호환성을 유지하면서 루아 스크립팅 & 시뮬레이션이 가능하도록 만드게 목표였다. 작업은 순조로워서 엔진과 툴 모두 쓸만한 수준으로 부작용 없이 리뉴얼 할 수 있었다. 이후 UI 들은 자체 테스트를 내장한 채로 개발이 되었었다. 그런데 어떤 경우들은 테스트 작성 비용이 재현 및 디버깅 비용을 넘어서기도 했다.

 

게임 프로그래밍이란게 그렇다. input 과 output 을 명확하게 정의하기 힘들다. 시간의 흐름도 중요하고 타이밍도 중요하다. 몇몇 특정한 상태에 대한 테스트를 작성하고 유지하는것에 대한 비용은 정말이지 엄청나게 커질 수 있다. 내가 취한 방법은 대부분의 UI 들에서 테스트 작성을 포기하고, 런타임에 재현 및 디버깅이 쉽도록 한 것이었다. 키 하나로 스크립트가 모두 reload 되고, UI 가 문제 발생 이전으로 리셋되는 식이었다.

 

요약하자면, TDD 는 사실 패턴과 마찬가지로 이전부터 쓰는 사람은 모두 써왔던 방법이고, 그게 모든 분야에 사용되고 있지 않은 이유는 당연하게도 TDD 모든것에 대한 해답이 될 수 없기 때문이라고 생각한다. (난 사실 TDD 가 적용될 수 있는 분야가 매우 한정적이라고 생각한다) 문제는 이런글 (http://testors.net/tt/625)들이 귀 얇은 친구들을 혹세무민하여 주화입마에 빠지게 하는것에 있다. (이 대목에서 모 군이 찔려할것 같다...)

 

만약 TDD 가 정말로 결함을 줄여주고 개발 기간을 단축시켜 준다면 (참고: 난 이런 개발 효율이 측정 가능하지 않다고 생각한다), TDD 를 도입하지 않은것을 불안해 할 필요가 없다. 그게 사실이라면 어느샌가 당신 주변의 대부분의 개발자들이 TDD 를 사용해 프로젝트를 진행하고 있게 될거다. 그때 관심 가져도 늦지 않을것 같다.