Vibe Coding의 기원

당신이 코드의 모든 줄을 수동으로 작성하는 것을 멈추고, Large Language Model (LLM)이 당신의 생각을 완성하도록 Tab 키를 누르기 시작한 정확한 날을 기억하시나요? 2024년과 2025년 초 사이 어느 시점에, 소프트웨어 개발은 전례 없는 문화적 돌연변이를 경험했습니다. 우리는 엄격한 구문(syntax)과 세심한 시스템 설계의 경직성에서 벗어나, 순수하고 직관적인 흐름(flow)의 상태로 넘어갔습니다. Tesla의 전 AI 디렉터이자 OpenAI의 공동 창립자인 Andrej Karpathy는 이 현상에 확정적인 이름을 붙였습니다: Vibe Coding.

_Vibe Coding_은 이성적인 설계와 세심한 코드 작성을 통해서가 아니라, AI 어시스턴트와의 직관적인 상호작용을 통해 소프트웨어를 개발하는 행위로 정의됩니다. 이 패러다임에서 프로그래머는 더 이상 텍스트 파일에 로직을 옮겨 적는 필기자가 아닙니다. 대신 시스템의 동작에 대한 자신의 "바이브(vibe)"와 느낌에 주로 의존하여 결과를 경험적으로 평가하는 오케스트라 지휘자가 됩니다.

가속화된 생산성의 환상

언뜻 보기에 _Vibe Coding_은 초능력처럼 느껴집니다. TypeScript로 Express 서버를 설정하거나, 복잡한 SQL 쿼리를 구조화하거나, 외부 API를 위한 통합 _boilerplate_를 작성하는 등 이전에는 몇 시간이 걸리던 작업들이 이제는 간단한 prompt 하나로 몇 초 만에 해결됩니다. 개발 속도가 급등하면서, 개인 개발자(indie hackers)와 소규모 팀은 이전에 볼 수 없었던 짧은 시간 안에 제품을 시장에 출시할 수 있게 되었습니다.

하지만 이러한 초기 속도는 위험한 인지적 함정을 숨기고 있습니다. 생성되는 내용의 기초를 이해하지 못한 채 에이전트형 도구(agentic tools)와 대화형 모델에 코드 작성을 위임할 때, 우리의 비판적 추론 능력은 감소합니다. 우리는 코드를 매우 빠르게 생성하지만, 장기적인 유지보수성(maintainability)은 미지수인 블랙박스에 의존하게 됩니다.

반응형 프롬프팅 (Reactive Prompting)의 악순환

_Vibe Coding_의 전형적인 사이클은 세 가지 반복적인 단계로 구성됩니다:

1. 프롬프트 작성: "이 API에 JWT 인증을 추가해줘".
2. 실행 및 관찰: Localhost에서 엔드포인트(endpoint)를 테스트합니다. 한 번에 작동하면 계속 진행합니다.
3. 오류에 반응: 오류가 발생하면 에러의 스택 트레이스(stack trace)를 복사하여 LLM에 다시 붙여넣고 다음과 같이 요청합니다: "이것 좀 고쳐줘".

이러한 반응형 접근 방식은 빠른 프로토타이핑과 작은 개인 프로젝트에는 완벽하게 작동합니다. 하지만 실제적인 아키텍처(architecture) 전략이 결여되어 있으며, 이는 규제되지 않은 현대 소프트웨어 개발의 가장 큰 위험 요소인 _Frankenstein code_로 우리를 직접 인도합니다.

Frankenstein Code의 위험성

Frankenstein code(프랑켄슈타인 코드)라는 용어는 응집력 있는 아키텍처 설계 없이, AI가 생성한 코드 조각들을 무질서하게 축적하고 서로 기워 붙여 만들어진 코드베이스를 설명합니다. 개별 조각들은 각각 즉각적인 문제를 해결할 수 있을지 모르지만, 전체 시스템은 통합된 비전이 결여되어 있습니다.

_Vibe Coding_의 영향 아래 프로젝트가 성장함에 따라, 다음과 같은 심각한 기술적 부채(technical debt) 증상들이 나타나기 시작합니다:

• 스타일 및 패턴의 불일치: AI 어시스턴트가 한 파일에서는 함수형 프로그래밍(functional programming)을 제안하고, 다른 파일에서는 객체 지향 프로그래밍(object-oriented programming)을 제안하거나, 동일한 유형의 문제를 해결하기 위해 중복된 라이브러리를 섞어서 사용할 수 있습니다.
• 극단적이고 의도치 않은 결합(Coupling): 구조화된 설계가 존재하지 않기 때문에, LLM은 저항이 가장 적은 경로로 문제를 해결하려는 경향이 있으며, 이 과정에서 모듈을 불필요하게 결합하고 단일 책임 원칙(single responsibility principle)을 깨뜨립니다.
• 에이전트의 컨텍스트 맹목(Context Blindness): 코드베이스의 크기가 AI 어시스턴트의 유효한 컨텍스트 윈도우(context window)를 초과하면, 에이전트는 인터페이스를 지어내거나, 기존 함수를 중복 생성하거나, 이전 반복(iteration)에서 이미 해결된 버그(bug)를 다시 도입하기 시작합니다.

그 결과는 다루기 힘든 시스템이 됩니다. 즉, 팀 내의 인간 구성원 중 누구도 완전히 이해하지 못하며, AI 어시스턴트조차 다른 세 가지 기능을 망가뜨리지 않고서는 더 이상 수정할 수 없는 취약한 코드베이스 (codebase)가 만들어집니다.

엔지니어링으로의 회귀

_Vibe Coding_은 소프트웨어 개발에 대한 접근성을 민주화하고 코딩의 가장 단조로운 작업들로부터 우리를 해방시킴으로써 역사적인 이정표를 세웠습니다. 하지만 2024년의 초기 열광은 기술적 방향성 없는 속도가 코드의 파산으로 가는 가장 빠른 길임을 우리에게 가르쳐 주었습니다.

인공지능 (AI) 시대에 확장 가능하고(scalable), 안전하며, 유지보수가 가능한 (maintainable) 소프트웨어 시스템을 구축하기 위해서는 오직 "느낌 (vibes)"에만 의존할 수 없습니다. 우리는 엄격함 (rigor), 품질 관리 (quality control), 그리고 형식적 명세 (formal specifications)를 도입해야 합니다. 이 시리즈의 다음 포스트들에서는 산업계가 이러한 혼돈에 어떻게 대응해 왔는지, 즉 견고한 평가 인프라 (evaluation infrastructures), 명세 기반 개발 (specification-driven development), 그리고 최종적으로는 _Guardrails_와 _Agentic TDD_에 의해 엄격하게 제한되면서도 완전히 자율적인 에이전트 시스템 (agentic systems)으로 진화하는 과정을 탐구할 것입니다.