Vibe Coding vs AI 기반 개발: 계약 문제 (and GS‑TDD)
Source: Dev.to
Vibe coding vs. AI‑driven development
대부분의 AI‑지원 코딩은 지금은… 분위기(vibe)일 뿐입니다.
기능을 요청하면 그럴듯한 diff를 받고, 컴파일이 되고, 도파민이 급상승하고, 이틀 뒤에 프로덕션이 해석적 춤을 추기 시작합니다.
그 실패 유형에는 이름이 있습니다: vibe coding.
제가 목표로 하는 것은 AI‑driven development입니다. 이를 AI‑Assisted Engineering이라고 부르든, (제가 태어난 덴마크에서는) AI‑drevet udvikling이라고 부르든 목표는 동일합니다: AI가 매일 소프트웨어를 설계하고 구현하도록 돕는 워크플로우이며, 인간은 정확성, 보안, 운영에 대한 완전한 책임을 유지합니다.
차이는 “어떤 모델을 쓰느냐”가 아니라 계약(contracts) 입니다.
Vibe coding은 신뢰 문제입니다
Vibe coding은 생성된 코드를 “아마 괜찮을 거야”라고 여기게 될 때 발생합니다. 그 이유는:
- 보기에 합리적이기 때문에
- 익숙한 패턴을 사용하고 있기 때문에
- 빠른 스모크 테스트를 통과했기 때문에
- 시간이 늦었고 집에 가고 싶기 때문에
AI는 그럴듯한 코드를 만드는 데는 뛰어납니다. 하지만 그럴듯한 코드가 올바른 코드와 동일한 것은 아닙니다.
워크플로우가 생성 → 배포라면, 여러분은 AI‑driven development를 하고 있는 것이 아닙니다. 확률적 배포를 하고 있는 겁니다.
AI‑driven development는 계약 문제입니다
신뢰할 수 있는 버전은 간단하지만, 규율이 필요합니다:
- 계약 정의 (인간)
- AI가 그 계약 내부에서 작업하도록 함 (기계)
- 결과를 성인처럼 검증 (인간 + CI)
“계약”은 수용 테스트, 단위 테스트, 불변식, 스키마, 타입, 혹은 이 모든 것이 될 수 있습니다. 테스트는 동작을 코딩하고, 크게 실패를 알리기 때문에 가장 보편적인 계약 형태입니다.
지루한 루프: Red → Gold → Refactor (GS‑TDD)
이를 실현하기 위해 저는 Gold Standard TDD (GS‑TDD) 라는 변형 TDD를 사용합니다. 기존의 Red–Green–Refactor 루프를 Red–Gold–Refactor 로 진화시킵니다.
| 단계 | 수행 내용 |
|---|---|
| Red | 동작을 정의하는 실패하는 테스트 스위트를 작성(또는 생성)합니다. 가능하면 BDD 스타일로 의도와 엣지 케이스를 명시합니다. |
| Gold | AI에게 Gold Standard 구현을 첫 번째 시도에서 생성하도록 지시합니다. 이는 생산 지향 설계여야 합니다. 즉: • 보안‑인식 기본값 • 유지보수 가능한 구조 • 견고한 오류 처리 및 경계 • 지루하고 표준적인 아키텍처 • MVP나 프로토타이핑 없음 |
| Refactor | 동작은 변하지 않도록 내부를 안전하게 개선합니다. |
핵심 변화: GS‑TDD는 “최소한의 Green”을 “Gold Standard”로 대체합니다. AI 덕분에 보일러플레이트 단계를 건너뛸 수 있기 때문입니다. 테스트(계약)가 AI를 정직하게 유지하고, “Gold” 프롬프트가 아키텍처를 깔끔하게 유지합니다.
방법론에 대해 더 깊이 알아보려면 제 연구 노트인 GS‑TDD를 확인하세요.
작은 예시 (워크플로우)
규칙을 추가한다고 가정해 보세요: “사용자는 3개 이상의 API 키를 생성할 수 없습니다.”
Red – 계약을 먼저 작성하기
it("limits API keys per user", async () => {
const user = await seedUser();
await createKey(user);
await createKey(user);
await createKey(user);
// This defines the contract: behavior AND error shape
await expect(createKey(user)).rejects.toThrow("API key limit reached");
});이제 테스트 스위트가 주인입니다.
Gold – 제약 조건 하에 생산 지향적인 첫 번째 시도를 AI에 요청하기
“이 기능을 구현하세요. 레이스 컨디션을 방지하기 위해 제한을 트랜잭션 방식으로 적용하고, 표준 도메인 오류 타입을 사용하며, 제한에 도달했을 때 구조화된 로그 라인을 추가하세요.”
“Gold” 코드는 첫 실행 시 테스트 한두 개가 실패할 수도 있습니다 — 괜찮습니다. 계약 내부에서 디버그하여 초록색이 될 때까지 진행하세요.
Refactor – 이름과 파일 구조 정리하기
AI는 모든 단계에서 도움을 줄 수 있지만 — 계약이 허용되는 범위를 결정합니다.
지루한 AI 체크리스트 (내가 실제로 따르는 8가지 규칙)
- 계약 정의 – 테스트는 반드시 유지되어야 할 것을 설명합니다.
- 검증, 신뢰하지 않기 – 로컬에서 테스트, 린트, 빌드를 실행합니다.
- 작은 차이점 선호 – AI는 큰 컨텍스트에서 더 많이 환각합니다; 변경을 검토 가능하게 유지하세요.
- 프롬프트를 차이점에 포함 – “왜”는 PR/문서에 넣고, 채팅 기록에는 넣지 마세요.
- 인간 코드처럼 검토 – 명명, 불변조건, 경계를 확인합니다.
- 위험한 가장자리 방어 – 인증, 데이터 손실, 보안 헤더, 속도 제한 등을 보호합니다.
- 프로덕션 모니터링 – 로그/메트릭/알림을 통해 변경이 정상 동작했는지 확인합니다.
- 롤백은 기능 – 배포 전에 변경을 어떻게 되돌릴지 알아두세요.
그게 전부입니다. 신비주의는 없습니다. 단지 빠른 속도의 지루한 검증일 뿐입니다.
“하지만 이게 그냥 TDD가 아니에요?”
어느 정도 — 하지만 동기가 조금 다릅니다.
전통적인 TDD는 인간이 명확하게 사고하고 잘 설계하도록 돕습니다. AI가 포함되면 테스트는 안전 레일이 되어 그럴듯한 헛소리가 메인에 들어가는 것을 막습니다.
AI 워크플로에 계약이 없다면, 배포 파이프라인은 가끔 보상을 주는 슬롯 머신과 같습니다.
전체 시리즈 읽기
저는 이 전체 방법론(및 “Ward” 개념)을 제 사이트에 문서화하고 있습니다.
코딩의 미래는 지루합니다: 작은 차이점, 명시적인 계약, 그리고 생산 환경에서의 놀라움이 적은 것. 바로 그런 미래가 우리가 배포할 가치가 있는 미래입니다.