배포 버튼 누르기 전 5분만 투자하자
바이브코딩으로 앱을 만들 때의 흐름은 빠르다. 프롬프트 작성 → AI 코드 생성 → 테스트 → 배포. 이 과정에서 보안 점검은 보통 생략된다. 그리고 사고는 배포 직후에 일어난다.
이유는 단순하다. AI 코딩 도구는 "동작하는 코드"를 만드는 데 최적화돼 있지, "안전한 설정"까지 챙겨주지는 않는다. 로컬에서 잘 돌아가던 앱이 인터넷에 노출되는 순간, 로컬에서는 문제없던 디버그 모드·열린 포트·공개된 키가 전부 공격 표면으로 바뀐다. 공격자는 신규 배포를 사람보다 먼저 찾는다. 새로 뜬 서버 IP와 도메인을 자동 스캐너로 24시간 훑고, 노출된 .env·인증 없는 DB·디버그 페이지를 자동으로 수집한다. 사람이 "이제 홍보 좀 해볼까" 생각하기도 전에 봇이 먼저 도착한다.
SENTRIX가 레드팀 진단에서 반복적으로 목격하는 초기 침해 경로는 화려한 제로데이가 아니다. 대부분은 배포 설정 실수 하나다. 5분이면 충분하다. 아래 다섯 가지만 확인해도 흔한 보안 사고의 대부분을 막을 수 있다.
점검 항목 5가지
1. .env 파일이 공개 저장소에 올라가지 않았는가
가장 흔하고, 가장 치명적이다. .env 안에는 DB 비밀번호, 결제 API 키, 외부 서비스 토큰이 평문으로 들어있다. 이게 공개 GitHub 저장소에 올라가면 사실상 서버 열쇠를 인터넷에 게시한 것과 같다. 공격자는 GitHub 검색과 자동 봇으로 API_KEY, SECRET, PASSWORD 같은 패턴을 실시간 수집한다. 커밋 후 노출된 키가 악용되기까지 수 분 단위로 짧아지는 경우도 흔하다.
먼저 현재 상태를 확인한다.
cat .gitignore | grep .env
# 아무것도 안 나오면 즉시 추가
echo ".env" >> .gitignore
echo ".env.local" >> .gitignore
echo ".env.production" >> .gitignore
직접 확인하는 법: 저장소가 이미 원격에 올라가 있다면, 브라우저에서 GitHub 저장소로 가서 검색창에 .env를 쳐본다. 파일이 뜨면 이미 노출된 것이다. 커밋 이력에 한 번이라도 들어갔다면 .gitignore에 뒤늦게 추가해도 소용없다, git history에 영구히 남는다. 다음으로 확인한다.
# 과거 커밋에 .env가 있었는지 추적
git log --all --full-history -- .env .env.local .env.production그래서 뭘 해야 하나: 한 줄이라도 결과가 나오면 순서는 정해져 있다. (1) 노출된 모든 키를 즉시 재발급한다. 파일을 지우는 것보다 키 무효화가 먼저다. 이미 유출됐다고 가정하라. (2) GitHub 저장소의 Settings → Security → Secret scanning 알림을 확인한다. (3) 이력에서 완전히 지우려면 git filter-repo로 히스토리를 재작성하고 강제 푸시한다. 키만 바꿔도 실제 피해는 대부분 차단된다.
2. Supabase RLS가 켜져 있는가
Supabase처럼 프론트엔드에서 DB를 직접 호출하는 구조는 바이브코딩에서 매우 흔하다. 편리한 만큼 위험도 크다. RLS(Row Level Security)가 꺼져 있으면, 클라이언트에 심어진 anon 키만으로 누구나 테이블 전체를 읽고 쓸 수 있다. anon 키는 브라우저 코드에 노출되는 게 정상이라, "키가 있으니 안전하다"는 착각이 사고로 이어진다. 실제 레드팀 관점에서 Supabase 앱을 만나면 가장 먼저 하는 일이 바로 RLS 상태 확인이다.
공격 시나리오는 이렇다. 공격자는 브라우저 개발자도구 → Network 탭에서 supabase.co/rest/v1/ 요청과 anon 키를 그대로 복사한다. 그리고 같은 키로 users, orders 같은 테이블에 직접 SELECT를 날린다. RLS가 없으면 회원 전체의 이메일·주소·주문 내역이 응답으로 돌아온다. UI에 버튼이 없다고 데이터가 안전한 게 아니다, API는 UI를 거치지 않는다.
직접 확인하는 법: Supabase 대시보드 → Table Editor에서 각 테이블 옆 방패 아이콘이 초록(활성)인지 본다. 더 확실한 검증은 직접 쏴보는 것이다.
# anon 키로 테이블을 통째로 읽어본다 (내 앱의 공개 키로 테스트)
curl "https://<프로젝트>.supabase.co/rest/v1/users?select=*" \
-H "apikey: <anon_key>"
# 데이터가 그대로 나오면 RLS가 뚫려 있다는 뜻그래서 뭘 해야 하나: 꺼진 테이블은 RLS를 켜고, "기본 차단 후 필요한 것만 허용" 원칙으로 정책을 작성한다. 예를 들어 사용자가 본인 행만 보게 하려면:
-- 취약: RLS 꺼짐 → 전체 노출
-- 안전: 본인 데이터만 접근 허용
alter table users enable row level security;
create policy "본인 행만 조회"
on users for select
using ( auth.uid() = id );정책을 켠 뒤에는 위 curl 테스트를 다시 돌려 빈 배열이 오는지 확인한다. 그게 검증이다.
3. 디버그/개발 모드가 꺼져 있는가
디버그 모드가 켜진 채 배포되면, 에러가 날 때 프레임워크가 스택 트레이스·환경변수·DB 쿼리·파일 경로를 에러 페이지에 그대로 뿌린다. 공격자에게는 이게 무료 설계도다. Django의 경우 DEBUG=True 상태에서 존재하지 않는 URL을 호출하면 등록된 모든 URL 패턴이 노출되고, 예외 페이지에는 설정값 일부까지 찍힌다. 공격자는 일부러 에러를 유발해 내부 구조를 캐낸다.
# Next.js: .env.production 확인
NODE_ENV=production
# Django: settings.py 또는 환경변수 확인
DEBUG=False
# Flask
app.config['DEBUG'] = False직접 확인하는 법: 배포된 사이트에서 존재할 리 없는 주소를 열어본다. 예: https://내앱.com/asdf-없는페이지-123. 여기서 상세한 오류 화면·코드 조각·경로가 보이면 디버그 모드가 켜져 있는 것이다. 정상 배포라면 밋밋한 404/500 페이지만 떠야 한다.
그래서 뭘 해야 하나: 디버그 플래그를 끄는 것으로 끝내지 말고, 프로덕션 설정을 함께 잠근다. Django라면 DEBUG=False와 동시에 ALLOWED_HOSTS를 실제 도메인으로 좁히고, 커스텀 404/500 템플릿을 둔다. 이 값들은 코드에 박지 말고 환경변수로 분리해, 로컬은 켜고 운영은 꺼진 상태가 자동으로 유지되게 한다.
4. 열려있으면 안 되는 포트가 노출되지 않았는가
클라우드에 서버를 띄우면서 "일단 되게 하려고" 보안 그룹을 0.0.0.0/0(전체 허용)으로 열어두는 실수가 잦다. 특히 데이터베이스 포트가 인터넷에 열려 있으면, 앱을 거칠 필요도 없이 DB에 직접 붙는다. 인증이 약하거나 없는 Redis·MongoDB는 발견 즉시 탈취 대상이 된다.
클라우드 보안 그룹(AWS Security Group, GCP Firewall)에서 다음 포트가 0.0.0.0/0으로 열려있지 않은지 확인한다.
- 3306 (MySQL), 5432 (PostgreSQL): DB 직접 접근. 열려 있으면 브루트포스와 알려진 취약점 공격의 표적이 된다.
- 6379 (Redis): 기본 설정은 인증이 없다. 열려 있으면 데이터 조회는 물론, 설정 명령으로 서버 파일 쓰기·원격 코드 실행까지 이어질 수 있다.
- 27017 (MongoDB): 인증 미설정이면 그대로 공개 DB가 된다. 노출된 MongoDB를 찾아 데이터를 지우고 몸값을 요구하는 자동 공격이 상시 돌아간다.
- 22 (SSH): 전체 공개는 금물. 특정 관리자 IP만 허용해야 한다.
직접 확인하는 법: 내 서버 IP를 대상으로 밖에서 포트가 열려 있는지 본다.
# 특정 포트가 외부에서 열려 있는지 확인
nc -zv <서버IP> 5432 6379 27017 3306
# nmap이 있으면 한 번에
nmap -Pn -p 22,3306,5432,6379,27017 <서버IP>"open"으로 뜨는 DB/캐시 포트가 있으면 그건 문제다. 보안 그룹 콘솔에서 각 규칙의 소스가 0.0.0.0/0인지도 눈으로 재확인한다.
그래서 뭘 해야 하나: DB·캐시 포트는 인터넷에서 완전히 닫고, 애플리케이션 서버의 내부 IP(같은 VPC/보안 그룹)에서만 접근하게 좁힌다. SSH는 관리자 IP로 제한한다. "일단 열고 나중에 닫자"는 대부분 닫히지 않는다, 처음부터 닫힌 상태로 배포하는 게 원칙이다.
5. URL 하나로 전체 점검
위 네 가지를 손으로 확인했다면 큰 구멍은 막은 셈이다. 다만 사람은 빠뜨린다. 특히 보안 헤더 누락(Content-Security-Policy, X-Frame-Options, Strict-Transport-Security), SSL 설정 문제, 하위 도메인에 방치된 테스트 서버처럼 눈에 잘 안 띄는 설정 취약점은 손 점검으로 놓치기 쉽다. 마지막으로 배포된 URL을 스캐너에 돌려서 설정 레벨의 취약점을 한 번에 확인한다.
CodeScan은 URL 하나만 넣으면 21개 항목을 자동 점검한다, 보안 헤더, SSL/TLS, 노출된 .env·백업 파일, 열린 디렉터리, 하위 도메인, 이메일 스푸핑 설정(SPF/DKIM/DMARC)까지. 설치도 로그인도 필요 없고, 결과는 등급과 함께 무엇을 어떻게 고칠지 알려준다.
배포 후에도 정기 점검이 필요하다
한 번 점검했다고 끝이 아니다. 보안 상태는 시간이 지나면서 조용히 무너진다. SSL 인증서는 만료되고, 급하게 추가한 새 API에는 인증이 빠져 있고, 잘 돌던 의존성 패키지에서 신규 취약점(CVE)이 발표된다. 어제 A등급이던 앱이 오늘 취약해지는 일은 흔하다. 특히 바이브코딩처럼 기능을 빠르게 붙여 나가는 개발 방식에서는, 배포마다 새로운 공격 표면이 생긴다.
그래서 초기 점검만큼 지속 모니터링이 중요하다. 사람이 매주 기억해서 돌리기는 어렵다. 자동화가 답이다. CodeScan의 정기 모니터링을 걸어두면 SSL 만료·신규 취약점·설정 변화가 감지될 때 알림을 받는다. 사고가 터진 뒤가 아니라, 터지기 전에 안다.
지금 배포하는 앱이 있다면, 홍보를 시작하기 전에 30초만 투자하자. URL 하나로 내 앱의 실제 보안 상태부터 확인하는 게 순서다.