제 11강. 망한 바이브 코딩 살리는 법

꿀팁 — 이것만 알면 시킬 수 있다

앱이 터졌다. 어제 되던 로그인이 안 된다. 결제가 두 번 빠진다. 코드를 건드릴수록 다른 곳이 깨진다. AI에게 “고쳐"라고 시키면 더 망가진다.

새로 만들지 마라. 새로 만들어도 3개월 뒤 같은 곳에서 터진다. 지금 상태를 먼저 잠가라.

구조 도구 세 개가 있다:

• codistill — 진단. 기존 코드에서 API 엔드포인트, DB 스키마, 인증 흐름을 자동으로 추출한다.
• huma — 잠금. 모든 엔드포인트에 회귀 테스트를 걸어서 현재 동작을 보호한다.
• yongol — 전환. SSOT에서 새 백엔드를 생성하고, 기존 테스트로 동일 동작을 증명한다.

왼쪽부터 오른쪽으로 진행한다. codistill로 진단하고, huma로 잠그고, 준비됐을 때 yongol로 전환한다.

에이전트에게: “codist scan을 실행해서 이 프로젝트의 엔드포인트, DB 스키마, 인증 흐름을 추출해.”

현황이 나온다. 25개 엔드포인트 중 몇 개가 살아있고 몇 개가 죽어있는지 보인다.

에이전트에게: “huma verify를 실행해서 모든 엔드포인트의 상태를 확인하고, 살아있는 것마다 Hurl 테스트를 작성해.”

이것이 회귀 테스트다. 지금 작동하는 것을 잠근다. 이 테스트가 통과하는 한, 에이전트가 코드를 수정해도 기존 동작이 깨지지 않는다.

에이전트에게: “이제 로그인 버그를 고쳐. 단, Hurl 테스트 전부 통과해야 해.”

버그를 고치되 다른 곳을 깨뜨리지 않는다. 래칫이 걸린 상태에서 수리하는 것이다.

찍먹 체험

터진 앱이 없어도 체험할 수 있다. “만들고 → 부수고 → 살리는” 과정을 3분 만에 경험한다.

1단계 — 앱을 만든다

Claude Code에서:

“간단한 할 일 목록 API를 만들어. 엔드포인트 5개: 할 일 목록 조회, 할 일 추가, 할 일 수정, 할 일 삭제, 할 일 완료 처리. 서버를 띄워.”

2단계 — codist로 진단한다

“codist scan을 실행해서 이 프로젝트의 엔드포인트 목록을 추출해.”

codist가 5개 엔드포인트의 경로, 메서드, 파라미터를 자동으로 뽑아낸다. 이것이 현재 지도다.

3단계 — huma로 잠근다

“huma verify를 실행하고, 모든 엔드포인트에 Hurl 테스트를 작성해.”

5개 엔드포인트 각각에 Hurl 파일이 생긴다. 현재 동작이 잠겼다.

4단계 — 일부러 부순다

“할 일 수정 엔드포인트의 응답 형식을 바꿔. title 필드를 name으로 변경해.”

바꾼 뒤:

“Hurl 테스트를 실행해.”

테스트가 실패한다. “title을 기대했는데 name이 왔다.” 드리프트가 잡혔다. 래칫이 작동하는 순간이다.

5단계 — 래칫 걸린 상태에서 수리한다

“Hurl 테스트가 전부 통과하도록 수정해. 하지만 name 필드를 쓰는 새 기능도 유지해야 해.”

에이전트가 하위 호환성을 유지하면서 수정한다. Hurl이 통과하면 기존 동작이 보존된 것이다.

이것이 codistill → huma → 수리의 축소판이다. 실제 터진 앱에서는 이 과정이 25개, 50개, 200개 엔드포인트로 확대될 뿐 원리는 같다.

왜 이렇게 시켜야 하는가

도입: 당신의 앱이 터진 진짜 이유

2025년, Lovable로 만든 170개 앱의 데이터베이스가 인터넷에 통째로 노출됐다. 이메일, API 키, 결제 정보. 원인은 코드 버그가 아니었다. AI가 보안 정책을 빠뜨린 채 앱을 만들었고, 아무도 검증하지 않았다.

2026년 1월, AI 소셜 네트워크 Moltbook에서 150만 API 토큰이 유출됐다. 같은 원인. AI가 만들고, 사람이 확인하지 않았다.

이것은 남의 이야기가 아니다. 바이브 코딩으로 앱을 만든 사람이라면 같은 구조 위에 앉아 있다.

“로그인 만들어” — 30초. “결제 붙여” — 2분. “관리자 대시보드 추가해” — 5분. 3개월이 지나면 AI가 결제 로직을 “정리"하면서 할인 계산을 바꾸고, 새 기능을 추가하면 인증이 깨지고, 어제 되던 페이지가 오늘 500 에러를 반환한다.

당신은 두 가지 선택지 앞에 서 있다:

1. 새로 만든다
2. 살린다

새로 만드는 건 3개월 전에도 할 수 있었다. 문제는 다시 만들어도 같은 패턴이 반복된다는 것이다. 드리프트는 코드의 문제가 아니라 구조의 문제이기 때문이다.

살리는 법을 배워야 한다.

조난자 셀프구조법 — 5단계

터진 앱을 살리는 과정은 등산 조난 대응과 같다. 뛰지 마라. 현재 위치를 파악하고, 안전을 확보하고, 한 걸음씩 이동하라.

1단계. 진단 — 지금 뭐가 살아있는가

가장 먼저 할 일은 코드를 고치는 것이 아니다. 현황을 파악하는 것이다.

에이전트에게: "이 프로젝트의 모든 API 엔드포인트를 스캔해.
각 엔드포인트에 실제로 요청을 보내서 
응답 상태 코드를 기록해.
결과를 표로 정리해: 경로, 메서드, 상태코드, 응답시간."

25개 엔드포인트 중 18개가 200을 반환하고, 4개가 401이고, 3개가 500이라면 — 이것이 현재 지도다. 지도 없이 수리를 시작하면 고친 곳이 다른 곳을 깨뜨린다.

codistill의 codist scan이 이 작업을 자동화한다. 기존 코드에서 엔드포인트, 데이터 모델, 인증 흐름을 추출한다.

2단계. 잠금 — 살아있는 것을 먼저 보호한다

진단이 끝나면, 살아있는 엔드포인트를 잠근다.

에이전트에게: "200을 반환하는 18개 엔드포인트 각각에 
Hurl 테스트를 작성해.
현재 응답 그대로를 기대값으로 잡아.
인증이 필요한 것은 로그인 시퀀스를 먼저 실행해서 
토큰을 받아 사용해."

이 18개 Hurl 파일이 안전망이다. 이후 어떤 수정을 하든, 이 테스트가 통과하면 기존 동작이 보존된 것이다.

huma의 huma verify가 이 과정을 체계화한다. 엔드포인트별로 상태를 추적하고, PASS/IMPROVE/FAIL을 판정한다.

중요: 부분 잠금은 안 된다. 18개 중 10개만 잠그면, 나머지 8개는 수리 중에 깨져도 모른다. 전량 잠금이 원칙이다.

3단계. 수리 — 래칫 걸린 상태에서 고친다

안전망이 있으니 이제 버그를 고칠 수 있다.

에이전트에게: "로그인이 실패하는 원인을 찾아서 고쳐.
단, 모든 Hurl 테스트가 통과해야 해.
하나라도 실패하면 수정을 되돌려."

이것이 6강에서 배운 Ratchet Pattern의 실전 적용이다. 고치되 깨뜨리지 않는다. 하나를 수리할 때마다 Hurl을 돌린다. 통과하면 다음 버그로. 실패하면 되돌린다.

500 에러를 반환하던 3개 엔드포인트도 같은 방식으로 수리한다. 수리가 끝나면 새 Hurl 테스트를 추가한다. 래칫이 한 칸 더 잠긴다.

4단계. 추출 — 블랙박스에서 로직을 꺼낸다

여기가 핵심이다. 앱이 터진 근본 원인은 보통 여기에 있다.

Supabase를 쓰고 있다면:

• RLS 정책이 대시보드에만 있고 코드에 없다
• Edge Functions에 비즈니스 로직이 숨어 있다
• 인증 로직이 Supabase Auth에 묶여 있다

Firebase를 쓰고 있다면:

• Security Rules가 콘솔에만 있다
• Cloud Functions에 로직이 분산되어 있다

어떤 BaaS를 쓰든 같은 구조다. 비즈니스 로직이 코드베이스 밖에 있다.

에이전트에게: "Supabase 대시보드에서 모든 RLS 정책을 추출해.
각 테이블의 SELECT, INSERT, UPDATE, DELETE 정책을 
SQL 파일로 저장해. git에 커밋해."

에이전트에게: "Edge Functions의 비즈니스 로직을 분석해.
어떤 함수가 어떤 비즈니스 규칙을 구현하는지 
문서로 정리해."

블랙박스 안의 로직을 코드베이스로 꺼내는 것이다. 꺼내야 에이전트가 읽을 수 있고, 테스트할 수 있고, 래칫으로 잠글 수 있다.

codistill의 codist ddl이 기존 DB에서 DDL을 추출한다. codist scan이 코드에서 SSOT를 추출한다. 블랙박스에서 선언적 레이어로 옮기는 도구다.

5단계. 전환 — 준비됐을 때만

1~4단계를 마치면 앱은 이런 상태다:

• 모든 엔드포인트에 Hurl 회귀 테스트가 있다
• 버그가 수리되었다
• 블랙박스의 로직이 코드베이스에 문서화되었다
• 래칫이 걸려있어 새로운 수정이 기존 동작을 깨뜨리지 않는다

이 상태에서 전환을 결정한다. Supabase에서 자체 백엔드로, Deno에서 Go로, 무엇이든.

전환의 안전망은 2단계에서 작성한 Hurl 테스트다. 새 서버에 같은 Hurl을 돌려서 전부 통과하면 — 레거시와 동일하게 동작하는 것이 증명된다.

에이전트에게: "yongol generate로 Go+Gin 백엔드를 생성해.
기존 Hurl 테스트 전부 통과시켜."

전환은 5단계이지 1단계가 아니다. 1단계에서 전환을 시도하면 실패한다. 사고당 온보딩에서 확인된 교훈이다.

Supabase에서 빠져나오는 법

11강의 가장 빈번한 사례가 Supabase다. 바이브 코딩으로 시작해서, Supabase에 올인하고, 3개월 뒤 터진다.

빠져나오는 순서:

1. DB는 유지하고 래칫만 건다

Supabase의 PostgreSQL은 그대로 쓴다. DB를 바꾸는 건 마지막이다.

codist ddl → 기존 테이블에서 DDL 추출
huma verify → 엔드포인트 현황 파악
hurl → 살아있는 API를 전량 잠금

2. 로직을 코드로 옮긴다

RLS 정책 → Rego 파일로. Edge Functions → SSaC 어노테이션으로. 대시보드에서 코드베이스로 이동.

3. 인증을 분리한다

Supabase Auth는 가장 마지막에 떼어낸다. auth.users의 비밀번호 해시를 추출할 수 없으므로, 초창기(고객 없음)라면 즉시 전환하고, 고객이 있으면 이중 인증 기간을 운영한다.

4. 새 서버를 올리고 Hurl로 검증한다

yongol generate → Go+Gin 백엔드 생성
hurl 전량 실행 → 레거시와 동일 동작 증명

Hurl이 전부 통과하면 트래픽을 전환한다.

왜 새로 만들면 안 되는가

“그냥 새로 만들면 안 돼?”

안 된다. 세 가지 이유:

1. 같은 패턴이 반복된다

드리프트는 코드의 문제가 아니라 구조의 문제다. 래칫 없이 새로 만들면 3개월 뒤 같은 지점에서 터진다.

2. 레거시에 지식이 묻혀 있다

3개월간 바이브 코딩하면서 쌓인 비즈니스 규칙이 코드에 있다. 새로 만들면 이 규칙을 기억에서 재구성해야 한다. 기억은 틀린다.

3. 고객이 이미 있을 수 있다

프로토타입이 프로덕션이 되는 순간이 있다. 사용자가 1명이라도 있으면 “새로 만들기"는 데이터 마이그레이션, 인증 전환, 다운타임을 동반한다.

살리는 법을 배우는 것이 새로 만드는 법을 배우는 것보다 가치 있다. 왜냐하면 레거시는 항상 존재하고, 새 코드도 6개월이면 레거시가 되기 때문이다.

10강까지 배운 것과 11강의 관계

같은 도구, 반대 방향. 1~10강이 “위에서 아래로” (선언 → 생성) 였다면, 11강은 “아래에서 위로” (기존 코드 → 추출 → 선언) 이다.

codistill이 이 “아래에서 위로"를 자동화하는 도구다. 기존 코드에서 SSOT를 짜낸다.

조난자에서 구조자로

이 과정을 마치면 당신은 두 가지 능력을 가진다:

1. 처음부터 만드는 법 (1~10강) — 선언하고, 검증하고, 잠그고, 영속한다
2. 망한 것을 살리는 법 (11강) — 진단하고, 잠그고, 수리하고, 추출하고, 전환한다

세상의 코드 대부분은 레거시다. 처음부터 만드는 프로젝트는 드물다. 살리는 능력이 더 자주 쓰인다.

바이브 코딩은 끝나지 않았다. 고삐를 잡는 법을 배운 것이다.

연관 글

• Supabase는 바이브 코딩의 함정이다 — 11강의 이론적 배경. 왜 BaaS에서 터지는가.
• Hurl이 바이브 코딩의 드리프트를 막는다 — 2단계 잠금의 상세.
• codistill — 기존 코드에서 SSOT를 짜낸다 — 1단계 진단, 4단계 추출의 도구.
• huma — 엔드포인트를 한 개도 빠뜨리지 않는 래칫 — 2단계 잠금의 도구.
• yongol — AI 코딩 SaaS의 용골 — 5단계 전환의 도구. SSOT에서 풀스택 생성.
• 에이전트가 일할 수 있는 코드베이스 — 블랙박스를 공장으로 바꾸는 원리.
• tsma — 레거시 코드의 회귀 방어선 — 래칫 걸린 상태에서 수리하는 법.
• 에이전트 운용 가능한 시스템 구축 — 잠긴 레거시를 에이전트가 닿을 수 있게 만드는 법.

Reins Engineering 전체 강의

출처

• Feathers, M. (2004). Working Effectively with Legacy Code. Prentice Hall. — Characterization testing의 원전. 레거시 코드에 테스트를 감싸서 현재 동작을 잠그는 기법. 11강 2단계의 이론적 기초.
• CVE-2025-48757 (2025). Lovable 생성 앱 170+ RLS 누락으로 Supabase DB 노출. ameeba.com
• OG William (2026). “Moltbook Hack: Supabase Vibe Coding.” 1.5M API 토큰 노출. blog.ogwilliam.com
• Cursino, D. et al. (2026). “Speed at the Cost of Quality? The Impact of AI Coding on Software.” MSR 2026. arxiv.org/abs/2511.04427 — Cursor 도입 후 코드 복잡도 41.6% 영구 증가. 바이브 코딩이 터지는 정량적 근거.
• Liu, Z. et al. (2026). “Debt Behind the AI Boom: A Large-Scale Empirical Study of AI-Generated Code in the Wild.” arxiv.org/abs/2603.28592 — 6,299개 리포지토리, 302,600건 AI 커밋 분석. 미해결 기술 부채가 2025년 초 수백 건에서 2026년 2월 110,000건 이상으로 급증.
• Storey, M.-A. (2026). “From Technical Debt to Cognitive and Intent Debt.” arxiv.org/abs/2603.22106 — 드리프트의 근본 원인을 “인지 부채”(공유 이해 침식)와 “의도 부채”(근거의 미외부화)로 이론화.
• Nguyen, H. et al. (2025). “Vibe Coding in Practice: Flow, Technical Debt, and Guidelines for Sustainable Use.” arxiv.org/abs/2512.11922 — 바이브 코딩의 flow-debt 트레이드오프를 문서화한 최초의 학술 논문.
• Cloud Security Alliance (2026). “Vibe Coding Security Crisis: Credential Sprawl and SDLC Debt.” labs.cloudsecurityalliance.org — AI 생성 코드의 45%가 OWASP Top 10 취약점 포함. AI 커밋의 시크릿 노출률 2배.
• GitClear (2025). “AI Copilot Code Quality 2025.” gitclear.com — 2.11억 라인 분석. 코드 중복 4배 증가, 리팩토링 비율 25% → 10% 감소.
• Encore (2026). “Backend as a Service (BaaS) in 2026: Providers, Tradeoffs, and Migration Paths.” encore.dev — BaaS 이탈은 포팅이 아니라 백엔드 재작성.