기획자 윤누리와 개발자 황인준이 5주간 바이브 코딩으로 서비스를 런칭하기까지의 과정입니다!
팀 소개
10년 동안 프론트엔드를 해왔습니다. NextJS, React, Vue, 뭐든 익숙했습니다. 그런데 백엔드를 사이드 프로젝트 수준이 아닌 서비스 레벨에서 메인으로 담당해본 적은 한 번도 없었습니다.
이번 프로젝트에서 처음으로 백엔드 및 인프라 구성을 맡았습니다.
본업은 기획자입니다. AI가 본격화되기 전부터, '바이브 코딩'이라는 말이 생기기도 전부터 AI로 코드를 짜왔습니다. ChatGPT 초기 버전부터 프론트, 백, 파이썬 자동화를 만들었습니다.
문제는 AI로 해결이 안 될 때였습니다. 에러가 나면 AI한테 물어보고, AI가 준 답이 또 에러를 내고, 그 에러를 또 물어보고... 이 루프에서 빠져나오지 못할 때가 종종 있었습니다.
저희는 이런 상황에서 2025년 zero100 빌더톤에 참여하게 되었습니다.
프로젝트 시작: 노션에서의 기획과 R&R
빌더톤에 참여하면서 어떤 아이디어로 도전할지 고민했습니다. 결국 '당장이라도 돈을 벌 수 있는 아이디어'라는 관점에서 AI 포트폴리오 서비스가 최종 아이디어로 선정됐습니다. (상 탄 아이디어를 반대한 사람이 저입니다..)
프로젝트는 노션에서 시작했습니다. 아이디어 정리, 기능 목록, 일정 계획. 모든 게 노션 페이지 안에 있었습니다.
R&R은 자연스럽게 나뉘었습니다:
이 과정에서 R&R을 직접 정했고 단순히 개발/기획, front와 back으로 나누지 않은건 누리님이 바이브코딩으로 충분히 한 feature를 구현하기 충분하고 이 과정 자체가 더 서로 즐겁게 일할 수 있는 방식이라고 판단했기 때문에 이렇게 진행했습니다. 이것이 프로젝트를 모노 레포로 구조로 선택하게 된 계기 였습니다.
| 구분 | 윤누리 | 황인준 |
|---|---|---|
| 포지션 | Product Owner & Vibe Coder | Tech Lead & Developer |
| 핵심 역할 | 서비스 컨셉 기획 및 초기 아이디어 제공 바이브 코더 관점의 제품 요구사항 정의 실사용자로서 피드백 및 개선사항 도출 | 프로젝트 기술 설계 및 아키텍처 책임 개발 방향 설정 및 기술 의사결정 인프라 구축 및 배포 관리 |
| 개발 영역 | 포트폴리오 생성 시스템 (Full-stack) • GitHub 데이터 분석 및 시각화 • Vibe 코딩 메트릭 통합 및 표시 • 포트폴리오 템플릿 및 커스터마이징 • 포트폴리오 공유 및 프라이버시 설정 프로젝트 분석 시스템 (Full-stack) • 분석/평가 페이지 구현 • 프로젝트 동기화, 일괄 분석, 재분석 기능 Daily Review 시스템 (Full-stack) • Daily Review 메인/상세 페이지 • /dailyreview-sync 커스텀 커맨드 개발• Git 커밋 분석 로직, Claude AI 통합 | 인증 시스템 • GitHub OAuth 통합 • 사용자 인증/인가 관리 결제 시스템 • 구독/결제 모듈 구현 • 플랜별 기능 제어 백그라운드 처리 • GitHub 프로젝트 비동기 데이터 수집 • Worker 시스템 구축 (BullMQ) • 대용량 데이터 처리 최적화 인프라 & DevOps • 모노레포 구조 설정 및 관리 • CI/CD 파이프라인 • 데이터베이스 설계 및 최적화 • 배포 환경 구축 (Railway + Vercel) |
| 개발 방식 | Vibe 코딩을 활용한 빠른 프로토타이핑 실제 사용 경험을 바탕으로 한 기능 개발 | 기획 완료 후 체계적인 개발 아키텍처 설계 우선 접근 |
✅ 명확한 분업:
✅ 상호 보완:
첫번쨰 고민 - 문서화
첫번쨰 고민 - 문서화 그런데 고민이 하나 있었습니다. 문서화를 어디에 할 것인가? 저는 노션에 모든 문서가 기록되길 바랐습니다. 하지만 누리님은 "왜 굳이 노션에 한 번 더 써야 되는지 모르겠다"고 했습니다.
제 주장은 이랬습니다. 클로드 코드에 기획 문서를 추가하는 것은 당연하다. 하지만 클로드 코드에 작성되어 있는 문서가 언제 추가되고 변경되는지 확인하기 어렵고, 그 맥락을 팀 차원에서 공유할 수 있는 방법은 노션이라고 생각했습니다.
결론부터 말하면, 제가 졌습니다. 결국 선택한 방식은 CLAUDE.md 시스템이었습니다. 프로젝트 루트와 각 앱 폴더에 claude.md 파일을 두고, 개발 맥락을 코드와 함께 버전 관리했습니다.
이 결정이 나중에 큰 차이를 만들었습니다. 윤누리가 Claude Code를 쓸 때, 프로젝트 맥락을 AI가 바로 이해할 수 있었습니다. "이 프로젝트는 이런 구조고, 이런 패턴을 쓰고 있어"라고 매번 설명할 필요가 없었습니다.
결국 선택한 방식은 CLAUDE.md 시스템이었습니다. 프로젝트 루트와 각 앱 폴더에 claude.md 파일을 두고, 개발 맥락을 코드와 함께 버전 관리했습니다.
이 결정이 나중에 큰 차이를 만들었습니다. 윤누리가 Claude Code를 쓸 때, 프로젝트 맥락을 AI가 바로 이해할 수 있었습니다. "이 프로젝트는 이런 구조고, 이런 패턴을 쓰고 있어"라고 매번 설명할 필요가 없었습니다.
하지만 관리를 잘못한 탓에 5주차에 문서 폭탄으로 돌아왔습니다.
이 후 초기 화면 기획은 누리님이 Google AI Studio 를 사용하여 모든 화면에 대한 기획을 마쳤고, 저는 그 화면을 보며 클로드 코드와 화면에 대한 명세, API 명세, 인프라 구성, 프로젝트 구조에 대한 기획을 할 수 있었습니다.
own-it/ ├── apps/ # Application workspaces ├── packages/ # Shared packages ├── docs/ # Documentation (restructured) ├── docker/ # Docker configurations ├── scripts/ # Utility scripts ├── testsprite_tests/ # E2E test suites ├── env-package/ # Environment file packaging ├── docs-backup-20251215/ # Documentation backup ├── worktrees/ # Git worktrees ├── .github/ # GitHub Actions workflows ├── docker-compose.yml # Local development services ├── turbo.json # Turborepo configuration ├── pnpm-workspace.yaml # PNPM workspace configuration ├── package.json # Root package.json (workspace) └── claude.md # AI development guide
apps/api/ ├── src/ │ ├── config/ # Configuration (database, GitHub, JWT) │ ├── controllers/ # Request handlers │ ├── db/ # Database schema and migrations │ ├── middlewares/ # Express middlewares │ ├── routes/ # API route definitions │ ├── services/ # Business logic services │ ├── types/ # TypeScript types │ ├── utils/ # Utility functions │ └── index.ts # Application entry point ├── docs/ # API-specific documentation ├── scripts/ # Database and utility scripts ├── drizzle.config.ts # Drizzle ORM configuration ├── package.json ├── tsconfig.json └── claude.md # API development guide
apps/web/ ├── app/ # Next.js 15 App Router │ ├── (auth)/ # Auth routes (login, signup) │ ├── (main)/ # Main app routes (dashboard, editor) │ ├── (public)/ # Public routes (landing, portfolio view) │ ├── api/ # API routes (webhooks, internal) │ ├── layout.tsx # Root layout │ └── page.tsx # Landing page ├── components/ # React components │ ├── blocks/ # Portfolio block components │ ├── dashboard/ # Dashboard UI components │ ├── editor/ # Portfolio editor components │ ├── modals/ # Modal dialogs │ ├── theme/ # Theme system components │ └── ui/ # shadcn/ui components ├── contexts/ # React contexts ├── hooks/ # Custom React hooks ├── lib/ # Libraries and utilities │ ├── api/ # API client functions │ ├── types/ # TypeScript types │ └── utils/ # Utility functions ├── public/ # Static assets ├── stores/ # State management (Zustand) ├── styles/ # Global styles ├── next.config.ts ├── package.json ├── tsconfig.json └── claude.md # Web development guide
apps/worker/ ├── src/ │ ├── config/ # Configuration │ ├── services/ # Service layer │ │ ├── ai-analyzer.ts # Claude AI integration │ │ └── github-client.ts # GitHub API client │ ├── workers/ # BullMQ worker definitions │ └── index.ts # Worker entry point ├── Dockerfile # Docker container config ├── railway.json # Railway deployment config ├── package.json ├── tsconfig.json └── claude.md # Worker development guide
1-3주차
핵심 기능의 시작점이었습니다.
GitHub OAuth를 붙이고, 사용자의 저장소에 접근할 수 있는 권한 체계를 만들었습니다. 여기서 GitHub App을 선택한 건 나중에 좋은 결정이 됐습니다.
사용자가 직접 만지는 부분이라 공을 들였습니다.
6가지 구성 요소 개발
블록 기반 에디터를 만들었습니다. Hero, About, Project, Skills, Experience, Contact. 6가지 블록을 조합해서 포트폴리오를 구성하는 방식입니다. 누리님이 전부 개발을 맡아서 처리했습니다.
비용이 문제였습니다.
처음엔 Claude Sonnet을 썼는데, 분석 한 번에 $0.50 정도 나왔습니다. 서비스로 굴리기엔 부담스러운 금액이었습니다. Haiku 4.5로 바꾸니까 $0.10으로 떨어졌습니다. 품질은 거의 차이가 없었습니다.
이 과정에서 프로젝트 분석 및 평가를 BullMQ 기반 비동기 Job Queue 시스템으로 구현을 하고, 분석이 완료 알림을 보내도록 구현을 했는데,
이게 누군가가 merge 할때마다 알림이 안오는 이슈가 생겼습니다. 여기서 두번째 문제가 발생했습니다.(이어서...)
댓글을 작성하려면 로그인이 필요합니다.
기획자 윤누리와 개발자 황인준이 5주간 바이브 코딩으로 서비스를 런칭하기까지의 과정입니다!
팀 소개
10년 동안 프론트엔드를 해왔습니다. NextJS, React, Vue, 뭐든 익숙했습니다. 그런데 백엔드를 사이드 프로젝트 수준이 아닌 서비스 레벨에서 메인으로 담당해본 적은 한 번도 없었습니다.
이번 프로젝트에서 처음으로 백엔드 및 인프라 구성을 맡았습니다.
본업은 기획자입니다. AI가 본격화되기 전부터, '바이브 코딩'이라는 말이 생기기도 전부터 AI로 코드를 짜왔습니다. ChatGPT 초기 버전부터 프론트, 백, 파이썬 자동화를 만들었습니다.
문제는 AI로 해결이 안 될 때였습니다. 에러가 나면 AI한테 물어보고, AI가 준 답이 또 에러를 내고, 그 에러를 또 물어보고... 이 루프에서 빠져나오지 못할 때가 종종 있었습니다.
저희는 이런 상황에서 2025년 zero100 빌더톤에 참여하게 되었습니다.
프로젝트 시작: 노션에서의 기획과 R&R
빌더톤에 참여하면서 어떤 아이디어로 도전할지 고민했습니다. 결국 '당장이라도 돈을 벌 수 있는 아이디어'라는 관점에서 AI 포트폴리오 서비스가 최종 아이디어로 선정됐습니다. (상 탄 아이디어를 반대한 사람이 저입니다..)
프로젝트는 노션에서 시작했습니다. 아이디어 정리, 기능 목록, 일정 계획. 모든 게 노션 페이지 안에 있었습니다.
R&R은 자연스럽게 나뉘었습니다:
이 과정에서 R&R을 직접 정했고 단순히 개발/기획, front와 back으로 나누지 않은건 누리님이 바이브코딩으로 충분히 한 feature를 구현하기 충분하고 이 과정 자체가 더 서로 즐겁게 일할 수 있는 방식이라고 판단했기 때문에 이렇게 진행했습니다. 이것이 프로젝트를 모노 레포로 구조로 선택하게 된 계기 였습니다.
| 구분 | 윤누리 | 황인준 |
|---|---|---|
| 포지션 | Product Owner & Vibe Coder | Tech Lead & Developer |
| 핵심 역할 | 서비스 컨셉 기획 및 초기 아이디어 제공 바이브 코더 관점의 제품 요구사항 정의 실사용자로서 피드백 및 개선사항 도출 | 프로젝트 기술 설계 및 아키텍처 책임 개발 방향 설정 및 기술 의사결정 인프라 구축 및 배포 관리 |
| 개발 영역 | 포트폴리오 생성 시스템 (Full-stack) • GitHub 데이터 분석 및 시각화 • Vibe 코딩 메트릭 통합 및 표시 • 포트폴리오 템플릿 및 커스터마이징 • 포트폴리오 공유 및 프라이버시 설정 프로젝트 분석 시스템 (Full-stack) • 분석/평가 페이지 구현 • 프로젝트 동기화, 일괄 분석, 재분석 기능 Daily Review 시스템 (Full-stack) • Daily Review 메인/상세 페이지 • /dailyreview-sync 커스텀 커맨드 개발• Git 커밋 분석 로직, Claude AI 통합 | 인증 시스템 • GitHub OAuth 통합 • 사용자 인증/인가 관리 결제 시스템 • 구독/결제 모듈 구현 • 플랜별 기능 제어 백그라운드 처리 • GitHub 프로젝트 비동기 데이터 수집 • Worker 시스템 구축 (BullMQ) • 대용량 데이터 처리 최적화 인프라 & DevOps • 모노레포 구조 설정 및 관리 • CI/CD 파이프라인 • 데이터베이스 설계 및 최적화 • 배포 환경 구축 (Railway + Vercel) |
| 개발 방식 | Vibe 코딩을 활용한 빠른 프로토타이핑 실제 사용 경험을 바탕으로 한 기능 개발 | 기획 완료 후 체계적인 개발 아키텍처 설계 우선 접근 |
✅ 명확한 분업:
✅ 상호 보완:
첫번쨰 고민 - 문서화
첫번쨰 고민 - 문서화 그런데 고민이 하나 있었습니다. 문서화를 어디에 할 것인가? 저는 노션에 모든 문서가 기록되길 바랐습니다. 하지만 누리님은 "왜 굳이 노션에 한 번 더 써야 되는지 모르겠다"고 했습니다.
제 주장은 이랬습니다. 클로드 코드에 기획 문서를 추가하는 것은 당연하다. 하지만 클로드 코드에 작성되어 있는 문서가 언제 추가되고 변경되는지 확인하기 어렵고, 그 맥락을 팀 차원에서 공유할 수 있는 방법은 노션이라고 생각했습니다.
결론부터 말하면, 제가 졌습니다. 결국 선택한 방식은 CLAUDE.md 시스템이었습니다. 프로젝트 루트와 각 앱 폴더에 claude.md 파일을 두고, 개발 맥락을 코드와 함께 버전 관리했습니다.
이 결정이 나중에 큰 차이를 만들었습니다. 윤누리가 Claude Code를 쓸 때, 프로젝트 맥락을 AI가 바로 이해할 수 있었습니다. "이 프로젝트는 이런 구조고, 이런 패턴을 쓰고 있어"라고 매번 설명할 필요가 없었습니다.
결국 선택한 방식은 CLAUDE.md 시스템이었습니다. 프로젝트 루트와 각 앱 폴더에 claude.md 파일을 두고, 개발 맥락을 코드와 함께 버전 관리했습니다.
이 결정이 나중에 큰 차이를 만들었습니다. 윤누리가 Claude Code를 쓸 때, 프로젝트 맥락을 AI가 바로 이해할 수 있었습니다. "이 프로젝트는 이런 구조고, 이런 패턴을 쓰고 있어"라고 매번 설명할 필요가 없었습니다.
하지만 관리를 잘못한 탓에 5주차에 문서 폭탄으로 돌아왔습니다.
이 후 초기 화면 기획은 누리님이 Google AI Studio 를 사용하여 모든 화면에 대한 기획을 마쳤고, 저는 그 화면을 보며 클로드 코드와 화면에 대한 명세, API 명세, 인프라 구성, 프로젝트 구조에 대한 기획을 할 수 있었습니다.
own-it/ ├── apps/ # Application workspaces ├── packages/ # Shared packages ├── docs/ # Documentation (restructured) ├── docker/ # Docker configurations ├── scripts/ # Utility scripts ├── testsprite_tests/ # E2E test suites ├── env-package/ # Environment file packaging ├── docs-backup-20251215/ # Documentation backup ├── worktrees/ # Git worktrees ├── .github/ # GitHub Actions workflows ├── docker-compose.yml # Local development services ├── turbo.json # Turborepo configuration ├── pnpm-workspace.yaml # PNPM workspace configuration ├── package.json # Root package.json (workspace) └── claude.md # AI development guide
apps/api/ ├── src/ │ ├── config/ # Configuration (database, GitHub, JWT) │ ├── controllers/ # Request handlers │ ├── db/ # Database schema and migrations │ ├── middlewares/ # Express middlewares │ ├── routes/ # API route definitions │ ├── services/ # Business logic services │ ├── types/ # TypeScript types │ ├── utils/ # Utility functions │ └── index.ts # Application entry point ├── docs/ # API-specific documentation ├── scripts/ # Database and utility scripts ├── drizzle.config.ts # Drizzle ORM configuration ├── package.json ├── tsconfig.json └── claude.md # API development guide
apps/web/ ├── app/ # Next.js 15 App Router │ ├── (auth)/ # Auth routes (login, signup) │ ├── (main)/ # Main app routes (dashboard, editor) │ ├── (public)/ # Public routes (landing, portfolio view) │ ├── api/ # API routes (webhooks, internal) │ ├── layout.tsx # Root layout │ └── page.tsx # Landing page ├── components/ # React components │ ├── blocks/ # Portfolio block components │ ├── dashboard/ # Dashboard UI components │ ├── editor/ # Portfolio editor components │ ├── modals/ # Modal dialogs │ ├── theme/ # Theme system components │ └── ui/ # shadcn/ui components ├── contexts/ # React contexts ├── hooks/ # Custom React hooks ├── lib/ # Libraries and utilities │ ├── api/ # API client functions │ ├── types/ # TypeScript types │ └── utils/ # Utility functions ├── public/ # Static assets ├── stores/ # State management (Zustand) ├── styles/ # Global styles ├── next.config.ts ├── package.json ├── tsconfig.json └── claude.md # Web development guide
apps/worker/ ├── src/ │ ├── config/ # Configuration │ ├── services/ # Service layer │ │ ├── ai-analyzer.ts # Claude AI integration │ │ └── github-client.ts # GitHub API client │ ├── workers/ # BullMQ worker definitions │ └── index.ts # Worker entry point ├── Dockerfile # Docker container config ├── railway.json # Railway deployment config ├── package.json ├── tsconfig.json └── claude.md # Worker development guide
1-3주차
핵심 기능의 시작점이었습니다.
GitHub OAuth를 붙이고, 사용자의 저장소에 접근할 수 있는 권한 체계를 만들었습니다. 여기서 GitHub App을 선택한 건 나중에 좋은 결정이 됐습니다.
사용자가 직접 만지는 부분이라 공을 들였습니다.
6가지 구성 요소 개발
블록 기반 에디터를 만들었습니다. Hero, About, Project, Skills, Experience, Contact. 6가지 블록을 조합해서 포트폴리오를 구성하는 방식입니다. 누리님이 전부 개발을 맡아서 처리했습니다.
비용이 문제였습니다.
처음엔 Claude Sonnet을 썼는데, 분석 한 번에 $0.50 정도 나왔습니다. 서비스로 굴리기엔 부담스러운 금액이었습니다. Haiku 4.5로 바꾸니까 $0.10으로 떨어졌습니다. 품질은 거의 차이가 없었습니다.
이 과정에서 프로젝트 분석 및 평가를 BullMQ 기반 비동기 Job Queue 시스템으로 구현을 하고, 분석이 완료 알림을 보내도록 구현을 했는데,
이게 누군가가 merge 할때마다 알림이 안오는 이슈가 생겼습니다. 여기서 두번째 문제가 발생했습니다.(이어서...)
댓글을 작성하려면 로그인이 필요합니다.