지난 8월 7일(화요일) 이규원님이 진행하시는 TDD참관에 참석하였습니다.
처음에 규원님에게 연락왔을때는 ‘와 진짜 진행하시는 구나!’라는 놀라움과 규원님과 약간은 사적으로 볼 수 있는 자리가 될 수도 있다는 설렘(TDD는 뒷전… ㅎㅎ)으로 꼭 참석하겠다는 의사를 전달했었습니다.
해당 회차(?)에 함께하게 된 인원은 당일에 처음 만난 이종호님과 저 이렇게 두명이었으며 규원님을 사이에 두고 규원님의 모니터를 함께 보며 참관행사가 진행되었습니다.
먼저 처음엔 TDD의 생각과 궁금한점들을 서로 공유하며 간단한 지식과 서로에 대한 정보를 주고 받았습니다.
이야기가 진행되면서 자연스럽게 코드로 대화할 내용이 이어지고, 본격적으로 실전을 경험하는 시간이 이어졌습니다.
실전이라는 표현을 사용한 이유는 규원님의 회사 코드를 TDD방식으로 이슈에 대해 기능을 정의하고 테스트 케이스와 코드를 수정하여 실제 운영되는 서비스에 반영하는 일련의 개발 프로세스를 직접적으로 보여주셨기 때문입니다.
약 1시간 반에 걸쳐 TDD에 대한 의견을 주고 받으며 실제 개발에 적용하는 모습을 보면서 TDD의 사실과 오해를 느낄 수 있었고, 실전에서 충분히 사용할 수 있다라는 확신을 갖게 되었습니다.
사실 저는 지난 1년간 코드스쿼드에서 프로그래밍 교육을 받으면서 pobi(박재성 마스터), JK(김정 마스터)에게 TDD교육을 받고 실제 프로젝트에 적용한 경험이 있기 때문에 TDD의 유용함과 필요성을 알고 있었습니다.
하지만 DB나 네트워크의 접근이 생기고, UI처리가 필요한 상황 등 프로젝트 규모가 커지면서 점점 TDD적용이 버거워지면서 큰 프로젝트 혹은 실전에선 어떻게 사용하는지 배우고 싶어 참관을 신청하였습니다.
이 부분에 대해서 규원님이 대답해주신 답변은 프로젝트의 모든 부분을 TDD로 100퍼센트 커버할 필요는 없다라는 것이었습니다.
100퍼센트 커버가 불가능하다기 보다는 투자하는 시간에 비해 효율이 떨어지는 부분이 생길 수 있기에 그런 부분은 과감히 TDD를 생략하고 확신이 필요한 부분에 집중한다는 것이었습니다. 대신 Functional Test를 도입하여 해당 부분을 보완해 전체 테스트 커버리지를 높이는 전략을 활용한다고 노하우를 전해주셨습니다.
1시간반은 정말 순식간에 지나갔습니다. 다행인건 그 후 저녁을 함께할 수 있는 엑스트라 타임이 있다는 것이었습니다. 참관행사에 참여한 셋이 함께 곱창에 소주 한 잔 걸치면서 1시간 반 동안 하지 못한 이야기를 주고 받으면서 좀 더 사적인 어쩌면 진솔한 대화의 장을 풀어나가면서 행사가 마무리 되었습니다.
규원님이 저희 둘에게 다른 사람에 비해 질문이 적다는 얘기를 해주셨는데, 종호님의 경우 1시간반 진행을 하면서 그동안 궁금했던 부분이 많은 부분 해소되어서였고, 저는 TDD에 대해선 코드스쿼드에서 배웠었고, 지금 회사에 들어온지 갓 1주일 지난 상황이었기에 코드 파악이 완전하지 않아서였던 것 같습니다.
그 부분은 좀 아쉬웠지만, 같은 건물에서 근무하고 저희 회사에선 Functional Test를 도입하기 위해 준비하고 있기 때문에 다음에 기회를 만들어 찾아뵙기로 후일을 기약했습니다.
TDD에 관한 이야기 혹은 이규원님과 대화를 나누고 싶은 분에게 이 행사를 추천 합니다.
행사는 당분간 더 진행하실 것 같아 링크(참관신청)를 남겨둡니다.
개발하는 모습을 집접 옆에서 보기때문에 TDD뿐 아니라 Tool사용 및 이슈관리 등 개발자에게 유용한 팁 등을 간접적으로 체험할 수 있기에 저에겐 특히 유용했던 것 같습니다. (블로그 링크로 좋은 정보도 직접 전달해 주시는 걸 보고 블로그 활성화에 대한 의지도 다시 생겼네요 ㅎㅎ)
간략히 참관행사에 대한 정보를 요약하자면:
- 위 링크에서 참관 신청을 하면 댓글 순서대로 2명씩 초청됩니다.
- 약 1시간 30분 정도 이야기를 주고 받으며 개발 과정을 보면서 TDD를 체험하실 수 있습니다.
- 못다한 얘기 혹은 궁금한 사항들을 저녁식사자리를 이용해 추가로 더 나눌 수 있는 기회가 있습니다.
마치며
TDD를 잘 적용하기 위해선 좋은 설계가 필요하다는 것을 배웠습니다.
TDD를 통해 설계를 개선하기 보다 좋은 설계를 통해 TDD를 적용하는 것에 문제가 없도록 하는 것이 중요한 포인트라는 규원님의 조언은 결국 좋은 설계를 위해 끊임없이 생각하고 변화에 유연한 코드를 작성하는 것이 얼마나 중요한 것인지 깨닫는 계기가 되었습니다.