바이브코딩 할수록 겸손해져야 하는 이유 — PoC는 누구나 만들지만, 운영은 다른 게임입니다

클로드 코드와 GPT 아스트라가 정말 엄청납니다. 이제 코딩을 제대로 배운 적 없는 사람도 아이디어만 있으면 꽤 그럴듯한 PoC 수준의 서비스를 바이브코딩으로 직접 만들 수 있습니다. 저도 2026년 한 해 동안 가계부 앱, 전자책 판매 사이트, 가상 오피스까지 코드를 한 줄도 직접 쓰지 않고 만들었습니다.

그런데 직접 만들어 볼수록 생각이 바뀌었습니다. 바이브코딩은 개발의 진입장벽을 무너뜨렸지만, 서비스 운영의 책임까지 없애 주지는 않았습니다. 이 글에서는 배포 버튼을 누른 뒤에도 남는 사각지대 7가지와, 2026년 10월 기준으로 제가 실제로 점검하는 순서를 정리했습니다.

바이브코딩으로 PoC는 정말 누구나 만들 수 있을까요?

네, 만들 수 있습니다. 지난 9월에는 오퍼스 5.5와 GPT-6 아스트라에 같은 프롬프트 4개를 줘서 결과물을 비교했는데, 모션 웹사이트와 3D 롤러코스터 게임이 프롬프트 한 번에 돌아가는 수준으로 나왔습니다. 그 전에는 한 줄로 적는 가계부 앱도 같은 방식으로 만들었습니다.

솔직히 이런 결과를 보면 “와, 이제 진짜 개발자 없어도 되는 거 아냐?” 싶을 때가 있습니다. 웹사이트·앱 프로토타입, 간단한 기능 구현, Vercel이나 Supabase 같은 서비스로의 빠른 배포, 아이디어 검증까지는 바이브코딩만으로 충분히 가능합니다.

그런데 왜 직접 만들수록 겸손해질까요?

개발자는 여전히 필요합니다. 어쩌면 AI 때문에 더 중요해진 영역도 있습니다.

특히 저 같은 문과 출신은 더 겸손해야 합니다. IT나 플랫폼 서비스 PM을 오래 해 봤다면 모를까, 저희는 애초에 무엇을 모르는지조차 모르는 사각지대가 많습니다. 대표적인 것이 백엔드, 서버, DB, 인프라, 보안입니다.

보통 저 같은 문과생은 AI가 만들어 준 코드를 제대로 읽지 못합니다. AI가 알아서 커밋하고 푸시해 주니 “오? 배포됐다. 끝!”이라고 생각하기 쉽습니다. 그런데 정작 데이터가 암호화되고 있는지, API 키가 노출되지 않았는지, DB 접근 권한은 맞게 설정됐는지, 인증·인가 구조는 안전한지, 트래픽이 갑자기 100배 늘면 버틸 수 있는지는 머릿속에 아예 없는 경우가 많습니다.

사각지대 1. API 키와 Secret은 어디에 있어야 할까요?

API 키는 “이 요청은 내 계정이 보낸 것”이라고 증명하는 비밀번호입니다. 이 값이 브라우저로 내려가는 코드 안에 들어가면, 페이지 소스를 열어 본 누구나 그 키로 내 계정에 요금을 청구할 수 있습니다.

바이브코딩으로 만든 앱에서 자주 생기는 실수가 여기서 나옵니다. 예를 들어 Next.js는 이름이 NEXT_PUBLIC_으로 시작하는 환경 변수를 빌드할 때 브라우저용 코드에 그대로 넣습니다. Next.js 공식 문서에도 이 동작이 설명돼 있습니다. AI가 “에러가 나서 앞에 NEXT_PUBLIC_을 붙였습니다”라고 고쳐 주면, 그 순간 비밀 키가 공개 키가 됩니다.

원칙은 세 가지입니다.

• 비밀 키는 서버 쪽 환경 변수에만 둡니다. Vercel이라면 프로젝트 환경 변수 설정에 넣고, 코드와 GitHub에는 남기지 않습니다.
• .env 파일은 처음부터 .gitignore에 넣습니다. GitHub의 시크릿 스캐닝은 이미 올라간 키를 찾아 주는 안전망이지, 예방책이 아닙니다.
• AI API 콘솔에서 월 사용 한도나 예산 알림을 걸어 둡니다. 키가 새도 피해 금액에 천장이 생깁니다.

보안 개념 없이 서비스를 공개했다가는 API 키 한 번 털리고, 어느 날 영문 모를 해외 API 사용료가 카드에서 빠져나가는 걸 보면서 강제로 클라우드 보안 수업을 듣게 될 수도 있습니다.

이건 가정만이 아닙니다. 저도 실제로 겪었습니다. 작년에 퍼플렉시티(Perplexity) API를 이용해 자동 리서치 솔루션을 바이브코딩으로 만든 적이 있습니다. 마케팅 조사를 하고, 제가 쌓아 둔 스타일의 문서 규격에 따라 보고서를 만들어 주는 솔루션이었습니다.

어느 날부터 쓰지 않는데도 퍼플렉시티 과금이 계속 나갔습니다. 확인해 보니 그 솔루션의 API 키가 노출돼, 정체불명의 사용자가 티 나지 않게 조금씩 쓰고 있었습니다. 어차피 사용성도 낮았던 터라 API 키를 폐기하고 결국 서비스를 종료했습니다.

이렇게 조금씩 새는 요금은 눈에 잘 띄지 않습니다. 그래서 비밀 키는 서버에만 두고, 사용 한도와 예산 알림은 키를 만든 날 바로 걸고, 쓰지 않게 된 서비스의 키는 그때그때 폐기하는 편이 안전합니다.

그리고 2026년 7월에는 제 GitHub 저장소 7개를 전체 커밋 기록까지 점검했습니다. 살아 있는 API 키는 0개였습니다. 운이 아니라, 콘텐츠 자동화 저장소를 처음 만들 때 “기본은 전부 제외, 필요한 파일만 허용”하는 방식으로 .gitignore를 잡아 둔 덕분이었습니다. 반대로 말하면, 이 설정이 없었다면 바이브코딩 속도로 커밋하는 동안 키가 한 번은 섞여 들어갔을 겁니다.

사각지대 2. Supabase에 올렸으니 DB는 안전할까요?

“Vercel이랑 Supabase에 올렸으니 끝 아닌가?” 아닙니다. 그때부터 시작일 수도 있습니다.

Supabase의 publishable 키(예전 이름 anon 키)는 원래 브라우저에 들어가도록 설계된 키입니다. 그래서 이 키로 누가 어떤 행을 읽고 쓸 수 있는지는 키가 아니라 RLS(Row Level Security, 행 단위 접근 정책)가 정합니다. 테이블에 RLS를 켜지 않았거나 정책을 “모두 허용”으로 열어 두면, 공개된 키만으로 다른 사용자의 데이터까지 조회될 수 있습니다. 반대로 secret 키(예전 이름 service_role 키)는 RLS를 우회하는 관리자 키라서 프론트엔드에 절대 들어가면 안 됩니다. 두 키의 차이는 Supabase API 키 문서와 RLS 가이드에 정리돼 있습니다.

바이브코딩으로 DB를 붙일 때 제가 AI에게 꼭 따로 묻는 질문은 이것입니다. “모든 테이블에 RLS가 켜져 있는지, 그리고 로그인한 사용자가 자기 행만 읽고 쓰는지 테이블별로 표로 보여 줘.” 이 질문을 안 하면 AI도 먼저 알려 주지 않는 경우가 많습니다.

사각지대 3. 인증과 인가, 그리고 ‘기본값’이라는 함정

인증(authentication)은 “당신이 누구인지” 확인하는 것이고, 인가(authorization)는 “당신이 이걸 해도 되는지” 확인하는 것입니다. 로그인 화면이 있다고 인가까지 되는 것은 아닙니다. 주소창의 숫자만 바꿔서 남의 주문 내역이 보인다면 인증은 됐지만 인가가 없는 상태입니다. 웹 보안 위험 목록인 OWASP Top 10에서도 접근 통제 실패(Broken Access Control)가 대표 항목으로 올라 있습니다.

제가 7월 점검에서 실제로 찾은 문제도 이 영역이었습니다. 키 유출은 없었지만 설계 문제가 두 가지 나왔습니다.

1. 내 컴퓨터에서만 쓰려던 대시보드 서버가 같은 네트워크의 다른 기기에서도 인증 없이 접속되는 설정이었습니다. 접속 범위를 내 컴퓨터(1xx.x.x.1)로만 좁혀서 고쳤습니다.
2. 다른 저장소에서는 관리자 기능을 지키는 비밀값의 기본값이 예시용 문자열 그대로 남아 있었습니다. 환경 변수로 설정하지 않으면 누구나 그 값을 알 수 있는 구조였습니다. 기본값을 없애고 관리자 경로에 별도 토큰 확인을 붙였습니다.

둘 다 바이브코딩 중에 AI가 “일단 돌아가게” 만들면서 넣은 기본값이었고, 저는 코드를 읽지 못해서 몇 달 동안 몰랐습니다. 이후 공개할 필요가 없는 저장소 3개는 비공개로 바꿨습니다.

사각지대 4. 트래픽이 100배 늘면 서버와 카드값은 버틸까요?

서비스가 잘되면 생기는 문제도 있습니다. 누군가 내 API 엔드포인트를 반복 호출하면, 서버리스 함수 실행 비용과 AI API 호출 비용이 그대로 쌓입니다. 이걸 막는 장치가 레이트 리미팅(rate limiting, 일정 시간당 요청 수 제한)입니다.

• 로그인하지 않은 사용자의 AI 호출은 IP나 세션 단위로 횟수를 제한합니다.
• AI API 콘솔과 클라우드 결제 화면 양쪽에 예산 알림을 걸어 둡니다.
• “갑자기 100배”를 가정해 한 달 최대 비용을 미리 계산해 둡니다. 계산이 안 되면 상한을 먼저 겁니다.

PoC에서는 사용자가 나 혼자라서 이런 장치가 필요 없어 보입니다. 바이브코딩으로 만든 서비스가 실제로 공개되는 순간부터 필요해집니다.

사각지대 5. GitHub 오픈소스와 공개 MCP, 별이 많으면 안전할까요?

GitHub 오픈소스와 공개 MCP라고 무조건 믿으면 안 됩니다. 오픈소스 생태계에는 훌륭한 개발자들이 정말 많습니다. 하지만 인터넷에 공개돼 있다는 이유만으로 그 코드가 안전하다는 보증은 어디에도 없습니다. 악성코드, 공급망 공격, 탈취된 패키지와 계정처럼 저희가 모르는 위험도 존재합니다.

실제 사례도 있습니다. 2024년 3월, 리눅스에서 널리 쓰이는 압축 라이브러리 xz utils의 5.6.0·5.6.1 버전에 백도어가 심겨 배포된 사실이 드러났습니다(CVE-2024-3094). 오랜 기간 기여하며 신뢰를 쌓은 계정이 코드를 넣은 경우였습니다. 별 개수나 기여 이력만으로는 걸러지지 않는다는 뜻입니다.

MCP 서버는 여기서 한 단계 더 조심해야 합니다. MCP는 AI 에이전트에게 파일, 터미널, 외부 서비스 접근 권한을 넘겨주는 통로라서, 악의적인 서버 하나가 내 컴퓨터와 계정 전체에 닿을 수 있습니다. MCP 공식 보안 모범 사례 문서도 권한과 신뢰 범위를 따로 다룹니다.

그러니 출처도 확인하지 않고 “오 이거 MCP네?”, “별 많네?”, “설치!” 하는 습관은 위험합니다. 지난 9월에 제 클로드 코드 플러그인을 출처별로 정리해 봤더니, 플러그인 5개의 출처가 3곳이었고 그중 1곳은 공식 마켓플레이스가 아닌 개인 저장소였습니다. 거기서 받은 것들은 4월에 설치한 뒤 한 번도 쓰지 않은 상태였습니다. 지금은 설치 전에 아래 순서로 확인합니다.

1. 공식 조직 계정인지, 이름 철자가 유명 패키지와 한 글자만 다른 가짜는 아닌지 봅니다.
2. 최근 커밋과 이슈 응답이 살아 있는지, 관리자가 바뀐 적은 없는지 봅니다.
3. 요구하는 권한이 기능에 비해 과하지 않은지 봅니다. 메모 도구가 셸 실행 권한을 요구하면 설치하지 않습니다.
4. 설치한 버전을 고정하고, npm 프로젝트라면 npm audit으로 알려진 취약점을 확인합니다.
5. 쓰지 않는 플러그인과 MCP 서버는 지웁니다.

인터넷에 공개된 코드는 선량한 개발자들의 놀이터이기도 하지만, 공격자가 지뢰를 심을 수 있는 공간이기도 하다고 생각하는 편이 안전합니다.

사각지대 6. 백업과 모니터링이 없으면 장애는 언제 알게 될까요?

답은 “고객이 알려 줄 때”입니다. 바이브코딩으로 만든 PoC에서는 DB가 날아가도 다시 만들면 되지만, 고객 데이터가 쌓인 서비스에서는 복구할 수 없는 손실이 됩니다.

• 백업은 “켜 두었다”가 아니라 “복원해 봤다”까지가 백업입니다. 사용하는 DB 서비스의 백업 주기와 보관 기간을 확인하고, 한 번은 테스트 환경에 실제로 복원해 봅니다.
• 에러 로그와 알림을 한곳으로 모읍니다. 결제 실패, 로그인 실패 급증, 함수 타임아웃은 사람이 보기 전에 알림이 먼저 와야 합니다.
• 배포가 끝나면 실제 주소를 직접 두드려 보는 점검을 돌립니다. 저는 판매 중인 전자책 사이트를 리뉴얼하던 날 밤, 배포 직후 모든 작품의 본문 주소가 404를 내는 장애를 겪었습니다. 로컬에서는 재현되지 않는 문제였고, 핫픽스까지 3분이 채 안 걸렸지만 그동안 구매자의 리더는 열리지 않았습니다. 그 뒤로는 배포할 때마다 주소 10곳, 콘텐츠 API 7개, 결제 설정 2가지까지 19개 항목을 자동으로 확인합니다.

사각지대 7. 개인정보를 받는 순간, 게임 난이도가 올라갑니다

진짜 무서운 건 기술만이 아닙니다. 법과 운영이 남아 있습니다. 이메일 주소 하나라도 회원 정보를 받는 서비스를 만들면 한국에서는 개인정보 보호법이 적용됩니다. 법률 전문가가 아닌 입장에서 조심스럽게, 조문에 근거가 분명한 기본만 정리하면 이렇습니다.

결국 무슨 정보를 왜 수집하는지, 어디에 저장하는지, 누가 접근할 수 있는지, 얼마나 보관하는지, 언제 어떻게 파기하는지까지 생각해야 합니다. 원문은 국가법령정보센터의 개인정보 보호법에서, 해설과 가이드는 개인정보보호위원회와 개인정보 포털에서 확인할 수 있습니다. 보안 점검 도구와 침해사고 안내는 한국인터넷진흥원(KISA)이 제공합니다. 위반하면 과태료·과징금 같은 제재 조항도 있으니, 실제로 회원을 받기 전에는 전문가 확인을 권합니다.

배포 전에 확인할 바이브코딩 체크리스트 7가지

바이브코딩 중에 이 질문들을 던지면, 정답보다 제가 무엇을 모르는지가 먼저 드러납니다. 답이 이해되지 않으면, 그 부분이 바로 개발자에게 물어봐야 할 곳입니다.

자주 묻는 질문

Q. 바이브코딩으로 만든 서비스는 출시하면 안 되나요?

A. 아닙니다. 다만 PoC와 출시 사이에 위 7가지를 확인하는 단계가 하나 더 있어야 합니다. 결제나 개인정보가 오가는 서비스라면 그 단계에 개발자 검토를 넣는 것을 권합니다.

Q. AI에게 “보안 점검해 줘”라고 하면 충분하지 않나요?

A. 도움은 됩니다. 하지만 AI는 질문받은 범위만 봅니다. “키가 새지 않았는지”와 “다른 기기에서 접속할 수 있는지”, “남의 데이터를 읽을 수 있는지”는 각각 따로 물어야 답이 나옵니다.

Q. 바이브코딩으로 만든 개인 프로젝트인데 개인정보 처리방침까지 필요한가요?

A. 다른 사람의 개인정보를 받아 처리한다면 규모와 상관없이 기본 의무를 확인해야 합니다. 처음부터 이메일 같은 개인정보를 받지 않는 설계로 가는 것도 방법입니다.

마치며 — 내가 무엇을 모르는지 아는 능력

요즘 바이브코딩을 하면서 가장 크게 느끼는 것은 이것입니다. AI는 개발의 진입장벽을 무너뜨렸습니다. 하지만 서비스 운영의 책임까지 없애 주지는 않았습니다. PoC를 만드는 것과 실제 고객에게 돈을 받고 서비스를 운영하는 것은 완전히 다른 문제입니다.

AI 덕분에 문과생도 개발할 수 있는 시대가 왔습니다. 그래서 오히려 더 중요한 능력은 “AI가 다 해 준다”는 자신감이 아니라, 내가 무엇을 모르는지 아는 능력입니다.

아이디어 검증이 목적이라면 지금처럼 빠르게 만들어도 괜찮습니다. 반대로 고객의 돈이나 개인정보를 받는 서비스라면, 출시 전에 이 글의 체크리스트를 한 번은 거치시길 권합니다. 바이브코딩 할수록 겸손해져야 합니다. 특히 Production에 올릴 거라면 더더욱.

▶ 이 글의 내용을 영상으로 보기: 유튜브 ATM 「바이브코딩 할수록 겸손해야 하는 이유」

*이 글은 2026년 10월 기준 제 작업 경험과 공개 문서를 바탕으로 정리했습니다. 법률·보안 자문이 아니며, 실제 서비스의 개인정보·보안 요건은 전문가와 함께 확인하시기 바랍니다.*

작성자 소개

Marketer Jin

Editor

AI 트렌드 마스터(ATM) — 20년 경력의 디지털 마케터이자 AI 에이전시 운영자입니다. AI 에이전트로 홈페이지·앱·서비스를 직접 만들고 그 과정을 실습 중심으로 공유합니다. YouTube @aitrendmaster 운영. 직접 제작: moa365·atmbook·atm.ai.kr. 문의 aitrendmarketer@gmail.com

웹사이트 방문 모든 글 보기