바이브 코딩(vibe coding) 2개월 차에 배운 점

일단 나 소프트웨어 개발 경력 10년 차임. 근데 바이브 코딩(vibe coding) 시작한 지는 이제 2달 됐다. 1인 개발자로 일하면서 배운 것들 좀 풀어볼게. 팀 단위로 일하는 사람들은 상황이 좀 다를 수 있으니 참고해.

Stage 1: 나만의 문제 찾기

아무 이유 없이 앱 만드는 놈들 진짜 많더라. 있지도 않은 문제를 해결하려고 용쓰는 거지. 아이디어 찾으려고 애쓰지 마. 그냥 너나 네 주변 사람이 겪고 있는 진짜 문제를 해결해. 아무리 사소한 거라도 상관없어. 네가 불편하면 남들도 똑같이 불편할 확률이 높거든.

이 관점 하나만 바꿔도 나중에 결과가 완전히 달라질 거다.

Stage 2: 조사하기

문제를 정했으면 AI한테 세부 내용 좀 파보라고 시켜. 99% 확률로 네가 해결하려는 문제는 이미 시중에 솔루션이 널려 있을 거야. 근데 그중에서 '개인적으로' 마음에 안 드는 부분을 찾아내. 그게 바로 네 제품의 차별점이 될 거다. 이게 없으면 네 제품은 시장에서 아무도 안 사. 가장 좋은 차별점은 기존 솔루션들과 확실하게 대립각을 세우는 거야.

이런 준비도 안 된 상태에서 무작정 코딩부터 시작하는 게 제일 멍청한 짓임.

Stage 3: 아이디어/기능 구체화

이제 네 문제를 해결하기 위해 어떤 앱을 만들지 아이디어를 굴려봐. 기능들을 싹 다 적어. 얼마나 거창하거나 미친 소리 같든 상관없어. AI랑 같이 머리 맞대고 고민해 봐.

이 단계에서 미션 스테이트먼트랑 브랜딩도 정해. 네가 추구하는 가치가 뭔지, 앱이 뭘 하는 건지, 왜 다른 앱보다 나은지 확실히 해두라고.

그리고 이걸 바탕으로 프로젝트 기획서를 만들어.

진짜 네 문제라면 이건 자연스럽게 나올 거다.

Stage 4: 프로토타이핑

아이디어랑 기능이 나왔으면 이제 AI한테 프로토타입 만들어달라고 해. 프로토타입 목적은 앱이 어떻게 생겼는지, 어떻게 돌아가는지 눈으로 확인하고 만져보는 거야. 다른 기능들은 어떤 게 좋을지 고민도 해보고.

프로토타이핑할 때 너무 세세하게 파고들지 마. 그냥 AI한테 다 맡겨. 기능은 대충 뭉뚱그려서 설명하고, 브랜딩이랑 미션 스테이트먼트만 확실하게 전달해.

버튼 사이즈나 백엔드 구조 같은 세부적인 거에 목매지 마. 그런 건 안 중요해. 큰 그림만 그려. 안 그러면 시간 낭비만 하게 된다.

Stage 5: 계획 세우기

여기서 사람들이 두 번째로 많이 하는 실수가 프로토타입을 최종 결과물인 줄 아는 거야. 그러지 마라. 프로토타입은 길어야 며칠이면 뚝딱 만드는 거다.

이제 프로토타입을 보고 AI한테 시킬 기능 단위로 쪼개.

JIRA 같은 거창한 툴 필요 없어. 그냥 docs 폴더 만들어서 그 안에 기능 명세 파일 넣어두면 돼.

Stage 6: 릴리즈

초보들이 또 하는 실수가 한 번에 다 만들려고 하는 거임. 그러지 말고 덩어리를 나눠. 가장 핵심적인 기능 하나만 골라. 처음부터 끝까지 제대로 돌아가는 기능 하나. 이게 제일 중요해!

Stage 7: 기술 스택 조사

프로토타이핑할 때 AI가 알아서 스택을 썼겠지만, 그건 네가 직접 조사해야 해. 언어는 뭘 쓸지, 데이터베이스는 뭔지, 라이브러리는 뭘 쓸지 등등. AI한테 물어봐서 조사해. 최고의 스택이 뭔지, 대안은 있는지, 비교는 어떤지 물어보고 최종 결정은 네가 내려. 제품 만들 때 스택 결정이 제일 중요한데, 이걸 AI한테 다 맡기면 안 된다.

Stage 8: 스택 설정

스택을 정했으면 각 항목마다 AI한테 감사(Audit) 파일을 만들라고 해. React를 쓰면 React 베스트 프랙티스, CSS 베스트 프랙티스, Kotlin이면 Kotlin 관련해서 물어봐. 성능, 보안, 코드 구성, 유지보수성, 폴더 구조 같은 거 다 포함해서. 이 감사 파일이 곧 네 CI가 되는 거야. 이거 안 만들고 코드부터 짜지 마라.

Stage 9: 구현

이제 기능 명세서가 있을 거 아냐. AI한테 이 기능을 더 잘게 쪼개라고 해. 업계에서는 보통 티켓이라고 부르는 것들 있지?

꼭 티켓 형태일 필요는 없어. 문서에 한 줄 적어놓는 것만으로도 충분해.