'3시간 만에 풀스택 앱을 완성했다'는 이야기가 더 이상 놀랍지 않은 시대가 됐다. Cursor, Bolt, Lovable, Claude—도구의 이름만 바뀔 뿐, 누구나 아이디어를 코드로 빠르게 바꿀 수 있다는 명제는 이미 사실로 굳어졌다. 그런데 최근 연속으로 터진 세 가지 사건을 나란히 놓고 보면, 이 풍경이 마냥 낙관적이지만은 않다는 생각이 든다.
신뢰부터 흔들렸다: Copilot의 PR 광고 삽입
Microsoft Copilot이 자동으로 생성한 GitHub Pull Request 150만 건 이상에 광고 문구를 몰래 삽입했다는 사실이 알려졌다. 호주 개발자 Zach Manson이 단순 오타 수정 PR에서 <!-- START COPILOT CODING AGENT TIPS -->라는 숨은 HTML 주석과 함께 Raycast 홍보 문구가 딸려온 것을 발견하면서 수면 위로 올라온 일이다. Slack, Teams, VS Code 언급이 담긴 변형도 발견되었고, GitLab Merge Request에서도 유사한 사례가 보고됐다.
Microsoft GitHub Copilot 팀의 Tim은 HN 댓글을 통해 '개발자들이 Copilot을 더 잘 활용하도록 돕기 위한 팁이었다'고 해명하며 해당 기능을 비활성화했다. '잘못된 판단이었다'고 인정한 것은 다행이지만, 이미 벌어진 일이 남긴 질문은 쉽게 지워지지 않는다. AI 도구가 내 코드베이스에, 내 이름으로 열린 PR에, 내가 모르는 문자열을 심을 수 있다면—이것은 단순한 실수가 아니라 도구와 개발자 사이의 신뢰 계약을 다시 쓰는 문제다. AI 서비스 산업이 약 4000억 달러의 투자-수익 격차를 메우기 위해 광고 기반 수익 모델로 눈을 돌리고 있는 지금, 이런 시도가 일회성으로 끝나리란 보장도 없다.
속도가 빼앗아간 것: 프로덕트 마인드셋
dev.to에 올라온 글 'Product Mindset Is the Skill Vibe Coding Can't Replace'는 이 흐름을 다른 각도에서 짚는다. 저자는 직접 Claude를 활용해 Go 학습 퀴즈 앱 'Go Mastery'를 만들면서, Vibe Coding이 제거한 것이 단순한 구현 비용만이 아님을 체감했다고 말한다.
구현 비용이 높았던 시대에는 '2주를 쓸 가치가 있는가'라는 질문이 자동으로 강제됐다. 무엇을 만들지, 누구를 위해 만드는지, 실패 시나리오는 무엇인지—이 질문들은 개발 고통 자체가 만들어낸 산물이었다. Vibe Coding은 그 마찰을 없앴고, 덩달아 질문을 강제하는 장치도 사라졌다. 결과적으로 지금 우리는 '만들 수 있는가'가 아니라 '무엇을 만들어야 하는가'를 스스로 물어야 하는 환경에 내던져졌다.
저자가 제안하는 실천은 구체적이다. 프롬프트를 쓰기 전에 브리프를 먼저 작성하고, AI 출력을 '맞는가'가 아니라 '어디서 틀렸는가'의 시각으로 읽는 것. AI 환각(hallucination)과 학습 오개념(misconception)은 구조적으로 같은 문제—90%는 맞고 10%가 교묘하게 틀린 출력—이며, 이걸 잡아내는 능력이 Vibe Coding 시대의 핵심 역량이 된다는 주장이다. 프롬프트를 잘 쓰는 사람이 아니라 출력을 잘 평가하는 사람이 살아남는다.
조용히 터지고 있는 것: 보안 위기
그리고 가장 조용하지만 가장 값비싼 문제가 있다. dev.to의 'The Quiet Security Crisis in Vibe-Coded Apps'는 비개발자 창업자가 AI 코딩 도구로 앱을 만들었다가 하룻밤 사이에 AWS 청구서 4만 7000달러를 받은 사례로 시작한다. 범인은 JavaScript 소스에 하드코딩된 API 키였다. 봇이 이를 발견하고 GPU 인스턴스를 돌려 크립토를 채굴했다.
AI 코딩 도구는 '작동하게 만드는 것'에 최적화되어 있다. .env 파일 생성은 부가 단계이고, 인증 없는 API 라우트는 개발 편의를 위해 그냥 배포된다. CORS 설정은 개발 중 에러를 없애기 위해 origin: "*"로 열어두고 프로덕션까지 그대로 간다. eval(userInput) 같은 코드도 'AI가 기능 요구사항을 빠르게 구현하다 보면' 자연스럽게 나온다. OWASP를 한 번도 들어본 적 없는 수백만 명이 앱을 배포하는 지금, 이것은 예외가 아니라 표준이 되어가고 있다.
세 사건이 교차하는 지점
이 세 이야기는 각기 다른 문제처럼 보이지만 하나의 지점에서 만난다. AI 도구가 개발의 속도를 압도적으로 높이는 동시에, 그 속도가 가려버리는 것들—신뢰, 판단력, 보안—이 지금 동시에 위기에 처해 있다는 것이다.
Copilot의 PR 광고 삽입은 도구 자체가 개발자의 공간을 침범할 수 있다는 선례를 남겼다. AI 환각을 걸러내지 못한 채 배포된 코드는 기술 부채가 아니라 즉각적인 비즈니스 손실로 이어진다. 그리고 '이게 정말 풀어야 할 문제인가'를 묻지 않은 채 만들어진 제품은 아무리 빠르게 완성해도 사용자에게 닿지 않는다.
실무에서 달라져야 하는 것
프로덕트 관점에서 정리하면 세 가지다.
첫째, 도구를 감사(audit)하라. AI 도구가 내 코드베이스에 무엇을 쓰고 있는지 정기적으로 확인해야 한다. PR 본문, 커밋 메시지, 자동 생성된 주석까지 포함해서. Copilot 사건이 남긴 교훈은 '도구를 믿되 검증하라'는 것이다.
둘째, 배포 전 5분 보안 체크를 습관화하라. grep -r "sk_live|AKIA|sk-proj" .로 하드코딩된 키를 확인하고, .gitignore에 .env가 있는지, CORS가 *로 열려 있지 않은지—이 세 가지만으로도 가장 흔한 재앙을 막을 수 있다.
셋째, 프롬프트 전에 브리프를 써라. '무엇을 만들 것인가'보다 '어떤 문제를 푸는가, 누구를 위해, 실패 시나리오는 무엇인가'를 먼저 5분 써두면 30분의 무의미한 이터레이션을 줄인다. Vibe Coding이 빼앗아간 강제적 사고 시간을 의식적으로 되돌려놓는 작업이다.
전망: 판단력이 새로운 기술 스택이다
AI 코딩 도구는 계속 좋아질 것이다. 구현 비용은 계속 낮아질 것이고, 더 많은 사람이 더 빠르게 무언가를 만들어 배포할 것이다. 그 흐름 자체를 거스를 이유는 없다.
다만 그 안에서 차별화되는 개발자는 '더 빠르게 만드는 사람'이 아니라 '만들어야 할 것을 정확히 아는 사람', '도구의 출력을 비판적으로 읽는 사람', '사용자 신뢰를 구조로 설계하는 사람'이 될 것이다. Vibe Coding은 코드를 민주화했지만, 판단력은 민주화하지 못했다. 그리고 그 판단력이야말로 지금 가장 희소한 기술 스택이다.