바이브 코딩 (Vibe Coding)이 문제가 아닙니다. 스택 (Stack)을 이해하지 못하는 것이 문제입니다.

AI 코딩 도구가 거의 수정하지 않고 저에게 건네준 설정 파일입니다:

DATABASE_URL = "postgresql://admin:SuperSecret123@db.internal:5432/app"
API_KEY = "sk-live-4f9a..."   # 저장소(repo)에 그대로 커밋됨

이것은 실행됩니다. 그것이 바로 모든 문제입니다. 실행이 되고, 데모가 작동하며, 리뷰어가 고개를 끄덕이면, 그 비밀 정보는 이제 당신의 git 히스토리에 영원히 남게 되며, 팀의 모든 구성원과 저장소를 해킹하는 누구라도 읽을 수 있게 됩니다.

저는 개발자가 아닙니다. 시스템 엔지니어링 분야에서 20년을 보냈지만, 실제 애플리케이션을 출시해 본 적도 없고, 프로덕션 코드베이스 (production codebase)를 소유해 본 적도 없으며, 파일을 옮기는 것 이상의 셸 스크립트 (shell script)를 작성해 본 적도 거의 없습니다. 제가 그동안 구축해 온 것은 애플리케이션이 실행되는 기반, 즉 호스트 (hosts), 네트워크 (network), 데이터베이스 (databases), 배관 (plumbing)과 같은 것들이었습니다. 그래서 AI 코딩 도구들이 등장하고 제가 다시 무언가를 만들기 시작했을 때, 왜 저의 경험이 사람들이 게시하는 실패 사례들과 전혀 다르게 느껴지는지 파악해야 했습니다.

Andrej Karpathy는 2025년 초에 "바이브 코딩 (vibe coding)"이라는 용어를 만들었으며, 이는 진심 어린 의미였습니다. 즉, 분위기 (vibes)에 몸을 맡기고, 코드를 보지 말고, 당신이 이해할 수 있는 수준을 넘어서까지 코드가 성장하게 두라는 것이었습니다. 그는 일회성 주말 프로젝트를 설명하고 있었던 것입니다. 인터넷은 "코드가 존재한다는 사실을 잊어라"라는 부분만 남겨둔 채, 이를 조용히 "시스템이 존재한다는 사실을 잊어라"로 업그레이드했습니다. 이 둘은 같은 것이 아닙니다. 코드는 무시할 수 있습니다. 하지만 시스템은 무시할 수 없습니다. 왜냐하면 시스템이 실제로 실행되고 있는 것이기 때문입니다.

모델이 볼 수 없는 것

아래의 모든 예시는 실제 세션에서 AI 도구가 저에게 제안했던 것들이며, 제가 이를 거부하고 수정했던 사례들입니다. 제가 모델보다 코딩을 더 잘해서가 아니라, 저는 이전에 그 계층 (layer)에 서 본 적이 있지만 모델은 그렇지 못했기 때문입니다.

모델은 보안 앱의 OS로 Windows를 제안했습니다. 기술적으로는 괜찮지만, 비용과 점유율 (footprint) 측면에서는 틀렸습니다. 무료 Ubuntu 서버가 더 가볍게 동일한 작업을 수행할 수 있음에도 불구하고 라이선스 비용이 드는 Windows Server 호스트를 제안한 것입니다. 모델은 청구서 (bill)에 대한 개념이 없습니다. 왜냐하면 청구서는 코드보다 한 단계 아래 계층에 존재하기 때문입니다.

모델은 데이터베이스로 MySQL을 선택했습니다. 기술적으로는 괜찮습니다. 하지만 이 시스템을 장기적으로, 그리고 대규모로 운영하는 사람은 바로 저이며, 저의 경험은 MySQL이 아닌 Postgres에 있습니다. 모델은 1년 뒤 새벽 2시에 이 시스템을 책임지는 사람이 누구인지 알지 못합니다. 제가 실제로 압박 속에서도 실행할 수 있는 엔진을 선택하는 것은 운영상의 결정(operational call)이며, 운영(operations)은 애플리케이션 코드에서는 보이지 않는 영역입니다.

모델은 인증 (auth) 기능을 연결하고 "로그인이 작동함" 단계에서 멈췄습니다. 작동하게 만드는 것은 쉬운 20%에 불과합니다. 보안이 강화된 버전은 Microsoft Entra ID (이전의 Azure AD)를 통한 단일 로그인 (SSO)과 조건부 액세스 (Conditional Access)로 제한된 환경을 의미합니다. 즉, "인증됨"이라는 의미는 단순히 유효한 토큰을 가진 누구나가 아니라, 신뢰할 수 있는 장치, 허용된 위치, 적절한 조건이 충족되었음을 의미합니다. 로그인 양식을 바이브 코딩 (vibe coding) 한다고 해서 조건부 액세스 (Conditional Access)를 발견할 수는 없습니다.

그리고 네트워킹 (networking) 문제입니다. 초기에는 항상 똑같이 자신만만하게 행동했습니다: 포트를 여는 것이죠.

# 연결을 작동하게 만드는 것
ufw allow 22                                 # SSH, 전체 인터넷에 개방

...

두 버전 모두 연결됩니다. 하지만 그중 하나만이 안전하며, 그 차이는 애플리케이션 계층에서는 보이지 않습니다. 그 차이는 네트워크에 존재하며, 모델은 이를 다른 사람의 문제로 취급합니다.

이는 모델이 하드코딩하려고 시도했던 비밀 정보 (secrets) 문제로 다시 돌아옵니다. 해결책은 복잡하지 않습니다. 단지 모델이 스스로는 도달하지 못하는 계층일 뿐입니다:

import os

DATABASE_URL = os.environ["DATABASE_URL"]
...

런타임 (runtime) 시점에 환경 변수에서 가져오거나, 실제 비밀 정보 저장소 (secrets store)에서 가져와야 합니다. 비밀번호는 해싱 (hashed) 처리하고, 키와 토큰은 암호화 (encrypted) 해야 하며, 그 어떤 것도 소스 제어 (source control)에 포함되어서는 안 됩니다. 더 잘 아는 누군가가 막지 않는 한, 모델은 이 모든 것을 저장소 (repo)로 향하는 파일 안에 인라인 (inline)으로 집어넣을 것입니다. 보통 그 누군가는 바로 저입니다.

아무것도 격리되어 있지 않다

아무것도 격리되어 있지 않다

스택(Stack)이 두 개의 상자로 이루어져 있지 않다는 것은 이미 알고 있을 겁니다. 프론트엔드(Frontend), 백엔드(Backend), API, 인증(auth), 데이터베이스(Database), 캐시(Cache), 오브젝트 스토리지(Object Storage), 큐(Queues), 리버스 프록시(Reverse Proxy), DNS 등 그 아래에는 수십 개의 레이어가 존재하며—각각 고유한 방식으로 실패하고 이웃들을 함께 무너뜨립니다. 이것이 바로 '번아웃된 바이브 코더(burned vibe coders)'들이 놓치는 부분입니다. 그들은 주로 애플리케이션 코드 자체를 잘못 작성하는 것이 아닙니다. 지금은 모델이 애플리케이션 코드에 능숙합니다. 그들이 실패하는 이유는 애플리케이션 코드가 곧 시스템이라고 생각하기 때문인데, 실제로는 자신들이 기초 공사를 한 번도 하지 못하고 볼 수 없는 건물 한 층일 뿐입니다. 그들 입장에서는 변화가 자체적으로 완결된 것처럼 보이지만, 아무것도 자체적으로 완결되어 있지 않습니다.

제가 기계와 논쟁하는 이유

제가 바이브 코딩(vibe code)을 할 때, AI는 애플리케이션 레이어를 작성하고 저는 그 아래의 모든 것을 여전히 구축하고 있습니다—그리고 더 중요한 것은, 저는 충분히 알고 있기 때문에 반박할 수 있다는 것입니다. 모델이 어떤 접근 방식을 선택하면, 저는 왜 그것을 선택했는지 물어보고, 명백한 대안이 더 나은지, 그리고 언급하지 않은 부분에서 무엇을 포기(trade away)하고 있는지 물어볼 수 있습니다. 스스로 추론해 볼 수 없었던 답변에 대해서는 의문을 제기할 수 없습니다. 이것이 경계선이며, 이는 개인이 얼마나 많은 코드를 직접 타이핑하는 것과는 아무 상관이 없습니다.

심지어 제가 시작하는 방식도 바꿉니다. 저는

이 중 그 어떤 것도 바이브 코딩 (vibe-coding)에 반대하는 것이 아닙니다. 이것은 제 커리어에서 처음으로 무언가를 구축하게 해주었으며, 다시 예전 방식으로 돌아가는 일은 없을 것입니다. 문제는 결코 바이브 (vibes)가 아니었습니다. 문제는 자신이 무엇을 건드리는지 보지 못하는 누군가가 만든, 독립적인 변경 사항이 자신이 화이트보드에 그릴 수도 없는 시스템으로 배포된다는 점입니다. 기초 (foundation)를 아는 사람에게 동일한 도구를 준다면, 그 기초야말로 바이브를 안전하게 따를 수 있게 만드는 바로 그 요소가 됩니다.

경계선은 재능이 아니며, 당신이 얼마나 많은 코드를 작성하느냐도 아닙니다. 그것은 당신의 코드가 딛고 서 있는 대상을 이해하고 있느냐의 여부입니다. 그 외의 모든 것은 그저 바이브일 뿐이며, 바이브는 무게감을 가질 수 없습니다.

당신이 계속해서 수행해야만 하는 오버라이드 (override)는 무엇입니까? 모델이 당신의 스택 (stack)에서 매번 틀리고 마는 바로 그 오버라이드 말입니다.

원문은 blog.vertexops.org에 게시되었습니다.