바이브코딩 보안 점검, 권한⁠·비밀 키⁠·업데이트⁠·에이전트 체크리스트

바이브코딩으로 만든 앱은 화면이 잘 돌아가도 보안은 따로 점검해야 합니다. 이 글은 바이브코딩 보안 점검을 권한, 비밀 키, 업데이트, 에이전트와 패키지, AI 점검의 다섯 영역으로 나눠 내 앱에서 할 일을 순서대로 적었습니다. 내가 만든 앱과 내 계정끼리의 점검만 다루고, 남의 서비스를 뚫어 보는 방법은 다루지 않습니다.

왜 AI가 만든 앱에 점검이 따로 필요한가

AI 모델의 코드는 문법 검사는 거의 통과하지만 보안 검사에서는 자주 떨어집니다. 보안업체 베라코드의 2026년 7월 보고서는 100개가 넘는 모델을 시험한 결과 보안 시험 통과율은 56%쯤에서 제자리입니다. 열 번 중 네 번 넘게 떨어진다는 뜻입니다. 이 시험은 보안 지시 없이 모델만 돌린 결과라, 실제 서비스에서 그만큼 뚫린다는 수치는 아닙니다.

실제 사고는 화려한 해킹보다 설정 누락에서 많이 납니다.

• 2026년 9월 보안업체 업가드는 읽기 권한이 공개로 열려 있는 슈퍼베이스(Supabase) 데이터베이스를 16,326개 찾았고, 절반이 넘는 곳에서 개인정보로 보이는 데이터가 있었다고 발표했습니다. 슈퍼베이스가 뚫린 것이 아니라 각자의 설정이 열려 있던 것입니다. 업가드는 이 앱이 모두 AI로 만들어졌다고 단정하지는 않았습니다.
• AI 에이전트 소셜 서비스 몰트북은 보안업체 위즈가 설정이 잘못된 슈퍼베이스 데이터베이스를 찾았고, API 인증 토큰 150만 개와 이메일 3만 5천 개 등이 읽을 수 있는 상태였습니다. 화면 쪽 코드에 키가 있었고 접근 규칙(RLS)이 제대로 걸려 있지 않았던 것이 원인으로 보고됐습니다.
• 깃가디언의 2026년 보고서에 따르면 2025년에 공개 깃허브에서 새어 나간 AI 서비스 비밀 키가 127만 5천 개쯤이고, 전년보다 81% 늘었습니다.
• 2026년 4월 스타트업 포켓OS의 창업자는 코딩 에이전트가 테스트 환경의 오류를 고치려다 운영 데이터베이스 볼륨을 호스팅 API 호출 한 번으로 지웠고 같은 볼륨의 백업도 함께 사라졌다고 주장했습니다. 삭제에 걸린 시간은 9초였습니다. 창업자 본인의 설명이라 세부는 보도마다 차이가 있습니다.

아래 점검은 이런 사고를 막는 기본기입니다.

준비물

• 점검할 내 앱(바이브코딩으로 만든 것)과 코드 저장소
• 슈퍼베이스를 쓴다면 대시보드 접근 권한
• 테스트용 계정을 하나 더 만들 수 있는 환경
• 비용: 공개 저장소의 비밀 키 검사는 무료입니다. 비공개 저장소는 조건이 다릅니다.

권하는 순서는 권한, 비밀 키, 업데이트, 에이전트와 패키지, AI 점검입니다. 사고가 났을 때 피해가 가장 큰 곳부터입니다.

1부. 내 앱이 어디서 돌아가는지 알기

바이브코딩 앱은 세 겹 위에 있습니다. 운영 체제와 PHP·Node.js·Next.js 같은 런타임과 프레임워크가 땅이고, AI가 써 준 내 코드가 집이고, 집을 짓는 AI 코딩 도구와 가져온 패키지가 도구입니다. 땅의 업데이트가 누구 몫인지부터 가려야 합니다.

1. 앱이 올라간 곳을 확인합니다. 버셀이나 슈퍼베이스 같은 관리형 플랫폼인지, 내 서버나 도커에 직접 올린 것인지 구분합니다. 관리형 플랫폼은 운영 체제와 런타임 업데이트를 플랫폼이 맡는 경우가 많습니다.
2. 직접 올렸다면 운영 체제와 런타임(PHP, Node.js 등)의 업데이트는 내 몫이라고 메모해 둡니다. 예를 들어 PHP는 2026년 10월 21일 로그인 없이 서버를 장악할 수 있는 위험한 취약점 두 건(CVE-2026-109618, CVE-2026-109619)의 수정판(8.5.12, 8.4.27, 8.3.36, 8.2.35)을 냈습니다. 패치가 나오면 업데이트를 미루는 만큼 문을 열어 두는 셈입니다.

2부. 권한 점검

프런트엔드(화면)는 백엔드(서버, 데이터베이스)에 접속하는 단말기일 뿐입니다. 화면에서 버튼을 숨기고 입력을 막아도 누구든 화면을 건너뛰고 서버로 직접 요청을 보낼 수 있습니다. 그래서 누가 무엇을 볼 수 있는지는 서버와 데이터베이스가 검사해야 합니다.

3. 권한 검사를 화면이 아니라 서버와 데이터베이스에 둡니다. 버튼 숨기기나 입력 막기에만 의존하지 않는 상태가 목표입니다.
4. 슈퍼베이스를 쓴다면 화면(브라우저)에서 바로 읽을 수 있는 모든 테이블에 RLS(Row Level Security, 행 단위로 누가 읽고 쓸 수 있는지 정하는 데이터베이스 보안 기능)를 켭니다. SQL 편집기에서 테이블마다 실행합니다.

alter table public.reports enable row level security;

reports는 내 테이블 이름으로 바꿉니다. SQL이나 마이그레이션, AI가 만든 코드로 테이블을 만들면 RLS가 꺼진 채 생길 수 있어서 하나씩 확인해야 합니다.

5. 각 테이블에 접근 정책을 겁니다. RLS를 켜고 정책이 없으면 키로는 아무 데이터도 읽히지 않습니다. 로그인한 사용자가 자기 행만 읽게 하는 정책 예시입니다. user_id 열이 있다는 가정입니다.

create policy "own rows read"
on public.reports for select to authenticated
using ((select auth.uid()) = user_id);

6. 슈퍼베이스 대시보드의 보안 점검 화면(Security Advisor)에서 경고를 하나씩 확인합니다. 메뉴 이름과 위치는 바뀔 수 있습니다. "RLS가 꺼져 있다"는 경고가 남아 있으면 그 테이블부터 처리합니다.
7. 내 앱에 테스트용 계정을 하나 더 만듭니다.
8. 내 앱 안에서 A 계정으로 만든 데이터를 B 계정으로 열 수 있는지 봅니다. 예를 들어 A의 데이터 주소를 B로 로그인한 상태에서 열어 봅니다. 내가 만든 앱, 내 계정끼리의 점검에만 씁니다. 막히면 안심이고, 열리면 바로 고쳐야 할 구멍입니다.

3부. 비밀 키 점검

비밀 키는 앱이 외부 서비스에 접속할 때 쓰는 열쇠 문자열입니다. 슈퍼베이스에는 화면에 들어가도 되는 공개용 키와, 데이터베이스 규칙(RLS)을 건너뛰는 서버 전용 비밀 키(service_role)가 따로 있습니다. 공개용 키가 화면 코드에 있는 것은 정상이지만 RLS가 없으면 그 키만으로 데이터를 읽을 수 있습니다. 서버 전용 키가 화면 코드에 있으면 RLS도 소용없습니다.

9. 서버에서만 쓰는 키가 화면 쪽 코드에 들어 있는지 확인합니다. 프로젝트 전체에서 service_role을 검색하고, NEXT_PUBLIC_이나 VITE_로 시작하는 환경 변수에 비밀 키가 들어 있지 않은지 봅니다. 이 접두어가 붙은 값은 브라우저로 전달됩니다.
10. 환경 파일(.env)이 깃에 올라가지 않게 .gitignore에 넣습니다.

.env
.env.*

이미 올라갔는지는 아래 명령으로 확인합니다. 한 줄이라도 출력되면 올라간 것입니다.

git ls-files | grep -i "\.env"

11. 저장소가 공개인지 비공개인지 확인합니다.
12. 공개 저장소라면 깃허브의 비밀 키 검사(secret scanning)가 무료로 동작합니다. 저장소 설정의 코드 보안 항목에서 푸시 보호(비밀 키가 든 커밋을 올리기 전에 막는 기능)도 켜져 있는지 확인합니다.
13. 비공개 저장소라면 깃허브의 비밀 키 검사는 조건이 붙은 유료 기능(조직 계정의 GitHub Secret Protection 등)이므로, Gitleaks 같은 무료 비밀 검사 도구를 커밋 전 검사나 CI(자동 검사)에 걸어 둡니다.
14. 키가 새 나갔다면 지우는 것으로 끝내지 말고 그 키를 폐기합니다. 올라간 순간 이미 복사됐을 수 있기 때문입니다. 깃허브 문서도 유출된 값은 즉시 교체하고, 깃 기록에서 지우는 작업은 필요할 때만 하라고 안내합니다.
15. 폐기한 뒤 새 키를 발급하고 앱이 새 키로 동작하는지 확인합니다.

4부. 업데이트 점검

16. 새 버전이 나오면 알려 주거나 업데이트 요청을 자동으로 만들어 주는 도구를 켭니다. 깃허브의 Dependabot이나 Renovate가 대표적입니다.
17. 내가 쓰는 프레임워크와 런타임의 보안 공지를 구독합니다. 공식 블로그, 메일링 리스트, 깃허브 저장소의 보안 알림(Releases와 Security 탭의 Watch 설정)이 있습니다.
18. 서버를 직접 운영한다면 긴급 패치 원칙을 정해 둡니다. 예를 들어 위험도가 높은 패치는 가능하면 즉시, 늦어도 그 주 안에 적용한다고 문서나 메모에 적어 둡니다.

5부. 에이전트와 패키지 점검

AI 코딩 에이전트는 내 컴퓨터와 서버에서 명령을 직접 실행합니다. 에이전트가 쓸 수 있는 열쇠의 범위가 곧 사고의 최대 크기입니다.

19. 에이전트에게 운영 환경의 열쇠를 주지 않습니다. 에이전트가 쓰는 키는 개발용뿐이어야 합니다.
20. 개발용과 운영용을 나눕니다. 두 환경의 키, 데이터베이스, 설정이 분리돼 있어야 합니다.
21. 삭제나 배포처럼 되돌리기 어려운 명령은 사람이 확인하게 합니다. 클로드 코드 같은 도구의 권한 설정에서 이런 명령을 자동 허용하지 않고 매번 묻도록 둡니다.
22. 백업을 운영 데이터와 다른 곳에 따로 보관합니다. 포켓OS 사례처럼 백업이 같은 볼륨에 있으면 데이터와 함께 사라집니다.
23. 백업으로 실제 복구가 되는지 시험합니다. 복구해 보지 않은 백업은 있는지조차 모릅니다.
24. AI가 추천한 패키지는 설치하기 전에 실제로 있는지, 많이 쓰이는지 확인합니다. AI는 없는 패키지 이름을 지어내기도 합니다. 2025년 USENIX Security에 발표된 논문이 코드 생성 모델 16개를 시험했더니 추천된 패키지의 19.7%가 실제로 없는 이름이었습니다. 공격자가 그 이름으로 가짜 패키지를 먼저 등록해 두는 수법이 있습니다. 자바스크립트라면 설치 전에 이름과 내려받기 수를 확인합니다.

npm view 패키지이름

25. 막 올라온 새 버전은 하루쯤 기다렸다가 받게 하는 설정을 겁니다. 감염된 버전은 대개 발견되고 걷어지는 데 시간이 걸려서, 하루를 기다리는 것만으로 피할 수 있는 경우가 많습니다. 패키지 관리자마다 설정 이름이 다릅니다. pnpm은 minimumReleaseAge(분 단위, 1440이면 하루), npm은 min-release-age(일 단위, npm 11.10 이상), 얀(Yarn)은 npmMinimalAgeGate(분 단위)입니다. 쓰는 도구의 공식 문서로 정확한 위치와 형식을 확인합니다.

6부. AI에게 점검 맡기기

26. 배포하기 전에 개발 환경에서 AI에게 보안 점검을 맡깁니다. "취약점을 찾아 줘"보다, 테스트 계정으로 다른 사용자의 데이터를 읽을 수 있는지 직접 확인해 보라고 시키면 훨씬 쓸모 있는 답이 나옵니다. 요청 예시입니다.

이 앱은 내가 만든 것이고 지금은 개발 환경이다.
테스트 계정 A와 B를 만들어, B로 로그인한 상태에서 A의 데이터를 읽거나 바꿀 수 있는지 확인해 줘.
읽을 수 있는 경로가 있으면 어떤 요청으로 가능한지와 고치는 방법을 알려 줘.
운영 환경에는 접속하지 말고, 데이터를 지우거나 바꾸는 작업은 먼저 나에게 물어봐.

운영 환경에서는 하지 않고, 내가 만든 앱에만 씁니다. AI의 보고도 틀릴 수 있으니 보고된 항목은 사람이 직접 다시 재현해서 확인합니다.

막히는 곳과 대처

• 테스트 계정으로 다른 계정의 데이터가 열린다면: 바로 고쳐야 할 구멍입니다. RLS와 정책부터 확인합니다.
• 키가 새 나갔다면: 지우는 것으로 끝내지 말고 폐기한 뒤 새로 발급합니다.
• AI 점검 결과가 맞는지 모르겠다면: AI가 말한 요청을 직접 재현해 보고, 재현되지 않으면 고치기 전에 근거를 다시 물어봅니다.
• 어디서부터 해야 할지 모르겠다면: 슈퍼베이스를 쓴다면 4번(RLS)과 9번(서버 키 검색)부터 합니다. 사고가 가장 많이 나는 두 곳입니다.

체크리스트

• 내 앱이 어디서 돌아가는지, 업데이트가 누구 몫인지 안다
• 슈퍼베이스를 쓴다면 모든 테이블에 RLS와 접근 정책이 있다
• 테스트 계정으로 다른 계정의 데이터가 열리지 않는다
• 서버 전용 키가 화면 쪽 코드나 깃에 없다
• 업데이트 도구, 보안 공지 구독, 긴급 패치 원칙이 있다
• 에이전트에게 운영 열쇠가 없고 위험한 명령은 사람이 확인한다
• 백업이 따로 있고 복구를 시험했다
• 새 패키지는 존재 여부를 확인하고 새 버전은 하루 늦춰 받는다
• AI 점검 결과를 직접 재현해 확인했다