https://www.youtube.com/watch?v=smW3raqdTv0
# 1. 이건 꼭 알아야 한다[^1]
[? 질문] 왜 최근 몇 달 사이 **바이브 코딩(Vibe Coding)** 관련 서비스(예: Lovable)의 트래픽이 크게 줄었는가[^1]
[= 답] “코딩을 몰라도 제품을 만들 수 있다”는 초반의 기대와 달리, 서비스가 **고도화(외부 API/DB/인증/운영)** 단계로 가면 바이브 코딩 도구만으로는 한계가 뚜렷해 많은 사용자가 **개발자용 코딩 에이전트(Cursor, Claude Code, Codex CLI 등)**로 이동했기 때문이다.[^2]
[? 질문] 바이브 코딩으로 SaaS를 ‘진짜로 운영/수익화’ 가능한 수준까지 만들려면 무엇을 최소한 알아야 하는가[^3]
[= 답] 프론트엔드/백엔드, API, 에러 유형, 프레임워크 vs 라이브러리, DB, 스토리지, 인증, 이메일, 배포, 모니터링 등 **운영까지 이어지는 필수 개발 개념 10가지**는 “전문가 수준이 아니어도” 최소 개요를 이해하고 있어야 한다.[^4]
[? 질문] 현실적으로 가장 효율적인(초기 비용도 낮춘) 바이브 코딩 기반 SaaS 개발 스택/서비스 조합은 무엇인가[^5]
[= 답] (1) **Next.js**로 프론트/백을 한 프레임워크에서 처리하고,[^6] (2) **Supabase**로 DB/인증/스토리지를 묶어 해결하며,[^7] (3) **Resend**로 이메일을 붙이고,[^8] (4) **Vercel**로 배포,[^9] (5) **Sentry**로 모니터링까지 구성하는 조합을 제시한다(초기 무료 플랜 활용 가능).[^^10]
---
# 2. 큰 그림[^11]
이 콘텐츠는 한때 크게 유행했던 **바이브 코딩**(AI가 생성한 코드를 이해하지 못해도 자연어 지시로 개발을 진행하는 방식)이 왜 최근 주목도가 감소했는지 배경을 설명하고, 그럼에도 불구하고 바이브 코딩으로 **SaaS를 실제 운영/수익화 단계까지** 끌고 가려면 어떤 기본 개념과 기술 스택을 갖춰야 하는지 “현실적인 가이드”를 제공한다.[^11]
- **환상에서 운영 현실로의 전환**: MVP 수준은 빠르게 만들 수 있지만, 운영 단계(인증/DB/배포/모니터링)에서 막히며 도구 트래픽이 감소했다는 관찰을 제시한다.[^2]
- **‘무지성 수락’의 한계**: 바이브 코딩은 AI가 만든 코드를 이해하지 못한 채 모두 수락하는 개발을 의미하며, 운영/수익화까지 가려면 최소한의 개발 개념 이해가 필요하다고 주장한다.[^12]
- **최소 스택의 제안**: 초보/초기 서비스일수록 스택을 늘리기보다 **Next.js + Supabase + Resend + Vercel + Sentry**처럼 핵심만 묶어 생산성을 높이라고 권한다(무료 플랜 근거 포함).[^7]
---
# 3. 하나씩 살펴보기[^13]
## 3.1 바이브 코딩 서비스 트래픽 감소 관찰: “왜 예전만큼 얘기가 없나”[^1]
영상은 “최근 몇 달” 동안 바이브 코딩 주요 서비스들의 트래픽이 크게 줄고, 바이브 코딩 자체에 대한 언급도 예전만큼 많지 않다는 문제 제기로 시작한다.[^1]
그 사례로, 과거 채널에서도 다뤘고 사용자도 많았던 “바이브 코딩 서비스 **Lovable(러버블)**”의 트래픽이 “몇 달간 거의 절반 이상” 감소했다는 언급을 제시한다.[^1]
화자는 링크드인에 올라온 자료(“크로스트 데이터 코파운더”가 올린 글)에서 여러 바이브 코딩 툴(예: Lovable, Replit, V0, Bolt 등)이 한때 매우 ‘핫’했음을 나열하며 당시 생태계가 다수의 툴로 확장되었음을 상기시킨다.[^2]
그리고 그중에서도 Lovable은 초기에 사용자가 급격히 늘었으나, 최근 들어 사용자가 “거의 절반 가까이” 줄었다는 그래프 흐름을 근거로, 단순 관심 감소가 아니라 **실사용 단계에서의 이탈**이 있었음을 암시한다.[^2]
> [!NOTE] 관찰 포인트: “유행/언급 감소”가 아니라, 실제 트래픽 지표에서 “절반 수준 감소”가 확인된다는 식으로 문제를 설정한다.[^1]
---
## 3.2 ‘Vibe Coding’ 용어의 확산 배경: 카파치 언급 이후 붐이 왔다[^2]
화자는 2025년 2월경 오픈AI 공동 창립 멤버 중 한 명으로 소개되는 **안드레이 카파치(Andrej Karpathy)**가 트위터에 글을 올린 것을 계기로 “바이브 코딩”이라는 용어가 확산되기 시작했다고 설명한다.[^2]
즉, 해당 용어가 유행을 타면서 관련 서비스가 급증했고, 그에 따라 사용자/트래픽도 폭증하는 “붐”이 만들어졌다는 인과를 제시한다.[^2]
이 시기의 분위기를 화자는 “용어 자체에 환상이 있었다”고 묘사한다. 즉, 바이브 코딩을 통해 “코딩을 아무것도 몰라도 프로덕트를 만들 수 있다”는 기대가 시장에 널리 퍼졌다는 것이다.[^14]
그리고 그 기대는 완전히 허상이 아니라, 실제로 “어느 정도 서비스까지는” 비개발자도 바이브 코딩 서비스를 활용하면 제품 개발이 가능해지는 사례가 있었다고 인정한다.[^14]
---
## 3.3 트래픽 감소의 이유: ‘MVP는 되는데 운영/고도화에서 막힌다’[^2]
화자는 가장 핵심적인 원인 설명으로, 초기에 엄청난 환상을 갖고 개발에 뛰어든 비개발자들이 다음 단계에서 한계를 경험했다고 말한다.[^2]
- **가능했던 구간**: “간단한 수준의 프로덕트”, 즉 MVP/초기 단계는 만들 수 있다.[^15]
- **막히는 구간**: 서비스가 조금 더 고도화/복잡해지고,
- 외부 API 연동
- 데이터베이스
- 인증
같은 기능이 붙어야 하는 상황에서 한계를 느낀다.[^2]
이 한계 경험이 누적되면서, 최근에는 전통적인 바이브 코딩 서비스(앱을 ‘통째로 만들어주는’ 성격의 도구)보다 **개발자들이 많이 활용하는 코딩 에이전트**인 커서(Cursor), 클로드 코드(Claude Code), 코덱스 CLI(Codex CLI) 쪽으로 주류가 이동하고 있다고 진단한다.[^2]
화자는 “바이브 코딩을 시도해 본 분들은 알겠지만 아직 한계가 명확하다”고 말하며, 이 문제를 개인 경험/일반 경험의 공감대로도 연결한다.[^2]
---
## 3.4 바이브 코딩이 잘 되는 영역 vs 부족한 영역: “만드는 것”과 “운영하는 것”의 차이[^15]
화자는 바이브 코딩 서비스의 장점도 분명히 말한다.
- “간단한 서비스까지는 문제가 없다.”[^15]
- “굉장히 빠르게 만들어 주고”, 때로는 “직접 개발하는 것보다 퀄리티가 더 높게 나오는 경우도 많다.”[^15]
하지만 **운영 단계로 배포해서 실제로 활용**하려는 순간, 바이브 코딩 서비스만으로는 부족한 부분이 “굉장히 많이” 드러난다고 강조한다.[^15]
즉, “만들어주는 능력”은 뛰어나도, “내가 운영하는 서비스”로 만들려면 부가 요소(배포/인증/DB/모니터링 등)가 필요하다는 문제의식을 다음 파트(필수 개념 10가지)로 연결한다.[^15]
---
## 3.5 ‘바이브 코딩’의 정의를 명확히 하기: “이해하지 못해도 전부 수락”[^12]
화자는 바이브 코딩 용어를 더 정확히 정의한다.[^12]
- 사용자는 자연어로 AI에게 “어떤 기능을 개발해 달라”, “어떤 서비스를 만들어 달라” 요청한다.[^12]
- AI가 실제 코드를 작성해 준다.[^12]
- 이때 “바이브 코딩을 한다”는 것은, **개발자가 AI가 만들어 준 코드를 전혀 이해하지 못한 채**
- 모든 것을 그냥 수락하고
- “이거 해줘, 저거 해줘”처럼 지시만으로 개발하는 방식
을 의미한다.[^12]
이 정의는 영상 전체의 논지(‘그래도 최소 개념은 알아야 한다’)를 정당화하는 전제가 된다. 즉, “이해하지 못한 채 수락”만으로는 운영/수익화로 이어지는 복잡한 문제를 해결하기 어렵다는 결론으로 이어지기 때문이다.[^3]
---
## 3.6 결론 제시: 수익화 가능한 서비스까지 가려면 “요청하는 능력”이 필요하다[^3]
화자는 “개발 지식이 아무것도 없는 상태”에서 AI에게 기능을 요청하면 초기 단계 서비스까지는 만들 수 있으나, “온전한 서비스”를 만들기 위해서는 결국 개발 지식을 어느 정도 알고 **AI에게 요청하는 능력**이 필요하다고 말한다.[^3]
여기서의 핵심 전개는 다음 구조를 따른다.
1) 비개발자 + 자연어 지시 → MVP는 가능[^3]
2) 서비스화 + 수익화 + 실제 사용자 사용 가능 수준 → 요구사항 급증[^3]
3) 따라서 최소한의 개발 개념 이해 + 맥락 있는 요청 능력 필요[^3]
이 문제의식을 바탕으로, 영상의 목적을 “바이브 코딩으로 개발하려면 최소한 이 정도는 알고 가야 하는 필수 개발 개념 + 요즘 즐겨 쓰는 스택/무료 서비스 총정리”라고 선언한다.[^4]
---
## 3.7 바이브 코딩을 해도 반드시 알아야 할 필수 개발 개념 10가지 소개 (총론)[^4]
화자는 “아무리 바이브 코딩을 하더라도 기본 개념은 알고 가야 한다”고 전제한다.[^4]
이유는 다음과 같다.
- AI에게 요청할 때도,
- AI가 응답한 내용을 검토할 때도,
전체적인 개요를 알아야 개발이 더 원활해진다.[^4]
그리고 “AI를 통해 개발하더라도 무조건 알아야 하는 필수 개발 개념 10가지”를 소개하겠다고 예고한다.[^4]
이후 파트는 개별 개념을 하나씩 설명하는 방식으로 진행된다.[^4]
---
## 3.8 개념 1) 프론트엔드 vs 백엔드: 보이는 것과 보이지 않는 것[^4]
### 프론트엔드(클라이언트 사이드)[^4]
프론트엔드는 “클라이언트 사이드에서 실행되는 모든 것”이며, 예로 **브라우저에서 보여지는 화면** 전부를 프론트엔드로 이해하라고 설명한다.[^4]
기본적으로 HTML/CSS/자바스크립트로 구성되는 “화면 구성 자체”이며, 유튜브 예시로 버튼 같은 UI 요소도 모두 프론트엔드에서 개발된다고 말한다.[^4]
또한 탭을 눌러 화면이 이동하는 등, “보여지는 부분에 대한 로직”은 프론트엔드에서 개발된다고 덧붙인다.[^4]
### 백엔드(서버 사이드)[^4]
백엔드는 서버 사이드에서 실행되는 “눈에 보이지 않는 뒷단에서 일어나는 모든 일”을 처리한다고 설명한다.[^4]
예시는 다음과 같다.
- 데이터베이스 연동/관리[^4]
- 비즈니스 로직 처리[^4]
- 보안/인증 관리[^4]
- 서버에서 실행되는 API[^4]
유튜브 계정/로그인 상태 예시를 들어, 계정 정보를 브라우저에 저장하면 취약점이 많아 보통은 브라우저에 저장하지 않고, 백엔드의 데이터베이스에 계정 정보를 저장한다고 설명한다.[^4]
또한 대표 기술 예시를 든다.
- 프론트엔드 기술: React, Next.js, Vue, Angular, TypeScript 등[^4]
- 백엔드 언어/환경: Node.js, Python, Java 등[^4]
---
## 3.9 개념 2) API: 프론트엔드와 백엔드의 통신 규격[^4]
화자는 API를 “프론트엔드와 백엔드가 소통하는 통신 규격”이라고 간단히 정의한다.[^4]
그리고 연동 방식으로 REST API, GraphQL, WebSocket 등 여러 방식이 있음을 언급한다.[^4]
그중에서도 “가장 많이 활용”되는 방식은 **REST API**이며, “거의 대부분의 서비스는 REST API로 개발 가능”하다고 말한다.[^4]
> [!TIP] API 이해의 실전 의미
> 바이브 코딩으로 화면을 만들었더라도, 사용자/결제/데이터 같은 핵심 기능은 결국 프론트가 백엔드에 요청하는 구조(API 호출)를 이해해야 붙일 수 있다는 문제의식으로 연결된다.[^4]
---
## 3.10 개념 3) 에러: 유형과 확인 위치를 알아야 수정 요청이 가능하다[^4]
화자는 개발 중 에러는 필연적으로 발생하므로, 다음을 알아야 한다고 말한다.[^4]
- 어떤 에러들이 있는지
- 에러는 어디서 확인하는지
- 바이브 코딩/AI 에이전트를 쓰더라도, 에러를 확인하고 수정 요청을 할 줄 알아야 한다[^4]
주요 에러 유형으로 다음을 든다.
- 구문 오류(문법 오류)[^4]
- 런타임 오류(실행 중 발생)[^4]
- 논리적 오류[^4]
또한 에러가 프론트에서 발생했는지, 백엔드에서 발생했는지에 따라 확인 위치/수정 방식/AI에게 요청하는 방식이 달라진다고 말한다.[^4]
---
## 3.11 개념 4) 프레임워크 vs 라이브러리: 제어권의 차이[^4]
화자는 프레임워크와 라이브러리는 모두 “개발을 도와주는 도구 모음”이지만 근본적 차이가 있다고 설명한다.[^4]
- **라이브러리**: 개발자가 제어권을 가지고 필요한 기능을 선택적으로 사용한다.[^4]
- **프레임워크**: 개발자가 아니라 프레임워크가 제어권을 가지며, 개발자는 프레임워크 규칙을 따라야 개발이 가능하다.[^4]
예시로,
- 날짜 처리를 돕는 도구는 라이브러리 사례로 들고[^4]
- Next.js, Django, Ruby on Rails 등은 “전체 아키텍처 구조”를 제공하는 프레임워크로 제시한다.[^4]
---
## 3.12 개념 5) 데이터베이스: 대부분 서비스의 ‘핵심’[^4]
화자는 “웬만한 서비스에 데이터베이스가 들어가지 않는 서비스가 없다”고 말하며 데이터베이스의 필수성을 강조한다.[^4]
데이터베이스를 정형/비정형 데이터를 저장하는 공간으로 설명하고, 데이터베이스도 “하나의 서버”로 보면 된다고 말한다.[^4]
특히 “어떤 서비스를 만들 때 데이터베이스가 가장 핵심적이고 가장 중요한 부분”이라고 강조한다.[^4]
데이터베이스에는 예를 들어,
- 사용자 정보[^4]
- 제품 데이터[^4]
- 거래 내역[^4]
같은 중요한 정보가 저장되며, 서비스에 필요한 대부분의 데이터가 DB에 저장된다고 설명한다.[^4]
또한 데이터베이스 유형을 크게 2가지로 나눈다.
- 관계형 데이터베이스[^4]
- 비관계형(NoSQL) 데이터베이스[^4]
그리고 둘 중 하나만 선택해야 한다면 “대부분의 서비스는 관계형 DB를 선택하면 무리 없이 개발 가능”하다고 조언한다.[^4]
---
## 3.13 개념 6) 스토리지: 비구조화 파일은 DB가 아니라 스토리지에[^4]
화자는 스토리지를 “정보를 저장하는 공간”이라는 점에서 DB와 유사하지만, **저장 대상의 성격이 다르다**고 구분한다.[^4]
- 데이터베이스: 구조화된 데이터 저장[^4]
- 스토리지: 이미지/비디오/문서 등 **비구조화된 정보** 저장[^4]
그 이유로 비용을 든다. 데이터베이스는 “굉장히 비싼 자원”이기 때문에 이미지/비디오/문서처럼 용량이 커질 수 있는 데이터를 DB에 저장하면 비용이 많이 나온다고 설명한다.[^4]
따라서 비구조화 파일은 스토리지에 저장해야 한다는 실무적 결론을 제시한다.[^4]
---
## 3.14 개념 7) 인증(Authentication): 대부분 서비스의 필수이자 구현 난이도 높은 영역[^4]
화자는 인증이 회원가입/로그인/로그아웃 등 모든 과정을 포괄하며, 대부분의 서비스에서 필수 기능이라고 말한다.[^4]
또한 인증과 함께 “인증과 인가” 개념도 존재한다고 언급한다.[^4]
인증 방식의 예시로 다음을 나열한다.
- 세션 기반 인증[^4]
- 토큰 기반 인증[^4]
- 소셜 로그인 연동[^4]
- MFA(다중요소인증)[^4]
그리고 인증은 개발자에게도 구현이 까다로운 작업이며, 바이브 코딩을 하다 보면 “인증 같은 부분에서 막히는 경우가 굉장히 많이” 발생한다고 말한다.[^4]
다만 뒤에서 소개할 스택/서비스를 쓰면 인증/DB 등을 더 편하게 구현할 수 있다고 예고한다.[^4]
---
## 3.15 개념 8) 이메일: 흔하지만 안정적으로 만들기 어려운 기능[^4]
화자는 서비스 개발 시 이메일 기능이 다양한 목적으로 자주 쓰인다고 말한다.[^4]
- 회원가입 인증 메일[^4]
- 비밀번호 재설정 메일[^4]
- 알림/마케팅 목적[^4]
그러나 “생각보다” 이메일 기능을 안정적/효과적으로 구축하는 것은 까다롭고 어려운 작업이라고 설명한다.[^4]
그래서 이를 돕는 다양한 이메일 서비스가 존재한다는 흐름으로, 뒤에서 특정 서비스(Resend) 추천으로 이어진다.[^8]
---
## 3.16 개념 9) 배포: 자동화/무중단 등 신경 쓸 것이 많다[^4]
화자는 개발된 서비스를 사용자들이 쓰게 하려면 “배포 과정”이 필요하다고 말한다.[^4]
배포는 단순히 올리는 것에서 끝나지 않고 다음 이슈들을 포함한다.
- 매번 수동 배포가 아니라 배포 자동화 필요[^4]
- 배포 중 서비스가 죽지 않도록 무중단 배포 고려[^4]
이런 이유로 배포 플랫폼이 많이 활용된다고 말하며, 뒤에서 Vercel 추천으로 연결한다.[^9]
---
## 3.17 개념 10) 모니터링: 배포 후에도 운영 품질을 점검해야 한다[^4]
화자는 “배포만 했다고 끝이 아니다”라고 강조하며 운영 관점에서 모니터링의 필요성을 설명한다.[^4]
모니터링 범주는 다양하다고 나열한다.
- 성능 모니터링[^4]
- 보안 모니터링[^4]
- 인프라 모니터링[^4]
- 오류 추적[^4]
- 사용자 행동[^4]
- 헬스 체크[^4]
결론적으로 서비스 운영은 신경 쓸 것이 많고, 아직은 바이브 코딩만으로 이 모든 것을 커버하기 어렵다고 정리한다.[^4]
---
## 3.18 “한 번에 다 이해는 어렵지만, 들어보고 아는 것과 모르는 것은 다르다”[^4]
화자는 앞서 소개한 10가지 개념이 비개발자/초보자에게 한 번에 완전히 이해되기 어렵다는 점을 인정한다.[^4]
그러면서도 다음을 강조한다.
- 한 번쯤 듣고 “느낌”을 알고 가는 것[^4]
- 아예 모르는 상태에서 AI에게 “만들어줘”만 하는 것[^4]
사이에는 큰 차이가 난다는 것이다.[^4]
이후, 이러한 개념을 어느 정도 이해한 상태에서 실제로 제품을 만들려면 “적절한 기술 스택”과 “유용한 서비스” 활용이 효율을 크게 높여준다고 연결한다.[^5]
---
## 3.19 현실적인 추천 스택: “최소 스택으로 압축” + 프론트/백을 한 프레임워크로[^6]
화자는 실제 개발 단계에서 프레임워크 선택이 필요하다고 말한다.[^6]
일반적으로는 프론트 프레임워크/백엔드 프레임워크를 각각 선택하지만, 프론트와 백을 하나의 프레임워크에서 개발할 수 있게 돕는 프레임워크가 있다고 소개한다.[^6]
그 프레임워크로 **Next.js**를 추천한다.[^6]
Next.js는 프론트엔드와 백엔드를 “하나의 Next.js 프레임워크 내에서 개발”할 수 있게 돕는다고 설명한다.[^6]
또한 화자는 기술 스택이 많아질수록 관리가 어려워진다고 말하며, 처음 만드는 서비스/규모가 크지 않은 서비스라면 “최소한의 기술 스택으로 압축”해서 개발하는 것이 좋다고 주장한다.[^6]
그래서 프론트+백 프레임워크를 하나만 추천한다면 Next.js를 추천한다고 결론 내린다.[^6]
> [!IMPORTANT] 스택 전략의 메시지
> “많은 스택을 아는 것”이 아니라 “초기에는 최소 스택으로 완성→운영→확장”이 현실적이라는 전개를 통해, 바이브 코딩의 생산성을 ‘운영 가능한 구조’로 연결하려 한다.[^6]
---
## 3.20 백엔드 필수 3요소(DB/인증/스토리지)를 한 번에: Supabase(BaaS) 추천 + 무료 플랜 근거[^7]
화자는 데이터베이스/스토리지/인증이 대부분 서비스에서 핵심 기능이라고 다시 상기시키고, 원래는 각각을 직접 구축해야 했다고 설명한다.[^7]
- DB: 직접 서버 구축 필요[^7]
- 스토리지: 서버를 빌려야 함[^7]
- 인증: 복잡한 기능을 직접 개발해야 함[^7]
하지만 “백엔드에 필요한 필수 기능들을 지원해주는 서비스”가 있으며, 그 서비스로 **Supabase(슈퍼베이스)**를 제시한다.[^7]
Supabase를 쓰면 데이터베이스/인증/스토리지를 “서비스 하나로 다 커버” 가능하다고 말한다.[^7]
또한 Supabase를 **BaaS(Backend as a Service)**로 정의하면서, 백엔드에서 많이 쓰는 기능을 모듈화해 쉽게 가져다 쓸 수 있게 만든 서비스라고 설명한다.[^7]
### 무료 플랜 수치 제시[^7]
화자는 초기 단계에서 무료로 활용 가능하다는 점을 강조하며 예시 수치를 제시한다.
- 월간 활성 유저(MAU) 5만 명이 무료 플랜에 포함[^7]
- 데이터베이스 500MB 지원[^7]
- 스토리지 1GB까지 무료 지원[^7]
따라서 초기에는 추가 비용 없이 Supabase만 활용해도 많은 부분을 지원받을 수 있다는 결론을 낸다.[^7]
---
## 3.21 이메일 서비스는 Resend로: API로 “가져다 쓰기” + 무료 플랜 근거[^8]
화자는 이메일 기능 역시 직접 구현하면 까다롭지만, 이미 이메일 인증/전송 등 복잡한 기능을 구축해 둔 서비스가 있으므로 이를 활용하면 “초기 개발 속도”를 크게 올릴 수 있다고 말한다.[^8]
그중 추천 서비스로 **Resend(리센드)**를 제시한다.[^8]
Resend의 가치 제안은 다음처럼 설명된다.
- 이메일 관련 대부분 기능을 Resend가 API로 만들어 둠[^8]
- 개발자는 그 API를 “가져다 쓰기만” 하면 됨[^8]
- 이메일 기능 연동이 “굉장히 쉽게” 가능[^8]
또한 무료 플랜 근거를 든다.
- 월간 3,000개 이메일 전송까지 무료[^8]
---
## 3.22 배포 플랫폼은 Vercel: Next.js와 궁합(제작사 동일) + 무료 활용 가능[^9]
개발 완료 후 인터넷에 배포해 접근 가능하게 해야 한다는 흐름에서, 화자는 배포를 직접 서버 구축으로 할 수도 있지만 배포를 도와주는 서비스가 많다고 말한다.[^9]
추천 서비스는 **Vercel(버셀)**이다.[^9]
추천 이유의 핵심은 “Next.js와의 궁합”이다.[^9]
Vercel은 배포 플랫폼이며, Next.js를 만든 회사가 Vercel이기 때문에 Next.js 프로젝트를 Vercel에 배포했을 때 호환성이 가장 좋고 배포가 유기적으로 이뤄진다고 설명한다.[^9]
또한 Vercel 역시 초기 단계에는 무료로 활용 가능한 리소스가 많아, 초기에는 추가 비용 없이 배포 관련 지원을 받아 서비스 운영이 가능하다고 말한다.[^9]
---
## 3.23 모니터링은 Sentry: 대시보드 기반 모니터링 + 무료 에러 한도[^10]
화자는 배포 후에는 서비스가 제대로 동작하는지, 오류는 없는지, 트래픽이 몰릴 때 부하는 괜찮은지 등을 검증하기 위해 모니터링이 필요하다고 다시 강조한다.[^10]
모니터링 서비스로 하나를 추천한다면 **Sentry(센트리)**를 추천한다고 말한다.[^10]
Sentry를 프로젝트에 통합하면:
- 자체 대시보드가 잘 되어 있어 대부분 모니터링이 가능[^10]
또한 무료 한도를 제시한다.
- 초기 서비스라면 추가 비용 없이 최대 5,000개 에러까지 무료 모니터링 가능[^10]
---
## 3.24 정리 메시지: “개념 + 스택/서비스를 숙지하면 결과물 퀄리티가 달라진다”[^16]
화자는 다시 전체 흐름을 정리한다.[^16]
1) 바이브 코딩을 하더라도 최소한 10가지 개념은 알고 가자[^16]
2) 그 개념들을 쉽게 구현하도록 돕는 유용한 서비스들을 소개했다[^16]
그리고 다음 대상에게 메시지를 보낸다.
- AI로 개발하다 한계에 부딪힌 사람[^16]
- 더 고도화된 서비스를 만들고 싶은 사람[^16]
- 운영 단계에서 수익화까지 가는 서비스를 만들고 싶은 사람[^16]
이들이 영상에서 소개한 개념/필수 스택/유용 서비스들을 숙지하고 개발하면 결과물 퀄리티가 크게 달라질 것이라고 말한다.[^16]
---
## 3.25 추가 제안: 더 깊게 배우고 싶다면 ‘SaaS 개발 강의’ 안내 (프로젝트 기반, 결제/컨텍스트 엔지니어링/MCP 포함)[^17]
마지막 파트에서 화자는 영상에서 다룬 개념/기술을 더 깊게 배우고 싶은 사람을 대상으로 자신이 런칭하는 **SaaS 개발 강의**를 추천한다.[^17]
커리큘럼은 “아직 완전 확정은 아니지만” 대략적으로 다음 방향이라고 설명한다.[^17]
- 여러 프로젝트를 반복적으로 다루면서[^17]
- 앞서 설명한 개념들을 “자연스럽게 체득”하도록 돕는다[^17]
구체적으로는 “토이 프로젝트”도 만들고,[^17]
큰 축으로 “총 네 가지” SaaS 프로젝트를 만들어 보며, 필수 개념과 기술 스택을 프로젝트 단계별로 녹여 전달하겠다고 말한다.[^17]
또한 강의 목표를 “수익화 가능한 SaaS”로 설정한다.
- 데이터베이스[^17]
- 배포[^17]
- 이메일 인증[^17]
- 결제 연동(수익화)[^17]
까지 포함해, 강의를 완강하면 실제로 수익화 가능한 SaaS를 만들 역량을 기르도록 기획했다고 말한다.[^17]
국내 결제뿐 아니라 해외 결제까지 연동 가능한 스택/연동 방법도 소개하겠다고 덧붙인다.[^17]
### 바이브 코딩을 넘는 방법론: 컨텍스트 엔지니어링 + MCP[^17]
화자는 단순히 “바이브 코딩으로만 개발”하는 것이 아니라,
- **컨텍스트 엔지니어링** 기법으로 적절한 문맥을 유지해 AI 성능을 최대화하고[^17]
- AI 에이전트 성능 향상을 위해 외부 도구 연결로 **MCP** 같은 것들도 활용해보며[^17]
- 실무/엔터프라이즈 수준에서 활용 가능한 팁까지 전달하겠다고 말한다.[^17]
또한 강의가 특정 도구 사용법에 치중하지 않는다고 강조한다.[^18]
Cursor를 쓰든 Claude Code를 쓰든 Codex CLI를 쓰든, 어떤 AI 코딩 에이전트를 쓰더라도 “공통적으로 적용 가능한 본질”에 초점을 맞출 것이라고 설명한다.[^18]
마지막으로 “시간이 지나도 변하지 않는 AI 개발 방법론”을 학습하고 싶은 사람에게 강의를 추천하며, 관심 있으면 고정 댓글/설명란을 참고하라고 안내하며 영상을 마무리한다.[^19]
---
# 4. 핵심 통찰[^20]
1. 바이브 코딩은 “MVP 생산”에는 강하지만, **운영/고도화**(DB/인증/배포/모니터링)에서 급격히 난이도가 올라가며 이 지점이 트래픽 감소의 주요 원인으로 제시된다.[^2]
2. 바이브 코딩의 본질을 “코드를 이해하지 못한 채 전부 수락”으로 규정하는 순간, 최소한의 개발 개념 학습이 ‘선택’이 아니라 ‘필수’가 된다.[^12]
3. 초보/초기 SaaS는 스택을 늘리는 것보다 **최소 스택으로 압축**해 완성-배포-운영 사이클을 돌리는 전략이 현실적이라는 메시지를 준다.[^6]
4. BaaS/배포/모니터링/이메일 같은 외부 서비스를 조합하면, 비개발자/초기 팀이 가장 어려워하는 영역(인증/이메일/배포/관측성)을 “직접 구현” 대신 “연동”으로 전환할 수 있다.[^7]
5. 도구 트렌드가 바뀌어도(특정 바이브 코딩 툴의 흥망) 프론트/백, API, DB, 인증, 배포, 모니터링 같은 **본질적 구조**는 남는다는 관점에서, 학습 우선순위를 “도구 사용법”보다 “구조 이해”로 둔다.[^18]
실행 관점 시사점(콘텐츠가 제안하는 방향을 행동으로 옮기면):[^16]
- Next.js로 프론트/백을 한 프로젝트로 묶어 스택 복잡도를 낮춘다.[^6]
- Supabase로 DB/인증/스토리지의 ‘직접 구축’ 부담을 줄이고 무료 플랜 범위에서 MVP를 운영해본다.[^7]
- 이메일은 Resend로 붙여 인증/재설정 플로우를 빠르게 완성한다.[^8]
- Vercel 배포 후 Sentry로 에러를 관측하면서 운영 단계 문제를 빠르게 찾는다.[^9]
---
# 5. 헷갈리는 용어 정리 (해당 시에만)[^21]
- **바이브 코딩(Vibe Coding)**: 자연어로 AI에게 기능/서비스를 요청하고, AI가 작성한 코드를 개발자가 이해하지 못해도 “그냥 전부 수락”하며 개발을 진행하는 방식.[^12]
- **프론트엔드(Frontend)**: 브라우저 등 클라이언트에서 실행되며 사용자에게 “보이는 화면/동작”을 만드는 영역(HTML/CSS/JS 등).[^4]
- **백엔드(Backend)**: 서버에서 실행되며 DB/비즈니스 로직/보안/인증/API 등 “보이지 않는 뒷단”을 처리하는 영역.[^4]
- **API**: 프론트엔드와 백엔드가 소통하는 통신 규격(REST API, GraphQL, WebSocket 등).[^4]
- **프레임워크 vs 라이브러리**: 라이브러리는 개발자에게 제어권이 있고 선택적으로 사용, 프레임워크는 프레임워크가 제어권을 가지며 규칙을 따라야 함.[^4]
- **관계형 DB / 비관계형 DB**: DB의 대표적인 두 분류이며, 대부분 서비스는 관계형 DB 선택으로 무리 없이 개발 가능하다는 조언이 제시됨.[^4]
- **스토리지(Storage)**: 이미지/비디오/문서 같은 비구조화 파일을 저장하는 공간. DB는 비싸므로 큰 파일은 스토리지에 저장해야 한다는 비용 논리 제시.[^4]
- **BaaS(Backend as a Service)**: 백엔드에서 자주 쓰는 기능을 모듈화해 제공, 쉽게 가져다 쓰게 하는 서비스 형태. Supabase가 예로 제시됨.[^7]
- **모니터링**: 배포 후 서비스의 오류/성능/보안/인프라 상태 등을 관측하고 문제를 추적하는 운영 단계 활동.[^4]
- **컨텍스트 엔지니어링**: AI 성능을 최대화하기 위해 적절한 문맥(컨텍스트)을 유지/구성하는 기법으로 언급됨.[^17]
- **MCP**: AI 에이전트 성능 향상을 위해 외부 도구 연결에 활용하는 것으로 언급됨(영상 내 상세 정의는 약식 언급 수준).[^17]
---
---
## 참고(콘텐츠 정보)[^22]
- 제목: 바이브코딩으로 SaaS 개발하는 가장 현실적인 방법[^22]
- 채널: 개발동생[^22]
- 길이: 22분 28초[^22]
- 키워드: 바이브코딩, Lovable, Cursor, Codex, Claude Code, SaaS, 수익화, Vibe Coding[^22]
- 링크: https://www.youtube.com/watch?v=smW3raqdTv0[^22]
---
[^1]: @[00:00] "최근 몇 달간이 바이브 코딩 주요 서비스에 대한 트래픽이 굉장히 많이 줄어들고..." / @[00:12] "러버블... 트래픽이 거의 절반 이상 줄었다"
[^2]: @[00:16] "크로스트 데이터 코파운더가 링크든에..." / @[00:24] "러버블... 레플릿, V0, 볼트" / @[00:48] "2025년 2월... 안드레이 카파치..." / @[01:03] "바이브 코딩... 서비스 등장... 사용자 폭증" / @[01:40] "외부 API나 데이터베이스 인증..." / @[02:12] "커서나 클로드 코드... 코덱스 CLI..."
[^3]: @[03:16] "개발에 대한 지식이 아무것도 없는 상태..." / @[03:27] "수익화... 온전한 서비스... 개발 지식을 어느 정도 알고 AI한테 요청"
[^4]: @[03:59] "기본적인 개발 개념들은 알고 가야..." / @[04:26] "필수 개발 개념 열 가지" / @[04:30]~@[12:43] 프론트/백, API, 에러, 프레임워크vs라이브러리, DB, 스토리지, 인증, 이메일, 배포, 모니터링 설명
[^5]: @[13:29] "적절한 기술 스택 그리고... 유용한 서비스" / @[13:45] "기술 스택과 무료... 서비스 소개"
[^6]: @[14:04] "프론트엔드와 백엔드... 하나의 프레임워크" / @[14:16] "넥스트 JS 추천" / @[14:33] "기술 스택이 너무 많아져도..." / @[14:42] "최소한의 기술 스택으로 압축"
[^7]: @[14:52] "데이터베이스, 스토리지, 인증" / @[15:20] "슈퍼베이스... 데이터베이스 인증 스토리지 모두" / @[15:54] "월간 5만 명... 500MB... 스토리지 1GB"
[^8]: @[16:20] "이메일 기능... 까다롭" / @[16:40] "리센드 추천" / @[16:49] "월간 3,000개의 이메일 전송까지 무료"
[^9]: @[17:11] "배포" / @[17:22] "버셀 추천" / @[17:53] "넥스트 JS... 만든 회사가 버셀" / @[18:04] "초기 단계 무료"
[^10]: @[18:27] "모니터링" / @[18:40] "센트리 추천" / @[18:56] "최대 5,000개의 에러까지... 무료"
[^11]: @[00:00]~@[03:49] 트래픽 감소/한계 문제 제기와 영상 목적 소개
[^12]: @[02:45] "바이브 코딩... AI가 만들어 준 코드를 전혀 이해하지 못한 채... 다 수락"
[^13]: @[00:00]~@[22:25] 영상 전체 흐름(문제 제기→정의→필수개념→추천 스택/서비스→강의 소개)
[^14]: @[01:20] "환상... 코딩을 아무것도 몰라도..." / @[01:29] "비개발자... 프로덕트 개발 가능"
[^15]: @[02:23] "간단한 서비스까지는" / @[02:33] "빠르게... 퀄리티" / @[02:45] "운영 단계까지 배포... 부족"
[^16]: @[19:03] "열 가지... 설명" / @[19:10] "유용한 서비스" / @[19:17]~@[19:39] "한계... 고도화... 수익화... 퀄리티 달라질"
[^17]: @[19:55] "사스 개발 강의" / @[20:31] "사스 프로젝트... 총 네 가지" / @[20:45] "결제 연동까지" / @[21:01] "국내... 해외 결제" / @[21:19] "컨텍스트 엔지니어링" / @[21:19] "MCP"
[^18]: @[21:30] "특정 AI 도구에 치중..." / @[21:40] "커서를 쓰든지... 클로드 코드... 코덱스 CLI..." / @[21:52] "공통적으로 적용 가능한 본질"
[^19]: @[22:02] "시간이 지나도 변하지 않는 AI 개발 방법론" / @[22:23] "고정 댓글... 설명란"
[^20]: @[01:40]~@[12:50] 한계의 원인(운영 복잡도)과 10개 필수 개념의 필요성, @[14:16]~@[18:56] 최소 스택/서비스 조합의 제시
[^21]: @[02:45]~@[03:27], @[07:35]~@[09:33], @[09:39]~@[10:17], @[10:17]~@[11:03], @[21:19] 용어들의 정의/언급
[^22]: 사용자가 제공한 메타데이터(제목/채널/길이/키워드/링크)