바이브 코딩 하는 법 왕초보 튜토리얼: 기본 개념부터 설치, 배포까지

머릿속에는 만들고 싶은 게 분명히 있는데, 코드를 한 줄도 짜본 적이 없어서 시작조차 못 하셨을 수도 있어요. 그런데 최근 몇 년 사이 이 풍경이 빠르게 바뀌고 있습니다. AI에게 한국어로 "이런 앱을 만들어줘"라고 말하면, AI가 코드를 대신 작성해주는 시대가 열렸기 때문입니다. 이렇게 AI와 대화하며 소프트웨어를 만들어가는 방식을 '바이브코딩(Vibe Coding)'이라고 부릅니다.

흥미로운 지점은, 바이브코딩을 가장 활발히 쓰는 사람들이 개발자가 아니라는 점입니다. Vercel의 'State of Vibe Coding 2025'에 따르면 사용자의 63%가 비개발자이고, 대표 플랫폼인 Replit의 사용자는 2026년 3월 기준 약 5,000만 명을 넘어섰습니다(Vercel, 2025; Replit, 2026).

같은 시점 전 세계 개발자 인구가 약 2,800만 명으로 추산된다는 점을 생각하면, 이미 '코드를 짜는 사람'보다 '코드를 짜지 않으면서 소프트웨어를 만드는 사람'이 더 많아진 셈입니다.

오늘은 이 흐름 속에서 비개발자가 어떻게 첫 도구를 만들 수 있는지, 전자책 『왕초보 바이브코딩 튜토리얼』의 챕터를 따라가며 핵심만 발췌해 보여드리겠습니다.

1. 바이브코딩 이해하기

먼저 바이브코딩이 정확히 무엇이고, 왜 지금 이 시점에 등장했는지부터 짚어보겠습니다. 단순한 트렌드가 아니라 시장과 사람의 역할 자체가 옮겨가고 있는 흐름이거든요.

1-2. 할 수 있는 것과 할 수 없는 것

기대를 살짝 가라앉히는 이야기부터 시작해야겠습니다. 바이브코딩으로 모든 것을 만들 수 있는 건 아니고, 한 번의 대화로 완벽한 결과가 나오지도 않습니다. 이 점을 처음부터 알고 시작하시면 나중에 "왜 한 번에 안 되지" 하는 좌절을 줄일 수 있습니다.

먼저 잘되는 영역입니다. 미국 뉴욕타임스 기자 케빈 루스(Kevin Roose)는 2025년 2월 바이브코딩 도구로 직접 만든 앱들을 공개했습니다. 냉장고에 있는 재료로 도시락 메뉴를 추천해주는 앱, 자녀가 그린 미술 작품을 자동으로 정리해주는 앱, 특정 물건이 자동차 트렁크에 들어갈 수 있는지 알려주는 앱이었습니다(New York Times, 2025.2). 모두 '내 일상의 작은 불편함을 해결하는 도구'입니다.

반대로 잘 안 되는 영역도 분명히 있어요. 2025년 7월 METR의 무작위 대조 실험에서, 숙련된 오픈소스 개발자들은 AI 코딩 도구를 사용했을 때 오히려 작업 속도가 19% 느려졌습니다(METR, 2025.7). 본인들은 24% 빨라질 거라 예측했고 실험 후에도 20% 빨라졌다고 믿었다는 게 흥미로운 지점입니다. 코드 품질 측면에서도 CodeRabbit이 470개의 오픈소스 풀 리퀘스트를 분석한 결과, AI 공동 작성 코드는 주요 결함이 약 1.7배, 보안 취약점은 약 2.74배 더 많이 발견됐습니다(CodeRabbit, 2025.12).

…(후략)

🤔 이외에 1장에는 이런 내용들이 있어요

• 1-1. 바이브코딩의 정의와 등장 배경 (47억 달러 시장이 어떻게 만들어졌는지, 시장 규모 추정표와 함께 정리)

• 1-3. 사람의 역할 변화 ('코드를 쓰는 사람'에서 '무엇을 만들지 정하는 사람'으로 옮겨가는 흐름, 채용 시장 변화 예시 포함)

2. AI와 일하기 위한 기본기

이제 본격적으로 AI에게 무언가를 부탁하기 전에, 알아두면 대화의 질이 달라지는 기본 용어들을 정리해보겠습니다. 변수, 함수 같은 단어를 외울 필요는 없지만 AI가 만들어준 결과물을 보고 '이건 화면 부분이구나' 정도는 알아볼 수 있어야 다음 요청이 정확해지거든요.

2-5. 프로그램끼리 말을 거는 방식: API

API라는 단어를 정말 자주 듣게 되실 텐데, 영어 풀이는 잠시 잊으셔도 됩니다. 핵심은 'API는 프로그램끼리 말을 거는 약속된 통로'라는 점입니다. 여러분이 만든 앱에서 사용자가 주소를 입력하면 지도가 표시되도록 하고 싶을 때, 지도를 직접 만들 수는 없으니 구글이 제공하는 'Google Maps API'라는 통로를 빌립니다.

여기서 반드시 알아두셔야 할 개념이 'API 키(API Key)'입니다. 이건 그 통로를 사용할 권한이 있다는 것을 증명하는 일종의 비밀번호인데요. 문제는 이게 새어 나가면 다른 사람이 여러분의 이름으로 서비스를 사용하고, 그 요금이 여러분에게 청구된다는 겁니다.

이건 바이브코딩에서 가장 흔히 발생하는 사고입니다. GitGuardian의 2026년 보고서에 따르면, 2025년 한 해 동안 공개된 GitHub 코드 저장소에서 발견된 하드코딩된 비밀번호와 키가 약 2,865만 건에 달했습니다. 특히 AI가 작성한 커밋에서 비밀번호가 노출되는 비율은 3.2%로, 전체 평균 1.5%의 두 배 수준이었습니다(GitGuardian, 2026.3). 배포 플랫폼 Vercel은 2025년 7월 한 달간 API 키 노출 관련 배포 1만 7,000건을 사전에 차단했고, AI 서비스의 자격증명 노출은 2025년에만 81% 증가했습니다.

그래서 API 키는 코드 안에 직접 적지 않고, '환경 변수(environment variable)'라는 별도의 안전한 공간에 보관하는 것이 원칙입니다.

…(후략)

🤔 이외에 2장에는 이런 내용들이 있어요

• 2-1. 프로그램과 코드의 개념 (요리 레시피 비유로 풀어쓴 프로그래밍 언어 입문)

• 2-2. 웹을 만드는 세 가지 재료: HTML, CSS, JavaScript (뼈대·옷·움직임 비유로 정리)

• 2-3. 화면과 뒷면: 프론트엔드와 백엔드 (카페 좌석과 주방 비유로 비교)

• 2-4. 데이터를 담는 곳: 데이터베이스 (Lovable 앱 1,645개 분석으로 본 보안 주의점)

• 2-6. 프레임워크와 라이브러리 (React, Next.js 같은 이름들의 정체 풀이)

• 2-7. 로컬과 배포 (집밥과 가게의 차이 비유)

• 2-8. 버전 관리와 깃 ('보고서_최종_진짜최종' 자동화의 안전망 역할)

• 2-9. 그 외 자주 만나는 말들 (서버, 클라이언트, 터미널, 디버깅 등 한 줄 정리)

3. 도구 생태계와 선택

이제 손에 쥘 도구를 골라야 할 시점입니다. Cursor, Lovable, Replit, GitHub Copilot, Bolt.new 같은 이름들을 들어보셨을 텐데, 각 도구가 잘하는 분야와 어울리는 사용자가 다르거든요. 큰 그림부터 한번 정리해보겠습니다.

3-1. AI 코딩 도구의 큰 그림: 앱 빌더와 코딩 어시스턴트

바이브코딩 도구는 크게 두 가지 유형으로 나뉩니다. 하나는 '앱 빌더(App Builder)', 다른 하나는 '코딩 어시스턴트(Coding Assistant)'입니다.

앱 빌더는 한국어(또는 영어)로 "이런 앱을 만들어줘"라고 부탁하면, AI가 화면 디자인부터 작동하는 기능까지 한 번에 만들어주는 도구입니다. 사용자는 코드를 직접 볼 필요가 거의 없어요. 대표적으로 Lovable, Bolt.new, Replit이 있습니다. 비유하자면 가구가 완성된 채로 배달되는 서비스에 가깝습니다.

코딩 어시스턴트는 조금 다릅니다. 코드 편집기라는 작업 공간 안에서, AI가 옆자리 동료처럼 코드를 같이 써주는 방식입니다. 사용자는 코드 파일을 직접 보면서 AI가 생성한 코드를 한 줄씩 확인할 수 있어요. 대표적으로 Cursor와 GitHub Copilot이 있고, 이쪽은 가구를 직접 조립하는 서비스에 가깝습니다.

이 구분은 절대적인 경계는 아닙니다. 다만 처음 도구를 고르실 때는 이 구분을 기준으로 삼으시면 선택이 한결 쉬워집니다.

…(후략)

🤔 이외에 3장에는 이런 내용들이 있어요

• 3-2. 도구별 특징과 적합 대상 (Cursor, Lovable, Replit, GitHub Copilot, Bolt.new 다섯 도구의 강점과 어울리는 사용자 비교, 월 10~25달러대 가격 정리표 포함)

• 3-3. 나에게 맞는 도구 고르기 (코드 거부감·만들고 싶은 것·예산 세 가지 기준으로 도구 선택하는 법, 한국어 사용자가 추가로 챙길 점, '졸업생 워크플로우' 개념)

4. AI에게 말하는 법

도구를 켜고 빈 입력창을 마주하면, 머리가 하얘지는 순간이 옵니다. 분명히 만들고 싶은 게 있었는데 막상 한 줄로 적으려고 하니 막막해지죠. 이 막막함은 여러분만의 문제가 아닙니다. 바이브코딩의 결과물은 결국 요청의 품질에서 결정되는데, 그 감각을 익히는 방법을 정리해보겠습니다.

4-2. 좋은 요청과 나쁜 요청

같은 도구를 쓰더라도 결과물이 천차만별인 이유는 대부분 요청의 차이에서 옵니다. 두 예시를 비교해보시면 차이가 또렷하게 느껴집니다.

나쁜 요청의 예: '할 일 관리 앱 만들어줘.'

좋은 요청의 예: '하루 단위로 할 일을 관리하는 1인용 웹 앱을 만들어주세요. 화면 상단에 오늘 날짜가 크게 표시되고, 그 아래에 할 일을 추가할 수 있는 입력창이 있습니다. 추가된 할 일은 체크박스와 함께 목록으로 보이고, 체크하면 가운데 줄이 그어집니다. 색감은 노션처럼 흰 배경에 검정 글씨를 기본으로, 강조색은 옅은 파란색을 써주세요.'

두 요청의 차이는 길이가 아니라 '구체성'입니다. 나쁜 요청은 AI가 채워야 할 빈칸이 너무 많아서, AI는 가장 흔한 형태로 추측해 만들고 그게 여러분의 머릿속 그림과 어긋날 가능성이 큽니다. 좋은 요청에는 네 가지 요소가 들어 있어요. 누가 쓰는지(1인용), 무엇을 하는 도구인지(하루 단위 할 일 관리), 화면 구성(상단 날짜, 입력창, 체크박스 목록), 그리고 분위기(노션 스타일, 흰 배경, 파란 강조색)입니다.

이 네 가지를 의식적으로 챙기는 것만으로도 첫 결과물의 만족도는 눈에 띄게 올라갑니다.

…(후략)

🤔 이외에 4장에는 이런 내용들이 있어요

• 4-1. 뭘 만들어달라고 해야 할지 모를 때 (빈 입력창 앞에서 막힐 때 던지는 작은 질문 세 가지)

• 4-3. 점진적 요청의 원칙 (한 번에 다 만들려다 실패하지 않는 흐름, '한계 벽' 현상 이해)

• 4-4. 수정 요청과 방향 잡기 (수정 요청에 꼭 넣어야 할 한 줄, 점점 어긋날 때 되돌아가는 법)

• 4-5. AI 결과물 판단하기 (코드를 못 읽어도 가능한 직접 눌러보기·입력해보기 점검법)

• 4-6. 에러와 한계, 자주 빠지는 함정 (에러 메시지 활용법, 존재하지 않는 패키지를 진짜처럼 만들어내는 환각 현상 대처)

5. 실전 체험: 첫 도구를 직접 만들어 보기

이론은 충분합니다. 이제 Lovable에 가입하고 첫 화면을 띄우는 일부터, 머릿속에 있던 작은 도구 하나를 실제로 만들고, 마지막에 링크 하나로 다른 사람에게 보여주는 단계까지 직접 해봅니다.

5-2. 나만의 도구 만들기

예시로 '오늘 할 일 목록' 도구를 함께 만들어보겠습니다. 익숙한 주제처럼 보이지만 입력창·목록·체크박스·삭제 버튼처럼 웹에서 자주 쓰이는 요소들이 골고루 들어가 첫 경험에 적합합니다.

가장 먼저 보낼 요청은 이렇게 시작합니다.

오늘 할 일 목록을 관리하는 웹 페이지를 만들어주세요. 상단에 '오늘의 할 일'이라는 큰 제목이 있고, 그 아래에 할 일을 입력할 수 있는 입력창과 '추가' 버튼이 있습니다. 입력창 아래에는 추가한 할 일들이 목록으로 표시되고, 각 항목 옆에는 체크박스와 삭제 버튼이 있어야 합니다. 전체적으로 흰 배경에 차분한 파란색 포인트를 사용해주세요.

30초에서 1분 정도 기다리시면 Lovable이 미리보기 화면에 첫 결과를 띄워줍니다. 처음 결과물을 보시면 두 가지 감정이 동시에 들 가능성이 높습니다. '와, 정말 만들어졌네'라는 놀라움과 '근데 내가 생각한 거랑은 조금 다른데'라는 어색함입니다. 둘 다 정상이에요. 개발자의 66%도 'AI 결과물이 거의 맞지만 완전히 정확하지 않은 것'을 가장 큰 불만으로 꼽았습니다(Stack Overflow Developer Survey, 2025).

여기서 자주 마주칠 문제 중 하나가 한국어 글자가 어색하게 보이는 문제인데요. Lovable이 기본으로 적용하는 폰트는 영어 기준이라 한국어 간격이 어색할 수 있습니다. 이럴 때는 이렇게 요청하시면 됩니다.

전체 화면의 한국어 폰트를 Pretendard로 바꿔주세요. 만약 Pretendard를 불러올 수 없다면 Noto Sans KR을 대신 사용해주세요.

…(후략)

🤔 이외에 5장에는 이런 내용들이 있어요

• 5-1. 도구 시작하기 (Lovable 가입과 영어 UI 적응법, 영어 버튼·한국어 의미 정리표, 첫 도구로 어떤 규모를 골라야 하는지)

• 5-3. 배포와 공유 (Publish 버튼 하나로 인터넷에 올리기, 주변 두세 명에게 먼저 보여주기, 배포 직전 챙길 보안 한 줄)

6. 한 걸음 더: 안전하게 오래 만드는 법

만든 것을 안전하게 오래 쓰려면 몇 가지 점검 습관이 필요합니다. AI는 빠르게 코드를 만들어주지만 그 코드가 안전하다는 보장은 하지 않거든요.

6-4. AI가 잘하는 일과 사람이 해야 하는 일

마지막으로 함께 정리해볼 부분이 있습니다. AI에게 무엇을 맡기고, 사람이 무엇을 직접 챙겨야 할지 구분하는 감각이에요. 이 감각이 잡혀 있어야 오래 만들 수 있습니다.

흥미로운 데이터부터 보겠습니다. METR이 2025년 7월 발표한 실험에서 숙련된 오픈소스 개발자들이 AI 코딩 도구를 썼더니 오히려 19% 느려졌습니다. 그런데 이들은 실험 전에 24% 빨라질 것이라고 예상했고, 실험이 끝난 뒤에도 20% 빨라졌다고 믿고 있었습니다(METR, 2025.7). 체감 생산성과 실제 생산성이 어긋날 수 있다는 뜻이죠.

AI는 반복적인 작업에서는 큰 도움이 됩니다. GitHub과 Accenture가 4,800명을 대상으로 진행한 연구에서 AI 도구 사용 시 태스크 완료 속도가 55% 빨라졌고, McKinsey가 150개 기업을 대상으로 한 연구에서도 루틴 코딩 작업 시간이 46% 줄었습니다. 다만 복잡한 구조 설계나 처음 보는 코드 이해 같은 영역에서는 직접 하는 것보다 더 오래 걸릴 수도 있습니다.

AI에게 맡기기 좋은 일

• 화면 디자인과 레이아웃 만들기

• 자주 쓰이는 기능(로그인 양식, 입력 칸, 버튼)의 기본 구조 작성

• 같은 패턴이 반복되는 코드 만들기

• 에러 메시지의 의미 해석

사람이 직접 챙겨야 할 일

• '무엇을 만들지' 결정하는 일

• '이 기능이 정말 필요한지' 판단하는 일

• 사용자 입장에서 결과물을 실제로 써보고 평가하는 일

• 보안과 데이터 보호 관련 의사결정

이 구분이 중요한 이유는, 비개발자도 충분히 할 수 있는 영역이 사람이 직접 챙겨야 할 일 쪽에 더 많기 때문입니다.

…(후략)

🤔 이외에 6장에는 이런 내용들이 있어요

• 6-1. AI 코드를 그대로 믿으면 안 되는 이유 (AI 공동 작성 코드의 보안 취약점이 사람 작성보다 2.74배 많다는 분석, OWASP Top 10 통과 실패율 데이터)

• 6-2. API 키와 비밀번호, 어디에 두어야 할까 (Vercel이 한 달간 차단한 1만 7,000건 사례, 환경 변수 사용 원칙 세 가지)

• 6-3. 만들고 나서 점검할 것들 (배포 전 다섯 가지 점검 항목, 패키지 환각 현상과 슬롭스쿼팅 공격 대처)

7. 부록

마지막은 책상 위에 두고 필요할 때마다 꺼내 보실 수 있는 손에 잡히는 참고 자료집입니다.

7-3. 복붙용 요청 템플릿 모음

빈 입력창 앞에서 막막해지는 경험은 누구에게나 옵니다. 그럴 때 그대로 복사해 사용하실 수 있는 요청 템플릿 중 하나를 보여드리겠습니다. 처음 도구를 만들 때 쓰는 큰 그림 요청 템플릿입니다.

[누가 쓰는지: 예. 나 혼자] 사용할 [무엇: 예. 독서 기록]
도구를 만들고 싶습니다.

화면 구성은 다음과 같이 부탁드립니다.
- 상단: [예. 책 제목을 적는 입력창과 추가 버튼]
- 중간: [예. 지금까지 입력한 책 목록]
- 하단: [예. 별점을 매기는 영역]

분위기는 [예. 따뜻한 베이지 톤, 둥근 모서리]로 만들어주세요.
한국어 글꼴은 Pretendard 또는 Noto Sans KR을 사용해주세요.
모바일에서도 잘 보이도록 반응형으로 만들어주세요.

대괄호 안의 내용만 본인 상황에 맞게 바꿔 넣으시면 됩니다. 처음 몇 번은 이대로 복사해 사용하시고, 익숙해지신 다음 본인 어투로 다듬어가시기를 권합니다.

…(후략)

🤔 이외에 7장에는 이런 내용들이 있어요

• 7-1. 용어 사전 (바이브코딩·프롬프트·앱 빌더·API 키·환각 등 자주 등장하는 용어를 마주치는 순서대로 정리)

• 7-2. 도구별 비교표 (Google AI Studio·GitHub Copilot·Cursor·Lovable·Bolt.new·Replit 여섯 도구의 분류·무료 한도·유료 가격·추천 사용자 한눈에 비교)

• 7-3. 복붙용 요청 템플릿 모음 (위 한 가지 외에도 부분 수정·에러 대응·한국어 추가·결제 연동·배포 직전 점검까지 총 7가지 상황별 템플릿)

• 7-4. 막혔을 때 체크리스트 (상황 파악부터 AI 재질문, 작업 범위 좁히기, 한국어·보안 점검까지 6단계 체크리스트)

이름은 또 바뀔 겁니다. 바이브코딩이라는 표현을 처음 만든 안드레아 카르파티(Andrej Karpathy)조차 2026년 2월에 "바이브코딩은 이미 구식이 됐고 이제는 에이전틱 엔지니어링으로 이동 중"이라고 말했습니다(Karpathy 발언, 2026.2). 그런데 본질은 의외로 그대로입니다.

무엇을 만들지 정하고, 말로 풀어내고, 결과를 직접 확인하고, 다시 고쳐 보는 흐름. 도구가 바뀌어도 이 감각만 손에 익혀두시면 다음 도구도 어렵지 않게 적응하실 수 있습니다.

IDC는 2026년까지 글로벌 2000대 기업 직무 역할의 40%가 AI 에이전트와 함께 일하게 될 것으로 전망했고(IDC, 2026), 또 다른 전망에서는 소프트웨어를 만들 수 있는 사람의 수가 현재 약 3,000만 명에서 잠재적으로 10억 명까지 확장될 수 있다고 봅니다(Taskade, 2026).

'만드는 사람'의 경계가 흐려지고, 자신의 일에 필요한 작은 도구를 직접 만들어 쓰는 사람이 평범한 풍경이 되는 시대입니다.

코드를 한 줄도 짜본 적이 없다는 사실은, 이제 더 이상 시작을 막는 이유가 되지 않습니다. 오늘의 한 줄 요청이 내일의 작은 도구가 되고, 그 작은 도구가 쌓이면 어느 순간 여러분의 일하는 방식 자체가 달라져 있을 거예요.

내일배움캠프는 모든 취업 준비생 여러분을 진심으로 응원합니다.