코드를 먼저 짜고 테스트를 나중에 붙이는 방식에 한계를 느끼셨나요. 이 글에서는 테스트 주도 개발의 개념부터 실무 적용 단계까지 7가지 원칙으로 정리했습니다.
테스트 주도 개발이란 무엇이며 왜 등장했는가
처음 개발을 시작했을 때는 기능을 완성하는 것이 전부라고 생각했습니다. 요구사항대로 화면이 뜨고 버튼이 동작하면 그것으로 일이 끝났다고 여겼습니다. 그런데 프로젝트 규모가 커지고 코드가 수만 줄을 넘어가면서 상황이 달라졌습니다. 한쪽을 고치면 전혀 예상하지 못한 다른 쪽이 깨지고, 배포할 때마다 마음을 졸이는 일이 반복되었습니다. 그 무렵 팀 선배가 권해준 개념이 바로 테스트 주도 개발이었습니다.
테스트 주도 개발은 영어로 Test Driven Development, 줄여서 TDD라고 부릅니다. 이름 그대로 테스트가 개발을 이끌어가는 방식입니다. 일반적인 개발 순서는 기능을 먼저 구현하고 나중에 테스트 코드를 작성하지만, TDD는 그 순서를 완전히 뒤집습니다. 아직 존재하지 않는 기능에 대한 테스트를 먼저 작성하고, 그 테스트를 통과시키기 위한 최소한의 코드를 그다음에 작성합니다.
이 방식이 처음에는 상당히 어색하게 느껴집니다. 구현체가 없는 상태에서 테스트를 작성한다는 것 자체가 낯설기 때문입니다. 하지만 이 순서에는 명확한 이유가 있습니다. 테스트를 먼저 작성한다는 것은 곧 이 코드가 무엇을 해야 하는지를 먼저 정의한다는 뜻입니다. 즉, 테스트 주도 개발은 단순한 테스트 기법이 아니라 설계를 명확하게 만드는 방법론에 가깝습니다.
레드, 그린, 리팩터링으로 이어지는 세 단계 사이클
테스트 주도 개발의 핵심은 세 단계로 이루어진 짧은 반복 사이클입니다. 흔히 레드, 그린, 리팩터링이라고 부릅니다.
첫 번째 레드 단계에서는 실패하는 테스트를 작성합니다. 구현 코드가 없으니 당연히 테스트는 실패하고, 테스트 러너에는 빨간색 결과가 표시됩니다. 이 단계에서 중요한 것은 테스트가 반드시 실패하는 것을 눈으로 확인하는 일입니다. 간혹 잘못 작성된 테스트가 구현 없이도 통과하는 경우가 있는데, 이런 테스트는 아무것도 검증하지 못하는 껍데기에 불과합니다.
두 번째 그린 단계에서는 테스트를 통과시키기 위한 코드를 작성합니다. 이때 중요한 원칙은 최소한의 코드만 작성한다는 점입니다. 완벽하고 우아한 코드를 처음부터 만들려고 애쓸 필요가 없습니다. 심지어 값을 하드코딩해서라도 일단 통과시키는 것이 허용됩니다. 처음 이 부분을 배웠을 때 저항감이 컸던 기억이 있습니다. 하지만 실제로 해보니 이 단계는 정답을 빠르게 확인하는 과정이었고, 다듬는 작업은 다음 단계에서 충분히 이루어졌습니다.
세 번째 리팩터링 단계에서는 통과한 코드를 정리합니다. 중복을 제거하고, 이름을 명확하게 바꾸고, 구조를 개선합니다. 이때 테스트가 이미 존재하기 때문에 마음 놓고 코드를 수정할 수 있습니다. 무언가 잘못되면 테스트가 즉시 알려주기 때문입니다. 이 안전망이야말로 테스트 주도 개발이 주는 가장 큰 실무적 이점이라고 생각합니다.
테스트 주도 개발이 코드 품질에 미치는 실질적인 영향
많은 분들이 TDD를 단순히 버그를 줄이는 기법으로만 이해합니다. 물론 버그 감소 효과도 분명히 있지만, 실제로 더 큰 변화는 코드 구조에서 나타납니다.
테스트하기 좋은 코드는 자연스럽게 좋은 구조를 갖게 됩니다. 하나의 함수가 너무 많은 일을 하고 있으면 테스트 작성이 어려워집니다. 외부 의존성이 강하게 얽혀 있어도 마찬가지입니다. 테스트를 먼저 작성하다 보면 이런 문제를 구현 전에 미리 인지하게 되고, 자연스럽게 책임이 작고 명확한 단위로 코드를 나누게 됩니다. 결과적으로 응집도는 높아지고 결합도는 낮아지는 방향으로 설계가 흘러갑니다.
또 하나 주목할 점은 테스트 코드 자체가 살아 있는 문서 역할을 한다는 것입니다. 새로 합류한 팀원이 특정 모듈의 동작을 이해하려 할 때, 잘 작성된 테스트 코드는 어떤 주석보다 정확한 설명서가 됩니다. 문서는 시간이 지나면 실제 코드와 어긋나기 마련이지만, 테스트는 어긋나는 순간 실패하기 때문에 항상 최신 상태를 유지합니다. 실무에서 인수인계를 해보면 이 차이를 체감하게 됩니다.
리팩터링에 대한 심리적 부담이 줄어드는 것도 중요한 변화입니다. 테스트가 없는 코드는 손대기가 두렵습니다. 그래서 개선이 필요한 코드를 알면서도 방치하게 되고, 시간이 지날수록 기술 부채가 쌓입니다. 반면 테스트 주도 개발로 만들어진 코드베이스에서는 개선 작업이 훨씬 가볍게 이루어집니다.
단위 테스트와 통합 테스트를 구분하는 기준
테스트 주도 개발을 실천할 때 자주 혼동되는 부분이 테스트의 범위입니다. 모든 테스트를 같은 방식으로 다루면 실행 속도가 느려지거나 원인 파악이 어려워집니다.
단위 테스트는 함수나 클래스 같은 가장 작은 단위를 독립적으로 검증합니다. 데이터베이스나 외부 API 같은 의존성은 목이나 스텁으로 대체합니다. 실행 속도가 매우 빠르기 때문에 개발 중에 수시로 돌릴 수 있고, 실패했을 때 원인을 바로 특정할 수 있다는 장점이 있습니다. TDD 사이클에서 주로 사용하는 것이 바로 이 단위 테스트입니다.
통합 테스트는 여러 구성 요소가 함께 동작할 때 문제가 없는지를 확인합니다. 실제 데이터베이스에 연결하거나 여러 서비스 계층을 거치는 경로를 검증합니다. 단위 테스트가 모두 통과하더라도 조합 과정에서 문제가 생길 수 있기 때문에 반드시 필요합니다. 다만 실행 시간이 길고 환경 설정이 복잡하므로, 핵심 시나리오 위주로 선별해서 작성하는 것이 현실적입니다.
일반적으로 단위 테스트를 가장 많이 두고, 통합 테스트를 그다음, 전체 흐름을 검증하는 종단 테스트를 가장 적게 두는 형태를 권장합니다. 이 균형을 잘 잡는 것이 테스트 주도 개발을 지속 가능하게 만드는 핵심입니다.
좋은 테스트 코드를 작성하는 다섯 가지 기준
테스트를 많이 작성한다고 해서 무조건 좋은 것은 아닙니다. 잘못 작성된 테스트는 오히려 개발 속도를 떨어뜨리는 짐이 됩니다. 실무에서 검증된 몇 가지 기준을 정리해보겠습니다.
첫째, 테스트는 독립적이어야 합니다. 특정 테스트가 다른 테스트의 실행 결과에 의존하면 순서가 바뀌었을 때 예측 불가능하게 실패합니다. 각 테스트는 스스로 필요한 상태를 준비하고, 끝난 뒤에는 흔적을 남기지 않아야 합니다.
둘째, 테스트는 빠르게 실행되어야 합니다. 전체 테스트를 돌리는 데 십 분이 걸린다면 개발자는 점점 테스트를 실행하지 않게 됩니다. 느린 테스트는 결국 방치되고, 방치된 테스트는 없는 것과 다르지 않습니다.
셋째, 테스트 이름은 무엇을 검증하는지 명확히 드러나야 합니다. 어떤 상황에서 어떤 입력이 주어졌을 때 어떤 결과가 나와야 하는지가 이름만 봐도 파악되도록 작성하는 것이 좋습니다.
넷째, 하나의 테스트는 하나의 관심사만 검증하는 편이 좋습니다. 여러 검증을 한 테스트에 몰아넣으면 실패했을 때 어느 부분이 문제인지 파악하기 어려워집니다.
다섯째, 구현 세부사항이 아니라 동작을 검증해야 합니다. 내부 메서드 호출 순서까지 검증하는 테스트는 리팩터링할 때마다 깨집니다. 겉으로 드러나는 결과에 집중해야 테스트가 오래 살아남습니다.
테스트 주도 개발을 실무에 도입할 때 마주치는 현실적인 문제
이론을 아는 것과 실제로 적용하는 것 사이에는 상당한 간극이 있습니다. 테스트 주도 개발을 팀에 도입하려 할 때 흔히 부딪히는 벽들이 있습니다.
가장 자주 듣는 이야기는 시간이 부족하다는 것입니다. 실제로 초기에는 개발 속도가 눈에 띄게 느려집니다. 테스트 코드를 작성하는 만큼 물리적인 작업량이 늘어나기 때문입니다. 다만 경험상 이 비용은 유지보수 단계에서 회수되는 경우가 많았습니다. 회귀 버그를 잡는 데 쓰는 시간, 배포 후 긴급 수정에 쓰는 시간이 눈에 띄게 줄어들기 때문입니다. 물론 수명이 짧은 프로토타입이나 요구사항이 하루가 다르게 뒤집히는 초기 단계 프로젝트에서는 전면 도입이 비효율적일 수 있습니다.
두 번째 문제는 기존 레거시 코드입니다. 이미 테스트 없이 작성된 거대한 코드베이스에 갑자기 TDD를 적용하기란 사실상 불가능합니다. 이럴 때는 전체를 한 번에 바꾸려 하지 말고, 새로 추가하는 기능부터 테스트를 먼저 작성하는 방식으로 접근하는 것이 현실적입니다. 버그를 수정할 때 그 버그를 재현하는 테스트를 먼저 작성하는 습관을 들이면, 자연스럽게 중요한 영역부터 테스트가 쌓입니다.
세 번째는 무엇을 테스트해야 할지 모르겠다는 어려움입니다. 이런 경우에는 핵심 비즈니스 로직부터 시작하는 것이 좋습니다. 단순한 게터나 프레임워크가 보장하는 동작까지 굳이 테스트할 필요는 없습니다. 실패했을 때 사용자에게 실질적인 피해가 가는 부분, 로직이 복잡해서 실수하기 쉬운 부분이 우선순위가 높습니다.
언어별 테스트 도구와 환경을 선택하는 기준
방법론을 이해했다면 실제로 손에 쥘 도구가 필요합니다. 다행히 요즘은 어떤 언어를 사용하든 성숙한 테스트 프레임워크가 준비되어 있습니다.
자바스크립트와 타입스크립트 환경에서는 Jest와 Vitest가 널리 쓰입니다. 두 도구 모두 테스트 작성, 실행, 목 처리, 커버리지 측정까지 하나의 패키지 안에서 해결할 수 있어 초기 설정 부담이 적습니다. 특히 Vitest는 최신 빌드 도구와의 궁합이 좋아 실행 속도가 빠른 편이라, 사이클을 자주 돌려야 하는 TDD 방식과 잘 어울립니다. 리액트 컴포넌트를 검증할 때는 Testing Library를 함께 사용하는 경우가 많습니다. 이 도구는 내부 상태가 아니라 사용자가 실제로 보고 조작하는 요소를 기준으로 테스트를 작성하도록 유도하기 때문에, 앞서 언급한 동작 중심 검증 원칙과도 잘 맞습니다.
자바 진영에서는 JUnit이 사실상 표준으로 자리 잡고 있으며, 목 객체 처리를 위해 Mockito를 함께 사용하는 조합이 일반적입니다. 파이썬에서는 pytest가 간결한 문법과 풍부한 플러그인 생태계로 많은 선택을 받고 있습니다.
도구를 고를 때 가장 중요한 기준은 화려한 기능이 아니라 실행 속도와 피드백의 명확성입니다. 테스트가 실패했을 때 어디서 무엇이 잘못되었는지 한눈에 보여주는 도구가 좋은 도구입니다. 여기에 파일이 저장될 때마다 관련 테스트만 자동으로 다시 실행해주는 감시 모드를 함께 설정하면, 코드를 수정하는 즉시 결과를 확인할 수 있어 사이클이 훨씬 매끄러워집니다. 실무에서 이 설정 하나만 제대로 해두어도 테스트를 실행하는 빈도가 눈에 띄게 늘어나는 것을 여러 번 경험했습니다.
테스트 주도 개발을 오늘부터 시작하는 방법
지금까지 살펴본 내용을 실천으로 옮기려면 거창한 준비가 필요하지 않습니다. 처음부터 모든 코드에 적용하려고 하면 대부분 중도에 포기하게 됩니다.
가장 좋은 출발점은 작고 순수한 함수 하나를 골라 연습해보는 것입니다. 입력과 출력이 명확하고 외부 의존성이 없는 유틸리티 함수가 적합합니다. 이런 함수에 대해 레드, 그린, 리팩터링 사이클을 몇 차례 돌려보면 감각이 잡히기 시작합니다.
그다음 단계로는 새로 맡게 된 기능 하나를 통째로 테스트 주도 개발 방식으로 진행해보시길 권합니다. 처음에는 답답하고 오래 걸리겠지만, 완성했을 때 코드에 대한 확신이 이전과 다르다는 것을 느끼게 됩니다. 그 확신이 이 방법론을 계속 이어가게 만드는 원동력이 됩니다.
팀 차원에서 도입한다면 지속적 통합 환경을 함께 구축하는 것이 중요합니다. 코드가 병합될 때마다 자동으로 테스트가 실행되도록 설정하면, 테스트가 관리되지 않은 채 방치되는 상황을 막을 수 있습니다. 테스트 커버리지를 측정하되, 수치 자체를 목표로 삼지는 않는 것이 좋습니다. 커버리지를 높이기 위해 의미 없는 테스트를 양산하면 본래 목적에서 멀어지기 때문입니다.
테스트 주도 개발은 만능 해법이 아닙니다. 모든 상황에 무조건 적용해야 하는 규칙도 아닙니다. 다만 이 방식이 지향하는 가치, 즉 코드가 무엇을 해야 하는지 먼저 정의하고 검증 가능한 형태로 만들어간다는 사고방식은 어떤 개발 환경에서도 유효합니다. 오늘 작성하는 함수 하나에 테스트를 먼저 붙여보는 것만으로도 충분한 시작입니다. 그 작은 습관이 쌓이면 코드베이스의 안정성과 개발자 스스로의 자신감이 함께 성장하는 것을 경험하게 되실 것입니다.