**바이브코딩 보안 실수 3가지 — Transcript & Summary | SozAI**
Source: https://sozai.app/transcript/vibecoding-security-mistakes-3/

바이브코딩 앱에서 흔히 발생하는 보안 실수 3가지와 해결책, AI 시대 보안 중요성을 쉽게 설명합니다.

## Key Takeaways

- RLS 설정은 문법뿐 아니라 설계가 중요하며, 구체적 시나리오로 반드시 감사해야 한다.
- 프론트엔드 제한은 쉽게 우회 가능하므로 백엔드에서 사용자별 및 IP 기반 Rate Limit을 반드시 적용해야 한다.
- 민감한 API 키는 절대 프론트엔드에 노출하지 말고 백엔드에서만 호출하며 예산 한도를 설정해야 한다.
- AI가 만든 코드도 보안 취약점이 많으므로 사람이 직접 보안 검토와 설계를 해야 한다.
- 보안은 개발 역량의 핵심이며, AI 시대에도 '딸깍 한 번이면 끝'이라는 환상을 버려야 한다.

## What the video covers

- 바이브코딩으로 만든 앱 20,000개 중 11%가 데이터베이스 비밀번호를 프론트엔드에 노출했고, 83%는 접근 제어가 없었다.
- Supabase와 Firebase 같은 백엔드 없는 개발 방식이 보안 사고 증가의 원인 중 하나이다.
- 첫 번째 실수는 RLS(Row Level Security) 설정 오류로, 설계 문제로 인해 사용자가 권한을 우회할 수 있다.
- 두 번째 실수는 백엔드에 사용자별 및 IP 기반 Rate Limit 미설정으로, API 남용과 과금 폭탄 위험이 있다.
- 세 번째 실수는 민감한 API 키를 프론트엔드에서 직접 호출해 키가 노출되는 문제이다.
- 환경변수는 백엔드에서만 안전하며, 민감한 API 호출은 반드시 백엔드에서 해야 한다.
- AI가 코드를 생성해도 보안 설계와 검토는 사람이 직접 해야 하며, AI가 놓치는 부분을 보완할 수 있다.
- 보안 체크리스트: 1) RLS 구체적 시나리오 감사, 2) 백엔드 Rate Limit 설정, 3) 민감한 API 백엔드 호출 및 예산 한도 설정.
- AI 시대에 중요한 것은 단순한 기능 구현이 아니라 보안까지 포함한 개발 역량이다.
- 보안 사고 예방을 위해 의도적인 보안 대화와 점검이 필수적이다.

## Chapters

1. 00:00 바이브코딩 앱 보안 현황과 문제점 소개
2. 00:24 보안 사고 증가 원인과 백엔드 없는 개발 방식
3. 00:50 첫 번째 실수: RLS 잘못 설정 사례와 문제점
4. 02:00 두 번째 실수: Rate Limit 미설정과 해결책
5. 02:56 세 번째 실수: 프론트엔드에서 민감한 API 직접 호출 문제
6. 03:40 AI 코드의 보안 취약점과 사람의 역할
7. 04:13 보안 체크리스트 정리와 AI 시대 개발 역량 강조
8. 04:50 마무리 및 구독과 좋아요 요청

Answers

## Questions about this video

RLS 설정이 왜 중요한가요?

RLS는 데이터베이스 접근 권한을 사용자별로 제한하는 기능으로, 잘못 설계하면 사용자가 권한을 우회해 전체 데이터에 접근할 수 있습니다. 따라서 구체적 시나리오로 반드시 감사해야 합니다.

프론트엔드에서 Rate Limit을 설정하는 것만으로 충분한가요?

아니요. 프론트엔드 제한은 쉽게 우회될 수 있으므로 백엔드에서 사용자별 및 IP 기반 Rate Limit을 반드시 설정해야 API 남용과 과금 폭탄을 방지할 수 있습니다.

민감한 API 키는 어떻게 안전하게 관리해야 하나요?

민감한 API 키는 절대 프론트엔드에 노출되어서는 안 되며, 백엔드에서만 호출해야 합니다. 또한 예산 한도를 설정해 과금 폭탄을 예방하는 것이 중요합니다.

## Full Transcript — Download SRT & Markdown

00:00

Speaker A

AI로 만든 앱, 절반 이상이 해킹 가능합니다. 보안 연구팀이 바이브코딩으로 만든 앱 20,000개를 스캔했는데요. 11%가 데이터베이스 비밀번호를 프론트엔드에 그대로 노출하고 있었고, 그중 83%는 접근 제어가 아예 없었습니다.

00:16

Speaker A

누구나 전체 데이터를 다운로드할 수 있는 상태였어요. 오늘 바이브코딩 시대에 가장 흔한 보안 실수 3가지랑 체크리스트까지 다 정리해드릴게요.

00:24

Speaker A

왜 갑자기 보안 사고가 이렇게 많아졌을까요? Supabase랑 Firebase가 "백엔드 없이 개발하세요"라는 콘셉트로 나왔거든요. 원래 앱은 프론트엔드, 백엔드, 데이터베이스 이렇게 3단계인데, 이 서비스들은 프론트엔드에서 데이터베이스에 직접 접근하게 해줍니다.

00:40

Speaker A

빠르긴 한데 보안 설정을 직접 해야 돼요. 근데 AI한테 "앱 만들어줘"라고 하면 기능은 만들어주는데 보안 설정은 빠뜨리는 경우가 태반입니다.

00:50

Speaker A

첫 번째 실수, RLS 잘못 설정입니다. RLS는 Row Level Security의 약자인데요. 쉽게 말하면 데이터베이스의 출입증 같은 겁니다.

00:58

Speaker A

"너는 네 데이터만 볼 수 있어"라고 규칙을 거는 거예요. 이게 없으면 누구든 전체 데이터를 다 볼 수 있습니다.

01:05

Speaker A

10년 경력 개발자 Chris의 칼로리 앱 사례를 보면요. RLS 자체는 정확하게 설정했어요. 사용자가 자기 데이터만 읽고 쓸 수 있게요.

01:13

Speaker A

근데 구독 상태랑 API 호출 제한을 같은 테이블에 넣었거든요. 그러니까 사용자가 자기 구독 상태를 프리미엄으로 바꿀 수 있었고, API 호출 제한도 풀어서 AI를 무제한 호출했어요.

01:26

Speaker A

만 달러짜리 청구서가 날아올 뻔했습니다. 여기서 중요한 게, Claude한테 RLS 감사를 맡겼는데 이걸 못 잡았어요.

01:33

Speaker A

RLS 문법 자체는 맞았으니까요. 이건 문법 문제가 아니라 설계 문제입니다. SQL은 AI가 써줍니다. 하지만 어떤 데이터를 어떤 테이블에 분리할지, 이건 전체 플로우를 이해하는 사람이 판단해야 해요.

01:47

Speaker A

바이브코딩 플랫폼 Lovable으로 만든 앱에서 18,000명의 학생 데이터가 노출된 사건도 있었습니다. 인증 로직이 거꾸로 작동해서 정상 사용자는 차단하고 공격자는 접근 가능한 상태였어요.

02:00

Speaker A

성적 변경, 계정 삭제까지 가능했습니다. 두 번째 실수, Rate Limit 미설정입니다. "프론트엔드에서 하루 5회 제한 걸었으니 괜찮지?" 이렇게 생각하시죠?

02:10

Speaker A

근데 누군가 여러분의 API 엔드포인트 주소를 찾으면 프론트엔드 제한은 완전히 무시하고 백엔드를 직접 때립니다. 그 주소 찾는 거 어렵지 않아요.

02:20

Speaker A

브라우저 개발자 도구 Network 탭에 다 보여요. 모바일 앱도 마찬가지입니다. 요청을 가로채는 게 어렵지 않아요.

02:26

Speaker A

해결책은 간단해요. 백엔드에 사용자별 Rate Limit을 거세요. 그리고 IP 기반 제한도 추가하면 계정을 수백 개 만들어서 우회하는 것도 막을 수 있어요.

02:37

Speaker A

AI 기능이 없어도 이건 해야 합니다. Supabase랑 Firebase는 사용량 기반 과금이라 스팸 요청만으로도 요금 폭탄 맞을 수 있거든요.

02:46

Speaker A

코딩은 전체의 10%예요. 이런 설정이 나머지 90%입니다. 세 번째 실수, 프론트엔드에서 민감한 API 직접 호출입니다.

02:56

Speaker A

AI API, Stripe 결제, 이메일 서비스, 클라우드 저장소 이런 걸 프론트엔드에서 직접 부르면 키가 노출됩니다.

03:03

Speaker A

큰 착각 하나 짚고 갈게요. 환경변수에 넣으면 안전하다? 아닙니다. 프론트엔드와 모바일 앱의 환경변수는 전부 추출 가능해요.

03:12

Speaker A

환경변수가 안전한 곳은 백엔드뿐입니다. Chris 본인도 과거에 AWS 키가 유출됐는데 누군가 그 키로 머신러닝 훈련을 돌려서 삼만 달러짜리 청구서를 받았어요.

03:22

Speaker A

해결책이요. 민감한 API는 무조건 백엔드에서만 호출하세요. Supabase Edge Functions나 Firebase Functions를 쓰면 됩니다. 그리고 예산 한도를 반드시 설정하세요.

03:34

Speaker A

앱이 잠깐 죽는 게 만 달러 청구서보다 백 배 낫습니다. 그러면 바이브코딩 자체가 위험한 걸까요?

03:40

Speaker A

솔직히 말하면 아닙니다. Veracode 보고서에 따르면 AI가 생성한 코드의 45%가 취약점을 포함하긴 해요. 근데 사람이 짠 코드도 취약점 투성이였거든요.

03:51

Speaker A

오히려 AI가 있으면 사람이 놓치는 엣지 케이스를 잡아줄 수 있어요. 핵심은 "딸깍 한 번이면 끝"이라는 환상을 버리는 겁니다.

03:59

Speaker A

AI한테 "만들어줘"만 하면 기능은 만들어줘요. 근데 "이거 해킹 안 당하겠지?"라는 질문은 사람이 해야 해요. 저도 afterWork 앱을 만들면서 느꼈는데 AI의 "완료"와 내 "완료"는 기준이 다릅니다.

04:13

Speaker A

AI의 완료는 기능이 돌아가는 거고, 내 완료는 해킹 불가능한 상태여야 해요. 의도적으로 보안 대화를 나누면 혼자 짜는 것보다 훨씬 안전합니다.

04:23

Speaker A

정리합니다. 체크리스트 3가지요. 첫째, RLS를 구체적 시나리오로 감사하세요. "사용자가 구독 상태를 바꿀 수 있나?", "다른 사용자 데이터를 볼 수 있나?" 둘째, 백엔드에 사용자별 및 IP 기반 Rate Limit을 거세요.

04:38

Speaker A

셋째, 민감한 API는 백엔드에서만 호출하고 예산 한도를 설정하세요. AI 시대에 중요한 건 AI가 아니라 만드는 역량이고, 보안도 그 역량의 일부입니다.

04:50

Speaker A

도움이 됐다면 구독과 좋아요 부탁드려요. 감사합니다.

Topics: 바이브코딩 보안 실수 RLS Rate Limit 민감한 API AI 개발 Supabase Firebase 앱 보안 데이터베이스 보안


---
This is the markdown twin of https://sozai.app/transcript/vibecoding-security-mistakes-3/ — the same content, without the markup.
Published by SozAI (https://sozai.app). Reuse and quotation are allowed with attribution and a link back.
Machine-readable index: https://sozai.app/llms.txt · data API: https://sozai.app/api/