바이브코딩에 치명적인 보안: 출시 전, 꼭 확인할 7가지 사항
바이브코딩 보안 사고는 대부분 기본 설정에서 발생합니다. 2026년 실제 사고로 본 취약점 세 곳과 공개 전에 비개발자도 확인할 수 있는 점검 사항 7가지를 정리했습니다.
Oct 30, 2026
바이브코딩 보안의 현주소를 보여 주는 조사가 2026년 9월 말 발표된 적 있습니다. 보안 위험 관리 기업 업가드(UpGuard)가 바이브코딩 앱이 많이 쓰는 데이터베이스 서비스 Supabase(수파베이스)를 살펴본 결과입니다. Supabase를 쓰는 흔적이 있는 도메인 약 30만 곳을 살펴보니 누구나 표를 읽을 수 있는 데이터베이스가 16,326개 나왔습니다. 그중 절반 이상에서 개인정보로 보이는 항목이 확인됐습니다.
원인은 해킹 기술이 아니라 설정이었습니다. Supabase는 대시보드에서 직접 만든 표에는 접근 규칙을 기본으로 하지만 프로그램이 API로 만든 표에는 적용하지 않습니다. AI 코딩 도구는 표를 API로 만듭니다. 업가드는 사이트를 만든 사람들이 데이터베이스 설정을 이해하지 못하고 있었다고 짚었습니다.
바이브코딩 보안 사고의 상당수는 이렇게 데이터베이스 접근 설정, 코드에 남은 API 키, 사용자 간 권한 확인 같은 기본 설정에서 생깁니다. 이 세 곳은 코드를 읽지 못해도 공개 전에 질문으로 확인할 수 있습니다. 이 글은 2026년에 실제로 있었던 사고를 바탕으로 AI로 만든 앱이 어디서 새는지와 공개 전에 확인할 일곱 가지를 정리합니다.
바이브코딩으로 만든 앱에서 일어난 보안 사건/사고
2026년에만 바이브코딩으로 만든 서비스에서 큰 노출 사고가 여러 차례 있었습니다. 사고마다 규모와 원인은 달랐지만 만든 사람이 문제를 모른 채 서비스를 열어 두었다는 점만은 동일했습니다. 세 사례는 서비스 하나, 플랫폼 하나, 수만 개 데이터베이스로 규모가 다르지만 모두 기본 설정과 권한에서 문제가 생겼습니다.
첫 사례는 1월에 나왔습니다. 1월 31일 클라우드 보안기업 위즈(Wiz)는 AI 에이전트용 소셜 네트워크 몰트북(Moltbook)의 데이터베이스가 열려 있다는 사실을 찾아 운영사에 알렸습니다. 누구나 볼 수 있는 웹페이지 코드 안에 데이터베이스 접속 키가 들어 있었고 접근 규칙은 꺼져 있었습니다. 이 키만 있으면 데이터베이스 전체를 읽을 수 있는 상태였습니다. 이렇게 노출된 정보는 API 토큰 약 150만 개와 이메일 주소 약 3만 5천 개였습니다.
위즈에 따르면 사용자끼리 주고받은 비공개 메시지 안에는 다른 서비스의 API 키가 평문으로 들어 있기도 했습니다. 한 서비스의 설정 실수가 그 서비스를 쓰는 사람들이 연결해 둔 다른 서비스로까지 번질 수 있었다는 뜻입니다. 창업자는 이 서비스의 코드를 한 줄도 직접 쓰지 않았다고 공개적으로 말한 바 있습니다.
바이브코딩 도구를 만드는 회사에서 사고가 난 적도 있습니다. 스웨덴의 바이브코딩 플랫폼 러버블(Lovable)에서 무료 계정으로 몇 번만 요청을 보내면 다른 사용자 프로젝트의 소스코드와 데이터베이스 접속 정보, AI와 나눈 대화 기록까지 볼 수 있는 결함이 발견됐습니다. 영국 IT 매체 더레지스터(The Register) 등의 보도에 따르면 이 결함은 3월 3일 버그바운티로 신고됐지만 새로 만든 프로젝트만 고쳐졌습니다. 2025년 11월 이전에 만들어진 기존 프로젝트는 4월 20일 연구자가 내용을 공개할 때까지 그대로였고, 신고부터 공개까지 48일이 걸렸습니다. 러버블은 처음에 데이터 유출을 겪지 않았으며 "의도된 동작"이었다고 설명했다가 이후 부분적으로 사과했습니다. 앱을 만든 사람이 코드에 손대지 않았어도 플랫폼 쪽 권한 결함 하나로 프로젝트가 노출될 수 있다는 점을 보여 준 사례입니다.
업가드 조사는 이런 사고가 몇몇 서비스에 그치지 않는다는 점을 숫자로 보여 줍니다. 업가드는 웹 기술 분석 데이터에서 Supabase를 쓰는 흔적이 있는 도메인을 모은 뒤 각 도메인의 회원(users) 표를 조회하는 방식으로 조사했습니다. 미국 IT 매체 블리핑컴퓨터(BleepingComputer)가 전한 사례를 보면 업종도 가리지 않았습니다. 미국의 한 발레파킹 서비스에서는 연락처와 차량 번호판, 방문 이력이 담긴 고객 기록 10만 건 이상이 열려 있었습니다. 캐나다의 한 이민 서비스에서는 약 5,000명의 기록과 함께 암호화되지 않은 비밀번호 884개가 노출됐습니다. 다만 16,326개라는 수치는 읽을 수 있는 데이터베이스의 개수이고, 피해를 본 사람의 수나 실제 악용 여부를 확인한 결과는 아닙니다. 업가드도 모든 사이트가 AI로 만들어졌다고 단정하지는 않았습니다.
바이브코딩 보안 취약점이 발생하는 이유와 원인
바이브코딩 보안 취약점은 크게 세 곳에서 발생합니다. 열려 있는 데이터베이스, 코드에 박힌 키, 확인하지 않은 권한입니다. 세 곳 모두 고도의 해킹 기술 없이 뚫린다는 공통점이 있습니다. AI 코딩 도구가 일하는 방식과 앱을 만드는 사람이 달라진 환경이 이 약점을 키우고 있습니다.
첫 번째는 열려 있는 데이터베이스에서 비롯되는 경우입니다. 행 수준 보안(RLS, Row Level Security)은 데이터베이스의 표마다 "이 줄은 누가 볼 수 있는가"를 정하는 규칙입니다. 회원 표에 이 규칙이 없으면 앱에 들어 있는 공개 키를 가진 누구나 전체 회원 정보를 읽을 수 있습니다. 로그인한 회원이 자기 정보만 보도록 막는 장치가 사라지는 셈입니다. Supabase 공식 문서도 이 규칙이 없는 표는 접근 권한을 가진 모든 역할이 읽고 쓸 수 있다고 설명합니다. 몰트북이 이 경우였습니다. 업가드도 조사한 노출의 주된 원인으로 이 규칙이 없거나 제대로 설정되지 않은 점을 꼽았습니다. 앱 화면에서는 로그인해야만 정보가 보이니 만든 사람은 안전하다고 믿기 쉽습니다. 하지만 데이터베이스는 화면을 거치지 않고도 직접 조회할 수 있습니다.
두 번째는 코드에 박힌 키에서 발생하는 경우입니다. API 키와 비밀번호가 코드나 저장소에 그대로 들어가는 문제도 늘고 있습니다. 프랑스 보안기업 깃가디언(GitGuardian)의 2026년 보고서에 따르면 2025년 한 해 공개 깃허브에 새로 올라온 비밀정보는 약 2,865만 건이었습니다. AI 서비스와 관련된 비밀정보는 127만여 건으로 1년 사이 81% 늘었습니다. 같은 보고서는 AI 코딩 도구가 함께 작성한 커밋(측정 대상은 Claude Code)이 전체 기준치의 약 두 배 비율로 비밀정보를 노출한다고 분석했습니다. 미국 시장조사기관 가트너의 피트 쇼어드 사이버보안 리서치 총괄은 바이브코딩으로 만든 앱에서 하드코딩된 비밀정보가 깃허브에 올라가 침투 경로가 되는 것을 가장 큰 위험으로 꼽았습니다. 결제 서비스나 외부 AI 서비스의 키가 새면 데이터 유출에 그치지 않고 남이 우리 계정으로 요금을 쓰는 일까지 생길 수 있습니다.
세 번째는 확인하지 않은 권한에서 비롯되는 사례입니다. 사용자마다 볼 수 있는 범위를 확인하는 인가(authorization)와 서비스 고유의 규칙인 비즈니스 로직이 여기에 해당합니다. 미국 IT 매체 CIO가 전한 바에 따르면 보안 스타트업 텐자이(Tenzai)는 2025년 12월 주요 AI 코딩 도구 5종으로 같은 조건의 앱 15개를 만들어 점검했습니다. 취약점은 69개, 그중 치명적인 것은 6개였습니다. SQL 인젝션이나 크로스사이트 스크립팅처럼 오래 알려진 취약점은 악용 가능한 형태로 하나도 나오지 않았습니다. 가장 심각한 문제는 API 인가와 비즈니스 로직에서 나왔습니다. AI는 교과서에 나오는 실수는 줄였지만 "이 사용자가 이 주문을 봐도 되는가" 같은 우리 서비스만의 규칙은 알려 주지 않으면 모릅니다. 텐자이 연구진도 AI 코딩 에이전트에게는 개발자가 가진 상식이 없어 명시적인 지시에 크게 의존한다고 설명했습니다.
이런 실수가 쉽게 줄지 않는 데는 세 가지 사정이 겹쳐 있습니다. 우선 AI 코딩 도구가 들여온 취약점이 실제로 빠르게 늘고 있습니다. 미국 조지아공대 연구진이 운영하는 추적 프로젝트 바이브 시큐리티 레이더(Vibe Security Radar)는 공개된 취약점(CVE)의 수정 이력을 거슬러 올라가 AI 코딩 도구가 들여온 코드인지 확인합니다. 미국 클라우드보안연합(CSA)의 정리에 따르면, 이렇게 확인된 사례는 2026년 1월 6건, 2월 15건, 3월 35건으로 늘었고 3월까지 누적 74건이었습니다. 연구진은 도구의 흔적이 남지 않은 코드까지 더하면 실제 규모는 5~10배일 것으로 추정했습니다. 공개된 오픈소스만 센 숫자이고 기업 내부 코드는 집계에 들어가지도 않았습니다.
다음으로 만드는 속도를 검토 인력이 따라가지 못합니다. 한 번에 만들어지는 코드가 많아 사람이 전부 읽기 어렵습니다. 애플리케이션 보안기업 체크마크스(Checkmarx)의 에란 킨스브루너 부사장은 사후 디버깅을 늘리는 방식은 AI의 속도에 맞지 않으며 보안을 코드를 만드는 단계에 넣어야 한다고 말했습니다.
마지막으로 만드는 사람이 달라졌습니다. 미국 시장조사기관 포레스터의 에릭 노스트 수석 애널리스트는 개발이나 보안 경험이 없는 팀도 앱을 만들 수 있게 되면서 기업의 공격 표면이 넓어졌다고 분석했습니다. 사업부장이 주말에 만든 사내 도구가 월요일에 고객 데이터를 받기 시작하는 일이 실제로 가능해졌습니다. 바이브코딩 보안에서 사람이 맡아야 할 몫은 결국 우리 서비스의 규칙을 정하고, 그 규칙이 지켜지는지 공개 전에 확인하는 일입니다.
바이브코딩 보안 점검: 공개 전에 확인할 7가지
아래 일곱 가지는 코드를 읽지 못해도 확인할 수 있는 사항들입니다. 직접 만든 앱이라면 스스로, 외주로 만든 앱이라면 개발사에 그대로 확인 절차를 거치면 됩니다. 앞에서 본 세 가지 취약점에 사고 대비까지 더해 세 묶음으로 나눴습니다. 모든 항목을 한 번에 완벽하게 갖추기 어렵다면 앞의 네 가지부터 확인하시기를 권합니다. 앞에서 본 2026년 사고들도 모두 이 네 가지와 관련이 있었습니다.
데이터와 보안 코드가 잠겨 있습니까
- 데이터베이스 표마다 접근 규칙(RLS)이 켜져 있습니까. 로그인하지 않은 상태에서 앱이나 데이터베이스에 접속해 회원 정보, 주문 내역 같은 데이터가 보이는지 확인합니다. Supabase를 쓴다면 관리 화면에서 표마다 RLS가 켜져 있는지, 규칙이 실제로 정의돼 있는지 봅니다. 켜져만 있고 규칙이 "모두 허용"이면 꺼진 것과 같습니다. AI에게 기능을 추가해 달라고 할 때마다 새 표가 생길 수 있으므로 공개 전 한 번이 아니라 기능을 더할 때마다 다시 봐야 합니다.
- 코드와 저장소에 API 키·비밀번호가 들어 있지 않습니까. 코드 저장소가 공개로 설정돼 있지 않은지, 비밀정보를 담는
.env파일이 저장소에 올라가지 않았는지 확인합니다. 웹페이지에서 그대로 내려받을 수 있는 화면 쪽 코드에 비밀 키가 들어 있지 않은지도 함께 봅니다. 화면 쪽 코드에 들어가도 되는 공개 키라도 1번의 접근 규칙이 꺼져 있으면 몰트북처럼 데이터베이스 전체가 열립니다. 결제나 외부 AI 서비스의 키가 노출됐다면 삭제만으로는 부족합니다. 이미 누군가 복사해 갔을 수 있으니 키를 새로 발급하고 기존 키를 폐기해야 합니다.
권한이 적절하게 나뉘어 있습니까
- A 사용자가 B 사용자의 데이터를 볼 수 없습니까. 테스트 계정 두 개를 만들어 한 계정으로 로그인한 상태에서 주소창의 주문 번호나 회원 번호만 바꿔 다른 계정의 정보가 열리는지 시험합니다. 러버블 사고와 텐자이 평가에서 가장 심각했던 문제가 바로 이 유형이었습니다. 번호가 1, 2, 3처럼 순서대로 매겨져 있다면 특히 주의해야 합니다. 번호 하나만 바꿔 넣어도 남의 정보를 차례로 열어 볼 수 있기 때문입니다.
- 관리자 기능은 관리자만 쓸 수 있습니까. 관리자 화면 주소를 일반 계정이나 로그인하지 않은 상태로 열어 봅니다. 화면에서 버튼만 숨기고 실제 기능은 막지 않은 경우가 많습니다. 보도에 따르면 러버블로 만든 한 앱은 인증 논리가 거꾸로 짜여 로그인한 사용자는 막고 익명 사용자에게 전체 접근을 허용했습니다. 만든 사람이 로그인한 상태로만 테스트하면 이런 문제는 끝까지 드러나지 않습니다.
사고가 발생해도 대응할 수 있는 환경입니까
- 개인정보를 꼭 필요한 만큼만 받고 있습니까. AI는 "회원가입 기능을 만들어 줘"라는 요청에 생년월일, 주소, 전화번호까지 넉넉하게 받는 화면을 만들기도 합니다. 지금 받는 항목을 목록으로 적고 서비스에 꼭 필요한 것만 남깁니다. 받지 않은 정보는 샐 일도 없고, 사고가 나더라도 알려야 할 범위와 피해가 그만큼 줄어듭니다.
- 무슨 일이 있었는지 기록이 남습니까. 누가 언제 어떤 데이터에 접근했는지 접속 기록(로그)이 남는지 확인합니다. 기록이 없으면 사고가 나도 범위를 알 수 없고 아래에서 볼 개인정보보호법의 통지 의무도 지키기 어렵습니다. 기록이 남더라도 아무도 보지 않으면 소용이 없으니 누가 얼마나 자주 확인할지도 정해 둡니다.
- 공개 전에 사람이 한 번 검토했습니까. AI가 만든 코드를 AI 보안 점검 도구로 한 번 더 살펴보는 것도 도움이 되지만 결과를 판단하고 수정을 승인하는 일은 사람이 맡아야 합니다. 점검 결과와 조치 내용을 문서로 남겨 두면 나중에 같은 문제가 다시 생겼는지 비교할 수 있고, 회사가 보안에 들인 노력을 보여 주는 기록도 됩니다.
국내에서 보안 사고 발생시 따르는 책임
직접 만든 앱이든 외주로 만든 앱이든, 고객의 개인정보를 받기 시작하면 개인정보보호법상 책임은 서비스를 운영하는 회사가 집니다. AI가 코드를 썼다는 사실은 책임을 덜어 주지 않습니다. 사업부에서 직원이 만들어 띄운 앱이라도 회사 이름으로 고객 정보를 받았다면 회사의 책임입니다.
2026년 9월 11일 시행된 개정 개인정보보호법은 이 책임을 더 무겁게 만들었습니다. 법률신문에 실린 법무법인 린 변호사들의 분석을 기준으로 정리하면 다음과 같습니다.
- 과징금 상한: 원칙은 전체 매출의 3%입니다. 과징금 처분 후 3년 안에 고의나 중과실로 같은 유형의 위반을 다시 한 경우, 고의나 중과실로 1천만 명 이상에게 피해를 준 경우, 시정명령을 따르지 않아 유출이 생긴 경우에는 최대 10%까지 부과할 수 있습니다.
- 유출 가능성 통지: 유출이 확인되기 전이라도 유출 가능성을 알게 되면 해당 정보주체에게 알려야 합니다. 입법예고된 시행령안은 그 시한을 인지 시점부터 72시간으로 제시했습니다.
- 대표자 책임: 사업주와 대표자를 개인정보 보호의 최종 책임자로 명문화했습니다. 개인정보 보호책임자(CPO)의 업무에는 예산 확보와 대표자·이사회 보고가 더해졌습니다.
- 투자에 따른 감경: 개인정보 보호에 예산과 인력을 들인 기록이 있으면 과징금을 줄일 수 있습니다. 시행령안 기준으로 최대 40%이며, 고의나 중과실이 있으면 감경되지 않습니다.
바이브코딩으로 앱을 운영하는 회사라면 6번의 접속 기록이 있어야 유출 가능성을 제때 파악하고 알릴 수 있습니다. 7번처럼 점검과 조치를 문서로 남겨 두면 보호 조치에 들인 노력을 보여 주는 자료로도 쓸 수 있습니다. 대표자 책임이 명문화된 만큼 현업 부서가 만든 앱이 어디에 몇 개 떠 있는지 경영진이 파악하고 있는지도 점검할 대상입니다. 몰트북처럼 출시 직후 데이터베이스가 열려 있었다면, 국내 기준으로는 감경받을 투자 기록도 72시간 안에 통지할 체계도 없는 상태에서 사고를 맞는 셈입니다. 시행령의 세부 기준은 개인정보보호위원회의 최종 발표로 확인하시기 바랍니다.
어디까지 직접 하고, 언제 전문가에게 맡겨야 합니까
사내에서만 쓰는 도구나 아이디어를 검증하는 시제품은 바이브코딩으로 직접 만들어도 됩니다. 외부 고객의 개인정보나 결제를 받기 시작하는 순간부터 기준이 바뀝니다. 같은 앱이라도 쓰는 사람이 직원에서 고객으로 바뀌면 지켜야 할 대상과 책임의 크기가 달라지기 때문입니다.
구분 | 예시 | 권장 |
사내 도구·시제품 | 업무 자동화 화면, 내부 대시보드, 투자 설명용 데모 | 직접 제작 가능. 위 7가지로 자가 점검 |
외부 공개 서비스 | 회원가입, 예약·주문, 결제, 고객 상담 기록 | 공개 전 전문 점검. 운영 중 정기 재점검 |
사내 도구라도 고객 명단이나 거래 내역처럼 외부에 나가면 안 되는 데이터를 다룬다면 외부 공개 서비스에 가깝게 보는 편이 안전합니다. 반대로 고객을 받는 서비스라도 바이브코딩으로 만든 시제품을 버릴 필요는 없습니다. 화면 구성과 기능 흐름은 그대로 살리고 데이터베이스 설정, 비밀정보 관리, 권한 구조를 전문가가 다시 점검해 다듬는 방식도 가능합니다.
외주 개발사에 맡길 때도 바이브코딩 보안은 확인할 항목입니다. AI 코딩 도구를 쓰는 개발사가 늘고 있어 도구를 쓰는지보다 그 결과를 어떻게 검토하는지가 더 중요해졌습니다. 계약 전에 세 가지를 물어보시기를 권합니다. AI 코딩 도구를 어느 단계에 쓰는지, AI가 만든 코드를 누가 어떤 기준으로 검토하는지, 납품 전에 보안 점검 결과를 문서로 받을 수 있는지입니다. 세 번째 질문에 대한 답은 앞서 본 7번 항목의 점검 기록이 되고, 나중에 회사가 보호 조치를 해 왔다는 근거로도 쓸 수 있습니다.
바이브코딩 보안은 공개 전 한 번의 질문에서 시작합니다
2026년의 바이브코딩 보안 사고는 대부분 열어 둔 데이터베이스, 코드에 남은 열쇠, 확인하지 않은 권한에서 시작됐습니다. 고도의 공격 기술이 필요한 일은 드물었습니다. AI는 앱을 만드는 속도를 바꿨지만 무엇을 지켜야 하는지 정하는 일은 여전히 서비스를 운영하는 회사의 몫입니다. 앱을 공개하기 전에, 로그인하지 않은 상태로 우리 데이터가 보이는지 한 번 확인해 보시기를 권합니다.
스파르타빌더스는 사업 구조를 먼저 이해하고 기술로 설계하는 IT 개발 파트너입니다. 바이브코딩으로 만든 서비스를 외부에 공개하기 전, 보안 점검부터 함께 살펴보고 싶으시다면 상담해 드립니다.
자주 묻는 질문
Q1. 바이브코딩으로 만든 앱은 보안상 안전합니까?
스파르타빌더스 설정에 따라 다릅니다. 2026년 업가드 조사에서는 Supabase를 쓰는 도메인 약 30만 곳 가운데, 누구나 읽을 수 있는 표를 가진 데이터베이스가 16,326개 확인됐습니다. 피해자 수가 아닌 데이터베이스 개수 기준입니다. 바이브코딩 앱도 데이터베이스 접근 규칙, 비밀정보 관리, 사용자 간 권한 확인을 거치면 안전하게 운영할 수 있지만 공개 전에 이 세 가지를 반드시 확인해야 합니다.
Q2. 바이브코딩 보안 취약점은 주로 어디서 생깁니까?
스파르타빌더스 바이브코딩 보안 취약점은 주로 세 곳에서 생깁니다. 접근 규칙이 꺼진 데이터베이스, 코드나 저장소에 들어간 API 키와 비밀번호, 다른 사용자의 데이터를 볼 수 있게 열린 권한입니다. 2025년 12월 텐자이 평가에서도 가장 심각한 취약점은 인가와 비즈니스 로직에서 나왔습니다.
Q3. 바이브코딩 보안 점검은 개발자가 아니어도 할 수 있습니까?
스파르타빌더스 기본 점검은 할 수 있습니다. 로그인하지 않은 상태로 데이터가 보이는지, 테스트 계정 두 개로 서로의 정보가 열리는지, 관리자 화면이 일반 계정에 열리는지를 직접 시험할 수 있습니다. 다만 외부 고객의 개인정보나 결제를 다루는 서비스라면 공개 전에 전문가 점검을 받는 편이 안전합니다.
Q4. Supabase RLS는 무엇이고 왜 꺼져 있습니까?
스파르타빌더스 RLS(행 수준 보안)는 데이터베이스 표마다 누가 어떤 줄을 볼 수 있는지 정하는 규칙입니다. 업가드에 따르면 Supabase는 대시보드에서 만든 표에는 RLS를 기본으로 켜지만 AI 코딩 도구처럼 API로 만든 표에는 기본으로 켜지 않습니다. 그래서 AI로 만든 앱은 RLS 설정을 따로 확인해야 합니다.
Q5. 바이브코딩 보안 사고로 개인정보가 유출되면 누가 책임집니까?
스파르타빌더스 서비스를 운영하는 회사가 개인정보보호법상 책임을 집니다. 2026년 9월 시행된 개정법은 원칙 상한(전체 매출의 3%)을 두되 반복·대규모 위반 등에는 최대 10%까지 과징금을 매길 수 있게 했고 유출 가능성만 알아도 정보주체에게 알리도록 했습니다. AI가 코드를 작성했다는 사실은 책임을 덜어 주지 않습니다.
Share article