클로드코드부터 배포, 리전, 무료 플랜의 함정까지 — 바이브코딩으로 서비스 하나를 세상에 내보내는 데 실제로 알아야 할 것들을 목공방 김 사장님을 따라 정리했습니다.
컴윗
· 18분 읽기
바이브코딩의 흐름은 생각보다 단순합니다. 아이디어를 넣고, AI와 같이 만들고, 남들이 접속할 수 있게 배포하면 됩니다.
바이브코딩을 한번 해보려고 검색창을 열면, 제일 먼저 만나는 게 용어 폭탄이더라고요. 클로드코드, 코덱스, v0, 러버블, 터미널, 리전, 배포. 이름만 우르르 쏟아지는데, 정작 "그래서 나는 지금 뭘 누르면 되지?"엔 아무도 딱 답을 안 해주죠.
그래서 이 글에서는 시작부터 배포까지, 뭐가 뭔지 제 나름대로 한번 정리해보려 합니다. 겁나 보이는 단어도 뜻만 알면 대개 별거 아니더라고요. 아래 설명들이 좀 더 와닿게, 인물 하나 설정하고 갑니다. 동네에서 작은 목공방을 하는 김 사장님. 손님이 온라인으로 수업 예약을 넣을 수 있는 페이지 하나를 직접 만들어보기로 했어요. 이런 분이 바이브코딩을 한다면 뭘 어떻게 해야 할지, 사장님을 따라가며 하나씩 살펴볼게요. (나오는 요금은 2026년 7월 8일 기준이라, 결제 전엔 각 서비스 공식 페이지에서 한 번 더 확인하는 게 좋아요.)
먼저, 우리가 만드는 건 '앱'이 아니라 '서비스'입니다
많이들 "앱을 만든다"고 하는데, 엄밀히 말하면 바이브코딩으로 처음 만드는 건 대부분 웹 서비스입니다. 브라우저에서 주소로 접속하는 것 말이에요. 아이폰 앱스토어에 올리는 그 '앱'과는 다릅니다.
이 구분이 왜 중요하냐면, 웹 서비스는 시작이 훨씬 쉽기 때문입니다. 앱스토어 심사도 필요 없고, 링크만 있으면 누구나 바로 들어올 수 있습니다. 혼자 쓰는 예약 신청 폼, 작은 습관 기록장, 문의 접수 페이지, 내부 업무 도구 같은 건 대개 웹으로 충분합니다.
댓글 0
첫 댓글을 남겨보세요.
그래서 이 글에서도 '앱'이라는 말 대신 '서비스'라고 부르겠습니다. 우리가 만들려는 건 링크 하나로 열리는 그것이니까요.
뭘로 만드냐, 처음엔 클로드코드를 권합니다
도구 이야기부터 하죠. 바이브코딩 도구는 결이 조금씩 다릅니다. v0나 러버블처럼 말하면 화면부터 뚝딱 뽑아주는 빌더가 있고, 커서 같은 AI 코드 에디터도 있고, 클로드코드와 코덱스처럼 실제 프로젝트를 읽고 고쳐주는 코딩 에이전트도 있습니다.
처음 서비스 하나를 제대로 만들어보려는 사람에게는, 저는 우선 클로드코드나 코덱스 쪽을 권합니다. 둘 다 말로 시키면 실제 파일을 읽고, 코드를 고치고, 실행해보고, 다시 수정하는 도구입니다. 예전에는 터미널이라는 검은 화면에서만 돌리는 느낌이 강했는데, 요즘은 데스크톱 앱이나 웹에서도 점점 편하게 씁니다.
Claude Code도 이렇게 데스크톱 앱에서 대화하듯 씁니다. 코드베이스를 읽고, 파일을 수정하고, 실행 결과를 보며 작업하는 코딩 에이전트예요. 이미지: Anthropic 공식 Claude Code 제품 페이지.
Codex 앱은 여러 작업 스레드, 코드 변경 리뷰, Git 작업을 한 화면에서 다루는 데 초점을 둔 데스크톱 경험입니다. 이미지: OpenAI Developers 공식 Codex 앱 문서.
돈 이야기도 해야겠죠. 둘 다 구독 안에서 쓰는 구조라, 한눈에 보면 이렇습니다. (2026년 7월 기준)
도구
시작(발 담그기)
진지하게 쓸 때
비고
클로드코드
Claude Pro 월 $20
Max 월 $100 · $200
Pro·Max 구독으로 사용. 연 결제 시 Pro는 월 $17꼴
코덱스
ChatGPT Plus 월 $20 (무료·Go $8도)
ChatGPT Pro 월 $100 · $200
ChatGPT 구독에 포함, 따로 결제할 것 없음
다만 솔직히 말하면, 월 20달러짜리는 "맛보기와 작은 작업"에 가깝습니다. 서비스를 조금 진지하게 만들기 시작하면 사용량 한계에 금방 닿습니다. 한창 코드를 짜는 중에 "오늘 치 다 썼습니다" 소리를 듣는 거죠. 그래서 꾸준히 만드는 사람들은 대개 월 100달러 안팎의 상위 플랜까지 생각합니다. 도구값만 월 10만 원대는 잡아두는 편이 마음이 편합니다. 그리고 이건 뒤에 나올 배포 비용을 뺀 값입니다.
그럼 둘 중 뭐로 시작하느냐. 처음이라면 저는 클로드코드를 권하는 편입니다. 이유가 하나 있어요. 코덱스는 지시를 좀 더 또박또박 해줘야 하는 쪽에 가깝고, 클로드코드는 애매하게 말해도 의도를 꽤 잘 받아주는 편입니다. 초보는 애초에 뭘 어떻게 시켜야 할지 모르는 게 반이잖아요. 그 관대함이 생각보다 크게 다가옵니다. 물론 정답은 없습니다. 이미 ChatGPT를 쓰고 있어서 추가 결제 없이 시작하고 싶다면 코덱스도 충분히 좋은 선택이고요. 우리 김 사장님도 클로드코드를 켜고 "목공방 수업 예약받는 페이지 만들어줘" 하고 첫 말을 건넸다고 해두죠.
시작에 필요한 건, 사실 아이디어 하나입니다
거창한 기획서나 개발 지식은 필요 없습니다. 정말 필요한 건 작은 서비스 아이디어 하나입니다. 습관 기록장이든, 예약 신청 폼이든, 문의 접수 목록이든, 한 사람이 한 가지 일을 하는 작은 것이면 됩니다.
그 서비스를 쓸 사람 한 명만 머릿속에 정해두면 한결 수월해요. 우리 김 사장님이라면 "손님이 원하는 수업 날짜를 고르고, 이름과 연락처를 남긴다" 정도가 전부입니다. 스터디원이 매주 과제를 체크하든, 내가 매일 운동 기록을 남기든, 원리는 같아요. 그 사람이 하고 싶어 하는 일이 곧 만들 기능이 되고요.
위에서 고른 도구 하나면 준비는 끝입니다. 테스트에 쓸 가짜 데이터 같은 건 굳이 직접 안 만들어도 돼요. "샘플로 예약 몇 개 넣어줘" 하면 AI가 알아서 만들어주거든요.
여기서 오해하기 쉬운 게 하나 있어요. "작게 시작하라"는 말은 서비스를 심플하게 가라는 뜻이지, 지시를 잘게 쪼개라는 뜻이 아니에요. 오히려 지시는 한 번에 왕창 몰아주는 편이 편하더라고요. 클로드코드나 코덱스는 시간이 좀 걸리는 긴 작업을 알아서 처리하는 도구라, 10분마다 들여다보며 하나씩 시키는 것보다 "예약 페이지 이렇게 통째로 만들어줘" 하고 맡긴 다음 결과를 보고 피드백하는 게 저는 더 수월했어요.
대신 기능을 자꾸 붙이는 건 다른 얘기예요. 김 사장님도 처음엔 딱 "날짜 고르고 예약 남기기"부터. 로그인·회원가입은 서비스라면 대개 있어야 하니 기본으로 잡되, 카카오 로그인이나 알림 보내기 같은 건 나중으로 미뤄도 됩니다. 일단 만들어서 직접 써봐야 뭐가 진짜 필요한지 감이 오는데, 써보지도 않고 머릿속으로 거대하게 기획만 해두면 정작 안 쓰는 기능만 잔뜩 나오기 쉽거든요.
잠깐, 프론트엔드와 백엔드가 뭔가요
배포로 넘어가기 전에 단어 두 개만 짚고 가겠습니다. 이걸 알면 뒤에 나올 이야기가 훨씬 쉬워집니다.
우리가 만드는 서비스는 크게 두 부분으로 나뉩니다. 하나는 사용자가 눈으로 보는 화면입니다. 버튼, 글자, 색깔, 목록, 입력창 같은 것들이죠. 이걸 프론트엔드라고 합니다. 다른 하나는 그 화면 뒤에서 데이터를 저장하고 처리하는 부분입니다. 회원 정보를 기억하고, 주문을 받아 적고, 로그인을 확인하는 일. 이걸 백엔드라고 부릅니다.
프론트엔드는 손님이 보는 홀, 백엔드는 실제 일이 벌어지는 주방, 데이터베이스는 재료 창고에 가깝습니다.
식당으로 비유하면 딱 떨어집니다. 프론트엔드는 손님이 앉는 홀입니다. 인테리어와 메뉴판, 눈에 보이는 전부죠. 백엔드는 주방입니다. 손님 눈엔 안 보이지만 실제로 요리가 벌어지고 재료가 오가는 곳. 여기에 재료 창고에 해당하는 게 데이터베이스입니다.
김 사장님 예약 페이지로 옮겨볼까요. 손님이 수업 날짜를 고르고 이름을 적는 그 화면이 홀, 곧 프론트엔드예요. 뒤에서 그 예약을 받아 처리하는 쪽이 주방인 백엔드, 예약이 하나씩 쌓이는 곳이 창고인 데이터베이스고요.
그런데 여기서 사장님이 놓치기 쉬운 게 하나 있어요. 손님이 넣은 예약을, 정작 사장님은 어디서 보죠? 손님용 화면 하나로는 부족합니다. 사장님이 들어온 예약을 확인하고, 취소하거나 정리하는 화면이 따로 있어야 하거든요. 이걸 흔히 관리자 페이지라고 불러요. 겉으로는 예약 폼 하나처럼 보여도, 실은 손님용 화면과 사장님용 관리자 화면, 두 개를 만들어야 하는 셈이죠. 이것도 처음엔 자주 잊고 지나가는 부분이에요.
그럼 기술스택은 뭐냐. 이 홀과 주방을 지을 때 쓰는 도구와 재료의 묶음을 말합니다. 다행히 바이브코딩에서는 처음부터 이걸 직접 고를 일이 많지 않습니다. AI가 알아서 정해주는 경우가 많거든요. 그래도 요즘 표준처럼 많이 쓰는 조합 하나는 알아두면 좋습니다. 바로 Next.js입니다. 화면을 만드는 React에 서버 기능까지 얹은 도구라서, 프론트엔드와 백엔드를 어느 정도 한 번에 처리해줍니다. 공교롭게도 이걸 만든 회사가 뒤에 나올 배포 플랫폼 Vercel이라, Vercel에 올릴 때 궁합이 좋고요.
정리하면, 스택은 처음엔 AI에게 맡겨도 됩니다. 다만 이 그림 하나는 기억해두면 좋아요. 화면이 있고, 뒤에서 일하는 서버가 있고, 데이터를 넣어두는 창고가 있다. 이 정도만 알아도 배포에서 훨씬 덜 헤매더라고요.
진짜 관문은 다 만든 다음에 옵니다
자, 김 사장님이 클로드코드와 며칠 씨름한 끝에 예약 페이지를 완성했습니다. 그런데 화면이 뜨는 곳은 아직 사장님 노트북 안뿐이에요. 손님한테 링크를 보내려는 순간 깨닫습니다. 만드는 것과 남한테 보여주는 건 다른 일이라는 걸.
내 컴퓨터에서만 돌아가는 걸 남들이 접속하게 하려면 배포라는 걸 해야 합니다. 쉽게 말하면 24시간 켜져 있는 남의 컴퓨터, 그러니까 서버를 빌려서 내 서비스를 얹어두는 일이에요. 그래야 사장님이 노트북을 꺼도 예약 페이지가 살아 있습니다.
이 서버가 몇 가지 종류로 나뉩니다. 미리 만들어둔 화면을 그대로 보여주기만 하는 정적 호스팅이 있고, 누가 접속할 때만 잠깐 코드를 돌리고 끄는 서버리스가 있습니다. 마지막으로 통째로 24시간 켜두는 상시 서버도 있고요.
이 중 서버리스는 조금 더 설명할 값어치가 있습니다. 이름은 '서버가 없다'는 뜻처럼 보이지만, 진짜 없는 건 아닙니다. 서버를 내가 신경 안 써도 된다는 쪽에 가깝습니다. 손님이 문을 두드릴 때만 불이 켜지고, 일 끝나면 다시 꺼지는 가게라고 보면 됩니다. 안 쓰는 동안엔 돈이 거의 안 나가니까, 하루에 몇 명 올까 말까 한 초기 서비스엔 딱입니다.
그런데 바로 이 "안 쓰면 꺼진다"가 양날의 검입니다. 아무도 안 들어오면 서버가 잠들고, 누가 오랜만에 접속하면 다시 깨우는 데 시간이 걸립니다. 이 첫 응답이 유독 느린 걸 콜드 스타트라고 부릅니다. 차갑게 식어 있다가 처음 켜질 때 느리다는 뜻입니다.
예를 들어 Render 무료 웹 서비스는 15분 동안 요청이 없으면 잠들고, 다음 요청 때 다시 뜨는 데 1분쯤 걸리기도 합니다. 김 사장님 예약 페이지가 밤새 조용하다가 아침에 첫 손님이 열었을 때 화면이 1분간 안 뜬다면, 무료라는 말이 마냥 반갑지만은 않겠죠.
배포 플랫폼 이름은 많지만, 질문은 세 개입니다
플랫폼 이름을 보면 또 겁이 납니다. Vercel, Cloudflare, Netlify, Render, Railway, Fly.io, Supabase. 처음 보는 이름이 한꺼번에 몰려오죠.
김 사장님도 이 이름들 앞에서 한참 멈칫했는데, 사실 초보 입장에선 질문을 세 개로 줄이면 됩니다.
첫째, 화면을 어디에 올릴 것인가. Vercel, Netlify, Cloudflare Pages 같은 곳이 이쪽입니다. Next.js로 만들었다면 Vercel이 제일 편한 선택일 때가 많습니다. 대신 Vercel의 Hobby 플랜은 개인·비상업 용도이고, 상업적으로 쓰려면 Pro나 Enterprise로 가야 합니다.
둘째, 서버가 잠들어도 괜찮은가. 초기 테스트나 내부 도구라면 잠깐 느려도 괜찮을 수 있어요. 하지만 손님이 들어왔는데 첫 화면이 한참 안 뜨면 곤란한 서비스라면, 슬립이 있는 무료 플랜은 좀 아슬아슬하더라고요. Render 무료 플랜은 실험용으론 좋은데, 콜드 스타트가 있다는 걸 알고 쓰는 게 마음 편했어요. Railway나 Fly.io는 더 직접적으로 서버를 띄우는 느낌에 가깝고, 쓰는 만큼 내는 감각이 강하고요.
셋째, 데이터는 어디에 저장할 것인가. 화면을 올리는 곳과 데이터베이스는 보통 다릅니다. Supabase 같은 곳이 여기서 자주 나옵니다. 로그인, 데이터베이스, 파일 저장 같은 걸 한꺼번에 묶어주기 때문입니다. 다만 Supabase 무료 프로젝트도 활동이 낮으면 7일 기준으로 멈출 수 있습니다. 무료는 무료지만, 운영 서비스처럼 항상 깨어 있는 걸 보장하는 무료는 아닙니다.
세 질문을 한 장으로 옮기면 이렇게 됩니다. (2026년 7월 기준이라 결제 전엔 각 공식 페이지 확인)
플랫폼
역할
무료
유료 시작
단가·주의
Vercel
화면 호스팅
개인·비상업만
월 $20/명
대역폭 1TB 포함, 초과분 GB당 $0.15
Cloudflare
화면 호스팅
하루 10만 요청
월 $5
1천만 요청 포함, 초과는 100만 건당 소액
Netlify
화면(정적)
있음
사용량
DB 없음, 함수 60초 제한
Render
상시 서버
월 750시간(슬립)
월 $7
무료는 15분 뒤 잠들어 콜드 스타트
Railway
상시 서버
사실상 없음(첫 달 $5 크레딧)
종량제
쓴 만큼 초 단위 과금
Fly.io
상시 서버
없음(카드 필수)
월 ~$2부터
트래픽(egress) GB당 $0.02
Supabase
DB·로그인
500MB(1주 뒤 멈춤)
프로토타입은 금방 나오지만, 실제 서비스가 되려면 호스팅, 데이터베이스, 로그인, 도메인, 환경변수, 비용 한도 같은 조각이 연결되어야 합니다.
문제는 이걸 하나로 못 끝낸다는 데 있습니다. 실제로는 화면은 Vercel, 데이터베이스는 Supabase, 로그인도 따로, 도메인도 따로, 비밀번호 같은 환경변수도 손으로 넣는 식이 됩니다. 서비스 하나를 세상에 내보내려면 서너 개 조각을 직접 이어 붙여야 합니다.
바이브코딩으로 화면이 뜨는 순간은 꽤 신납니다. 그런데 사람들이 조용히 손을 놓는 자리는 대개 그다음입니다. "내 컴퓨터에서는 됐는데 배포하면 안 돼요." "환경변수가 뭐예요?" "DB URL은 어디 넣어요?" "도메인은 연결했는데 왜 안 떠요?" 이 구간입니다.
서비스 만들기가 쉬운 80%라면, 이 붙이는 작업이 지겨운 20%입니다. 그리고 그 20%가 생각보다 질깁니다.
리전은 서버의 위치입니다
배포를 고르다 보면 리전이라는 말이 꼭 나옵니다. 이거 하나 알아두면 나중에 "왜 우리 서비스가 이렇게 느리지?"를 덜 헤맵니다.
리전은 서버가 실제로 놓인 데이터센터의 위치를 뜻합니다. 서울 리전이면 한국에, 미국 리전이면 미국에 컴퓨터가 있는 겁니다. 한국 사용자가 미국 리전에 접속하면 데이터가 태평양을 왕복합니다. 아무리 코드가 잘 짜여 있어도 물리 거리는 못 이깁니다.
김 사장님한테는 이게 남 얘기가 아니에요. 예약하는 손님이 대부분 동네, 넓게 봐도 한국 사람이잖아요. 그러면 예약 페이지 서버가 미국에 있느냐 한국에 있느냐가 곧 손님이 체감하는 속도가 됩니다.
여기에 CDN이라는 것도 있습니다. 전 세계에 화면 조각을 미리 복사해두고, 사용자에게 가까운 곳에서 꺼내주는 구조입니다. 글로벌 서비스가 어디서든 빠르게 뜨는 이유가 이겁니다.
그런데 한국에서는 좀 조심할 게 있어요. "글로벌 CDN이니까 한국에서도 무조건 빠르겠거니" 했다간 어긋날 수 있거든요. Cloudflare는 서울 데이터센터를 운영하고, Cloudflare Radar에서도 한국 라우팅 정보를 볼 수 있습니다. 하지만 실제 접속 경로는 통신사 피어링과 BGP 라우팅에 따라 달라집니다. 과거에도, 최근에도 한국 사용자가 가까운 국내 지점이 아니라 해외 POP으로 빠진다는 사례가 반복적으로 보고됐습니다.
더 곤란한 건, 이걸 요금제만 올려서 풀기가 어렵다는 점입니다. 한국 사용자를 서울 지점에 안정적으로 붙이려면 사실상 기업용(엔터프라이즈) 계약까지 가야 하는 경우가 많다고 알려져 있고, 그 계약도 서비스 만드는 사람이 아니라 도메인 주인이 직접 해야 하는 구조에 가깝습니다. 개인이나 작은 서비스가 Pro 요금제 하나 결제한다고 해결되는 문제가 아닌 셈이죠.
서버가 '어딘가에 있다'는 말만 봐선 알기 어려워요. 한국 손님한테는 그 데이터가 실제로 어느 길로 오가느냐가 체감 속도를 좌우하더라고요.
그래서 한국 손님이 많은 서비스라면, "글로벌 CDN이라 빠릅니다"라는 말만 믿기보다 한국에서 실제로 어디로 붙는지 한 번쯤 확인해보면 좋을 것 같아요. 리전이나 라우팅이 개발자만 쓰는 어려운 말처럼 들리지만, 따지고 보면 손님이 첫 화면을 얼마나 빨리 보느냐랑 그대로 이어지거든요.
가격표가 알려주지 않는 것들
요금표만 보고 고르면 십중팔구 당황합니다. 무료라는 단어부터 그래요. 앞에서 본 Render의 슬립이나 Supabase의 멈춤처럼, 같은 '무료'라도 조건이 제각각입니다. Vercel 무료 플랜은 상업적 사용에 제한이 있고, Netlify는 아예 한도를 딱 걸어 비용 사고를 막는 대신 그 선에 닿으면 멈춥니다. 공짜라는 말이 '언제든 켜져 있고 마음껏 쓴다'는 뜻은 아니라는 거죠.
초과 요금도 마찬가지입니다. 평소엔 몇 천 원이다가 글 하나가 터져서 트래픽이 몰리면 청구서가 갑자기 커질 수 있습니다. 특히 이미지가 많거나, 파일 다운로드가 많거나, AI API를 붙였거나, 서버 함수가 자주 돌면 "작은 서비스니까 싸겠지"가 쉽게 깨집니다.
그래도 제일 큰 함정은 따로 있습니다. 바로 조합입니다. 화면은 여기, DB는 저기, 로그인은 또 다른 곳, 도메인은 다른 회사, 비밀키는 환경변수. 이 조각들을 전부 내 손으로 이어 붙여야 서비스가 돌아갑니다.
이게 실력의 문제가 아니라, 원래 지겹고 낯선 준비 작업이라 그렇습니다. 특히 비개발자는 에러 메시지를 읽어도 어디가 문제인지 모릅니다. AI에게 물어보려 해도 뭘 붙여 넣어야 할지 모르고요. 그러다 어느 순간 "그냥 나중에 해야겠다"가 됩니다.
그래서 컴윗은 이 20%를 줄이려 합니다
시작에 필요한 지식은 지금까지 훑은 게 거의 전부입니다. 웹 서비스는 화면과 서버와 데이터베이스로 나뉜다. 배포는 남들이 접속할 수 있게 올리는 일이다. 무료 플랜은 전부 같은 무료가 아니다. 한국 사용자를 보면 리전과 라우팅도 중요하다. 이 정도면 첫 지도를 얻은 셈입니다.
하지만 지도를 안다고 해서 길이 편해지는 건 아닙니다. 도구값은 진지하게 쓰면 월 100달러 안팎까지 생각해야 하고, 배포 비용은 또 별도로 붙습니다. 돈보다 더 큰 벽은 직접 이어 붙이는 시간입니다. 배포 플랫폼을 고르고, 리전을 따지고, 데이터베이스를 붙이고, 환경변수를 넣고, "내 컴퓨터에선 됐는데 올리면 깨지는" 문제를 검색해가며 넘는 일. 이게 바이브코딩 입문자가 제일 많이 멈추는 자리입니다.
이 지겨운 20%를 대신 줄여두는 게 저희 컴윗이 하려는 일입니다. 컴윗에 가입하면 코드 템플릿부터 배포, 데이터베이스 연동, 로그인, 도메인 같은 기본 세팅을 한 번에 가져갈 수 있게 만들고 있습니다. 아까 김 사장님이 깜빡했던 관리자 페이지도, 컴윗에선 처음부터 딸려 나오게 세팅해두고요. 손으로 하나하나 이어 붙이던 과정을 최대한 건너뛰고, 한국 사용자 기준으로 빠르게 도는 인프라를 바로 쓰게 하는 거죠.
그리고 어디선가 막히면, 바이브코딩은 원래 어디선가 막히거든요, 그때 혼자 문서와 커뮤니티에 던져두지 않으려 합니다. 문의하면 현직 개발자가 프로젝트 맥락을 보고 같이 풀어주는 구조를 만들고 있습니다. 혼자 이틀 헤맬 일이, 옆에서 봐줄 사람이 있으면 십 분에 끝나기도 하니까요.
김 사장님에게 필요했던 건 결국 "수업 예약을 받고 싶다"는 생각 하나였습니다. 그 뒤에 줄줄이 붙는 벽은, 굳이 혼자 다 넘지 않아도 됩니다.
바이브코딩의 흐름은 생각보다 단순합니다. 아이디어를 넣고, AI와 같이 만들고, 남들이 접속할 수 있게 배포하면 됩니다.
