Behavior-Driven Development (BDD) — 행위 주도 개발

정의

Behavior-Driven Development(BDD, 행위 주도 개발) 는 소프트웨어의 내부 구현이 아니라 사용자 관점에서 관찰 가능한 행위(Behavior) 를 명세·검증의 중심에 두는 개발 방법론이다. harness나 mcp 같은 실행 환경을 갖추기 전에 “무엇을 만들어야 하는가”를 팀 전체가 같은 언어로 합의하게 만든다.

코드의 행위를 설명하기 위해 도메인 언어(유비쿼터스 언어) 로 테스트 이름을 짓는다.
자연어에 가까운 문장(Gherkin)으로 실행 가능한 명세(executable specification) 를 작성하고, 이를 자동 테스트로 전환한다.
비즈니스 가치 순서로 작성된 시나리오가 인수 기준(acceptance criteria) 역할을 한다.

핵심 한 줄: BDD는 "테스트를 먼저 쓰는 방법"이 아니라 **"행위를 먼저 합의하는 방법"** 이다.

기원과 철학

2006년 Dan North(ThoughtWorks) 가 TDD의 오해를 풀기 위해 제안. TDD에서 test·assert 같은 기술 용어를 should·ensure 같은 행위 언어와 Given-When-Then 구조로 바꾸자고 한 것이 출발점이다.
TDD + DDD의 결합으로 설명되곤 한다 — TDD의 테스트-우선 사이클에 DDD의 유비쿼터스 언어·도메인 전용 언어(DSL) 개념을 얹은 형태다.
“외부에서 안으로(outside-in)” 접근을 강조: 비즈니스 이해관계자가 원하는 외부 동작을 먼저 명세하고, 그 뒤에 내부 단위 구현을 채운다.

3원칙과 Given-When-Then

BDD의 모든 시나리오는 세 절로 나뉜다 — Martin Fowler가 정리한 Four-Phase Test(Arrange-Act-Assert)와 같은 뿌리다.

절	역할	의미	테스트 프레임워크 관점
Given	전제·맥락	테스트 전 세계의 상태(사전 조건)	Setup / Arrange
When	행위·사건	명세하려는 동작 한 가지	Exercise / Act
Then	결과·기대값	그 행위로 기대되는 변화·출력	Verify / Assert (+ Teardown은 생략 가능)

핵심 원칙: When은 하나. Given → When(1개) → Then(여러 검증 가능) 은 허용되지만, 한 시나리오에 When을 두 개 넣으면 실패 원인 특정·이름 짓기·의존성 문제가 생긴다. 검증이 5~6개 이상이면 @Nested·@BeforeEach로 관점별 분리한다.

예시 — Gherkin

Feature: 계좌 현금 인출
  As a 고객
  I want 현금 인출
  So that 현금을 손에 쥘 수 있다
 
  Scenario: 잔액 충분·카드 정상·현금 있음
    Given 계좌에 잔액이 있고 카드가 유효하며 인출기에 현금이 있다
    When 고객이 현금 인출을 요청하면
    Then 계좌에서 금액이 차감되고 현금이 배출되며 카드가 반환되어야 한다
 
  Scenario: 잔액 부족
    Given 계좌 잔액이 부족하다
    When 고객이 현금 인출을 요청하면
    Then 거래가 거절되고 잔액 부족 메시지가 표시되어야 한다

각 절은 Cucumber·Behave·SpecFlow 같은 도구가 파싱해 단계 정의(step definition) 코드와 연결된다.

@Given("사용자가 로그인 페이지에 접속했을 때")
public void givenLoginPage() { /* Given 조건 설정 */ }
 
@When("올바른 아이디·비밀번호로 로그인을 시도하면")
public void whenLogin() { /* 행위 실행 */ }
 
@Then("메인 페이지로 이동해야 한다")
public void thenMainPage() { /* 결과 검증 — 부작용 없는 조회여야 함 */ }

유비쿼터스 언어와 살아있는 문서

BDD는 유비쿼터스 언어(ubiquitous language) 를 요구한다 — 개발자·QA·기획·비즈니스 모두가 같은 (반)형식 언어로 도메인을 논의한다.
이 언어를 Gherkin 같은 DSL로 형식화하면, 요구사항 문서 자체가 도구로 직접 실행 가능한 테스트 모음이 된다 → 요구사항 = 테스트 = 살아있는 문서(living documentation).
도구가 문서를 읽어 Given/When/Then 키워드로 절을 나누고, 각 절을 테스트 파라미터로 변환해 실행한다.

TDD / ATDD / BDD 비교

구분	TDD	BDD	ATDD
초점	기능 단위·구현 방법(How)	사용자 행동·비즈니스 요구(What)	인수 기준 충족 여부
언어	개발자 중심 (코드·assert)	비즈니스 중심 (자연어 Given-When-Then)	비즈니스 인수 기준 중심
작성 시점	테스트 → 구현 (단위 레벨)	시나리오 → 테스트·구현 (스토리 레벨)	인수 테스트 → 구현
참여자	주로 개발자	개발자·QA·기획·PO 전원	PO/비즈니스 주도
산출물	단위 테스트	실행 가능한 행위 명세	인수 테스트 스위트

BDD는 TDD를 대체하지 않는다 — TDD를 확장해 테스트 이름과 구조를 비즈니스 언어로 바꾸고, 인수 레벨 명세 레이어를 추가한다.

도구 생태계

Cucumber (Ruby/Java/JS) — Gherkin 기반 대표 프레임워크. Cucumber.js·Cucumber-JVM 등 다언어 포트.
SpecFlow (.NET), Behave (Python), godog (Go), JBehave (Java), JSSpec (JavaScript, 스프링노트 사례 유명)
AWS 예시: aws-samples/aws-cdk-pipelines-cucumber-bdd — CDK Pipeline에 Cucumber BDD 인수 테스트를 통합해 Dev/PreProd 배포 후 자동 검증. AWS Device Farm·Selenium과 결합.
알렉사 스킬 BDD: Cucumber.js로 When the user says "…" 같은 제네릭 스텝을 만들고, 로컬 목 음성 서비스가 Voice Interaction Model을 정규식으로 매칭해 IntentRequest를 생성 — 클라우드 없이 로컬에서 행위 검증.

아마존에서의 실천

2026-08-30-clare-liguori-ai-native-five-habits 맥락에서 아마존이 BDD를 “적극 실천”한다는 말은 다음 제도·기술과 짝을 이룬다.

AWS Well-Architected DevOps Guidance (QA.FT.3): “팀은 이상적으로 BDD를 실천해 코드 작성 전에 시스템이 어떻게 테스트되도록 설계될지 정의해야 한다. 그 뒤 AWS Device Farm·Selenium 같은 적합한 자동 테스트 프레임워크를 채택하고, CD Pipeline에서 스크립트된 테스트 케이스를 테스트 환경의 실행 중인 시스템에 대해 실행하라”고 명시.
인증·거버넌스 테스트: Alexa-Cert-Tech 팀은 BDD statement 자동 생성을 LLM으로 자동화 — Bedrock Agents(QA/Structure Agent) + RAG + Step Functions 파이프라인으로 NoCodeAutomation 도구(OAK)의 Feature File 생성을 자동화. 수동 BDD 문장 작성의 시간·오류 병목을 줄였다.
조직 정책 테스트: SCP(Service Control Policy)·Tag Policy 변경을 BDD(Gherkin + godog)로 샌드박스에서 검증 — “태그 없이 EC2를 띄우면 거절되어야 한다” 같은 시나리오를 go test로 실행하고, DryRun·권한 오류 구분·병렬 계정 검증을 CI에 통합. 실패 시 롤백 트리거.
Clare Liguori 5습관과의 연결:
- 습관 4 Make intent explicit — 코드 전에 Feature Specification(Objective/Use Cases/Key Functionality/Technical Requirements)을 에이전트와 합의하는 단계는 BDD의 “시나리오를 먼저 정의”와 동일하다.
- 습관 5 Shift testing left — 린터·mock 서비스·unit/integration/performance/security 테스트로 빠르고 로컬한 피드백 루프를 주는 것은 BDD가 요구하는 “신호가 있으면 에이전트가 스스로 고친다”는 전제와 일치한다.
- 습관 3 Feed agents, don’t babysit 의 “할 일 + 검증 방법 + 품질 기준을 한 번에 넘겨 에이전트가 30분~수시간 자율 보정하게 하라”는 패턴은 BDD 시나리오의 Then 절이 품질 바를 명시하는 것과 같은 구조다.

따라서 아마존식 BDD는 단순한 테스트 기법이 아니라 의도 명문화 → 실행 가능한 명세 → 빠른 로컬 검증 → 파이프라인 자동화 로 이어지는 일하는 방식의 일부다.

장점과 오해·한계

장점

비즈니스·개발·QA 사이의 의사소통 단절을 줄인다 — 모두가 읽는 같은 시나리오가 기준점이 된다.
요구사항이 코드와 함께 진화하는 살아있는 문서가 되어 오래된 스펙 문서 문제를 제거한다.
시나리오가 비즈니스 가치 순으로 정렬되어 우선순위가 드러난다.
에이전트 시대에 특히 유효: 에이전트에게 자연어 명세와 검증 조건을 한 번에 주면 자율 루프를 돌릴 수 있다.

오해

“BDD = Cucumber를 쓰는 것”이 아니다. 도구는 구현체일 뿐, 핵심은 협업과 언어 통일이다.
“BDD가 TDD를 대체한다”는 오해 — BDD는 인수 레벨을 덮고, TDD는 단위 레벨을 계속 담당한다.

한계·주의

모든 요구를 Gherkin으로 자동화할 수 없다 — 권한 오류 vs 정책 거절처럼 오류 구분이 필요하거나, DryRun이 없는 리소스는 실제 생성·정리 비용이 든다.
비형식 언어를 형식 DSL로 바꾸는 과정에서 작성 스타일 변경이 필요할 수 있다.
과도한 시나리오 세분화는 유지보수 부담이 된다 — When 하나 원칙과 적정 추상도 유지가 중요하다.

실전 체크리스트 (BDD 시작하기)

유저 스토리 형식 통일: As a [역할], I want [기능], So that [이익] 템플릿을 팀에 공유한다.
시나리오를 Given-When-Then으로 쓰되 When은 하나로 제한한다.
Given은 사전 조건 서술(테스트 프레임워크는 이를 상태 구성 명령으로 해석), Then은 부작용 없는 조회(assert)로 둔다.
Gherkin Feature 파일(.feature)을 만들고 Cucumber/Behave/godog 중 스택에 맞는 러너를 연결한다.
단계 정의에서 도메인 용어를 그대로 사용해 유비쿼터스 언어를 코드까지 관통시킨다.
CI 파이프라인에 BDD 스위트를 넣어 PR 체크·배포 게이트로 삼는다.
아마존 사례처럼 민감한 변경(SCP·스키마·권한)은 샌드박스 + BDD 베이스라인 테스트를 먼저 돌린다.

description	TDD에서 확장된 행위 중심 개발 방법론으로 Given-When-Then과 유비쿼터스 언어로 협업을 이끈다.
tags	dev-tools, productivity, ai-coding
aliases	BDD, 행위 주도 개발, 행동 주도 개발

LLM Wiki

탐색기