기획부터 배포까지 | 현업 개발자의 바이브코딩 풀코스

한 줄 핵심

Claude Desktop과 MCP를 활용해 아이디어 구상부터 리서치, 디자인, 구현, App Store 심사 제출까지 AI 네이티브 회의록 앱을 실제로 완성하는 전 과정을 실시간으로 보여주는 바이브 코딩 실전 라이브다.

시간별 요약

1. 0:00
   시작 대기 방송 시작 전 목을 가다듬으며 라이브 준비 상태를 정리한다.
2. 4:39
   인사 이번 라이브의 목적은 기획부터 배포까지를 한 번에 보여주는 것이며, 최신 흐름에 맞춰 다시 실전형 데모를 진행한다.
3. 6:26
   오늘 사용할 도구 Claude Desktop과 직접 만든 마피아MCP를 사용해 기획·디자인·개발 판단을 보조하고, 더 똑똑하게 작업을 진행하는 구조를 만든다.
4. 8:00
   비개발자도 가능한가요? 비개발자도 만들 수는 있지만 실제 운영에는 HTTP, 서버 장애, 인프라 같은 기본 지식이 필요하므로 최소한의 개발 이해는 갖춰야 한다.
5. 10:09
   오늘 만들 앱: AI 네이티브 회의록 앱 Void 위젯과 알림바에서 바로 녹음을 시작하고, 로컬 전사·자동 정지·정보 유출 방지 같은 특성을 가진 AI 네이티브 회의록 앱 Void를 만든다.
6. 12:13
   프로젝트 폴더부터 만들기 작업 폴더와 환경을 먼저 만들고, 프롬프트와 초기 기획을 분리해 입력할 수 있도록 기본 작업 환경을 세팅한다.
7. 16:03
   첫 프롬프트: 어디서부터 시작해야 할까? 아주 짧은 초기 요구사항만 넣고, 어디서부터 시작할지와 전문적인 진행 방식을 Claude에게 맡겨 기획의 출발점을 잡는다.
8. 18:20
   마피아MCP의 계획: 성공 기준을 숫자로 정하고 기존 앱부터 조사 코드를 바로 쓰지 않고 성공 기준을 수치로 정의한 뒤, 기존 앱과 경쟁 제품을 조사해 기능 범위와 기술 요구사항을 구체화한다.
9. 34:02
   조사 결과: 같은 조합의 앱은 없다 전사·요약·완전 로컬·무음 자동 정지를 모두 갖춘 앱은 없다는 점을 확인하고, 경쟁군과 차별화 포인트를 다시 정리한다.
10. 36:02
    타깃 다시 잡기: 데이터 유출을 걱정하는 AI 네이티브 조직 개인 사용자가 아니라 실무 데이터 유출을 걱정하면서도 AI 네이티브한 업무 환경을 원하는 조직을 주 타깃으로 재정의한다.
11. 45:14
    국내·해외 엔터프라이즈 경쟁자 조사 국내외 엔터프라이즈 회의록·노트테이커 시장을 살피며, 실제 구매자는 단순 개인이 아니라 조직 단위라는 점과 포지셔닝 방향을 점검한다.
12. 50:00
    Q. 에이전트를 만드는 것과 Claude Code를 쓰는 것은 뭐가 다른가요? 에이전트 제작은 단순 호출보다 훨씬 넓은 개념이며, 하네스 엔지니어링처럼 실행 환경과 통제 구조까지 포함하는 작업이라는 점을 설명한다.
13. 52:32
    B2C는 무료로, 수익은 B2B에서 무료 B2C로 관심을 모으고 B2B에서 수익을 내는 전략을 고민하지만, 결국 돈을 낼 고객군에 바로 집중하는 쪽이 더 적합하다는 방향으로 정리한다.
14. 58:36
    수익 모델과 포지셔닝 확정 수익은 B2B 라이선스와 컨설팅으로 두고, 고객 인프라에 설치해 우리 서버를 거치지 않는 포지셔닝으로 최종 방향을 잡는다.
15. 1:00:44
    음성 전사 엔진 실측 시작 긴 작업은 백그라운드로 돌리면서 전사 엔진의 성능과 앱 UI 작업을 병렬로 진행해 실제 동작 기준을 검증한다.
16. 1:03:39
    디자인 레퍼런스 조사 미니멀한 툴과 앱을 레퍼런스로 삼아 여러 시안을 만들고, 전사 품질 검증과 디자인 탐색을 동시에 진행한다.
17. 1:10:47
    디자인 시안 비교와 선택 여러 디자인 안 중에서 가장 미니멀한 시안을 고르고, 무음 자동 정지와 같은 핵심 상태 표현은 더 단순하고 상징적으로 바꾸도록 수정 요청한다.
18. 1:20:32
    아마존식 보도자료(Working Backwards)로 기획 다지기 출시된 상태를 가정해 보도자료를 먼저 써 보고, 사람들이 무엇에 관심을 가질지 거꾸로 검토하면서 기능의 매력도와 메시지를 다듬는다.
19. 1:32:35
    "화면이 난잡하다" 피드백 → 애플 기본 앱과 비교 점검 화면이 복잡하다는 피드백을 반영해 애플 기본 앱과 비교하며 레이아웃과 시각 규칙을 다시 점검하고, 더 깔끔한 구조로 수정 방향을 잡는다.
20. 1:49:03
    디자인 확정, 코드 작업 시작 디자인이 최종 확정되자 Git 세팅과 본격적인 코드 작업으로 넘어가며, 랜딩 페이지와 도메인 작업도 함께 준비한다.
21. 1:51:58
    도메인 구매와 랜딩 페이지 기획 서비스명과 연결될 도메인을 구매하고, 랜딩 페이지까지 포함해 제품 전체의 외부 노출 구조를 함께 설계한다.
22. 2:00:53
    랜딩 페이지 레퍼런스 조사 토스 등 다양한 서비스를 참고해 랜딩 페이지의 구조와 디자인 흐름을 조사하고, 제품 성격에 맞는 웹 구성을 찾는다.
23. 2:22:08
    다른 세션이 이어받을 수 있게 문서로 남기기 진행 내용을 문서화해 다른 세션이 이어서 작업할 수 있게 만들고, 코드와 문서 간 불일치도 함께 점검한다.
24. 2:27:25
    마피아MCP로 프로젝트 문서 점검 프로젝트 문서와 실제 상태를 대조해 누락이나 오기입을 수정하고, 개발 맥락이 어긋나지 않도록 문서를 정리한다.
25. 2:33:25
    랜딩 페이지 첫 시안 리뷰 첫 랜딩 시안이 텍스트 위주로 답답하게 느껴져, 표현과 구성 방식이 글로벌하고 직관적으로 보이도록 다시 손본다.
26. 2:43:50
    Q. 최신 AI 도구를 일일이 공부해야 할까요? 새 도구를 단순히 써보는 것보다, 그 도구가 해결하려는 문제와 철학을 이해하는 것이 차별점이 되며, 특히 시니어에게 더 의미가 있다.
27. 2:48:50
    첫 녹음·전사 테스트 실제 녹음과 전사가 잘 되는지 확인하면서, 실시간 표시와 자동 정리 같은 사용자 경험 요소가 아직 보강돼야 함을 확인한다.
28. 2:50:14
    REA로 경쟁 앱 UX 분석 경쟁 미팅 노트 앱의 UI/UX와 마이크로 인터랙션을 체계적으로 분석해, 직접 구현하기 전에 참고할 전사 품질과 인터페이스 패턴을 추린다.
29. 3:04:43
    Q. 전사는 어떤 모델을 쓰나요? 전사는 클라우드 API가 아니라 온디바이스 모델인 Whisper를 사용하며, 데이터가 시스템 밖으로 나가지 않는 점이 핵심 장점이다.
30. 3:16:16
    전화로 쓰는 Claude 에이전트 시연 음성 통화 방식으로 Claude와 연결해 브리핑과 작업 지시를 수행하며, 운전이나 설거지처럼 손이 바쁠 때도 에이전트를 활용할 수 있음을 보여준다.
31. 3:23:03
    요즘 시대에 개발자라는 이점 AI 덕분에 누구나 프로토타입은 만들 수 있지만, 끝까지 완성시키는 힘은 개발·기획·디자인의 기본기가 있는 사람에게 더 유리하다는 점을 짚는다.
32. 3:28:34
    Q. 어떤 창업을 하셨었나요? 과거 남성 패션 쇼핑몰 창업 경험과 투자 유치, 실패 경험을 공유하며, 엔터프라이즈와 협업할 때는 이력과 신뢰가 중요하다는 현실도 설명한다.
33. 3:50:02
    랜딩 페이지 시안 확정 여러 시안 중 가장 직관적이고 깔끔한 버전을 최종 선택해 랜딩 페이지 방향을 확정한다.
34. 3:52:19
    기기 안 모델로는 요약이 어렵다 → 요약 빼기 온디바이스 모델만으로는 요약 품질을 만족시키기 어렵다고 판단해, 요약 기능은 제외하고 전사 품질 중심으로 정리한다.
35. 3:56:22
    랜딩 페이지 구현 디자인 시안을 실제 페이지로 옮기며, AI가 과한 계획을 세울 수 있으므로 구현 전후로 비용과 실행 가능성을 검토하는 태도를 유지한다.
36. 4:13:04
    Q. @ 명령어 자주 쓰시나요? 파일이나 폴더를 직접 지정하는 @ 명령은 요즘 잘 쓰지 않으며, 세부 지정보다 AI가 맥락을 알아서 활용하도록 두는 편이 많다.
37. 4:17:30
    오늘의 목표: App Store 심사 제출 오늘의 최종 목표를 App Store 심사 제출로 재확인하고, 배포와 등록을 향해 작업 속도를 끌어올린다.
38. 4:19:15
    랜딩 페이지 배포·도메인 연결 웹페이지를 실제로 배포하고 도메인을 연결하며, 제품 공개를 위한 외부 접점을 완성해 간다.
39. 4:20:02
    출시 전에 준비할 것들 심사에 필요한 자료와 배포 체크리스트를 점검하고, 데이터베이스나 로그인 같은 요소가 없어 심사가 상대적으로 쉬워질 수 있음을 확인한다.
40. 4:41:52
    Android 앱 개발 시작 iOS에 이어 Android 버전도 병렬로 개발하며, 세션을 나눠도 작업 충돌이 적도록 구조를 정리한다.
41. 5:03:04
    Q. 세션을 여러 개 병렬로 돌리면 느려지지 않나요? 병렬 세션 자체가 느려지게 하진 않지만, 공유 자원 충돌과 CPU 사용량 증가 같은 이유로 느려질 수 있어 환경 설계가 중요하다고 설명한다.
42. 5:09:03
    커서맛피아에서 바이브마피아로 바꾼 이유 Cursor의 존재감이 예전보다 약해져 이름의 효용이 떨어졌고, 더 넓은 바이브 코딩 맥락을 담기 위해 닉네임을 바꿨다.
43. 5:14:31
    랜딩 페이지 모션 그래픽 랜딩 페이지의 퀄리티를 끌어올리기 위해 모션 그래픽을 추가하는 방향으로 보강 작업을 이어간다.
44. 5:24:10
    App Store Connect 등록 App Store Connect 등록과 심사 제출 절차를 진행하며, 출시 준비를 실무 단계까지 밀어붙인다.
45. 5:32:21
    디자인 세부사항은 직접 정하지 말고 AI에게 디자인 세부는 사람이 억지로 정하기보다 AI가 레퍼런스를 조사하고 여러 버전을 제안하게 한 뒤 선택하는 방식이 더 효율적이라고 정리한다.
46. 5:39:47
    히어로 문구: AI 네이티브 팀을 위한 노트테이커 이 앱을 AI 네이티브 팀을 위한 로컬 기반 노트테이커로 정의하고, 알림창 등에서 빠르게 시작할 수 있는 제품 메시지를 만든다.
47. 5:47:04
    Q. 노트테이커는 이미 많은데 왜 만드나요? 기존 노트테이커가 많아도 전사 완료 시 바로 다른 워크플로로 넘기는 자동화가 필요하므로, AI 네이티브 팀용으로 차별화된 포지셔닝이 가능하다고 본다.
48. 6:07:50
    Claude 응답은 어디까지 읽나요? 설계와 관련된 응답은 꼼꼼히 읽고, 구현 세부는 과감히 넘기는 식으로 중요한 정보만 선별해서 활용한다.
49. 6:10:04
    스토어 미리보기 이미지 다시 만들기 스토어에 올릴 미리보기 이미지를 더 보기 좋게 다시 만들고, CTA와 문구도 실제 출시용으로 다듬는다.
50. 6:18:07
    이 앱이 비교적 쉬웠던 이유: 서버·DB가 없다 서버와 DB가 없는 로컬 앱이라 아키텍처와 인프라 부담이 적었고, 그래서 개발 난이도가 상대적으로 낮았다고 정리한다.
51. 6:26:29
    Q. 서버 없이 로컬 LLM을 쓰나요? 이 앱은 로컬 LLM을 쓰는 구조가 아니라, 음성 전사 모델만 온디바이스로 내려받아 실행하는 방식이라고 설명한다.
52. 6:34:01
    App Store 심사 제출 완료 아이디어 단계였던 앱이 랜딩 페이지와 스토어 등록 정보를 갖춘 상태로 심사 제출까지 완료되며, MVP 출시 단계에 도달한다.
53. 6:35:56
    마무리 목표를 달성하고 라이브를 마무리하며, 다음 주에도 다른 주제로 다시 돌아오겠다고 인사한다.

실무 인사이트

• 초기에는 기능 구현보다 성공 기준, 타깃, 수익 구조를 먼저 숫자와 문장으로 고정해야 이후 디자인과 개발이 흔들리지 않는다.
• AI 개발에서는 직접 정답을 쓰기보다 레퍼런스를 조사하게 하고 여러 시안을 받은 뒤 선택하는 방식이 시간 대비 품질이 높다.
• 서버·DB 없이 완전 로컬로 설계하면 심사와 운영 난도가 크게 내려가므로, 첫 버전 MVP에서는 의도적으로 복잡도를 줄이는 전략이 유효하다.