들어가며: GPT가 사람보다 코딩을 잘한다는 건 부정할 수 없는 사실이다

요즘 GPT나 Claude 같은 AI가 사람보다 코드를 더 잘 짠다는 이야기가 심심찮게 나온다. 이건 부정할 수 없는 사실이다. 사람이 알고리즘과 아키텍처를 하나하나 고민하며 설계하는 것과 달리, AI는 이미 방대한 양의 코드와 설계 패턴을 학습한 상태에서 답을 내놓는다. 학습량과 처리 속도 면에서 인간이 AI를 따라잡기 어려운 건 어쩌면 당연한 결과다.

문제는 그다음이다. 이 사실을 근거로 "아이디어만 있으면 뭐든 만들 수 있는 시대"라는 말이 퍼지면서, 소위 바이브 코딩(Vibe Coding)이 하나의 흐름으로 자리 잡았다. 나는 이 흐름 자체를 부정하지는 않지만, "아이디어만 있으면 개발자 없이도 뭐든 만들 수 있다"는 주장에는 동의하지 않는다. 이 글에서 그 이유를 정리해보려 한다.

이 글에서 다루는 핵심은 세 가지다.

1. AI는 결국 '다음에 올 답'을 예측하는 알고리즘이라 결과물이 서로 비슷해질 수밖에 없다.
2. 바이브 코더는 눈에 보이는 결과물만 볼 뿐, 보안과 인프라는 들여다보지 않는다.
3. 디자인 감각은 데이터 양만으로 채워지지 않는다.

바이브 코딩이란 무엇인가

바이브 코딩이라는 용어는 OpenAI 공동 창립자이자 전 테슬라 AI 총괄이었던 안드레이 카파시(Andrej Karpathy)가 2025년 2월 처음 제안한 말이다. 코드를 한 줄씩 직접 작성하는 대신, 자연어로 원하는 것을 설명하면 AI가 코드를 생성하고 사람은 그 결과를 보고, 실행하고, 다시 요청하는 방식으로 개발을 이어가는 것을 뜻한다. 이 말은 등장한 지 한 달 만에 메리엄-웹스터 사전에 "속어 및 트렌드" 명사로 등재될 정도로 빠르게 퍼졌다.

이제는 코딩을 전혀 몰라도 아이디어 하나만 있으면 서비스를 만들어 배포할 수 있는 시대라고들 말한다. 실제로 많은 개발자가 AI 코딩 도구를 일상적으로 쓰고 있고, 그 생산성 향상 자체를 부정할 생각은 없다.

하지만 좋은 아이디어를 가지고 바이브 코딩을 시켜도, 결과적으로는 다른 사람들과 비슷한 디자인, 비슷한 구조, 비슷한 결과물이 나오는 경우가 대부분이다. 심지어 서로 다른 모델(GPT, Claude, Gemini 등)에 같은 아이디어를 넣고 돌려봐도 마찬가지다. 왜 이런 일이 벌어질까?

이유 1: AI는 결국 '다음에 올 답'을 예측하는 알고리즘이다

이걸 이해하려면 먼저 거대 언어 모델(LLM)의 작동 구조를 알아야 한다.

LLM은 사용자가 어떤 입력을 주면, 그 입력 뒤에 이어질 확률이 가장 높은 다음 단어(토큰)를 순차적으로 예측해서 문장을 만들어내는 알고리즘이다. 코드를 생성할 때도 마찬가지다. "이런 기능을 만들어줘"라는 요청이 들어오면, 모델은 학습 과정에서 봤던 수많은 코드 중 그 요청과 가장 유사한 맥락에서 가장 등장 확률이 높았던 패턴을 조합해 답을 내놓는다. 창작이 아니라 예측인 것이다.

문제는 대부분의 상용 AI 모델이 비슷한 공개 데이터(깃허브, 스택오버플로, 오픈소스 저장소 등)로 학습한다는 점이다. 그래서 서로 다른 회사가 만든 서로 다른 모델이라도, 결국 "가장 흔하고 무난한" 패턴으로 수렴하는 경향을 보인다. 최근 이런 현상을 두고 업계에서는 AI 슬롭(AI Slop)이라는 표현을 쓰기도 한다. 브랜드나 맥락에 대한 별도 지침 없이 "대시보드를 만들어줘"라고만 요청하면, 모델은 인터넷에서 가장 흔한 UI 패턴 보라색 그라디언트 버튼, 카드형 레이아웃, 특별한 이유 없는 호버 애니메이션으로 수렴한다는 것이다. 이걸 흔히 평균의 함정이라고 부른다. 학습 데이터 전체의 평균적 패턴을 내재화한 모델은, 별도의 지시가 없는 한 언제나 가장 무난하고 평균적인 답을 내놓을 수밖에 없다.

정리하면, AI는 창의적으로 "새로운 것"을 상상해서 만들어내는 게 아니라 이미 존재하는 것들 중 가장 그럴듯한 조합을 예측해서 보여줄 뿐이다. 그래서 "아이디어만 있으면 개발자를 이길 수 있다"는 말은 반은 맞고 반은 틀렸다. 아이디어를 실행 가능한 결과물로 빠르게 옮기는 속도는 AI가 압도적으로 빠르지만, 그 아이디어를 독창적인 결과물로 완성하는 몫은 여전히 사람에게 달려 있다.

결국 바이브 코딩이라는 방식 자체가 이 구조를 바꾸는 건 아니다. 방법이 달라졌을 뿐, 뼈대는 AI가 예측해서 짜낸다는 사실은 그대로다.

이유 2: 바이브 코더는 보안과 인프라를 보지 않는다

두 번째 이유는 더 현실적이다. 바이브 코더 대부분은 화면에 보이는 결과물만 보고 배포를 결정할 뿐, 그 뒤에 숨어 있는 보안·인증·인프라 구조는 자세히 들여다보지 않는다.

이건 이제 막연한 우려가 아니라 여러 보안 조사기관의 데이터로도 확인되는 사실이다.

• 보안 업체 Veracode가 100개 이상의 LLM을 대상으로 진행한 테스트에서, AI가 생성한 코드 중 약 45%가 OWASP 보안 기준을 통과하지 못했다.
• 스탠퍼드 대학교 연구팀의 통제 실험에서는, AI 코딩 어시스턴트를 사용한 참가자들이 보안이 중요한 과제에서 오히려 더 취약한 코드를 작성했음에도, 자신의 코드가 더 안전하다고 믿는 경향을 보였다.
• 보안 기업 Escape.tech가 실제로 배포된 바이브 코딩 기반 애플리케이션을 대규모로 스캔한 결과, 다수의 애플리케이션에서 치명적인 취약점과 함께 400건이 넘는 노출된 비밀 키(API 키 등), 175건의 개인정보 노출 사례가 발견됐다.
• 노코드/바이브 코딩 플랫폼 Lovable로 만들어진 앱들 중 상당수가 데이터베이스 접근 제어 설정 실수로, 인증 없이 누구나 데이터를 조회할 수 있는 상태로 방치되어 있었던 사례(CVE-2025-48757)도 있었다.

실제로 배포 플랫폼(Vercel 등)의 서브도메인으로 구글에 검색해보면(site:vercel.app), 비슷한 실수를 반복한 사이트들을 어렵지 않게 찾아볼 수 있다. 겉보기엔 멀쩡하게 작동하는 것 같아도, 인증 로직이 허술하거나 환경 변수가 그대로 노출된 경우가 적지 않다.

바이브 코더가 이런 문제를 놓치는 이유는 단순하다. AI는 "요청한 기능이 동작하는가"에 최적화되어 답을 내놓을 뿐, "이 구조가 안전한가"를 스스로 검증하고 책임지지는 않는다. 이 부분은 여전히 설계자, 즉 사람의 몫으로 남아 있다.

"AI가 요구사항대로 됐는지 알아서 테스트하니까 상관없지 않나요?"

일리 있는 지적이지만, 여기에는 중요한 전제가 하나 빠져 있다.
AI가 테스트하는 대상은 어디까지나 "요구사항에 적힌 것"에 한정된다는 점이다. "로그인 기능을 만들어줘"라는 요구사항에는 보통 "로그인이 되는가", "잘못된 비밀번호를 넣으면 실패하는가" 정도만 담겨 있지, "무차별 대입 공격을 방어하는가", "세션 토큰이 안전하게 관리되는가", "환경 변수가 클라이언트에 노출되지 않는가" 같은 조건은 애초에 요구사항에 없는 경우가 대부분이다.

앞서 언급한 Veracode의 조사에서 AI가 생성한 코드 중 상당수가 기능적으로는 정상 동작하면서도 보안 기준은 통과하지 못했다는 결과가 바로 이걸 보여준다. 기능 테스트를 통과했다는 것과 안전하다는 것은 전혀 다른 이야기다.

더 근본적인 문제는, 코드를 생성한 모델과 그 코드를 검증하는 모델이 사실상 같은 학습 데이터와 같은 사고방식을 공유한다는 점이다. 이유 1에서 설명했듯 AI는 결국 학습 데이터 안에서 "그럴듯한 패턴"을 예측하는 알고리즘이다. 같은 원리로 작동하는 AI가 자기가 만든 코드를 검증한다고 해서, 애초에 그 모델의 사각지대에 있던 보안 취약점을 스스로 발견해낼 가능성은 낮다. 자기가 놓친 것을 자기가 다시 찾아내기는 어려운 것과 같은 이치다.
실제로 스탠퍼드 연구에서 AI 코딩 어시스턴트 사용자들이 더 취약한 코드를 작성하고도 오히려 자신의 코드가 안전하다고 믿었다는 결과도, 이런 자기검증 구조의 한계와 무관하지 않다.

결국 "요구사항대로 됐는지"를 판단하는 기준, 즉 무엇을 테스트해야 하는가를 정의하는 일 자체가 사람의 몫이다. AI는 주어진 정의 안에서는 꼼꼼하게 검증할 수 있지만, 그 정의 밖에 있는 위협 아직 아무도 요구사항에 적지 않은 위협까지 스스로 상상해서 채워 넣지는 못한다. 보안은 대체로 "이런 것까지 노려질 줄은 몰랐다"는 지점에서 뚫린다는 걸 생각하면, 이 한계는 결코 가볍지 않다.

여기서 한 걸음 더 나아가 이런 반론도 가능하다. "그럼 사람이 보안 체크리스트를 하나하나 직접 알려주고, AI에게 그 항목들을 전부 테스트해보라고 시키면 되는 것 아니냐?"
이 방법이 앞서의 반론보다는 분명 나은 접근이다. 실제로 OWASP Top 10 같은 체크리스트를 주고 검증을 맡기면, 아무 지시 없이 맡기는 것보다 훨씬 안전한 결과를 얻을 수 있다. 하지만 이것도 근본적인 한계에서 벗어나지는 못한다.

첫째, 체크리스트는 결국 "이미 알려진 위협"의 목록일 뿐이다. OWASP Top 10이든 어떤 보안 가이드든, 그 안에 담긴 항목들은 과거에 이미 발생했거나 널리 알려진 취약점 유형이다. 하지만 실제 보안 사고의 상당수는 그 서비스만의 특수한 비즈니스 로직, 특정 도메인의 맥락, 여러 기능이 얽히면서 생기는 예상치 못한 조합에서 터진다. 이런 건 애초에 체크리스트에 항목으로 존재하지 않기 때문에, 아무리 꼼꼼히 체크리스트를 훑어도 걸러지지 않는다.

둘째, 결국 "무엇을 체크리스트에 넣을지"를 판단하는 것도 사람의 몫이다. 이 서비스에 어떤 위협이 특히 치명적인지, 어떤 항목을 우선순위로 둬야 하는지를 결정하려면 그 서비스의 구조와 맥락을 이해하고 있어야 한다. AI에게 "이것도 테스트해봐, 저것도 테스트해봐"라고 지시하는 사람의 보안 지식과 상상력의 범위가, 결과적으로 그 검증의 한계선이 되는 셈이다. 즉 체크리스트를 만든다고 해도, 그 체크리스트의 완성도 자체가 다시 사람의 역량에 달려 있다.

정리하면, AI에게 구체적인 보안 항목을 하나하나 지정해서 테스트를 맡기는 건 분명 유효한 보완책이지만, 그 자체가 "AI에게 보안을 통째로 맡겨도 된다"는 근거는 되지 못한다. 무엇을 테스트해야 하는지 아는 것, 그리고 아직 아무도 정의하지 않은 위협을 상상하는 것. 이 두 가지는 여전히 AI가 대신할 수 없는 사람의 영역이다.

이유 3: 디자인 감각은 데이터 양만으로 채워지지 않는다

세 번째 이유는 디자인이다. AI가 만든 사이트들을 보면 화려한 그라디언트, 과도한 호버 이펙트, 비슷한 카드 레이아웃 등 서로 다른 서비스인데도 묘하게 닮아 있는 경우가 많다. 실제로 이런 현상을 풍자하는 "Every AI-Coded Website Ever"라는 패러디 프로젝트까지 등장했을 정도로, 개발자들 사이에서는 이미 공공연한 농담거리가 됐다. 패러디 프로젝트 보러가기

바이브 코더는 이런 결과물을 보고 "잘 만들어졌다, 이 정도면 사람들이 많이 쓰겠지"라고 생각하기 쉽다. 하지만 실제로 서비스를 사용하는 사람들의 반응은 다르다. AI가 만든 듯한 뻔한 디자인과 구조에 오히려 피로감을 느낀다는 이야기가 커뮤니티 곳곳에서 나오고 있다.

예상되는 반론: "그럼 AI에게 보안과 다양한 디자인을 대량으로 학습시키면?"

이 글을 읽고 이런 반론을 떠올릴 수도 있다. "결국 데이터의 문제라면, AI에게 더 다양한 보안 사례와 디자인 패턴을 학습시키면 해결되지 않을까?"

나는 이 역시 근본적인 해결책은 아니라고 생각한다. 앞서 설명했듯 LLM은 학습한 데이터를 바탕으로 가장 그럴듯한 다음 답을 예측하는 모델이다. 아무리 많은 데이터를 학습시켜도, 모델은 결국 학습 데이터의 분포 안에서 보간(interpolation)할 뿐이지, 그 분포 밖에서 전혀 새로운 관점을 창조하지는 못한다. 그리고 당신이 떠올린 참신한 아이디어도, 이미 다른 누군가가 비슷한 생각으로 바이브 코딩을 시도해봤을 가능성이 크다. AI 입장에서는 그 아이디어조차 학습 데이터 속 어딘가에 있는 익숙한 패턴일 뿐이다.

사람마다 다른 개인적 취향, 자라온 배경, 특정 도메인에 대한 깊은 이해에서 나오는 주관적 판단은 통계적 평균으로 환원되지 않는다. 이건 데이터를 더 많이 넣는다고 해결될 문제가 아니라, 통계적 예측이라는 구조 자체의 한계에 가깝다.

그래서 우리는 AI를 어떻게 대해야 할까

여기까지 읽으면 내가 AI를 부정하는 입장이라고 오해할 수도 있겠다. 전혀 그렇지 않다.

내가 하고 싶은 말은, 아이디어만 있다고 해서 코딩과 디자인과 보안까지 전부 AI에게 통째로 맡겨버리는 태도가 위험하다는 것이다. 대신 내가 가진 아이디어와 판단을 중심에 두고, 모르는 부분이나 손이 많이 가는 반복 작업이 있을 때 AI에게 물어보고 도움을 받는 '도구'로 활용하는 것. 나는 이것이 지금 이 시대에 개발자가 가져야 할 바람직한 태도라고 생각한다.

AI는 속도를 압도적으로 높여주는 훌륭한 협업자다. 하지만 무엇을 만들지, 어떻게 안전하게 만들지, 어떤 인상을 남길지를 결정하는 최종 책임은 여전히 사람에게 있다. 그 경계를 분명히 하는 것이, AI 시대를 살아가는 개발자에게 가장 필요한 자세가 아닐까.

참고 자료

• Wikipedia, 「바이브 코딩」
• IBM Think, "Vibe Coding Security Risks Aren't Like Ordinary Security Risks"
• Cloud Security Alliance Research Note, "AI-Generated Code Security & Vibe Coding"
• Axis Intelligence, "Vibe Coding Statistics 2026"
• BeyondScale, "Vibe Coding Security Risks: Enterprise Guide 2026"
• Museum of Vibe Coding, "Vibe Coding Security: Complete Record"
• braindetox.kr, "Atlassian DESIGN.md — AI가 이해하는 이식 가능한 디자인 컨텍스트 2026"