월간 지앤선

'TDD 잘알못을 위한 돌직구 세미나' 참관기 - 그 남자와 그 여자의 사정

남자 편

글 - 강대명 님


- 길을 아는 것과 그 길을 걷는 것은 분명히 다르다. (모피어스, 매트릭스) 

청포도가 익어갈 2018년 6월의 어느 날에, "TDD 잘알못을 위한 돌직구 세미나" 가 열렸습니다. 네이버, NHN 넥스트들을 거쳐서 지금은 NextStep이라는 1인 교육 사업을 시작하신 자바지기 박재성님과 Envicase의 CTO이신 정진욱님, 오마이트립의 지옥에서 돌아온 CTO이신 이규원님이 TDD에 대한 세미나를 연다고 해서, 알바로 명을 받고 당당하게 이브레인에 잠입했습니다. 


두 개의 30분짜리 세션과, 한시간 반 정도의 토론 세션을 꾀는 줄기 하나는... 위에 언급한 것처럼 "길을 아는 것과 그 길을 걷는 것은 분명히 다르다."입니다. TDD는 Test Driven Development의 약어로, 테스트를 먼저 작성하고(Test First라고 한다고 합니다.) 이를 성공시키는 코드를 짜면서 기능을 개발하는 방식을 말합니다. 요구사항이 명확해지는 효과가 있다고 하네요. (전 입개발이라 이런 걸 모릅니다.) 그런데 공통적인 얘기가 이게 쉽지 않다고 것입니다. 의식적으로 연습을 많이('많이'를 강조합니다.) 하지 않으면, 어렵다고 하네요. 



자바지기님의 첫 발표

초반 내용은, 이거 하다가 실패, 저거 하다가 실패하셨지만 볼링 게임 점수판이라는 순수한 자바 프로그램을 통해서 연습을 반복하면서 어느 정도 TDD에 대한 깨달음을 얻으셨다고 것이었습니다. 자바지기 박재성님의 세션은 "조급하지 말고 천천히, 그러나 꾸준히"로 요약이 됩니다. 언급하신 볼링 게임 점수판은 10번 이상 TDD 연습을 통해 개발을 하셨답니다(당연히 가장 마지막이 맘에 든다고). 그리고 매번 의도적인 과제를 부여하고 이를 통해서, 연습을 하셨다네요. 예를 들어, 첫 번째로는 오직 한 단계 들여쓰기만...(강제로 함수를 나누도록) else를 쓰지 않는다는 등으로...(어려워요.) 


두 번째 Envicase의 CTO이신 정진욱 님의 발표

약간 콜럼버스의 달걀과 같은 느낌이었습니다. 테스트하기 쉬운 코드로 개발 하자라니...(우리가 몰라서 안하는 것이였던가!!! T.T) 일단 TDD도 자전거 타기 처럼, 단순히 암기가 아닌 연습을 통해서 체화되는 것이 중요한 것이라는 명언을 던지고, 테스트 시의 장애물에 대한 설명을 해주셨습니다. 일단 테스트 시의 장애물은 불확실성과 Side Effect인데, 변하는 값을 읽어오게 되면서 생기는 이슈, 결국 외부 데이터에 의존성이 생기는 것(이를 외부에 대한 IO로 표현을 하셨습니다.), 이런 것들이 테스트하기 어려운 이유라고 설명을 해주셨습니다. 그래서 테스트를 쉽게 하기 위해서, 최대한 외부에 의존하는 코드를 분리해서 개별적인 테스트를 적용하는 걸 권장 하셨습니다. 그런데 이렇게 되면 결국은 외부랑 연결되는 코드를 테스트를 해야 하는데요. 이를 위해서 Bounded Layer라는 개념으로 호출하는 부분에서 최대한 가장 바깥 쪽에서 이를 테스트하는 것을 이야기 해주셨네요. (설명이 어려운데, 내가 호출하는 쪽 가장 밖에 의존적인 코드를 들고 있고, 그 하위는 테스터블한 코드가 있도록... 왜냐하면 테스트하기 어려운 코드에 의존하는 모든 코드는 테스트하기 어려운 코드가 되고 말기 때문인데요.) 이 때, Test Double(여기서 Double은 대역을 뜻합니다.), 즉 Dependency Injection 등을 통해서 테스트할 수 있는 대역을 끼어 넣는거죠. 결국 이런식으로 테스트하기 쉬운 코드를 최대한 만들어서 테스트를 하는것이 좋은 방법이라는 얘기였습니다. 



이규원 and 박재성 and 정진욱 토론

마지막으로 지옥에서 돌아온 CTO님인 이규원님과 박재성님, 정진욱님의 질문 토론이 이어졌습니다. 토론에서 제 귀를 때린 가장 중요한 것들 중에, '아 용어를 잘 정리해야겠구나.', '다들 ATDD와 통합테스트를 헷갈려하고 있는 ㅎㅎㅎ' (저만 그렇습니다만...) 몇 가지 좋은 용어들을 들었는데, Characterization Test (https://en.wikipedia.org/wiki/Characterization_test)라는 것이 기억에 남습니다. 기존 레거시를 이용하다 보면 테스트 케이스를 만들기 어려운 경우가 있는데, 이 방법은 반대로 기존 소프트웨어의 결과 값을 기록해서 테스트를 만듭니다. 예를 들어 해당 API는 1이 들어가면 2가 나온다. 2가 들어가면 3이 나온다. 이런 식으로 확인할 수 있는 테스트 코드를 만들어 두는 겁니다. 실제로 2010년 경에 네이버 메일 시스템 개선을 위해서, 팀 동료분이 테스트를 만드셨는데, 기존 시스템에 대해 모든 입력값과 출력값을 이용해서 테스트 케이스를 만드셨는데, 그게 이 방법이었던... 


재미난 건 지옥에서 돌아온 CTO님은 절대로 TDD를 강요하지 않는다고 하셨습니다. 그리고 더 재미난 건 세 분 모두, TDD가 좋은 디자인을 가지게 도와주는 것은 아니고, 크게 관련성이 없다는 얘기를 하셨는데... 저같은 TDD 잘알못은 흑흑흑 어려운 토론 시간이었습니다. 다음에 이런 시간이 있으면 그 때는 코드를 깊게 보면서 질문을 드리고 싶네요. 결론적으로 다시 한 번 길을 아는 것과 그 길을 걷는 것은 분명히 다르다는 것... 


마지막으로 이 글을 준비하면서 본 이규원님의 명언 "TDD에 대해서 오해하는 것은 TDD가 어렵다는 것이다. 사실 TDD는 매우 매우 어렵다" 를 적으면서, 이상 지앤선 알바 응봉동 입개발자 강씨였습니다.