안녕하세요 졸린 개발자입니다.
최근 카카오 테크 블로그의 TDD 정리글을 보게 되면서,
제가 가지고 있는 TDD에 대한 생각도 같이 공유하는건 어떨까 해서 글을 작성하게 되었습니다.
결론부터 말씀드리자면 TDD는 분명 좋은 점이 많은 구현방법이지만,
모든 상황에서 100% 활용가능한 실버불릿은 아니라는 말씀을 드리고 싶습니다.
TDD는 스펙에 대한 테스트를 먼저 작성해서
스펙을 온전히 반영할 수 있는 코드를 지향하는 것에 초점이 맞추어져 있습니다.
덤으로 코드의 문서화 기능도 가지고 있구요.
반대로 말하면, 스펙에 대한 모든 테스트를 작성해야한다는 것을 의미합니다.
그러면 테스트를 왜 작성해야하는걸까요?
기능이 잘 동작함을 보장하기 위해서입니다.
그럼 이쯤에서 한번 생각해보죠.
현재 어떤 서비스를 사용하는 유저가 월 100명의 스타트업이라고 가정해봅시다.
제가 만약 위 조직에 속했는데, 한 팀원이 TDD를 도입하자고 하면
저는 반대할것 같습니다.
그 이유는 결국 Money입니다.
100명이 쓰는 서비스라고 가정했을때 1%의 유저만 영향을 미치는 버그가 나왔으면, 1명만 영향을 미치게 되는거고
그 1명에게 문제가 생겼으면, 그 1명에게는 돈으로 피해보상을 해주면 될 것입니다.
그동안 빠르게 개발을 해서, 100명~1000명의 다른 추가적인 많은 유저들을 끌어모으는게 더 회사에 이득일 것입니다.
그럼 반대로 큰 회사라고 생각해보죠.
10만명이 쓰는 서비스에서 1%의 유저만 영향이 미치는 버그가 나왔으면, 1000명이 영향을 미치게 되는것이니
기업 이미지 측면에서나, 실제 피해 보상을 해주는 측면에서나, 기업의 소모값은 대단할 것입니다.
전국민이 사용하는 카카오같은 대기업이면 더욱더 안정성을 생각할 수밖에 없죠.
대규모 시스템에서는 추가 기능개발만큼 시스템을 안정적으로 유지하는 것도 중요합니다.
결국 리소스를 어디에 쏟을 것이냐에 대한 트레이드 오프입니다.
안정적인 코드 개발 vs 단기간의 빠른 개발
혹자는 이렇게도 말씀하실 수도 있습니다.
코드를 읽는 시간이 90%고, 실제 작성하는 시간이 10%니까,
TDD를 통한 문서화가 더 빠른 개발속도를 가져갈 수 있지 않느냐?
물론 맞는 말씀입니다만, 100명 정도의 유저를 가진 스타트업은 보통 백엔드 개발자는 많은 숫자가 있지는 않습니다.
많아봤자 3명정도겠지요. 그 정도면 거의 대부분 자기가 작성한 코드이거나, 모든 백엔드 개발자들이 코드리뷰를 거치면서 한번씩은 본 코드입니다.
더군다나 그정도 규모의 스타트업이면, 기존 코드를 작성하는 것보다 완전히 새로운 기능을 만드는 것도 부지기수입니다.
따라서 90:10 이 아닌, 50:50정도도 가능하겠죠.
혹시나 해서 말씀드리는 것이지만, 저는 기능이 제대로 동작하지 않는 서비스를 배포하자는 말씀을 드리려는 것은 아닙니다.
서비스라면 기능에 대한 정상동작을 보장하는 것은 당연한 얘기입니다.
제가 다니고 있는 스타트업에서는 빠른 기능 개발을 위해 TDD를 사용하지는 않고,
테스트는 작성을 하고 있습니다. 최소한의 품질 보증은 해주는 것이죠.
다만 TDD이 제공하는 만큼의 코드 안정성은 포기하고 있습니다.
대신 QA를 하시는 분이 계십니다.
기능을 완성하면 QA 엔지니어분의 최종 테스트가 되기 전까지는 기능을 나갈 수가 없습니다.
기능에 대한 정상동작을 QA엔지니어가 보장해주는 것이죠.
하지만 QA엔지니어도 사람이라, 당연히 서비스가 스펙을 100% 준수한다라는 보장을 해줄수는 없습니다.
그 정도의 구멍은 돈으로 해결할 수 있는 정도의 규모이기 때문에, 빠른개발을 위한 리소스 트레이드 오프를 선택한 것이죠.
TDD는 분명 좋은 개발 구현 방법입니다.
안정적인 코드를 작성하는건 모든 개발자들의 워너비 코드겠죠.
하지만 회사에 속한 회사원이라는 입장에서 보면,
회사가 현재 어떤 것에 리소스를 할당해야하는지에 따라,
어떻게 기능을 구현할지도 달라지는것 같습니다.
그에 따라 TDD를 할것인가 말 것인가도 선택을 해야하겠죠.
결론을 지어보자면
1. TDD는 안정성을 보장해주는 좋은 개발 방법이다.
2. 하지만 모든 회사가 안정적인 코드 개발이 목표는 아니다. 빠른 기능 개발이 우선인 회사들도 있다.
3. 자신의 회사가 어떤 상태인지에 따라 TDD를 선택하자.
제가 하는 말이 모두 맞는 말은 아닌 것을 잘 알고 있고,
제 개인적인 말씀을 한번 드려봤네요.
혹시 이 글을 읽으시는 분들은 회사에서 TDD를 적용하고 계신지
왜 TDD를 적용하시는지를 공유해주시면, 저의 짧은 견식에 도움이 될 것 같습니다.
긴 글 읽어주셔서 감사합니다.