바이브 코딩 튜토리얼: 모노레포로 멀티 플랫폼 개발하기
📺 원본 영상: 바이브 코딩 튜토리얼! 모노레포로 멀티 플랫폼 개발하기 🎙️ 채널: 코드팩토리 📅 정리 일자: 2026-04-24 ⚠️ Note: 본 리포트는 영상의 음성을 텍스트로 변환(STT)하여 정리한 것입니다. 화면에 표시된 자료(코드, 시연 화면 등)는 포함되지 않을 수 있으며, 정확한 내용은 원본 영상을 참조하세요.
개요
이 영상은 코드팩토리 채널의 바이브 코딩(Vibe Coding) 튜토리얼로, MiniMax M2.7 AI를 파트너 삼아 로컬 취미 모임 서비스를 웹에서 시작해 정적 랜딩 페이지, 모바일 앱까지 확장하는 전 과정을 실시간으로 보여준다. 핵심 기술 키워드는 Turborepo 기반의 모노레포(Monorepo) 아키텍처로, Next.js 웹 앱·Astro 랜딩 페이지·React Native 앱을 단일 저장소에서 관리하며 코드를 재사용하는 전략이 영상 전반을 관통한다. 기술 스택 설명 못지않게 강조되는 것은 AI 이터레이션 루프(Iteration Loop) 설계 철학이다. 즉, 반복 검증 과정을 AI에게 완전히 위임함으로써 인간이 개발 속도의 병목이 되지 않도록 하는 방법론이 이 영상의 진짜 주제다.
”망상”에서 시작하는 서비스 기획
강연자는 자신이 MBTI 극 N이라고 소개하며, 먼저 ‘망상’부터 해보자고 제안한다. 이 접근 방식은 단순한 유머가 아니라 실제 스타트업이 성장하며 맞닥뜨리는 기술적 요구사항 흐름을 그대로 시뮬레이션한 것이다. 시나리오는 다음과 같다. 웹 서비스를 런칭했더니 트래픽이 폭증해 서버가 다운될 지경에 이르렀고, 서버 부담을 줄이기 위해 랜딩 페이지를 정적으로 분리해야 하는 상황이 생겼다. 그리고 그 서비스가 또 잘 되어 사용자 경험을 높이기 위한 모바일 앱 개발까지 이어진다. 이 가상의 성장 시나리오는 웹 → 랜딩 → 앱이라는 개발 순서에 논리적 근거를 부여하기 위한 설정이기도 하다.
서비스 컨셉은 ‘로컬 취미 모임’ 플랫폼으로 정했다. 동네에서 축구 모임을 개설하면 주변 사람들에게 추천되고 참여 신청을 받을 수 있는 형태다. UI 목표는 명확하게 두 가지 레퍼런스를 제시했는데, 데스크탑에서는 왼쪽 리스트·오른쪽 지도의 Airbnb 스타일 스플릿 뷰를, 모바일에서는 지도 위에 바텀 시트가 올라오는 당근마켓 스타일을 지향했다.
AI 파트너 선택: MiniMax M2.7의 포지셔닝
강연자가 이 영상에서 선택한 AI 모델은 MiniMax M2.7이다. 선택 근거로 SWE-bench Pro 벤치마크 수치를 언급했는데, Claude Opus 4.6이 57.3%를 달성하는 시점에 MiniMax M2.7은 56.2%를 기록했다. 단 1.1%p의 성능 차이를 상쇄하고도 남는 강점이 속도와 비용이다. 개발 업무처럼 수십~수백 번의 요청이 반복되는 워크플로우에서 토큰 비용이 저렴하고 응답 속도가 빠른 모델은 결과물의 품질 못지않게 중요한 선택 기준이 된다.
한국어 요청에 간혹 일본어나 중국어가 섞인 답변이 나오는 한계가 있다고 강연자는 솔직하게 밝혔다. 그러나 코드 생성 작업에서는 이러한 언어 혼용이 실질적인 문제가 되지 않으므로, 비용 절감 효과를 충분히 누릴 수 있다는 판단이다. 이 선택은 AI를 단순히 ‘가장 성능이 좋은 모델’로 고르는 것이 아니라, 작업 특성에 맞게 최적화된 도구를 선택한다는 실용주의적 관점을 잘 보여준다.
기술 스택과 모노레포 아키텍처
이번 프로젝트의 기술 스택은 Next.js(App Router), Supabase, Kakao Maps API, Tailwind CSS로 구성되어 있으며, 이 모든 패키지가 Turborepo 기반의 모노레포 구조 아래 관리된다. 강연자는 AI가 플래닝을 완료하자마자 turbo.json 파일이 자동으로 생성된 것을 언급하며, Turborepo가 모노레포 설정의 사실상 표준이 되었음을 자연스럽게 확인해 준다.
04:23 - AI 플래닝 완료 화면 — turbo.json이 포함된 Turborepo 기반 모노레포 프로젝트 구조
모노레포를 선택한 의도는 단순히 코드를 한 곳에 모아두는 것이 아니다. 이후에 추가될 Astro 랜딩 페이지와 React Native 앱이 공통 컴포넌트와 비즈니스 로직을 공유할 수 있도록 기반을 미리 깔아두는 것이 진짜 목적이다. 요청 프롬프트도 정교하게 설계되었다. “현재 이 빈 폴더에다가 소모임 서비스 MVP를 만들어줘”라는 핵심 지시 외에, 기술 스택·UI 레이아웃·데이터베이스 설정 지시, 그리고 “직접 할 수 있다면 디버깅과 이터레이션도 직접 진행해줘”라는 자율 권한 부여까지 한 번에 담았다. 이 프롬프트 설계 방식 자체가 이미 하나의 노하우다.
Supabase MCP 연동과 자동 마이그레이션
Supabase 데이터베이스 설정 단계에서 강연자는 MCP(Model Context Protocol)를 적극적으로 활용한다. 일반적으로 개발자가 직접 Supabase 대시보드에 접속해 테이블을 생성하고 마이그레이션 SQL을 실행하는 과정은 상당한 시간이 소요된다. 그러나 Supabase MCP가 AI 에이전트에 연결되어 있으면, “Supabase MCP 사용해서 마이그레이션 같이 직접 할 수 있는 작업들을 직접 실행해 달라”는 요청 한 줄로 테이블·정책(Policy)·트리거(Trigger)·인덱스까지 모두 자동 생성된다. 심지어 환경 변수 설정마저 “Supabase MCP 사용해서 환경 변수까지 설정해줘”라는 단 한 줄의 요청으로 처리했다.
이 과정이 시사하는 바는 단순한 편의성을 넘어선다. MCP 생태계가 확장될수록 AI 에이전트가 외부 서비스와 직접 상호작용할 수 있는 범위가 넓어지고, 개발자가 손수 처리해야 하는 설정 작업의 비중이 급격히 줄어드는 방향으로 개발 패러다임이 이동하고 있음을 보여주는 대목이다. 인프라 설정의 자동화가 코드 생성 자동화와 맞닿는 지점이 여기다.
Playwright 기반 자동 이터레이션 루프 — 이 영상의 핵심 주제
강연자가 이 영상 전반에 걸쳐 가장 강조하는 개념은 AI 이터레이션 루프다. 전통적인 개발 방식에서는 코드를 작성하고, 브라우저를 직접 열어 클릭해가며 버그를 확인하고, 다시 코드로 돌아가 수정하는 과정을 반복했다. 강연자는 이 사이클에서 ‘사람이 클릭하고 확인하는 순간’이 곧 병목이라고 지적한다. AI의 코드 생성 속도가 인간의 검증 속도를 이미 추월한 현시점에서, 검증 과정까지 AI에게 위임하지 않으면 전체 개발 속도는 여전히 인간의 반응 속도에 종속된다는 논리다.
해결책으로 제시된 것이 Playwright를 활용한 자동 디버깅 루프다. “Playwright를 사용해서 직접 디버깅과 이터레이션을 진행해줘, 지금까지 구현한 모든 요소들이 잘 실행되는지 확인하고, 안 되는 부분들이 있다면 직접 확인하고 수정해줘”라는 단 한 번의 요청으로, AI는 브라우저를 자동으로 조작하며 각 기능을 검증하고 발견된 문제를 즉각 수정하는 루프를 스스로 실행한다.
06:42 - Playwright 자동 디버깅 루프 실행 중 — 브라우저가 자동으로 열려 각 기능을 순차 검증하는 화면
이 방식이 특히 강력한 것은 MiniMax처럼 응답 속도가 빠른 모델과 결합될 때다. 빠른 코드 생성과 빠른 자동 검증이 맞물리면, 인간이 개입하지 않아도 수십 번의 수정-검증 사이클이 짧은 시간 안에 완료된다. 결과적으로 개발자는 최초 요구사항 정의와 최종 결과 확인에만 집중하고, 그 사이의 모든 반복 작업은 AI가 처리하는 구조가 완성된다. 강연자가 중간에 “SO EASY”라고 외치는 장면은 이 루프가 실제로 작동하는 순간의 감탄이었다.
07:13 - 완성된 Next.js 웹 서비스 — Kakao Map과 모임 리스트 스플릿 뷰, 모임 상세 정보 표시
랜딩 페이지 전략: Astro 프레임워크로 트래픽 비용 최적화
서비스 MVP가 완성되면 다음 단계는 랜딩 페이지 분리다. 강연자의 논리는 간결하다. Next.js로 만든 동적 웹 서비스는 매 요청마다 서버 연산이 필요하지만, 랜딩 페이지는 본질적으로 정적 콘텐츠이므로 CDN에 배포하면 서버 비용을 대폭 절감할 수 있다. 이를 위해 선택된 것이 Astro 프레임워크다. Astro는 JavaScript를 최소화하고 정적 HTML을 출력하도록 설계된 프레임워크로, SEO 최적화와 초기 로딩 속도 측면에서 Next.js보다 유리한 위치에 있다.
여기서 강연자가 강조하는 것은 작업 순서다. 웹 서비스를 먼저 완성한 뒤에 랜딩 페이지를 만들어야 한다는 원칙인데, 이미 구현된 서비스의 실제 UI 컴포넌트와 스크린샷을 레퍼런스로 사용할 수 있기 때문이다. “실제 우리 서비스의 UI를 사용해서 랜딩 페이지를 현대적으로 구현해줘”라고 요청하면, AI는 기존 컴포넌트를 Astro로 이식해 서비스와 디자인 언어가 일관된 랜딩 페이지를 생성한다. 강연자에 따르면 처음부터 랜딩 페이지를 별도로 설계하는 것보다 훨씬 설득력 있는 결과물이 나온다고 한다.
강연자는 약 8분 33초 만에 완성된 Astro 랜딩 페이지를 화면으로 보여주며, 실제 서비스 스크린샷이 랜딩 페이지에 그대로 반영된 결과를 확인한다.
09:04 - Astro 랜딩 페이지 완성 결과 — 실제 서비스 스크린샷이 반영된 현대적 랜딩 페이지 전체 화면
React Native 앱 개발: 레퍼런스 기반 멀티플랫폼 전략
세 번째 단계는 모바일 앱이다. 강연자가 Flutter 대신 React Native를 선택한 이유가 흥미롭다. Flutter 자체는 뛰어난 프레임워크지만, AI가 이터레이션 루프를 형성하기에는 React 생태계가 더 방대한 학습 데이터와 도구 지원을 갖추고 있어 유리하다는 판단이다. “어느 프레임워크가 더 좋은가”가 아니라 “AI가 어느 프레임워크로 더 잘 작동하는가”를 기준으로 삼는 이 관점은, AI 시대의 기술 선택 기준이 근본적으로 달라지고 있음을 시사한다.
모노레포 아키텍처의 진가가 발휘되는 것이 바로 이 단계다. 이미 Turborepo로 설정된 모노레포 덕분에, AI는 별도의 초기 설정 없이 독립된 패키지 폴더에 React Native 앱을 생성하고 Supabase 클라이언트 등 공통 로직을 재사용한다. 그리고 “웹과 앱이 완전히 동일한 기능들을 수행하고 있다는 거를 반복해서 확인하고 검증해줘”라는 요청이 핵심이다. 이미 완성된 Next.js 웹 서비스가 React Native 앱이 도달해야 할 정확한 기준점, 즉 레퍼런스가 된다. 동일한 기능을 기준으로 두 플랫폼을 서로 대조하며 검증하는 이 방식은, AI가 목표 상태를 명확히 이해하고 이터레이션할 수 있는 조건을 만들어준다.
11:45 - React Native 앱 iOS 시뮬레이터 자동 실행 — 이터레이션 루프 도중 로그인 화면부터 지도까지 자동 검증
TCR AI 프레임워크와 레퍼런스의 중요성
강연자는 자신이 별도 영상에서 소개한 ‘TCR AI 프레임워크’를 언급하며, 이번 튜토리얼 전체가 그 프레임워크의 핵심 원칙 중 하나인 ‘레퍼런스의 중요성’을 실증하는 과정임을 밝힌다. 원칙의 골자는 단순하다. AI에게 어떤 것을 만들어달라고 요청할 때, 이미 완성된 결과물이 기준점으로 존재한다면 그것을 레퍼런스로 삼아 다음 작업을 요청하는 방식이 완성도를 극적으로 높인다는 것이다.
이 원칙이 이번 개발 순서에 그대로 투영된다. 웹 서비스가 완성되면 그것이 랜딩 페이지의 디자인 레퍼런스가 되고, 동시에 React Native 앱이 구현해야 할 기능의 레퍼런스가 된다. 강연자가 여러 플랫폼을 동시에 개발하지 말고 순차적으로 완성해 나가라고 권고하는 것도 이 때문이다. 하나를 완성하고 그것을 기준으로 다음을 만들면 전체 품질이 상향 평준화되는 반면, 동시에 여러 플랫폼을 진행하면 각각의 완성도가 분산되어 결국 모두 엉성해지는 결과를 낳는다.
마무리 / 핵심 정리
이 영상이 전달하는 가장 중요한 인사이트는 기술 스택의 선택이 아니라 개발 워크플로우의 재설계다. 강연자는 가장 구현하기 쉽고 AI 이터레이션이 용이한 플랫폼(Next.js 웹)에서 시작해 Playwright를 통한 자동 검증 루프로 사람의 개입을 최소화한 뒤, 그 완성된 결과물을 레퍼런스로 삼아 랜딩 페이지와 모바일 앱을 순차적으로 확장하는 흐름을 제시했다. 이 세 단계가 Turborepo 기반 모노레포 위에서 하나의 저장소로 연결될 때, 코드 재사용과 공통 설정의 이점이 멀티플랫폼 개발의 복잡성 비용을 넘어서게 된다.
사람이 병목이 되어서는 안 된다는 강연자의 반복적인 강조는 단순한 편의주의가 아니라 AI 시대 개발 생산성의 핵심 원리다. MCP로 데이터베이스 마이그레이션을 자동화하고, Playwright로 UI 검증 루프를 자동화하면, 개발자는 초기 요구사항 정의와 최종 결과 확인이라는 판단이 필요한 영역에만 집중할 수 있다. 여기에 MiniMax M2.7처럼 응답 속도가 빠른 모델을 결합하면 이 루프의 회전 속도가 배가된다는 것이 강연자의 결론이다. 적은 인력, 적은 토큰 비용, 최소한의 사람 개입으로 다중 플랫폼 서비스를 구축하는 이 워크플로우는, 바이브 코딩이 단순한 유행어가 아니라 구체적인 방법론으로 자리잡아가고 있음을 보여준다.
📚 출처 및 참고
| 구분 | 내용 |
|---|---|
| 원본 영상 | 바이브 코딩 튜토리얼! 모노레포로 멀티 플랫폼 개발하기 |
| 채널 | 코드팩토리 |
| 리포트 작성 | 2026-04-24 |
| 작성 방식 | YouTube 영상 STT 변환 후 에디팅 |
💬 본 리포트는 영상 내용을 바탕으로 재구성되었습니다. 정확한 내용은 원본 영상을 참조해 주세요.