3개월의 벽

바이브 코딩으로 SaaS를 만든다. 처음에는 빠르다. “로그인 만들어” — 30초. “결제 붙여” — 2분. 3주 만에 MVP가 나온다.

3개월이 지나면 이상한 일이 생긴다. AI가 결제 로직을 “정리"하면서 할인 계산을 조용히 바꾼다. 새 엔드포인트를 추가했더니 기존 인증이 깨진다. 리팩토링을 시켰더니 공개 API의 필드명이 달라져서 모든 클라이언트가 죽는다.

이것을 로직 드리프트라고 부른다 — AI가 기존 비즈니스 로직을 비의도적으로 변경하는 현상. 회귀 버그는 전통적 개발에도 있다. 그러나 로직 드리프트는 다르다. 개발자가 의도하지 않은 변경이, 개발자가 인식하지 못하는 사이에, 코드 전체에 걸쳐 일어난다. 매 프롬프트가 새 컨텍스트 윈도우에서 시작되기 때문이다.

숫자로 보는 드리프트

이것은 감상이 아니다. 데이터가 있다.

속도의 대가는 복잡도다. Carnegie Mellon 연구팀이 807개 GitHub 저장소에서 Cursor 도입 전후를 비교했다 (MSR 2026). 도입 첫 달에 코드 추가량이 3~5배 증가했다. 2개월 후 속도 이점은 소멸했다. 남은 것은 정적 분석 경고 30% 증가, 코드 복잡도 41% 영구 증가.

빨라진 게 아니라 느려진 것이다. 비영리 AI 연구기관 METR이 16명의 숙련 오픈소스 개발자를 대상으로 무작위 대조 실험을 수행했다 (2025). 본인이 잘 아는 프로젝트에서 AI 도구를 사용한 그룹이 작업 완료까지 19% 더 오래 걸렸다. 그런데 개발자 본인은 20% 빨라졌다고 인식했다. 인식과 현실의 격차가 39%p. 새 프로젝트에서는 다를 수 있지만, “AI = 무조건 빠르다"는 가정이 깨진다.

규모가 커지면 안정성이 무너진다. Google DORA 보고서(2025)에 따르면, AI 도입이 25% 증가할 때마다 소프트웨어 전달 안정성이 7.2% 감소한다.

실제로 무너졌다. Amazon은 2025년 전사적으로 AI 코딩 도구 사용을 의무화하고 21,000개 AI 에이전트를 배포했다. 같은 기간 약 30,000명이 해고되어 리뷰 인력이 급감했다. AI 코딩 도구의 빠른 생성과 리뷰 인력 감축이 결합된 결과, 90일간 Sev-1 사고 4건이 발생했다. 2026년 3월 5일, 6시간 장애로 추정 630만 건의 주문이 손실되었다. 내부 문서는 이렇게 말했다: “GenAI의 빠른 코드 생성이 취약점을 우연히 노출하고 있으며, 현재 안전 조치는 완전히 부적절하다.”

“TDD를 하라"는 답이 아니다

바이브 코딩의 드리프트에 대한 흔한 조언은 “테스트를 짜라"이다. 방향은 맞지만, 어떻게 테스트를 주느냐가 결과를 갈른다.

TDAD 연구(arxiv 2026)가 이것을 정확히 실험했다. Qwen3-Coder 30B에게 SWE-bench Verified 100개 인스턴스를 풀게 했다.

조건회귀율
기본 (테스트 지시 없음)6.08%
“TDD를 하라"는 절차적 지시9.94% (악화)
영향받는 테스트 파일을 맥락에 제공1.82% (70% 감소)

“TDD를 하라"고 시키면 오히려 나빠진다. 에이전트는 절차적 지시를 따르려다 본래 작업에서 벗어난다. 그러나 “이 테스트 파일이 통과해야 한다"는 구체적 맥락을 주면 회귀가 70% 줄어든다.

차이는 명확하다. “어떻게 테스트하라"는 지시가 아니라, “무엇이 통과해야 하는가"라는 계약이 필요하다.

Hurl: 계약을 plain text로

Hurl은 HTTP 요청과 기대 응답을 plain text로 선언하는 테스트 도구다. Orange(프랑스 텔레콤)가 유지보수하고, Rust 바이너리로 런타임 의존성이 없으며, GitHub 18.7k 스타. CI에서 매 커밋마다 돌릴 수 있을 만큼 빠르다.

# 로그인 성공
POST http://localhost:8080/api/auth/login
{
  "email": "test@example.com",
  "password": "secret123"
}
HTTP 200
[Asserts]
jsonpath "$.token" exists
jsonpath "$.user.email" == "test@example.com"

# 인증 없이 접근 시 401
GET http://localhost:8080/api/pages
HTTP 401

두 개의 계약. 로그인은 200과 토큰을 반환해야 하고, 인증 없는 접근은 401이어야 한다.

이 파일이 git에 커밋되고, CI에서 매 커밋마다 실행되면 — AI가 인증 로직을 “정리"해서 401이 200이 되는 순간, 커밋이 거부된다. 드리프트가 프로덕션에 도달하기 전에 잡힌다.

왜 Hurl인가

단위 테스트도 드리프트를 잡을 수 있다 — AI에게 테스트 파일 수정 권한을 주지 않으면. 그러나 단위 테스트는 코드 내부의 함수를 검증하기 때문에 구현에 구조적으로 결합되어 있다. 함수명이 바뀌면 테스트도 깨지고, 리팩토링할 때마다 테스트를 함께 고쳐야 한다.

Hurl은 HTTP 경계에 있다. 요청과 응답만 선언한다. 코드의 내부 구조를 모른다. AI가 코드를 어떻게 바꾸든, 외부에서 관측 가능한 행위가 같으면 통과하고, 다르면 실패한다. 구현이 아니라 행위에 자연적으로 독립적이다.

단위 테스트Hurl
검증 대상함수 내부HTTP 계약
AI 리팩토링 시함께 변경됨불변
드리프트 감지조건부 (수정 금지 시)자연적
코드 구조 의존높음없음
사람이 읽기코드 수준plain text
LLM이 생성하기코드 구조 이해 필요HTTP만 알면 됨

Hurl이 검증하는 것은 코드가 아니라 행위다. 코드는 AI가 자유롭게 바꿔도 된다. 행위는 바뀌면 안 된다. 이 구분이 드리프트를 잡는 핵심이다.

래칫 잠금

Hurl 테스트가 통과하면 잠근다. 이것이 래칫이다.

1. 현재 API의 Hurl 테스트 작성 (또는 자동 추출)
2. CI에서 매 커밋마다 실행
3. 통과한 테스트는 삭제/수정 금지
4. 새 기능 추가 시 새 Hurl 테스트 추가
5. 기존 테스트 전부 + 새 테스트 전부 통과해야 머지

에이전트에게 “코드를 리팩토링해"라고 시키면, 에이전트는 자유롭게 코드를 바꾼다. 그러나 Hurl 테스트가 깨지면 커밋이 거부된다. 에이전트는 모든 기존 행위를 보존하면서 리팩토링해야 한다. Hurl이 커버하지 않는 엣지 케이스에서는 여전히 드리프트가 가능하지만, 커버된 행위에 대해서는 드리프트가 구조적으로 억제된다.

TDAD 연구의 발견과 정확히 일치한다. “테스트를 짜라"는 절차적 지시가 아니라, “이 Hurl 파일이 통과해야 한다"는 구체적 계약. 에이전트는 방법을 선택할 수 있지만, 계약을 위반할 수 없다.

레거시에도 적용된다

이미 바이브 코딩으로 프로덕션을 운영하고 있다면? 처음부터 다시 짤 필요 없다.

1단계: 현재 행위를 Hurl로 캡처한다.

API 문서가 있으면 그대로 Hurl로 옮긴다. 없으면 에이전트에게 기존 코드를 읽혀서 Hurl 테스트를 작성시킨다. 목표는 현재 API의 모든 엔드포인트에 대해 “이것이 지금 동작하는 방식이다"를 plain text로 선언하는 것이다.

2단계: CI에 건다.

모든 Hurl 테스트가 통과하는 것을 확인하고, 머지 조건에 추가한다.

3단계: 이제부터 안전하다.

AI에게 리팩토링을 시켜도, 새 기능을 추가해도, Hurl이 기존 행위를 보호한다. 드리프트가 발생하면 CI가 즉시 잡는다.

기초 공사가 아니라 내진 보강이다. 영업하고 있는 가게 문을 닫지 않고, 건물을 보강하는 것이다.

바이브 코딩의 종말이 아니라 진화

바이브 코딩을 만든 Andrej Karpathy 본인이 2026년 2월, 정확히 1년 후 “바이브 코딩 시대는 끝났다"고 선언했다. 새 패러다임은 에이전틱 엔지니어링 — 인간이 코드를 짜는 게 아니라, 에이전트를 조율하여 자율적으로 계획·구현·테스트하는 것.

Thoughtworks Technology Radar(2025)는 Spec-Driven Development를 “Assess” 등급에 배치했다. Martin Fowler 팀은 SDD 도구 분석을 발행했다. 업계가 같은 방향으로 수렴하고 있다.

Hurl 테스트는 이 전환의 가장 작은 단위다. 명세 10개를 쓸 필요 없다. OpenAPI를 배울 필요 없다. Hurl 파일 하나가 계약 하나다. 그리고 그 계약이 에이전트의 자유를 제한하지 않으면서, 드리프트를 구조적으로 막는다.

모델을 바꾸지 말고, 계약을 추가하라.

관련 글

출처