비개발자를 위한 바이브 코딩 입문 5단계 가이드
(stdy.blog)지난 몇주간 비개발자 지인들(변호사, 마케터, PM 등)과 함께 바이브 코딩으로 간단한 앱을 대여섯 개 만들어봤음
- WoW 길드 레이드 대시보드 (웹)
- 경품 추첨 이벤트용 레이싱 시뮬레이터 (웹 + Three.js)
- 영상 편집자와 의뢰자 사이 의사소통하는 도구 (크롬 익스텐션)
- 이터레이션 횟수를 정하고, 일정 시간동안 집중하고, 끝나면 회고하도록 돕는 자동 타이머 (Electron 데스크톱 앱)
이 과정을 정리하여 '비개발자를 위한 바이브 코딩 입문 가이드'를 5단계로 만들어봄
- 요즘 AI가 어디까지 뭘 할 수 있는지 감 잡기
- 풀고 싶은 문제, 만들고 싶은 제품 명확히 정의하기
- 빠르고 빈번하게 내 눈으로 결과물 동작 확인하기
- AI가 잘 코딩할 수 있도록 프롬프팅하며 주고받기
- 이상 동작과 개선점을 인지하고 개선하며 마감하기
1) 요즘 AI가 어디까지 뭘 할 수 있는지 감 잡기
바이브 코딩을 처음 접하는 비개발자 분들은 이정도 활동으로 시작하시길 권함
- LLM에서, 또는 AI 프로토타이핑 서비스에서 짧은 프롬프트만으로 동작하는 무언가를 만들 수 있다는 걸 직접 경험해보며 효능감 높이기
- 최신 AI 정보를 정리해서 알려주는 SNS와 뉴스레터 몇 개 구독하기
- 모든 AI 정보와 도구를 소화할 욕심은 버리고, 내가 관심있는 특정 주제의 도구들만 관심 가지며 찍먹해보기
2) 풀고 싶은 문제, 만들고 싶은 제품 명확히 정의하기
- AI의 능력에 대한 인식은 했더라도 문제 정의가 명확하지 않으면 제품을 만들 수 없음
- 그래서 먼저 메타인지를 높이는 질문을 통해 내가 똑똑해져야 함.
- 바이브 코딩으로 만든 메타인지 앱 이용
- 뭘 만들고 싶은가?
- 그걸 왜 만들고 싶은가? 어떤 문제를 풀려고?
- 누가 겪는 문제인가?
- 그들이 어떤 상황에서 그 문제를 겪나?
- 그 상황에서 지금은 어떤 임시방편/대체재를 쓰고 있나?
- 5보다 1이 문제를 더 잘 풀어준다는 걸 어떻게 확인할 수 있을까?
- 그들이 5 대신 기꺼이 1을 쓰게 만드려면 어떻게 할까?
- 만들고 싶은 게 정리되면, 위 앱에서 생성된 'PRD 생성 프롬프트'를 LLM에 집어넣어 PRD를 만들게 했음
3) 빠르고 빈번하게 내 눈으로 결과물 동작 확인하기
- '동작하는 앱'을 굉장히 이른 시점에 바이브 코딩의 가장 큰 장점. 비개발자에 동기부여 되는 데에도 아주 중요
- 그런 의미에서 비개발자가 Cursor로 바이브 코딩 시작하는 걸 별로 권하지 않음. 앱 실행까지 넘어야 할 크고작은 산이 많다고 생각하기 때문
- 대신 PRD를 주면 동작하는 프로토타입이 튀어나오는 Lovable 같은 서비스들이 더 좋은 출발점이라고 봄. 퍼블릭 링크도 바로 만들어지니 지인에게 보여주고 피드백받기도 좋음
- 단 만들려는 앱이 웹 기반이 아니라면 조금 복잡해짐. 프로토타이핑 도구들은 웹앱으로 만들어주기 때문
- 이 때는 기술적 의사결정과 실행 환경 세팅이 필요한데, 그러려면 나와 AI가 모두 똑똑해져야 함
4) AI가 잘 코딩할 수 있도록 프롬프팅하며 주고받기
- 나와 AI가 똑똑해진다 <-> 프롬프트 잘 짠다 <-> 결과물이 더 빨리, 더 잘 나온다
- 프롬프트 잘 짤수록 목표 달성에 드는 핑퐁 횟수(= 시간과 돈)이 줄어듦
- 각종 프롬프트 엔지니어링 가이드를 보면 공통적으로 언급하는 게 프롬프트 안에 역할(Role), 맥락(Context), 작업(Task)을 잘 정의하라는 것
역할, 맥락, 작업
- 바이브 코딩에서 '역할'은 엄청 중요하지 않음
- 코딩 에이전트들에 이미 적절한 역할이 정의되어 있어서 꼬일 수 있고
- 코딩이 중요한 벤치마크라서인지 LLM에서도 역할 부여 없이 코딩 잘 하기 때문
- 물론 내가 만들려는 앱이 특별하다면 적절한 역할을 주는 것도 좋음
- '맥락'은 PRD 잘 만들었으면 충분
- '작업'은 목표와 완료기준을 잘 정하는 것. 완료기준은
- 프롬프트 내에 명시되어있을 수도 있고(few-shot 프롬프팅)
- 외부 파일이나 코드에 정의되어있을 수도 있고(
TODOs.md나 테스트 코드) - 내 머릿속에만 있을 수도 있음(이 스타일은 예쁘지 않아)
- 바이브 코딩의 궁극적 목표는 AI가 잘 코딩하도록 지시해서 PRD대로 동작하는 앱을 빠르게 만드는 것. 이를 위해선 3가지 중간목표를 삼는 게 좋음
- 내가 더 똑똑해진다
- AI가 더 똑똑해진다
- 기능이 스펙대로 동작한다
내가 더 똑똑해진다?
- 비개발자이거나, 도메인이 생소하거나, 기술 스택이 생소하다면 정확한 용어로 지시하기 어려움
- 이럴 때는 내가 부족함을 LLM에게 알리고 배우면 됨
- "(스샷 주고) 이런 게임은 보통 뭘로 만들어?"
- "이런 거 만들건데, 너라면 데이터를 어떻게 확보할 것 같아?"
- "네이티브 앱의 핵심 동작을 최대한 빨리 확인하려면 어떤 기술을 써야 해?"
- 이런 질문을 통해 내가 이렇게 변하고 있는지 관찰해볼 것
- 기술 키워드: 내가 정확한 기술 용어/도메인 용어를 사용하고 있다
- 데이터 흐름: 내 앱의 핵심 기능을 위한 데이터를 어떻게 확보해서, 처리해서, 보여주는지 설명할 수 있다
- 실행 환경: AI가 짜준 코드를 실행해서 동작 여부를 내 눈으로 확인할 수 있는 환경을 마련했다
- 이상적으로는 unknown unknown을 다 해소한 상태에서 PRD 쓴 뒤 코딩 착수하는 게 좋으나 꼭 안그래도 됨
- 코딩 들어가야 학습하는 것도 많고, 여차하면 처음부터 다시 만들면 되니까. (이미 있는 거 고치기보다 더 빠를 수도 있음)
AI가 더 똑똑해진다?
- 파악한 기술 키워드나 데이터 흐름을 시스템 프롬프트(Cursor Rules 등)로 AI에게 알려주는 것
- 나의 개입 횟수를 줄이고, AI의 코드가 내 마음에 더 들게 하려면 크게 두 가지가 필요함. 제약조건과 문서화에 대한 지침임
-
제약조건 지침은 AI가 더 일관된 코드를 쓰도록 도움. 예를 들어:
- 기술 스택: NextJS app router 써라, Tailwind와 ShadCN으로 스타일링해라, 아이콘은 Lucid만 써라, 결제는 Stripe 써라 등
- 구조와 패턴: 폴더는 이렇게 구성해라, 파일명은 이렇게 지어라, UI 스타일은 Material처럼 해라 등
- (실행 환경에 따른) 출력 형식: Electron Fiddle을 쓸 거니까 그에 맞춰 파일 4개를 줘, CodePen을 쓸 거니까 HTML, CSS, JS를 하나씩 줘 등
-
문서화 지침은 AI의 집중력과 기억력을 향상시키도록 도움. 두 가지 아이디어가 아주 유용했음
- Cline의 메모리 뱅크: 한 일과 할 일들을 파일에 기록하며 작업하는 워크플로우를 정의
- 강동윤님의 프롬프트 컨텍스트: 전체 프로젝트에 대한 지침을 최상위 폴더에 길게 남기는 대신 폴더별로 지침을 만듦
- 메모리 뱅크는 현재 무슨 일이 일어나는지 관찰과 학습이 쉬워지니, 비개발자에게 특히 추천
기능이 스펙대로 동작한다?
- 프로젝트 수준이 아닌 (코딩 에이전트에서) 채팅할 때의 프롬프팅 전략
- 기능이 스펙대로 동작하게 만드는 가장 좋은 전략은 테스트 통과하면 커밋이라고 생각
- "X를 구현해줘. 테스트 먼저 작성하고, 코딩한 다음, 테스트를 돌려보고, 통과할 때까지 계속 코드를 수정해줘."
- 이는 코딩 에이전트가 테스트 코드를 작성하고, 터미널에서 실행하고, 그 결과를 읽을 수 있는 권한과 능력이 있기 때문에 가능
- 그렇게 테스트를 통과하면 커밋 메시지를 제안받아서, 테스트 코드와 기능 코드를 함께 커밋하면 됨. 나는 커밋을 직접 하지만 에이전트가 자동 커밋도 가능
- 유닛 테스트뿐 아니라 통합 테스트, E2E 테스트도 AI가 짜고, 실행하고, 알아서 고치게 할 수 있음 (참고: Cursor + Playwright 자동화 테스트)
- 이 모든 게 '스펙대로 개별 기능이 구현되고, 전체 앱이 PRD대로 동작하는가' 를 바이브 코더와 AI 양측이 더 쉽게 확인하도록 만들어주는 전략임
5) 이상 동작과 개선점을 인지하고 개선하며 마감하기
- 내가 생각하는 바이브 코딩은 '딸깍'과 거리가 멀고 학습할 게 많음
- 그중에서도 '나만의 작은 프로토타입'을 넘어, 솔로 창업자로서 상용 제품 수준의 앱을 만드는 데 필수적이라고 보는 3가지 역량이 있음. 인지 역량, 코딩 역량, 프로덕 엔지니어링 역량임
인지 역량
- PRD(또는 내 원래 의도)와 다르게 동작하는 화면 또는 기능을 예민하게 인지하는 것
- 이게 부족하면 AI가 잘못한 걸 찾아서 고치라고 하기가 너무 어려움
- 4단계의 '테스트'는 AI의 잘못을 애초에 줄임과 동시에 내 역량을 키워주기도 함.
- 스펙을 AI가 테스트 코드로 변환하는 과정을 읽으면서 단순히 '이 기능이 필요해'가 아닌 '이 기능 구현을 완료하려면 이 조건들이 필요해'를 학습할 수 있기 때문
- 그런데 '앱을 스펙대로 구현했다'와 '앱이 좋다'는 다름. 그래서 개선점을 찾는 '프로덕 센스'가 중요 (자세한 내용은 링크한 Lenny의 뉴스레터 참조)
코딩 역량
- 적어도 아직까지는, 아무리 일을 잘 쪼개서 AI에게 맡겨도 최소 5% 정도는 직접 코드에 손대서 마감을 쳐야 함.
- 이걸 못해서 80% 수준에서 머물며 출시 못하는 앱들이 SNS상에 수두록함
- 물론 만들고자 하는 앱에 따라 이 비율이 달라질 수도 있고, 끝까지 AI만으로 구현하는 것도 불가능하진 않겠지만 너무 비효율적임
- 바이브에 완전히 몸을 맡기기보다는 (메모리 뱅크, 테스트 코드 등을 통해) AI가 생성해주는 문서들을 보며 코딩 자체도 공부하길 권함. 개발자에게 코칭도 받아보고.
- 특히 상대적으로 눈에 덜 보이는 백엔드(사용자 인증, 외부 API 연동, 데이터 입출력, 결제 등)와 배포 전략(메인 브랜치와 피처 브랜치, 환경변수 관리 등)에 대해서 학습하시는 게 효과가 클 것
프로덕 엔지니어링 역량
- 앱 출시는 끝이 아니라 시작임. 제대로 하려면 제품 개발 라이프싸이클 전체를 이해할 필요가 있음
- 문제 인식, 해결 아이디어 도출, 기획, 디자인, 구현, 테스트, 배포, 홍보, 에러 모니터링, 피드백 수집, 운영...
- 이 모든 단계를 깊이있게 다루는 것까지는 아니어도, 적어도 해당 단계에서 어떤 일을 하고 어떤 키워드를 쓰는지까지는 알아두는 게 좋음
- 그래야 모르는 걸 배울 수 있고, 혼자 감당이 안될 때 함께할 동료의 역량을 알아볼 수 있음
맺으며
- 바이브 코딩으로 앱을 상용 제품 수준으로 만드는 건 결코 쉬운 일이 아님. 그러나 '시작'하기가 그 어느 때보다 쉬워진 건 누구도 부정할 수 없을 것
- 자신의 작은 아이디어가 살아 움직이는 걸 본 지인들이 탄성과 함께("와 내가 코딩을 하다니!") 너무나 즐거워하는 걸 보니 나 또한 굉장히 행복했음
- 이 글을 읽는 다른 비개발자 분들도 이번 기회에 즐겁게 '메이커'가 되어보시는 걸 권함
- 본인만의 도메인 전문성을 이용해, 특정 문제를 탁월하게 해결하는 작고 빠르며 유용한 도구를 (바이브 코딩으로) 만든다면 AI 시대에도 충분히 경쟁력이 있을 거라고 생각