[SI 프로젝트 TDD 실천기] 2. 통합 테스트부터 프로젝트 철수까지 느낀점

지난 [SI 프로젝트 TDD 실천기 1탄]에 이어서 실천기 2탄 써보려고 합니다. 다만 이번에는 TDD가 중심이 되기보다는 TDD를 통한 개발 스타일이 SI에서 어떻게 활용되면 좋을지, 어떤 부분에서는 활용이 어려운지를 중심으로 말 그대로 느낀 점을 전달하고자 합니다. (사실 통합 테스트부터는 테스트 코드가 중심이 되기보다는 트러블슈팅 및 개선사항 반영에 정신없어 테스트 코드 관리에 실패했습니다😭 )

 

통합 테스트

TDD의 필요성이 가장 높아지는 시기입니다. 이번 프로젝트는 특히 로그인 및 인증에서 버그가 많았습니다. 공인인증서, 휴대폰 인증, 생체인증, 카카오페이 인증 등 4개의 방법과 PC, Mobile에 따라 8개로 구분되며, 인증방법 역시 동일한 수만큼 가능했습니다. 또한 고객의 타입에 따라 비즈니스 로직도 복잡하게 얽혀 사이드 이펙트 발생이 잦았습니다.

 

아마 로그인 및 인증에 대해 테스트 코드를 미리 작성했다면, 사이드 이펙트를 빠르게 발견하고 이를 기반으로 코드의 분리도 깔끔하게 할 수 있지 않았을까 생각이 듭니다. 

 

오픈 후 안정화

안정화 기간에도 트러블슈팅은 계속되었습니다. 오픈을 위해 미뤄두었던 요구사항도 개발하기 시작했고, 웹 접근성 마크를 획득하기 위해 웹 표준에 맞는 개발을 하도록 Java Script를 대대적으로 수정하였습니다. 안정화 기간은 개발 표준은 지켜야 한다는 교훈을 얻는 시기였습니다.

웹 표준을 준수하여 개발한 개발자들은 여유롭게 보냈지만 그렇지 못한 개발자들은 매일 전쟁 같은 하루를 보냈기 때문입니다. 특히 오픈 이후에 운영서버에 배포해야 할 파일이 하루에 100개가 넘는 경우도 있어 불안에 떨면서 반영을 지켜봐야 했습니다.

 

'개발 표준을 모두가 지켰다면 오픈 이후에 이런 리스크를 감수하지 않아도 되었을 텐데...'같은 아쉬움이 남았던 시기였습니다.

 

종합평가

SI에서 TDD를 하기 어렵다는 이야기를 종종 들어왔습니다. 그래서 직접 해보는 첫 프로젝트였습니다. 우선은 직접 테스트 환경을 구축하기 위해 개발환경에 맞는 JUnit & Mockito를 설치해보는 경험과 Spring boot test를 세팅해볼 수 있었던 좋은 기회였습니다. 세간의 이야기와는 다르게 SI는 오히려 TDD를 원하고 있습니다. 다만 개발자의 TDD 이해 부족과 관리자의 필요성의 부재, 프로젝트 내 시간의 촉박함이 'SI에 TDD는 어울리지 않다'라고 생각하도록 강요하는 것 같았습니다.

 

이것에 익숙해지면 허둥대지 않고 고객의 요구사항에 유연하게 대처할 수 있다고 생각합니다. 프로젝트 초반에 여유가 있다면 테스트 코드를 꼭 만들어 보시기 바랍니다. 화면을 거치지 않는 테스트 코드는 개발자의 시간을 벌어주는 좋은 도구가 될 것입니다.

 

다만 단순한 조회성 코드에 대해서는 TDD가 갖는 한계가 명확했습니다. 변화할 가능성이 없는 코드는 오히려 테스트 코드를 작성하여 활용할 수 없어 시간을 두 배로 잡아먹는 악순환이 반복되었습니다. 물론 이마저도 테스트 코드가 없는 것보다는 있는 것이 낫지만 효율성이 낮다는 것을 인지해야 할 것입니다.

 

마치며

TDD 실천기를 적어보기로 마음먹고 쓴 글이 아쉽게도 적용하려고 노력했던 후기가 되어버렸습니다. 그래도 첫걸음을 떼었다는 생각에 마냥 슬프지는 않습니다. 다음 프로젝트에서도 사용해볼 의향이 있고, 팀원들에게 TDD에 대해 알려주고 테스트 코드의 중요성을 설파할 수 있었습니다.

 

이 글을 보는 분들도 테스트 코드를 작성해보시기 바랍니다. 기회가 오기를 기다리면 기회를 잡지 못합니다. 스스로 움직여서 기회를 만들어야 한다는 것을 기억해주시기 바라며 TDD 실천기를 마치도록 하겠습니다.

 

오늘도 이 글을 읽어주셔서 감사합니다. :)