165. BDD (Behavior Driven Development, 행위 주도 개발)

핵심 인사이트 (3줄 요약)

본질: BDD (Behavior Driven Development)는 소프트웨어의 기대 행위를 자연어 시나리오로 먼저 합의하고, 이를 실행 가능한 테스트로 연결하는 명세 중심 개발 방식이다.

가치: 기획자·개발자·품질보증 담당자 (Quality Assurance, QA)가 같은 시나리오를 공유하면 요구사항 해석 차이와 재작업 비용이 크게 줄어든다.

판단 포인트: BDD의 성패는 문법 도입이 아니라 협업 품질에 달려 있으며, 테스트 코드를 예쁘게 쓰는 것보다 "올바른 행동을 함께 정의했는가"가 더 중요하다.

Ⅰ. 개요 및 필요성

BDD는 "무엇을 만들어야 하는가"를 먼저 언어로 명확히 한 뒤 구현에 들어가는 접근이다. 테스트 주도 개발 (Test-Driven Development, TDD)이 개발자 중심의 작은 단위 검증에 강하다면, BDD는 사용자와 비즈니스가 이해할 수 있는 기능 행위 수준에서 명세를 정렬하는 데 강하다.

이 방식이 필요한 이유는 요구사항 문서와 개발 해석 사이의 간극 때문이다. 같은 "로그인 실패 처리"라도 기획자는 보안 정책을, QA는 오류 메시지를, 개발자는 예외 흐름을 떠올린다. BDD는 이 차이를 Given/When/Then 형식의 구체 시나리오로 끌어내어, 애매한 표현을 실행 가능한 약속으로 바꾼다.

특히 복잡한 업무 규칙이 있는 도메인에서 효과가 크다. 예를 들어 보험 청구, 금융 이체, 쿠폰 정책은 코드보다 예외 규칙이 더 어렵다. 이때 행위를 문장으로 먼저 명확히 하면 개발 착수 전부터 누락 규칙과 충돌 정책을 발견할 수 있다.

📢 섹션 요약 비유: BDD는 공연 리허설 전에 대본을 함께 읽는 과정과 같다. 배우마다 자기 식으로 해석하기 전에, 어떤 장면에서 누가 무엇을 하고 어떤 결과가 나와야 하는지 먼저 맞춰 보는 것이다.

Ⅱ. 아키텍처 및 핵심 원리

BDD의 핵심은 자연어 명세와 자동화 테스트를 끊지 않고 연결하는 것이다. 보통 기능 요구를 발견하고, 시나리오로 공식화하고, 이를 스텝 정의 (Step Definition) 코드에 연결한 뒤, 지속적 통합/지속적 전달 (Continuous Integration/Continuous Delivery, CI/CD) 파이프라인에서 반복 실행한다.

아래 흐름은 BDD가 단순 문서 작성이 아니라 협업, 자동화, 검증이 이어지는 구조임을 보여준다.

┌────────────────────────────────────────────────────────────────────┐
│                  BDD Workflow                                     │
├────────────────────────────────────────────────────────────────────┤
│ 1. Discovery                                                     │
│    Business + Dev + QA gather concrete examples                  │
│                │                                                  │
│                ▼                                                  │
│ 2. Formulation                                                   │
│    Feature / Scenario / Given-When-Then                          │
│                │                                                  │
│                ▼                                                  │
│ 3. Automation                                                    │
│    Gherkin ↔ Step Definitions ↔ Test Runner                      │
│                │                                                  │
│                ▼                                                  │
│ 4. Validation                                                    │
│    CI/CD run + report + living documentation                     │
└────────────────────────────────────────────────────────────────────┘

이 구조에서 중요한 연결점은 Gherkin이다. 거킨 (Gherkin)은 BDD 시나리오를 표현하는 도메인 특화 언어 (Domain-Specific Language, DSL)로, 비기술자도 읽을 수 있으면서 도구가 파싱할 수 있다. 아래 예시는 명세와 검증이 같은 문장 구조를 공유한다.

Feature: 송금 한도 검증
  Scenario: 1일 이체 한도를 초과하면 송금이 거절된다
    Given 사용자 "mina"의 1일 이체 한도는 1,000,000원이다
    And 오늘 이미 900,000원을 이체했다
    When 사용자가 200,000원을 추가 이체한다
    Then 송금은 거절된다
    And "1일 이체 한도를 초과했습니다" 메시지가 표시된다

요소	의미	설계 포인트
Feature	사용자 가치 단위	기능 이름보다 비즈니스 목적이 드러나야 한다
Scenario	하나의 검증 가능한 사례	한 시나리오에는 한 행동만 담는 편이 좋다
Given	사전 상태	데이터와 전제를 구체적으로 적는다
When	사용자 행위/이벤트	UI 클릭보다 의미 있는 행동으로 쓴다
Then	기대 결과	화면, 상태, 규칙 검증을 명확히 쓴다
Examples	여러 입력 조합	시나리오 중복을 줄여 준다

📢 섹션 요약 비유: BDD는 요리책에서 "재료 준비(Given) → 조리 행동(When) → 완성 상태(Then)"를 적는 것과 같다. 레시피가 정확해야 누구가 요리해도 같은 맛이 난다.

Ⅲ. 비교 및 연결

BDD는 TDD를 대체하는 기법이 아니라 다른 추상화 수준을 담당하는 보완재다. TDD가 함수와 클래스 수준의 설계를 다듬는다면, BDD는 기능과 정책 수준에서 팀의 공통 이해를 만든다. 또한 인수 테스트 주도 개발 (Acceptance Test-Driven Development, ATDD)과도 닿아 있지만, BDD는 특히 대화와 예시 중심 협업을 더 강조한다.

구분	TDD	BDD	ATDD
주 초점	구현 정확성	기대 행위 공유	인수 기준 합의
주요 독자	개발자	비즈니스 + 개발 + QA	고객/비즈니스 + QA
표현 방식	테스트 코드	자연어 시나리오 + 코드	인수 기준 시나리오
테스트 레벨	단위 테스트 중심	기능/행위 테스트 중심	인수 테스트 중심
대표 질문	"이 함수가 맞게 동작하는가?"	"사용자는 무엇을 기대하는가?"	"이 기능을 완료로 볼 수 있는가?"

BDD의 핵심 협업 방식으로는 쓰리 아미고스 (Three Amigos) 회의가 자주 언급된다. 여기서 제품 책임자 (Product Owner, PO)는 비즈니스 규칙을, 개발자는 구현 가능성을, QA는 검증 관점을 제시한다. 이 세 관점이 충돌하는 지점에서 좋은 시나리오가 만들어진다.

또한 BDD는 생존 문서 (Living Documentation) 개념과 연결된다. 시나리오가 자동화 테스트와 연결되어 있으면 문서는 정적 산출물이 아니라 실제 동작과 함께 유지되는 실행형 명세가 된다. 따라서 문서와 시스템이 따로 노는 문제를 줄일 수 있다.

📢 섹션 요약 비유: TDD가 부품 하나하나를 점검하는 정비라면, BDD는 운전자가 실제로 차를 몰았을 때 기대하는 경험을 점검하는 시승 테스트다. 둘 다 필요하지만 보는 높이가 다르다.

Ⅳ. 실무 적용 및 기술사 판단

실무에서 BDD는 로그인처럼 단순한 기능보다 정책성 규칙이 많은 영역에서 빛난다. 예를 들어 전자상거래 쿠폰 기능은 "신규 회원만 가능", "중복 할인 불가", "유효기간 만료 시 거절" 같은 규칙이 얽혀 있다. 이때 시나리오를 먼저 정리하면 구현 전에 누락 정책과 예외 흐름을 발견할 수 있다.

좋은 BDD 시나리오는 구체적이고, UI 세부보다 행위 중심이며, 비즈니스 언어를 사용한다. 반대로 나쁜 시나리오는 버튼 클릭 순서만 적거나, 하나의 시나리오에 여러 정책을 몰아넣어 실패 원인을 अस्पष्ट하게 만든다. 따라서 시나리오 수를 줄이는 것보다 책임이 명확한 시나리오를 만드는 것이 중요하다.

실무 체크리스트

시나리오를 PO, 개발자, QA가 함께 검토했는가?
Given이 데이터 전제를 충분히 드러내는가?
When이 UI 조작이 아닌 사용자 의도를 표현하는가?
Then이 관찰 가능한 결과를 검증하는가?
자동화 후 CI/CD에서 회귀 테스트로 계속 실행되는가?

안티패턴

개발자가 혼자 Gherkin 문법만 작성하고 협업을 생략하는 경우
테스트 도구 도입만 하고 예시 기반 대화를 하지 않는 경우
시나리오를 화면 캡처 순서서처럼 작성해 요구사항 변화에 약해지는 경우
📢 섹션 요약 비유: 건축을 시작하기 전에 설계자, 시공자, 검사자가 같은 도면을 보고 질문을 끝내야 공사 중 재작업이 줄어든다. BDD는 코드를 짓기 전에 그 도면을 함께 고정하는 과정이다.

Ⅴ. 기대효과 및 결론

BDD를 제대로 적용하면 요구사항과 테스트와 구현의 간격이 줄어든다. 팀은 기능을 "대충 이해하고 구현한 뒤 수정"하는 대신, 먼저 시나리오를 통해 완료 기준을 선명하게 만든다. 그 결과 회귀 테스트 품질이 좋아지고, 신규 인력도 시나리오만 읽어 핵심 정책을 빠르게 이해할 수 있다.

물론 BDD가 모든 프로젝트에 무조건 필요한 것은 아니다. 규칙이 단순하고 팀 규모가 작다면 오히려 작성 비용이 부담이 될 수 있다. 또 시나리오를 지나치게 세분화하면 문서 유지 비용이 커지고, 비즈니스 언어가 아니라 구현 용어가 들어오면 금방 낡은 테스트가 된다.

따라서 BDD는 "Given/When/Then 문법"보다 "행위를 함께 정의하는 문화"로 기억하는 편이 맞다. 좋은 BDD는 테스트 기술이 아니라, 팀이 같은 기능을 같은 말로 이해하게 만드는 운영 체계다.

📢 섹션 요약 비유: 같은 보드게임을 할 때 규칙 설명서를 다 같이 읽고 시작하면 싸움이 줄어든다. BDD는 소프트웨어 팀이 게임 시작 전에 규칙을 함께 확정하는 일이다.

📌 관련 개념 맵

개념	연결 포인트
BDD (Behavior Driven Development)	행위 중심 시나리오로 요구사항과 테스트를 연결하는 핵심 방법론
Gherkin	BDD 시나리오를 표현하는 대표 문법
쓰리 아미고스 (Three Amigos)	PO·개발·QA가 예시를 통해 공통 이해를 만드는 협업 방식
TDD (Test-Driven Development)	구현 단위 설계를 다듬는 보완 기법
생존 문서 (Living Documentation)	실행되는 시나리오가 최신 명세가 되는 개념

📈 관련 키워드 및 발전 흐름도

요구사항 모호성
    │
    ▼
예시 기반 대화 (Example Conversation)
    │
    ▼
BDD (Behavior Driven Development)
    │
    ├── Gherkin 시나리오
    │
    ├── Step Definition 자동화
    │
    ▼
CI/CD 회귀 테스트 · 생존 문서 (Living Documentation)

이 흐름은 구두 요구사항이 예시와 시나리오를 거쳐 실행 가능한 명세와 지속 검증 체계로 발전하는 과정을 보여준다.

👶 어린이를 위한 3줄 비유 설명

친구들과 게임을 만들 때 "이 버튼을 누르면 어떤 일이 생겨야 하는지"를 먼저 약속하는 게 BDD예요.
모두가 같은 약속을 보고 게임을 만들면 나중에 "나는 이렇게 생각했는데?"라는 싸움이 줄어요.
그리고 그 약속을 자동으로 검사해서 게임이 업데이트돼도 규칙이 그대로 지켜지는지 확인한답니다.