💡 핵심 인사이트
BDD(행동 주도 개발)는 테스트 주도 개발(TDD)이 철저하게 '개발자의 뇌 구조(코드 내부 로직)'에 갇혀 기획자나 고객과 소통하지 못하는 단점을 부수기 위해 탄생했습니다.
코드를 짜기 전, 기획자, QA, 개발자가 다 같이 모여 "이 시스템이 사용자 앞에서 어떤 행동(Behavior)을 보여야 하는가?"를 누구나 읽을 수 있는 평범한 영어(자연어) 문장으로 먼저 적고, 그 문장 자체가 자동화된 테스트 코드가 되게 만드는 기적의 애자일 협업 기법입니다.

Ⅰ. TDD의 한계와 BDD의 탄생

• TDD의 고통: 개발자가 assertEquals(calc.add(1, 2), 3) 같은 테스트 코드를 짭니다. 코드는 튼튼해졌지만, 옆에 있던 기획자는 그 코드를 보고 "그래서 이게 쇼핑몰 장바구니 쿠폰 로직을 제대로 구현한 거 맞아?"라고 물어봐도 코드를 못 읽으니 알 수가 없습니다.
• BDD의 제안: 댄 노스(Dan North)는 "테스트 코드를 calc.add 같은 수학/기술 용어가 아니라, 사용자의 행동(Behavior)을 묘사하는 쉬운 문장으로 적으면 안 될까?"라고 생각했습니다.

Ⅱ. BDD의 공용어: GIVEN / WHEN / THEN 패턴

BDD의 알파이자 오메가입니다. 기획자, 테스터, 개발자는 회의실에 모여 새로운 기능을 만들 때 반드시 아래의 3단계 영어 문장 템플릿(Gherkin 문법)에 맞춰 스토리를 적습니다.

• Given (주어진 상황 / 전제 조건): 시스템이 테스트를 시작하기 전의 초기 상태를 묘사합니다.
  • 예: "사용자가 이미 로그인된 상태이고, 장바구니에 10만 원어치 상품이 담겨 있다 (Given)"
• When (사용자의 행동 / 트리거): 사용자가 무슨 액션을 취했는지 묘사합니다.
  • 예: "사용자가 '5천 원 생일 쿠폰 적용' 버튼을 클릭했을 때 (When)"
• Then (기대되는 결과 / 보장): 시스템이 어떻게 반응해야 정답인지 묘사합니다.
  • 예: "최종 결제 금액은 9만 5천 원으로 변경되어야 하고, 쿠폰은 '사용 완료' 상태로 변해야 한다 (Then)"

이렇게 포스트잇에 적힌 한글(또는 영어) 문장 덩어리 자체가 완벽한 **'요구사항 명세서'**이자 **'테스트 시나리오'**가 됩니다.

Ⅲ. BDD의 자동화 툴 (Cucumber)

"그냥 영어로 쓴 기획서 아니야? 이게 어떻게 개발이야?" BDD가 미친 기술인 이유는 이 평범한 텍스트 파일(.feature)을 컴퓨터(Cucumber 같은 프레임워크)가 읽어 들여서 실제 자바(Java)나 파이썬 테스트 코드로 1:1 자동 매핑시켜 버린다는 점입니다.

1. 기획자가 Given 로그인 상태라고 텍스트를 치면.
2. 큐컴버 봇이 뒤에서 껍데기 함수 @Given("로그인 상태") public void checkLogin() { ... }를 만들어 줍니다.
3. 개발자는 그 함수 껍데기 안에 진짜 로그인 DB 체크 코드만 채워 넣으면 끝납니다.
4. 나중에 기획자가 텍스트의 숫자를 10만 원에서 5만 원으로 수정하고 엔터를 치면, 개발자 코드를 안 고쳐도 봇이 즉시 5만 원짜리 자동화 테스트 로직을 다시 돌려버립니다.

📢 섹션 요약 비유: TDD가 자동차를 만들 때 엔지니어 혼자 지하에서 **"이 엔진 기어가 1분에 3천 바퀴를 정확히 도는가(내부 로직 테스트)?"**를 검사하는 고독한 작업이라면, BDD는 사장님, 고객, 엔지니어가 차에 다 같이 타서 **"시속 100km로 달리다(Given), 브레이크를 밟으면(When), 3초 안에 차가 부드럽게 서야 한다(Then)"**라는 사용자 체감 행동을 평범한 말로 적고, 그 말이 곧 로봇의 검수 체크리스트가 되게 만드는 마법의 소통법입니다.