디자이너도 앱을 만들 수 있을까?
디자이너의 바이브 코딩 도전기 – 산다가계부 제작기
코딩을 전혀 모르는 디자이너가 정말 앱을 출시할 수 있을까?
이 질문에 답하기 위해 한 달 반 동안 Cursor AI와 함께 앱을 개발해봤다. 결과는? 내가 매일 쓸 만한 수준의 가계부 앱을 만들 수 있었고, 지금은 앱스토어에서 누구나 다운로드할 수 있다.
플랫폼: iOS (React Native+ expo)
개발 기간: 6주 (실험 1주 + 본격 개발 5주)
일일 개발 시간: 평일 1-3시간, 주말 4-7시간
대략 이런 타임라인으로 진행되었다.
디자이너가 피그마 플러그인을 만들었다고?
나는 HTML, CSS, JavaScript의 아주 기초적인 개념만 알고 있었다. 그러다 친구가 공유해준 당근 아티클에서, 디자이너가 Cursor AI를 활용해 피그마 플러그인을 직접 만들었다는 글을 보았다.
'디자이너도 직접 서비스를 만들 수 있다니!'
AI가 많이 발전했다는 건 알고 있었지만, 디자이너의 바이브 코딩 가능성을 몸소 느끼던 순간이었다.
'그럼 앱도 내가 만들 수 있지 않을까?'
기대감 반, 호기심 반으로 Cursor를 다운받았다.
지출에만 집중하는 가계부가 필요한데...
앱을 만들어야겠다고 생각하니 가장 먼저 떠오른 건 가계부였다. 실제로 매일 불편함을 느끼고 있었기 때문이다.
나는 약 17,000원짜리 유료 가계부 앱을 영구 결제해서 사용 중이었다. 5~6개 앱을 써보다가 선택한 이유는 단순했다. 지출 관리를 내가 원하는 방식으로 자유롭게 할 수 있었기 때문이다. 특히 카테고리를 세분화해서 관리할 수 있다는 점이 만족스러웠다.
하지만 매일 사용하다 보니 점점 불편한 점들이 쌓여갔다.
1. 나에게 불필요한 기능이 너무 많았다.
대부분의 가계부는 수입과 지출 관리를 모두 제공하는데, 고정 월급을 받는 나는 수입은 거의 변동이 없었다. 고정된 예산 속에서 지출을 관리해도 충분했기 때문에 수입 탭은 항상 비어 있었다.
2. UI가 너무 복잡했다.
기능이 여기저기 숨겨져 있었고 설명도 생략되어 있었다. 특히 ‘예산 관리’ 기능은 여러 단계를 거쳐야만 접근할 수 있었다. 결국 점점 손이 가지 않았다.
매일 기록해야 하는 가계부이기에, 더 단순하고 지출에만 집중할 수 있는 앱이 필요했다.
1주차 : Cursor 다뤄보기
ChatGPT에게 도움 요청
어떻게 시작해야하는지 조차 몰랐기 때문에 일단 ChatGPT에게 도움을 요청했다.
"나는 비개발자야. Cursor를 가지고 iOS에서 사용할 수 있는 가계부 앱을 만들고 싶은데, 뭘 준비해야 해?"
ChatGPT는 친절하게 내 개발 수준과 특성에 맞는 추천 옵션들을 제공해줬다. 러닝커브가 낮고 추후 안드로이드로 확장할 수 있는 RN이 매력적이었다. 이 내용을 Cursor에게 전달하면서 처음으로 개발을 시작했다. 첫 명령어는 이랬다.
"나는 비개발자야. React Native와 Expo 조합으로 iOS 가계부 앱을 만들고 싶어. 프로젝트를 생성해줘."
작은 것부터 하나씩
처음에는 기본 환경 설정에서도 오류가 났는데 하나씩 해결하다보니 하루 뒤부터 개발된 내용을 내 핸드폰에서 확인할 수 있었다.
여기서 팁은 처음부터 기능을 구현하려고 하지 말고, 정말 작은 것부터 시작해보는거다. 넓은 범위의 작업을 한 번에 하려고 할수록 오류가 날 확률이 커지고 오류의 원인도 찾기 힘들어진다.
1."Hello World" 텍스트 한 줄 띄우기
2.버튼 하나 추가해보기
3.버튼 누르면 텍스트 바뀌게 하기
Cursor로 기능 만들어보기
처음 1주는 내가 가계부를 정말 만들 수 있을지 확인하는 실험 기간이었다. 다른 가계부 앱들을 참고해서 기본 기능을 따라 만들며 Cursor와 소통하는 법을 익혔다. 직접 사용해보니 내 생각보다 훨씬 ‘알아서 잘’ 구현해주었는데, 이것이 바이브 코딩의 가장 큰 장점이자 단점이었다.
예를들어 "카테고리를 설정할 수 있는 화면을 만들어줘"라고만 입력해도 가계부에서 사용될것같은 카테고리를 알아서 추가해주거나, 삭제, 수정에 대한 정책까지 알아서 고려해줬다.
그런데 동시에, 카테고리 페이지만 수정하고 싶었지만 이미 내가 원하는 대로 구현되어 있던 지출 입력 페이지도 같이 바꿔버리기도 했다. AI에게는 생각보다 훨씬 더 구체적으로 명령을 내려야 했다.
[⨉] 비효율적인 질문
"지출 입력 버튼 컬러 검정색으로 바꿔줘"
[◯] 효율적인 질문
"홈화면에 있는 지출입력버튼 배경 컬러 그레이 100으로바꿔줘. 다른 요소는 수정하지 마"
+ 시장 검증: 정말 필요한 앱일까?
동시에 중요한 검증을 했다. 정말 "지출 중심 가계부"가 의미 있을지 주변 지인들에게 물어봤다.
결과는 꽤 긍정적이었다.
"아, 나도 가계부에서 수입 기능은 안 써. 그냥 얼마 썼는지만 확인해."
“나도 부수입이 있을때는 관리했는데, 지금은 안쓰고 있어”
이런 반응들을 들으며 지출 중심 가계부라는 컨셉이 명확해졌다.
2~4주차: 실제 가계부 앱 개발하기
구조적으로 다시 접근하기
2주 차에 들어서면서 테스트용 프로젝트를 폐기하고 새 프로젝트로 다시 시작했다. 빠르게 테스트해보며 이것저것 붙이다 보니 코드가 꼬이고, 점점 디버깅에 많은 시간이 소요됐다. 그래서 이번엔 구조를 차근차근 쌓아가기로 했다.
그렇다고 완벽한 기획이나 디자인을 준비한 것은 아니었다. 앱의 전체 흐름은 간단하게 정의해두고, 핵심 기능 중심으로 PRD와 IA를 작성해 Cursor에게 공유했다. 미리 맥락을 설명해두면 앱의 방향성을 이해하고 더 똑똑하게 작업 경로, 구조, 이름 등을 제안해 준다. 참고로 IA, PRD 등의 문서는 next.cursor에서 손쉽게 작성할 수 있다.
.md 형식으로 만들어 두고 필요시에 add context 기능을 사용해서 참조할 수 있게 했다.디자인보다 코드가 먼저
이번 프로젝트에서 가장 유용했던 것은 디자인보다 코드를 먼저 쓰는 방식이었다. 혼자 진행하는 프로젝트였기 때문에, 기존의 기획 → 디자인 → 개발 순서를 따를 필요가 없었다.
홈화면을 예로 들어보자면 아래 과정으로 진행됐다.
1.figma에서 간단하게 기본 구조를 잡고 Cursor에게 전달한다.
2.Cursor가 만들어준 화면을 직접 사용해보며 사용자로서 편한 플로우가 나올때까지 핑퐁한다.
3. 편한 플로우룰 찾으면 Figma에서 디자인을 하고, 세부적인 사용성을 다듬는다.
이 방식을 선택한 이유는 2가지였다.
1. AI의 제안이 궁금했다. 실제로 AI가 내가 생각한 것보다 더 괜찮은 플로우를 제안해준 경우도 있었다.
2.더 빠른 사용성 검증이 가능했다. 피그마에서 프로토타입을 만드는 시간을 줄이고, 코드로 직접 UI를 구현하며 빠르게 테스트할 수 있었다.
이 방식으로 홈, 예산, 설정 탭을 각각 일주일씩 나눠 개발하며 3주 만에 MVP를 완성했다.
5~6주차: TestFlight로 사용성 테스트
결국 지출 입력 과정이 핵심
5주 차에는 지인 6명에게 TestFlight를 통해 앱을 공유하고, 일주일간 사용 후 인터뷰를 진행했다.
감사하게도 긍정적인 피드백이 많았다.
"개발자 없이 만든 앱이라고는 전혀 느껴지지 않아."
"수입 기능이 없는데 전혀 어색하지 않고, 지출에만 집중할 수 있어서 오히려 좋아."
무엇보다 흥미로웠던 건, 대부분의 피드백이 ‘지출 입력 과정을 얼마나 쉽게 만들 수 있는가’에 집중되어 있었다는 점이다. 수입 관리, PC 연동, 통계 같은 부가 기능보다도, 지출 입력을 얼마나 빠르고 단순하게 만들 수 있는지가 앱의 핵심 경쟁력이라는 걸 체감했다.
A/B 테스트까지
사용성이 고민되는 부분도 TestFlight를 통해 A/B 테스트를 해볼 수 있었다.
예를 들어 지출 입력 단계에서 ‘메모 입력’ 위치를 바꿔 실험해보았다.
A안: 지출 입력 플로우 중간에 바로 메모를 입력할 수 있는 방식
A안B안: 메모 입력을 생략하고 먼저 저장한 뒤, 필요한 경우 상세 페이지에서 메모를 추가하는 방식
B안인터뷰를 해보니 의외로 A안에 대한 선호가 압도적이었다. 작은 실험을 통해서 가계부 앱에서는 입력 단계가 짧은 것 자체보다도 금액이나 카테고리로는 충분히 설명되지 않는 맥락을 기록하는 것이 중요하다는 것을 알 수 있었다.
마주했던 한계들
하지만 모든 게 순탄했던 건 아니다. 비개발자로서 명확한 어려움도 존재했다.
1. 오류 해결의 어려움
오류가 생겼을 때 해결을 AI에게 의존해야 했다. 내가 코드를 잘 파악하고 있지 않다 보니 간단한 오류인데도 시간이 더 오래 걸리거나, 1개의 오류를 해결하고 나면 연관된 페이지에서 다른 오류가 발생하기도 했다.
Firebase를 사용한 회원가입 기능이나 AI API를 활용한 지출 입력 자동화 기능을 만들고 싶어서 3-4일 동안 씨름했지만, 결국 오류의 원인조차 알 수 없어서 롤백하기도 했다.
2. 코드 품질에 대한 불안감
현재 코드가 잘 짜인 코드인지, 유지보수가 가능할지 여부도 스스로 판단할 수 없는 게 아쉬웠다.
하지만 이런 한계들조차 "그러니까 안돼"라기보다는 “내가 더 배우면 되겠네" 라는 동기로 이어졌다.
앞으로의 계획
앞으로 6개월정도는 꾸준히 개선해볼 예정이다. 그리고 지출 중심 가계부라는 것이 돈을 낼 만한 가치가 있을지도 추가로 실험해볼 예정이다. 운영적인 부분은 시간이 지나고 후기를 다시 남겨보겠다.
그래서, 코딩 한 줄 모르는 디자이너가 정말 앱을 출시할 수 있을까? 결론은 "디자이너도 실제로 동작하는 앱을 만들 수 있다"는 것이다. 오류가 생겼을 때 포기하지 않을 인내심과 끈기만 있다면 누구나 만들 수 있다.
이제 머릿속에 떠오르는 아이디어들을 그냥 상상으로만 끝내지 않고, "일단 만들어볼까?"라고 생각하게 되었다.한 번 맛본 바이브 코딩의 재미는 쉽게 포기할 수 없을 것 같다.
산다가계부는 아래 링크에서 다운받아 보실 수 있습니다.
앱에 대한 제안 혹은 피드백은 언제나 환영입니다 :)
