TDD(테스트 주도 개발), 왜 중요할까?

시니어 개발자가 바라보는 TDD에 대해 궁금하시다면 주목해주세요. 
Jul 24, 2024
TDD(테스트 주도 개발), 왜 중요할까?
 
🌊
항해 플러스는 매주 발제 형식으로 코스가 진행되는 것 알고 계셨나요? 이번에 새롭게 선보이는 <Weekly 항플>는 항해 플러스 백엔드 & 프론트엔드 코스에서 실제로 제공되는 발제 내용 중 일부를 담고 있습니다. 최신 개발 트렌드, 빅테크 시니어의 생생한 의견이 담긴 내용을 다룰 예정이니, 성장하고 싶은 주니어 개발자분들은 주목해주시기 바랍니다.
 
 

시니어 멘토의 생각 : Why TDD?

1) TDD, 왜 중요할까?

개발해야 되는 스코프가 점점 더 많아지고 거대한 규모의 소프트웨어가 많아짐에 따라, 유지 보수 및 장애 발생 시 대처를 유연하게 할 수 있는 방법론으로 다들 회귀하기 시작했습니다. 즉, 코드의 규모는 점점 커지고 유저가 많아짐에 따라 예측하기 힘든 행동 패턴들에 의한 장애가 발생하기 시작한 거죠.
소위 새로운 기능을 만들기 위해 “요구사항을 찍어낸다” 식의 단순 재래식 개발로는 소프트웨어의 품질을 지속적으로 유지하고 향상시킬 수 없었기에 테스트 자동화에 대한 중요성은 점점 대두되어 왔습니다. 요구사항이 변경되었을 때, 기존의 기능이 영향이 없는가? 등을 검증하기 위한 방법론들이 주목받지 못하고 있다가 빠른 변화에도 유연하게 새로운 기능을 적용하고 변경할 수 있는 기반을 다질 수 있는 TDD에 대한 중요성이 더욱더 중요해지고 있습니다.
 

2) 현업에서의 TDD란?

사람마다 생각하는 스코프가 조금 천차만별인 경우가 많은 것 같습니다. 이는 현재 본인의 일하는 환경에 따른 영향, 조직의 업무량과 방식 등이 매우 상이하기 때문인데 특히 테스트에 대한 중요성과 작성 여력이겠죠. 그래서 저는 어떤 조직에 합류하던 최대한 작성하려는 기능을 분석 후 핵심이 되는 테스트 코드부터 작성하고 이를 완성하기 위해 적용된 아키텍처에 맞는 기능 개발을 진행합니다. 그리고 모든 테스트를 완료하는 순간, 목표한 개발 스코프가 종료되었다는 기준으로 테스트 주도 개발을 진행합니다. 작업 여건 상 짧게 개발하고, 테스트해보고 실패하면 리팩토링하는 방식을 취하는 대신에 분석/설계 단계에서 테스트 코드를 면밀히 작성해두고 모든 TC 성공 시엔 개발 컨텍스트를 완료하는 방식을 취하고 있습니다.
 

3) 항해 플러스에서 TDD에 대해 알게 되는 것들

백엔드 개발자로서, 요구사항을 분석하고 기능을 올바르게 완성하기 위한 TC를 작성하는 방법을 익힙니다.특정 문제 상황에 대해 올바른 기능을 제공하기 위해서 어떤 테스트케이스를 단계적으로 작성해나갈 수 있는지, 점진적으로 우리가 작성한 기능을 리팩토링하며 올바른 백엔드 서비스를 제공할 수 있는 방법을 익힙니다. 또한 테스트 코드를 잘 작성할 수 있는 소프트웨어의 구조 등을 고민해보고 이를 적용해 요구사항에 맞는 백엔드 서비스를 개발해 봅니다.
 
 
 

시니어 멘토의 답변

Q : 요즘 Clean , Hexagonal , Vertical Slice 등 다양한 아키텍처에 대한 이야기가 들려옵니다. 이런 것들을 이용해 볼 수는 없을까요?
A : 물론 가능합니다! 클린 아키텍처는 DDD 기반으로 도메인 중심의 설계에 효율적이며 헥사고날 아키텍처는 보통 잘게 나눈 도메인에 기반한 MSA에 효율적인 아키텍처입니다. 이는 실제로 SOLID 원칙을 잘 지킨 하에, 레이어드 아키텍처와 함께 녹여내어 현업에서 사용하는 아키텍처입니다. 그래서 러닝 커브로 인한 프로젝트의 지연보다는, 먼저 기본에 충실한 구현을 진행하고 차후 리팩토링 등을 통해 고도화된 아키텍처의 도입을 시도해 보는 것을 추천드립니다.
 
Q : TDD 가 아닌 DDD로 개발하는 것은 안될까요?
A : DDD 와 TDD는 같은 범주로 묶이는 개발론이 아닙니다. DDD는 기존 DB 테이블 중심적으로 설계하고, 서비스를 구성하는 방식보다 요구사항에 대해 도메인을 명확히 분석하고, 도메인이 주체가 되도록 기능을 개발하는 방식을 의미합니다. 즉, 설계론 적인 의미에서 더 많은 이점을 찾고자 하는 개발론이죠. TDD는 개발하는 방식을 테스트적인 관점에서 바라보는 방법론입니다. 이에 DDD로 개발할 때는 각 도메인의 컨텍스트를 보다 명확하게 정의하고, 기능을 단순화하고 정확하게 표현할 수 있어야 합니다.
A : 위에 설명한 바처럼 오히려 DDD 기반의 설계와 구현에 대해 익숙하고 잘 정의되어 있다면 TDD 방법론을 이용해 개발을 진행하기에 오히려 적합한 구조를 갖출 수 있다고 생각해요. TDD는 각 기능에 대해 작은 단위로 구성하고 Unit Test부터 잘 작성해나가며 빠른 주기로 개발/테스트/리팩토링을 반복해나가며 기능을 완성해나가는 방식인데, 도메인이 잘 정의되어 있고 기능에 대한 책임이 명확히 나누어져 있다면 더 빠른 개발을 진행할 수 있습니다.
 
 
💡
뉴스레터 <Weekly 항플>에서는 블로그 아티클보다 더 심층적인 내용을 다루고 있습니다. 항해 플러스 합류를 고려하고 있거나, 더 깊이 있는 학습을 원하는 주니어 개발자라면, 뉴스레터 <Weekly 항플>을 구독하여 더 많은 내용을 받아보시기 바랍니다.

👉 뉴스레터 <Weekly 항플> 구독 신청하기

 
 
 

🚢 개발자 이직 준비, 어떻게 시작해야 할지 모르겠나요? 한 단계 더 도약하는 험난한 항해에서 든든한 메이트가 되어드리겠습니다.

항해 플러스는 성장의 한계를 느끼고 있는 주니어 개발자를 위해 만들어진 실무 역량 강화 코스입니다.
기본기 역량 강화부터, 커리어 점프시켜 줄 TDD / 대용량 트래픽 처리 or 장애 대응 프로젝트와 이직 코칭까지 한번에 할 수 있습니다. TDD에 관심이 있는 백엔드 주니어라면 TDD와 클린 아키텍처 기반 서버 구축 프로젝트를 경험할 수 있는 항해 플러스 10주 성장 코스로 이직을 도전해보세요.
 
Share article
RSSPowered by inblog