화면이 뜨고 버튼이 눌리고 데이터가 저장되면, 만든 사람 눈에는 다 끝난 것처럼 보입니다. 바이브 코딩으로 며칠 만에 여기까지 도달하는 일은 이제 드물지 않습니다. 대표님이 직접 만든 화면을 들고 오시는 경우도 부쩍 늘었습니다.
문제는 그다음입니다. 사용자가 들어오는 순간 필요한 것은 '작동한다'가 아니라 '남의 데이터가 새지 않는다'입니다. 다행히 출시 전에 확인할 항목은 생각보다 적고, 대부분 개발 지식 없이도 직접 볼 수 있습니다.
돌아가는 것과 서비스할 수 있는 것은 다릅니다
Veracode가 2025년 7월 30일 공개한 GenAI Code Security Report는 100개가 넘는 언어모델에 코딩 과제를 시킨 뒤 결과물을 검사했습니다. 그중 45%가 OWASP Top 10에 해당하는 취약점을 포함하고 있었습니다.
언어별 실패율은 자바 72%, C# 45%, 자바스크립트 43%, 파이썬 38%였습니다. 같은 보고서는 모델이 새로 나올수록 기능은 좋아졌지만 보안 수준은 나아지지 않았다고 정리했습니다.
2025년 스택오버플로 개발자 설문에서도 응답자의 66%가 'AI의 답이 거의 맞지만 완전히 맞지는 않은 것'을 가장 큰 불편으로 꼽았습니다. 이 '거의'가 실서비스에서는 사고로 나타납니다.
코드가 돌아간다는 사실은 그 코드가 안전하다는 증거가 되지 못합니다.
점검 1. 남의 데이터가 보이는지 계정 두 개로 확인하세요
가장 흔하고 가장 치명적인 실수입니다. Supabase 공식 문서는 공개된 스키마의 테이블에 행 수준 보안(RLS, 사용자별로 볼 수 있는 행을 제한하는 기능)이 꺼져 있으면 권한을 가진 누구나 읽고 쓸 수 있다고 명시합니다.
실제 사고도 있었습니다. 바이브 코딩 플랫폼 Lovable의 취약점은 CVE-2025-48757로 등록됐고, 2025년 5월 29일 공개된 이 건의 심각도는 10점 만점에 9.3입니다. 로그인하지 않은 외부 공격자가 생성된 앱의 임의 테이블을 조회하거나 수정할 수 있었습니다.
확인 방법은 간단합니다. 테스트 계정 두 개를 만들고, A 계정으로 로그인한 상태에서 B 계정의 글과 주문, 연락처가 보이는지 보세요. 하나라도 보이면 출시하면 안 됩니다.
점검 2. 공개해도 되는 키와 절대 안 되는 키를 구분하세요
Supabase 문서는 공개용 키를 노출해도 안전하다고 설명하는데, 조건이 붙습니다. RLS가 켜져 있어서 접근 권한이 정책과 사용자 토큰으로 검사될 때에만 안전합니다.
정책이 없으면 그 공개 키가 사실상 마스터 키가 됩니다. 개발자나 도구에게 물어볼 질문은 하나입니다. "브라우저에 실려 있는 키로 할 수 있는 일이 정확히 무엇입니까"라고 물으세요.
점검 3. 사용자가 쓴 글이 코드로 실행되지 않는지 보세요
앞의 Veracode 보고서에서 가장 결과가 나빴던 항목이 크로스 사이트 스크립팅(CWE-80)입니다. 관련 코드 표본의 86%에서 방어에 실패했습니다.
위험한 화면은 정해져 있습니다. 후기, 문의, 댓글, 프로필 이름처럼 남이 입력한 값을 다른 사람 화면에 다시 보여주는 곳입니다. 입력란에 따옴표와 꺾쇠괄호가 섞인 문자열을 넣어보고 화면이 깨지는지 확인하세요.
점검 4. 백업은 있는지가 아니라 되돌려 봤는지로 판단하세요
Supabase 공식 문서 기준으로 무료 플랜에는 자동 일일 백업이 없습니다. 문서는 무료 플랜 사용자에게 명령줄 도구로 직접 데이터를 내보내 별도 보관하라고 권하고 있습니다.
유료 플랜은 보관 기간이 나뉩니다. Pro는 최근 7일, Team은 14일, Enterprise는 최대 30일치 일일 백업을 제공합니다. 특정 시점 복구는 Pro 이상에서 유료 부가 기능이고 최소 사양 조건이 붙습니다.
중요한 것은 복구를 실제로 해봤는지입니다. 테스트 데이터를 지운 뒤 되살리는 연습을 한 번 하면, 복구에 걸리는 시간과 잃는 데이터의 범위를 숫자로 알게 됩니다.
점검 5. 개인정보를 받는 순간 법이 따라옵니다
이름과 연락처 하나만 받아도 개인정보처리자가 됩니다. 개인정보 처리방침을 만들어 공개하고, 수집 항목과 보관 기간을 정해두어야 합니다.
개인정보 보호법 제64조의2는 과징금 상한을 전체 매출액의 100분의 3으로 정하고 있습니다. 매출액이 없거나 산정이 어려우면 20억원 이하입니다. 2023년 9월 15일부터 시행 중인 기준입니다.
그래서 가장 확실한 대응은 덜 받는 것입니다. 지금 쓰지도 않는 생년월일, 주소, 성별 항목이 가입 폼에 남아 있다면 출시 전에 지우세요.
점검 6. 사용자가 늘 때 요금이 어떻게 오르는지 계산하세요
바이브 코딩으로 만든 서비스는 대부분 무료 플랜 안에서 개발됩니다. 그 상태에서 본 것은 요금이 아니라 한도입니다.
앞의 백업 항목만 봐도 그렇습니다. 자동 백업을 쓰려면 유료 전환이 전제입니다. AI 기능을 붙였다면 호출 건수만큼 따로 과금됩니다. 사용자가 100명일 때와 1,000명일 때의 월 비용을 공식 요금 페이지에서 직접 계산해 보고 출시하세요.
점검 7. 코드와 계정이 내 이름으로 되어 있는지 확인하세요
서비스가 잘될수록 이 항목이 비싸집니다. 만든 사람과 연락이 끊겼을 때 내 손에 무엇이 남는지의 문제이기 때문입니다.
출시 전에 다음 항목이 모두 내 계정 아래에 있는지 확인하세요.
- 플랫폼 계정의 소유자와 결제 수단
- 도메인 등록 계정
- 소스 코드 저장소 접근 권한
- 데이터베이스 관리자 계정
- 결제·메일·문자 발송 서비스의 키
연락이 끊긴 뒤에 확인하면 그것은 점검이 아니라 복구입니다.
특히 코드를 통째로 내려받을 수 있는지 확인하세요. 내보내기가 막힌 도구를 썼다면 나중에 다른 개발자에게 넘기는 비용이 처음 개발비보다 커집니다.
이 7가지가 다 필요하지는 않은 경우도 있습니다
사내 직원 몇 명만 쓰는 내부 도구나 로그인이 없는 소개 페이지라면 1번과 2번은 해당하지 않습니다. 개인정보를 아예 받지 않는다면 5번도 넘어가도 됩니다. 규모에 맞지 않는 점검은 시간만 씁니다.
반대로 결제, 의료, 미성년자 데이터를 다룬다면 이 7가지로는 부족합니다. 그때는 출시 전에 보안 점검을 따로 받는 편이 낫습니다.
비슷한 주제의 글은 실무 가이드에 모아두었고, RLS 설정 방법은 Supabase 공식 문서에 정리돼 있습니다. 직접 점검하기 어려우시면 Codeforest에 문의하세요.
결론: 세 가지는 출시 전에, 나머지는 첫 달 안에 끝내세요
일정이 촉박하다면 순서를 정하세요. 1번 권한, 2번 키, 5번 개인정보는 출시 전에 반드시 끝내야 합니다. 이 세 가지는 사고가 나면 되돌릴 수 없고, 수습 비용이 개발비보다 큽니다.
3번과 4번, 6번과 7번은 출시 후 한 달 안에 처리해도 늦지 않습니다. 바이브 코딩의 장점은 시작이 빠르다는 것이지 점검을 건너뛰어도 된다는 뜻이 아닙니다. 계정 두 개로 로그인해 보는 10분이 그 차이를 만듭니다.