라이브 바이브코딩 | 바이브마피아가 대신 만들어드림

한 줄 핵심

바이브 코딩으로 두 가지 요청을 빠르게 MVP 수준까지 구현하면서, 요구사항 정리·개념 모델링·API 계약·병렬 개발·문서 정리 같은 설계 역량이 결과물을 좌우한다는 점을 실전으로 보여준 영상이다.

시간별 요약

1. 0:00
   시작 대기 방송 시작 전 간단히 인사를 나누며 라이브를 준비한다.
2. 8:37
   인트로 — 대신 만들어드림이 돌아왔습니다 시청자 요청을 받아 라이브에서 아이디어를 직접 구현해 주는 형식의 방송임을 소개하고, 오늘 첫 번째 요청을 시작한다.
3. 9:33
   요청 1: 욕실장 3D 커스텀 주문 사이트 욕실장 색상, 거울 형태, 내부 간격, 사이즈를 3D 애니메이션처럼 고르며 주문하는 사이트를 만들기로 하고, 구현 방향을 대략 잡는다.
4. 12:07
   폴더 만들고 Claude Code 세션 시작 터미널에서 프로젝트 폴더를 만든 뒤 Claude Code 세션을 열고, 이미지를 넣어 요구사항을 파악하도록 지시한다.
5. 16:38
   마피아MCP로 요구사항 분석하기 마피아 MCP로 요구사항을 정리해 3D 욕실장 커스텀 경험의 핵심을 빠른 프로토타이핑과 옵션 커스터마이징으로 정의한다.
6. 18:37
   빠른 프로토타입을 위해 가벼운 기술 구성(바닐라 HTML·JS)으로 구현은 바닐라 HTML·JS처럼 가벼운 스택으로 시작하고, 3D 모델은 실제 제품과 비슷하게 보여야 한다는 조건을 강조한다.
7. 20:23
   프로토타입으로 UI·UX 감부터 잡는 이유 처음부터 구조를 무겁게 잡기보다 빠른 프로토타입으로 UI·UX 감을 먼저 잡아야 시행착오 비용이 줄어든다고 정리한다.
8. 27:01
   모델이 너무 느리면 되돌린다 엑스트라 모드가 너무 느리다고 판단해 되돌리고, 속도 개선을 위해 병렬 작업을 고려한다.
9. 30:58
   작업 분해 계획으로 쪼개기 WBS처럼 작업을 작은 단위로 분해해 병렬화하고 병목을 찾는 방식이 에이전트 개발에도 유효하다고 설명한다.
10. 34:11
    세션 하나 더 — 병렬 개발 새 세션을 열어 작업을 병렬로 돌리고, 서로 기다릴 필요 없는 일부터 동시에 진행한다.
11. 36:23
    3D 현실감 퀄리티 끌어올리기 3D 렌더링의 현실감을 높이는 기법을 더 요청하고, 3D 데모의 조형 품질이 핵심이라고 본다.
12. 40:02
    미감·사용감 평가는 AI 말고 내가 링크로 직접 미감 평가는 AI가 아니라 직접 들어가서 확인해야 하며, 6~7단계 수준의 결과부터는 사람이 최종 판단해야 한다고 정리한다.
13. 46:04
    유사 레퍼런스 사이트 분석 비슷한 서비스들을 찾아 UX와 반응을 분석하고, 실제 레퍼런스를 참고해 구조를 뜯어본다.
14. 50:52
    욕실장 커스텀 주문 시안 완성 옵션 선택에 따라 3D 렌더링과 주문 흐름이 완성되고, MVP 수준에서는 의외로 쉽게 구현된다고 평가한다.
15. 54:03
    실제 쇼핑몰에 붙이려면 실제 쇼핑몰에 붙여도 결제와 모바일 대응이 크게 어렵지 않아 보이며, 관리자 페이지까지 함께 고려한다.
16. 56:27
    Opus 엑스트라를 쓸 이유가 없었다 Opus 엑스트라는 느리고 비용 대비 이점이 적어 보이며, 토큰을 아끼기 위해 끄는 쪽으로 판단한다.
17. 59:53
    문서화 점검 — 남지 말아야 할 문서까지 진행 상황을 따라잡을 수 있도록 문서화하되, 남겨야 할 문서와 남기지 말아야 할 문서를 함께 점검한다.
18. 1:08:47
    비슷한 서비스는 연 1,700만 원? 유사 서비스의 가격과 사업성을 보고, 세션 데이터는 귀중한 자원이라 지우지 않고 아카이브하는 방식을 선호한다고 말한다.
19. 1:12:14
    오픈소스로 만들면 어떨까 가구 회사의 기술 수준과 매니지드 서비스 수요를 고려하면 오픈소스만으로는 사업화가 쉽지 않을 수 있다고 본다.
20. 1:16:33
    요청 2: 토익 단어 앱 두 번째 요청으로 토익 단어 학습 앱을 다루고, 단어 공부 앱인지 시험 대비 앱인지 범위를 먼저 정리한다.
21. 1:21:30
    개념 모델링 직접 해보기 유저, 문제, 단어, 선택지, 풀이 기록, 구독, 결제, 북마크 같은 핵심 개념을 관계 중심으로 직접 모델링한다.
22. 1:31:57
    애그리거트 나누기 도메인 객체를 유저, 문제, 단어, 풀이 기록 단위의 애그리거트로 나누며, 어디에 무엇을 묶을지 정리한다.
23. 1:36:54
    개념 모델을 AI에게 넘기고 되물어 달라고 하기 정리한 개념 모델과 요구사항을 AI에 넘겨 확인 질문을 받으며, 누락된 제약과 운영 조건을 보완한다.
24. 1:44:06
    앱 DB 스키마는 왜 바꾸기 어려운가 앱이 DB에 직접 붙으면 스키마 변경이 어려워지고 유지보수가 힘들어지므로, 서버 레이어를 두는 편이 낫다고 설명한다.
25. 1:48:11
    확정한 결정은 decisions.md에 의사결정 내용을 문서로 남겨 팀과 세션 간 기준을 공유하고, 이후 구현 방향을 흔들리지 않게 한다.
26. 1:50:06
    작업을 어떻게 나눌까 — API 엔드포인트 규칙 도메인 스토리에서 REST API 엔드포인트와 권한 표를 도출하고, 병렬 개발을 위해 API 계약을 먼저 확정한다.
27. 1:54:15
    TypeScript 모노레포 스캐폴딩 Pnpm 기반 모노레포를 잡고 React Native, 서버, 웹, 공용 패키지를 TypeScript로 통일해 시작한다.
28. 2:04:41
    Supabase Auth를 쓰지 않는 이유 · 수직 슬라이스 Supabase Auth 대신 서버에서 권한을 통제하고, 기능 단위 수직 슬라이스로 개발하는 구조가 유지보수에 유리하다고 본다.
29. 2:12:05
    서버 구현에 AOP 관점 넣기 인증·권한처럼 여러 곳에 반복되는 로직은 AOP 관점으로 묶어 중복을 줄이고 구조를 정돈해야 한다고 설명한다.
30. 2:14:07
    API 계약부터 정하면 서버·앱을 병렬로 API 스펙을 먼저 정해 두면 서버와 앱을 동시에 개발할 수 있고, 작업 시간을 줄이는 최적화가 가능하다.
31. 2:18:03
    API를 검토하다 보니 약관 동의 모델이 필요하다 API를 검토하는 과정에서 약관 동의와 같은 추가 도메인 모델이 필요해졌고, 이를 기획 단계에서 반영한다.
32. 2:40:17
    ts-rest로 계약(contract) 만들기 ts-rest 같은 계약 도구를 검토하며, 컨트랙트를 기준으로 나머지 모노레포 구성 요소를 스캐폴딩한다.
33. 2:48:52
    랜딩 페이지·디자인도 병렬로 서버 작업과 별개로 랜딩 페이지와 디자인 작업도 병렬로 돌리며, 모노레포 관리 방식의 이점을 설명한다.
34. 2:54:06
    모노레포와 작업 순서 고정 모노레포에서는 작업 순서를 고정하고 캐시를 활용해 반복 작업을 줄일 수 있으며, 지금은 그 관리 도구가 당장 필요하지 않다고 본다.
35. 2:58:02
    서버 코드 아키텍처 잡기 서버와 앱을 포함한 전체 프로젝트의 폴더 구조와 아키텍처를 어떻게 나눌지 고민하며 기본 뼈대를 점검한다.
36. 3:02:07
    레퍼런스 없는 디자인은 별로다 디자인은 레퍼런스 조사 없이 바로 만들면 결과가 별로라며, 참고 사례를 기반으로 진행해야 퀄리티가 오른다고 말한다.
37. 3:03:47
    Q&A: HTML 시안을 피그마로 옮기려면? HTML 시안을 피그마로 옮기는 과정과 피그마 AI 활용 여부를 묻는 질문에 답하며, 실제 도구 활용 경험을 공유한다.
38. 3:10:57
    욕실장 3D 렌더러 결과 다시 보기 완성된 3D 렌더러를 다시 보여 주며, 옵션에 따라 렌더링이 바뀌는 제품 경험을 확인한다.
39. 3:12:23
    오늘 한 일 정리 — 요청자 기획에서 개념 모델까지 오늘 작업을 정리하며 서버 분리, TypeScript 통일, RLS 대신 서버 권한 제어, 개념 모델링과 AI 보완 과정을 다시 요약한다.
40. 3:16:42
    Q&A: 협업 기능은 처음부터 고려해야 할까? 실시간 협업은 초기부터 고려하는 게 좋지만 구현이 까다로우며, 레퍼런스 서비스의 API 구조를 역설계해 참고할 수 있다고 답한다.
41. 3:20:04
    랜딩 페이지 시안 고르기 여러 랜딩 페이지 시안을 비교해 보고, 참고 사례를 바탕으로 괜찮은 방향을 골라낸다.
42. 3:27:07
    모바일 디자인 시안 비교 → D 선택 모바일 시안을 A~D로 비교한 뒤 D가 가장 단순하고 낫다고 판단해 선택한다.
43. 3:33:34
    정리 — 앱 MVP까지 얼마나 걸릴까 초반 설계와 레퍼런스 기반 디자인을 잘 잡으면 MVP는 대략 4시간 내외로 가능하다고 보고, 인프라와 아키텍처 학습의 중요성을 덧붙인다.
44. 3:36:07
    마무리 시청자에게 감사 인사를 전하며 라이브를 마무리한다.

실무 인사이트

• 바이브 코딩에서도 가장 큰 차이는 코딩 속도보다 요구사항을 도메인 모델과 API 계약으로 먼저 정리하는 능력에서 난다.
• MVP는 완벽한 설계보다 병렬화 가능한 작업 분해, 문서화, 레퍼런스 확보가 성패를 좌우한다.
• 앱을 DB에 직접 붙이는 구조는 초기에 빨라 보여도 스키마 변경과 권한 관리 때문에 결국 유지보수 비용을 키우므로, 서버 레이어를 두는 편이 안전하다.