Lovable로 만든 앱, 출시 전 체크리스트 10가지
Lovable은 아이디어를 실제 앱으로 만드는 시간을 크게 줄여줍니다. 하지만 “화면이 잘 열린다”와 “고객에게 안전하게 공개할 수 있다”는 다른 문제입니다. 특히 Supabase 인증·데이터와 결제를 연결했다면 아래 순서로 확인하세요.
1. 브라우저 코드에 서버 전용 키가 없는가
Supabase의 anon 키처럼 공개되어도 되는 키와 service_role처럼 서버에만 있어야 하는 키를 구분해야 합니다. 배포된 자바스크립트에 관리자 키나 결제 시크릿이 들어가면 방문자 누구나 꺼낼 수 있습니다.
2. 모든 테이블에 RLS가 켜져 있는가
로그인 화면이 있어도 데이터베이스 정책이 없으면 API를 직접 호출해 다른 사용자의 데이터를 읽을 수 있습니다. 테이블별로 RLS 활성화 여부와 SELECT·INSERT·UPDATE·DELETE 정책을 각각 확인하세요.
3. URL의 ID만 바꿔 남의 데이터가 열리지 않는가
/orders/123의 숫자를 바꿨을 때 다른 주문이 보인다면 IDOR 취약점입니다. 화면에서 버튼을 숨기는 것으로는 막을 수 없고, 서버나 RLS에서 소유권을 검사해야 합니다.
4. 로그아웃 상태로 보호 API를 호출해보았는가
대시보드 주소를 직접 열고, 브라우저 개발자 도구에서 API 요청을 다시 보내보세요. 인증 토큰이 없거나 만료된 상태에서는 반드시 401 또는 403이 나와야 합니다.
5. 가격을 브라우저가 결정하지 않는가
결제 요청에 담긴 가격을 서버가 그대로 믿으면 값을 0원으로 바꿀 수 있습니다. 상품 ID만 전달하고 실제 가격은 서버의 상품 정의에서 다시 조회해야 합니다.
6. 결제 성공을 웹훅으로 검증하는가
성공 페이지에 도착했다는 이유만으로 유료 권한을 열면 안 됩니다. 결제사의 서버 검증 또는 서명된 웹훅을 기준으로 권한을 부여하고, 같은 웹훅이 두 번 와도 중복 지급되지 않게 처리하세요.
7. 개인정보처리방침과 탈퇴 경로가 보이는가
이름·이메일을 수집한다면 무엇을 왜 수집하고 얼마나 보관하는지 알려야 합니다. 서비스 안에서 회원 탈퇴와 데이터 삭제를 요청할 경로도 쉽게 찾을 수 있어야 합니다.
8. 모바일에서 가입·결제 버튼이 보이는가
375px 안팎의 화면에서 고정 헤더, 키보드, 긴 문구 때문에 핵심 버튼이 밀리지 않는지 확인하세요. 첫 화면뿐 아니라 로그인·결제·완료 화면까지 실제 휴대폰으로 밟아보는 것이 좋습니다.
9. .env와 .git 경로가 404를 반환하는가
/.env, /.env.local, /.git/HEAD를 공개 도메인 뒤에 붙여 확인하세요. 내용이 보인다면 즉시 배포 설정을 고치고 노출된 모든 키를 폐기·재발급해야 합니다.
10. 수정 뒤 다시 같은 검사를 했는가
AI에게 한 문제를 고치게 하면 다른 흐름이 바뀌기도 합니다. 수정 전 결과를 남기고 같은 URL·계정·시나리오로 재검사해야 실제로 해결됐는지 알 수 있습니다.
공식 참고 자료
- Supabase RLS 공식 문서 — 공개 스키마 정책과 service role 주의사항
- OWASP Web Security Testing Guide — 출시 전 보안 검증 범위
- 포트원 웹훅 연동 공식 문서 — 브라우저 응답 누락에 대비한 결제 상태 동기화