최근 요즘 IT에서 아티클을 많이 보고 있는데, 꽤나 공감하는 포인트를 마주해서 이야기해볼까 한다.
요즘IT바이브 코딩의 진짜 시작은 이제부터다 | 요즘IT
바이브 코딩의 진짜 시작은 이제부터다 | 요즘IT
꽤 그럴듯한 환상이었습니다. 아이디어를 설명하면 AI가 코드를 만들어줍니다. 프로젝트에 붙여 넣고 브라우저를 새로고침하면, 앱이 돌아갑니다. CS 학위도, Stack Overflow를 뒤질 일도, 새벽 2시에 디버깅할 일도 없었죠. 바이브만 있으면 됐습니다. 이 환상에는 이름도 있었습니다. 바이브 코딩(vibe coding)입니다. 모든 줄을 이해하지 못해도 AI가 생성한 코드를 그대로 받아들이는, "바이브에 완전히 몸을 맡기는" 개발 방식을 뜻했습니다. Collins 사전은 이 단어를 2025년 올해의 단어로 선정하기도 했죠. 그리고 14개월이 지난 지금, 후폭풍이 오고 있습니다.
사람들이 바이브 코딩 바이브 코딩 할 때마다 좀 답답했던 게 있었는데. 기분대로 바이브를 타는 게 아니라, 결국 구조화가 먼저라는 얘기를 제대로 하는 글을 드디어 봤다.
바이브 코딩은 자연어가 아니라 구조화
바이브 코딩은 개발 지식이 없는 비개발자도 자연어로 개발한다는 메타로 최근 1-2년간 뜨거웠지만, 사실 바이브 코딩의 핵심은 자연어가 아니라고 생각한다. 자연어로 정리하더라도, 결국은 요구사항을 구조화해서 명확하게 정의하는 게 핵심이다. 프롬프트가 자연어일 뿐이지, 기획-디자인-개발 모든 프로세스가 딸깍으로 모두 대체 가능한 건 아니다. 어떤 요구사항을 어떻게 개선할건지, 동작의 우선순위는 뭔지. 기획자의 문서와 개발자의 로직 설계는 여전히 유효하다고 믿고 있다.
흔히들 프롬프트 한 줄로 프로덕트를 만들 수 있다는데 매몰되어있지만, 프로덕트로서 기능하기 위해서는 결국 설계부터 단단한 정책과 인프라까지 운영 레벨까지는 멀고도 험한 여정이 기다리고 있다.
나는 바이브 코딩을 할 때 ERD와 핵심 유저 플로우를 먼저 정의하고, 기능을 1-2문장으로 정리하고, 기술스택을 확정한 뒤에 코드를 만들고 있다. 기획도 개발도 아이데이션부터 구현까지 End-to-End로 AI와 함께할 뿐 기존의 프로덕트 개발 사이클과 달라지지 않았다. 이 블로그를 만들 때도 노션 CMS DB 스키마부터 설계하고 Claude Code를 켰다. 순서가 바뀌면 나중에 뜯어고치는 비용이 생긴다.
기능은 AI가 기준은 내가
아티클이 짚는 핵심은 명확하다. 바이브 코딩의 문제는 속도가 아니라 설계 없이 달렸다는 것. AI는 기능을 만들어내는 속도가 사람보다 빠르고, 같은 문제를 여러 방식으로 풀어낼 수도 있다. 근데 어떤 범위에서 어떤 권한으로 움직여야 하는지는 AI가 스스로 정의하지 못한다. 최근, 그걸 정의하지 않은 채 에이전트를 풀어놓았을 때의 위험성을 실감할 수 있는 사건을 본 적이 있다.
올해 4월 25일. Cursor(Claude Opus 4.6 기반)가 카렌터 SaaS 스타트업 PocketOS의 프로덕션 DB를 9초 만에 삭제했다. 스테이징 환경에서 루틴 작업을 하다가 credential mismatch를 만났고, 에이전트는 스스로 판단해서 문제를 "해결"했다. 백업도 같은 볼륨에 저장돼있어서 같이 날아갔다. 복구 가능한 가장 최근 백업은 3개월 전 것. 창업자가 설명을 요청하자 에이전트는 이렇게 답했다.
"나는 내게 주어진 모든 원칙을 위반했다. 확인하지 않고 추측했다. 요청받지도 않은 파괴적 행동을 실행했다."
자백은 완벽했다. 실행 전엔 아무것도 멈추지 않았으면서.
PocketOS 사건을 AI 위험성으로 읽으면 안 되는 이유
근데 이걸 AI의 위험성으로 읽으면 본질을 놓치기 쉽다. AI가 무서운 이유가 아니라, 정책이 미비했을 때 발생할 수 있는 이슈라는 걸 먼저 짚어야 한다. 이건 그냥 보안 사고다. 권한을 분리했어야 하는데 분리를 안 했고, 권한을 가진 에이전트의 실수로 삭제됐고, 막는 단계가 없었다. 사람이 깜빡 졸면서 같은 실수를 했어도 결과는 똑같았을 일이다. AI를 도입해서 생긴 문제가 아니라, 보안 정책이 모호하고 미비해서 생긴 문제다.
나도 비슷한 경험이 있다. 초기 설계 단계에서 MCP로 노션 데이터베이스 생성/프로퍼티 수정 작업하다가 row 하나 지워달라고 했더니 클로드가 DB 전체를 삭제했다. 클로드는 망설이지 않았다. 확인창도 없었고,
Notion-fetch 와 같이 API 호출 UI가 몇번 깜빡이고, 삭제하겠다더니 페이지 1개가 아니라 데이터베이스를 지웠을 뿐. 복구 버튼을 누르면서 깨달은 건 하나였다. 에이전트가 닿을 수 있는 범위를 내가 먼저 제어하지 않았다는 것.정책과 설계는 여전히 유효하다
바이브 코딩이 운영/프로덕션 레벨에서도 유효하려면, 설계와 정책, 에이전트의 접근 권한을 먼저 정의해야 한다. 기능을 구현하는 건 AI가 사람보다 빠르고 여러 버전의 방법을 찾아낼 수 있다. 하지만 권한이나 보안 체계의 원칙을 세우는 기준이 없다면, 프로덕트의 근간을 흔드는 위험한 결정을 내리는 걸 지켜보기만 하게 될 수도 있다.
요즘 린트로 AI가 실행하면 안 되는 명령을 사전에 제한해두는 방식이 많이 나오고 있다. 결국 같은 맥락이다. 정책 → 설정 → 구조화 → 설계 → 실행. AI를 이용한다고 해서, 원래 프로덕트를 만들 때 신경 쓰던 걸 안 써도 되는 게 아니다. 오히려 에이전트는 사람보다 빠르고 주저하지 않으니까, 제약 조건을 더 촘촘하게 설계해야 한다.
우리가 가야할 길
요즘은 작업의 병목이 사람이라는 목소리가 나오고 있지만, 병목이 될지언정 더 나은 길로 가고싶다. 개인 작업을 할 땐 좀 날려먹고, 프롬프트를 두어번 더 입력해가며 시행착오를 겪는 것도 재미있는 경험이지만, 업무 환경에서는 겪고 싶지 않으니까.
여전히 정책과 설계가 프로덕트의 근간이 된다는 생각이 혼자만의 생각이 아니라는데서 약간의 위안을 얻었다. 누군가는 AI가 일자리를 대체할까 걱정하고, 누군가는 AI가 다해주니까 딸깍만 하면 되지 않냐고 말하는 세상에서 여전히 AI는 도구이고, 방식이라고 정의하는 사람들을 더 많이 만나고 싶다.
갖가지 제약 조건과 원하는 방향성을 종합해서 최선의 솔루션을 만들어가는 것. 이 시대에 필요한 프로덕트 메이커의 자질이 달라진 게 아니다. 아직은 여전히 우리들의 몫이 남아있으니 열심히 해보자고요.