tddbuddy.com에서 처음 게시되었습니다.

Gherkin은 결코 진정한 테스트 형식이 아니었습니다. 그것은 _조정 형식 (coordination format)_이었습니다.

테스트 부분은 거의 부수적인 것이었으며, 산출물이 조용히 표류하지 않도록 실행 가능해야 할 필요성에서 비롯된 부작용에 가까웠습니다. 실제 목적은 다른 것이었습니다. 제품(Product), QA, 그리고 엔지니어링 팀이 소프트웨어가 무엇을 해야 하는지에 대해 서면으로 합의하도록 만드는 것이었습니다. 기능 파일(Feature file)은 서로 다른 어휘, 서로 다른 일정, 그리고 서로 다른 인센티브를 가진 세 역할 사이의 **조약 문서 (treaty document)**였습니다.

그 점을 이해하고 나면, BDD의 쇠퇴는 이해가 됩니다. 조약은 그것이 줄이려고 했던 조정 비용 (coordination cost)과 함께 생존하고 소멸합니다. 비용이 변하면, 조약은 형식적인 의례 (ceremony)가 되어버립니다.

이 글은 에이전트 시대(agentic era)의 TDD에 관한 3부작 시리즈 중 두 번째 포스트입니다. 첫 번째 글인 "TDD Already Does BDD, Without the Gherkin"은 코드 수준에서의 **기술적 근거 (craft case)**를 다루었습니다: 빌더(builders), 팩토리(factories), 그리고 모크 기반 협업 테스트 (mock-driven collaboration tests)를 활용한 절제된 TDD는 이미 BDD가 약속했던 것을 제공하고 있다는 내용입니다. 이 포스트는 **조직적 근거 (org case)**를 다룹니다. 조정 목적으로 BDD가 진정으로 필요했던 팀들조차 그 필요성이 재산정(repriced)되는 과정을 지켜보고 있습니다. 세 번째 글인 "The Bar for TDD Just Moved"은 새롭게 요구되는 수준이 무엇인지, 그리고 왜 에이전트 코딩 (agentic coding)이 이를 타협 불가능한 요소로 만드는지를 설명합니다. 만약 당신이 기술적 숙련도를 위해 비용을 지불하고 있었다면, 첫 번째 포스트는 그만두라고 말합니다. 만약 조정(coordination)을 위해 비용을 지불하고 있었다면, 이 포스트는 조정 비용이 방금 더 저렴해졌음을 인지하라고 말합니다. 세 번째 포스트는 그 자리에 이제 무엇이 필요한지를 말해줍니다.

BDD가 실제로 해결하고 있었던 것

BDD가 왜 등장했는지로 돌아가 봅시다. 문제는 "행동을 어떻게 테스트할 것인가"가 아니었습니다. TDD가 이미 그 답을 내놓았기 때문입니다. 절제된 TDD 사용자들은 Cucumber가 존재하기 수년 전부터 시나리오 이름이 붙은 테스트를 작성하고, 유비쿼터스 언어 (ubiquitous language)를 사용하며, 구현보다 행동을 중심으로 프레임을 잡고 있었습니다.

BDD가 실제로 해결하고 있었던 문제는 조직적인 문제였습니다.

• 제품 팀(Product)은 보통 Word 문서나 Jira 에픽(epic)과 같은 하나의 어휘로 요구사항을 작성했습니다.
• QA는 보통 별도의 도구에 있는 테스트 계획과 같은 또 다른 어휘로 수락 기준(acceptance criteria)을 작성했습니다.
• 엔지니어링 팀은 보통 앞선 두 팀과 일치하지 않는 변수명과 도메인 타입(domain types)을 사용하여 세 번째 어휘로 코드를 작성했습니다.

세 가지 산출물. 세 가지 어휘. 세 명의 소유자. 공유된 단일 진실 공급원(single source of truth)의 부재.

피처 파일(feature file)은 세 역할 모두가 명목상 읽고, 편집하고, 승인할 수 있는 단일 문서가 됨으로써 이 문제를 해결했습니다. Given-When-Then 형식은 뛰어난 산문이 아니었습니다. 그것은 PM이 작성할 수 있고, 테스터가 확장할 수 있으며, 엔지니어가 코드에 바인딩(bind)할 수 있는 **최소 공통 분모의 문법 (lowest-common-denominator grammar)**이었습니다.

그것은 교차 기능 팀(cross-functional teams)을 위한 에스페란토(Esperanto)였습니다.

조약이 작동했던 이유 (작동했을 때)

적절한 맥락에서는 그 오버헤드(overhead)를 감수할 가치가 있었습니다.

느리게 움직이는 조직. 전문화된 역할. 비동기적 인수인계(Async handoffs). 2주 전에 미리 예약해야 하는 비용이 많이 드는 회의들. PM, QA, 개발자(Dev)를 다시 정렬하는 조정 비용(coordination cost)이 달력상의 날짜로 측정될 때, 피처 파일 저장소(feature file repo)를 유지하는 것이 저렴한 옵션이었습니다.

Gherkin은 테스트 사이클이 아니라 회의 사이클을 절약했습니다.

이러한 프레임워크는 그 조약이 실제로 무엇을 맞바꾸고 있었는지를 드러냅니다. 팀들은 다음을 감수했습니다:

• 두 번째 명세 언어 (specification language)
• 스텝 정의(step-definition) 코드베이스
• 피처 파일의 드리프트(drift) 및 유지보수
• 컴파일 타임 체크(compile-time checks) 대신 런타임 정규표현식(regex) 매칭
• 느린 엔드 투 엔드(end-to-end) 테스트 스위트

그리고 그 대가로 다음을 얻었습니다:

• 더 적은 회의
• 더 적은 인수인계 확인 작업
• 무언가 잘못 배포되었을 때 제품 팀이 지목할 수 있는 문서
• 개발자 없이도 QA가 확장할 수 있는 문서
• 세 명의 서명이 담긴 조정 접점(coordination surface)

서명을 받는 것이 진정으로 어려운 조직에게 그 거래는 합리적이었습니다. 테스트는 부수적인 이점이었을 뿐입니다. 조약 자체가 목적이었습니다.

PRD도 동일한 궤적을 그렸다

이 패턴은 BDD에만 국한된 것이 아닙니다.

제품 요구 사항 문서 (Product Requirements Documents, PRD)는 제품 팀이 엔지니어링 팀과 다른 건물에 위치하고, 분기별로 제품을 출시하며, 벽 너머로 사양을 전달하던 시절에는 의미가 있었습니다. PRD는 일종의 조약이었으며, 6주 후에 의견 불일치가 발생했을 때 양측 모두가 참조할 수 있는 형식으로 의도를 포착하는 수단이었습니다.

그 후 팀들이 같은 공간에서 근무하게 되었습니다. 반복 주기 (Iteration cadence)가 분기 단위에서 주 단위로 단축되었습니다. 제품 담당자가 데일리 스탠드업 (Standup) 회의에 참여하게 되었습니다. PRD가 사라진 것은 아니지만, 압축되었습니다. 그것은 Linear 문서, Notion 페이지, 원페이저 (one-pager), 짧은 RFC, 또는 Amazon의 식스페이저 (six-pager)가 되었습니다. 그 _기능 (function)_은 지속되었습니다. 즉, 분산된 독자들(인접 팀, 신규 입사자, 미래의 당신 자신, 법무팀, AI 에이전트)이 질문 없이도 의도를 재구성할 수 있도록 의도를 포착하는 것입니다. 하지만 그 역할은 극적으로 줄어들었습니다. PRD는 더 이상 중심적인 조약이 아니라, 가끔 참조될 뿐 지속적으로 편집되지 않으며, 종종 에이전트에 의해 필요할 때마다 조립되고 업데이트되는 가벼운 참조 자료가 되었습니다.

Gherkin 또한 동일한 경로를 걷고 있으며, 아마 더 빠르게 걷고 있을 것입니다. 갑작스러운 소멸이 아니라, 역할의 꾸준한 압축입니다. 기능 파일 (feature files)을 살아있는 사양 (living specification)으로 _유지 관리 (maintaining)_하는 의식은 마지막 .feature 파일이 삭제되기 훨씬 전부터 희미해집니다. 팀들은 더 이상 파일을 확장하지 않고, 새로운 파일을 작성하지 않으며, 결국 오래된 PRD가 Confluence의 "Archive / 2019" 아래에 여전히 남아 있는 것처럼 이를 레거시 유물 (legacy artifacts)로 남겨두게 됩니다.

디자인 문서 (Design docs), 티켓 템플릿 (ticket templates), 릴리스 노트 (release notes), 핸드오프 문서 (handoff docs), 런북 (runbooks): 모든 조정 산출물 (coordination artifact)은 동일한 곡선의 어떤 버전을 따릅니다. 때로는 사라지기도 합니다. 하지만 더 빈번하게는 유지 관리 비용이 더 적고, 빠르고, 가벼운 무언가로 압축됩니다. 그것이 줄여주는 조정 비용 (coordination cost)이 높았을 때는 가치가 있었습니다. 하지만 비용이 낮아지면 그것은 오버헤드 (overhead)가 되며, 팀은 새로운 비용 구조에 맞춰 산출물의 형태를 재편합니다.

산출물은 비용이 변했다는 사실을 알지 못합니다. 팀이 이를 알아차려야 합니다.

역할 압축이 계산법을 바꾼다

그리고 그 비용은 빠르게 낮아지고 있습니다.

현대의 제품 엔지니어(product engineers)는 발견(discovery) 단계부터 프로덕션(production) 단계까지 스토리를 직접 이끌고 갑니다. 풀스택 엔지니어(Full-stack engineers)는 과거에 프론트엔드(frontend), 백엔드(backend), QA 역할로 분리되어 있던 업무들을 흡수합니다. 종종 AI의 도움을 받는 1~5명 규모의 민첩한 팀들은, 10년 전이라면 10명 규모의 교차 기능 팀(cross-functional team)이 필요했을 기능들을 출시하고 있습니다.

이것은 더 이상 스타트업만의 패턴이 아닙니다. 기업들도 이를 향해 적극적으로 구조를 재편하고 있습니다. 대규모의 역할 전문화된 전달 그룹(delivery groups)에서 소규모의 교차 기능 스쿼드(cross-functional squads)로의 전환, 그리고 제품(product) 및 QA 계층을 통한 중재 대신 엔지니어링(engineering) 수준에서 이루어지는 저장소 간(cross-repo) 및 서비스 간(cross-service) 협업은 은행, 보험, 물류, 통신 분야 전반에서 목격되고 있습니다. 지난 10년간의 "2피자 팀(two-pizza team)"이라는 수사학은 "에이전트(agent)를 동반한 3~5인 규모의 스쿼드"라는 현실로 변하고 있습니다.

1~5명 규모의 팀이 "이것이 무엇을 해야 하는가"부터 "완료되었는가"까지의 스토리를 동일한 작업 세션 내에서 처리할 때, 협약(treaty)을 던져 넘겨야 할 벽은 존재하지 않습니다. 최소 공통 분모(lowest-common-denominator) 수준의 문법이 필요했던 역할들은 동일한 대화에 참여하는 소수의 인원으로 압축됩니다. 세 개의 서명은 빠른 구두 확인으로 바뀌고, 세 개의 어휘는 대개 도메인에서 직접 추출되어 코드에 반영되는 하나의 공유된 내부 어휘로 수렴됩니다.

옆에 앉아 있는 사람과 협약을 작성하지는 않으니까요.

역할이 압축된 팀에서, Gherkin을 통한 모든 왕복(round-trip) 과정은 대응 상대(counterparty)가 거의 없는 재인코딩(re-encoding) 비용일 뿐입니다. 여러분은 나중에 동일한 팀의 다른 버전이 이를 다시 번역할 수 있도록 공유된 이해를 공식 문법으로 번역하는 것입니다. 그것은 의사소통이 아니라 의례(ritual)입니다.

AI는 두 번째 압축이다

첫 번째 압축 위에 두 번째 역할 압축이 일어나고 있으며, 이는 훨씬 더 중요합니다.

인간의 의도(intent)와 실행 가능한 코드(executable code) 사이의 간극은 과거에는 번역의 문제였으며, Gherkin이 바로 그 사이에 위치하도록 설계된 이유이기도 했습니다. PM의 말은 중간 산출물(intermediate artifacts)의 사슬을 거쳐 개발자의 코드가 되었고, 각 산출물은 역할의 경계를 넘을 때마다 의미를 보존하려고 노력했습니다.

AI는 그 사슬을 붕괴시킵니다.

당신은 비즈니스와 공유하는 도메인 언어(domain language)를 사용하여 LLM에게 원하는 동작을 말할 수 있으며, 그러면 LLM은 실제 도메인 타입(domain types)을 사용하여, 실제 코드에 연결된 호스트 언어(host language)로 테스트를 작성할 것입니다. Gherkin이 차지하고 있던 번역 계층은 이제 모델 그 자체입니다. 번역할 단계(step)가 없기 때문에 단계 정의(step definition)도 존재하지 않습니다. AI는 의도(intent), 코드, 그리고 도메인 모델(domain model)을 직접 읽습니다.

과거에는 기능 파일(feature file)에 단계 정의 라이브러리(step-definition library), Cucumber 러너(runner), 그리고 이 모든 것을 하나로 묶어줄 CI 작업(CI job)이 필요했지만, 이제는 단 한 문장과 테스트 파일 하나면 충분합니다.

이것은 점진적인 개선이 아닙니다. 시장 자체가 사라지는 것입니다.

BDD는 Gherkin이 아니다

정확하게 짚고 넘어갈 가치가 있습니다. 왜냐하면 이 글에 대한 가장 강력한 반박은 다음과 같을 것이기 때문입니다: "당신은 실천법으로서의 BDD와 도구로서의 Cucumber를 혼동하고 있습니다."

타당한 비판입니다. 둘은 같은 것이 아니며, 이러한 분리야말로 이 논증을 명확하게 만들어 줍니다.

**실천법으로서의 BDD(BDD the practice)**는 발견 대화(discovery conversations), 예시를 통한 명세(specification by example), 예시 매핑(Example Mapping), 삼총사 정제(three-amigos refinement), 유비쿼터스 언어(ubiquitous language), 그리고 행동 프레이밍(behavior framing)을 포괄합니다. 이것은 생존합니다. 어쩌면 번창할지도 모릅니다. 이것들은 팀이 소프트웨어가 무엇을 해야 하는지에 대해 함께 생각하는(thinks together) 방식을 설명하며, 역할이 압축된 세상에서는 함께 생각하는 것이 덜 중요한 것이 아니라 오히려 더 중요해집니다. 다만 그 모습이 이제는 달라 보일 뿐입니다. 라이브 문서(live doc)를 바탕으로 15분간 정제 작업을 수행하는 소규모 스쿼드(lean squad), 테스트에 직접 구체적인 예시를 작성하는 프로덕트 엔지니어(product engineer), 그리고 AI를 또 다른 삼총사(amigo)로 삼아 예시 매핑을 수행하는 1인 운영자(solo operator)의 모습으로 말입니다.

**BDD 툴링 (tooling)**은 Gherkin을 승인된 명세 언어 (specification language)로 사용하고, 단계 정의 (step-definition) 코드베이스, Cucumber 스타일의 러너 (runner), 살아있는 문서 생성기 (living-documentation generators), 그리고 비개발자가 시나리오를 읽고 편집할 것이라는 전제하에 판매되는 전체 아티팩트 스택 (artifact stack)을 다룹니다. 하지만 이것은 생존하지 못합니다. 혹은 PRD가 Linear 문서로 생존하는 방식처럼 압축된 형태로만 생존할 뿐입니다. BDD 툴링은 특정 조정 비용 (coordination costs)을 수반하는 특정 역할 형태 (role shape)를 지원하기 위해 구축되었으며, 그 두 가지 모두가 변하고 있습니다.

따라서 이 글에서 "BDD는 조정 비용 (coordination tax)이었다"라고 말할 때, 재산정되고 있는 비용은 관행 (practice)이 아니라 _툴링과 아티팩트 오버헤드 (tooling and artifact overhead)_를 의미합니다. 관행은 결코 비용이 아니었습니다. 관행은 그저 훌륭한 제품 사고 (product-thinking)일 뿐이며, 훌륭한 제품 사고는 팀의 형태, 툴 체인 (tool chains), 그리고 AI 역량 전반에 걸쳐 잘 전달됩니다.

많은 BDD 도입 기업들이 저지른 실수는 툴링을 관행과 동일시하여, 피처 파일 (feature files)을 작성하지 않으면 "BDD를 하고 있지 않다"라고 주장한 것입니다. 이러한 혼동이 가치 있는 일련의 아이디어들을 하나의 의식 (ritual)으로 변질시켰습니다. 의식을 제거하고 관행을 유지한다면, 압축된 역할의 팀 (compressed-role teams), AI 증강 (AI augmentation), 그리고 절제된 TDD (TDD)와 깔끔하게 결합되는 무언가가 남을 것입니다.

끝나고 있는 것은 의식이지, 관행이 아닙니다.

여전히 적합한 곳

예외 사항에 대해서는 솔직해져야 합니다.

규제 산업 (금융, 의료 기기, 항공우주, 국방)은 종종 명세가 비개발자가 승인할 수 있는 형식으로 인간이 읽을 수 있어야 한다는 엄격한 요구 사항을 가집니다. 감사 추적 (Audit trails)은 도구 중립적인 아티팩트 (tool-neutral artifacts)를 요구합니다. 컴플라이언스 체계 (Compliance regimes)는 때때로 BDD 툴링이 부산물로 생성하는 것과 정확히 같은 종류의 피처 파일 출력을 의무화하기도 합니다.

조직도, 보안 승인, 또는 규제 구조에 의해 역할 경계가 강제되는 진정으로 사일로화된 (siloed) 기업들은 조정 비용을 계속 지불할 것입니다. 왜냐하면 그 대안이 더 나쁘기 때문입니다. 하지만 그곳에서조차, 변화의 방향은 더 작은 스쿼드 (squads)와 리포지토리(repos) 및 서비스 전반에 걸친 엔지니어 수준의 협업을 향하고 있으며, 이는 시간이 지남에 따라 기존 협약의 전제를 잠식해 나갈 것입니다.

제품(Product), QA, 엔지니어링이 서로 다른 속도(cadence)로 작동하며, 규약 문서(treaty document)가 실제로 사용 가능한 가장 저렴한 동기화 메커니즘인 대규모 교차 기능 프로그램(cross-functional programs)들이 있습니다.

그러한 맥락에서 BDD 툴링은 제 역할을 다합니다. 변화하는 부분은 바로 _기본적인 가정(default assumption)_입니다.