* 이 게시물은 쿠팡 파트너스 활동의 일환으로, 이에 따른 일정액의 수수료를 제공받습니다.
(바이브 코딩 ①) 흐름
“바이브 코딩(vibe coding)”이라는 말이 2025년에 훅 들어왔다. AI가 코드를 실시간으로 생성하고 고쳐주면, 사람은 한 줄씩 타이핑하는 대신 방향을 잡고 결과를 검수한다. 처음엔 장난스러운 표현 같았는데, 지금 보면 일하는 방식 자체가 그쪽으로 굳어졌다.
실제 흐름은 대충 이렇다. 하고 싶은 걸 말로 던진다 — “이 CSV를 읽어서 월별 매출 그래프를 그려줘.” AI가 코드를 뱉는다. 돌려본다. 안 되면 “에러 났어, 이 부분 고쳐”라고 한다. 되면 “축 라벨을 한글로 바꿔”처럼 다듬는다. 이 반복이 바이브 코딩의 본체다.
여기서 바뀐 건 개발자의 무게중심이다. 예전엔 “어떻게 짤까”에 시간을 썼다면, 지금은 “무엇을·왜 만들지”와 “이게 맞게 됐나”에 시간을 쓴다. 코드를 쓰는 일에서 코드를 지휘하는 일로 옮겨간 거다. 구현의 장벽이 낮아진 만큼, 방향을 잡고 결과를 판단하는 능력이 더 중요해졌다.
숫자로도 이건 이미 대세다. 해외 개발자 설문들에서 AI 코딩 도구를 일상적으로 쓴다는 응답이 압도적 다수로 나온 지 오래다. 실험 단계는 지났고 인프라가 됐다는 얘기다. 안 쓰는 게 선택지가 아니라, 잘 쓰는 법을 익히는 게 과제인 상황이다.
잘 굴러갈 때와 헛돌 때
잘 될 땐 신기할 만큼 빠르다. 문제는 안 될 때인데, 원인은 대개 컨텍스트다. 대화가 길어지고 넣은 정보가 쌓이면 출력 품질이 떨어진다 — 이걸 context rot이라고 부른다. 막히기 시작하면 프롬프트를 더 쥐어짜기보다, 필요 없는 맥락을 정리하거나 새 대화로 리셋하는 편이 훨씬 빠르다. 이 감각은 컨텍스트 엔지니어링 편과 그대로 이어진다.
기록을 남겨야 나중이 편하다
혼자 빠르게 만들 때 가장 놓치기 쉬운 게 기록이다. 무엇을 왜 이렇게 정했는지, 어떤 요청이 통했는지를 남기지 않으면, 나중에 남에게 넘기거나 몇 주 뒤 내가 다시 볼 때 막막해진다. 거창할 필요 없다. 요청과 응답을 훑는 프롬프트 로그와 핵심 결정 몇 줄만 있어도 다음 사람(혹은 미래의 나)이 맥락을 잡는다.
초보와 숙련자의 진짜 차이
시작은 초보도 쉽다. 다만 결과가 맞는지 판단할 눈이 없으면 틀린 코드를 걸러내지 못한다. 숙련자는 AI에게 무엇을 시킬지와, 나온 걸 어떻게 검증할지를 안다. 그래서 바이브 코딩은 기초를 대체하는 게 아니라 기초가 있는 사람의 속도를 몇 배로 키운다. 다음 편은 그 도구 선택 — Cursor와 Claude Code다.
예를 들면, 이 블로그도
멀리 갈 것도 없이 이 cozlab 작업이 그랬다. “모든 글에 FAQ를 붙이고 구조화 데이터를 넣어라”, “썸네일 카드를 시리즈별로 생성해라” 같은 반복 작업을, 나는 한 줄씩 타이핑하지 않았다. 목표를 말로 던지고, AI가 스크립트를 짜고, 결과를 몇 개 확인해 어긋난 걸 고치게 하는 식으로 돌렸다. 수십 개 글을 같은 규칙으로 바꾸는 일에 사람이 하나씩 붙어 있는 건 낭비고, 그걸 위임하는 게 정확히 바이브 코딩의 자리다. 실제 왕복 하나를 그대로 옮기면 이랬다.
지시는 “모든 글에 FAQ를 붙이고 FAQPage 구조화 데이터를 넣어라. 이미 있는 글은 건너뛰어라”였고, AI가 낸 스크립트의 뼈대는 이랬다 — build_faq()로 글마다 질문·답을 만들고, apply_faq()가 본문 끝에 붙이되 이미 FAQ가 있으면 건너뛴다(멱등). 내가 한 검수는 두 가지였다: 샘플 세 편을 열어 JSON-LD가 실제로 파싱되는지 확인했고, ‘건너뛰기’ 조건이 빠져 있길래 그걸 고치게 했다. 100편 넘는 글이 이 왕복 두 번으로 끝났다 — 스크립트를 내가 짰다면 반나절, 검수 없이 믿었다면 중복 FAQ 사고였을 것이다.
다만 마냥 장밋빛은 아니다. AI가 뱉은 코드를 그대로 믿었다가 데는 경우, 잘 되다가 어느 순간 통제가 안 되는 경우가 분명히 있다. 이 시리즈에서 도구 고르기(②), 코드 검수(③), 무너지는 지점(④), 그리고 사람과 AI가 역할을 어떻게 나눌지(⑤)를 하나씩 짚어보려 한다.
실무 팁 — 처음 바이브 코딩이 헛도는 8할은 모델이 멍청해서가 아니라 목표가 흐릿해서다. ‘좀 더 좋게’가 아니라 무엇을·왜·어떤 제약을 앞에서 못박고, 큰 작업은 단계로 쪼개 각 단계를 테스트로 검증하면 성공률이 확 오른다.
자주 묻는 질문 (FAQ)
바이브 코딩이면 코드를 안 봐도 되나요?
아닙니다. 방향·검수·결정은 여전히 사람 몫입니다. AI가 짠 코드를 읽고 이해하지 못하면 유지보수와 디버깅 단계에서 무너집니다.
초보자도 바이브 코딩을 할 수 있나요?
시작은 쉽습니다. 다만 결과가 맞는지 판단할 기초가 없으면 틀린 코드를 걸러내기 어렵기 때문에, 기본기를 함께 쌓으며 하는 걸 권합니다.
답글 남기기