지난 글에서는 Supabase와 Firebase를 사용할 때 특히 조심해야 할 권한 설정 문제를 정리했다.
이번에는 한 단계 더 넓게 보려고 한다.
AI로 만든 웹앱은 실제로 어디에 배포될까?
그리고 배포 플랫폼이 달라지면 무엇을 먼저 확인해야 할까?
개인적으로 이 질문이 중요한 이유는, 많은 사람들이 “클라우드 보안”이라고 하면 곧바로 AWS, IAM, VPC, Security Group 같은 키워드를 떠올리기 때문이다.
물론 그것도 중요하다.
하지만 AI로 만든 초기 MVP나 사이드 프로젝트는 생각보다 그렇게 배포되지 않는 경우가 많다.
오히려 실제 흐름은 이런 경우가 더 많다.
v0로 만들고Vercel에 배포Replit에서 만들고Replit Publishing으로 공개Lovable로 만들고Lovable Cloud에 배포- 백엔드는
Supabase나Firebase에 연결
즉, AI로 만든 웹앱의 초기 보안 포인트는 raw AWS보다 상위 플랫폼 설정에 더 가까운 경우가 많다.
AI로 만든 웹앱은 왜 상위 플랫폼에 많이 배포될까
이유는 단순하다.
AI로 빠르게 만든 프로젝트는 보통 이런 요구가 있다.
- 빨리 배포하고 싶다
- 인프라 설정은 최소화하고 싶다
- 로그인, DB, 파일 업로드를 바로 붙이고 싶다
- 커스텀 도메인을 빠르게 연결하고 싶다
- 서버 운영보다 기능 구현에 집중하고 싶다
이 요구에 잘 맞는 게 Vercel, Replit, Lovable Cloud, Supabase, Firebase 같은 관리형 플랫폼이다.
예를 들어:
v0는 공식 페이지에서 바로Deploy to Vercel흐름을 전면에 두고 있다.Replit은Publishing기능으로 앱을 공개하고, 공식 문서에서 배포 인프라가Google Cloud Platform기반이라고 설명한다.Lovable은 공식 문서에서Publish your Lovable project,Lovable Cloud,Supabase,Custom domain을 별도 기능으로 안내한다.Supabase는Database,Auth,Storage,Edge Functions를 기본 제품으로 제공한다.Firebase는Authentication,Security Rules,Firestore,Storage,Hosting,App Hosting을 한 묶음으로 제공한다.
즉, AI로 만든 웹앱은 “클라우드를 안 쓴다”가 아니라, 클라우드를 더 높은 추상화 레벨에서 사용한다고 보는 게 맞다.
배포 플랫폼이 달라지면 보안 체크포인트도 달라진다
중요한 건 “어디에 배포했는가”에 따라 먼저 봐야 하는 포인트가 달라진다는 점이다.
예를 들어 AWS EC2에 직접 올린 앱이라면 이런 걸 먼저 볼 수 있다.
- 보안 그룹
- SSH 노출
- IAM 권한
- S3 bucket 정책
- ALB/WAF 설정
반면 Vercel, Replit, Lovable, Supabase, Firebase 같은 플랫폼에서는 사용자가 직접 이런 레벨을 만지지 않는 경우가 많다.
대신 아래 같은 질문이 더 중요해진다.
- 환경변수가 클라이언트로 노출되지는 않는가?
- Preview URL이나 임시 배포 URL이 외부에 열려 있지는 않은가?
- 로그인만 붙이고 권한은 비어 있지 않은가?
- 파일 업로드가 public으로 열려 있지는 않은가?
- 도메인, 인증서, 배포 환경 분리가 제대로 되어 있는가?
- 개발용 설정이 운영으로 그대로 나가지는 않았는가?
이게 초기 AI 웹앱 보안의 실제 출발점에 더 가깝다.
1. Vercel에 배포했다면 먼저 볼 것
v0를 쓰는 사람이라면 자연스럽게 Vercel로 이어지는 경우가 많다.
공식 페이지에서도 Deploy to Vercel을 직접 안내한다.
Vercel 계열에서 먼저 봐야 할 것은 이런 것들이다.
환경변수 관리
다음 값을 NEXT_PUBLIC_ 같은 public 환경변수로 넣고 있지 않은지 확인해야 한다.
- DB password
- API secret
- JWT secret
- Supabase
service_rolekey - Stripe secret key
- 관리자 토큰
브라우저에 전달되는 환경변수는 사용자에게 공개된다고 봐야 한다.
Vercel에 올렸다고 안전해지는 것이 아니라, 어떤 값이 클라이언트 번들에 들어가느냐가 더 중요하다.
Preview Deployment 노출
Vercel은 미리보기 배포가 편하다.
문제는 편한 만큼, 운영 전 상태의 URL이 외부에 공유되거나 노출될 수 있다는 점이다.
특히 아래 상황은 다시 확인할 필요가 있다.
- 임시 URL인데 로그인 없이 접근 가능
- 테스트 데이터가 그대로 들어 있음
- 운영용 API에 연결되어 있음
- 관리자 기능이 preview에서도 살아 있음
Source map과 디버그 정보
운영 배포에 source map이나 과한 debug log가 남아 있으면, 내부 구조가 지나치게 노출될 수 있다.
source map이 곧바로 취약점은 아니지만, 운영 정책상 공개가 적절한지는 따로 판단해야 한다.
2. Replit에 배포했다면 먼저 볼 것
Replit은 “만들고 바로 공개”가 쉬운 플랫폼이다.
공식 문서에서도 Publish 기능과 Custom domains, Access controls, Analytics를 함께 제공한다고 설명한다.
Replit 계열에서 먼저 봐야 할 것은 이런 것들이다.
앱 공개 범위
Replit에서는 배포를 누르는 순간 인터넷에 공개되는 흐름이 빠르다.
그래서 먼저 확인해야 한다.
- 지금 이 앱이 공개 상태인가?
- 누구나 접근 가능한가?
- 테스트용 앱인데 이미 외부 URL이 살아 있는가?
Secrets 관리
Replit은 secret 관리 기능을 제공하지만, 코드 안에 직접 key를 박아두는 실수는 여전히 발생할 수 있다.
특히 확인해야 할 것:
.env를 코드 저장소에 커밋했는가- Secret을 브라우저로 직접 내려주고 있지는 않은가
- 테스트용 third-party key를 그대로 운영에 쓰고 있지는 않은가
파일시스템에 데이터 저장
Replit 공식 문서도 배포된 앱의 파일시스템에 쓴 데이터를 영속 저장소처럼 믿지 말라고 안내한다.
즉 이런 구조는 다시 봐야 한다.
업로드 파일을 로컬 파일시스템에 저장
문의 데이터를 앱 내부 파일에 저장
세션 상태를 파일에만 기록이런 건 보안 문제이기도 하고 운영 안정성 문제이기도 하다.
3. Lovable로 배포했다면 먼저 볼 것
Lovable은 단순 코드 생성기를 넘어서, Lovable Cloud, Publish, Custom domain, Security overview, Test and Live environments 같은 기능을 문서에서 직접 제공한다.
이건 좋은 신호이기도 하다.
즉, 보안과 배포를 기능으로 다루고 있다는 뜻이다.
다만 그만큼 사용자가 직접 확인할 것도 있다.
테스트 환경과 운영 환경 분리
Lovable 문서에는 Test and Live environments 기능이 있다.
이게 중요한 이유는, 많은 초기 프로젝트가 아래처럼 꼬이기 쉽기 때문이다.
- 테스트 중인데 운영 데이터에 붙어 있음
- 내부 검토용 앱인데 이미 실서비스 도메인에 연결됨
- 실험용 기능이 라이브 환경에 반영됨
AI로 빠르게 만드는 흐름에서는 특히 더 자주 생길 수 있다.
Security overview를 실제로 보는가
Lovable 문서에는 Security overview, Security center, Sensitive data scanning, Project security view가 있다.
문제는 기능이 존재하는 것과 실제로 확인하는 것은 다르다는 점이다.
배포 전에 최소한 이런 질문은 해야 한다.
- 민감정보 스캔 결과를 봤는가?
- 보안 관련 경고를 무시하고 배포하지 않았는가?
- 외부 공유 설정이 과하게 열려 있지 않은가?
- 프로젝트 접근 범위가 적절한가?
Supabase 연동 상태
Lovable 프로젝트는 Supabase와 연결되는 경우가 많다.
그렇다면 결국 보안 핵심은 다시 RLS, Storage, key 권한으로 돌아온다.
즉 Lovable 보안은 Lovable 자체만 보면 끝나는 게 아니라, 연결된 Supabase 설정까지 같이 봐야 한다.
4. Supabase를 백엔드로 쓴다면 먼저 볼 것
Supabase는 AI로 만든 웹앱에서 가장 자주 붙는 백엔드 중 하나다.
이 경우 핵심은 명확하다.
RLS가 필요한 테이블에 켜져 있는가
- 사용자 데이터가 들어가는 테이블
- 주문, 예약, 문의, 결제, 업로드 메타데이터
- 관리자 외에는 보면 안 되는 데이터
정책이 너무 넓지 않은가
using (true)to authenticated using (true)
서버 전용 key가 클라이언트에 있지 않은가
service_role- secret key
Storage bucket이 public이어도 되는가
- 프로필 이미지는 공개 가능할 수 있음
- 계약서, 상담 파일, 증빙자료는 별도 판단 필요
Supabase에서는 결국 질문이 이거다.
이 사용자가 이 row와 이 파일에 접근할 수 있어야 하는가?
5. Firebase를 백엔드로 쓴다면 먼저 볼 것
Firebase 역시 AI와 함께 빠르게 MVP를 만들 때 자주 선택된다.
이 경우 먼저 보는 건 Security Rules다.
개발용 open rule이 남아 있지 않은가
allow read, write: if true;로그인만 확인하고 끝내지 않았는가
allow read, write: if request.auth != null;이건 “로그인하면 다 됨”에 가까울 수 있다.
사용자별 데이터에 uid 조건이 있는가
request.auth.uid == userIdStorage Rules도 따로 확인했는가
Firestore만 보고 끝내면 안 된다.
파일 업로드는 또 다른 권한 경계다.
클라이언트가 보내는 role 값을 믿고 있지 않은가
role: "admin"을 프론트에서 보내면 관리자 처리- 버튼만 숨겨두고 실제 권한 검증은 없음
Firebase는 제품 자체가 위험한 것이 아니라, Rules를 비워둔 상태로도 기능이 일단 되는 것처럼 보일 수 있다는 점이 함정이다.
AWS 보안 글은 나중에 쓰는 게 더 나은 이유
여기서 오해하면 안 되는 점이 있다.
AWS 보안이 덜 중요하다는 뜻은 아니다.
오히려 나중에 서비스가 커지면 더 중요해진다.
다만 지금 이 시점, 즉:
- AI로 웹앱을 만든 비개발자
- 빠르게 MVP를 만든 기획자/창업자
- Supabase/Firebase/Vercel/Replit/Lovable을 쓰는 사용자
이 사람들에게는 IAM, VPC, NACL, ALB, Private Subnet보다 먼저 봐야 하는 것이 있다.
그게 바로:
- 공개 URL
- 배포 환경
- secrets 노출
- 권한 설정
- Storage 공개 범위
- 테스트/운영 분리
즉, 초기 AI 웹앱 보안의 출발점은 플랫폼 보안 설정에 더 가깝다.
배포 전에 확인할 체크리스트
AI로 만든 웹앱이라면 배포 전에 최소한 아래 질문은 해보는 것이 좋다.
공통 체크
- 공개 URL이 이미 외부에 열려 있지 않은가?
- 테스트용 앱이 실데이터와 연결되어 있지 않은가?
- 커스텀 도메인이 올바른 앱에 연결되어 있는가?
- HTTPS는 정상인가?
- 운영 환경 변수와 테스트 환경 변수가 분리되어 있는가?
프론트엔드/배포 플랫폼
- public 환경변수에 secret이 들어가 있지 않은가?
- preview deployment가 과도하게 공유되고 있지 않은가?
- debug 로그와 source map 정책은 괜찮은가?
관리형 백엔드
- Supabase RLS 또는 Firebase Security Rules가 있는가?
- 사용자별 데이터 접근 제한이 있는가?
- 업로드 파일이 public이어도 되는가?
- service key나 admin 권한이 클라이언트에 없나?
마무리
AI로 만든 웹앱이 모두 AWS를 직접 다루는 것은 아니다.
오히려 많은 초기 프로젝트는 Vercel, Replit, Lovable Cloud, Supabase, Firebase 같은 상위 플랫폼 위에서 만들어지고 배포된다.
그래서 보안도 그 현실에 맞게 봐야 한다.
초기 단계에서 진짜 먼저 확인해야 하는 것은 이런 것들이다.
- 어디에 배포되었는가
- 누가 그 URL에 접근할 수 있는가
- 어떤 데이터가 public으로 열려 있는가
- 권한 설정이 실제로 존재하는가
- secret이 브라우저로 내려가지 않는가
즉 질문은 더 이상 이것만이 아니다.
어떤 클라우드를 쓰고 있는가?이제는 이것도 같이 물어야 한다.
이 플랫폼에서 내가 직접 확인해야 할 보안 경계는 어디인가?참고자료
