바이브코딩 보안
AI가 짜준 코드는 잘 돌아가는데, 정작 키가 코드에 그대로 노출되거나 데이터가 아무나 읽히는 상태로 배포되는 일이 흔합니다. API 키를 어디에 두어야 하는지, Supabase에 붙일 때 RLS와 서버 접근이 왜 필요한지처럼 만든 앱을 안전하게 지키는 데 필요한 이야기를 모았습니다.
API 키는 Git에 넣으면 안 되는데 Vercel에는 왜 넣어도 될까요?
비밀 API 키를 Git에 넣으면 프로젝트 기록과 함께 복제되지만, Vercel 환경변수에 넣으면 프로젝트 파일과 분리해 암호화하여 보관할 수 있어요. 바이브코딩 입문자도 이해할 수 있게 두 방식의 차이를 설명합니다.
바이브코딩 보안 체크리스트: 만든 서비스를 공개하기 전에 확인할 12가지
AI가 보안 점검을 마쳤다고 말해도 실제 서비스가 안전하다는 뜻은 아니에요. 공개 전에는 비밀 키, 로그인과 권한, XSS·CSRF·SSRF, 파일과 외부 URL, 의존성, 보안 로그를 실제 배포 환경에서 확인해야 합니다.
RLS 뜻: 데이터베이스의 ‘행 단위 보안’을 쉽게 설명하면
RLS는 Row Level Security의 약자로, 같은 데이터베이스 테이블에서도 사용자마다 조회·추가·수정·삭제할 수 있는 행을 다르게 만드는 보안 기능이에요. 로그인은 사용자가 누구인지 확인하고 RLS는 그 사용자가 접근할 데이터를 정합니다.
로그인 기능을 만들려면 무엇이 필요할까요? 회원가입·세션·권한 이해하기
로그인 기능은 버튼 하나가 아니라 계정 생성, 본인 확인, 세션 유지와 서버의 권한 검사가 함께 작동하는 흐름이에요. 소셜 로그인을 붙여도 사용자가 볼 수 있는 데이터와 할 수 있는 일은 서비스가 별도로 제한해야 합니다.
파일과 이미지는 데이터베이스에 저장하면 안 되나요?
이미지·영상·PDF 같은 파일 자체는 보통 파일 스토리지에 두고, 데이터베이스에는 파일 경로·소유자·형식·공개 여부를 저장해요. 공개 파일과 비공개 파일의 읽기·업로드·삭제 권한을 따로 설계하고 두 저장소가 어긋나는 실패도 처리해야 합니다.
바이브코딩으로 만든 웹앱, 공개하기 전에 무엇을 테스트해야 할까요?
웹앱 공개 전에는 성공 화면 한 번이 아니라 사용자의 시작부터 데이터 저장과 운영 확인까지 전체 흐름을 테스트해야 해요. 정상·잘못된 입력·중복 요청·실패·권한·새로고침·모바일을 실제 배포 환경에서 확인하고 출시 뒤 문제를 찾을 로그도 준비하세요.
MCP는 많이 연결할수록 좋을까요? 필요한 도구만 연결해야 하는 이유
MCP 서버는 많이 연결할수록 좋은 것이 아니에요. 도구 선택지가 늘면 컨텍스트와 권한 범위, 실패했을 때 확인할 곳도 커지므로 자주 하는 작업 하나를 끝내는 데 필요한 연결만 프로젝트별로 두는 편이 좋아요.
RLS가 무슨 뜻인가요? Supabase가 설정하라는 규칙
RLS는 로그인한 사용자가 테이블의 어떤 행을 읽고 추가·수정·삭제할 수 있는지 데이터베이스에서 검사하는 규칙이에요. 켜기만 하면 기본적으로 전부 막히므로 각 동작에 필요한 정책을 따로 만들어야 합니다.
Supabase를 연결하는 방법: 서버 접근을 추천하는 이유
결제·예약·관리자 기능처럼 권한과 업무 규칙이 복잡한 앱은 브라우저가 Supabase Data API를 직접 호출하기보다 서버가 요청을 확인하고 DB 작업을 실행하는 구조가 관리하기 쉬워요. 단순 앱은 SDK와 RLS로 빠르게 시작할 수 있지만 두 방식 모두 권한 검사가 필요합니다.
API 키와 .env
API 키는 외부 서비스가 어떤 계정의 요청인지 확인하는 값이고, 비밀 키는 코드나 GitHub에 넣으면 안 돼요. 로컬에서는 .env에, 배포 환경에서는 Vercel 같은 서비스의 환경변수 설정에 따로 저장하며 노출되면 즉시 폐기·재발급해야 해요.
