Insights·2026-07-23

바이브 코딩이란 무엇이고, 도구부터 배포까지 지도 한 장으로 어떻게 정리되는가?

바이브 코딩은 코드를 한 줄씩 직접 타이핑하는 대신, AI에게 한국어(자연어)로 지시해 웹사이트나 서비스를 만드는 방식이다. 코딩을 한 번도 안 해 본 사람이 막막함을 느끼는 이유는 개별 도구가 어려워서가 아니라, 전체가 어떻게 맞물려 돌아가는지 그림이 머릿속에 없기 때문이다. 그 전체 그림은 지도 한 장으로 접힌다. 첫째, 도구다. ChatGPT·클로드 같은 LLM이 학습된 두뇌라면, 그 두뇌를 달고 실제로 파일을 만들고 고치는 손발이 코딩 에이전트이고, 요즘은 클로드 코드 하나가 터미널·편집기 없이 이 역할을 단독으로 한다. 둘째, 프론트엔드(눈에 보이는 화면)다. 만들 서비스의 규모만 알려 주면 에이전트가 맞는 스택을 골라 준다. 셋째, 백엔드(화면 뒤에서 데이터를 저장·처리하는 서버)다. 대부분이 여기서 포기하는데, 서버·데이터베이스·배포의 복잡한 과정을 Supabase(데이터 매니저)와 Vercel(배포 매니저)이 대신 넘겨 준다. Git과 GitHub은 그 사이에서 작업을 저장하고 인터넷 창고에 올리는 역할을 맡는다. 결국 지도는 세 줄로 접힌다: 도구는 클로드 코드, 프론트는 규모를 말해 스택을 맡기고, 백엔드는 Supabase와 Vercel.

바이브 코딩 전체 흐름을 3단계로 그린 지도 — ① 도구: LLM(학습된 두뇌)에 코딩 에이전트(손발)를 붙인 클로드 코드 하나, Git·GitHub는 저장·창고. ② 프론트엔드(시계 문자판): 규모만 알려주면 에이전트가 스택을 고른다, HTML·CSS·JS·React. ③ 백엔드(시계 태엽, 대부분 포기하는 곳): Supabase가 데이터·서버 매니저, Vercel이 배포 매니저. 하단 세 줄 요약: 도구는 클로드 코드, 프론트는 규모로 스택, 백엔드는 Supabase+Vercel.
바이브 코딩 지도 한 장: 도구 → 화면(프론트엔드) → 그 뒤(백엔드)

바이브 코딩이란 무엇인가, 왜 지도가 먼저인가

바이브 코딩(vibe coding)은 개발 언어를 배워 코드를 직접 타이핑하는 대신, AI에게 자연어로 원하는 것을 말해서 프로그램을 만들게 하는 방식이다. '한 페이지짜리 소개 사이트를 만들어 줘'라고 한국어로 지시하면 AI가 코드를 짜고, 작업 과정을 보여주고, 완성된 화면 미리보기까지 내놓는다. 사람은 무엇을 만들지 결정하고 방향을 잡고, 실제 코드 타이핑은 AI가 맡는다.

그런데 코딩을 처음 접하는 사람은 시작 전에 지레 접는 경우가 많다. 도구 이름과 개념이 낯설기 때문이다. 문제는 개별 개념이 특별히 어려워서가 아니라, 이것들이 서로 어떻게 맞물려 하나의 사이트로 완성되는지 전체 그림이 없다는 데 있다. 지도가 없으면 아무리 각 지점을 쉽게 설명해도 매 단계에서 길을 잃는다.

그래서 개별 도구 사용법을 외우기 전에 전체 지도를 먼저 편다. 지도의 큰 덩어리는 셋이다. (1) 어떤 도구로 만드는가, (2) 눈에 보이는 화면(프론트엔드)을 어떻게 만드는가, (3) 화면 뒤에서 데이터를 다루는 부분(백엔드)을 어떻게 채우는가. 이 셋을 순서대로 짚으면 바이브 코딩의 처음부터 끝까지가 한눈에 들어온다.

LLM과 코딩 에이전트: 두뇌와 손발

먼저 두 단어를 구분해야 한다. LLM(Large Language Model, 거대 언어 모델)은 엄청난 양의 데이터를 학습한 '두뇌'다. ChatGPT, 제미나이, 클로드가 모두 LLM이다. 질문에 답하고 글을 쓰고 코드를 생각해 낼 수 있지만, 그 자체로는 내 컴퓨터의 파일을 직접 만들거나 고치지는 못한다. 대화창 안에서 말로만 존재한다.

그 두뇌에 손발을 달아 실제로 일하게 하는 것이 코딩 에이전트다. 코딩 에이전트는 LLM의 판단을 받아 내 컴퓨터에서 파일을 생성하고, 코드를 고치고, 명령을 실행하고, 결과를 확인한다. 즉 '생각하는 두뇌'(LLM)와 '움직이는 손발'(에이전트)이 합쳐져야 비로소 바이브 코딩이 된다. 우리가 실제로 설치해서 쓰는 것은 이 코딩 에이전트다.

코딩 에이전트에는 여러 제품이 있고 접근 방식도 다양하다. 여러 LLM을 골라 끼우고 싶다면 커서(Cursor) 같은 도구가 유리하다. 하지만 이 지도에서는 가장 단순한 길로, 결과물이 좋은 클로드 코드를 기준으로 설명한다.

도구 세팅: 예전의 복잡함과 지금의 단순함

예전에는 코딩 에이전트를 쓰려면 세팅이 복잡했다. 검은 화면에 영어 명령어가 잔뜩 뜨는 '터미널'을 열어 낯선 프로그램을 설치하고, 코드 미리보기용 편집기(비주얼 스튜디오 코드, 줄여서 VS Code)를 따로 깔고, 되돌리기 기록을 남기는 Git까지 그 검은 화면에서 명령어로 세팅해야 했다. 뭔지도 모르고 따라 설치하는 구간이 많았다.

여기서 용어 하나. 터미널은 마우스 클릭 대신 글자 명령어로 컴퓨터에게 일을 시키는 창이다. 우리가 쓰는 윈도우·맥의 예쁜 화면도, 원래 이렇게 명령어로 돌아가던 것을 보기 편하게 덮어 놓은 것이다. 초기 코딩 도구에는 이 '보기 편한 껍데기'가 없어서 검은 화면을 직접 다뤄야 했던 것이다.

지금은 클로드 코드 PC 버전이 이 모든 것을 단독으로 대신한다. 터미널이나 편집기를 따로 열 필요 없이, 설치하고 로그인하면 하나의 창 안에서 대화·코딩·미리보기가 다 된다. 설치는 이렇게 한다: 구글에 '클로드 코드'를 검색해 공식 다운로드 페이지에 들어가고, 내 컴퓨터(윈도우/맥)에 맞는 설치 파일을 받아 실행한다. 설치가 끝나면 실행해서 클로드 계정으로 로그인하고, 창 좌측 상단에서 채팅 탭이 아니라 '코드' 탭을 고르면 코딩 화면이 뜬다. 여기 대화창에 한국어로 지시하면 코드가 짜지고 결과 미리보기까지 이 안에서 보인다.

비용은 어떻게 생각해야 하나

솔직히 짚어야 할 부분이 있다. 코딩을 대신 짜 주는 이런 도구는 대개 유료 구독을 요구한다. 클로드 코드로 실제 코딩(코드 탭)을 쓰려면 프로 이상 유료 구독이 필요할 수 있다.

다만 비교 대상을 바꿔 보면 판단이 달라진다. 원래 사이트 하나를 만들려고 개발자를 고용하거나 외주를 맡기면 최소 수백만 원이 든다(영상에서는 200만 원 이상을 예로 든다). 반면 구독료는 그보다 훨씬 낮고, 그 한 번의 구독으로 여러 개의 사이트를 만들 수 있다. 처음에는 저렴한 요금제로 시작하고, 본격적으로 서비스를 만들 때 상위 요금제로 올리면 된다.

즉 '비용이 든다'를 '외주 대비 얼마나 아끼는가'로 바꿔 보면, 빠르게 변하는 시대에 나쁘지 않은 투자라는 계산이 선다. 특히 혼자 서비스를 만들고 운영하는 1인 빌더에게는 개발자 한 명의 인건비를 도구 구독으로 치환하는 셈이다.

Git과 GitHub: 세이브 파일과 인터넷 창고

도구를 깔았으면 작업을 저장할 곳이 필요하다. 클로드 코드가 코드를 고칠 때마다 그 변화를 저장해 두고, 잘못되면 이전 상태로 되돌릴 수 있어야 한다. 게임의 세이브 파일과 같은 역할을 하는 것이 Git이다. 맥에는 대부분 기본으로 들어 있고, 윈도우는 없을 수 있어 한 번만 직접 설치하면 된다(git-scm.com에서 설치 파일을 받아 옵션은 전부 기본값으로 두고 다음만 눌러 설치, 그 뒤 클로드 코드를 껐다 켠다).

GitHub은 이름 그대로 Git에 '허브(hub)'가 붙은 것으로, Git으로 저장한 기록을 인터넷 창고에 올려 두는 서비스다. Git이 내 컴퓨터 안의 저장이라면, GitHub은 그 기록이 인터넷에 보관되는 창고다. 이걸 연동하면 코드를 인터넷에 백업하고, 여러 기기에서 이어 작업하고, 나중에 사이트를 인터넷에 공개할 때도 쓴다.

연동은 이렇게 한다. GitHub 사이트에서 가입한 뒤, 클로드 코드로 돌아와 입력창 옆 플러스(+) 버튼에서 커넥트(Connect) 메뉴를 열고 GitHub를 선택해 방금 만든 계정으로 인증하면 끝이다. 이후에는 '지금까지 작업한 거 GitHub에 올려 줘'라고 말할 때마다 그 시점의 코드가 저장된다. 매 순간 자동이 아니라, 올려 달라고 할 때 저장된다는 점만 기억하면 된다.

프론트엔드와 백엔드: 시계 화면과 태엽

이제 사이트를 만드는데, 사이트는 크게 두 부분으로 나뉜다. 시계에 비유하면 이해가 쉽다. 시계에는 눈에 보이는 화면(시침·분침·숫자)이 있고, 그 뒤에서 돌아가는 태엽이 있다. 시계가 제대로 돌려면 둘 다 있어야 한다. 웹사이트도 똑같다. 눈에 보이는 화면이 프론트엔드, 화면 뒤에서 데이터를 저장하고 처리하는 부분이 백엔드다.

프론트엔드는 우리가 눈으로 보는 화면이다. 원래는 HTML·CSS·자바스크립트 같은 언어로 짜고, 자주 쓰는 기능을 미리 묶어 둔 '프레임워크'(리액트, 플러터, 리액트 네이티브 등 — 요리로 치면 밀키트)를 얹는다. 이름이 많아 겁먹기 쉽지만, 바이브 코딩에서는 이런 게 있다는 것만 알면 된다.

핵심은 순서다. 내가 만들 서비스의 규모를 먼저 가늠한다. 예를 들어 간단한 구독형 서비스라면 규모가 크지 않고 저장할 데이터도 적다. 그 규모를 클로드 코드에 말해 주고 거기에 맞는 언어·구성으로 짜 달라고 하면, 에이전트가 규모에 맞는 스택을 골라 준다. 마음에 안 들면 다른 걸로 바꿔 달라고 하면 그만이다. 이게 중요한 이유는, 작은 프로젝트에 맞는 구성으로 짜 두면 나중에 트래픽이 몰릴 때 사이트가 버티지 못할 수 있어서다. 처음부터 규모에 맞게 짜 두는 것이 그래서 중요하다.

클로드 코드에 주는 첫 지시 예시
간단한 한 페이지짜리 회사 소개 사이트를 만들어 줘.
어떤 스택과 언어로 만들지도 먼저 알려 주고,
이 정도 규모에 맞는 가벼운 구성으로 짜 줘.

백엔드의 벽과 두 매니저: Supabase와 Vercel

프론트엔드까지는 어렵지 않게 나온다. 문제는 그다음이다. 소개 페이지에 회원가입을 붙이고 게시판을 넣으려면 화면만으로는 안 된다. 데이터를 저장하고 처리하는 백엔드가 필요하다. 그리고 여기가 코딩을 안 배운 사람이 대부분 포기하는 지점이다. 백엔드에는 서버 프로그램, 데이터베이스, API, 배포, 포트처럼 챙길 것이 많기 때문이다.

예를 들어 회원가입 하나를 되게 하려면, 회원 정보를 담는 데이터 저장소가 있어야 하고, 화면과 저장소가 서로 소통하는 코드도 짜야 한다. 예전에는 이걸 위해 아마존 웹서비스 같은 곳에서 서버(컴퓨터)를 빌리고, 코드를 그 서버에 올리고, 웹서버 프로그램을 설치하고, 도메인을 연결하는 복잡한 과정을 다 거쳐야 했다.

이 복잡한 과정을 대신해 주는 매니저가 둘 있다. 하나는 Supabase — 서버 빌리기, 데이터베이스 만들기, 데이터 담기를 한 번에 처리해 주는 '데이터 매니저'다. 다른 하나는 Vercel — 완성한 사이트를 인터넷에 올리는 '배포 매니저'다. 원래 있던 복잡한 과정을 이 둘이 대신 넘겨 준다고 이해하면 충분하다.

Supabase 연동은 이렇다. supabase.com에 (GitHub 계정으로) 가입·로그인하고 새 프로젝트(New Project)를 만든다. 데이터베이스 비밀번호는 자동 생성(Generate) 버튼으로 만들고 따로 적어 둔다. 지역은 한국이면 서울을 고른다. 생성하면 그 순간 비어 있는 내 백엔드(서버)가 진짜로 만들어진다. 이제 상단 커넥트(Connect) 버튼이나 설정의 API 키에서 두 가지 — 프로젝트 URL(내 백엔드 주소)과 공개용 키(열쇠) — 를 복사해 클로드 코드에 붙여 넣고 '지금 만든 사이트를 이 Supabase와 연결해 줘'라고 하면, 연결 코드와 데이터 표(테이블)를 만드는 명령문까지 짜 준다. 그 명령문을 Supabase의 SQL 에디터에 붙여 넣고 실행(Run)하면 표가 생긴다. 이때 키는 비밀번호와 같으니 남에게 공개하면 안 되고, 클로드 코드에게 키를 넣는 전용 파일을 열어 달라고 해서 그 파일에 등록하는 것이 안전하다.

Vercel 배포는 이렇다. 지금까지 만든 사이트는 내 컴퓨터 안에서만 돌아간다(유튜브로 치면 편집만 끝내고 아직 업로드 전인 상태). vercel.com에 접속해 'Continue with GitHub'로 로그인하면 내 GitHub 창고와 바로 이어진다. Add New에서 프로젝트를 누르고, 아까 만든 사이트 저장소를 불러온 뒤 Deploy(배포) 버튼을 누른다. 잠깐 기다리면 '프로젝트이름.vercel.app' 같은 누구나 접속 가능한 인터넷 주소가 생긴다. 이제 내 컴퓨터가 꺼져 있어도 전 세계 누구나 그 사이트를 볼 수 있다. 게다가 앞으로 클로드 코드로 코드를 고쳐 GitHub에 올릴 때마다 Vercel이 자동으로 사이트를 최신 버전으로 갱신한다. '배포 매니저'라는 이름이 그래서 붙는다.

지도는 세 줄로 접힌다 (그리고 다음 지도)

여기까지가 바이브 코딩의 전체 지도다. 도구 세팅부터, 화면을 만들고, 화면 뒤 데이터를 채우고, 인터넷에 올리는 배포까지 한 바퀴를 돌았다. 이제 클로드 코드에 지시만 하면 사이트가 만들어질 준비가 끝난 것이다.

복습은 세 줄이면 된다. 첫째, 도구는 클로드 코드. 둘째, 프론트엔드는 만들 서비스의 규모를 말해 주고 언어·스택을 맡긴다. 셋째, 백엔드는 Supabase(데이터)와 Vercel(배포)에 맡긴다. 이 세 줄이 머릿속에 있으면, 낯선 용어가 나와도 그것이 지도의 어느 지점에 해당하는지 바로 짚을 수 있다.

다음 지도에서는 '만들어지긴 하는데 어떻게 하면 더 잘 만들게 할까'로 넘어간다. 하네스, MD(지시 문서), 스킬, 커넥트, API, 에이전트 같은 개념이 그때 등장한다. 이름은 어려워 보여도, 이미 편 지도 위에 얹히는 것들이라 순서대로 짚으면 어렵지 않다. 이 글은 혼잡스 채널의 '바이브 코딩 지도 한 장' 1부를 입문자 기준으로 정리한 것이다.