BDD가 뭐길래? 개발자와 기획자가 싸우지 않는 비결
우리 서로 오해하지 않게 '같은 말'로 이야기해요
제품 개발팀에서 가장 먼저 확인하는 것은 팀원들이 '같은 말'로 대화하고 있는지 확인하는 것이다.
외국어를 이야기하는 것은 아니다. 한국말로 대화를 해도 '동상이몽' 문제를 겪고 있을 가능성이 있다.
기획자: "사용자가 '쉽게' 가입할 수 있게 해 주세요."
개발자: (아이디, 비번, 이메일, 폰 인증, 주소... 10개 항목을 넣으며) "다 필요한 정보라 '쉽게' 만든 건데요?"
기획자: ?????? (what..?!)
이 문제를 해결하기 위해 등장한 개념이 바로 BDD(Behaviour-Driven Development), 즉 '행위 주도 개발'이다. 어렵게 들리지만, 쉽게 말해 "우리, 서로 오해하지 않게 '같은 말'로 대화하자!"는 약속이다.
1. 비극의 시작: 기획자어(語) vs. 개발자어(語)
소프트웨어를 만들 땐 여러 사람이 필요하다.
기획자 (비즈니스 전문가): "돈을 벌어야 해! 사용자가 이걸 좋아할 거야!" (주로 '한글'로 말함)
개발자: "그게... 기술적으로 가능한가요? if... else..." (주로 '코드'로 말함)
테스터: "이거 왜 안 돼요? 저거 왜 이래요?" (주로 '버그 리포트'로 말함)
이들은 마치 각자 다른 나라 말을 쓰는 것과 같다. 기획자가 아무리 멋진 아이디어를 설명해도, 개발자가 "그래서 정확히 어떻게 하라는 거죠?"라고 되묻고, 나중에 완성된 걸 보면 기획자는 "이게 아닌데..."라고 한다.
이 '바벨탑' 문제를 해결할 **'만국 공용어'**가 필요했고, 그게 바로 BDD다.
2. 마법의 레시피: "Given-When-Then"
BDD는 복잡한 말 대신, 누구나 이해할 수 있는 '시나리오 (이야기)' 형식으로 소통하자고 제안한다. 이때 사용되는 마법의 레시피가 바로 **'Given-When-Then '** 문법이다.
이게 뭐냐면, **"준비물-요리법-완성품"**이라고 생각하면 쉽다.
아까 그 '은행 출금' 예시를 이 레시피에 맞춰 다시 써보자.
[시나리오: 5천 원 인출하기]
Given (준비물 �)
내 계좌에 잔액이 10,000원 있다. 그리고 현금 인출기는 정상 작동 중이다.
When (요리법 �)
내가 5,000원을 인출한다.
Then (완성품 �)
내 계좌의 잔액은 5,000원이 된다. 그리고 나는 현금 5,000원을 받는다.
어떠한가? 이건 개발자가 아니어도, 코딩을 1도 몰라도 누구나 이해할 수 있다.
기획자는 이 시나리오를 보고 "아, 맞아요! 잔액이 부족할 땐 '잔액 부족'이라고 떠야 하는 시나리오도 추가하죠!"라고 말할 수 있다.
개발자는 이 시나리오를 '그대로' 가져가서 코드로 옮긴다.
테스터는 이 시나리오대로 '정말' 작동하는지 확인한다.
드디어 모두가 같은 '이야기'를 보며 대화하게 된 것이다!
3. 잠깐! 촬영 전 연습은 '스턴트맨'에게! (모킹)
그런데 문제가 있다. "회원가입 시 환영 문자를 보낸다"는 시나리오를 개발해야 한다고 해보자.
개발자가 기능을 잘 만들었는지 확인하려고 테스트할 때마다 진짜로 문자를 쏘면 어떻게 될까?
1. 문자 발송 비용이 계속 나간다. (돈 낭비 ㅜㅜ)
2. 새벽 3시에 테스트하다가 사장님 폰으로 문자가 갈 수도 있다. (대참사!!!)
이럴 때 필요한 게 모킹(Mocking), 우리말로 하면 **'흉내 내기'**이다.
영화 찍을 때, 비싼 슈퍼카가 절벽에서 떨어지는 신을 연습한다고 진짜 슈퍼카를 부술까? 아니다! 비슷하게 생긴 **'가짜 차(모형 차)'**로 수십 번 연습한다.
모킹이 바로 그 '스턴트맨' 또는 '가짜 차' 역할이다.
즉, '가짜 문자 발송 서비스(모킹 객체)' 만들면 비용은 아끼면서도 테스트는 진행해 볼 수 있다.
이 가짜 서비스는 실제로 문자를 보내진 않고, "네! 010-1234-5678로 문자 잘 보냈다고 '척' 할게요!"라고 흉내만 낸다.
이게 왜 좋을까? 개발자는 돈 걱정 없이, 남에게 피해 주지 않고, 자기 기능을 100번이고 1000번이고 빠르고 안전하게 테스트할 수 있다. 덕분에 설계도 깔끔해지고 개발 속도도 빨라진다.
4. BDD에 대한 흔한 오해 3가지
1) "BDD는 TDD보다 쉬운 건가요?"
A. 아니요! BDD는 TDD(테스트 주도 개발)라는 개념 위에 '협업'과 '소통'이라는 양념을 더한 **'업그레이드 버전'**에 가깝습니다. "코딩만 잘하자"가 아니라 "다 같이 잘하자"는 거라 더 넓은 시야가 필요합니다.
2) "BDD는 'Cucumber' 같은 프로그램 이름인가요?"
A. 아니요! BDD는 '민주주의'처럼 '생각하는 방식'이나 '문화'입니다. 'Cucumber(큐컴버)' 같은 프로그램은 BDD를 더 쉽게 하도록 도와주는 '도구'일뿐입니다. (투표를 도와주는 '투표용지'처럼)
3) "나는 제품 메이커들과 협업만 하는 마케터입니다. BDD 알아서 뭐 하죠?" A. 이게 핵심입니다! BDD는 코딩 기술이 아니라 **'커뮤니케이션 기술'**입니다. 개발을 1도 모르는 사람도 BDD를 통해 핵심 기능의 동작 원리와 요소를 쉽고 빠르게 캐치할 수 있습니다.
5. 맺음말: 그래서 BDD가 우리에게 알려주는 것
이 글을 읽는 독자분들이 제품 메이커가 아니더라도 팀으로 일하고 있다면, 누군가와는 끊임없이 협업하고 있을 것이다.
BDD가 우리에게 정말 알려주는 가치는 "코딩 잘하는 법"이 아니라, **"서로 오해 없이, 명확하게 소통하는 법"**이다.
- '깔끔하게' 같은 애매한 말 대신,
- "Given(어떤 환경에서), When(어떤 액션을 하면), Then(이 결과가 나옵니다)"
-처럼 구체적인 '시나리오'로 이야기하는 습관을 들인다면, 여러분이 어떤 팀에 가든 "아, 저 사람이랑 일하니까 진짜 편하다!"라는 말을 듣게 될 것이다.
개발자와 기획자뿐만 아니라, 우리 모두에게 필요한 소통의 기술, 그게 바로 BDD의 진짜 가치라고 볼 수 있다.
핵심 키워드
#BDD, #행위 주도 개발, #Given-When-Then, #모킹
