VIBECODING 365 / DICTIONARY
바이브 코딩 스펙트럼
Vibe Coding Spectrum
DEFINITION
정의
AI 참여도에 따른 코딩 방식의 연속적 범위를 나타내는 개념 모델. 한쪽 끝에는 개발자가 모든 코드를 직접 작성하는 '완전 수동 코딩(Manual Coding)'이 있고, 반대쪽 끝에는 AI가 독립적으로 소프트웨어를 구축하는 '완전 AI 자율 코딩(Autonomous Development)'이 있으며, 대부분의 실무는 그 사이 어딘가에 위치한다. 일반적으로 Manual Coding → AI-Assisted Coding(자동완성·제안 수준) → Vibe Coding(자연어 기반 코드 생성) → Agentic Engineering(AI 에이전트 자율 작업 + 인간 감독) 순으로 AI 참여도가 높아진다. 중요한 것은 이것이 '진화의 단계'가 아니라 '선택의 스펙트럼'이라는 점이다. 같은 개발자가 같은 프로젝트 내에서도 작업의 성격에 따라 다른 지점을 선택할 수 있다. 예를 들어, 단순 스크립트나 보일러플레이트는 바이브 코딩으로, 핵심 결제 로직이나 보안 관련 코드는 AI 어시스트 + 수동 코딩으로, 대규모 리팩토링은 에이전틱 엔지니어링으로 접근하는 식이다.
ENGLISH
Vibe Coding Spectrum
EXAMPLE
같은 개발자가 단순 스크립트는 바이브 코딩으로, 핵심 결제 로직은 AI 어시스트 + 수동 코딩으로 접근.
관련
이어서 볼 문서
RELATED TERMS
연관 용어
Vibe Engineering
바이브 코딩의 개념을 소프트웨어 엔지니어링 전반으로 확장한 접근 방식. 바이브 코딩이 '코드 생성'이라는 단일 활동에 초점을 맞춘다면, 바이브 엔지니어링은 시스템 설계(아키텍처), 테스트 전략 수립, 인프라 구성, CI/CD 파이프라인, 배포까지 소프트웨어 개발 생명주기 전체를 AI에게 자연어로 지시하여 수행한다. 예를 들어, 개발자가 '마이크로서비스 아키텍처를 설계하고, API 엔드포인트를 만들고, 단위 테스트를 작성하고, Docker 컨테이너로 배포해줘'라는 고수준의 요구사항만 전달하면, AI 에이전트가 각 단계를 계획하고 실행한다. 이 개념은 에이전틱 엔지니어링(Agentic Engineering)의 전신으로 볼 수 있으며, 개발자의 역할이 '코드를 직접 쓰는 사람'에서 '시스템을 설계하고 AI의 작업을 감독하는 사람'으로 전환되는 패러다임 변화를 반영한다. 단, 바이브 엔지니어링은 아직 '체계적 방법론'이라기보다는 '접근 방식'에 가까우며, PEV 루프나 가드레일 같은 구조가 추가되어야 프로덕션 수준의 에이전틱 엔지니어링이 된다.
핵심 개념 AI 슬롭AI Slop
AI가 양산하는 저품질 코드 또는 콘텐츠를 가리키는 경멸적 표현. 'Slop'은 원래 '찌꺼기·잔반'을 뜻하며, AI 생성물이 표면적으로는 그럴듯해 보이지만 실제로는 심각한 문제를 내포하고 있음을 비유한다. 구체적인 문제로는 에러 처리 누락(try-catch 없이 API 호출), 보안 취약점(입력값 검증 미수행, SQL 인젝션 미방어), 유지보수 불가능한 구조(거대한 단일 함수, 하드코딩된 값), 성능 문제(불필요한 재렌더링, N+1 쿼리), 접근성 무시 등이 있다. 바이브 코딩의 가장 큰 위험 요소로, AI가 '동작하는 코드'를 생성하는 것과 '프로덕션에 배포할 수 있는 코드'를 생성하는 것 사이의 간극을 보여준다. AI Slop을 방지하려면 명확한 스펙 전달, 단위 테스트 게이트, 린터·보안 스캔 통합, 인간의 코드 리뷰가 필수적이며, 이는 곧 하네스 엔지니어링의 필요성으로 이어진다.
핵심 개념 수락/거부Accept/Reject
AI 코딩 도구에서 AI가 제안한 코드 변경사항을 개발자가 선택적으로 승인(Accept)하거나 거부(Reject)하는 인터페이스 패턴. 바이브 코딩의 가장 기본적인 인간-AI 상호작용 방식으로, 모든 주요 AI IDE(Cursor, Windsurf, GitHub Copilot)에서 표준으로 채택하고 있다. AI가 여러 파일에 걸쳐 변경을 제안하면, 개발자는 각 변경사항을 개별적으로 또는 일괄적으로 수락/거부할 수 있다. 이 패턴의 핵심 가치는 '인간의 최종 결정권 유지'에 있으며, Human-in-the-Loop 원칙의 가장 직접적인 구현이다. YOLO Mode(자동 수락)와 정반대의 철학을 가지며, 프로덕션 코드에서는 Accept/Reject 패턴을 유지하는 것이 권장된다. 다만, 매번 수락/거부를 결정하는 것은 개발 속도를 저하시킬 수 있어, 변경 규모와 위험도에 따라 자동화 수준을 조절하는 전략이 필요하다.