바이브코딩 앱, 배포 전 보안 점검 3가지

바이브코딩으로 만든 앱을 배포하기 전에 이 3가지만 확인해도 큰 사고는 대부분 막을 수 있어요. 숏츠에서 짧게 말한 내용을, 내 앱에서 직접 확인하는 방법과 고치는 방법까지 풀어 적었어요.

먼저: 클라이언트 코드는 전부 공개된 거예요

웹이나 앱 같은 프론트엔드 코드는 누구나 볼 수 있어요. 새로운 얘기는 아니에요.

원래도 클라이언트 코드는 오픈소스라고 생각해야 된다라고 했거든요.

달라진 건 이제 누구나 뜯어볼 수 있다는 점이에요. Claude Code 같은 에이전트에 리버스 엔지니어링 도구를 붙이면, 개발을 몰라도 남의 앱 내부를 들여다볼 수 있어요. 지켜야 할 보안 지침이 새로 생긴 게 아니라, 원래 있던 지침을 뚫을 수 있는 사람이 많아진 거예요.

그래서 원칙은 하나예요. 클라이언트는 최대한 멍청하게 만든다. 어차피 털리는 곳이니 중요한 건 하나도 두지 않고, 화면을 그리는 용도로만 써요. 아래 3가지가 전부 이 원칙에서 나와요.

1. 시크릿 키 조심하기

과외를 하면서 수강생분들이 만든 서비스를 보면, 시크릿 키가 노출된 경우가 정말 많아요. 모바일 앱을 만드시는 분들은 더 그래요. 앱 안에 넣은 키는 앱 파일을 풀면 그대로 나오거든요.

시크릿 키는 그 값만 있으면 내 이름으로 외부 서비스를 쓸 수 있는 값이에요. OpenAI API 키, 결제사 비밀 키, DB 비밀번호, Supabase service_role 키 같은 것들이요. 누가 가져가면 요금은 내가 내고, 데이터는 남이 가져가요.

확인하는 법

• 배포된 사이트에서 개발자 도구(F12) → Sources 탭에서 sk-, secret, service_role을 검색해 보세요
• 코드에서 NEXT_PUBLIC_, VITE_, EXPO_PUBLIC_로 시작하는 환경변수를 확인하세요. 이 접두어가 붙으면 브라우저나 앱에 그대로 실려요
• GitHub에 .env 파일을 올린 적이 있는지 확인하세요

고치는 법

• 키가 필요한 호출은 서버(Next.js라면 API Route)로 옮기고, 앱은 내 서버만 부르게 해요
• 키는 서버 환경변수에만 둬요

// ❌ 앱 코드 안에서 OpenAI를 직접 부른다 — 키가 사용자 기기에 내려간다
const res = await fetch("https://api.openai.com/v1/chat/completions", {
  headers: { Authorization: "Bearer sk-proj-..." },
  // ...
});

// ✅ 앱은 내 서버(/api/chat)만 부르고, 키는 서버 환경변수에서 읽는다
// app/api/chat/route.ts — 서버에서만 실행된다
const res = await fetch("https://api.openai.com/v1/chat/completions", {
  headers: { Authorization: `Bearer ${process.env.OPENAI_API_KEY}` },
  // ...
});

2. 입력은 서버에서 검증하기

배송비가 5만 원 이상 구매하면 배송비 무료 이런 로직 있잖아요. 이거 클라이언트에 넣는 분들 진짜 많거든요.

그러면 안 돼요. 서버에서 계산해서 내려줘야 해요. 클라이언트가 보낸 금액을 서버가 그대로 믿으면, 요청을 고쳐서 원하는 금액으로 결제하는 것도 가능해져요.

서버에서 다시 해야 하는 건 세 가지예요.

• 가격·할인·배송비·쿠폰 — 클라이언트는 상품 ID와 수량만 보내고, 금액은 서버가 DB에서 다시 읽어 계산해요
• 본인 확인 — 회원정보 API에 권한 검사가 빠진 경우가 꽤 있어요. /api/users/123의 숫자만 바꿨는데 남의 정보가 나온다면 구멍이에요
• 관리자 화면 — 권한에 따라 화면을 다르게 보여줄 때, 권한은 서버에서 판정하고 맞는 화면만 내려줘야 해요. 클라이언트에서 숨기기만 하면 관리자 화면 코드가 이미 내려와 있어서, 뜯어보는 순간 드러나요

Supabase를 쓴다면 한 번 더 보세요. 브라우저에서 공개 키로 DB를 바로 부르는 구조인데 RLS(테이블 행 단위 접근 권한)가 꺼져 있으면, 누구나 그 테이블을 읽고 쓸 수 있어요. 저는 RLS를 켜고 정책을 따로 만들지 않아 외부에서 직접 접근하는 길을 막은 다음, 데이터는 서버에서만 다뤄요.

민감한 정보는 암호화해서 저장해요. 주민번호는 말할 것도 없고, 고객의 업무상 비밀 같은 내용도 평문으로 두지 않는 편이 좋아요. AI한테 "단방향 또는 양방향 암호화를 적절히 적용해 달라"고 하면 잘해 줘요. 단방향은 비밀번호처럼 맞는지만 확인하면 되는 값, 양방향은 나중에 다시 꺼내 써야 하는 값에 써요.

3. 배포 전에 레드팀 공격하기

레드팀은 일부러 공격자 역할을 맡아 내 서비스를 털어 보는 거예요. 학생분들한테 예전부터 많이 시키던 건데요.

일단 앱이나 뭘 만들었으면 한번 보안적으로 두들겨 볼 필요가 있어요.

인프라나 데이터베이스 쪽에서 뭔가 빠뜨리는 경우가 생각보다 많거든요. AI에게 레드팀을 시켜 보면 진짜 잘해요. 개발을 잘 모르는 상태에서 얼기설기 만들었다면 문제가 나올 확률이 높아요.

프롬프트, 언제 어디에 붙여넣나요

• 언제 — 기능을 다 만들고 배포 버튼을 누르기 직전에 한 번 돌려요. 앱이면 스토어 심사를 내기 직전이에요. 그 뒤로도 결제·로그인·회원 정보 기능을 새로 붙였다면 배포 전에 다시 돌려요
• 어디에 — 그 앱을 만든 프로젝트 폴더를 연 Claude Code나 Cursor 채팅창이에요. AI가 내 코드를 직접 읽어야 해서, 코드를 볼 수 없는 ChatGPT 웹 채팅창에 붙이면 제대로 못 찾아요
• 순서 — ①은 누구나 먼저 → 내 앱에 해당하면 ②·③ → 문제 목록이 나오면 같은 채팅창에 ④

① 배포 직전, 누구나 먼저

너는 보안 레드팀이야. 이 프로젝트를 해커 입장에서 분석해서 ① 코드나 앱에 노출된 시크릿 키 ② 클라이언트에서만 하는 가격·할인·권한 처리 ③ 권한 검사가 빠진 API를 찾아줘. 각 문제마다 위치, 공격 방법, 고치는 방법을 알려줘.

② 모바일 앱이라면 — ① 다음에

너는 보안 레드팀이야. 이 모바일 앱 프로젝트를 해커 입장에서 분석해줘. 앱을 빌드했을 때 앱 파일 안에 그대로 들어가는 것을 기준으로 ① 앱 코드나 설정 파일에 들어간 API 키·시크릿 ② 앱이 서버를 거치지 않고 직접 부르는 외부 서비스(결제·AI·DB) ③ 앱 안에서만 하는 결제·권한 처리를 찾아줘. 각 문제마다 위치, 공격 방법, 고치는 방법을 알려줘.

③ Supabase·Firebase 같은 DB나 파일 저장소를 쓴다면 — ① 다음에

너는 보안 레드팀이야. 이 프로젝트의 데이터베이스와 파일 저장소 설정을 공격자 입장에서 점검해줘. ① 로그인 없이 공개 키만으로 읽거나 쓸 수 있는 테이블 ② 로그인한 사용자가 남의 데이터를 읽거나 고칠 수 있는 경로 ③ 누구나 열 수 있는 파일 저장소 ④ 암호화 없이 저장된 개인정보를 찾아줘. 실제로 확인해 볼 수 있는 요청 예시와 고치는 방법을 같이 알려줘.

④ 문제 목록이 나왔으면 — 같은 채팅창에 이어서

위에서 찾은 문제를 심각한 순서로 정리하고, 하나씩 서버 쪽에서 고쳐줘. 고친 뒤에는 같은 공격을 다시 시도해서 실제로 막혔는지 확인해줘.

결과를 받으면 세 가지만 기억하세요.

• 시크릿 키 노출, 가격·결제 조작, 남의 데이터 접근은 바로 고쳐요. 나머지는 우선순위를 보고 정해도 돼요
• 고칠 때는 클라이언트가 아니라 서버에서 막아요. 클라이언트에 보안을 거는 건 사실상 의미가 없어요. 결국 다 뜯기거든요
• 완벽할 필요는 없어요. 서버와 클라이언트를 나누고 외부 서비스를 서버 뒤로 숨기기만 해도 웬만한 보안 이슈는 잘 안 생겨요. 여기에 민감정보 암호화까지 했다면, 사이드 프로젝트 하는 개인 개발자로서 할 건 다 한 거예요

AI 기능을 넣었다면 하나만 더요. 프롬프트 인젝션까지 출시 전부터 막을 필요는 없다고 봐요. 악용하는 사람이 나타나는 건 생각보다 나중이거든요. 대신 사용자별로 크레딧 한도를 걸어서, 넘으면 끊기게만 해 두세요. 요금 폭탄은 그걸로 막혀요.

배포 전 체크리스트

• 배포된 사이트·앱에서 sk-, secret, service_role을 검색해도 아무것도 안 나온다
• 한 번이라도 노출된 키는 재발급했다
• 가격·할인·배송비는 서버가 계산한다
• API 주소의 ID만 바꿔서 남의 데이터를 불러올 수 없다
• 관리자 화면은 서버가 권한을 확인한 뒤에만 내려간다
• 브라우저에서 DB에 직접 붙어 테이블을 읽을 수 없다
• 주민번호 같은 민감정보는 암호화해서 저장한다
• AI 기능에 사용자별 사용 한도가 걸려 있다
• 레드팀 프롬프트 ①을 돌리고, 나온 문제를 고쳤다

더 보고 싶다면

우리가 아무리 보안 수준이 높은 코드를 작성하더라도 데이터베이스 자체가 문이 열려 있으면 소용이 없어요.

DB나 이미지 저장소 같은 인프라는 꼭 필요한 권한을 가진 경우에만 접근을 허용하도록 규칙을 세워야 해요. 이 부분은 AI에게 통째로 맡기기가 조금 번거로워서, 어느 정도 알아 두는 편이 좋아요.

이 내용은 따로 강의로 정리했어요. 아래 인프라·네트워크 설계 VOD를 보세요.

관련 숏츠: 바이브코딩 보안은 어떻게 해야할까? · 바이브코딩 앱, 배포 전 보안 점검 3가지