Claude Code를 켜고 머릿속에 굴러다니던 아이디어 하나를 그대로 던졌습니다. 꽤 잘 나왔길래 얼른 Supabase를 붙여 로그인과 데이터 저장을 테스트했고, 스레드에 제품 홍보 콘텐츠를 하나 남겼습니다. 친구 몇 명한테 DM도 보냈고요. 오, 사람들이 와서 좀 써봅니다. 아이디어가 재미있다는 말도 있네요. 신이 나서 결제도 붙이고 돈을 써서 광고도 좀 돌려보기로 합니다.

그런데 지금 이 순간, 아무도 알려주지 않는 게 하나 있습니다. 그 앱의 데이터베이스가 통째로 열려 있을지 모른다는 사실이요. API 키는 코드에 그대로 박혀 있고, 데이터베이스는 아무나 읽을 수 있고, 어떤 주소는 로그인 없이도 그냥 열립니다. 빠르게 만드는 데만 초점을 맞추다 보니 보안은 아예 안 챙긴 거죠.

자, AI가 짜준 코드는 안전하지 않습니다. 오히려 반대입니다. 100개가 넘는 AI 모델을 테스트한 Veracode 조사에서, AI 생성 코드의 45%가 보안 테스트를 통과하지 못했습니다. 다행히 우리 서비스는 이제 시작이고, 지금 바이브코딩으로 인한 사고는 누가 작정하고 ‘털어서’ 나기보다 애초에 문도 안 잠그고 나간 쪽에 가깝습니다. 달리 생각하면, 간단히 잠그면 막을 수 있다는 뜻이기도 하고요.

그래서 이 글은 철저히 바이브코더를 위한 기초 보안 점검법을 다룹니다. 가장 흔히 할 법한 실수가 어떻게 사고로 번지는지 보고, 그걸 시점별로 어떻게 막는지 짚은 다음, 이 일을 도와줄 도구까지 정리하겠습니다.

바이브코더가 흔히 하는 보안 실수 5가지

이건 AI가 빠뜨리기 쉬운 것들입니다. 즉, 사람이 챙기지 않으면 그대로 배포된다는 공통점이 있어요. 그러니 모르면 당하기 딱 좋습니다. 각각이 어떻게 사고로 번지고 무엇이 돌아오는지까지 따라가 보겠습니다.

① 데이터베이스 잠금장치(RLS)를 안 켜고 배포한다

자주 쓰이는 백엔드 서비스인 Supabase에서 SQL로 테이블을 만들면 잠금장치인 RLS는 기본으로 꺼져 있습니다. 이 RLS는 쉽게 말해 “누가 어느 데이터를 봐도 되는지” 정하는 규칙인데요. AI에게 “회원 표 만들어줘”라고 하면 기능은 잘 만들지만 이 접근 규칙까지 챙기지는 않습니다.

털리는 과정: 앱을 배포하면 데이터베이스에 접근하는 공개 키(anon 키, 로그인 없이 누구나 쓰는 키)가 브라우저 코드에 올라갈 수도 있습니다. 누구든 브라우저 개발자 도구로 그 키를 꺼내 데이터 주소(/rest/v1/표이름)를 직접 부르면, 잠금장치가 없으니 실제 데이터가 응답으로 돌아옵니다. 고객 정보가 샌 거죠. 이런 앱은 자동 점검 프로그램이 알아서 찾아내기도 합니다.
돌아오는 결과: 간단합니다. 개인 정보 유출, 즉, 전체 회원 데이터가 빠져나갑니다. 한 연구자가 Lovable로 만든 앱 1,645개를 점검했더니 170개에서 잠금장치 없이 데이터가 읽혔다고 합니다(CVE-2025-48757). 그 다음은 유출 공지, 회원 이탈, 그리고 집단소송으로 이어집니다.

② LLM API 키를 코드에 그대로 박는다

예제 코드를 따라 하다 보면 API 키를 코드에 직접 쓰기도 합니다. 이 LLM의 API 키는 곧 돈입니다. 이 키를 등록한 사람의 돈으로 AI 토큰을 공짜로 쓸 수 있는 거니까요. 그래서 공격자가 가장 먼저 노립니다.

털리는 과정: 키가 들어간 코드를 GitHub 공개 저장소에 올리는 순간(또는 빌드 결과물에 둔 순간) 우리는 목을 그대로 내놓은 겁니다. 공격용 프로그램은 GitHub의 새 코드를 실시간으로 훑어 키를 찾아냅니다. 키가 노출되고 악용되기까지 걸리는 시간이 예전엔 몇 시간이었다면 요즘은 몇 분 수준으로 짧아졌습니다. 가져간 키로 LLM API를 최대치로 돌려버리고요.
돌아오는 결과: 감당 못 할 만큼 비용이 불어납니다. 게다가 내가 알아채고 키를 바꾸기 전까지 요금은 계속 오릅니다. GitGuardian 집계로는 2025년 한 해에만 공개 코드에 키·비밀번호 2,865만 건이 올라왔고, AI 서비스 자격증명 유출은 1년 새 81% 늘었다고 합니다.

③ 인증 검사를 빼먹는다

AI는 화면에 관리자 버튼은 그려주면서 정작 서버에서 누가 관리자인지 확인하는 과정은 빼먹기도 합니다. "이건 우리만 쓸 내부용"이란 말에 인증 없이 공개 주소에 올리기도 하고요.

털리는 과정: 공격자는 화면을 거치지 않습니다. 데이터 주소를 직접 부르죠. 서버에 권한 검사가 없으면 관리자 기능이 그냥 실행되고, 간단한 조작만 해도 남의 자료를 들여다보는 일도 할 수 있습니다.
돌아오는 결과: 한 보안 업체가 공개된 바이브코딩 앱 38만 개를 점검했더니 약 5,000개 앱에 사실상 인증이 없었다고 합니다. 그중 40%는 이로써 회원의 민감한 정보를 노출하고 있었습니다. 권한 탈취와 자료 유출은 프리패스입니다.

④ 요청 횟수를 제한하지 않는다

AI가 처음 만든 예제 코드에는 요청 횟수를 막는 장치가 대개 빠져 있고는 합니다. 그러니까 서버와 API에 되는대로 요청을 보내고, 그거 하나하나가 다 비용으로 돌아옵니다.

털리는 과정: 누군가 특정 주소를, 특히 LLM을 중계하는 주소를 자동 스크립트로 체크하기 시작합니다. 이때 요청횟수를 제한하는 장치가 없으면 요청이 끝없이 들어오죠.
돌아오는 결과: 요금이 감당 못 할 만큼 불어나거나, 서버가 못 버텨 서비스가 멈춥니다. 아주 짧은 스크립트 하나로 벌어지는 일입니다.

⑤ 입력을 검증하지 않는다

AI가 데이터베이스에 던지는 쿼리를 안전한 방식 대신 문자열을 그냥 이어 붙여 만들기도 합니다.

털리는 과정: 내 테스트 입력에는 멀쩡히 돌다가, 공격자가 조작한 값을 넣으면 그 틈으로 들어옵니다. 데이터베이스 명령을 끼워 넣어 자료를 빼내거나(SQL 인젝션), 외부에서 가져온 글에 숨긴 명령으로 LLM이 원래 지시를 무시하게 만들 수도 있습니다(프롬프트 인젝션).
돌아오는 결과: 데이터베이스 전체가 털리거나, 지워지거나, 에이전트가 시키지 않은 위험한 작업을 하기도 합니다. 실제로 Replit에서는 AI 에이전트가 작업 중지 지시를 무시하고 운영 데이터베이스를 통째로 지운 사건도 있었어요. 에이전트에게 운영 권한을 함부로 주면 안 되는 이유입니다.

어느 정도 유형이 있습니다. 접근 통제(①③)가 뚫리거나, 비용(②④)이 새거나, 입력(⑤)으로 공격이 들어오거나. 그리고 이건 모두, 알아서 잘 깔끔하게 AI가 막아주길 기대하기 어려운 것들이에요.

그 보안 이슈를 (일단) 해결하는 방법

좋은 소식. 보안을 어떻게 챙길지는 이미 업계가 수십 년간 정리해뒀습니다. 표준 보안 규칙이 공통으로 말하는 건 하나입니다. 보안은 한 번에 끝내는 이벤트가 아니라 앱을 운영하는 내내 챙기는 일이라는 겁니다. 마이크로소프트도 보안 개발 가이드에서 보안은 다 만든 다음에 생각할 일이 아니라고 강조합니다.

문제는 개인 빌더가 언제나 이걸 신경 쓰기 어렵다는 겁니다. 바쁘니까요. 그러니 특히 처음 만들 때, 개발할 때, 배포한 다음, 이렇게 세 시점에서 특히 신경 쓰는 것이 좋습니다.

처음 만들 때: 설계와 세팅

흔히들 설계 단계에서 들어간 결함이 가장 고치기 비싸다고 말합니다. 거창한 설계가 필요한 게 아닙니다. 내 앱에서 가장 새면 안 되는 데이터가 무엇인지 정리하는 일이 출발입니다. 그 다음으로는 아래 일들을 합니다.

데이터베이스 잠금장치부터 켠다. 만약 Supabase라면, 대시보드에서 공개된 표마다 RLS가 켜져 있는지 확인하고, “내 데이터만 볼 수 있다(auth.uid() = user_id)” 같은 규칙을 붙이세요. 다른 데이터베이스도 잠금장치 점검이 필요한 건 마찬가지입니다.
인증은 직접 짜지 말고 검증된 서비스에 맡긴다. 권한 관련 허점은 자동 점검 도구로도 거의 못 잡는 영역이라, 처음부터 안전한 걸 쓰는 게 쉽습니다. 이미 Supabase를 쓴다면 Supabase Auth가 기본이고, 아니라면 Clerk처럼 컴포넌트만 끼우면 로그인이 붙는 서비스가 흔히 추천됩니다.
API 키를 코드 밖으로 뺀다. 키는 .env 파일로 옮기고 그 파일을 .gitignore에 넣으세요. 브라우저에서 직접 부르던 API는 서버 함수를 거치게 바꿔서 키가 사용자 화면까지 내려가지 않도록 막고요.
요청 제한을 건다. 앱 앞에 Cloudflare 같은 서비스를 두면 IP당 요청 횟수에 상한을 거는 규칙을 만들기 쉽습니다. AI라면, 특히 콘솔에서 월 지출 한도를 정해두면 비용 사고가 대부분 막아집니다.
개발용과 운영용 환경을 나눈다. AI 에이전트에게 실수로라도 운영 데이터베이스 권한이 가지 않도록 처음부터 환경을 갈라두세요. 내부에서 소수만 쓰는 게 아니라 어느 정도 볼륨을 확보한 서비스는 이런 세팅을 기본으로 두는 것이 좋습니다.

개발할 때: 코딩 습관

처음 세팅을 마쳤어도 코드를 새로 짤 때마다 헛점은 생깁니다. 무엇보다 가장 중요한 건 AI가 내놓은 결과를 그대로 믿지 않는 것입니다. 이런 습관이 도움이 됩니다.

쿼리를 손으로 이어 붙이지 않는다. 문자열을 직접 합쳐 데이터베이스 쿼리를 짜지 말고 SDK나 ORM 같은 도구에 맡기세요(Supabase 클라이언트 SDK를 쓰면 SQL 인젝션을 대체로 막아줄 가능성이 높습니다). 즉, 사용자 입력을 쿼리 명령어로 그대로 넣는 방식보다는 파라미터로 바꿔 넣는 것이 좋다는 뜻입니다. 형식 검사 도구로도 한 번 걸러내고요.
AI가 추천한 라이브러리를 의심한다. AI는 있지도 않은 패키지나 오래되고 취약한 라이브러리를 자신 있게 추천하기도 합니다. 공격자가 AI의 단골 실수를 노려 가짜 패키지 이름을 선점해두기도 하고요. 일단 깔라는 거 다 깔기 전에 안전한 지 확인해 보세요. 중요 시점마다 검토하는 것도 좋습니다.
커밋 전에 API 키가 섞였는지 거른다. 커밋 직전에 키가 코드에 들어갔는지 자동으로 확인하는 장치(이를테면 pre-commit 훅)를 걸어두면, 키가 GitHub로 새기 전에 걸러집니다.
AI가 짠 코드는 받아들이기 전에 한 번 본다. 사실 마냥 Accept를 누르기 전에 보안을 한 번 점검하는 습관이 중요해요. 코드는 못 보면 어떻게 하냐고요? 도구를 쓰면 됩니다. (잠시 후에 추천해 보겠습니다)
외부에서 가져온 소스는 일단 의심한다. 웹에서 긁어오거나 다운로드 받은 걸로 위험한 작업을 시킬 땐, 사람이 한 번 승인하는 단계를 두세요. AI가 신경써서 공격을 체크하도록 하는 것도 방법이죠.

배포 후: 꾸준한 점검과 대응 원칙

NIST의 보안 개발 표준은 그룹 하나를 통째로 ‘취약점 대응’에 씁니다. 허점을 찾고 같은 일이 다시 안 생기게 막는 것까지가 보안이라는 뜻이죠.

가장 쉬운 자가 점검부터. 로그인하지 않은 상태에서 내 앱의 데이터 주소에 요청을 한 번 보내보세요. 데이터가 그냥 돌아오면 어딘가 문이 열린 겁니다. 새 기능을 붙일 때마다 한 번씩 해보면 좋아요.
알림을 켜둔다. 키가 새거나 라이브러리에서 취약점이 나왔을 때 알려주는 점검을 걸어두면, 사고를 나중이 아니라 거의 실시간으로 잡고 대응할 수 있습니다.
새 기능마다 잠금장치와 인증을 다시 확인한다. 데이터베이스 테이블을 새로 만들거나 주소를 추가할 때, 그 기능이 잠겨 있는지 그때그때 보는 습관이 가장 확실합니다.
터졌을 때의 순서를 미리 정해둔다. 사고가 의심되면 ① 노출된 키부터 바로 바꾸고 문제 기능을 막은 다음, ② 어떤 데이터가 얼마나 새어 나갔는지 범위를 파악하고, ③ 원인을 막고 같은 허점이 다른 곳에 또 있는지 살핍니다.

물론, 이건 가장 기초적이며 제일 기본적인 대처 방식입니다. 그것만으로도 할 일이 많고, 이것만으로도 아주 쉬운 공격은 막아내죠. 다만, 서비스가 커지고 더 많은 정보를 담게 되며 큰 돈이 오갈 때는 무조건 보안에 대한 노력을 기울여야 한다고 생각합니다. 공부하고 노력을 기울이고 돈을 써서요.

“해 줘”를 담당해 줬으면 하는 보안 도구

할 일이 많죠? 그러니 여기까지 전부 손으로 챙기기는 벅찰 겁니다. 그래서 보안 도구를 씁니다. 다만 분명히 하고 갈게요. 도구는 거들 뿐 다 해주지 않습니다. 점검 도구를 깔아도 경고를 읽고 고치는 건 사람입니다. 보안 서비스에 백날 항의 메일을 보내봤자 떠나간 고객은 돌아오지 않습니다.

다만, 모든 바이브코더가 보안에 대해 높은 이해를 가졌을 가능성은 낮습니다. 그래서 더 필요한 건 이런 서비스를 따로 켜지 않고 ‘지금 쓰는 코딩 에이전트’ 안에서 보안을 챙기는 방법입니다. 다시 크게 코딩 에이전트에 붙이기 쉬운 외부 전용 보안 도구와 코딩 에이전트 벤더사 자체가 제공하는 보안 도구로 나눠볼 수 있습니다.

외부 MCP: SonarQube · Snyk · Semgrep

외부 보안 도구 계열에서는 SonarQube, Snyk, Semgrep이 많이 쓰입니다. 셋 다 MCP 서버를 연결해 보안 검수를 받고 코딩 에이전트가 이를 활용하는 구조가 일반적입니다.

SonarQube

원래 보안보다 코드 품질을 보는 도구라, 버그·지저분한 코드·취약점을 폭넓게 훑는 게 강점입니다. MCP 서버를 붙이면 코딩 에이전트가 SonarQube의 품질·보안 분석 결과를 그대로 읽고, 짧은 코드 조각도 그 자리에서 검사해 줍니다.

핵심 기능은 무료로 시작할 수 있어요. 커뮤니티 에디션이 오픈소스고, 클라우드도 무료 플랜이 있습니다. GitHub 인기도와 설치 수로만 보면 SonarQube가 1위입니다(2026년 6월 기준 에디터 플러그인 449만 설치, 전체 개발자 기준).

Snyk

라이브러리(오픈소스 의존성) 취약점 감지가 특히 강하고, 코드·컨테이너·인프라 설정까지 함께 봅니다. MCP 서버는 Snyk CLI 안에 들어 있어, snyk mcp -t stdio로 로컬에서 띄우면 에이전트가 코드를 받아들이기(Accept) 전에 스캔해 줍니다.

마찬가지 무료 계정으로 바로 붙여 쓸 수 있지만, 스캔 횟수는 항목별로 월 한도가 있습니다.

Semgrep

5,000개가 넘는 규칙으로 코드를 의미 단위로 훑는, 빠른 보안 전용(SAST) 도구입니다. 규칙이 소스 코드처럼 생겨서 원하는 패턴을 직접 만들기도 쉽죠. MCP 서버는 보안 점검·스캔·커스텀 규칙 실행 같은 기능을 에이전트에 열어 줍니다(단, 이 저장소는 앞으로 semgrep 바이너리로 통합될 예정이라 최신 안내를 한 번 확인하세요).

애초에 이건 오픈소스 도구라 기본 스캔은 무료로 쓸 수 있습니다. 보안 위험 감지만 놓고 보면 SonarQube보다 더 나은 부분도 있습니다.

내장형 연계 도구: Claude Code, Codex, Copilot 보안 도구

보안은 개발에 있어 중요한 이슈기 때문에, 코딩 에이전트들 스스로도 보안을 챙길 내장형 도구를 내고 있습니다.

Claude Code의 /security-review

Claude Code를 쓴다면 /security-review 명령어를 써볼 수 있습니다. 그냥 코드 근처에서 저 명령어를 입력만 하면 됩니다. 커밋 전에 SQL 인젝션·XSS·인증 허점을 훑어 준다고 하고요. 토큰은 당연히 태울 테지만, 추가 비용은 0이며 코드 단위로 꽉 막아줄 GitHub Action도 따로 있어요.

Codex Security

Codex를 쓴다면 Codex Security도 있습니다. 아직 Pro 이상 가입자만 쓰는 프리뷰 버전이긴 하지만, “보안 전용”으로 나온 기능이라는 점이 매력적이네요. 코드를 훑어 취약점을 식별/검증하고, 수정 패치까지 제안하는 에이전트형 도구입니다. 격리된 환경에서 재현을 검증해 수준을 높이는 것도 좋네요. 다만, 일단 정식 라인으로 공개된 만큼 앞으로 Codex에서 보안 점검이 필요하면 이 도구가 유용할 겁니다.

Copilot Autofix

그 다음, GitHub에 올린다면 Copilot Autofix가 취약점 검증과 고칠 코드 제안도 해줍니다. 공개·오픈소스 저장소는 무료고, Copilot 구독도 필요 없어요.

마치며

바이브코딩에서는 ‘지식을 엮는 일’이 중요하다고 생각합니다. 쉽게 말하면 뭐가 필요하고 무엇이 부족한지 알아야 한다는 거죠. 보안 지식을 막 쌓으라는 게 아닙니다. 어떤 위험이 있는지 알고, 시점에 맞춰 막아두는 것 정도만 해도 초기 단계 보안 사고의 대부분을 막습니다. 아는 만큼 대응합니다.

보안에서는 사실 완전한 방패를 세울 수는 없습니다. 공격의 방법이 끝없이 진화하니까요. 그래서 원칙으로 접근하는 것이 중요합니다.

어려운 원칙은 그때 생각하고, 일단 시작할 때 알아두면 좋을 원칙은 두 가지입니다. 첫째, AI를 너무 믿지 마세요. AI가 짠 코드일수록 한 번 더 의심하고, 배포 전에 사람이 확인해야 합니다. 둘째, ‘나중에 하자’는 마음을 버리세요. 트래픽이 모이면, 결제가 붙으면, 시간이 나면 하고 미루다 보면 사고가 난 다음에야 챙기기 일쑤입니다. 지금 사고 난 서비스들도 다 같았겠죠. ‘일단 돈부터 벌고 하지, 뭐’에서 시작하는 무언가들.

그럭저럭 괜찮지 않을까 생각하지 말고, 나중이 아닌 지금 시작하세요. 보안의 첫 걸음입니다.