2026년 1월 말. 개발자가 주말 동안 사회 네트워크를 출시했습니다. 전통적인 코드를 작성하지 않았습니다. 대신 프롬프트, 비전, 그리고 며칠 안에 아이디어를 작동 가능한 제품으로 바꾸는 AI만이 있었습니다. 플랫폼이 바이럴되었습니다. OpenAI 공동 창립자인 Andrej Karpathy는 이를 "최근에 본 가장 놀라운 과학 소설적인 takeoff-adjacent 일"라고 부릅니다.

그런데 보안 연구자가 브라우저 개발 도구를 엽니다.
몇 분 안에 그들은 평범한 자바스크립트에 있는 API 키를 찾았다 — F12를 누를 줄 아는 누구나 볼 수 있다. 그들은 그것을 생산 데이터베이스를 쿼리하는 데 사용한다. 로그인이 필요 없다. 특별한 도구가 필요 없다. 단순한 명령과 커피뿐이다.

반환된 것: 150만 개의 API 인증 토큰. 35,000개의 이메일 주소. 수천 개의私信. 전체 플랫폼 — 모든 에이전트, 모든 자격 증명, 모든 대화 — 넓게 열려 있습니다.

플랫폼은 Moltbook이라고 불렸습니다. 수정 사항은 나타나자마자 두 개의 SQL 문장이 필요했습니다.

이것은 나쁜 개발자에 대한 이야기가 아닙니다. 이것은 AI가 자동으로 채우지 않는 간극과 그것을 배포하기 전에 할 수 있는 일에 대한 이야기입니다.

모두를 사로잡는 환각

몇 년 전, 소프트웨어를 만드는 것은 아픈 장벽을 넘어야 했다. 문법, 프레임워크, 데이터베이스, API, Git, 배포 같은 것들을 배워야 했고, 그 과정에서 계속해서 문제를 만들었다. 기술 분야 외의 대부분의 사람들에게 소프트웨어 엔지니어링은 매우 작은 문을 가진 잠긴 방처럼 느껴졌다.

그런데 그때 AI가 나타났다.

이제 전통적인 프로그래밍 경험이 적은 사람도 주말 동안 SaaS 앱을 만들고, 데이터베이스를 프론트엔드에 연결하며, 결제를 통합하고, API를 배포할 수 있습니다. 모두 프롬프트만으로 가능합니다. 이 변화는 매우 특별하며, 저는 진정으로 놀라운 것이라고 생각합니다. 저도 바이브 코더입니다. 아이디어가 상상에서 작동하는 제품으로 빠르게 이동하는 것을 보는 흥분을 이해합니다.

하지만 AI가 생성한 소프트웨어 주위에 위험한 환상이 형성되고 있습니다: 앱이 작동하면 사람들은 그것이 안전하다고 생각합니다. 그것들은 같은 것이 아닙니다.

아름답게 디자인된 애플리케이션도 여전히 개인 사용자 데이터를 노출시킬 수 있으며, API 키를 유출시킬 수 있고, 권한 없는 접근을 허용할 수 있으며, 우연히 데이터베이스 보호 기능을 비활성화시킬 수 있지만, 모든 것이 매끄럽게 보이고 로그인 흐름도 완벽하게 작동할 때입니다. 보안 문제는 시각적인 기능 아래에 존재합니다. 바로 이것이 Moltbook에서 일어난 일입니다.

AI가 올바르게 이해하는 것과 조용히 건너뛰는 것

AI는 매우 잘 도와줍니다. 행복한 경로를 만드는 데 — 기능이 작동하며, 버튼이 반응하며, API가 데이터를 반환하며, 페이지가 렌더링됩니다. 그 부분은 정말 인상적입니다.
보안은 불행한 경로에 살아있습니다:

• 로그인하지 않고 데이터베이스를 쿼리하는 사람이 있을까요?
• 공격자가 브라우저에서 요청을 조작할까요?
• API 키가 페이지 소스에 보이는 경우는 어떨까요?
• 만약 누군가 등록 엔드포인트를 10,000번 반복해서 호출한다면 어떡할까요?

경험 많은 개발자들은 이런 질문을 자동으로 합니다. 지능이 뛰어나기 때문이 아니라, 수년간의 디버깅 중요한 문제 해결, 사후 분석, 낮은 위험 환경에서의 실수를 통해 천천히 형성한 습관 때문입니다.

AI는 구현 시간을 매우 크게 단축합니다. 올바른 보안 질문을 제기하기 위해 필요한 경험은 단축되지 않습니다. 그 격차가 침입이 발생하는 곳입니다.

그리고 명확히 하자: 이것은 초보자 문제만이 아니다. 경험 많은 개발자들도 AI가 출력 속도를 가속할 때 과신하게 될 수 있다. 왜냐하면 AI가 생성한 코드는 종종 매우 설득력 있어 보이기 때문이다. 설명은 자신감 있어 보인다. 아키텍처는 합리적으로 보인다. 기능은 올바르게 작동한다.

하지만 합리적인 코드는 안전한 코드와는 같지 않다.

Moltbook 분석: 실제로 무엇이 잘못되었는가

Moltbook은 Supabase를 기반으로 구축되었습니다. Supabase는 빠른 개발에 적합한 인기 있는 잘 문서화된 백엔드 서비스입니다. Supabase는 클라이언트 측에 노출된 공개 API 키와 함께 작동하도록 설계되었습니다. 그것은 의도적이며, 그 자체로 보안 실패는 아닙니다.

보안 실패는 그 키를 구성할 수 있는 작업입니다.

Supabase는 레벨 보안이라는 기능을 함께 제공합니다 — 사용자가 자신만의 데이터에만 접근할 수 있도록 보장하는 데이터베이스 설정입니다. 기본적으로 활성화되지 않습니다. 이를 켜야 합니다. 그리고 만약 당신이 vibe 코딩을 하고 AI가 보안에 대해 묻지 않고 작동하는 백엔드를 생성한다면, 그 단계가 결코 나타나지 않을 가능성이 높습니다.

Moltbook에서는 그렇지 않았습니다.

결과는: 기본적인 기술 지식만 있다면 누구나 전체 생산 데이터베이스를 쿼리할 수 있었습니다 — 모든 사용자의 자격 증명 정보, 개인 메시지, 인증 토큰 — 웹사이트에 명백히 보이는 키를 사용하여. 쓰기 접근 권한도 열려 있었으므로, 공격자는 로그인하지 않고 플랫폼의 모든 게시물을 편집할 수 있었습니다.

창립자의 공식 성명은 상황을 솔직하게 담고 있었습니다:"Moltbook을 위해 단 한 줄의 코드도 작성하지 않았습니다. 저는 기술 아키텍처에 대한 비전만 가지고 있었고, AI가 그것을 현실로 만들었습니다."

AI는 작동하는 플랫폼을 만들었습니다. 안전한 것은 만들지 않았습니다.

It Is Not Just Moltbook

Moltbook 이전 6개월 동안, Wiz의 보안 연구자들은 실제 기업들이 내부 인사 시스템, 고객 데이터베이스, 그리고 민감한 직원 데이터를 포함한 지식 베이스를 구축하는 데 사용하는 vibe 코딩 플랫폼인 Base44에 중요한 취약점을 발견했습니다.

결함은 놀라울 정도로 간단했습니다: 사용자 등록 및 인증을 위한 두 개의 API 엔드포인트는 전혀 인증이 필요하지 않았습니다. 앱의 공개 URL에 표시되는 값만 사용하여 연구자는 플랫폼의 어떤 사내 애플리케이션 내에서도 인증된 계정을 만들 수 있었습니다 — SSO 및 모든 다른 접근 제어를 완전히 무시하며.

대화를 바꾸는 세부 정보는 이것입니다:Base44 개발자들은 그 취약한 엔드포인트를 작성하지 않았습니다. 플랫폼이 작성했습니다. 개별 개발자들은 이 결함에 대한 통찰력이 없었습니다. 이것은 거의 아무도 이야기하지 않는 vibe 코딩 보안 위험의 두 번째 차원입니다. 첫 번째는 AI가 당신이 프롬프트할 때 생성하는 것이며, 두 번째는 당신의 코드와 독립적으로 플랫폼이 도입하는 것입니다.

두 가지 모두 중요합니다. 두 가지 모두 해결할 수 있습니다.

평범한 영어로 보안

보안이 두려워지는 이유 중 하나는 용어가 추상적이고 기술적으로 들리기 때문입니다. 대부분은 그렇지 않습니다. 가장 자주 나오는 개념들의 평범한 영어 번역은 다음과 같습니다:

보안은 마법이 아니다. 대부분의 경우 명백한 실수를 줄이고 실수가 발생했을 때 피해를 제한하고 사용자의 신뢰를 보호하는 것이다. 그것이 전부다.

AI가 일관되게 놓치는 다섯 가지 사항

이것들은 AI가 생성한 코드에서 반복적으로 나타나는 패턴들이다 — 이상한 경계 사례가 아니라 기본값으로. 각각에는 실질적인 해결책이 있다.

1. 클라이언트 측 코드에 API 키가 노출됨
AI가 앱을 외부 서비스에 연결하라고 요청하면, 그는 종종 자격 증명을 앞단 코드에 직접 넣습니다. 앞단 코드는 공개적입니다. 누구나 브라우저 개발 도구를 엽니다고 찾을 수 있습니다. 자동 스캐너들은 웹을 스크래핑하여 정확히 이런 것을 찾습니다.

해결책: Gitleaks를 실행하세요 코드를 푸시하기 전에. 이는 비밀을 검색하고 하나라도 찾으면 커밋을 차단합니다. GitHub의 내장 비밀 검색은 공개 저장소에서 자동으로 동일한 작업을 수행합니다 — 설정이 필요 없습니다.

2. 행 수준 보안이 활성화되지 않음
이것은 Moltbook 실패입니다. AI는 RLS를 사용하지 않고도 완전한 Supabase 스키마를 생성할 수 있으며, 그 이유는 RLS는 데이터 접근 모델을 이해해야 하기 때문입니다 — 누가 무엇을 볼 수 있어야 하는지 — 그리고 AI는 명시적으로 요청하지 않는 한 그 논리를 건너뛸 수 있습니다.

수정 방법: Supabase 대시보드에서 사용자 데이터를 포함하는 모든 테이블에서 RLS가 활성화되어 있는지 확인하세요. 그런 다음 정확히 누가 각 행에 접근할 수 있는지 정의하는 정책을 작성하세요. Supabase 문서에는 약 스무 분 소요되는 초보자 친화적인 완주 가이드가 있습니다.

-- Enable RLS on a table
ALTER TABLE agents ENABLE ROW LEVEL SECURITY;

-- Users can only read their own records
CREATE POLICY "owner_only"
ON agents FOR SELECT
USING (auth.uid() = owner_id);

3. 인증 없는 API 엔드포인트
AI는 요청에 응답하는 경로를 생성합니다. 이 경로에 인증을 추가할지 여부는 사용자가 요청했는지 여부와 AI가 해당 파일에 도달할 때까지 사용자의 이전 요구 사항을 기억했는지 여부에 따라 달라집니다.

해결책: 모든 API 경로를 검토하고 질문하세요: 로그인하지 않고 이 경로를 호출하는 경우 어떻게 되는가요? Bearer와 같은 도구들 코드베이스를 스캔하고 무보호 경로를 무료로 표시하세요. 더 나은 것은 미들웨어 레이어에서 인증을 적용하여 모든 경로가 기본적으로 보호되도록 하세요.

4. 앱의 잘못된 쪽에 있는 비밀
많은 AI 도구들은 비밀을 하드코딩하지 않고 환경 변수를 제안할 수 있습니다. 하지만 그들이 종종 놓치는 것은 클라이언트가 사용할 수 있는 변수(공개)와 서버만 사용할 수 있는 변수(개인적)의 차이입니다.

Next.js에서는 어떤 변수도NEXT_PUBLIC_는 클라이언트 자바스크립트에 포함되어 모두에게 보입니다. 당신의 OpenAI API 키, Stripe 비밀 키, 그리고 데이터베이스 자격 증명은 결코 그 접두사를 가지면 안 됩니다.

수정 방법: 프로젝트에서 NEXT_PUBLIC_를 검색하고 민감한 정보가 이를 사용하지 않는지 확인하세요. 서버 전용 비밀 정보는 접두사가 없습니다. 공개 구성 값 - 예를 들어 당신의 Supabase URL과 같은 값 - 은 안전하게 접두사를 사용할 수 있지만, RLS가 올바르게 구성되어 있을 때만 가능합니다.

5. 요청 제한 없음
AI는 요청에 응답하는 엔드포인트를 생성합니다. 요청하면 요청 제한을 추가하지 않습니다. 이는 등록 엔드포인트, 로그인 엔드포인트, 데이터 엔드포인트가 누구든 무제한의 요청을 수락할 것임을 의미합니다.

Moltbook에서는 이것이 단일 봇이 500,000개의 가짜 계정을 만들 수 있게 했습니다. 동일한 패턴은 밤새 API 할당량을 고갈시키고 프로젝트를 끝내는 청구를 발생시킬 수 있습니다.

수정 방법: Vercel을 사용 중이라면, 프로젝트의 보안 설정에서 요청 제한을 활성화하세요 — 다섯 분 걸리고 코드 작성이 필요 없습니다. Supabase의 경우, 동일한 옵션이 프로젝트 설정 아래에 있습니다. 공개하기 전에 이 작업을 수행하세요.

거의 모든 사람이 하는 실수: "나중에 보안을 강화하겠어"

이러한 사고방식은 이해할 수 있습니다. 학습할 때는 이미 배포(shipping)가 어렵다고 느껴질 수 있습니다. 보안은 자신의 미래 버전에 대한 고급 주제처럼 느껴질 수 있습니다.

문제는 불안전한 아키텍처가 매우 빨리 단단해지는 것입니다. 실제 사용자가 도착하면 기술 부채가 복합되고, 불안전한 패턴이 코드베이스를 통해 퍼지며, 누출된 비밀이 다시 숨길 수 없습니다. Moltbook 침입은 창립자가 나중에 보안을 수정하려고 계획했기 때문이 아니라, 플랫폼이 그 순간이 오기 전에 바이럴되었기 때문에 발생했습니다.

보안은 마지막에 추가된 장식적인 레이어가 아닙니다. 그것은 설계의 일부입니다. 이는 발표하기 전에 완벽함이 필요하다는 의미는 아닙니다. 그것은 보안 인식이 모든 것과 동시에 시작되어야 한다는 의미입니다.

당신의 보안 스택, 간단하게 유지됩니다

보안 엔지니어가 되어야 하는 것은 아닙니다. 짧은 체크리스트와 실행을 위한 자기 통제가 필요합니다.

여기서 시작하세요 — 총 1시간 이하로 걸립니다:

• GitHub 비밀 스캔 — 공개 저장소에서 기본적으로 활성화되어 있으며, 노출된 키를 자동으로 포착합니다
• Gitleaks — 푸시하기 전에 로컬에서 실행하세요; 비밀을 포함한 커밋을 차단합니다
• Supabase RLS — 대시보드의 모든 테이블에서 활성화하세요; 문서의 완료 과정을 따르세요
• Vercel Rate Limiting — 공개하기 전에 프로젝트 설정에서 활성화하세요
• Snyk 무료 계층 — 의존성을 검색하여 알려진 취약점을 찾고; VS Code와 통합됩니다

프로젝트가 더 중요해질 때:

• Semgrep — CI에서 불안전한 코드 패턴을 포착하는 정적 분석
• CodeQL — 깊이 있는 분석이 GitHub 풀 리퀘스트 워크플로우에 통합되었습니다
• 프리커밋 훅 — 위험한 커밋을 머신을 떠나기 전에 막습니다

이러한 도구들을 자동화된 두 번째 의견으로 생각하세요. AI가 빠르게 움직이는 초보 개발자라면, 보안 도구는 자동화된 리뷰어입니다. 그 조합은 직관에만 의존하는 것보다 훨씬 안전합니다 — 특히 빠르게 움직일 때 더욱 그렇습니다.

추가로 말씀드리자면: AI에게 질문해보세요

vibe coding 보안에서 가장 잘 활용되지 않는 기술 중 하나는 단순히 요청하는 것입니다. 사용자 데이터를 건드리는 어떤 기능도 배포하기 전에 이를 시도해보세요:

"이 코드를 보안 문제로 검토하십시오. 클라이언트 측 코드에 자격 증명이 노출되었는지, 데이터베이스 테이블에 행 수준 보안이 활성화되었는지, API 엔드포인트가 인증이 필요한지, 그리고 등록 및 데이터 엔드포인트에 요청 제한이 있는지 확인하십시오."

AI는 명시적으로 요청될 때 매우 능숙하게 보안 검토를 할 수 있습니다. 문제는 그 검토를 자동으로 적용하지 않는 것입니다. 요청하는 것을 습관으로 만드세요. 삼십초가 걸리며, 이를 포착하게 될 것입니다.

비판자들에게 공정한 심리를 보장하세요

vibe 코딩에 반대하는 사람들은 틀린 게 아니다. 그들은 실제 패턴을 지적하고 있으며: AI는 훈련된 개발자가 결코 건너뛰지 않을 가정을 건너뛰며 작동하는 코드를 생성한다. Moltbook과 Base44는 그에 대한 유효한 증거이다.

하지만 결론 — 전통적인 코딩 배경이 없는 사람들이 물건을 만들어서는 안 된다는 것 —은 그렇지 않습니다. 증거가 실제로 보여주는 것은 보안 의식 없이 밸브 코딩이 위험하다는 것입니다. 그것은 다른 주장이며, 다른 해결책이 있습니다.

Wiz Research 팀 — 두 번의 침입을 발견한 동일한 팀 — 이 명확하게 말했다: 기회는 vibe 코딩을 늦추는 것이 아니라 높이는 것이다. Supabase 백엔드를 생성하는 AI 도구는 기본적으로 RLS를 활성화할 수 있습니다. 배포 플랫폼은 노출된 자격 증명을 자동으로 스캔할 수 있습니다. 기본적으로 안전한 vibe 코딩 인프라가 존재합니다. 그냥 아직 기본값이 아니다.

그것이 되기 전까지는, 확인해야 할 것을 아는 건축가들이 그 틈을 메워야 합니다 — 그리고 확인해야 합니다.

출시 전에

[ ] No API keys or secrets in frontend code
[ ] Gitleaks run before pushing to the repository
[ ] Row-Level Security enabled on every database table with user data
[ ] Every API endpoint requires authentication, or is explicitly marked public
[ ] Rate limiting enabled on registration and data endpoints
[ ] NEXT_PUBLIC_ prefix checked — nothing sensitive uses it
[ ] Snyk or equivalent scanned your dependencies
[ ] Asked AI to review your code specifically for security issues
[ ] Opened the browser dev tools and checked what a stranger can see

AI는 소프트웨어 창작을 이전에 없던 것처럼 접근 가능하게 만들고 있습니다. 더 많은 사람들이 만들면 더 많은 혁신, 더 많은 창의성, 더 다양한 목소리가 기술 분야에 들어옵니다. 그것은 진정으로 좋은 일입니다.

하지만 소프트웨어 공학은 항상 작동하는 코드를 생성하는 것 이상입니다. 모든 애플리케이션 아래에는 — 신뢰, 보안, 권한, 책임 — 이 여전히 코드를 배포한 사람에게 속한 층이 있습니다.

당신은 구축하기 전에 모든 것을 배워야 하는 것은 아닙니다. 그냥 층이 존재한다는 것을 알고, 확인하는 습관을 들이면 됩니다.

체크리스트는 위에 있습니다. 도구는 무료입니다. 나머지는 자기 통제입니다. 소프트웨어의 미래는 AI를 도와받을 수 있습니다. 하지만 책임은 여전히 인간입니다.

이것이 유용하다고 생각하나요? 첫 번째 AI로 만든 앱을 출시한 사람과 공유하세요. 가장 필요한 사람은 보통 아직 필요함을 알지 못하는 사람입니다.