Vibe Coding
Vibe의 의미
개발자가 머릿속에 그린
의도(Intent), 맥락(context), 사용자 경험(UX)의 느낌을 의미함정의(Defination)
전통적인 코딩이 어떻게(How) 구현할지 컴퓨터의 문법으로 명령하는 것이었다면, 바이브 코딩은 AI에게 무엇을(What) 원하는지 자연어로 전달하여 코드를 생성, 수정, 결합하는
의도 중심 개발(Intent-Driven-Development)을 의미
바이브 코딩(Vibe Coding) 개발 프로세스 흐름도
핵심 단계
4단계인 Vibe Check 단계로,
생성된 앱을 실제로 실행해 보면서 처음에 기획했던 느낌(바이브)이 나는지 점검.
디자인의 분위기는 물론이고, 기능의 작동 방식과 사용자 경험이 우리의 의도와 일치하는지 점검하는 필수적인 과정
2~5단계의 루프를 얼마나 빠르고 정확하게 돌릴 수 있는지가
바이브 코딩의 열쇠임
바이브 코딩 실전 예시
바이브 코딩의 장단점
바이브 코딩의 장단점 구분 장점 단점 생산성 및 속도 빠른 프로토타이핑,
초기 개발 속도 비약적 상승장기적 유지보수 어려움,
기술 부채 누적진입 장벽 코딩 지식 부족해도
아이디어 구현 가능원리 이해 없는 파상적 코드 양산 코드 품질 및 안정성 창의적 흐름 유지, 즉각적 결과 확인 가독성 저하,
AI 할루시네이션 및 보안 취약점 위험
바이브 코딩이 위험한 이유
- 기술적 부채의 폭증
AI가 짠 코드는 가독성이 떨어지거나 중복된 로직을 포함하기 쉬움- 환각(Hallucination) 리스크
존재하지 않는 라이브러리를 활용하거나,
보안에 취약한 코드를 그럴듯하게 제안할 수 있음- 디버깅의 늪
왜 작동하는지 모르니, 에러가 났을 때 어디를 고쳐야 할지 또한 모르게 됨
예)
게시판을 만들어달라는 요청 뒤 결과물을 받았으나,
실제로는 보안 인증 로직이 통째로 빠져 있어 해킹에 노출되는 상황
AI 결과물의 불확실성 원리를 극복하기 위한 방안
명세주도개발(Specification Driven Development, SDD)
- 코드를 작성하기 전에 명세를 정의한다는 원칙에 기반
Vibe Coding vs SDD
바이브 코딩과 명세주도개발은 서로 상호 보완적인 관계임
AI가 스스로 추측할 수 없도록 확실한 명시가 필요함
SDD Workflow
기존 명세서: 참고용
SDD에서의 명세서: 절대적인 기준
명세서는 마크다운(Markdown) 문서 형식으로 정리해야 함
- 사람 뿐만 아니라 AI 또한 가장 빠르고 정확하게 읽을 수 있는
공용 언어이기 때문- 텍스트 형태라 git과 같은 도구를 통해 코드와 함께 버전 관리를 하기 유리
사람의 생각과 컴퓨터의 코드를 이어주는 연결고리
1단계: 무엇을 만들것인가?
제품 요구사항 문서(Product Requirement Document, PRD)
- 프로젝트의 목표와 범위를 정의
- 기술적인 구현 방법(How)보다는 무엇(What)을 만들지 집중
사용자 스토리(User Story)
- 개발자의 관점이 아닌, 실제 서비스를 사용하는 사람의 관점에서
이 기능이 왜 필요한가를 한 문장으로 설명하는 도구
- 사용자 스토리의 구성 요소 3가지
사용자가 누구인지?, 무엇을 하고 싶은지?, 그로 인한 가치는?
EARS 문법
EARS(Easy Approach to Requirements Syntax)
- 누구나 똑같이 해석할 수 있도록 요구사항을 작성하는 약속된 문장 구조
- AI가 테스트 코드를 짤 수 있을 만큼 구체적인 조건과 결과를 정의함
핵심 구조
어떤 사건이 발생하면(WHEN)
→ (THE SYSTEM SHALL)시스템은 반드시 ~동작을 해야 한다.
시나리오: 로그인 실패
- WHEN
사용자가 잘못된 비밀번호 5회 입력- THE SYSTEM SHALL
계정을 10분간 잠그고 "계정이 잠겼습니다"라는 팝업 표시5가지 핵심
- Ubiquitous(보편적) (X)
[대상]은 [동사] 해야 한다.
(조건 없이 수행되는 기능)
예)
시스템은 모든 결제 내역을 5년간 보관해야 한다.- Event-Driven(이벤트 구동) (WHEN)
WHEN [이벤트]가 발생하면, [대상]은 [동사] 해야 한다.
(특정 트리거 발생 시 동작)
예)
사용자가 결제 버튼을 클릭하면,
시스템은 결제 완료 페이지를 표시해야 한다.- State-Driven(상태 구동) (WHILE)
WHILE [특정 상태]인 동안, [대상]은 [동사] 해야 한다.
(특정 모드나 상태 유지 시의 동작)
예)
시스템이 점검 모드인 동안, 관리자 페이지 접근은 차단되어야 한다.- Unwanted Behavior(예외 상황) (IF, THEN)
IF[예외 상황]이면, THEN[대상]은 [결과]를 수행해야 한다.
(에러 처리나 장애 대응 시나리오)
예)
유효하지 않은 카드 번호가 입력되면,
시스템은 오류 메시지를 보여주어야 한다.- Optional Feature(선택적 기능) (WHERE)
[특정 조건]인 경우, [대상]은 [동사]해야 한다.
(특정 환경/하드웨어 존재 시의 동작)
예)
생체 인식 센서가 탑재된 기기에서는,
시스템은 지문 로그인을 허용해야 한다.
Requirements.md
2단계: 기술적으로 어떻게 구현할 것인가?
(Design.md or TechSpec.md)
"어떤 기술로 무엇을 만들 것인가?"3단계: 실행 가능한 세부 작업 목록 생성
(Task.md)
- 체크박스를 배치해둠으로써 작업의 원자성을 확보할 수 있음
- 한 항목은 AI가 한번의 작업으로 완결할 수 있는 최소 단위가 됨
"구현을 하기 위해서 어떤 것부터 시작해야 하는가?"
4단계: 구현 시작
Task.md에 있는 작업 중 가장 먼저 처리해야 할
단 하나의 원자 단위 작업만을 선택하여 AI에게 넘겨줌
SDD Levels
- Sepc-First
초기 구현이 끝나면 스펙은 폐기되거나, 코드와의 차이(drift)가 발생함- Spec-Anchored
스펙은 시스템의 생명 주기 전반에 걸쳐 코드와 함께 유지관리됨
동작의 변경이 있다면 스펙과 코드 두 가지를 모두 업데이트 해야 함- Spec-as-Source
스펙은 사람이 직접 편집하는 유일한 아티팩트가 됨
모든 코드와 테스트, 그리고 문서는 이 아티팩트로부터 자동으로 생성됨
코드는 직접 수정이 불가하며, 명세 변경을 통해서만 할 수 있음
Spec Kit
1) Constitution: 프로젝트의 불변 원칙
AI가 모든 후속 단계에서 절대 어겨서는 안될 도덕적/기술적 헌법을 제정
2) Specify: '무엇'과 '왜'에 집중하라
기술적인 구현 방법(How)을 철저히 배제하고,
비즈니스 목적과 사용자 경험에 집중하는 제품 요구사항 문서(PRD) 초안 작성
- 기술 스택, API 설계, DB 스키마 언급 금지(X)
- 비즈니스 의도, 사용자 시나리오(User Cases), 디자인 컨텍스트(O)
needs clarification: 구조화된 명세서 생성 및 모호한 부분에 자동 태그 부여
3) Clarify: 환각을 차단하는 인터뷰
AI가 임의로 요구사항을 추측하지 못하도록 논리적 공백을 메우는 과정
-
1) 분석
AI가 사양서의 빈틈과 논리적 공백을 스스로 찾아냄 -
2) 질문
사용자에게 최대 5개의 핵심 질문 제안 -
3) 답변 및 확정
사용자의 답변을 바탕으로 사양서를 완벽하게 업데이트
4) Plan: 기술적 청사진 설계(How)
확정된 명세(What)를 바탕으로 구체적인 기술 구현 계획(Tech Spec)을 수립
- 아키텍쳐 구조
- 데이터 모델
- 인터페이스
데이터 모델이나 설계가 마음에 들지 않을 경우 plan.md를 직접 수정하지 말 것
반드시 Specify 단계로 돌아가 요구사항을 재정의하여
AI가 계획을 다시 세우도록 유도할 것
5) Tasks: 실행 가능한 작업의 분할
기술 설계안을 AI가 맥락을 잃지 않고 실행할 수 있는 단위 작업 지시서로 변환
-
Phase 분류
논리적인 구현 순서에 따른 체계적인 작업 묶음 -
정밀한 태스크
고유 번호 부여 및 명확한 완료 기준(Definition of Done, DoD) 명시 -
병렬 실행
에이전트 동시 처리를 위한 태그 지원
6) Analyze: 최종 논리 검증 게이트
실제 구현 직전, 지금까지 작성된 모든 문서 간의
논리적 결함이나 모순을 교차 검증하는 과정
- 요구사항(Spec)이 계획(Plan)에 모두 반영되었는가?
- 기술 구조(Plan)가 작업 목록(Tasks)으로 빠짐없이 쪼개졌는가?
- 모든 내용이 프로젝트 대원칙(Constitution)을 준수하는가?
모순 발견 시 AI가 수정안을 제안하며,
승인 시 모든 파일이 일관성에 맞게 자동 동기화됨
7) Implement: 컨텍스트 기반 자동화 구현
풍부한 맥락을 바탕으로 소스 코드를 생성하는 과정
/speckit.implement
