바이브 코딩, 어디까지 맡겨도 될까요? 멈추는 지점 3곳

AI한테 시켰더니 2주 만에 화면이 나왔어요. 로그인도 되고, 목록도 뜨고, 버튼도 눌리죠. 사내 시연에서 반응도 좋았고요. 그런데 6개월이 지난 지금도 출시를 못 하고 있지 않으신가요?

여러분만 겪는 일이 아니에요. 멈추는 지점은 정해져 있고, 이미 데이터로도 밝혀져 있어요.

미리 말씀드리면, 저희는 바이브 코딩을 권해요. 저희도 씁니다. 다만 어디까지가 그 도구의 영역인지 알고 쓰는 것과 모르고 쓰는 건 결과가 완전히 달라요. 오늘은 그 경계선 이야기를 해볼게요.

바이브 코딩은 왜 80%에서 멈출까요?

2026년 6월에 나온 연구가 이 질문에 정면으로 답해요. 연구팀이 이런 방식으로 만들어진 저장소 10,517개를 모은 다음, 그중 실제로 배포까지 된 1,170개에서 200개를 무작위로 뽑아 보안 분석을 했거든요.

결과는 이랬어요. 배포된 앱 200개 중 180개, 그러니까 90%에서 취약점이 나왔어요. 총 1,471건이었고 심각도로 보면 Critical이 20%, High가 56.7%로 둘을 합치면 76.7%예요. 업계 기준선과 비교하면 최대 20배 높은 수치고요.

어떤 결함이 제일 많았을까요? 1위가 접근 통제 실패(36.0%)였어요. 쉽게 말해 "권한 없는 사람이 남의 데이터를 볼 수 있는" 문제죠. 그다음이 암호화 실패(20.7%), 코드 침투(17.7%), 인증 실패(9.0%) 순이었고요. 코드 침투는 공격자가 입력창 같은 통로로 명령을 밀어 넣는 방식이라 인젝션이라고도 불러요.

그런데 왜 그렇게 됐는지가 더 중요해요. 연구팀이 원인을 분석했더니 이런 결과가 나왔거든요.

원인	비중	무슨 뜻이냐면
숨겨진 보안 규칙	43.9%	사용자가 콕 집어 말하지 않으면 AI가 알아서 챙기지 않아요
데모 지향 설계	16.1%	'보여주기용' 코드를 만들고 실운영 조건은 가정하지 않아요
기타 지식·기억 결함	나머지	맥락 유실, 앞서 정한 것 망각 등

AI는 말하지 않은 걸 하지 않아요. 그런데 실서비스 요구사항은 대부분 아무도 말해주지 않는 것들이죠. "결제 실패하면 어떻게 되나요", "이 데이터를 다른 회사 직원이 보면 안 되죠", "동시에 1,000명이 누르면요" 같은 것들이요.

Q. 모델이 더 좋아지면 해결되지 않나요?

가장 많이 받는 질문이고, 마침 데이터가 있어요. 보안 기업 베라코드(Veracode)가 100개 이상의 모델을 네 차례에 걸쳐 같은 방식으로 측정했거든요.

모델이 좋아진 만큼 보안이 따라오지 않은 거예요. 절반 가까이가 여전히 보안 테스트에 실패합니다.

그런데 이건 희망적인 이야기이기도 해요. 같은 연구에서 재밌는 실험을 했거든요. 작업은 똑같이 시키고 프롬프트만 바꿔본 거예요.

그냥 시켰을 때 취약점 발생률이 40%였어요. 더 큰 모델로 바꿨더니 33%, 거의 그대로였고요. 그런데 "실서비스용"이라고 한마디 덧붙였더니 13%로 떨어졌어요.

연구팀 결론이 이래요. "바이브 코딩의 보안은 코드 생성 문제가 아니라 워크플로 수준의 문제다." 도구를 바꾸는 것보다 무엇을 요구할지 아는 게 3배 효과적이라는 뜻이에요.

Q. 로그인이랑 결제까지 다 되는데, 뭐가 부족한 건가요?

멈추는 지점 ① 보안·인증·결제

실제로 무슨 일이 벌어지는지 보실래요? 2026년 초에 있었던 일이에요.

여기서 짚을 부분은 이 앱이 잘 돌아갔다는 거예요. 화면도 예쁘고, 기능도 되고, 사용자도 모였죠. 빠진 건 "권한 없는 사람은 못 보게 한다"는 설정 하나였는데, 그건 화면 어디에도 나타나지 않아요.

한국에서는 이 항목이 특히 무거워요

2023년 9월 개인정보보호법 개정으로 과징금 기준이 "위반행위 관련 매출액"에서 "전체 매출액의 3% 이하"로 바뀌었어요. 서비스 하나의 매출이 아니라 회사 전체 매출이 기준이죠.

최근 제재를 보면 규모가 짐작되실 거예요. 2025년 8월 통신사 약 1,348억 원, 2026년 6월 유통 플랫폼 약 6,247억 원이 부과됐어요. 특히 후자의 제재 사유에 "인증 서명키 관리 및 접근통제 소홀 등 기본적인 안전관리 체계 미흡"이 명시됐고요.

앞에서 본 연구에서 바이브 코딩 앱 취약점 1위가 뭐였는지 기억하시나요? 접근 통제 실패, 36%였어요. 같은 항목이죠.

결제는 코드 밖에도 요건이 있어요

결제를 붙이려면 코드만으로는 안 돼요. 전자지급결제대행업(PG)으로 등록하려면 자본금 10억 원 이상이라는 요건이 전자금융거래법 시행령에 정해져 있고, 여기에 재무 건전성과 전산 전문인력 확보 같은 요건이 함께 붙어요. 코드 품질과 무관하게 적용되는 조건인 거죠.

직접 등록하지 않고 PG사를 통해도 심사는 통과해야 해요. 저희 경험상 여기서 자주 막히는데, 심사는 "결제창이 실제로 뜨는지"를 봅니다. 코드가 완성돼 있어도 실제로 띄워지지 않으면 통과가 안 돼요.

Q. 배포는 성공이라는데 왜 화면은 그대로일까요?

멈추는 지점 ② 배포·운영

로컬에서는 완벽한데 배포하면 이상해지는 경험, 다들 있으시죠. 그런데 진짜 골치 아픈 건 배포가 성공이라고 뜨는데 실제로는 반영이 안 된 경우예요.

AI로 만든 서비스를 넘겨받아 정리해 드린 사례를 몇 가지 소개할게요. 셋 다 담당자분은 "잘 돌아가고 있다"고 알고 계셨던 상태였어요.

공통점이 보이시나요? 셋 다 "고장 났다는 표시가 어디에도 없는 고장"이에요. 화면에 빨간 오류가 뜨면 오히려 다행이죠. 바로 알 수 있으니까요. 정말 곤란한 건 아무 일 없는 것처럼 보이면서 조용히 잘못되는 쪽이에요.

Q. 테스트도 통과했는데 더 봐야 할 게 있나요?

멈추는 지점 ③ 마지막 20%

제일 까다로운 영역이에요. 여기서는 "확인했다"는 것 자체가 착각인 경우가 생기거든요.

이런 일 때문에 저희는 확인 장치를 믿기 전에 꼭 해보는 게 있어요. 일부러 고장을 내보고 그 장치가 잡아내는지 보는 것이에요. 안 잡아내면 그건 아무것도 지키지 않고 있다는 뜻이니까요.

제일 조심할 건 '조용한 폴백'이에요

지금까지 본 사례를 관통하는 패턴이 하나 있어요. 고장이 고장처럼 보이지 않는다는 거예요.

AI한테 코드를 맡기면 꼼꼼하게 잘 짜요. "값이 없으면 기본값을 쓴다", "안 되면 그냥 넘어간다", "설정이 없으면 다른 방법으로 처리한다" 같은 대비를 알아서 넣어주죠. 얼핏 보면 안전해 보이고요.

그런데 실제 서비스에서는 이게 제일 곤란한 형태가 돼요. 잘 되고 있는 것처럼 보이면서 틀리거든요.

화면에 보이는 것	실제로 벌어지고 있던 일
알림이 정상 발송됨	엉뚱한 서비스 이름으로 발송되고 있었음
통계가 정상 집계됨	거의 전부 "알 수 없음"으로 쌓이고 있었음
"결제 준비 중" 안내 표시	설정이 어긋나 결제가 막혀 있었음
"배포 성공" 표시	수정 사항이 서버에 올라가지 않았음

세 번째 줄이 특히 곤란한 경우였어요. 설정이 어긋나 결제를 못 받고 있었는데, 화면에는 "준비 중"이라고 떠서 2주 동안 아무도 이상하다고 생각하지 않았거든요. 친절하게 만들어 둔 안내 문구가 고장을 의도된 상태처럼 보이게 가려버린 거죠.

그래서 AI에게 코드를 맡길 때 "설정이 없거나 값이 비면 조용히 넘어가지 말고 명확히 실패하게 해줘"라고 짚어주세요. 개발자들은 이걸 "빠르게 실패하기"라고 불러요. 운영에서는 시끄러운 실패가 조용한 성공보다 훨씬 낫습니다.

우리 프로젝트, 지금 올려도 될까요?

아래 12개로 직접 점검해 보세요. 각 항목은 "코드가 있는가"가 아니라 "실제로 확인했는가"를 묻습니다.

보안·인증·결제

• 다른 사람 계정 데이터에 접근을 시도해 봤고, 막히는 걸 확인했다. 코드에 권한 검사가 있다는 것만으로는 부족해요. 실제로 남의 ID를 넣어보세요.
• 브라우저 개발자 도구를 열어 소스에 키나 토큰이 노출됐는지 확인했다. 프론트엔드 코드는 사용자가 전부 볼 수 있어요.
• 결제 실패·취소·중복 결제를 각각 실행해 봤다. 성공 경로만 테스트된 결제는 검증된 게 아니에요.
• 개인정보를 수집한다면 수집 항목·보유 기간·파기 시점을 문서로 답할 수 있다. 접근 통제 소홀은 실제 제재 사유예요.

배포·운영

• 배포 후 실제 서비스 주소에서 핵심 기능을 눌러봤다. 배포 성공 표시는 아무것도 보장하지 않아요.
• 배포 스크립트의 모든 단계가 실행됐는지 확인할 방법이 있다. 마지막에 완료 표시를 남기고 그걸 검사하는 게 제일 확실해요.
• 장애가 났을 때 누구에게 어떻게 알림이 가는지 정해져 있고, 한 번은 실제로 받아봤다.
• 데이터베이스 백업이 돌고 있고, 복원을 한 번 해봤다. 백업은 복원해 보기 전까지 백업이 아니에요.

마지막 20%

• 테스트가 있다면, 고친 부분을 일부러 되돌렸을 때 실패하는 걸 확인했다. 실패하지 않으면 그 테스트는 아무것도 안 지켜요.
• 화면에 보이는 값이 실제 데이터인지 확인했다. 기본값이나 임시값이 그럴듯하게 채워진 경우가 많아요.
• 사용자가 실수할 만한 입력을 넣어봤다. 빈 값, 아주 긴 글, 특수문자, 뒤로 가기 연타 같은 것들이요.
• 이 코드를 만든 사람이 아닌 다른 사람이 이해할 수 있는 상태다. 지금은 괜찮아도 담당자가 바뀌는 순간 비용이 돼요.

몇 개나 확실히 체크하셨나요?

9개 이상이면 꽤 잘 관리되고 있어요. 남은 항목만 정리하면 출시 가능한 상태고요.

5~8개는 흔한 상태예요. 다만 미체크가 보안·결제에 몰려 있다면 그것부터 처리하시길 권해요.

4개 이하라면 지금 올릴 때 사고가 날 가능성이 높아요. 다만 이건 프로젝트가 잘못됐다는 뜻이 아니라 아직 프로토타입 단계라는 뜻입니다.

만들어 둔 프로토타입은 버리지 마세요

여기까지 읽고 "그럼 처음부터 다시 만들어야 하나" 싶으셨다면, 그렇지 않아요.

여러분이 만든 프로토타입은 가장 정확한 요구사항 명세서예요. 문서로 백 장을 쓰는 것보다 동작하는 화면 하나가 "우리가 만들려는 게 이겁니다"를 훨씬 정확히 전달하거든요. 실제로 저희가 프로젝트를 받을 때 동작하는 프로토타입이 있는 쪽이 요구사항 정의에 드는 시간이 제일 짧아요.

바뀌어야 하는 건 대개 화면이 아니라 그 아래예요. 권한 구조, 데이터 모델, 배포 방식, 장애 대응 같은 것들이죠. 화면과 흐름은 그대로 살리고 기반만 다시 세우는 방식이 대부분 제일 빠릅니다.

바쁜 담당자님을 위한 4줄 정리

바이브 코딩은 계속 쓰세요. 개발자 84%가 이미 쓰고 있거나 도입할 계획이고, 프로토타입 만드는 데는 압도적으로 효율적이에요.

다만 AI는 말하지 않은 걸 하지 않아요. 배포된 앱 90%에서 취약점이 나온 이유의 44%가 "명시하지 않아서"였어요.

모델을 바꾸는 것보다 요구를 바꾸는 게 3배 효과적이에요. "실서비스용"이라고 말하는 것만으로 취약점이 40%에서 13%로 떨어졌거든요.

제일 위험한 건 에러가 아니라 조용한 성공이에요. 실패는 바로 알 수 있지만 그럴듯한 기본값은 몇 달을 갑니다.

혼자 판단하기 어렵다면

위 체크리스트에서 걸리는 게 있는데 어디부터 손대야 할지 모르겠다면, 그 상태 그대로 문의 주셔도 돼요. 정리해서 오실 필요 없고요. 지금 어디까지 돼 있고 뭐가 비어 있는지 확인하는 게 첫 단계니까요.

저희는 10개 이상의 서비스를 직접 운영하고 있어요. 만들어 넘기고 끝나는 게 아니라, 저희 비용으로 서버를 돌리고 장애를 직접 맞으면서요. 위에 적은 대응 사례들을 실제 화면과 로그까지 열어보며 짚어낼 수 있는 것도 같은 일을 매일 하고 있어서예요. 그리고 저희도 AI를 적극적으로 씁니다. 쓰는 방식이 다를 뿐이에요.

프로젝트 문의하기 — 프로토타입이 있는 상태에서의 인수·고도화, 보안·결제·인프라를 포함한 전체 구축 모두 상담 가능합니다.

참고자료

1. Zhang et al., Understanding the (In)Security of Vibe-Coded Applications, arXiv:2606.23130 (2026) — 저장소 10,517개 수집, 배포된 1,170개 중 200개 감사. 취약점 분포와 프롬프트 실험(40%→13%)의 출처.
2. Veracode, 2026 GenAI Code Security Report — 100개 이상 모델의 보안 통과율 55%→56% 정체.
3. METR, Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity (2025) 및 실험 설계 변경 공지 (2026).
4. 개인정보보호위원회, 쿠팡 개인정보 유출 제재 발표 (2026) — "인증 서명키 관리 및 접근통제 소홀" 인용 출처.
5. 전자금융거래법 시행령, 국가법령정보센터 — 전자지급결제대행업 자본금 요건.
6. The Register, Vibe coding service Replit deleted user's production database (2025).
7. Stack Overflow, 2025 Developer Survey — AI — 개발자 84%가 사용 중이거나 도입 계획.