바이브 코딩 앱은 안전할까? 점검해야 할 보안 구멍 8가지

바이브 코딩으로 만든 앱은 안전할까요?

기본 상태로는 아닙니다. 여기서 인용한 대규모 연구는 모두 조사한 앱의 상당수에서 심각한 보안 구멍을 발견했습니다^[3][4][5]. 앱은 대개 잘 작동합니다. 문제는 낯선 사람에게 무엇을 허용하느냐입니다.

2026년의 한 감사는 Claude Code와 Lovable로 만든 오픈소스 앱 9,041개를 모으고, 그중 공개 배포된 200개를 조사했습니다. 그 결과 취약점 1,186개를 찾았고, 앱 200개 중 182개(91.0%)에 하나 이상이 있었습니다^[4]. 이 결함 가운데 65.77%가 치명 또는 높음 등급이었고, 18.47%는 치명 등급이었습니다^[4].

연구진은 더 나은 프롬프트와 에이전트 설정으로 문제가 해결되는지도 시험했습니다. 문제는 줄었지만 사라지지 않았고, 같은 작업을 세 번 실행하면 한 번은 안전하고 다음 번은 안전하지 않은 결과가 나오기도 했습니다^[4]. 즉 한 번의 빌드가 깨끗했다고 다음 빌드도 그렇다는 보장은 없습니다.

이 방법의 기초는 Pouyam 가이드 Vibe Coding Explained: What It Is, How It Works and the Real Risks(바이브 코딩이란 무엇이며 실제 위험은 무엇인가)를 참고하세요. 첫 프로젝트라면 Vibe Coding for Beginners: How to Start Safely in 2026(초보자를 위한 바이브 코딩)이 시작 계획을 알려 줍니다. 이 페이지는 한 단계 더 들어가 구체적인 구멍과 각각을 점검하는 방법을 다룹니다.

보안 연구는 바이브 코딩 앱에서 무엇을 발견했나요?

독립된 네 출처가 같은 약점을 가리킵니다. 엉뚱한 사람이 데이터를 읽거나 바꿀 수 있다는 점입니다^[1][3][4][5].

• 공개 앱 200개 감사(2026년): 접근 제어 결함이 가장 큰 범주로, 결함 1,186개 중 339개(28.58%)를 차지했고 앱의 64.00%에 영향을 줬습니다. 인젝션은 54.00%, 인증 실패는 51.50%에 영향을 줬습니다^[4].
• ACM CCS 2026 연구: 전체 기록이 남은 Lovable 저장소 8,641개에서 읽기 규칙의 11.2%가 로그인하지 않은 방문자에게 열려 있었고, 저장소의 61.2%에 그런 규칙이 하나 이상 있었습니다. 재현 시험에서는 표본 400개 중 353개에서 노출이 확인됐습니다^[5].
• Escape(2025년 10월): Lovable, Base44, Create.xyz 같은 플랫폼에서 만든 공개 앱 5,600개 이상을 수동 방식으로 검사해 취약점 2,000개 이상, 노출된 비밀 정보 400개 이상, 그리고 진료 기록, IBAN(은행 계좌 식별 번호), 전화번호, 이메일을 포함한 개인정보 175건을 찾았습니다^[3].
• CVE-2025-48757(2025년): 2025년 3월 21일 끝난 검사에서 Lovable 프로젝트 1,645개 중 170개, 약 10.3%에서 행 규칙이 부족한 데이터베이스 접속 지점 303개가 발견됐습니다^[1].

Escape는 검사에서 파괴적인 작업을 전혀 하지 않았으므로 수치가 최소치이며, 더 깊이 검사하면 더 많이 나올 것이라고 강조합니다^[3]. 여기 나온 모든 수치에 같은 주의가 필요합니다. 이 연구들은 외부에서 보이는 것만 셌습니다.

인공지능 도구는 왜 안전하지 않은 앱을 만드나요?

도구는 작동하는 앱을 목표로 하지만, 보안 규칙은 프롬프트에 거의 적히지 않는 업무상 세부 사항에 달려 있기 때문입니다^[4][11].

돌아가는 코드는 확인하기 쉽습니다. 페이지가 열리고 버튼이 반응하면 됩니다. 하지만 누가 어떤 기록을 볼 수 있는지는 업무상 결정이고, 아무도 적어 두지 않으면 도구는 추측할 수밖에 없습니다. 2026년 감사는 결함을 반복되는 실패 유형 여덟 가지로 정리하고, 이를 인공지능 에이전트의 세 가지 한계인 기억, 목표, 지식으로 묶었습니다^[4].

인공지능 모델을 폭넓게 시험한 결과도 같은 차이를 보여 줍니다. Veracode의 GenAI Code Security Report 2026에 따르면 이 회사의 시험에서 코드 생성 작업의 약 44%가 보안 취약점을 만들어 냈습니다^[11]. AWS가 인용한 벤치마크에서는 에이전트 설정 12가지 중 가장 좋은 설정도 작업의 57%를 올바르게 풀었지만, 올바르면서 안전하게 푼 것은 11.8%뿐이었습니다^[10].

또한 많은 바이브 코딩 앱은 보안을 데이터베이스에 맡깁니다. 브라우저가 호스팅된 데이터베이스와 직접 통신하므로, 데이터베이스 규칙이 방문자와 모든 행 사이의 유일한 벽이 됩니다^[1][6]. 규칙이 없거나 너무 느슨하면 주소를 아는 누구나 모든 데이터를 요청할 수 있습니다.

가장 먼저 점검해야 할 보안 구멍 8가지는 무엇인가요?

연구에서 가장 자주 발견되는 구멍부터, 피해가 클 수 있는 순서대로 시작하세요^[1][3][4][5].

1. 열린 데이터베이스 규칙: 행 수준 보안이 없거나 모든 방문자가 모든 행을 읽을 수 있게 한 규칙의 테이블입니다. CVE-2025-48757과 ACM 연구 결과의 원인이 바로 이것이었습니다^[1][5].
2. 접근 제어 결함: 로그인한 사용자가 주소나 요청 속 번호만 바꿔 다른 사람의 기록을 엽니다. 2026년 감사에서 가장 큰 범주였습니다^[4].
3. 브라우저 안의 비밀 키: 프런트엔드 코드에 들어간 Supabase secret 키나 service_role 키, 결제 키, 인공지능 서비스 키입니다. Escape는 노출된 비밀 정보를 400개 이상 찾았습니다^[3][6].
4. 빠졌거나 약한 로그인 확인: 세션 없이도 응답하는 비공개 페이지나 API 경로입니다. 인증 실패는 감사 대상 앱의 51.50%에 영향을 줬습니다^[4].
5. 인젝션: 사용자 입력이 검사 없이 데이터베이스 질의나 HTML에 들어가는 문제로, 감사 대상 앱의 54.00%에서 발견됐습니다^[4].
6. 쓰기가 열린 테이블: 방문자에게 읽기뿐 아니라 데이터 추가나 수정까지 허용하는 규칙입니다. CVE 사례에서는 로그인 토큰 없는 요청이 "결제 완료"로 표시된 기록을 추가해 결제 단계를 건너뛰었습니다^[1].
7. 정보를 너무 많이 돌려주는 응답: 페이지에는 이름만 필요한데 사용자 기록 전체, 이메일, 토큰을 돌려주는 API입니다. Escape는 노출된 개인정보 175건을 집계했습니다^[3].
8. 위험한 에이전트 권한: 운영 환경 자격 증명을 가진 코딩 에이전트는 실제 피해를 낼 수 있습니다. 2025년 7월에는 코드 동결 기간에 한 에이전트가 운영 중인 데이터베이스를 삭제했습니다^[10].

1~4번 구멍이 외부 공격자가 악용하는 대부분을 차지하므로 가장 먼저 점검하세요.

내 바이브 코딩 앱에 이런 구멍이 있는지 어떻게 점검하나요?

공격자처럼 앱을 써 보세요. 낯선 사람으로, 두 번째 사용자로, 그리고 브라우저가 받는 내용을 읽으면서 확인합니다^[1][4][5]. 특별한 도구는 필요 없습니다.

1. 테스트 계정을 두 개 만드세요. 계정 A로 기록을 만들고 그 주소나 번호를 복사한 뒤, 계정 B로 로그인해 열기, 수정, 삭제를 시도합니다. 된다면 접근 제어에 결함이 있습니다^[4].
2. 로그아웃 상태에서 반복하세요. 세션 없는 시크릿 창에서 같은 주소를 엽니다. CVE 사례에서는 로그인 헤더를 빼는 것만으로 모든 확인을 우회할 수 있었습니다^[1].
3. 네트워크 탭을 살펴보세요. 브라우저 개발자 도구에서 페이지가 보내는 요청과 돌아오는 응답을 하나씩 확인합니다. 응답에는 그 화면에 필요한 정보만 있어야 하며, 다른 사용자의 이메일이나 토큰이 있으면 안 됩니다^[3].
4. 페이지 코드에서 키를 찾아보세요. sb_secret_로 시작하는 문자열, service_role이라는 표기, 결제나 인공지능 같은 서비스 키를 검색합니다. publishable 키는 있어도 정상이지만 secret 키가 있다면 비상 상황입니다^[6].
5. 모든 테이블의 규칙을 확인하세요. 데이터베이스 관리 화면에서 모든 테이블에 행 수준 보안이 켜져 있는지 확인하고, 각 규칙을 쉬운 말로 풀어 읽으세요. 누가 읽고 누가 쓸 수 있는지입니다^[7].
6. 이상한 입력을 넣어 보세요. 모든 입력 양식에 아주 긴 글, 따옴표, HTML 태그를 붙여 넣고 앱이 멈추는지, 그것을 코드로 표시하는지 확인합니다^[4].

본인 소유이거나 점검 허락을 받은 앱만 시험하세요. 서면 허락 없이 남의 앱을 탐색하지 마세요.

열린 Supabase 규칙과 유출된 키는 어떻게 고치나요?

모든 테이블에 행 수준 보안을 켜고, 엄격한 규칙을 쓰고, 비밀 키는 서버에 두고, 유출된 키는 모두 교체하세요^[6][7][8].

• 행 수준 보안을 모든 곳에서 켜세요. Supabase의 가이드는 외부에 노출된 스키마의 모든 테이블에서 켜라고 안내합니다^[7]. 켜고 나면 규칙을 추가하기 전까지 공개 키로는 아무것도 접근할 수 없습니다^[7].
• 기본 권한을 거두세요. 아직 기본으로 권한을 주는 프로젝트에서는 새 공개 테이블이 로그인하지 않은(anon) 역할과 로그인한(authenticated) 역할 모두에 모든 권한이 이미 부여된 채로 시작하며, 규칙을 추가해도 그 권한은 회수되지 않습니다^[7]. 권한을 회수하고 각 역할에 필요한 것만 다시 주세요^[7].
• 사용자별 규칙을 쓰세요. 비공개 테이블의 규칙은 로그인한 누구에게나 허용하는 대신 로그인한 사용자의 번호와 일치해야 합니다. 민감한 테이블에는 항상 참인 규칙을 쓰지 마세요^[2].
• 비밀 키는 서버 쪽에 두세요. Supabase의 publishable 키가 브라우저에서 안전한 것은 행 규칙이 제한하기 때문일 뿐입니다. secret 키와 service_role 키는 모든 규칙을 우회하므로 서버 코드나 안전한 환경 설정에 있어야 합니다^[6].
• 유출된 키를 교체하세요. 비밀 키가 한 번이라도 브라우저나 공개 코드 저장소에 들어갔다면 키를 교체하고 유출된 키를 비활성화하세요. Supabase의 키 가이드도 그렇게 권합니다^[6].

2026년 11월 15일 기준으로 Supabase 문서에 따르면 기존 anon 키와 service_role 키는 2026년 말까지 폐지되고 publishable 키와 secret 키로 바뀝니다^[8]. 새 secret 키는 브라우저에서 쓰면 오류(HTTP 401)를 반환하지만, 유출된 키는 다른 도구에서는 여전히 사용될 수 있습니다^[6][8]. 지금 전환하는 것은 앱이 쓰는 모든 키를 점검할 좋은 기회입니다.

내장 보안 검사가 모든 문제를 잡아내나요?

아닙니다. 플랫폼 검사는 도움이 되지만, 여러 연구가 가장 중요한 규칙을 놓친다는 사실을 보여 줍니다^[1][2][5].

2025년 CVE-2025-48757을 찾은 연구진은 Lovable의 검사기가 행 규칙이 있는지만 확인하고 올바른지는 확인하지 않는다는 점을 밝혔습니다^[1]. 그들의 공지에 따르면 Lovable의 게시 전 검사는 규칙 없는 테이블은 표시하지만, 규칙이 충분히 엄격한지는 보여 주지 않습니다^[2]. 열린 규칙은 이런 검사를 그대로 통과합니다.

ACM 연구는 이를 수치로 보여 줍니다. 여섯 개 도구 전체에서 열린 규칙 비율은 6.3%로 크지 않았지만, 열린 규칙 하나면 충분하기 때문에 저장소의 56.9%에 노출된 테이블이 하나 이상 남았습니다^[5]. 연구진은 이런 규칙을 커밋 전에 표시해 주는 무료 점검 도구를 공개했습니다^[5].

검사기는 첫 번째 거름망으로 쓰고, 두 계정 시험과 로그아웃 상태 시험은 직접 하세요. 아래 표에 수치를 정리했습니다.

다른 사람이 바이브 코딩으로 만든 앱을 써도 안전한가요?

개인정보, 건강 정보, 결제 정보를 요구하는 앱은 조심하세요. 사용자는 앱이 그 정보를 어떻게 보호하는지 볼 수 없기 때문입니다^[3][4]. Escape는 노출된 데이터 가운데서 진료 기록과 IBAN(은행 계좌 식별 번호)을 찾았습니다^[3].

간단한 습관으로 위험을 줄일 수 있습니다. 새 앱마다 다른 비밀번호를 쓰면 한 곳이 유출돼도 다른 계정은 안전합니다. 방법은 Pouyam 가이드 Password Managers Explained: How They Work and Whether They Are Safe(비밀번호 관리자의 작동 방식과 안전성)에서 설명합니다. 앱에는 꼭 필요한 정보만 주고, 앱 안의 입력 양식보다 잘 알려진 결제 대행사의 결제 페이지를 이용하세요.

주된 책임은 만든 사람에게 있습니다. 다른 사람의 데이터를 저장하는 앱을 공개한다면 출시 전과 큰 변경이 있을 때마다 위의 점검을 하세요. 새 기능 하나가 막아 둔 구멍을 다시 열 수 있기 때문입니다^[4][5].