현업 개발자의 바이브코딩 초기 세팅법

한 줄 핵심

바이브 코딩은 아무 말이나 던지는 방식이 아니라, 목표·데이터 모델·우선순위·검증 질문을 먼저 좁혀 놓고 에이전트에게 구현을 맡겨야 실제로 빠르고 덜 흔들리게 서비스까지 갈 수 있다는 점을 보여준다.

시간별 요약

1:52
바이브 코딩을 다시 보는 이유 요즘의 바이브 코딩은 예전처럼 대충 시키는 방식이 아니라, 초기 기획과 에이전트 활용을 어떻게 설계하느냐가 성패를 가르는 흐름으로 바뀌었다. 그래서 이번 작업은 그 차이를 실제 서비스 기획으로 보여 주는 데 초점이 맞춰져 있다.
4:00
개인 운동 관리 시스템의 목표 정의 PT 6개월차에 변화가 체감되지 않아, 목표를 수치로 추적할 수 있는 개인 운동 관리 시스템이 필요해졌다. 중량, 루틴, 영양, 눈바디, 인바디 기록을 한곳에 모아 트레이너와 수강생이 같은 상태를 보게 만드는 것이 핵심이다.
10:00
앱·서버·MCP로 역할을 나누는 구조 트레이너는 앱으로, 수강생의 기록은 Claude Code와 MCP를 통해 자동화하는 구조로 정리된다. 앱은 기록과 조회를 담당하고, 서버는 데이터와 권한을 책임지며, 앱이 DB나 스토리지에 직접 붙지 않도록 분리하는 것이 기본 원칙이다.
20:01
TypeScript와 NestJS를 고른 이유 바이브 코딩에서는 앱과 서버를 같은 언어로 묶을 수 있는 TypeScript가 유리하고, 크로스 플랫폼 앱으로는 X4가 적합하다고 본다. 서버는 구조가 강제되고 프로덕션 전환에 유리한 NestJS를 택해, 초기 보일러플레이트보다 장기 유지보수성을 우선한다.
30:02
클라이언트와 서버, 보안의 경계 클라이언트는 서버와만 통신하고 데이터베이스나 스토리지에 직접 붙지 않아야 보안과 유지보수 모두 안정적이다. Supabase처럼 클라이언트 직결이 가능한 구조도 있지만, 정석적인 서버 경유 구조가 더 안전하고 확장에 유리하다.
32:02
에이전트에게 기획을 먼저 시키는 법 코딩 전에 초기 요구사항을 에이전트에게 던져 모호한 부분을 먼저 찾게 하고, 비개발자 관점에서도 질문과 반박을 반복하며 기획을 다듬는다. 이 단계는 AI에게 맡기기보다 사람이 주도해야 하며, 여기서 시간을 아끼면 뒤에서 더 큰 수정 비용이 생긴다.
46:00
데이터 모델과 개발 순서 정하기 기능의 중요도보다 데이터베이스 의존관계를 기준으로 개발 순서를 잡아야 스키마 변경을 최소화할 수 있다. 유저 스토리와 데이터 플로우를 먼저 정리하고, 목표·횟수·기준선 같은 정책을 명확히 해야 에이전트가 엉뚱한 방향으로 가지 않는다.
1:08:02
구현 단계는 서브에이전트와 검증 루프로 구현은 한 번에 맡기기보다, 단계별로 진행하고 매 단계마다 검증하는 루프로 설계해야 한다. 서브에이전트에게 반복 작업을 맡기되, 비즈니스 오너가 방향성과 제품 철학을 잡아 두어야 과도한 설계나 불필요한 복잡화를 막을 수 있다.
1:15:15
인프라 세팅은 에이전트에게 시키고, 사람은 막판 점검 배포, 스토리지, Supabase 설정, Xcode 라이선스 같은 귀찮은 인프라 작업은 에이전트와 브라우저 유즈로 처리하는 편이 효율적이다. 다만 에이전트가 오래 도는 일은 종종 숨은 막힘 때문이므로, 막혔을 때는 바로 확인하고 스톱 포인트를 제거해야 한다.
1:52:34
바이브 코딩은 많이 만드는 것보다 잘 묻는 것 AI로 돈을 벌거나 서비스까지 내는 난이도는 높고, 단순 반복 제작만으로는 실력이 쌓이지 않는다. 좋은 결과를 내려면 책과 실무 지식으로 안목을 키우고, AI에는 반복 실행을 맡기되 목표·제약·판단 기준은 사람이 책임져야 한다.

실무 인사이트

바이브 코딩을 시작할 때는 기능 목록보다 먼저 목표, 측정 기준, 데이터 소유자, 수정 정책을 문장으로 고정해야 한다.
앱·서버·DB를 분리하고 TypeScript 계열로 통일하면, 초기 세팅은 약간 번거로워도 이후 에이전트 운영과 유지보수가 훨씬 쉬워진다.
에이전트에게는 코드를 바로 쓰게 하기보다, 모호한 점을 질문하게 하고 데이터 모델을 검증하게 하는 편이 실패 비용을 크게 줄인다.