바이브 코딩으로 프로젝트를 만드는 건 정말 쉬워졌습니다. 프롬프트 몇 줄이면 웹사이트가 나오고, 채팅봇이 돌아가고, 대시보드가 완성됩니다. 그런데 한 가지 빠진 게 있습니다. 바로 바이브 코딩 보안입니다.
제 경우가 딱 그랬습니다. 첫 바이브 코딩 프로젝트를 만들었을 때 보안 같은 건 생각도 안 했거든요. AI가 짜준 코드가 돌아가니까 끝인 줄 알았죠. 그런데 친구가 제 프로젝트를 보더니 한마디 합니다. “이거 이대로 두면 나중에 큰일 난다.” 그때서야 부랴부랴 보안을 챙겼고, 돌이켜 보면 일찍 알아서 다행이었습니다.
AI는 “돌아가는 코드”를 만들어 주지, “안전한 코드”를 만들어 주진 않습니다. 바이브 코딩 보안의 차이를 모르면 프로젝트가 커질수록 위험도 같이 커집니다.
바이브 코딩으로 만드는 건 대부분 SaaS입니다
바이브 코딩을 하면서 아마 Vercel, Supabase, Firebase, Netlify 같은 이름을 한 번쯤 보셨을 겁니다. 이런 서비스를 SaaS(Software as a Service)라고 부르는데, 쉽게 말하면 이렇습니다.
서버를 직접 사서 관리하는 게 아니라, 다른 회사가 만들어 놓은 서버·데이터베이스·배포 시스템을 빌려 쓰는 겁니다. 내 컴퓨터에서 코드를 짜고, 버튼 하나 누르면 그 회사 서버에 올라가서 전 세계 사람이 접속할 수 있게 되죠.
이 구조의 장점은 서버 관리를 직접 안 해도 된다는 겁니다. 하지만 함정이 하나 있어요. “서버는 그쪽에서 관리하니까 보안도 알아서 되겠지”라고 생각하기 쉽다는 점입니다. 플랫폼이 해주는 보안이 있고, 내가 직접 챙겨야 하는 보안이 있는데, 바이브 코더 대부분이 후자를 모릅니다.
플랫폼이 해주는 건 SSL 인증서, 기본 방화벽, 서버 인프라 보호 같은 것들이에요. 내가 챙겨야 하는 건 API 키 관리, 데이터베이스 접근 권한, 인증 로직, 입력값 검증 같은 것들입니다. 서버를 빌려 쓴다고 해서 내 코드의 구멍까지 막아주진 않거든요.
이런 공격이 실제로 들어옵니다
“내 프로젝트는 작은데 누가 공격하겠어”라고 생각하실 수 있습니다. 하지만 공격은 대부분 자동화돼 있어요. 봇이 인터넷을 돌아다니면서 취약한 사이트를 무차별로 찾아냅니다. 프로젝트 크기는 상관없습니다.
비개발자가 알아둬야 할 대표적인 공격 세 가지를 정리합니다.
DDoS — 접속 폭탄
DDoS(분산 서비스 거부 공격)는 수만 대의 컴퓨터가 동시에 내 서버에 접속 요청을 보내는 겁니다. 카페에 손님 한 명이 오면 괜찮은데, 갑자기 만 명이 동시에 몰리면 문이 막히잖아요. 똑같은 원리입니다. 서버가 정상 요청을 처리할 수 없게 돼서 사이트가 다운됩니다.
다행히 Vercel이나 Cloudflare 같은 플랫폼을 쓰면 기본적인 DDoS 방어가 포함돼 있는 경우가 많습니다. 하지만 무료 플랜에서 어디까지 막아주는지는 확인이 필요하고, 규모가 큰 공격은 추가 설정 없이는 버틸 수 없을 수도 있어요.
SQL 인젝션 — 데이터베이스 도둑
SQL 인젝션은 로그인 폼이나 검색창 같은 입력란에 데이터베이스 명령어를 슬쩍 끼워 넣는 공격입니다. 예를 들어 로그인할 때 아이디 칸에 정상 아이디 대신 데이터베이스 명령어를 입력하면, 보안이 허술한 사이트는 그걸 그대로 실행해 버립니다. 공격자가 회원 정보를 통째로 빼가거나, 데이터를 삭제할 수도 있죠.
바이브 코딩 보안에서 특히 위험한 이유가 있습니다. AI가 짜준 코드가 입력값을 검증 없이 바로 데이터베이스에 넣는 경우가 생각보다 많거든요. 코드가 “돌아가긴” 하니까 문제를 모르고 넘어가는 겁니다.
XSS — 방문자를 노리는 함정
XSS(크로스 사이트 스크립팅)는 내 사이트에 악성 스크립트를 심는 공격입니다. 댓글란이나 게시판에 자바스크립트 코드를 올리면, 다른 방문자가 그 페이지를 열었을 때 코드가 실행됩니다. 방문자의 쿠키나 로그인 정보가 공격자에게 넘어갈 수 있어요.
무서운 건 공격받는 쪽이 내 서버가 아니라 내 사이트를 방문한 사람이라는 점입니다. 내 프로젝트가 다른 사람을 공격하는 도구가 돼버리는 거죠.
지금 당장 챙길 바이브 코딩 보안 수칙
복잡한 바이브 코딩 보안 지식 전부를 알 필요는 없습니다. 하지만 아래 수칙은 바이브 코딩을 시작하는 순간부터 바로 적용해야 합니다.
.env 파일은 절대 깃허브에 올리지 마세요
.env 파일에는 API 키, 데이터베이스 비밀번호, 외부 서비스 인증 정보가 들어 있습니다. 이 파일이 깃허브에 올라가면 전 세계 누구나 볼 수 있어요. 실제로 깃허브에서 .env 파일을 자동으로 스캔하는 봇이 돌아다닙니다. 올라간 지 몇 분 만에 API 키가 도용되는 일이 흔합니다.
.gitignore 파일에 .env를 반드시 추가하세요. AI에게 코드를 짜달라고 할 때 “.gitignore에 .env 포함시켜 줘”라고 한마디만 하면 됩니다.
API 키는 프론트엔드 코드에 넣지 마세요
프론트엔드, 그러니까 사용자 브라우저에서 실행되는 코드에 API 키를 직접 넣으면 브라우저 개발자 도구로 누구나 볼 수 있습니다. 키를 서버 쪽(백엔드)에서만 사용하도록 구조를 잡아야 해요.
바이브 코딩할 때 AI에게 “이 API 호출은 서버사이드에서 처리하고, 프론트엔드에는 키가 노출되지 않게 해줘”라고 지시하면 대부분 알아서 분리해 줍니다.
데이터베이스 보안 규칙을 반드시 설정하세요
Supabase나 Firebase를 쓸 때 보안 규칙(RLS, Security Rules)을 설정하지 않으면 데이터베이스가 사실상 누구에게나 열려 있는 상태가 됩니다. 기본 설정이 “전체 공개”인 경우도 있어요.
로그인한 사용자만 자기 데이터를 읽고 쓸 수 있도록 규칙을 걸어야 합니다. 이 부분은 AI에게 “Supabase RLS 설정해 줘, 각 사용자가 자기 데이터만 접근할 수 있게”라고 요청하면 기본 규칙을 만들어 줍니다.
사용자 입력은 믿지 마세요
검색창, 로그인 폼, 댓글란, 파일 업로드 등 사용자가 무언가를 입력하는 곳은 전부 공격 통로가 될 수 있습니다. 입력값을 항상 검증하고, HTML이나 스크립트 태그는 걸러내야 합니다.
AI에게 코드를 짜달라고 할 때 “입력값 유효성 검증 포함해 줘”, “XSS 방지를 위한 입력 소독(sanitization) 적용해 줘”라고 추가하는 습관을 들이면 됩니다.
레드팀 전략 — AI로 내 프로젝트를 직접 공격해 보세요
바이브 코딩 보안 수칙을 챙겼다고 해도 실제로 뚫리는지 안 뚫리는지는 공격해 봐야 압니다. 여기서 쓸 수 있는 전략이 레드팀입니다.
레드팀이란 원래 군사 용어인데요. 아군 중 일부가 일부러 적군 역할을 하면서 우리 방어의 약점을 찾는 훈련입니다. 보안에서도 똑같습니다. 내 프로젝트를 일부러 공격해 보고, 뚫리는 곳을 찾아서 고치는 거죠.
바이브 코더에게 좋은 소식은, AI를 활용해 바이브 코딩 보안 점검을 직접 수행할 수 있다는 겁니다.
이렇게 해보세요
먼저 AI에게 공격자 역할을 맡깁니다. 프롬프트를 이렇게 짜볼 수 있어요.
“지금부터 너는 보안 전문가(레드팀)야. 내 프로젝트 코드를 보고 보안 취약점을 찾아줘. SQL 인젝션, XSS, 인증 우회, API 키 노출, 권한 상승 가능성을 전부 확인해. 취약점마다 위험도(상·중·하)와 구체적인 공격 시나리오를 알려줘.”
AI가 취약점 목록을 주면, 이번에는 방어자(블루팀) 역할로 전환합니다.
“방금 찾은 취약점을 하나씩 수정해 줘. 수정 전 코드와 수정 후 코드를 같이 보여주고, 왜 이렇게 고쳤는지 설명해 줘.”
이 과정을 한 번만 하는 게 아니라, 기능을 추가할 때마다 반복하는 게 중요합니다. 새 기능이 새 구멍을 만들 수 있으니까요.
레드팀을 돌리면 자주 나오는 취약점
제 경험으로는 바이브 코딩 프로젝트에서 레드팀을 돌리면 비슷한 문제가 반복해서 나옵니다. 코드 수정 중 오류가 발생하면 오류 해결 복구 가이드를 참고하세요. 인증 없이 접근 가능한 API 엔드포인트, 프론트엔드에 노출된 시크릿 키, 입력값 검증 누락, 에러 메시지에 서버 정보가 그대로 노출되는 경우 등이죠.
이런 건 AI가 처음 코드를 짤 때는 잘 안 챙겨주는 부분입니다. “돌아가게 만들어 줘”와 “안전하게 만들어 줘”는 다른 요청이라는 걸 기억해야 합니다.
서버를 모르면 나중에 큰일 납니다
바이브 코딩의 매력은 코딩을 몰라도 만들 수 있다는 점입니다. 하지만 보안은 “몰라도 되는 영역”이 아닙니다. 내 프로젝트에 사용자가 생기고, 그 사용자의 데이터를 다루는 순간부터 보안은 선택이 아니라 책임이 됩니다.
전부 다 알 필요는 없어요. 하지만 .env 파일이 뭔지, API 키가 어디에 있으면 안 되는지, 데이터베이스 보안 규칙은 왜 걸어야 하는지, 이 정도는 프로젝트를 만드는 사람이 직접 이해해야 합니다.
그리고 AI 레드팀은 비개발자가 쓸 수 있는 가장 현실적인 바이브 코딩 보안 점검 방법입니다. 만들고 나서 한 번 돌려보세요. 생각보다 많은 구멍이 보일 겁니다. 그 구멍을 아는 것과 모르는 것의 차이는, 나중에 진짜 문제가 터졌을 때 확 체감됩니다.