AI 시대, Gherkin으로 탈출하는 스펙 관리법
- 마크다운(Markdown)이 AI 개발 워크플로우의 사실상의 스펙 언어가 되었지만, 실행할 수 있는 문법이나 검증 기능이 없어 스펙과 코드 불일치 문제가 발생하고 있습니다.\n- 거킨(Gherkin)의 Given/When/Then 구조는 사람이 읽는 명세와 머신이 실행할 수 있는 테스트를 같은 파일에 통합하여 살아있는 스펙을 실현합니다.\n- 시나리오 아웃라인(Scenario Outline)과 예제 테이블(Examples)을 이용하면 데이터 기반 테스트 케이스를 스펙 자체에 내장하여 명세와 테스트 통합을 달성할 수 있습니다.\n- AI/LLM 활용 시 고정 문법, 실행 가능한 수락 기준, 스펙과 코드 간 양방향 생성이라는 3가지 이점으로 AI 코드 생성 품질 향상을 기대할 수 있습니다.\n- 마크다운의 한계(과도한 상세함, 테이블-enumeration, 자주 바뀌는 요구사항)가 감지되면 거킨 전환 신호로 점진적 전환을 권장합니다
Markdown 대 Gherkin: 스펙의Execute 불가능성 문제
본문에 따르면 마크다운(Markdown)은 제목, 불릿 포인트, 테이블 등 유사 DSL(DSL-like) 구조를 제공하지만, 실제로는 자유 형식의 텍스트 문서에 불과합니다.
정적 문서(Static Document)의 한계: 코드가 변경되어도 마크다운은 자동으로 갱신되지 않으며, 아무도 변경 사항을 검증하지 않으면 스펙 부패(Spec Rot)가 발생합니다.
모호한 의도 표현: "사용자가 로그인해야 한다"는 문장은 다양한 구현을 허용하여 팀 간 소통 오류를 유발합니다.
반면 Gherkin의 Given/When/Then은 구문 하이라이팅(Syntax Highlighting)과 정형화된 어휘(Vocabulary)를 강제하여 해석의 여지를 줄입니다.
그러나 마크다운의 유연성이 오히려 장점으로 작용하는 상황도 있습니다: 초기 탐색 단계나 비기술 Stakeholder와 소통할 때에는 Gherkin의 규격화된 구조가 과도할 수 있습니다.
실제 프로젝트에서는 마크다운(초기 탐색) → Gherkin(안정화 단계)로 전환하는 것이 현실적입니다.
Gherkin 시나리오 아웃라인의 데이터 기반 테스트 패턴
글에서 강조하는 시나리오 아웃라인(Scenario Outline)과 예제 테이블(Examples)은 Gherkin의 핵심 기능으로, 동일 시나리오에 다양한 입력값을 적용하는 데이터 기반 테스트(Data-Driven Testing)를 구현한다.
본문의 할인 티어 예제처럼 \| tier \| total \| discount \| 테이블은 파라미터화된 시나리오(Parameterized Scenario)를 정의하며, 각 행이 독립적인 테스트 케이스로 변환됨
마크다운 테이블과의 본질적 차이: 마크다운 테이블은 참조용 데이터 나열에 그치지만, Gherkin 테이블은 실행 가능한 어설션(Executable Assertion)을 내포함
Examples 테이블에 행을 추가하는 것만으로 테스트 추가가 완료되어, 테스트 유지보수 비용(Test Maintenance Cost)을 획기적으로 절감
주의할 점: 예제 데이터가 많아질수록 테스트 실행 시간이 비례하여 증가하므로, 데이터Subset 선택(Data Subset Selection) 전략이 필요할 수 있음
AI/LLM 코드 생성을 위한 Gherkin의 구조적 이점
본문에 따르면 AI/LLM 기반 개발에서 Gherkin은 3가지 핵심 이점을 제공하며, 이는 프롬프트 엔지니어링(Prompt Engineering) 관점에서 중요하다.
고정 문법(Fixed Grammar): Gherkin의 어휘는 작고 well-documented되어 있어 LLM이 구조를 추측할 필요 없이 정확히 파싱 가능 → 환각(Hallucination) 방지에 기여
실행 가능한 수락 기준(Executable Acceptance Criteria): 생성된 코드를 Gherkin 시나리오로 즉시 검증 가능하여, 사람이 마크다운을 재읽고 판단하는 주관적 검토 Subjective Review) 회피
양방향 생성(Round-Trip Generation): 자연어 설명 → 시나리오 → 코드, 또는 코드 → 시나리오 역추적 모두 가능하여 반복적 개선(Iterative Refinement) 사이클 구축
그러나 이 이점들은 시나리오 품질(Scenario Quality)에 크게 의존하므로, 시나리오 작성자의 도메인 지식과 Gherkin 숙련도가 병목이 될 수 있음
BDD 도입의 함정: 협업 문화와 기술적 장벽
Gherkin/Cucumber는 도구 자체는 성숙했으나, 행동 주도 개발(Behavior-Driven Development) 도입에는 조직적 맥락이 중요하다.
글에서 언급되듯 "모든 BDD를 채택하거나 팀을 재구조화할 필요는 없다"는 조언은 실무적이다: 도메인 전문가(Domain Expert)와 개발자 간의 협업 문화가 전제되어야 Gherkin이 의미 있음
기술적 장벽: 비개발자인 Product Manager가 Given/When/Then 구조를 이해하고 올바르게 작성하려면 학습 곡선이 존재하며, 이 비용이 초기에 부담이 될 수 있음
도구 생태계: Cucumber는 Java, JavaScript, Ruby, Python 등 주요 언어 전반에서 지원되므로 특정 기술 스택에 종속되지 않음
핵심 트레이드오프: Gherkin 도입 비용(학습, 협업 조정) 대비 스펙 드리프트 방지 효과가 충분한지 프로젝트 특성(변경 빈도, 팀 규모, 이해관계자 다양성)을 기준으로 평가해야 함
