바이브코딩으로 만든 서비스, 런칭 전에 이 세 가지부터 확인하세요
바이브코딩으로 기능을 완성하고 배포까지 했다고 해서 바로 운영할 준비가 끝난 것은 아닙니다.
다른 사용자가 들어오기 시작하면 내 화면에서 잘 작동하는 것과는 다른 문제가 생깁니다.
- 다른 사용자의 데이터까지 볼 수 있지는 않은가
- 비밀 키가 코드나 브라우저에 노출되지는 않았는가
- 에러가 생겼을 때 운영자가 바로 알 수 있는가
아래 세 프롬프트를 프로젝트에서 하나씩 실행해 보세요.
처음에는 코드를 바로 고치게 하지 않고 현재 상태와 실패할 수 있는 경우부터 확인하는 것이 좋습니다.
바로 쓰는 점검 프롬프트 3개
1. 보안 점검 - 사용자 권한
현재 프로젝트를 런칭 전 사용자 권한 관점에서 점검해줘.
아직 코드는 고치지 마.
- API와 Server Action에 인증·인가가 빠진 곳이 있는지
- 다른 사용자의 데이터나 파일에 접근할 수 있는지
(Supabase를 쓴다면 RLS 포함)
- 관리자 화면과 관리자 API가 일반 사용자에게 열려 있지 않은지
- 요청 body를 통째로 반영하고 있지 않은지
- 응답에 화면에서 쓰지 않는 개인정보까지 내려주고 있지 않은지
결과는 아래 순서로 정리해줘.
1. 위험한 항목과 그 근거
2. 내가 직접 해볼 실패 테스트
3. 바로 고칠 수 있는 것
4. 사람이 정책을 결정해야 하는 것
화면에서 버튼을 숨기는 것으로는 부족합니다. 직접 들어온 요청도 서버와 데이터베이스의 세 관문에서 걸러져야 합니다.
2. 보안 점검 - 우리 서비스
현재 프로젝트를 런칭 전 서비스 운영 보안 관점에서 점검해줘.
아직 코드는 고치지 마.
- API 키, 환경변수, 오류 응답을 통한 민감 정보 노출
- 로그인과 AI 호출 등의 rate limit과 과금 상한
- 로컬·프리뷰·운영 환경과 데이터베이스의 분리
- 데이터베이스 백업과 복구 가능 여부
- 사고가 났을 때 키 재발급과 기능 잠금 방법
- 에러 폭증이나 비용 급증을 알 수 있는 이상 감지 알림
결과는 아래 세 범주로 나눠줘.
- 새지 않게
- 무너지지 않게
- 잃지 않게
각 항목마다 현재 상태, 문제가 생겼을 때의 영향,
직접 확인할 방법, 먼저 처리할 순서를 알려줘.
키 노출, 과도한 요청, 데이터 손실은 막는 방법과 복구 방법이 각각 다릅니다.
3. 모니터링 점검
Vercel과 Supabase의 최근 24시간 운영 상태를 확인해줘.
아직 설정이나 코드는 바꾸지 마.
[Vercel]
- 배포 상태와 실패한 빌드
- 에러 수와 가장 많이 발생한 경로
- 실패가 몰린 시간대
[Supabase]
- Auth 실패
- RLS로 거부된 요청
- 가장 느린 쿼리와 그 원인
전체를 정상 / 주의 / 확인 필요로 나눠서 요약하고,
지금 손봐야 할 것 3개만 근거와 함께 알려줘.
정보가 부족하면 추측하지 말고 어떤 로그나 설정이 더 필요한지 알려줘.
지표로 이상한 구간을 찾고, 그 구간의 로그로 개별 사건을 좁혀갑니다.
Vercel이나 Supabase가 아닌 다른 서비스를 쓴다면 프롬프트의 서비스 이름만 현재 사용하는 도구로 바꾸면 됩니다.
운영 환경을 읽을 때는 먼저 읽기 권한만 연결하고, 점검과 수정을 나눠서 진행하세요.
왜 보안을 두 번 나눠서 볼까요?
“해킹당하지 않게 해줘”는 너무 큰 요청입니다.
런칭 전에는 사용자 권한과 서비스 운영이라는 두 관점으로 나누면 점검하기 쉽습니다.
관점 1. 사용자가 자기 권한 밖의 데이터에 접근할 수 있는가
요청은 세 관문을 통과해야 합니다.
- 인증 - 누가 요청을 보냈는가
- 인가 - 이 사용자가 해당 데이터에 접근할 자격이 있는가
- 입력과 출력 - 허용한 값만 받고 필요한 정보만 돌려주는가
화면에서 버튼을 숨기는 것으로 끝내지 말고, 아래처럼 원래 막혀야 하는 요청을 직접 보내보세요.
| 직접 해볼 것 | 정상 결과 |
|---|---|
| 로그아웃한 상태로 보호된 페이지에 들어간다 | 접근이 막힌다 |
| 다른 사용자의 ID로 조회·수정·삭제를 요청한다 | 접근이 막힌다 |
일반 계정으로 /admin에 들어간다 | 접근이 막힌다 |
| 다른 사용자의 파일 URL을 주소창에 직접 붙인다 | 파일이 열리지 않는다 |
요청 body에 isAdmin: true를 끼워 넣는다 | 값이 무시된다 |
되는 것을 다시 확인하기보다 원래 막혀야 할 요청을 직접 보내봅니다.
Supabase를 쓴다면 앱 화면뿐 아니라 데이터베이스에 직접 요청해 RLS가 실제로 막는지도 확인하세요.
관점 2. 서비스가 새거나, 무너지거나, 복구할 수 없는 상태인가
두 번째 보안은 아래 세 줄로 기억하면 됩니다.
- 새지 않게 - 비밀 키를 서버에만 두고 오류 응답에서도 내부 정보를 감춥니다.
- 무너지지 않게 - 로그인과 AI 호출에 요청 제한과 과금 상한을 둡니다.
- 잃지 않게 - 운영 데이터를 분리하고 백업, 알림, 복구 방법을 준비합니다.
모니터링에서는 이것만 보세요
- Vercel - 배포 실패, 에러가 많은 경로, 문제가 몰린 시간대
- Supabase - Auth·RLS 실패, 느린 쿼리
문제를 발견하면 아래 순서로 대응합니다.
- 나눈다 - 서로 다른 증상을 하나의 문제로 묶지 않습니다.
- 재현한다 - 사용자가 겪은 것과 같은 상황을 다시 만듭니다.
- 좁힌다 - 지표로 문제가 생긴 구간을 찾고 로그로 개별 요청을 추적합니다.
- 확인한다 - 수정한 뒤 배포된 운영 환경에서 다시 같은 동작을 실행합니다.
어느 입구에서 문제를 발견해도 대응 순서는 나누기, 재현하기, 좁히기, 확인하기로 같습니다.
로그와 알림의 최소 기준
- 로그에는 시간, 동작, 요청 ID, 성공·실패 결과, 오류 코드를 남깁니다.
- API 키, 토큰, 비밀번호 같은 민감 정보는 남기지 않습니다.
- 에러와 비용이 급증하면 운영자가 먼저 알림을 받게 합니다.
마지막 체크리스트
처음부터 모든 항목을 완벽하게 만들 필요는 없습니다.
세 프롬프트를 하나씩 실행하고, 가장 위험한 항목부터 고친 뒤 같은 요청으로 다시 확인해 보세요.