PT 관리 앱을 라이브로 만들며 보여주는 2026년식 바이브 코딩 초기 세팅법

01핵심 개요 (표)

02핵심 기능/내용 구조

03기술적 맥락

화자는 타입스크립트를 "바이브 코딩의 깡패"로 표현하며, 앱·서버·웹·AI 서비스까지 하나의 언어로 대응 가능한 범용성 때문에 특별한 이유가 없다면 기본 선택지로 삼으라고 권한다. 크로스플랫폼 앱 프레임워크는 Expo(X4)와 Flutter 두 가지만 메이저로 보고, Flutter는 Dart 언어를 쓰기 때문에 서버와 언어를 통일할 수 없어 배제했다. 서버 프레임워크는 Express보다 보일러플레이트가 큰 NestJS를 택했는데, 이는 의존성 주입 등 초기엔 무거워 보이지만 프로덕션 단계에서 결국 필요해지는 구조를 프레임워크 레벨에서 강제해 개발자의 고민을 줄여주기 때문이라고 설명한다.

앱 서비스는 웹과 달리 풀스택 배포(클라이언트에서 DB 직접 연결)가 사실상 불가능하므로 반드시 별도 서버가 필요하다는 점, 그리고 Supabase처럼 클라이언트-DB 직접 연결을 지원하는 방식도 있지만 보안과 유지보수 관점에서 클라이언트-서버-DB로 분리하는 정석적 구조를 권장한다는 점을 강조한다. 데이터베이스와 스토리지 서비스 선택도 AI와 대화하며 결정했는데("Cloudflare가 낫지 않냐"는 질문에 에이전트가 응답), 이런 인프라 설정 작업을 사람이 직접 콘솔을 클릭하며 배우는 대신 에이전트의 브라우저 조작 기능에 맡기는 흐름을 실연했다.

04전략적 의미

이 방송의 핵심 메시지는 "바이브 코딩이 잘 되려면 AI에게 맡길 부분과 사람이 반드시 결정할 부분의 경계를 정확히 그어야 한다"는 것이다. 화자는 AI는 컴퓨터 안의 정보만 알고 있어 실제 타겟 유저(트레이너)의 기술 친화도나 문제 공감 수준 같은 현실 맥락을 모르기 때문에, 비즈니스 방향성 결정을 AI에 위임하는 것은 위험하다고 강조한다. 반대로 인프라 설정, 데이터 모델 초안 작성, 유저 스토리 초안 같은 반복적이고 검증 가능한 작업은 적극적으로 위임한다.

또한 "많이 만든다고 실력이 늘지 않는다"는 주장이 눈에 띈다. 화자는 자신도 15년간 요리를 해왔지만 요리사가 아니듯, 바이브 코딩도 반복만으로는 전문성이 생기지 않으며, PM 스킬(요구사항 명확화, 되묻기, 우선순위 결정)과 소프트웨어 공학 기본기(데이터베이스 의존관계, 아키텍처 분리 원칙)를 책과 이론으로 학습해야 실질적으로 성장한다고 역설한다. 이는 바이브 코딩 입문자들이 흔히 오해하는 "더 비싼 요금제, 더 많은 시행착오 = 실력 향상" 공식을 정면으로 반박하는 관점이다. 아울러 롱러닝 에이전트를 자랑하는 사례들에 대해 "토큰을 많이 쓰고 오래 도는 것 자체가 자랑거리가 아니라 비효율의 신호일 수 있다"는 회의적 시각도 제시한다.

05핵심 워크플로우 또는 비교표

06활용 시나리오

07현황 및 전망

방송이 끝난 시점까지 전체 9단계 구현 계획 중 0단계도 완료되지 않았으며, 화자는 실제 구현 진행 상황은 별도 녹화 영상으로 공개하고 다음 라이브(같은 주 금요일)에서 이어서 진행하겠다고 밝혔다. 서버 배포(Railway) 자체는 방송 중 성공했으나 실제 비즈니스 로직 구현은 이루어지지 않은 상태였다.

화자는 "예전에는 결과물을 만드는 것 자체에 학습 가치가 있었지만, 요즘은 AI가 어차피 잘 만들어주기 때문에 만드는 행위의 학습 가치가 크게 떨어졌다"고 진단하며, 앞으로는 코딩에 익숙해지는 것보다 탄탄한 이론·철학(소프트웨어 공학 원칙, PM 스킬)을 갖추는 쪽이 훨씬 중요해질 것이라는 전망을 제시한다. 또한 바이브 코딩으로 수익을 내는 난이도가 실제로는 매우 높으며, 검증되지 않은 고가 강의보다 스탠퍼드·YC 등에서 제공하는 무료 강의, 그리고 실질적 이론서를 우선하라는 조언을 덧붙였다. 본인의 전략으로는 컨설팅·강의로 먼저 고객 문제를 발견한 뒤, 반복되는 니즈를 소프트웨어(오픈소스 프로젝트 '아르고스' 등)로 전환해 B2B 커스터마이징·유지보수 계약으로 확장하는 방식을 소개했다.

08용어 사전