소프트웨어 개발에서 테스트는 더 이상 '개발 후 검증' 단계에만 머무르지 않습니다. 현대적인 애자일 개발 프로세스에서 테스트는 코딩보다 앞서서 개발을 이끌고, 팀의 소통을 증진시키며, 살아있는 문서의 역할을 하는 핵심적인 활동으로 진화했습니다.
이러한 '테스트 우선(Test‑First)' 접근법의 중심에는 TDD, ATDD, BDD라는 세 가지 중요한 개발 방법론이 있습니다. 이들은 종종 혼용되거나 그 차이가 모호하게 느껴지지만, 각각의 목표와 관점은 뚜렷하게 다릅니다. 이 글에서는 세 가지 방법론의 핵심 철학을 파헤치고, 이들이 어떻게 상호 보완적으로 사용될 수 있는지 알아보겠습니다.
1. TDD (Test‑Driven Development): 개발자의 내면을 향한 대화
TDD, 즉 테스트 주도 개발은 가장 근본적인 '테스트 우선' 개발 방법론입니다.
- 핵심 철학: 실패하는 테스트를 먼저 작성하고, 이 테스트를 통과하는 최소한의 코드를 만든 후, 코드를 리팩토링한다.
- 초점: 개발자 관점. 코드의 내부 설계와 품질을 점진적으로 개선하는 데 집중합니다. 주로 단위 테스트(Unit Test) 레벨에서 이루어집니다.
🔄 TDD 사이클: Red → Green → Refactor
| 단계 | 설명 |
|---|---|
| Red (실패) | 아직 존재하지 않는 기능에 대한 실패하는 테스트 코드를 먼저 작성합니다. (예: add(2, 3)가 5를 반환하는지 검증하는 테스트) |
| Green (성공) | 이 테스트를 통과시키는 가장 간단하고 빠른 방법으로 실제 코드를 작성합니다. (예: return 5; 같은 하드코딩) |
| Refactor (리팩토링) | 테스트가 통과하는 것을 확인한 후, 코드의 중복을 제거하고 구조를 개선합니다. (예: return a + b;로 일반화) |
TDD는 개발자가 “지금 무엇을 만들어야 하는가?” 를 명확히 정의하게 하고, 작은 성공을 반복하며 설계를 단단히 다지는 내적(Inner) 개발 루프입니다.
2. ATDD (Acceptance Test‑Driven Development): 고객의 기대를 코드로 번역
ATDD, 즉 인수 테스트 주도 개발은 TDD의 개념을 시스템 전체 기능 수준으로 확장합니다.
- 핵심 철학: 비즈니스 관점의 인수 조건(Acceptance Criteria) 을 만족하는 테스트를 먼저 작성하고, 이를 통과하는 시스템을 만든다.
- 초점: 고객/사용자 관점. 시스템이 무엇(WHAT) 을 해야 하는지 검증합니다. 주로 인수(E2E) 테스트 레벨에서 진행됩니다.
🔄 ATDD 사이클
| 단계 | 설명 |
|---|---|
| Discuss | 고객·기획·개발·QA가 인수 조건을 토론하고 명확히 합니다. |
| Distill | 토론된 내용을 실행 가능한 테스트 케이스로 구체화합니다. |
| Develop | 인수 테스트를 통과하도록 기능을 개발합니다. (개발자는 내부적으로 TDD 사이클을 돌릴 수 있습니다.) |
| Demo | 기능이 인수 테스트를 통과함을 고객에게 시연하고 피드백을 받습니다. |
ATDD는 “우리가 올바른 제품을 만드는가?” 를 확인하여 팀과 비즈니스 이해를 일치시키는 외적(Outer) 개발 루프입니다.
3. BDD (Behavior‑Driven Development): 모두를 위한 공통 언어
BDD, 즉 행동 주도 개발은 ATDD에서 한 걸음 더 나아가, ‘어떻게’ 소통하고 협업할 것인지에 대한 구체적 방법론과 도구를 제공합니다.
- 핵심 철학: ATDD 원칙 + 자연어로 시스템 행동(Behavior) 을 서술하고, 이를 직접 실행 가능한 테스트로 자동화한다.
- 초점: 비즈니스 ↔ 기술 간 소통·협업.
BDD는 Gherkin이라는 특정 형식을 사용하여 시스템의 행동을 시나리오로 작성합니다.
📝 Gherkin 시나리오 예시
Scenario: 사용자가 올바른 정보로 로그인에 성공한다
Given 사용자가 로그인 페이지에 있다
When 사용자가 아이디와 비밀번호를 입력하고 '로그인' 버튼을 누른다
Then 사용자는 "환영합니다!" 메시지를 보고 대시보드 페이지로 이동한다이 자연어 시나리오는 그 자체로 요구사항 명세서이자, Cucumber, SpecFlow 같은 도구를 통해 자동화된 테스트 케이스가 됩니다. 즉, 살아있는 문서(Living Documentation)가 만들어지는 것입니다.
4. 한눈에 보는 비교: TDD vs. ATDD vs. BDD
| 구분 | TDD (테스트 주도 개발) | ATDD (인수 테스트 주도 개발) | BDD (행동 주도 개발) |
|---|---|---|---|
| 목표 | 코드의 설계 개선 및 품질 보증 | 요구사항 충족 및 기능 검증 | 협업 증진 및 공통의 이해 구축 |
| 관점 | 개발자 (내부 구현) | 고객/사용자 (외부 기능) | 비즈니스/사용자 (시스템 행동) |
| 주요 사용자 | 개발자 | 팀 전체 (고객 포함) | 팀 전체 (고객 포함) |
| 주요 레벨 | 단위 테스트 (Unit Test) | 인수 테스트 (Acceptance Test) | 인수 테스트 (Acceptance Test) |
| 언어 | 프로그래밍 언어 (코드) | 테스트 케이스 형식 | 자연어 (Gherkin 구문) |
| 관계 | – | TDD를 포함할 수 있음 | ATDD의 구체적인 실천 방법론 |
많은 전문가들은 BDD를 ATDD의 한 종류, 즉 “ATDD를 제대로 하기 위한 방법론” 으로 간주합니다.
