나는 1,334개의 코딩 챌린지를 '바이브 코딩(vibe-coded)'했다. 아무도 말하지 않는 추악한 진실을 공개한다.

나는 몇 달 만에 Lovable, Supabase, 그리고 Claude를 사용하여 1,334개의 챌린지를 담은 코딩 플랫폼을 구축했습니다. 이런 종류의 빌드에 관한 대부분의 게시물은 하이라이트 영상과 같습니다. 하지만 이 글은 그렇지 않습니다. 실제로 무엇이 망가졌는지, AI가 무엇을 자신 있게 틀렸는지, 그리고 어떤 도구도 건드리지 못해 내가 직접 로우 코드(raw code)로 다시 작성해야 했던 세 가지는 무엇인지 알려드리겠습니다.

예상치 못했던 RLS 재앙

Lovable은 Supabase 테이블을 빠르게 생성합니다. 하지만 Row Level Security (RLS, 행 수준 보안)에 대해서는 생각하지 않습니다.

문제를 발견하기 전까지 2주 동안 사용자 진행 데이터가 계정 간에 유출되었습니다. 모든 사용자가 다른 모든 사용자의 챌린지 완료 내역을 조회할 수 있었습니다. AI는 테이블을 생성했고, 정책(policies)도 언뜻 보기에는 맞게 보였습니다 — 하지만 모든 정책의 조건이 using (true)였습니다. 완전히 열려 있었던 것입니다.

나는 구축을 완전히 중단하고, 모든 테이블을 감사(audit)했으며, 모든 RLS를 수동으로 다시 작성했습니다. 3일이 걸렸습니다. AI는 애초에 문제를 일으켰던 것과 똑같은 망가진 패턴을 계속해서 재생성했습니다.

교훈: 바이브 코딩(vibe coding) 도구를 당신의 보안 계층 근처에 절대 두지 마세요. RLS를 직접 작성하거나, 아니면 배포하지 마세요.

두 번이나 다시 만든 커리큘럼 구조

1,334개의 챌린지는 많아 보입니다. 문제는 사용자가 논리적으로 진행할 수 있도록 조직화하고, 부하가 걸려도 완료 추적이 무너지지 않도록 만드는 것입니다.

나의 첫 번째 스키마(schema)는 챌린지들을 하나의 테이블에 평면적으로(flat) 두었습니다. 간단했습니다. 하지만 틀렸습니다.

챌린지가 200개 정도 되자 정렬 로직이 엉망이 되었고 쿼리 속도가 느려졌습니다. 나는 노드/엣지(node/edge) 구조로 다시 구축했습니다 — 챌린지는 노드로, 의존성은 엣지로 구성했습니다. 이것은 Lovable이 자연스럽게 생성해내는 것이 아닙니다. 나는 마이그레이션 SQL(migration SQL)을 직접 작성했습니다.

4일이 지나갔습니다. Lovable은 더 나은 구조를 제안하는 대신 계속해서 더 많은 컬럼(column)을 제안했습니다.

AI가 끝내 제대로 구현하지 못한 엣지 함수(edge functions)

내가 Lovable이나 Claude에게 Supabase 엣지 함수(edge function)를 작성해 달라고 요청할 때마다, 격리된 환경에서는 작동하지만 프로덕션(production) 환경에서는 실패하는 코드를 생성했습니다. 잘못된 CORS 헤더, 부정확한 Deno 임포트(import) 패턴, 배포 시 깨지는 환경 변수(env variable) 접근 등이 문제였습니다.

저는 현재 프로덕션 환경에서 12개의 엣지 함수(edge functions)를 실행하고 있습니다. 이 12개 모두를 직접 손으로 다시 작성했습니다. AI가 유용한 시작점을 제공한 경우는 기껏해야 40% 정도였습니다. 나머지 경우에는 AI가 저를 적극적으로 오도했습니다. 아주 자신감 넘치고, 빠르게, 그리고 틀린 방식으로 말이죠.

이제 저만의 규칙이 생겼습니다: 엣지 함수(edge functions)는 순수 Deno로 작성하고, supabase functions serve를 사용하여 로컬에서 테스트하며, 세 번의 실제 배포를 통과하기 전까지는 생성된 함수를 절대 신뢰하지 않는 것입니다.

대규모로 경험해 본 '바이브 코딩(vibe coding)'의 실체

이것은 "원하는 것을 설명하면 작동하는 앱을 얻는 것"이 아닙니다. 오히려 다음과 가깝습니다: AI가 예측 가능한 70%를 작성하면, 여러분은 자신의 스택(stack)에 대한 실제 이해가 필요한 나머지 30%를 책임지는 것입니다.

그 30%는 항상 다음의 세 가지 요소입니다:

• 보안 (RLS, 인증 로직(auth logic), 서비스 역할(service role) 액세스)
• 하류(downstream)의 모든 것에 영향을 미치는 데이터 구조(data structure) 결정
• 경계를 넘나드는 모든 것 — 프론트엔드(frontend) → 엣지 함수(edge function) → 외부 API(external API)

만약 작고 금방 버릴 것을 만들고 있다면, 바이브 코딩(vibe coding)은 훌륭합니다. 하지만 실제 데이터가 있는 실제 사용자들에게 배포할 계획이라면, 첫날부터 이 세 가지 레이어(layer)를 직접 책임질 계획을 세우십시오.

여러분의 마지막 AI 빌드에서 무엇이 망가졌나요? 아래에 남겨주세요. 사람들이 저와 같은 벽에 부딪히고 있는지 궁금합니다.