10개의 AI 구축 앱을 보안 스캔하며 발견한 사실 (및 수동 점검 방법)

AI 코딩 에이전트(AI coding agents) — Lovable, bolt.new, Cursor, Replit — 덕분에 이제 누구나 직접 코드를 한 줄도 쓰지 않고도 작동하는 앱을 출시할 수 있게 되었습니다.
이것은 진정으로 멋진 일입니다. 하지만 이는 동시에 SQL 인젝션(SQL injection)이나 인증 체크(auth check) 누락이 무엇인지 아는 사람의 검토를 전혀 거치지 않은 수많은 라이브 앱들이 급증하고 있음을 의미하기도 합니다.

이와 관련된 수치는 결코 가볍지 않습니다:

연구에 따라 다르지만, **AI가 생성한 코드 샘플의 45~88%**에는 최소 하나 이상의 실제 악용 가능한 취약점이 포함되어 있습니다.
보안 검토 없이 바이브 코딩(vibe-coding) 플랫폼에서 실행되고 있는 380,000개의 공개 노출 자산이 발견되었으며, 그중 약 5,000개는 민감한 기업 데이터를 보유하고 있었습니다.
2026년에 출시된 실제 앱인 Moltbook은 3분도 채 되지 않아 150만 개의 API 토큰과 35,000개의 사용자 이메일이 노출되었습니다. 이 앱의 창업자는 직접 코드를 단 한 줄도 작성하지 않았습니다.
The Tea App은 사용자의 비공개 이미지를 공개적으로 접근 가능하게 방치했습니다. 이는 스캐너라면 즉시 잡아낼 수 있지만, 바쁜 1인 개발자는 절대 놓치기 쉬운 종류의 실수입니다.

저는 이것이 실제로 어떤 모습인지 알고 싶었습니다. 그래서 Lovable과 bolt.new로 생성된 10개의 실제 공개 리포지토리(repos)를 찾아 Semgrep — 계정이 필요 없는 무료 오픈 소스 도구 — 을 통해 실행했습니다. 상용 스캐너가 사용하는 것과 동일한 규칙 세트(p/secrets 및 p/owasp-top-ten)를 기준으로 삼았습니다. CVE 번호 대신 쉬운 언어로 분석 결과를 설명해 드리겠습니다.

발견 1: git에 커밋된 완전한 프로덕션 비밀 정보(production secrets) 세트

한 앱(AI 툴링 SaaS)의 경우, .env 파일과 .env.server 파일이 모두 리포지토리에 직접 커밋되어 있었습니다. 이 파일들에는 OpenAI API 키, Supabase 서비스 역할 키(service-role key) (데이터베이스의 모든 행 수준 보안(Row-Level-Security) 정책을 우회하여 모든 테이블에 대한 전체 읽기/쓰기 권한을 가짐), Supabase JWT 비밀값(JWT secret), 프로덕션 데이터베이스 비밀번호, Clerk 인증 비밀 키(auth secret key), 그리고 Vercel 배포 토큰(deploy token)이 포함되어 있었습니다.

JWT 비밀 키(JWT secret)를 이해하는 것이 핵심입니다. 이 키가 있으면 누구나 _관리자를 포함한 어떤 사용자_에 대해서도 유효한 로그인 토큰을 직접 생성(mint)할 수 있으며, Supabase의 API는 이를 실제 토큰으로 받아들입니다. 비밀번호도, 별도의 취약점 공격(exploit)도 필요 없습니다. 그저 저장소(repo)에 파일이 놓여 있는 것만으로 충분합니다.

해결 방법, 만약 이것이 귀하의 저장소라면: 오늘 즉시 해당 자격 증명(credentials)을 모두 교체(rotate)하십시오(네, 명백한 것뿐만 아니라 전부 다 말입니다). Git 히스토리에서 해당 파일들을 완전히 제거(scrub)해야 합니다(최신 커밋을 삭제하는 것만으로는 부족합니다. 이전 커밋에 여전히 남아 있기 때문입니다). 그리고 다시 커밋하기 전에 .gitignore에 .env*를 추가하십시오.

발견 사항 2: 마이그레이션 도중 행 수준 보안(RLS) 비활성화, 트랜잭션(transaction) 미사용

한 금융 그룹 저축 앱의 마이그레이션 파일에는 ALTER TABLE public.profiles DISABLE ROW LEVEL SECURITY;를 실행하고, 관련 없는 몇몇 컬럼을 추가한 뒤, 파일 하단부에서 RLS를 다시 활성화하는 코드가 포함되어 있었습니다. 하지만 이 모든 과정을 BEGIN; ... COMMIT;으로 감싸지 않았습니다.

이 스크립트는 마치 Supabase의 SQL 에디터에 한 블록씩 복사해서 붙여넣으려는 용도로 작성된 것처럼 보였는데, 이는 데이터베이스 배경지식이 없는 사람이 문제를 해결할 때 흔히 사용하는 방식입니다. 만약 비활성화와 재활성화 사이에서 오타나 중복 제약 조건(duplicate constraint) 등으로 인해 오류가 발생한다면, 사용자 프로필 테이블(이름, 이메일, 전화번호)은 보호 정책이 없는 상태로 완전히 노출되며, UI 상에서는 그런 일이 발생했는지 알려주는 기능이 전혀 없습니다.

해결 방법: 수정용 마이그레이션(fix-up migrations)을 명시적인 트랜잭션(transaction)으로 감싸서, 스크립트 실행 도중 실패하더라도 모든 작업이 함께 롤백(rollback)되도록 하십시오. 또한 RLS를 건드리는 마이그레이션을 실행한 후에는 Supabase 대시보드에서 RLS 토글 상태를 다시 확인하십시오.

발견 사항 3: 저장소에서 보안을 검증할 방법이 전혀 없음

제가 스캔한 Supabase 기반 앱들 중, 3개 중 2개는 저장소 내에 supabase/migrations 폴더가 없었으며 어디에도 SQL 파일이 존재하지 않았습니다. 이 앱들은 프론트엔드에 완전히 작동하는 Supabase 클라이언트가 연결되어 있었지만, 버전 관리 시스템(version control) 상에는 그 뒤에 있는 테이블들에 RLS 정책이 적용되어 있는지 여부를 보여주는 정보가 전혀 없었습니다.

이것이 제가 이 문제를 바라보는 방식에서 가장 중요한 지점입니다. 제가 만들고 있는 도구를 포함하여, 코드 스캐너(code scanner)는 진정으로 이것을 볼 수 없습니다. 스키마(schema)와 그 정책(policies)들은 대시보드에서 수동으로 구축되었으며, 검토 가능한 곳 어디로도 내보내진 적이 없습니다. 위험 요소는 코드의 버그가 아니라, 기록되지 않은 결정 그 자체입니다.

지금 바로 자신의 리포지토리(repo)를 확인하는 방법

도구를 기다릴 필요는 없습니다. 약 5분 정도면 충분합니다:

pip install semgrep
semgrep --config=p/secrets --config=p/owasp-top-ten /path/to/your/repo

이 명령은 커밋된 비밀 정보(secrets)와 가장 흔한 인젝션(injection)/XSS 패턴을 잡아냅니다. Supabase 특유의 공백(발견 사항 2 및 3)에 대해서는, 아직 이를 대체할 수 있는 방법이 없습니다. 직접 Supabase 대시보드를 열고, 테이블 에디터(Table Editor)로 이동하여, 실제 사용자 데이터를 처리하는 모든 테이블에 행 단위 보안(Row-Level Security, RLS)이 켜져 있는지, 그리고 정책이 실제로 auth.uid()로 범위를 제한하고 있는지 수동으로 확인해야 합니다.

향후 계획

저는 이러한 종류의 스캔을 자동으로 실행하고, 각 발견 사항을 심각도 점수나 CWE 번호 대신 — 무엇이 잘못되었는지, 그것이 왜 실제로 중요한지, 그리고 가장 작은 수정 방법은 무엇인지 — 평이한 언어로 설명해 주는 도구를 만들고 있습니다. 도구가 준비되었을 때 알림을 받고 싶다면 다음을 방문하세요: https://goosegustin.github.io/vibesafe/