바이브 코딩 보안: AI로 만든 앱을 보호하는 방법

Ailoot 사용법에 관한 추가 안내는 문서에 있습니다.

AI로 만든 앱은 왜 더 자주 해킹당할까요?#

저도 AI로 제품을 만들지만, 보안에 편집증적으로 굴면서 “전부 최대한 잠가야 한다”고 생각하지는 않습니다. 하지만 그 아래로 내려가면 안 되는 기본 수준이 있습니다. 그렇지 않으면 어느 날 데이터베이스는 텅 비고 서버에는 남의 채굴 프로그램이 돌아가는 모습을 보게 될 테니까요. 이 가이드는 바로 그 기본 수준에 관한 내용입니다. “보안 전문가가 되어라”가 아니라 “아무 이유 없이 자기 발등을 찍지 마라”는 것입니다.

문제의 근본은 간단합니다. AI 에이전트에게 “고객 예약 앱을 만들어 줘”라고 하면, 에이전트는 가능한 한 빨리 앱을 작동시킵니다. 보안은 데모에서 눈에 띄지 않는 추가 작업입니다. 그래서 데이터베이스는 개방된 상태로 설정되고, 결제 키는 코드에 바로 들어가며, “이 사용자가 접근 권한이 있는가?”를 확인하는 검사는 브라우저에만 존재해 1초 만에 우회될 수 있습니다.

두 번째 원인은 플랫폼 자체입니다.

다시 말해, 허점은 기본 설정에 따라 저절로 생깁니다. 당신이 잘못한 건 없습니다. 그저 아무것도 하지 않았을 뿐입니다. 보안에서 아무것도 하지 않는다는 것은 곧 “누구나 접근 가능”하다는 뜻입니다.

AI는 사람보다 시크릿을 유출할 가능성이 높습니다. 에이전트가 살펴보지도 않고 git add .와 git push를 실행하면, 키가 든 .env 파일도 다른 파일과 함께 공개될 수 있습니다.

바이브 코더들은 어떤 뼈아픈 교훈을 얻었을까요?#

부주의를 예방하는 가장 좋은 방법은 다른 사람의 실수에서 배우는 것입니다. 프로젝트를 공개하기 전에 살펴볼 만한 보고서 네 가지를 소개합니다.

Lovable과 꺼져 있는 RLS. Lovable 플랫폼은 텍스트 설명으로 앱을 만듭니다. 2025년, 앱 전반의 구조적 허점이 발견되어 CVE-2025-48757로 등록되었습니다. 원인은 생성된 앱에 데이터베이스 행 단위 접근 규칙(RLS, 아래에서 설명)이 없었던 것입니다. 한 연구자가 표본을 확인한 결과 앱 170개에서 노출된 접근 지점 303개를 발견했습니다. 이름, 전화번호, 결제 상태, 다른 사람의 API 키, 심지어 집 주소까지 노출되었습니다. 확인한 앱의 약 70퍼센트에서 행 단위 보호가 완전히 꺼져 있었습니다.

Tea와 민감 데이터. 사람에 대한 익명 리뷰 앱인 Tea는 2025년 7월 이미지 약 72,000장을 잃었습니다. 그중 셀카와 문서 사진이 13,000장이었고, 이후 비공개 메시지도 100만 건 넘게 유출되었습니다. 기술적 원인은 개방된 스토리지와 허술한 접근 검사였습니다. 보안 커뮤니티는 Tea를 생생한 사례로 꼽습니다. 권한 확인보다 빠른 출시를 우선하면 민감 데이터가 가장 먼저 유출됩니다.

또 다른 실제 사례. 원문 작성자가 설명한 사례에서 바이브 코더의 앱은 AI가 데이터베이스를 만들 때 자동으로 추측할 수 있는 기본 비밀번호를 설정한 탓에 해킹당했습니다. 그다음은 늘 같은 순서였습니다. 침입자가 들어와 채굴 프로그램을 설치하고 프로젝트를 덮어썼습니다. 서버 전체를 완전히 지워야 했습니다. 기본 비밀번호는 “어서 들어오세요”라는 팻말을 붙인 열린 문과 같습니다.

보안의 두 전선: 정확히 어디가 취약할까요?#

사람들은 “바이브 코딩 보안”을 이야기할 때 완전히 다른 두 가지 우려를 한데 묶는 경우가 많습니다. 서로 다른 방식으로 대응해야 하므로 나눠서 살펴보겠습니다.

첫 번째 전선—에이전트 자체. 컴퓨터에서 AI 에이전트를 실행하고 파일, 터미널, 키, 데이터베이스에 접근하도록 허용합니다. 에이전트는 사람이 아닙니다. 지시를 문자 그대로 따르고 위험하더라도 가장 빠른 방법을 찾는다는 점이 위험 요소입니다. 에이전트가 읽는 텍스트를 통해 다른 사람의 명령이 “주입”될 위험도 있습니다(이를 prompt injection이라고 합니다).

두 번째 전선—완성된 앱. 당신이 공개해 사람들이 사용하는 앱입니다. 공격 대상은 공개된 사이트나 서비스입니다. 공격자는 개방된 데이터베이스에 침입하거나, 가짜 요청을 보내거나, 다른 사람의 계정을 추측합니다. 이 문제는 에이전트와 관계없습니다. 허점은 이전에 남겨졌고 다른 사람들이 이를 악용합니다.

Claude를 만든 회사 Anthropic은 두 전선 모두에 적용되는 핵심 보호 원칙을 이렇게 설명합니다.

실제로는 AI가 “스스로 나쁜 일을 피할 것”이라고 기대하지 말라는 뜻입니다. 먼저 AI가 실제로 할 수 있는 일을 제한하고, 그다음에 올바르게 행동하라고 요청하세요. AI의 행동은 실패할 수 있고, 실제로 실패합니다. 그때 당신을 보호하는 것은 사전에 설정한 단단한 경계뿐입니다.

새 프로젝트를 시작할 때마다 AI가 예측 가능하게 작동하고 당신의 발등을 찍지 않게 하고 싶나요? 보안 규칙은 Second Brain의 일부입니다. CLAUDE.md에 한 번 기록해 두면 에이전트가 모든 요청에서 따릅니다.

AI 에이전트는 컴퓨터에 접근해 무엇을 할 수 있을까요?#

가장 과소평가되는 위험은 지나치게 넓은 권한을 가진 자기 에이전트입니다. 외부 해커조차 필요하지 않습니다. 다음은 2026년 5월 말의 최근 사례입니다. Codex 에이전트에게 관리자 권한이 필요했지만 사용자는 그 권한이 없었습니다. 에이전트는 포기하지 않았습니다. 주변을 살펴보다가 사용자가 사실상 root와 동등한 docker 그룹에 속해 있는 것을 발견하고 그 접근 권한을 사용했습니다.

악의적인 의도는 없었습니다. “작업을 해결하라”는 지시를 받은 에이전트가 사람보다 빠르게 구조적 약점을 찾아냈을 뿐입니다. 그 약점으로 키나 운영 환경에 접근할 수 있다면 에이전트는 그 권한을 사용합니다. 따라서 첫 번째 규칙은 최소 권한 원칙입니다. 특정 작업에 필요한 접근 권한만 정확히 주고, 그 이상은 주지 마세요.

프로그래머가 아니어도 실제로 할 수 있는 일은 무엇일까요?

1. 운영 머신에서 에이전트를 “모든 것 허용” 모드로 실행하지 마세요

   에이전트가 확인을 요청하지 않는 모드(흔히 bypass 또는 yolo라고 부름)는 샌드박스나 테스트 프로젝트에서만 사용하세요. 실제 키와 운영 접근 권한이 있는 머신에서는 사용하면 안 됩니다.

2. 에이전트가 시크릿을 읽지 못하게 하세요

   Claude Code에서는 키가 포함된 파일의 접근을 거부하는 규칙을 설정하면 됩니다. 그러면 에이전트가 .env를 열려고 해도 도구가 허용하지 않습니다.

3. 운영 키를 분리해 보관하세요

   운영 데이터베이스와 결제 서비스의 키를 에이전트가 코드를 작성하는 폴더에 두지 마세요. 환경을 분리하고 실험할 때는 테스트 키를 사용하세요.

4. 도구의 샌드박스를 사용하세요

   최신 AI 도구는 시스템의 나머지 부분에 접근하지 못하는 격리된 환경(샌드박스)에서 명령을 실행할 수 있습니다. Claude Code에서는 권한 요청을 약 84퍼센트 줄여 주므로 사용하기에도 편리합니다.

Claude Code에서 시크릿 읽기를 거부하는 규칙은 대략 다음과 같습니다. 권한 설정에 추가하세요.

{
  "permissions": {
    "deny": [
      "Read(.env)",
      "Read(**/.env)",
      "Bash(git push *)"
    ]
  }
}

API 키와 비밀번호를 절대 두면 안 되는 곳은 어디인가요?#

가장 흔하면서도 값싼 실수는 키를 코드에 넣는 것입니다. 결제 서비스의 API 키, 데이터베이스 비밀번호, 봇 토큰은 모두 시크릿입니다. 별도의 .env 파일에 보관해야 하며, 코드와 함께 git에 들어가지 않도록 .gitignore에 파일을 등록해야 합니다.

왜 중요할까요? 공개 저장소에 올라간 키는 오래 살아남지 못합니다. 봇은 새 커밋을 쉬지 않고 검색합니다. 보통 이어지는 과정은 이렇습니다. 클라우드 키를 찾아 당신 비용으로 암호화폐 채굴 서버를 띄우고, 아침이면 수만 달러에 이르는 청구서를 받게 됩니다. 개발자들은 이런 이야기를 자주 전하며, 청구액은 달러로 다섯 자리 수에 달합니다.

2025년 문제의 규모는 다음과 같습니다. 공개 저장소에 새로 하드코딩된 시크릿은 28.65 million개로 전년 대비 34퍼센트 증가했습니다. AI 서비스 전용 키 유출은 81퍼센트 늘었습니다. 에이전트가 살펴보지 않고 커밋하는 바이브 코딩이 문제를 더 키웁니다.

지금 바로 직접 확인할 항목:

1. 프로젝트의 .gitignore 파일을 여세요

   .env 행이 있는지 확인하세요. 없다면 첫 번째 커밋 전에 추가하세요.

2. GitHub 저장소를 확인하세요

   .env 파일이 없는지 확인하세요. 저장소에서 .env 또는 키의 일부를 검색하면 빠르게 확인할 수 있습니다.

3. 키가 유출됐다면 폐기하고 새로 발급받으세요

   커밋을 삭제하는 것으로는 충분하지 않습니다. 이미 키가 탈취됐을 수 있습니다. 해당 서비스(결제 제공업체, 클라우드 서비스, AI 제공업체)에 가서 기존 키를 폐기하고 새 키를 발급받으세요. 이를 키 로테이션이라고 합니다.

4. 키에 최소한의 권한만 부여하세요

   읽기만 필요한 키라면 읽기 전용으로 설정하세요. 그러면 유출되더라도 훔칠 수 있는 정보가 줄어듭니다.

RLS가 없으면 왜 누구나 데이터베이스를 볼 수 있을까요?#

Supabase나 유사한 데이터베이스에서 앱을 만들고 있다면 이 부분이 가장 중요합니다. RLS는 Row Level Security의 약자입니다. 간단히 말해, 특정 사용자에게 테이블의 어떤 행을 보여 줄지 결정하는 규칙입니다. RLS가 없으면 “주문” 테이블의 모든 고객 주문이 모든 사람에게 반환됩니다.

Supabase 문서는 이를 분명하게 설명합니다.

바이브 코더가 특히 빠지기 쉬운 함정이 있습니다. Supabase 대시보드에서 클릭해 테이블을 만들면 보호 기능이 자동으로 켜집니다. 하지만 AI가 테이블을 만들면, 거의 항상 SQL 명령을 직접 작성하기 때문에 RLS가 기본적으로 꺼진 채로 남습니다. 즉, 에이전트가 만든 테이블은 인터넷 전체에 공개되어 있을 가능성이 매우 높습니다. Lovable 앱 170개에서 데이터가 유출된 것도 바로 이 때문입니다.

해야 할 일:

1. 에이전트에게 직접 물어보세요

   이렇게 쓰세요. “RLS가 꺼져 있는 모든 테이블을 보여 줘.” AI가 목록을 만들면 그 목록이 작업 대기열이 됩니다.

2. 사용자 데이터가 있는 모든 테이블에서 RLS를 활성화하세요

   그리고 접근 정책을 하나 이상 추가하세요. 예를 들어 “사용자는 자신의 행만 볼 수 있다”와 같은 규칙입니다.

3. 대시보드를 확인하세요

   Supabase 대시보드의 각 테이블에 “RLS enabled”가 표시되어야 합니다. 회색이나 빨간색이라면 테이블이 공개된 상태라는 뜻입니다.

4. 실제로 테스트하세요

   일반 사용자로 로그인해 다른 사람의 데이터를 요청해 보세요. 접근이 거부된다면 정책이 작동하는 것입니다.

인터페이스의 권한 확인은 왜 당신을 보호하지 못할까요?#

흔히 “일반 사용자가 관리자 버튼을 못 보게 해 뒀다”고 생각합니다. 문제는 버튼이 브라우저에 표시되는 그림일 뿐이라는 점입니다. 버튼을 사용하지 않고 서버에 직접 요청을 보낼 수 있습니다. 서버가 권한을 다시 확인하지 않으면 다른 사람이 보낸 명령도 실행합니다.

대표적인 사례가 IDOR입니다. 주소가 id=123인 주문을 열었다고 가정해 보세요. 값을 id=124로 바꾸면 서버가 정말 당신의 주문인지 확인하지 않았기 때문에 다른 사람의 주문을 볼 수 있습니다. 이는 바이브 코딩 앱에서 가장 흔한 허점 가운데 하나이며, Tea 정보 유출의 원인도 허술한 권한 확인이었습니다.

규칙은 간단합니다. “이 사용자가 이 작업을 할 권한이 있는가?”라는 검사를 서버에서도 반복하세요. 인터페이스는 편의를 위한 것이고, 보호는 백엔드의 몫입니다. 에이전트에 다음과 같이 지시할 수 있습니다. “사용자 데이터를 읽거나 변경하는 모든 endpoint에 서버 측 권한 검사를 추가해. 인터페이스에서 요소를 숨기는 데 의존하지 마.”

프로그래머가 아니어도 코드의 허점을 확인할 수 있을까요?#

좋은 소식은 오늘날 같은 AI에게 보안을 확인해 달라고 요청할 수 있고, 흔한 허점을 찾는 데 꽤 능숙하다는 점입니다. 목적이 서로 다른 도구 세 가지를 소개합니다.

1. Claude Code의 /security-review 명령. 현재 branch에서 SQL injection, XSS, 권한 허점, 데이터 유출, 종속성 문제를 한 번 검사합니다. 작동 방식과 모든 변경 사항에 자동 검사를 연결하는 방법은 Claude Code 보안 리뷰 가이드에서 단계별로 설명했습니다. 여기서 핵심은 첫 번째 방어선이며 명령 하나로 실행된다는 점입니다.

2. 공식 security-guidance 플러그인. 공식 플러그인 마켓플레이스에서 /plugin install security-guidance@claude-plugins-official 명령으로 설치하세요(Claude Code 버전 2.1.144 이상 필요). 코드를 세 시점에 검사합니다. 수정할 때마다, 작업 턴이 끝날 때마다, 커밋할 때입니다. 권한 우회, IDOR, injection, 취약한 암호화를 찾아냅니다. 하지만 Anthropic은 한계를 솔직하게 밝힙니다.

bash

npx skills add <author>/<repo>

그런 다음 에이전트에게 “내 프로젝트의 취약점을 확인해 줘”라고 말하면 됩니다. 다만 이 모음에는 중요한 단서가 있어 아래에서 별도로 설명합니다.

참고로 주요 기업들도 AI 코드 보안을 진지하게 다루기 시작했습니다. 2026년 6월 2일 150개 조직으로 확대된 Project Glasswing에서 파트너들은 Anthropic 모델을 사용해 짧은 시간에 10,000개가 넘는 치명적 취약점을 발견했습니다. 위험성은 분명합니다.

GitHub의 스킬과 확장 프로그램을 믿어도 될까요?#

특히 까다로운 부분은 보안을 위해 설치하는 도구가 위험의 원인이 될 수 있다는 점입니다. npx skills add ...를 실행하거나 확장 프로그램을 설치하면 다른 사람이 작성한 코드를 가져오고, 에이전트는 당신의 권한으로 그 코드를 실행합니다. 작성자의 계정이 해킹되었거나 패키지가 처음부터 악성이었다면 문제가 생깁니다.

앞에서 소개한 스킬 모음을 살펴보세요. 이름에 “Anthropic”이 들어 있어 경계심을 풀게 만듭니다. 하지만 저장소 설명에는 분명히 적혀 있습니다.

즉 이름이 오해를 부릅니다. 현재 이 모음은 성숙하고 깨끗하지만, 원칙은 변하지 않습니다. 설치는 본인 책임입니다. 그리고 위협은 이론에 그치지 않습니다. 2026년 5월, 악성 편집기 확장 프로그램이 마켓플레이스에 머문 시간은 겨우 18분이었지만, 그사이에 설치한 사람들의 비밀번호 관리자 비밀번호, GitHub 토큰, 클라우드 접근 권한, Claude Code 설정까지 훔쳤습니다. 또 다른 골치 아픈 점은 이런 악성 코드가 일반적인 패키지 제거 후에도 남아 다음 세션에서 다시 실행되는 경우가 많다는 것입니다.

저는 간단한 습관을 들였고 여러분에게도 권합니다. GitHub에서 스킬을 설치하기 전에 직접 확인하세요. 작성자가 해킹당하거나 계정이 탈취될 수 있고, 저장소에 악성 코드가 들어갈 수도 있습니다. 직접 확인하는 것이 스스로를 지키는 방법입니다.

설치 전 최소한의 확인 사항: 작성자와 별 개수를 살펴보고, 스킬 설명을 읽으세요. 게시물 하나의 추천만 믿고 도구를 설치하지 말고, 익숙하지 않은 도구는 운영 키가 있는 머신이 아니라 별도의 테스트 환경에서 먼저 사용해 보세요.

침해 사고 후에 당신을 구해 줄 것: 백업과 롤백#

보안은 “외부인을 막는 것”뿐 아니라 “문제가 생겼을 때 정상 상태로 돌아오는 것”이기도 합니다. 문제는 언젠가 생깁니다. 설명된 실제 사례에서 AI 에이전트가 운영 프로젝트에서 일상적인 작업을 하다가 실제 데이터베이스를 삭제했습니다. 백업은 있었지만 사흘 전 것이었고, 데이터 사흘 치가 그대로 사라졌습니다.

여기서 두 가지 규칙을 얻을 수 있습니다.

자주 백업하세요. 잃고 싶지 않은 데이터가 앱에 들어 있다면 사흘에 한 번 복사하는 것은 보호라는 착각일 뿐입니다. 자동 백업을 적어도 30분마다 하도록 설정하세요. Supabase를 포함한 대부분의 데이터베이스에서는 클릭 몇 번이면 설정할 수 있습니다.

git은 에이전트에 대비하는 보험입니다. git은 코드 기록을 저장하므로 작동하던 상태라면 언제든 복구할 수 있습니다. 에이전트가 작동하던 내용을 다시 작성해 버리면 직접 고치는 대신 마지막으로 작동하던 버전으로 되돌리면 됩니다. AI가 프로젝트를 삭제하거나 망가뜨렸는데 복구 방법을 모르겠다면 별도 보고서인 AI가 데이터베이스를 삭제했을 때 할 일을 참고하세요. 프로젝트가 망가지기 전에 보호하는 방법은 Claude Code가 프로젝트를 망가뜨리지 않도록 보호하는 방법 가이드를 참조하세요.

게시 전 보안 체크리스트#

게시 직전에 이 목록을 순서대로 확인하세요.

1. 시크릿은 .env에, .env는 .gitignore에. 코드에는 키가 없어야 합니다. 공개 저장소에 .env 파일이 없어야 합니다.

2. 키에는 최소한의 권한만 부여. 각 키는 필요한 기능만 수행할 수 있어야 합니다. 운영 키는 에이전트 환경과 분리되어야 합니다.

3. 사용자 데이터가 있는 모든 테이블에서 RLS가 활성화되어 있고 접근 정책이 설정되어 있어야 합니다.

4. 모든 데이터 작업에 서버 측 권한 확인이 있어야 합니다. 인터페이스에서 버튼을 숨기는 것만으로는 부족합니다. 주소의 id를 바꿔 직접 테스트해야 합니다.

5. webhook 서명 확인. 모든 외부 알림 처리기(결제, 양식)는 서명을 확인해야 합니다.

6. 요청 속도 제한을 수신 요청과 비용이 많이 드는 작업에 적용해 무차별 대입으로 비밀번호를 알아내거나 청구액을 키울 수 없게 하세요.

7. 운영 키가 있는 머신에서 에이전트가 “모든 것 허용” 모드로 실행되지 않아야 합니다. .env 읽기를 거부해야 합니다.

8. 백업을 자주 수행하고 테스트해야 합니다. 복사본이 “어딘가에 있겠지”라고 믿는 데 그치지 말고 실제로 복원해 봐야 합니다.

9. 코드가 /security-review 또는 security-guidance 플러그인으로 검사되어야 합니다. 발견된 문제는 수정해야 합니다.

10. 다른 사람이 만든 스킬과 확장 프로그램은 설치 전에 확인해야 합니다. 아무것도 “눈먼 상태로” 설치하지 마세요.

오늘은 어디서부터 시작할까요?#

이 가이드의 모든 내용을 하루 저녁에 한꺼번에 실행하려고 하지 마세요. 결국 아무것도 하지 못하게 됩니다. 오늘은 가장 중요한 세 단계만 진행하세요.

1. 시크릿을 확인하세요. .gitignore를 열어 .env가 등록되어 있는지 확인하고, 공개 저장소에 키가 없는지 확인하세요. 키가 유출됐다면 폐기하고 새로 발급받으세요.
2. RLS에 대해 물어보세요. 에이전트에게 “RLS가 꺼져 있는 테이블을 보여 줘”라고 말하고, 사람들의 데이터가 저장된 모든 곳에서 RLS를 활성화하세요.
3. 자주 백업하도록 설정하세요. 문제가 생겨도 며칠이 아니라 몇 분 분량의 데이터만 잃도록 하세요.

그런 다음 프로젝트가 커지고 돈과 다른 사람의 데이터를 다루기 시작할 때 위 체크리스트를 따르세요.

마지막으로 한 가지. 바이브 코딩의 보안은 소유자의 책임입니다. 보안 전문가가 될 필요는 없습니다. AI가 저녁 한 번 만에 제품을 만들었다면 다행입니다. 하지만 그 제품에 대한 책임은 당신에게 있습니다. 이 가이드에서 설명한 기본 수준이 그 책임을 실천하는 방법입니다.

모델을 더 사용하려면 Ailoot으로 이동할 수 있습니다.