바이브코딩 보안 체크리스트: 만든 서비스를 공개하기 전에 확인할 12가지

바이브코딩으로 만든 서비스를 공개하려고 하면 이런 걱정이 생깁니다.

“기능은 작동하는데, 보안 문제는 괜찮을까요?”

AI에게 “보안도 확인해줘”라고 요청하면 환경변수와 몇 개의 설정을 살핀 뒤 안전하다고 답할 수 있습니다. 하지만 AI의 완료 보고는 코드를 검토했다는 뜻이지, 실제 서비스의 모든 권한과 운영 환경을 검증했다는 뜻은 아니에요.

바이브코딩으로 만든 서비스만 특별히 위험한 것은 아닙니다. 사람이 직접 작성한 코드에도 보안 문제는 생깁니다. 차이는 만드는 속도가 빨라진 만큼 로그인, 데이터 저장과 외부 서비스가 어떻게 연결됐는지 확인하지 않고 공개하기도 쉬워졌다는 데 있어요.

2025년 OWASP Top 10 (새 탭에서 열림)도 웹 애플리케이션의 주요 위험으로 잘못된 접근 권한, 보안 설정 오류, 소프트웨어 공급망 문제, 인증 실패와 보안 로그 누락 등을 다룹니다. 이 글에서는 이 항목을 바이브코딩 입문자가 실제로 확인할 수 있는 순서로 바꿔 살펴보겠습니다.

체크리스트의 범위부터 정해요

보안 점검은 “이제 절대 문제가 생기지 않는다”는 도장을 받는 일이 아닙니다. 어떤 데이터와 기능이 노출될 수 있는지 찾고, 문제가 생길 가능성과 피해를 줄이는 일에 가깝습니다.

이 글은 일반적인 웹 애플리케이션을 공개하기 전 확인할 최소 기준입니다. 건강 정보, 금융 정보, 대규모 개인정보처럼 피해가 큰 데이터를 다루거나 회사의 보안·법무 기준을 적용해야 한다면 별도의 전문가 검토와 조직의 절차가 필요할 수 있어요.

점검을 시작할 때는 먼저 서비스의 입구를 적어보세요.

로그인 없이 보는 공개 페이지
로그인한 사용자의 페이지
관리자 페이지
API와 Server Action
외부 서비스가 호출하는 웹훅
데이터베이스와 파일 저장소
결제·이메일·AI 같은 외부 서비스

이 목록이 있어야 홈페이지 화면만 확인하고 실제 데이터가 오가는 서버 요청을 놓치지 않습니다.

1. 꼭 필요한 데이터만 받고 있는지 확인해요

보유하지 않은 데이터는 유출될 수도 없습니다. 먼저 서비스가 받는 모든 입력 항목과 저장 위치를 표로 뽑아보세요.

데이터 | 받는 이유 | 저장 위치 | 볼 수 있는 사람 | 지우는 시점

문의에 답하는 데 이메일만 필요하다면 생년월일과 상세 주소까지 미리 받을 이유는 없습니다. 관리자 메모에도 업무에 필요하지 않은 민감한 내용을 자유롭게 적게 두지 않는 편이 좋아요.

다음 질문을 확인하세요.

• 이 정보가 없으면 핵심 기능을 제공할 수 없나요?
• 화면에만 잠깐 필요하고 데이터베이스에는 저장하지 않아도 되나요?
• 일반 사용자, 관리자와 외부 서비스 중 누가 볼 수 있나요?
• 테스트 데이터에 실제 고객 정보를 복사하고 있지 않나요?
• 탈퇴나 보관 기간이 끝났을 때 지우는 방법이 있나요?

개인정보처리방침을 만들어두는 것과 실제 코드가 필요한 데이터만 받는 것은 다른 일입니다. 화면의 안내와 실제 저장 내용이 같은지 확인해야 해요.

2. 비밀 키가 코드와 브라우저에 나오지 않는지 확인해요

데이터베이스 연결 문자열, 결제 비밀 키, 이메일 발송 키와 관리자용 토큰은 서버만 알아야 하는 비밀값입니다.

다음 위치를 검색하세요.

• Git이 기록하는 소스 코드와 설정 파일
• GitHub의 과거 commit
• 브라우저로 전달되는 JavaScript와 네트워크 응답
• 배포 로그와 오류 메시지
• 화면 캡처, 문서와 AI 대화에 붙여넣은 내용
• 테스트 코드와 예제 데이터

로컬에서는 Git에서 제외한 .env에, 배포 환경에서는 Vercel 같은 서비스의 환경변수 설정에 값을 둡니다. Vercel은 운영·미리보기 환경의 값을 읽을 수 없게 저장하는 Sensitive Environment Variables (새 탭에서 열림)도 제공합니다.

GitHub의 push protection (새 탭에서 열림)은 지원하는 비밀값이 저장소에 올라가기 전에 push를 막는 데 도움을 줍니다. 하지만 자동 탐지가 모든 키를 찾아주는 것은 아니므로 직접 확인도 필요해요.

키가 한 번 노출됐다면 파일에서 문자를 지우는 것으로 끝나지 않습니다. Git 기록이나 로그, 다른 사람이 복사한 곳에 남아 있을 수 있으므로 해당 서비스에서 기존 키를 폐기하고 새 키를 발급해야 합니다.

API 키와 환경변수를 다루는 방법에서 공개용 키와 서버 비밀 키를 구분하는 기준을 더 자세히 확인할 수 있어요.

3. 로그인과 세션의 전체 흐름을 확인해요

로그인 버튼을 눌러 내 이름이 보인다고 인증 기능이 완성된 것은 아닙니다.

다음 흐름을 실제로 시험하세요.

• 가입하지 않은 이메일과 잘못된 비밀번호로 로그인합니다.
• 이메일 인증이나 비밀번호 재설정 링크가 만료된 뒤 다시 엽니다.
• 로그아웃한 뒤 이전에 보던 보호 페이지 주소를 직접 엽니다.
• 세션이 만료됐을 때 다시 로그인하게 되는지 확인합니다.
• 정지하거나 탈퇴한 계정의 기존 세션이 계속 작동하지 않는지 봅니다.
• 소셜 로그인과 이메일 로그인으로 같은 사람이 중복 가입하지 않는지 확인합니다.
• 세션 쿠키에 HttpOnly, Secure와 서비스에 맞는 SameSite 설정이 적용됐는지 확인합니다.

비밀번호 저장과 세션 처리를 처음부터 직접 만들기보다 검증된 인증 서비스와 라이브러리를 사용하는 편이 안전합니다. 인증은 사용자가 누구인지 확인하는 일이고, 그 사람이 어떤 데이터를 볼 수 있는지 정하는 권한은 다음 단계에서 별도로 검사해야 해요.

세션 쿠키는 브라우저 JavaScript에서 읽을 필요가 없다면 HttpOnly로 두고, 실제 서비스에서는 HTTPS에서만 전송되도록 Secure를 사용합니다. SameSite는 외부 사이트에서 시작한 요청에 쿠키를 보낼 범위를 정합니다. 구체적인 값은 로그인 방식과 외부 결제·인증 흐름에 따라 달라질 수 있으므로 인증 라이브러리의 기본값과 OWASP 세션 관리 가이드 (새 탭에서 열림)를 함께 확인하세요.

회원가입·세션·권한의 차이를 먼저 이해하면 로그인 화면 밖에서 무엇을 확인해야 하는지 찾기 쉽습니다.

4. 중요한 권한은 서버에서 검사해요

관리자 메뉴를 숨기거나 다른 사용자의 수정 버튼을 화면에서 없애는 것은 사용성을 위한 처리입니다. 보안 경계는 서버에 있어야 해요.

최소한 다음 네 상태를 준비하세요.

로그아웃 상태
일반 사용자 A
일반 사용자 B
관리자

그리고 테스트 데이터로 다음을 확인합니다.

• 사용자 A가 사용자 B의 상세 주소를 직접 열 수 있나요?
• 요청의 주문 ID나 게시물 ID를 B의 값으로 바꾸면 조회되나요?
• 일반 사용자가 관리자 API나 Server Action을 직접 호출할 수 있나요?
• 조회만 가능한 사용자가 수정·삭제 요청도 보낼 수 있나요?
• 삭제되거나 만료된 계정이 예전 링크와 토큰을 사용할 수 있나요?

OWASP는 잘못된 접근 권한을 2025년에도 가장 중요한 웹 애플리케이션 위험으로 분류 (새 탭에서 열림)하고, 기본적으로 거부한 뒤 모든 요청에서 권한을 확인하라고 권합니다. Next.js 인증 가이드 (새 탭에서 열림)도 화면 요소를 숨기는 것만으로는 부족하며 Server Action을 포함한 서버 작업이 자체적으로 권한을 검사해야 한다고 설명합니다.

테스트할 때는 실제 고객의 ID를 추측하거나 데이터를 변경하지 마세요. 내가 만든 테스트 계정과 테스트 데이터만 사용하고, 조회·수정·삭제 각각이 올바르게 거부되는지 확인합니다.

5. 데이터베이스와 파일 저장소의 접근 경로를 구분해요

Supabase를 사용한다고 모든 프로젝트의 보안 설정이 같은 것은 아닙니다. 브라우저가 Data API로 직접 접근하는 구조와 서버가 PostgreSQL에 직접 연결하는 구조는 권한을 검사하는 위치가 달라요.

브라우저 → Supabase Data API → 데이터베이스
권한 검사: RLS 정책

브라우저 → 내 서버 → 데이터베이스
권한 검사: 서버 코드와 데이터 접근 계층

브라우저에서 Supabase Data API로 노출된 테이블에 접근한다면 Supabase 공식 문서 (새 탭에서 열림)의 안내처럼 RLS를 켜고 필요한 작업별 정책을 만들어야 합니다. SELECT가 안전하다고 UPDATE와 DELETE도 자동으로 안전해지는 것은 아니므로 각각 시험하세요.

RLS를 우회할 수 있는 service_role 키나 서버용 비밀 키는 브라우저 코드에 넣으면 안 됩니다. 공개용 키와 이름이 비슷해도 권한 범위가 다르므로 AI가 어떤 키를 어디에서 사용하는지 함께 보고하게 하세요.

서버가 데이터베이스에 직접 연결한다면 RLS만 켜고 안심할 수 없습니다. 서버 요청마다 현재 사용자와 데이터 소유자, 역할을 확인해야 해요. 두 방식의 차이는 Supabase 서버 접근을 추천하는 이유와 Supabase RLS를 설정하는 방법에서 각각 살펴볼 수 있습니다.

파일 저장소도 같은 기준으로 확인하세요.

• 프로필 이미지처럼 공개해도 되는 파일인가요?
• 계약서나 제출 문서처럼 본인과 관리자만 봐야 하나요?
• 파일 주소를 알면 로그인 없이 열리지 않나요?
• 비공개 파일의 임시 다운로드 주소가 지나치게 오래 유지되지 않나요?
• 삭제한 사용자의 파일도 함께 처리되나요?

데이터베이스 행의 권한과 파일 주소의 권한은 별개일 수 있습니다.

6. 서버가 입력값과 실행 경로를 제한해요

화면에서 필수 입력을 표시하고 글자 수를 제한해도 요청값은 직접 바꿔 보낼 수 있습니다. 서버는 브라우저의 검사를 믿지 말고 형식과 범위를 다시 확인해야 해요.

• 문자열, 숫자, 날짜와 이메일의 형식이 맞나요?
• 글자 수와 숫자의 최소·최대 범위가 있나요?
• 역할, 상태와 결제 금액처럼 서버가 정해야 할 값을 사용자가 보내는 대로 믿지 않나요?
• 목록에서 고르는 값은 허용된 목록 안에 있는지 확인하나요?
• 데이터베이스 쿼리를 문자열로 이어 붙이지 않고 ORM이나 매개변수화된 쿼리를 사용하나요?
• 사용자 입력을 셸 명령, 파일 경로와 템플릿 코드에 그대로 넣지 않나요?

입력값이 데이터베이스 쿼리, 운영체제 명령과 파일 경로에 그대로 들어가면 SQL 주입, 명령어 주입과 경로 탐색 같은 문제가 생길 수 있습니다. OWASP 입력값 검증 가이드 (새 탭에서 열림)는 가능한 입력의 형식과 범위를 서버에서 확인하는 허용 목록 방식과 길이 제한을 권합니다.

7. 사용자 입력을 화면에 안전하게 표시해요

게시글, 댓글, 관리자 메모와 Markdown처럼 사용자가 입력한 내용을 다시 화면에 보여줄 때는 XSS를 확인해야 합니다. 악성 스크립트가 실행되면 다른 사용자의 화면에서 계정 작업을 수행하거나 민감한 내용을 읽을 수 있어요.

React는 일반적인 문자열을 화면에 표시할 때 기본적으로 이스케이프합니다. 하지만 다음 기능은 별도로 확인해야 합니다.

• dangerouslySetInnerHTML을 사용하나요?
• Markdown이나 HTML 편집기의 결과를 그대로 렌더링하나요?
• 사용자가 입력한 주소를 href, src와 리디렉션에 넣나요?
• 외부 스크립트와 위젯을 필요한 출처에서만 불러오나요?
• HTML을 허용해야 한다면 검증된 라이브러리로 위험한 태그와 속성을 제거하나요?

OWASP XSS 방지 가이드 (새 탭에서 열림)는 React 같은 프레임워크도 dangerouslySetInnerHTML과 안전하지 않은 URL처럼 기본 보호를 벗어나는 지점을 따로 확인해야 한다고 설명합니다.

Content Security Policy(CSP)는 실행할 스크립트와 불러올 외부 출처를 제한해 피해를 줄일 수 있습니다. 다만 CSP 하나로 XSS가 사라지는 것은 아니므로 안전한 렌더링을 먼저 적용하고 추가 방어선으로 사용하세요.

8. 쿠키를 사용하는 변경 요청은 CSRF를 확인해요

브라우저는 요청을 보낼 때 로그인 쿠키를 자동으로 포함할 수 있습니다. 공격자가 다른 사이트에서 만든 요청이 내 서비스의 수정·삭제·결제 작업으로 처리되면 CSRF 문제가 됩니다.

다음 항목을 확인하세요.

• 조회용 GET 요청이 데이터 생성·수정·삭제를 하지 않나요?
• 쿠키로 인증하는 POST, PUT, PATCH, DELETE 요청에 CSRF 방어가 있나요?
• 인증 라이브러리나 프레임워크가 제공하는 CSRF 토큰을 임의로 제거하지 않았나요?
• 중요한 요청에서 Origin 또는 Referer를 확인하나요?
• CORS에서 자격 증명을 허용하는 출처를 구체적으로 제한했나요?

SameSite 쿠키는 도움이 되지만 모든 구조에서 CSRF 방어를 대신하지는 않습니다. OWASP CSRF 방지 가이드 (새 탭에서 열림)를 기준으로 현재 인증 방식에 맞는 토큰이나 요청 출처 검사를 적용하세요.

9. 업로드 파일과 외부 URL을 제한해요

이미지, 이력서와 문서 업로드는 사용자가 만든 파일을 서버와 저장소에 들여오는 입구입니다.

• 필요한 확장자만 허용하나요?
• 브라우저가 보내는 파일 형식 표시만 믿지 않고 실제 형식도 확인하나요?
• 한 파일과 사용자별 전체 용량에 제한이 있나요?
• 원래 파일명을 그대로 저장 경로로 사용하지 않나요?
• 업로드와 다운로드 권한을 각각 검사하나요?
• 비공개 파일이 공개 저장소나 추측 가능한 주소에 놓이지 않나요?

OWASP 파일 업로드 가이드 (새 탭에서 열림)는 필요한 확장자만 허용하고 파일 형식과 크기를 확인하며, 애플리케이션이 새 파일명을 만들고 허가된 사용자만 업로드하게 하라고 안내합니다.

사용자가 입력한 URL을 서버가 대신 열어 미리보기, 이미지 가져오기나 문서 분석을 제공한다면 SSRF도 확인해야 합니다. 서버가 localhost, 사설 네트워크와 클라우드 내부 주소에 접근하지 못하게 하고, 가능한 경우 허용한 도메인과 프로토콜만 요청하세요. 리디렉션을 따라간 뒤의 최종 주소도 같은 기준으로 검사해야 합니다.

OWASP SSRF 방지 가이드 (새 탭에서 열림)는 목적지가 정해져 있다면 허용 목록을 사용하고, 외부 주소를 받아야 한다면 프로토콜·도메인·IP와 리디렉션을 함께 제한하라고 안내합니다.

10. 반복 요청과 웹훅의 출처를 확인해요

로그인, 비밀번호 재설정과 인증 코드 발송을 누구나 무한히 실행할 수 있으면 계정 공격과 메시지 폭탄에 악용될 수 있습니다. AI 답변, 이메일 발송과 파일 처리처럼 비용이 드는 기능도 같은 문제가 생겨요.

• 사용자·계정·IP를 기준으로 반복 요청을 제한하나요?
• 로그인 실패와 인증 코드 발송이 비정상적으로 반복되면 알림이 남나요?
• 계정 잠금 정책이 정상 사용자를 쉽게 차단하지 않도록 설계됐나요?
• AI와 이메일 같은 외부 서비스에 계정별 사용량 한도가 있나요?

결제와 이메일 서비스가 보내는 웹훅도 요청 주소만 보고 믿으면 안 됩니다. 제공자가 지원하는 서명을 검증하거나 서버 API에서 이벤트와 금액·상태를 다시 조회하세요. 검증에 실패한 요청은 주문과 계정 상태를 바꾸지 않아야 합니다.

11. 의존성과 운영 설정을 점검해요

AI는 기능을 만들면서 여러 라이브러리와 외부 스크립트를 설치할 수 있습니다. 설치한 구성요소와 운영 설정도 공격 표면에 포함됩니다.

• 사용하지 않는 패키지와 예제 코드를 제거했나요?
• 알려진 취약점 알림과 수정 버전을 확인했나요?
• GitHub Actions와 배포 플러그인도 점검했나요?
• 개발용 디버그 페이지와 테스트 계정이 운영에 남아 있지 않나요?
• 관리자와 미리보기 주소가 인증 없이 열리지 않나요?
• CORS가 필요한 출처와 메서드만 허용하나요?
• CSP, frame-ancestors, X-Content-Type-Options 같은 보안 응답 헤더를 실제 기능에 맞게 설정했나요?

GitHub Dependabot security updates (새 탭에서 열림)는 알려진 취약점에 수정 버전이 있으면 업데이트 pull request를 만들 수 있습니다. 보안 업데이트는 실제 사용 여부와 영향 범위를 확인한 뒤 빌드와 핵심 기능을 다시 테스트하세요.

OWASP 보안 응답 헤더 가이드 (새 탭에서 열림)를 참고하되 설정을 그대로 복사하지는 마세요. 로그인, 이미지와 외부 스크립트가 사용하는 출처를 먼저 파악하고 실제 배포 주소에서 동작을 확인해야 합니다.

12. 오류 노출과 보안 로그를 확인해요

사용자 화면에 데이터베이스 쿼리, 내부 파일 경로와 전체 오류 스택을 그대로 보여주면 서비스 구조를 불필요하게 노출합니다. 화면에는 사용자가 다음 행동을 정할 안내를 보여주고, 원인을 찾을 정보는 접근이 제한된 운영 로그에 남기세요.

로그에는 다음 사건이 필요합니다.

• 반복된 로그인 실패
• 권한이 없는 조회·수정·삭제 시도
• 관리자 권한과 계정 상태 변경
• 결제·환불 같은 중요한 상태 변화
• 입력값 검증 실패와 비정상적으로 많은 요청
• 웹훅 검증과 파일 업로드 실패

비밀번호, 세션 토큰, API 키, 데이터베이스 연결 문자열과 결제 카드 정보는 로그에 그대로 남기면 안 됩니다. OWASP 로깅 가이드 (새 탭에서 열림)도 인증·권한 실패와 중요한 관리 작업을 기록하되, 접근 토큰과 주요 비밀값·민감한 개인정보는 제거하거나 가리도록 안내합니다.

기록이 있어도 아무도 보지 않으면 문제를 늦게 발견합니다. 중요한 실패가 반복되면 운영자가 알림을 받을 수 있는지도 확인하세요. 로그가 무엇이고 왜 필요한지에서 배포 로그와 사용자 행동 기록의 차이를 살펴볼 수 있습니다.

AI 기능을 연결했다면 도구 권한을 확인해요

사용자의 질문, 업로드 문서와 웹 검색 결과에는 AI의 지시를 바꾸려는 문장이 들어 있을 수 있습니다. 프롬프트에 “이 지시를 무시해”라는 문구를 막는 것만으로는 충분하지 않아요. AI가 어떤 결정을 하더라도 서버가 허용된 작업만 실행하게 해야 합니다.

• AI가 호출할 수 있는 도구를 기능에 필요한 범위로 제한했나요?
• 도구를 실행할 때 현재 사용자의 로그인과 권한을 서버가 다시 확인하나요?
• 파일 경로, 데이터 ID와 외부 URL 같은 도구 입력값을 검증하나요?
• 읽기 기능에는 읽기 전용 계정과 권한을 사용하나요?
• 삭제·결제·발송처럼 되돌리기 어려운 작업은 사용자 확인을 받나요?
• 시스템 프롬프트, 비밀 키와 다른 사용자의 데이터가 모델 입력과 출력에 섞이지 않나요?

OWASP 프롬프트 인젝션 방지 가이드 (새 탭에서 열림)는 AI 에이전트가 도구를 호출할 때 사용자 권한과 세션을 다시 확인하고, 도구별 입력값 검증과 최소 권한을 적용하라고 권합니다.

실제 배포 환경에서 다시 확인해요

로컬 코드가 안전해 보여도 운영 환경의 키, 쿠키, CORS와 데이터베이스 정책이 다를 수 있습니다. 실제 주소에 출시 후보 버전을 배포한 뒤 테스트 계정으로 로그인·권한·XSS·CSRF·파일·웹훅 흐름을 다시 확인하세요.

AI가 Vercel·Supabase 같은 외부 대시보드에 접근하지 못했다면 해당 설정을 추측으로 통과 처리하지 않습니다. 확인할 수 없는 항목을 따로 남기고 운영자가 직접 확인해야 해요. 위험한 명령과 운영 환경 접근을 반복해서 막아야 한다면 클로드코드 훅의 PreToolUse 설정도 함께 살펴보세요.

로컬 작업의 반복 승인을 줄이는 것과 안전 경계를 없애는 것은 다릅니다. 클로드코드 Auto mode와 코덱스의 Approve for me가 어떤 검토를 대신하고, 어떤 작업은 사람이 직접 확인해야 하는지는 두 자동 승인 방식의 차이에서 확인할 수 있습니다.

백업, 되돌리기, 중복 클릭과 모바일 같은 운영·품질 항목은 웹앱 공개 전 테스트 체크리스트에서 이어서 점검할 수 있습니다.

클로드코드에서 /security-review를 실행해요

클로드코드를 사용하는 프로젝트라면 기능을 만든 뒤 다음 명령을 실행할 수 있습니다.

/security-review

Claude Code 명령어 공식 문서 (새 탭에서 열림)는 /security-review를 현재 브랜치의 변경분에서 보안 취약점을 찾는 읽기 전용 점검으로 설명합니다. Git diff를 살펴보며 주입, 인증·권한과 데이터 노출처럼 실제 피해로 이어질 수 있는 위험을 찾습니다. 실행 방법은 처음에 익힐 클로드코드 슬래시 명령어에서도 확인할 수 있어요.

로그인, 관리자 기능, 결제, 파일 업로드처럼 중요한 기능을 수정한 뒤 실행하면 사람이 놓친 변경을 한 번 더 확인하기 좋습니다. 발견한 항목에는 파일과 위치, 위험한 흐름과 수정 방향이 함께 나오는지 확인하고, 수정한 뒤 같은 명령을 다시 실행하세요.

다만 /security-review는 현재 브랜치의 변경분을 중심으로 봅니다. 이번에 수정하지 않은 기존 코드, Vercel·Supabase 대시보드의 실제 설정, 운영 데이터와 배포 주소의 동작까지 모두 확인해주는 명령은 아닙니다. 아래의 전체 점검 요청과 실제 배포 테스트를 함께 사용해야 합니다.

AI에게 읽기 전용 보안 점검을 요청하는 방법

처음부터 “취약점을 전부 고쳐줘”라고 하면 원래 상태와 수정 결과를 구분하기 어렵습니다. 먼저 코드와 배포 환경을 읽기 전용으로 확인하고 확인한 내용을 보고하게 하세요.

이 웹 애플리케이션을 공개하기 전에 보안 기준으로 감사해줘.
아직 코드를 수정하지 말고 읽기 전용으로 확인해.

실제 배포 주소: [https://내도메인.com]

먼저 아래 항목을 목록으로 정리해줘.
- 공개 페이지와 로그인 후 페이지
- 관리자 페이지
- API Route와 Server Action
- 외부 웹훅
- 데이터베이스와 파일 저장소 접근 경로
- 사용하는 인증·결제·이메일·AI 서비스
- 코드에서 사용하는 환경변수 이름

그다음 아래 12개 항목을 확인해줘.
1. 수집·저장하는 개인정보와 불필요한 데이터
2. 코드·Git·브라우저·로그의 비밀 키 노출
3. 가입·로그인·로그아웃·만료·재설정의 세션 흐름과 쿠키 설정
4. 사용자별·관리자별 서버 권한 검사
5. 데이터베이스와 파일 저장소의 접근 정책
6. 서버 입력값 검증과 SQL·명령어·경로 삽입 방지
7. HTML·마크다운·URL의 XSS 방지와 CSP
8. 쿠키 인증을 쓰는 상태 변경 요청의 CSRF 방어
9. 파일 업로드 제한과 서버가 가져오는 외부 URL의 SSRF 방어
10. 반복 요청 제한과 웹훅 서명·원본 데이터 재검증
11. 취약한 의존성, 개발용 설정, CORS와 보안 헤더
12. 오류 응답, 보안 로그, 비밀값과 개인정보 마스킹

AI가 파일·데이터베이스·외부 서비스 도구를 호출한다면 사용자 권한 전달, 도구 인자 검증, 최소 권한, 파괴적 작업 재확인과 프롬프트 인젝션 방어도 추가로 확인해줘.

결과는 아래 열을 가진 표로 작성해줘.
항목 | 상태 | 확인한 파일·설정·URL | 확인 내용 | 영향 | 권장 수정

상태는 통과 / 주의 / 실패 / 확인 불가 중 하나로 표시해.
코드에서 확인한 사실과 외부 대시보드에서 직접 확인해야 할 일을 구분해.
확인하지 못한 항목을 추측으로 통과 처리하지 마.
실제 고객 데이터를 조회·수정·삭제하지 마.
파괴적이거나 서비스에 부하를 주는 테스트를 실행하지 마.

감사 결과를 검토한 뒤 수정 범위를 나누어 요청합니다.

감사 결과에서 실패 항목부터 수정 계획을 만들어줘.
아직 수정하지 말고 작업별 영향과 검증 방법을 적어줘.

우선순위는 다음 순서로 정해.
1. 비밀 키와 개인정보 노출
2. 로그인·세션과 권한 우회
3. SQL 삽입·명령어 삽입·XSS·CSRF·SSRF
4. 웹훅·파일 업로드·AI 도구의 중요한 작업
5. 의존성·운영 설정·보안 로그

각 수정 뒤 어떤 테스트 계정과 방법으로 통과를 확인할지도 포함해.

보안은 변경 범위가 크므로 보고서를 검토하고 한 묶음씩 수정하는 편이 안전합니다. 수정 뒤에는 기존 핵심 기능이 계속 작동하는지도 다시 확인하세요.

공개 전 최소 보안 체크리스트

• 서비스가 받는 데이터, 저장 위치와 접근자를 적었습니다.
• 핵심 기능에 필요하지 않은 개인정보를 받지 않습니다.
• 비밀 키가 코드·Git 기록·브라우저·로그에 없습니다.
• 노출된 키는 폐기하고 새로 발급했습니다.
• 가입·로그인·로그아웃·만료·재설정을 확인했습니다.
• 세션 쿠키에 HttpOnly·Secure·SameSite를 용도에 맞게 설정했습니다.
• 로그아웃·사용자 A·사용자 B·관리자 계정으로 권한을 시험했습니다.
• 화면뿐 아니라 API와 Server Action이 권한을 거부합니다.
• 데이터베이스와 파일 저장소의 접근 구조에 맞는 정책이 있습니다.
• 서버가 입력의 형식·길이·범위와 허용값을 다시 확인합니다.
• 데이터베이스 쿼리는 매개변수를 사용하고 입력값을 명령어나 파일 경로에 그대로 넣지 않습니다.
• HTML·마크다운·외부 URL을 안전하게 렌더링하고 위험한 스크립트 실행 경로를 막았습니다.
• 쿠키 인증을 쓰는 상태 변경 요청에 CSRF 방어가 있습니다.
• 파일 형식·크기·이름과 업로드·다운로드 권한을 제한합니다.
• 서버가 외부 URL을 가져갈 때 허용 대상과 프로토콜을 제한하고 내부망 접근을 막습니다.
• 로그인·인증 코드·메일·결제 요청에 사용량 제한이 있습니다.
• 웹훅은 서명을 확인하고 중요한 값은 공급자 서버에서 다시 조회합니다.
• 사용하지 않는 패키지를 제거하고 보안 알림을 확인했습니다.
• 운영 환경에 디버그 페이지·테스트 계정이 없고 CORS와 보안 헤더를 확인했습니다.
• 오류 화면에 내부 구조와 비밀값을 보여주지 않습니다.
• 중요한 인증·권한·관리자·결제 실패가 로그와 알림에 남습니다.
• 로그에 비밀번호·토큰·API 키·연결 문자열을 기록하지 않습니다.
• AI가 도구를 호출한다면 사용자 권한·인자 검증·최소 권한·파괴적 작업 재확인을 적용했습니다.
• 실제 배포 주소에서 확인하고 외부 대시보드처럼 보지 못한 항목은 확인 불가로 표시했습니다.

정리

바이브코딩 보안은 코드를 한 줄씩 외워서 검사하는 일이 아닙니다.

• 어떤 데이터와 기능이 외부에 열려 있는지 먼저 목록으로 만듭니다.
• 비밀 키는 코드와 브라우저에서 분리하고, 노출되면 폐기합니다.
• 로그인과 권한을 구분하고 서버가 모든 중요한 요청을 검사하게 합니다.
• 데이터베이스와 파일 저장소는 실제 접근 구조에 맞는 정책을 둡니다.
• 입력값을 검증하고 SQL 삽입·명령어 삽입·XSS·CSRF를 막습니다.
• 파일 업로드와 서버의 외부 URL 요청에는 별도 제한을 두어 SSRF를 막습니다.
• 웹훅은 발신자를 검증하고 중요한 데이터는 공급자 서버에서 다시 확인합니다.
• 의존성, CORS, 보안 헤더, 오류 응답과 보안 로그도 점검합니다.
• AI가 도구를 호출한다면 프롬프트 인젝션과 과도한 권한을 함께 확인합니다.
• 실제 배포 주소에서 테스트하고 확인하지 못한 것은 그대로 표시합니다.

AI에게 보안 점검을 맡길 수는 있습니다. 다만 “안전합니다”라는 결론만 받지 말고, 무엇을 어디에서 확인했고 어떤 계정과 요청으로 검증했는지 구체적으로 설명하게 해야 합니다.

무료 바이브코딩 가이드 12장의 보안 점검 실습에서도 프로젝트를 공개하기 전 비밀 키와 권한을 확인하는 흐름을 따라 할 수 있어요.