비개발자를 위한 바이브 코딩 입문 5단계 가이드

(stdy.blog)

26P by spilist2 2025-04-23 | ★ favorite | 댓글 7개

지난 몇주간 비개발자 지인들(변호사, 마케터, PM 등)과 함께 바이브 코딩으로 간단한 앱을 대여섯 개 만들어봤음

WoW 길드 레이드 대시보드 (웹)
경품 추첨 이벤트용 레이싱 시뮬레이터 (웹 + Three.js)
영상 편집자와 의뢰자 사이 의사소통하는 도구 (크롬 익스텐션)
이터레이션 횟수를 정하고, 일정 시간동안 집중하고, 끝나면 회고하도록 돕는 자동 타이머 (Electron 데스크톱 앱)

이 과정을 정리하여 '비개발자를 위한 바이브 코딩 입문 가이드'를 5단계로 만들어봄

요즘 AI가 어디까지 뭘 할 수 있는지 감 잡기
풀고 싶은 문제, 만들고 싶은 제품 명확히 정의하기
빠르고 빈번하게 내 눈으로 결과물 동작 확인하기
AI가 잘 코딩할 수 있도록 프롬프팅하며 주고받기
이상 동작과 개선점을 인지하고 개선하며 마감하기

1) 요즘 AI가 어디까지 뭘 할 수 있는지 감 잡기

바이브 코딩을 처음 접하는 비개발자 분들은 이정도 활동으로 시작하시길 권함

LLM에서, 또는 AI 프로토타이핑 서비스에서 짧은 프롬프트만으로 동작하는 무언가를 만들 수 있다는 걸 직접 경험해보며 효능감 높이기
최신 AI 정보를 정리해서 알려주는 SNS와 뉴스레터 몇 개 구독하기
모든 AI 정보와 도구를 소화할 욕심은 버리고, 내가 관심있는 특정 주제의 도구들만 관심 가지며 찍먹해보기

2) 풀고 싶은 문제, 만들고 싶은 제품 명확히 정의하기

AI의 능력에 대한 인식은 했더라도 문제 정의가 명확하지 않으면 제품을 만들 수 없음
그래서 먼저 메타인지를 높이는 질문을 통해 내가 똑똑해져야 함.
바이브 코딩으로 만든 메타인지 앱 이용
1. 뭘 만들고 싶은가?
2. 그걸 왜 만들고 싶은가? 어떤 문제를 풀려고?
3. 누가 겪는 문제인가?
4. 그들이 어떤 상황에서 그 문제를 겪나?
5. 그 상황에서 지금은 어떤 임시방편/대체재를 쓰고 있나?
6. 5보다 1이 문제를 더 잘 풀어준다는 걸 어떻게 확인할 수 있을까?
7. 그들이 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 시대에도 충분히 경쟁력이 있을 거라고 생각

GeekNews Weekly에 포함된 글입니다. 에디터 코멘트 보기