Vibe Coding

안녕하세요, MoonLight입니다.

​

이번 Post에서는 Vibe Coding(바이브 코딩)이란 용어에 대해서 알아보도록 하겠습니다.

 

 

 

1. 바이브 코딩(Vibe Coding)의 정의와 기원

바이브 코딩이란 개발자가 코드의 구문(Syntax)이나 저수준의 로직을 직접 입력하면서 SW를 개발하는 예전의 방식대신, 자연어를 통해 AI 에이전트에게 고수준의 아키텍처와 의도(Vibe)만을 전달하여 소프트웨어를 구축하는 새로운 개발 패러다임을 의미합니다.

​

LLM에게 '이런 이런 기능을 가진 어떤 SW를 개발하고자 한다. 언어는 뭘로 쓰고 어떤 기능이 필요하고, 어떤 제약사항이 있다.' 정도만 알려주면 LLM이 전체 Code를 알아서 작성해 준다는 개념입니다.

​

그럼 개발자는 이제 뭘하느냐?라고 생각하실 수 있으신데요, 개발자는 단순 Coding 작업에서 벗어나 좀 더 고수준의 업무에 역량을 집중할 수 있다는 의미입니다.

​

조금 더 자세히 알아보시죠.

​

 

 

기원

바이브 코딩이라는 용어는 2025년 2월, 전 Tesla AI 디렉터이자 OpenAI 공동 창립자인 안드레이 카파시(Andrej Karpathy)가 자신의 X(구 트위터)를 통해 처음 언급했다고 합니다.

​

그는 이를 "코드가 존재한다는 사실조차 잊어버리고 오직 AI와 상호작용하며 개발하는 상태"라고 묘사했습니다.

​

 

 

 

기존 AI 보조 도구와의 차이

단순히 GitHub Copilot의 자동 완성 기능을 사용해서 Code를 완성하거나, LLM이 작성한 Code 조각을 복붙해서 SW 개발하는 것이 바이브 코딩이 아닙니다.

​

AI가 파일 구조 전체를 수정하고, 개발자는 내부 로직을 일일이 검토하지 않고 출력 결과물(테스트 통과 여부, 기능 동작)만 확인한 뒤 다시 자연어로 피드백을 주는 '에이전틱 루프(Agentic Loop)' 형태의 작업 방식이 진정한 바이브 코딩이라고 할 수 있습니다.

​

​

​

 

2. 실제 작동 방식 및 아키텍처

바이브 코딩은 단순한 대화형 인터페이스를 넘어, 최근 IDE(통합 개발 환경)와 깊게 결합된 AI 에이전트(예: Cursor, Cline 등)를 통해서 적용할 수 있습니다.

​

이는 주로 LLM(대형 언어 모델), RAG(검색 증강 생성), 그리고 MCP(Model Context Protocol) 기술 등이 결합되면서 구현되는 것이죠.

​

 

AI 활용

​

 

작동 메커니즘

1) 컨텍스트 수집 (Context Gathering)

사용자가 프롬프트를 입력하면, IDE 내부의 AI가 RAG를 통해 현재 프로젝트의 전체 코드베이스, 종속성 파일, 최근 수정 기록 등을 벡터화하여 LLM의 컨텍스트 윈도우에 주입합니다.

​

2) 계획 수립 (Planning)

LLM은 요구사항을 분석하고, 수정해야 할 파일 목록과 논리적 단계를 스스로 수립합니다.

​

3) 다중 파일 동시 편집 (Multi-file Editing)

단일 함수가 아닌, 연관된 여러 파일(예: 메인 로직, 스키마, 테스트 코드)을 동시에 생성하거나 수정합니다.

​

4) 자동화된 피드백 루프 (Execution & Debugging)

코드를 실행하여 에러(Stack Trace)가 발생하면, AI가 터미널의 에러 메시지를 컨텍스트로 다시 읽어 들여 스스로 원인을 파악하고 코드를 재수정합니다.

​

​

 

실제 예제

​

실제 어떤 서비스를 개발한다고 할 때, 고전적 개발 방식과 바이브 코딩 방식의 워크플로우가 어떻게 달라지는 한 번 알아보도록 하겠습니다.

 

개발 단계	전통적 개발 (Before)	바이브 코딩 (After)
기획 및 준비	API 문서(부동산 데이터, 구글 맵)를 정독하고 데이터 구조를 설계함. 기술 스택(React, Vite 등)을 수동으로 설정.	"부동산 사이트 매물을 긁어와 가장 가까운 전철역까지 도보 시간을 계산해주는 사이트 만들어줘"라고 자연어로 명령.
초기 구축	폴더 구조를 만들고, API 호출 함수, 상태 관리 로직, UI 컴포넌트를 직접 타이핑함.	AI 에이전트가 자율적으로 의존성을 설치하고, 파일 구조를 생성하며 기본 프레임워크를 수 분 내에 완성.
문제 해결	에러 로그를 분석하고 스택 오버플로우를 검색하며 수 시간 동안 디버깅함.	에러 메시지를 복사해서 AI에게 던지면, AI가 터미널에서 스스로 수정한 후 다시 실행함.
기능 고도화	디자인 수정이나 기능 추가(예: 다크 모드)를 위해 CSS와 비즈니스 로직을 일일이 수정.	"테마를 좀 더 테크니컬한 다크 모드로 바꿔줘"라고 말하면 AI가 UI 전체를 즉시 리디자인함.
배포	Docker 설정, CI/CD 파이프라인 구축, 서버 환경 설정을 수동으로 수행.	"이거 배포해줘"라고 입력하면 AI가 클라우드 환경 (예: Cloud Run)에 한 번에 배포함(Vibe Deploy).

​

 

AI 활용

​

​

위 예제에서 보시다시피, 전통적 개발 방법에서는 개발자는 '어떻게(How)' 구현할지에 90%의 에너지를 쏟았으나, 바이브 코딩에서는 '무엇을(What)' 만들고 그 결과물이 의도(Vibe)에 부합하는지 '검증'하는 데 집중할 수 있다는 것을 알 수 있습니다.

​

위 사례처럼, 비전문가가 짧은 시간에 웹사이트 프레임워크를 완성하고 몇일 만에 실제 작동하는 맞춤형 서비스를 배포하는 것이 가능해 질 수도 있다는 것을 느낄 수 있습니다.

​

​

​

​

​

3. 바이브 코딩의 한계 및 기술적 과제

설명만 보면 뭐든지 뚝딱 만들어내는 만능처럼 보이지만 아직은 개선할 여지가 있습니다.

​

개념 검증(PoC, Proof Of Concpt)이나 단순 스크립트 작성에서는 생산성을 극대화 할 수 있지만, 복잡한 시스템 단위에서는 여러가지 한계가 있을 수 있습니다.

​

1) 아키텍처 부패 (Architecture Decay)

AI는 주어진 프롬프트만에 대해서 제한적인 문제 해결에 최적화되는 경향이 있습니다.

장기적인 관점의 디자인 패턴이나 시스템 레벨의 메모리 관리 등을 완벽히 통제하지 못해, 코드가 구조 없이 덧붙여지는 '스파게티 코드'가 발생하기 쉽습니다.

전체적인 구조를 살피고 Code를 작성하는 것은 아직은 서툽니다. 이런 문제는 서서히 나아질 것입니다.

​

​

2) 블랙박스화 및 디버깅의 어려움

개발자가 코드의 제어 흐름(Control Flow)을 직접 설계하지 않았기 때문에, 동시성 처리 중 발생하는 데드락(Deadlock)이나 미세한 메모리 안전성 문제 등 복합적인 버그가 발생했을 때 근본 원인을 추적하는 데 오히려 더 많은 시간이 소요될 수 있습니다.

​

직접 짠 코드가 아니기 때문에 어떻게 돌아가고 있는지 구조가 머리에 들어오지 않아서 디버깅이 오래 걸리는 것이죠.

하지만, 에러 상황 자체를 LLM에 던져주면 해결할 수도 있겠죠 ?

​

​

3) 컨텍스트 윈도우 한계

수십만 줄의 레거시 코드가 얽힌 대규모 프로젝트에서는 AI가 전체 의존성을 완벽히 파악하지 못하고, 환각(Hallucination) 현상으로 인해 존재하지 않는 함수를 호출하거나 엉뚱한 로직을 수정할 위험이 있습니다.

​

하지만, 이 역시 머지않아 개선될 것입니다.

​

​

​

​

 

4. 개발자의 역할 변화

결과적으로 바이브 코딩 시대에서 소프트웨어 엔지니어링의 본질은 '구문 작성(Implementation)'에서 '시스템 오케스트레이션(Orchestration) 및 검증(Verification)'으로 이동하고 있습니다.

​

문법을 완벽히 외우는 것보다, 시스템의 전체 구조를 명확히 설계하고 AI가 생성한 결과물을 빈틈없이 검증할 수 있는 테스트 아키텍처를 구축하는 능력이 더욱 중요해지고 있습니다.

​

실제 Vibe Coding을 사용해서 프로젝트를 진행해 보면 확실히 능률이 몇 십배내지 백배정도까지 올라가는 것을 체감할 수 있습니다.

아주 많은 똑똑하고 지치지 않고 토달지 않는 주니어 개발자들 수십명을 데리고 함께 일을 진행해 나가는 느낌입니다.

​

하지만, 예전에는 코드 한줄 한줄 적으면서, 내가 작성한 코드가 전체 Application에 어떤 영향을 끼치는지 어떤 기능이 구현되는지 확인하는 재미가 있었습니다.

​

또 말도 안되는 버그가 생기기도 하고 실제로 그것을 디버깅하면서 창작의 재미를 느끼는 것이 제 나름대로의 SW 개발의 큰 재미였는데,

LLM이 발달하고 Vibe Coding이라는 개념이 나오면서 뭐랄까.. 낭만이라고 부를만한 것들이 사라져 버린 것 같습니다.

​

효율은 올라가고 낭만과 창작의 기쁨은 없어져버린 그런 느낌이네요.

​

뭔가...씁쓸합니다.