저는 지난 몇 주 동안 AI 도구(Lovable, Bolt, Cursor, Replit, v0 등)로 구축된 앱들의 보안 문제를 살펴보았습니다. 사람들은 다르고, 제품도 다르고, 사용 스택도 다릅니다. 하지만 거의 매번 같은 다섯 가지 취약점이 나타납니다.

이것은 도구들이 나쁘다는 의미가 아닙니다. AI 코딩 어시스턴트가 **'데모를 작동시키는 것'**에 최적화되어 있을 뿐, **'인터넷에 올려도 안전하게 만드는 것'**에는 그렇지 않기 때문입니다. 이 두 목표 사이의 간극이 바로 여러분을 위험에 빠뜨리는 지점입니다.

여기서 자주 발견되는 다섯 가지 취약점과 그 모습, 그리고 여러분 자신의 앱을 점검하는 방법을 알려드립니다.

1. 프론트엔드 번들에 노출된 비밀 키(Secret keys sitting in the frontend bundle)

가장 흔하고 심각한 문제입니다. AI는 API를 호출해야 하므로, 키를 클라이언트 측 코드에 그대로 넣어버립니다:

// 이 코드는 모든 방문자의 브라우저로 전송됩니다.
const supabase = createClient(url, SERVICE_ROLE_KEY);
const stripe = new Stripe("sk_live_51H...");

프론트엔드 번들에 있는 것은 모두 공개적입니다. DevTools → Sources를 열거나 view-source를 사용해 보면 바로 보입니다. service_role 키나 브라우저에 노출된 sk_live_ 비밀 키는 누구나 여러분의 전체 데이터베이스를 읽고 쓰거나, 여러분을 사칭하여 결제 제공업체(payment provider)에 접근할 수 있다는 의미입니다.

사람들이 헷갈리는 미묘한 차이: 모든 키가 비밀인 것은 아닙니다. Supabase의 anon 키(sb_publishable_...), Firebase의 apiKey, 또는 Stripe의 publishable 키(pk_live_)는 접근 규칙(access rules)만 정확하다면 프론트엔드에 공개되는 것이 설계된 방식이며 안전합니다 (2번 참고). 위험한 것은 service_role, sk_live_/sk_test_, 그리고

-- 테이블이 생성되었고, RLS가 활성화되지 않았으므로 = 전체 테이블이 공개됨
create table orders (id uuid, user_id uuid, total numeric, card_last4 text);

anon 키가 프론트엔드에 있는 경우(정확하게!), 외부인이 콘솔을 열고 다음 코드를 실행할 수 있습니다:

const { data } = await supabase.from('orders').select('*'); // 모든 사람의 주문 내역

점검: Supabase 대시보드에서 public 아래의 모든 테이블은 **RLS가 활성화됨(RLS enabled)**이라고 표시되어야 하며, 정책이 실제로 사용자를 범위로 제한해야 합니다 (auth.uid() = user_id).

확인: 배포된 URL을 모든 헤더 검사기(headers checker)나 브라우저의 DevTools → Network → 문서를 클릭 → Response Headers에서 실행해 보세요.

실제로 이것들을 모두 확인하는 방법

위 목록은 수동으로 점검할 수 있습니다 — 그리고 솔직히 말해서 각 항목을 이해해야 합니다. 하지만 더 빠르게 검사하고 싶다면, AI로 생성된 앱에 특화된 스캐너 전체 카테고리가 생겼습니다. 이들은 두 가지 유형으로 나뉩니다:

• URL 스캐너: 배포된(deployed) 앱을 탐지합니다 (코드를 공유할 수 없거나 원하지 않을 때 유용).
• 코드 인식 스캐너(Code-aware scanners): 소스 코드를 읽습니다.

저는 실제로 주요 옵션들 — VibeSafe, Vibe App Scanner, CheckVibe, Snyk, Semgrep, AuditYourApp — 을 비교한 글을 작성했습니다. 어떤 상황에 무엇이 적합하고 각각의 단점은 무엇인지 포함되어 있습니다: 최고의 Vibe 코딩 보안 스캐너 (2026).

완전 공개: 저는 그 비교에 있는 도구 중 하나인 VibeSafe에서 일하고 있습니다 — 이 도구는 코드와 라이브 URL을 모두 스캔하여 문제를 쉬운 영어로 설명해 주기 때문에 제가 자주 사용합니다. 하지만 이 비교는 의도적으로 공정하며, 많은 사람들에게는 Snyk나 무료 URL 검사가 올바른 선택일 수 있습니다. 출시한 후에가 아니라 전에 확인할 수 있는 것을 사용하세요.

핵심 요약

만약 AI로 무언가를 만들었고 이 게시물에서 단 한 가지만 할 것이 있다면: Supabase 테이블에 실제 RLS 정책이 있는지, 그리고 프론트엔드에 service_role/sk_live_ 키가 없는지 확인하세요. 이 두 가지가 제가 'vibe-coded' 앱에서 본 심각한 침해 사고의 대부분을 다룹니다.

빨리 출시하세요 — 주소를 건네주기 전에 잠금장치를 확인하기만 하세요.

AI로 만든 앱에서 어떤 문제에 부딪혔나요? 댓글에 가장 이상했던 보안 문제를 남겨주세요.