이제 우리 모두 오이(Cucumber)를 먹어야 할 때입니다!

이제 모두가 AI를 위한 명세서(specs)를 작성하고 있습니다. 우리는 모델에게 마크다운(markdown) 파일을 건네주고, 우리가 원하는 것을 말하며, 모델이 올바른 것을 만들어내기를 기대합니다. 대부분은 잘 작동합니다 — 작동하지 않을 때까지는 말이죠.

마크다운(Markdown)은 조용히 명세 언어가 되었습니다. 사람들은 제목, 글머리 기호 목록, 가끔 등장하는 표 등 AI 기반 워크플로우를 위한 DSL(Domain Specific Language, 도메인 특화 언어)로서 마크다운을 선택하며, 그 느슨한 구조를 마치 계약서인 것처럼 취급합니다. 문제는, 그것이 DSL이 아니라는 점입니다. 그것은 마크다운입니다. 강제할 문법도 없고, 실행 가능한 구조도 없으며, 공유된 어휘도 없고, 명세와 코드가 여전히 일치하는지 확인할 방법도 없는 산문 형식의 포맷일 뿐입니다. 여러분은 원래 설계되지 않은 용도로 문서 형식을 사용하고 있으며, 명세가 기계가 확인할 수 있는 실제적인 '의미'를 갖기를 원하는 순간 한계에 부딪히게 됩니다.

그 길로 가기 전에, 저는 작고 약간은 황당한 제안을 하나 하고 싶습니다.

오이(cucumber)를 드세요.

제가 실제로 의미하는 것

Gherkin은 행위 주도 개발(BDD, Behavior-Driven Development) 세계에서 수년간 존재해 온 도구인 Cucumber의 기반이 되는 평문(plain-text) 언어입니다. 다음과 같은 형태를 띱니다:

Feature: User login

  Scenario: Successful login with valid credentials
...

그게 전부입니다. Feature, Scenario, Given/When/Then. 기계가 파싱(parse)할 수 있을 만큼 충분히 구조화되어 있으면서도, 제품 관리자(product manager)가 작성할 수 있을 만큼 충분히 느슨합니다.

이것이 메우는 간극

대부분의 명세는 두 가지 극단 중 하나에 머물러 있습니다.

한쪽 끝에는 **작성된 명세(written specs)**가 있습니다: 문서, 티켓, 마크다운(markdown) 파일 등입니다. 누구나 읽을 수 있지만, 비활성 상태입니다. 그것들이 여전히 유효한지 확인해 주는 것은 아무것도 없습니다. 코드가 변경되는 순간 그것들은 부패합니다.

다른 쪽 끝에는 **테스트(tests)**가 있습니다: 정밀하고, 실행 가능하며, 항상 정직합니다 — 하지만 코드로 작성되어 있어, 실제 동작(behavior)에 관심을 갖는 사람들의 절반에게는 읽기 어렵습니다.

Gherkin은 그 중간에 위치합니다. Gherkin은 각 Given/When/Then 단계를 실제 코드와 연결할 수 있을 만큼의 최소한의 골격만을 갖춘 산문(prose)입니다. 동일한 파일이 사람이 읽을 수 있는 명세(spec)인 동시에, 테스트 러너(test runner)가 실행하는 대상이 됩니다. 동작(behavior)이 변경되면 시나리오가 실패합니다. 명세가 실제 상황으로부터 조용히 멀어질 수 없는 이유는, 명세 그 자체가 검증(check)이기 때문입니다.

사람들이 말하는 "살아있는 명세(living specs)"란 바로 이것을 의미합니다. 실행 가능하기 때문에 당신에게 거짓말을 할 수 없는 문서 말입니다.

이것이 AI 작업에 중요한 이유

코드를 생성하거나 검증하기 위해 LLM(대규모 언어 모델)에 명세를 제공하는 경우, Gherkin은 자유 형식의 마크다운(markdown) 파일이 제공하지 못하는 세 가지를 제공합니다.

• 고정된 문법 (A fixed grammar). 모델이 당신이 임의로 만든 구조를 추측할 필요가 없습니다. Gherkin의 어휘는 작고, 문서화가 잘 되어 있으며, 거의 확실하게 모델의 학습 데이터에 이미 포함되어 있습니다.
• 실행 가능한 인수 조건 (Executable acceptance criteria). AI가 코드를 생성할 수 있고, 당신은 즉시 시나리오를 실행하여 AI가 실제로 작업을 수행했는지 확인할 수 있습니다. 사람이 마크다운을 다시 읽으며 판단할 필요가 없습니다.
• 라운드 트립 (A round trip). 모델에게 설명을 바탕으로 시나리오를 작성하도록 하거나, 시나리오로부터 코드를 작성하게 하거나, 기존 코드가 시나리오를 충족하는지 확인하도록 요청할 수 있습니다. 각 방향은 명확하고 검증 가능한 결과물(artifact)을 가집니다.

당신은 마크다운에서 원했던 가독성을 얻는 동시에