금요일에 회사에서 Test Driven Development에 대해 소개하는 세미나를 했다.
내가 다니는 회사에서는 한달에 한번씩 프로그래머가 세미나를 진행하는 이벤트(?)가 있다. 저번달 세미나가 끝나고 다음 세미나를 누가 할지에 대해 결정해야 하는데, 보통 서로 잘 하려고 하지 않는다.
그도 그럴 것이 세미나 준비는 상당히 귀찮은 일인데다가 시간도 들고 또 많은 사람들 앞에서 발표를 하는 것이 보통 프로그래머들의 내면 지향적인 성격과는 상당히 맞지 않아서일게다. 약간의 보상은 있긴 하다.
그런데 이번에는 왠지 내가 하고 싶었다. 그 당시에는 - 그러니까 저번 달 초 - '프로그래밍 심리학'이라는 책을 읽고 있던 때였는데, 프로그래밍과 인간의 심리와의 관계를 다룬 고전이었다. 나온지 40년이나 된 책이라서 말은 고전이라지만 그 내용은 지금 봐도 별로 어색한 감이 없었다. 오히려 프로그래머는 '프로그램을 만드는 기계'로 취급되는 지금은 현실은 40년 전에 비해 크게 나이지지 않았다는 사실을 깨닫게 해주었다. 한번 읽어보길 권한다, 정말 재미있다.
그래서 프로그래머의 심리적 요인이 개발에 얼마나 지대한 영향을 미치는지에 대해 강연하기 위해 세미나를 맡겠다고 했다. 그러면 사람들이 좀 더 자신과 남들의 마음을 이해하고, 더 즐거운 마음으로, 그리고 서로에게 상처주지 않으며 개발을 할 수 있게 될 것이라고 생각했기 때문이다.
그러고 나서 며칠 뒤 그러다가 팀원들과 식사를 하다가 세미나 내용에 대해 이야기가 나왔다. 다들 물어보길래 프로그래밍 심리학에 대해 하겠다고 하면서 이런 저런 이야기를 하다가 TDD - Test Driven Development - 를 세미나로 하면 어떨까 하는 생각을 던져봤는데 갑자기 팀원들이 그게 더 낫겠다고 입을 모아 이야기했다. 헉 이런... 프로그래밍 심리학에는 다들 별로 관심이 없는건가?
결국 대중의(?) 의견을 따라 TDD를 세미나 주제로 정했다. 사실 처음에도 프로그래밍 심리학과 TDD 중 어떤 것을 주제로 할까 고민하고 있었던 참에, 남들이 더 관심을 가지는 내용을 하는게 맞겠다고 생각했기 때문이다.
당시에는 나 또한 TDD라는 것에 관심을 가진 지 얼마 되지 않은 시점이었다. TDD 세미나 준비를 하면서 느낀 것은 남들에게 어떤 것을 가르치기 위해서는 나의 이해도와 경험이 청자보다 훨씬 뛰어나야 한다는 점이었다. 어떤 지식을 남에게 전달하는 것은 그 사람에게 내가 알고 있는 것을 이해시키고 경험을 전달하는 것인데, 나조차도 정확하게 경험하지도 이해하지도 못하면 어떻게 가르칠 수 있을까. 따라서 내가 TDD를 해보고 느끼고 배우는 것이 곧 세미나를 성공으로 이끄는 길이라고 생각했다.
처음엔 쉽지 않았다. 시작해보자는 생각은 했지만 마치 C를 처음 배우는 학생처럼 막막하기만 했다. 켄트 백의 '테스트 주도 개발'이라는 책을 읽고, 웹에서 TDD를 경험해본 사람들의 경험담을 뒤적거리기 시작했다. 특히 김창준님의
애자일 이야기 블로그에 포스팅되었던
관련된 글의 경험담이 인상적이었다. 알고 보니 김창준님은
동영상까지 찍으셨다!
잡설: 재미있게도 구글에서 '김창준'을 검색할 때와 네이버에서 '김창준'을 검색할 때의 결과가 아주 다르다.
C/C++에서의 TDD는 Java에 환경이 훨씬 열악한 것 같다. 그 중에서는 언어적 특성도 한 몫을 하지만, TDD 관련된 서적과 자료가 대부분 Java를 중심으로 되어 있다는 점이 그것이다. 특히 IDE의 지원도 역시 달랐는데, JUnit + Eclipse 조합으로 볼 수 있는 '빨간 막대'와 '녹색 막대'를 Visual Studio에서는 볼 수 없다는 점이 아주아주아주!! 싫었다(현재는 극복한 상태다). Visual Studio에서는 테스트 결과를 검은 배경에 흰색 글자가 찍힌 콘솔로 봐야 했다.
나중에 찾아낸
GoogleTest는
콘솔로 찍어줄 때 글자색이 빨간색과 녹색으로 나온다는 점에서 그런 갈증을 어느 정도 해소해 준다는 점에서 정말 좋았다. 역시 구글이다는 생각이 절로 들었다.
막대 표시해주는 Add-in 찾는 데만 며칠을 썼던 것 같다. 그 중 찾아낸 것이
쑥갓님의
vutpp이다. 이것을 발견한 뒤에야 비로소 첫번째 테스팅을 작성할 수 있었다. 그만큼 Java 유저들이 막대를 보며 느끼는 재미를 나도 느껴보고 싶었던 것이다.
두번째로는 어떤 테스팅 프레임워크를 쓸까 하는 고민을 했다. 이것도 역시 며칠을 소비했다. Noel이라는 사람이
테스팅 프레임워크 6종 비교를 해둔 기사를 보고 고민 끝에 첫 테스트 코드를
CppUnitLite로 작성했다. 가장 쉽고 작으며 내 입맛대로 수정이 가능한 테스팅 프레임워크였다.
그런데 한계가 금방 왔다. 처음에는 몇 가지 테스트를 하면서 재미를 보다가, 테스트가 늘어나자 중복되는 코드가 있어 이것을 묶어주는 Fixture라고 불리는 것이 없었기 때문에 직접 구현해줘야 했다. 또 테스트를 내가 원하는 것만 실행하고 싶을 때가 있는데, 이런 기능이 없었다. 다른 프레임워크에서는 대부분 지원해주기 때문에, 또다시 CppUnitLite 보다 더 나은 테스팅 프레임워크를 찾아 떠돌았다. 그리고 아직 녹색 막대는 포기하지 않은 상황이었다.
그렇게 발견한 것이
Visual Assert였다. Visual Studio와 통합되는 전용 Add-in으로 막대를 볼 수 있었을 뿐만 아니라, Fixture도 지원하고 원하는 테스트만 실행할 수도 있었다! 그렇게 다시 행복을 맛보던 찰나... 한계가 다시 찾아왔다. 이번에는 테스트가 실패해도 다음 테스트를 그냥 진행할 수 있는 기능이 없었던 것이다. 이래가지고는 테스트가 하나만 실패해도 그 뒤쪽에서 기다리는 테스트들은 모두 실행될 수 없게 되어버린다.
결국 마지막으로 찾은 것이 GoogleTest. MS MVP이신
김용현님의 추천이 있었다. 사실 처음에 추천해주셨을 때는 '막대'를 못본다는 점 때문에 별로 신경을 쓰지 않았다. 하지만 상황이 이렇게 되자 다시 기억이 났다. "아, 이걸 한번 써보자!"
써본 결과는 대만족이었다. 딱 하나, Visual Studio에서 막대를 볼 수 없다는 것만 빼면 내가 필요한 기능이 다 들어있었다. 이미 막대는 볼 만큼 봤기 때문에 더 이상 미련을 갖지 않았다. 그리고 텍스트에 색깔이 들어있다는 점에서 어느 정도 만족했다. 이정도면 정말 만들어 준 사람들에게 고맙다는 인사라도 한번 해야 할 것 같다. Thank you!
그리고... 이윽고... 드디어, 세번째 문제가 왔다. 이 문제야 말로 정말 사람프로그래머을 환장하게 하는 문제인데, 바로 Legacy Code라는 놈이다. 현재 진행 중인 프로젝트에 적용하려고 하니 그야말로 시작부터 문제였다. 한발자국도 앞으로 나아갈수가 없었다. 레거시 코드의 종속성은 내 상상을 초월할 정도로 뿌리깊었다. 소스 코드를 몇 시간동안이나 살펴봤지만 대체 어떻게 테스트 코드를 만들어야 할 지 머릿속은 새하얗기만 했다.
단 한개의 메소드만 테스트하려고 해도, 객체를 생성하고 초기화하는 과정에서 제공해줘야 하는 다른 객체가 너무나도 많았다. 환경 설정을 읽어오는 객체는 실제로 환경 설정 파일에 접근하고 있었고, 프로세스 간 통신을 담당하는 객체는 정말로 다른 프로세스를 찾아 연결시켜주는 역할을 했다. 하지만 테스트 과정에서 진짜 환경 설정 파일과 다른 프로세스를 제공해줄 수는 없었기 때문에 테스트 코드 자체가 나올 수 없었다.
물론 Mock Object라는 것을 사용하면 이런 것도 테스트할 수 있다는 점은 이미 알고 있었지만, 문제는 경험이었다. C를 처음 접할 때 포인터라는 것을 배우는 것과 같다. 포인터를 책에서 보고, 정의를 읽고, 사용법을 보고, 예제를 보아도 책을 쓴 사람은 이 정도면 알아들었겠지? 라고 생각했을지 모르나, 배우는 입장에서는 중학생에게 미적분을 보여준 것과 비슷한 얼굴을 하게 될 것이다.
너무나도 막막한 나머지 나는 그야말로 gg를 쳤다. 망했어요~
TDD가 좋다고 알고 있고 아무리 강조해도 무슨 소용인가! 레거시 코드 앞에서 TDD를 도입한다는 것은 쉽지 않다 정도가 아니라 불가능에 가까워 보였다. 주변 사람들에게 TDD라는 걸 써보자고 했을 때 다들 보였던 반응이 그것이었다. 기존 코드에 어떻게 적용할 것이냐고.
일단은 세미나 날짜가 되어서 세미나를 진행했다. 세미나는 TDD의 '실전'이 아니라 '소개'에 중점을 두었다. 이 월례 세미나는 모든 개발자가 의무에 의해 참석하는 것이기 때문에 대부분의 사람들이 TDD에 관심이 없을 가능성이 높다는 것은 알고 있었다. 만약 TDD의 심화 과정을 다뤘다면 - 사실 지금 그정도 내공도 안되지만 - 모두들 세미나 시간에 쓰러져 잤을 것이다. 그래서 전통적인 개발의 단점은 무엇인지, TDD가 어떤 점을 해소해 줄 수 있는지, 어떤 점이 좋은지대 대해 집중적으로 설명하고, 마지막으로 아주 간단한 예제 - 자판기 - 로 시연을 진행했다.
이번 세미나로 최소 한 명 이상이 TDD에 관심을 가지고 첫번째 테스트 코드를 작성해본다면 나는 성공했다고 생각한다.
세미나는 끝났지만, 나의 깊은 고민은 아직 끝나지 않았다. 레거시 코드... 대체 어떻게 해야 할까? 리팩토링에 대한 책도, 패턴에 대한 책도 다시 한번씩 읽어봤지만 별로 도움이 되지 않는다. 이론과 실전이 이렇게나 다를 줄이야.
결국
Working Effectively with Legacy Code, 일명 WELC 원서를 주문했다. 번역판이 있긴 한데
발번역이라고 해서 차라리 원서를 보기로 결정했다. 왠만큼 MSDN을 보고 구글링을 하다 보니 이제 영어도 별로 무섭지 않다.