3시간 만에 월 1억 앱? 바이브코딩 시대에 제일 먼저 털리는 건 보안이야

앱 하나가 3시간 만에 나오면, 취약점도 3시간 만에 나온다

요즘 바이브코딩 얘기 들으면 웃기면서도 좀 섬뜩해. 말로 대충 설명하면 앱 제작 도구가 화면 만들고, 로그인 붙이고, 결제 흐름까지 뽑아준다. 누군가는 재미로 만든 앱이 월 1억원을 번다고 하고, 구글 AI 스튜디오 같은 도구도 점점 모바일 쪽으로 내려온다. 개발 민주화? 맞아. 진입 장벽이 낮아지는 건 좋은 일이지.

그런데 공격자 입장에서 보면 이건 더 맛있는 시장이 열린다는 뜻이기도 해. 예전에는 앱 하나 만들려면 개발자, 서버, 배포, 심사, 운영 지식이 필요했다. 지금은 프롬프트 몇 줄과 샘플 코드로 프로토타입이 바로 튀어나온다. 문제는 속도가 빨라진 만큼 검증은 느슨해진다는 거야. 보안은 사후약방문이야. 특히 "일단 돌아가네?"라는 말이 회의실에서 나오는 순간, 취약점은 이미 배포 대기열에 올라가 있다.

코드가 현대의 언어라면, AI 코딩 도구는 번역기다. 번역기가 문장을 자연스럽게 만들어도 계약서의 법적 책임까지 이해하는 건 아니잖아. 앱도 똑같다. 화면이 예쁘고 버튼이 눌린다고 해서 권한 설계, 인증 흐름, 개인정보 저장 방식이 안전하다는 뜻은 아니다. 겉보기엔 완성품인데 속은 임시 스크립트인 경우, 진짜 많이 나온다.

제일 위험한 건 "내 앱은 작아서 안 털려"라는 착각

작은 앱이 더 안전하다는 믿음은 거의 미신에 가깝다. 공격자는 유명한 서비스만 보지 않아. 자동화 스캐너는 규모를 가리지 않는다. API 엔드포인트가 열려 있으면 찔러보고, 관리자 페이지가 노출돼 있으면 로그인 시도하고, 깃허브에 키가 올라와 있으면 바로 긁어 간다. 잠든 사이에 봇이 수천 개 서비스를 훑는 세상에서 "아직 사용자 1,000명밖에 안 돼요"는 방어 논리가 아니다.

바이브코딩 앱에서 특히 자주 터질 만한 건 세 가지다. 첫째, API 키 노출. 프론트엔드 코드에 외부 서비스 키를 박아 넣으면 브라우저에서 그대로 보인다. 둘째, 권한 과다 요청. 사진첩, 위치, 연락처, 마이크 권한을 아무 이유 없이 달라고 하면 사용자도 위험하고 앱도 심사에서 걸린다. 셋째, 서버 검증 부재. 클라이언트에서만 결제 완료를 확인하거나, 사용자 역할을 화면에서만 숨기면 끝이야. 공격자는 버튼을 누르지 않는다. 요청을 직접 만든다.

예전에 어떤 팀이 "자동 생성 도구가 뽑아준 관리자 페이지라 편하다"고 보여준 적이 있어. 주소만 알면 로그인 없이 통계가 보였다. 개발자는 "테스트용이라 괜찮다"고 했지. 공격자 입장에서 보면 그 말은 초대장이다. 테스트용 데이터에 진짜 이메일이 섞이고, 임시 비밀번호가 운영 비밀번호와 비슷하고, 스테이징 서버가 검색엔진에 잡히는 순간 이야기는 끝난다.

플랫폼이 쉬워질수록 책임은 더 명확해야 한다

구글이 AI 앱 제작 도구를 더 많은 사람에게 열어주는 흐름은 피할 수 없다. 스마트폰이 카메라 산업을 바꿨듯, 생성형 개발 도구는 앱 제작 문법을 바꿀 거야. 예전에는 소수의 개발자가 코드를 썼다면, 이제는 기획자, 디자이너, 마케터, 1인 창업자까지 앱을 만든다. 이건 문화적 변화다. 코드가 전문직의 성벽에서 내려와 일상어가 되는 장면이니까.

하지만 성벽이 낮아지면 출입문 관리는 더 중요해진다. 플랫폼은 기본 보안 가드레일을 깔아야 한다. 위험한 권한 요청을 경고하고, 개인정보를 로컬에 평문 저장하지 못하게 막고, 배포 전 취약한 인증 패턴을 잡아내야 한다. 자동 생성 코드가 위험한 패턴을 만들었다면 그 이유도 같이 설명해야 한다. "이 코드는 데모용이고 운영에는 부적합합니다" 같은 경고는 선택이 아니라 기본값이어야 해.

개발자도 태도를 바꿔야 한다. 이제 우리의 역할은 모든 코드를 직접 타이핑하는 사람이 아니라, 자동 생성 코드의 결과물을 의심하고 검증하는 사람에 가깝다. 옛날 장인이 망치질로 집을 지었다면, 지금은 공장에서 뽑힌 자재가 규격에 맞는지 검사하는 감리자에 가깝다. 낭만은 줄었지만 책임은 늘었다. 패치 안 하면 끝이야.

바이브코딩 앱 배포 전, 이것만은 보고 가자

1. 시크릿과 인증은 서버에서 끝내라

첫째, 비밀값은 절대 앱 안에 넣지 마. API 키, 토큰, 데이터베이스 URL은 서버 환경변수로 빼고, 클라이언트에는 공개돼도 되는 값만 남겨야 한다. 배포 전에 시크릿 스캔을 한 번 돌리는 건 선택이 아니라 기본이다. 둘째, 인증은 서버에서 검증해. 화면에서 버튼을 숨기는 건 보안이 아니다. 요청이 들어올 때마다 사용자가 누구인지, 어떤 권한인지 서버가 판단해야 한다.

2. 최소 권한과 로그 위생을 기본값으로 둬라

셋째, 개인정보 최소 수집. 앱이 날씨를 보여주는데 연락처 권한을 요구하면 그건 이미 설계가 틀린 거다. 최소 권한 원칙은 거창한 보안 교리가 아니라 사고 반경을 줄이는 현실적인 장치야. 넷째, 로그에 민감정보 남기지 마. 디버깅하려고 찍어둔 이메일, 전화번호, 결제 토큰이 사고 때 피해 규모를 키운다.

3. OWASP와 의존성 점검을 자동화해라

다섯째, 배포 전 자동 점검을 돌려. OWASP Top 10에 걸리는 인증 실패, 권한 검증 누락, 취약한 의존성, 오픈소스 라이선스, 노출된 시크릿, 기본 관리자 계정 정도는 도구로 잡을 수 있다. 그리고 마지막. 자동 생성 코드를 믿지 마. 도움은 받되 신뢰는 검증 뒤에 줘야 한다. 세상 모든 시스템은 뚫린다. 다만 제대로 만든 시스템은 한 번 뚫려도 전체가 무너지지 않게 버틴다.

누구나 앱을 만드는 시대, 누구나 책임도 져야 한다

바이브코딩은 분명 멋진 변화다. 아이디어가 있는 사람이 더 빨리 실험하고, 작은 팀이 큰 회사처럼 제품을 만들 수 있다. 스타트업 생태계에는 축복일 수 있어. 문제는 속도가 윤리를 앞지를 때다. 효율성이 곧 안전은 아니다. 더 빨리 만들수록 더 빨리 망가질 수도 있다.

19세기 공장 기계가 생산성을 폭발시켰을 때도 처음부터 안전장치가 있었던 건 아니다. 손가락을 잃고, 노동 규칙이 만들어지고, 표준이 생겼다. 디지털 세계도 비슷하다. 우리가 앱을 3시간 만에 만들 수 있게 됐다면, 이제 다음 질문은 이거다. 그 앱이 3개월 뒤에도 사용자 데이터를 지킬 수 있나?

재미로 만든 앱이 돈을 벌 수 있는 시대가 왔다. 좋다. 그런데 재미로 만든 보안은 없다. 사용자는 실험용 데이터가 아니고, 개인정보는 장난감이 아니다. 바이브코딩의 진짜 실력은 프롬프트를 얼마나 잘 쓰느냐가 아니라, 배포 버튼 앞에서 얼마나 오래 의심하느냐에서 갈린다.