바이브코딩

바이브코딩은 만들고 싶은 것을 말로 설명하면 AI가 코드를 쓰고, 사람이 결과를 확인하고 고칠 점을 말하는 작업 방식입니다. 이 장은 무엇이 잘 되고 무엇이 어려운지, 작게 시작해서 반복하는 요령, 한 장짜리 PRD, 입문 과정 4회차의 흐름, 흔한 실수를 다룹니다.

바이브코딩이란

코드를 직접 한 줄씩 쓰는 대신, 원하는 결과를 자연어로 설명합니다. AI가 코드를 만들고, 사람은 그것을 실행해서 눈으로 확인합니다. 마음에 들지 않으면 "이 부분만 바꿔 줘"라고 말합니다. 이 순환이 바이브코딩의 전부입니다.

여기서 사람이 맡는 일은 세 가지입니다.

• 무엇을 만들지 정합니다.
• 결과가 맞는지 확인합니다.
• 다음에 무엇을 고칠지 결정합니다.

코드를 몰라도 시작할 수 있지만, 판단과 책임이 사람에게 있다는 점은 변하지 않습니다. 코드를 이해하지 못한 채 AI가 만든 결과를 그대로 외부에 공개하거나 고객 데이터를 다루게 하면 문제가 생깁니다. 이 장의 마지막 절과 20장에서 이 위험을 다룹니다.

잘 되는 일과 어려운 일

잘 되는 일

• 한 장짜리 소개 페이지, 안내 페이지처럼 눈에 보이는 결과물
• 입력 폼, 목록, 간단한 계산기 같은 작은 화면
• 엑셀·CSV 정리, 파일 이름 일괄 변경 같은 반복 작업을 처리하는 짧은 스크립트
• 기존 결과물의 문구, 색, 배치 수정

공통점은 결과가 바로 눈에 보이고, 틀려도 되돌리기 쉬우며, 범위가 작다는 점입니다.

정리하면 내부 도구, 우리 팀 몇 명이 쓰는 수준, 빠르게 만들고 고치는 일이 금방 됩니다. 고객에게 파는 상용 서비스, 많은 사용자가 동시에 쓰는 시스템, 보안과 결제가 얽힌 민감한 시스템은 금방 되지 않습니다.

업무를 아는 사람이 더 잘 만듭니다

바이브코딩은 코딩을 아는 사람의 일이 아니라 업무를 아는 사람의 일에 가깝습니다. 무엇이 불편한지, 결과가 맞는지 틀린지를 판단하는 것은 업무를 아는 사람이기 때문입니다. 작업 방식의 차이는 아래 표와 같습니다.

어려운 일

• 결제, 개인정보 보관, 로그인처럼 보안과 법적 책임이 걸린 기능
• 여러 사람이 동시에 쓰는 서비스, 대용량 데이터
• 기존 시스템과 복잡하게 얽힌 변경
• 정답이 없어서 "맞는지 확인"하는 기준을 사람이 세우기 어려운 일

어렵다고 해서 못 하는 것은 아닙니다. 다만 혼자 AI만 믿고 진행하지 말고 19장의 계획과 자가검증을 거치고, 필요하면 전문가의 검토를 받아야 합니다.

작게 시작해서 반복하기

처음부터 완성품을 한 번에 시키면 실패합니다. 결과가 어긋났을 때 어디가 잘못인지 알 수 없기 때문입니다. 대신 이렇게 합니다.

1. 오늘 안에 끝낼 수 있는 크기로 줄입니다.
2. 요청합니다.
3. 결과를 직접 열어서 확인합니다.
4. 마음에 들지 않는 곳 하나만 고치도록 요청합니다.
5. 3번과 4번을 되풀이합니다.

요청, 확인, 수정의 고리를 짧게 돌릴수록 빠르고 안전합니다. 한 번에 한 가지만 바꾸게 하면 무엇이 효과가 있었는지도 알 수 있습니다.

한 번에 하나씩 고치라는 원칙에는 예외가 있습니다. 사용량 한도가 있는 도구에서는 요청 횟수가 곧 자원입니다. 이때는 고칠 점을 메모해 모았다가 한 번에 보냅니다. 서로 영향을 주지 않는 가벼운 수정은 모아서, 무엇이 문제를 만들었는지 모를 때는 하나씩 확인한다고 구분하면 됩니다.

수정하기 전에 지금 상태를 남겨 두는 것도 중요합니다. 파일을 복사해 두거나, 버전 기록 도구(git)로 기록을 남기면 결과가 나빠졌을 때 되돌릴 수 있습니다. 되돌릴 수 있으면 과감하게 시도할 수 있습니다.

핵심 한 번에 하나씩 고치고, 고치기 전 상태를 남겨 둡니다. 이 두 가지만 지켜도 대부분의 사고가 작은 일로 끝납니다.

만들기 전에 한 장짜리 PRD

PRD는 제품 요구사항 문서(Product Requirements Document)입니다. 무엇을 누구를 위해 왜 만드는지, 어디까지 하고 무엇은 하지 않을지 적은 짧은 문서입니다. 처음 만드는 사람을 위한 다섯 칸짜리 줄인 형태와 요청문에서 PRD로 자라는 과정은 6장에서 다룹니다. 바이브코딩에서 PRD는 AI와 맺는 약속입니다. 9장의 합의서와 같은 역할을 만드는 작업 단위로 옮겨 놓은 것입니다.

작은 작업이라면 한 장이면 충분합니다. 담을 내용은 다음과 같습니다.

• 문제: 어떤 불편을 해결하려는가
• 사용자: 누가 쓰는가
• 성공 기준: 무엇이 되면 성공인가
• 하지 않을 것: 이번에는 만들지 않을 것
• 제약: 기한, 쓸 수 있는 도구, 지켜야 할 규칙
• 화면: 어떤 화면이 필요한가

ACTIGENCE에는 PRD 작성을 돕는 PRD-Vibecoding 스킬이 있습니다. 한 줄짜리 아이디어를 주면 필요한 항목을 추론하고, 사용자가 정해야만 하는 것만 객관식으로 묻고, 나머지는 스스로 채워 PRD 한 편을 만듭니다. 이 스킬이 만드는 PRD는 처음부터 끝까지 한 번에 만드는 원샷 프로토타이핑 작업이 그대로 읽을 수 있는 형식입니다. 스킬 설명은 부록 B에 있습니다.

PRD는 이 도구의 단일 원본(SSOT, Single Source of Truth)입니다. 도구에 대한 판단이 엇갈릴 때 돌아가 확인하는 하나뿐인 원본이며, 범위를 묻는 사람과 일을 이어받는 사람에게 건네는 문서이기도 합니다. SSOT는 7장에서 자세히 다룹니다. 파일은 워드가 아니라 PRD.md로 저장합니다. AI가 가장 잘 읽는 형식이기 때문이며, 사람이 읽을 때만 보기 편한 HTML로 바꿔 봅니다.

준비 없이 "만들어 줘"로 시작하면 요청마다 방향이 흔들립니다. PRD를 먼저 쓰면 방향이 고정되고, 고치는 것이 아니라 쌓입니다.

스킬 없이도 아래 실습 2의 프롬프트로 한 장짜리 PRD를 만들 수 있습니다.

입문 과정 4회차의 흐름

ACTIGENCE의 AI 바이브코딩 입문 과정은 4주, 4회차로 구성됩니다. 회차별 실습은 actigence.ai 자료실에 있고, 이 책에서는 흐름을 요약합니다.

1회차. 도구를 준비하고 첫 결과물 만들기

AI에게 상황(직무, 목표, 수준)을 먼저 알려 주고, 작업 폴더를 만들고, 설치 중 막히면 화면 메시지를 그대로 붙여서 묻습니다. 그리고 한 장짜리 웹 페이지를 index.html 하나로 만들어 브라우저에서 엽니다. 무엇으로 이루어진 파일인지도 AI에게 설명을 듣습니다. 마지막에 수정하기 전 상태를 남겨 두는 방법을 익힙니다.

2회차. 화면을 말로 설명하기

바로 만들지 않고 AI가 질문을 하나씩 하게 해서 화면 구성안을 만듭니다. 꼭 필요한 것과 나중에 해도 되는 것으로 나눕니다. 그다음 버튼, 입력 폼, 목록을 차례로 만듭니다. 버튼은 "누르면 무슨 일이 일어나는지"까지 말하고, 목록은 보여 주기, 추가하기, 지우기 순서로 나눠 확인합니다. 휴대폰처럼 좁은 화면에서도 점검합니다.

3회차. 반복 업무 맡기기

AI에게 맡길 일과 사람이 남겨 둘 일을 구분합니다. 엑셀·CSV 정리를 시키되, 먼저 점검만 시키고 수정은 그다음에 합니다. 결과는 원본과 줄 수와 값을 비교해서 확인합니다. 메일 초안은 날짜와 금액을 [확인 필요]로 표시하게 하고, 사람이 직접 확인합니다. 이 회차의 데이터 정리는 14장에서 더 깊이 다룹니다.

4회차. 점검하고 웹에 올리기

공개 전에 개인정보, 비밀번호, 내부 자료가 파일에 들어 있지 않은지 점검합니다. README.md로 설명 문서를 남기고, 호스팅 서비스의 공식 문서를 보며 웹에 올립니다. 올린 뒤에는 다른 기기에서 열어 봅니다. 막혔을 때 묻는 틀(하려던 일, 실제로 일어난 일, 이미 해 본 것, 오류 메시지 원문)도 배웁니다. 이 흐름은 20장에서 더 확장됩니다.

설치 없이 브라우저만으로 시작하는 짧은 경로는 5장과 6장에 따로 정리했습니다. 입문 과정을 이틀로 압축한 흐름이며, 요청문에서 시작해 PRD, 파일, 주소로 이어집니다.

네 회차에 공통으로 흐르는 원칙은 하나입니다. AI가 만든 결과는 시작점이고, 확인은 사람이 합니다.

흔한 실수

• 처음부터 크게 시킵니다. 로그인, 결제, 관리자 화면까지 한 번에 요청하면 어디가 잘못인지 알 수 없습니다. 눈에 보이는 가장 작은 것부터 시작합니다.
• 확인 없이 다음으로 넘어갑니다. 결과를 열어 보지 않고 다음 요청을 쌓으면 오류가 겹쳐서 되돌리기 어려워집니다.
• 한 번에 여러 가지를 바꾸게 합니다. 무엇이 문제를 만들었는지 모르게 됩니다.
• 수정 전 상태를 남기지 않습니다. 결과가 나빠졌을 때 돌아갈 곳이 없습니다.
• 오류 메시지를 요약해서 전달합니다. 메시지는 요약하지 말고 그대로 붙입니다.
• 비밀 값을 파일에 넣습니다. 비밀번호와 접속 키는 대화에도, 공개되는 파일에도 넣지 않습니다.
• 실제 고객 정보로 연습합니다. 연습은 가짜 값으로 합니다.
• 검토가 새 병목인 것을 잊습니다. 만들기가 쉬워진 만큼 이해하고 확인하는 일이 늘어납니다. 내용을 이해하지 못한 결과물을 남에게 넘기면 일이 사라진 것이 아니라 받는 사람에게 넘어갑니다. 19장의 워크슬롭 절에서 이어서 다룹니다.
• 허락 창을 읽지 않고 누릅니다. 파일 삭제나 내려받기, 작업 폴더 밖의 이야기가 나오면 멈추고 확인합니다.
• 서비스마다 다른 계정으로 로그인합니다. 다른 계정으로 승인하면 빈 계정이 새로 생겨 올린 것이 보이지 않습니다.
• 만든 것을 이해하지 못한 채 공개합니다. 무엇을 하는 파일인지 AI에게 설명을 듣고, 공개 전 점검을 거칩니다.

실습

실습 1. 개인 소개 페이지 첫 프롬프트

작업 폴더를 하나 만들고, 클로드에서 아래 프롬프트로 시작합니다. 대괄호는 내용으로 바꿉니다. 입문 과정 1회차의 실습을 옮긴 것입니다.

[주제: 나 자신 / 우리 가게 / 우리 팀]를 소개하는 한 장짜리 웹 페이지를 index.html 파일 하나로 만들어 줘. 제목, 두세 문장의 소개, 연락 방법을 넣어 줘. 글자는 읽기 편한 크기로 하고, 색은 [차분한 / 밝은] 느낌으로 맞춰 줘. 연락처 칸에는 실제 번호 대신 [연락처]라는 자리 표시만 넣어 줘. 만든 뒤에 파일을 어떻게 열어 보는지도 알려 줘.

파일을 열어 보고, 마음에 들지 않는 부분 하나만 골라 고쳐 달라고 요청합니다. 그 한 가지를 바꾸기 전에 파일을 복사해 둡니다.

실습 2. 한 장짜리 PRD 만들기

만들고 싶은 작은 도구(예: 방문 예약 폼, 할 일 목록)가 있다면 아래 프롬프트로 PRD를 만들어 봅니다.

나는 [직무]이고 [만들고 싶은 것]을 만들려고 해. 코딩은 [못 해 / 조금 해].
한 장짜리 PRD를 쓰고 싶어. 먼저 필요한 것을 질문해 줘. 질문은 한 번에 하나씩, 객관식으로 해 줘.
답이 모이면 다음 항목으로 PRD를 써 줘: 문제, 사용자, 성공 기준, 하지 않을 것, 제약, 필요한 화면 목록.
'꼭 필요한 것'과 '나중에 해도 되는 것'을 나누고, 꼭 필요한 것은 오늘 안에 만들 수 있는 양으로 줄여 줘.

완성된 PRD에서 "하지 않을 것" 항목을 가장 먼저 읽어 봅니다. 여기가 비어 있으면 범위가 커지고 있다는 신호입니다.

실습 3. 작업 기록 남기기

하루 작업을 마치면 아래 프롬프트로 기록을 남깁니다.

오늘 우리가 한 작업을 notes.md 파일로 정리해 줘. 만든 파일 이름, 내가 쓴 지시 중 잘 먹힌 것, 막혔던 점, 다음에 해 보고 싶은 것을 항목별로 적어 줘.

정리

• 바이브코딩은 말로 설명하고, AI가 만들고, 사람이 확인하고 결정하는 작업 방식입니다.
• 눈에 보이고 되돌리기 쉬운 작은 일은 잘 되고, 보안과 법적 책임이 걸린 일은 어렵습니다.
• 요청, 확인, 수정의 고리를 짧게 돌리고, 한 번에 하나만 고치며, 수정 전 상태를 남겨 둡니다.
• 만들기 전에 한 장짜리 PRD로 문제, 성공 기준, 하지 않을 것을 정해 둡니다.
• 입문 과정 4회차는 도구 준비, 화면 구성, 반복 업무, 점검과 공개 순서로 이어지며, 공통 원칙은 확인을 사람이 한다는 것입니다.