바이브 코딩이 유행처럼 번지고 있다. 'Enterprise AI Seoul 2026'에서도 AI 에이전트와 바이브 코딩의 확산이 기업 운영 전반을 바꾸고 있다는 발표가 나왔다. 도구는 그 어느 때보다 강력하고, 진입 장벽은 낮아졌다. 그런데 이상하게도 결과물의 품질은 기대만큼 올라가지 않는다. 프롬프트를 잘 못 써서일까? 모델이 부족해서일까? 나는 그 원인이 더 앞 단계에 있다고 본다.
AI가 수렴시키는 것은 텍스트가 아니라 사고다. PNAS Nexus에 실린 연구는 이 문제를 데이터로 증명했다. 인간 102명과 LLM 22개에게 동일한 창의성 과제를 냈을 때, 개별 AI의 답변 수준은 평균적인 인간과 비슷했다. 그런데 여러 모델의 답을 한자리에 모아 비교하면 AI들의 답이 인간들의 답보다 훨씬 더 닮아 있었다. ChatGPT를 쓰든 Claude를 쓰든 Gemini를 쓰든, 아이디어는 같은 곳으로 모였다. 각자 다른 도구를 쓴다고 믿는 동안, 생각은 조용히 한 방향으로 수렴하고 있었던 것이다.
이 현상은 프론트엔드 개발 현장에서 이미 체감되고 있다. v0.dev나 Cursor로 UI를 뽑아내면 레이아웃이 그럴듯하게 생성된다. 하지만 비슷한 프롬프트를 던진 팀들의 결과물은 놀랍도록 닮았다. 컴포넌트 구조, 카드 배치, 인터랙션 패턴—심지어 색상 팔레트까지. AI가 학습한 '평균적으로 좋아 보이는 UI'가 복제되고 있는 것이다. 이것이 단순한 미적 동질화로 끝나면 다행이다. 더 심각한 문제는 사용자 문제를 정의하는 사고 자체가 AI가 제시한 틀 안으로 수렴된다는 점이다.
와이어플로우를 그리며 배운 것. macOS 앱을 만들던 한 팀의 경험은 이 지점을 잘 보여준다. 와이어프레임과 플로우차트를 합친 와이어플로우를 제작하면서, 팀은 예상보다 훨씬 많은 결정의 기로에 섰다. '이 화면에서 다음 화면으로 넘어가는 방법이 사용자에게 명확히 전달되는가', '이 버튼의 역할을 사용자가 직관적으로 파악할 수 있는가', 'macOS에서는 꾹 누르는 제스처가 부자연스러운데 모바일 사고방식을 그대로 들고 오면 어떤 마찰이 생기는가'. 이런 질문들은 피그마 캔버스 위에서 모래시계 이모지로 쌓여갔다. 기술 구현을 주목적으로 시작했지만, 만들다 보니 사용자 경험을 고려하지 않을 수 없었다는 회고는 솔직하다. 사용자가 버튼을 클릭하지 않는다면 기능을 만든 의미가 없기 때문이다.
이 팀이 와이어플로우를 직접 설계한 과정—레이아웃을 스케치하고, 흐름의 단절을 발견하고, 팀 안에서 같은 단어가 다르게 해석되고 있음을 깨닫는 과정—이 바로 AI를 쓰기 전에 먼저 해야 할 일이다. AI는 이 단계를 생략하게 만드는 유혹을 제공한다. "일단 생성해보고 고치자"는 방식은 빠르게 시작할 수 있게 해주지만, 사고의 주도권을 AI에게 넘기는 대가를 치른다.
텍스터와 컨텍스터의 차이는 순서에 있다. 최홍규의 'AI 컨텍스터 선언' 시리즈는 이 문제를 날카롭게 구분한다. '텍스터'는 AI가 먼저 내놓은 답을 출발점으로 삼아 다듬는다. 결과물은 그럴듯해지지만 생각의 방향은 AI가 먼저 정했다. '컨텍스터'는 AI를 열기 전에 먼저 스스로 묻는다—이 전제가 맞는가, 다른 방향은 없는가, 아직 아무도 꺼내지 않은 질문이 있는가. 그 탐색을 마친 뒤 AI를 정리 도구로 불러들인다. 두 사람이 같은 AI를 써도 결과가 다른 이유가 여기에 있다. 순서가 다를 뿐이지만, 그 순서가 생각의 주인이 누구인지를 가른다.
프론트엔드 개발 맥락으로 번역하면 이렇다. v0.dev를 열기 전에 먼저 물어야 할 것들이 있다. 이 화면이 해결하려는 사용자 문제가 정확히 무엇인가. 사용자는 어떤 맥락에서 이 인터페이스를 만나는가. 이 컴포넌트의 상태 변화는 어떤 시나리오를 커버해야 하는가. 이 플로우에서 사용자가 길을 잃을 수 있는 지점은 어디인가. 이 질문들을 먼저 명문화한 뒤 프롬프트를 구성하면, AI는 평균의 답이 아니라 그 맥락에 맞는 답을 생성할 가능성이 높아진다. 컨텍스트가 없는 프롬프트는 평균을 소환하고, 컨텍스트가 정교한 프롬프트는 가능성의 범위를 좁혀준다.
설계 전치(前置)가 만드는 차이. 실무에서 이것은 구체적인 습관으로 구현된다. 컴포넌트를 생성하기 전에 사용자 시나리오를 한 문단으로 적는다. 와이어플로우를 손으로 먼저 스케치하고 흐름의 단절을 찾는다. 팀원들과 같은 단어가 다른 의미로 해석되는 지점을 미리 짚어낸다. 이 과정은 느려 보이지만, AI 생성 이후에 반복적으로 수정하는 비용보다 훨씬 작다. 와이어플로우 팀이 피그마 코멘트로 미결 사항을 모두 적어두고 처리한 것처럼, '해결되지 않은 질문을 가시화하는 것' 자체가 AI 협업의 품질을 높이는 설계 행위다.
바이브 코딩의 진짜 문제는 '코딩 속도'가 아니다. 문제 정의 없이 생성 속도만 올릴 때, 우리는 더 빠르게 잘못된 방향으로 달려간다. AI가 만들어주는 UI는 그럴듯하지만, 그 UI가 해결하려는 문제가 처음부터 흐릿했다면 정교한 컴포넌트도 사용자에게 무의미하다. 발명은 평균 밖에서 시작된다. AI가 아직 패턴으로 굳히지 못한 곳, 학습 데이터가 희박한 문제의 틈새—그곳은 AI가 먼저 제시할 수 없는 영역이다. 그 영역을 먼저 탐색하는 것이 컨텍스터의 일이고, 프로덕트를 진짜로 설계하는 사람의 일이다.
AI 도구는 계속 강력해질 것이다. 그럴수록 '무엇을 생성할지'보다 '왜 이것을 만드는가'를 먼저 명확히 하는 사람의 가치가 역설적으로 올라간다. 오늘 AI에게 던진 첫 프롬프트를 떠올려보라. 입력하기 전에 먼저 스스로 물어본 것이 있었는가. 있었다면, 우리는 AI를 도구로 쓴 것이다. 없었다면, 우리가 만든 결과물의 방향은 처음부터 AI가 정한 것이다.