[AI 활용] 나만의 카페 출고 관리 서비스 만들기
바이브코딩을 통한 나만의 SaaS 만들기
개요
회사에서 업무가 몰리면서 업무 내·외로 다양한 SaaS 프로덕트를 만들어 문제를 해결하고 있다. 이번 글은 AI Agent 기반 바이브코딩을 통해 회사가 아닌, 실제 일상의 문제를 해결한 사례를 공유한다.
이 글이 유용할 독자
- 아이디어는 있지만 개발 리소스 부족으로 실행이 어려운 사람
- "나도 AI와 함께 무언가 만들 수 있을까?" 궁금한 사람
- AI Agent 활용 실전 사례가 필요한 사람
결과물 미리 보기
이 글에서 다루는 결과물은 '카페 음료 출고 관리 서비스'다. 화면에 보이는 버튼을 눌러 판매 수량을 기록하면 자동으로 시간대별 합산과 집계된다. 기존의 종이 기록을 대체하면서 현장에서 실수를 줄이고, 실시간 데이터를 확인하는 걸 목표로 만들었다.
서비스 화면 모음 ⓒ작가편집제작일자
2025년 9월
핵심 기능
- 버튼 클릭으로 판매 수량 기록
- 시간대별 자동 합산 및 집계
- 종이 기록 대체로 휴먼에러 최소화
- 실시간 데이터 확인 가능
서비스 체험 링크
- URL: https://cafe-inventory-management.vercel.app/
- 테스트 계정: tester@tester.com / test0528!
발단: 일상에서 발견한 문제
애인은 스타트업에서 운영하는 프라이빗 뱅크 센터의 사내 카페 매장에서 매니저로 근무 중이다. 서로 얘기를 나누다 보면 항상 등장하는 고민이 있다. 바로 '재고 관리'와 '판매 관리'.
매장 특성상 결제를 따로 받기보단, 주문을 받고 판매된 양을 체크하여 후에 차감하는 형태의 사업 모델인데, 이 때문에 매장 마감 시 항상 재고와 판매한 음료를 체크하는 업무가 존재한다.
재고 체크 방법은 단순한데, 미리 양식을 프린트해서 카운터에 두고 메뉴별로 판매 여부를 체크한다. 그리고 마감할 때 직접 손으로 합산한다. 당연히 따라오는 건 '휴먼에러', 기록이 누락되거나 계산 실수가 발생하는 경우가 빈번했다.
상황 요약
매장 운영 방식
- 고객으로부터 직접 결제를 받지 않음
- 주문을 받고 판매 수량을 체크한 뒤 후불로 차감하는 방식
- 매장 마감 시 재고와 판매 음료를 수동으로 체크
기존 방식
1. 미리 양식을 프린트해서 카운터에 배치
2. 메뉴별 판매 건수를 손으로 체크
3. 마감 시 직접 손으로 합산
문제점
- 기록 누락 빈번
- 계산 실수 잦음
- 휴먼에러로 인한 재고-판매 불일치
문제 정의서 제작
사용자 인터뷰를 통해 문제 정의서를 먼저 작성했다. 문제가 명확해야 솔루션도 명확해지기 때문.
심플한 문제 정의서 ⓒ작가편집바이브코딩 시작
문제를 정의한 뒤, 이제 어떻게 풀어낼 것인지가 남았다. 나는 개발자가 아니지만 PM 경력이 있는 만큼, 개발자의 사고 방식과 서비스 동작 방식을 이해하고 있다. 이 경험이 AI Agent와의 협업에서 큰 강점이 됐다.
프론트엔드 작업
사용 도구
- 와이어프레임: Figma
- 프로토타이핑: Claude Opus 4.1 (HTML + Tailwind CSS)
- 프론트엔드 코딩: Cursor AI + Gemini 2.5 Pro
- 프론트 배포 관리: Vercel + Github
작업 프로세스
1. Figma로 와이어프레임 작성
- 사용자 시나리오 기반 화면 설계
- 핵심 기능 중심의 UI 구성
2. Claude로 프로토타입 제작
- HTML 기반 간단한 프로토타입 생성
- 1차 UX 검증 완료
- Cursor보다 빠른 프로토타이핑이 가능했음
3. Cursor로 실제 개발
- 검증된 프로토타입을 바탕으로 바이브코딩 진행
- Gemini 2.5 Pro와 협업하며 코드 작성
- Github로 소스 코드 관리
- Vercel을 통한 자동 배포
서비스의 UX/UI는 Figma를 활용해서 와이어프레임을 만들었다.
이후 Claude Opus 4.1을 활용해서 HTML로 구성된 프로토타입을 만들어 1차로 UX를 검증했다. HTML로 가볍게 프로토타입(껍데기)를 만들어 검증할 수 있는 만큼, 속도적인 측면에선 Cursor보다 나은 판단이었다.
1차적인 사용성 검증을 끝낸 후, Cursor로 넘어가서 바이브코딩을 진행하며 테스트했고, 바이브코딩 소스 코드는 Github의 Repo에 푸시 후, Vercel을 통해 프론트 배포 관리를 진행했다.
백엔드 작업
사용 도구
- DB 및 기본적인 백엔드 로직 설계: Gemini 2.5 Pro
- DB 및 Auth 관리: Supabase
작업 프로세스
1. DB 설계
- 요구 스펙상 데이터 구조가 복잡하지 않아 RDB 선택
- Gemini 2.5 Pro를 활용해 유저 시나리오와 정책 기반으로 테이블 설계
- 1매장 1계정 정책으로 계정별 집계 관리
서비스 데이터 구조 ⓒ작가편집RDB 관리하는 게 편하고, 위 정도 스펙이면 데이터 구조가 그리 복잡하지도 않다. 그래서 Gemini 2.5 Pro를 활용해서 내가 생각한 유저 시나리오와 정책을 바탕으로 DB 테이블을 설계했다.
2. SQL Function & Trigger 작성
- Supabase SQL Editor에서 직접 작성
- 집계 로직을 Function과 Trigger로 자동화
- Gemini 2.5 Pro가 SQL 코드 작성 지원
- 비개발자가 체감하는 DB 로직 구현 난이도가 아주 쉽다
Supabase SQL Editor ⓒ작가편집계정 정책은 1매장 1계정을 기본으로 했다. 매장별로 계정을 사용하는 것과 테스트하는 것을 감안했고, 계정별로 집계를 한다고 이해하면 편하다.
집계와 같은 로직이 필요했는데, 이는 Supabase의 SQL Editor를 활용해 Function, Trigger도 직접 만들었다. SQL을 짜는 과정은 Gemini 2.5 Pro를 활용해서 진행했다. 재밌었던 과정.
바이브코딩에서 배운 경험
돌이켜보면 가장 중요한 건 코드 자체가 아니었다. 애초에 무엇을 해결하고 싶은지, 가장 작은 단위는 무엇인지를 명확히 한 것이 핵심이었다.
메모장에 '문제 정의 → 솔루션 아이디어 → 실행' 플로우를 먼저 작성하고, 계획·처리 프로세스를 정리해서 AI Agent와 소통했다. 문제를 명확히 정의했기에 AI와 대화가 길을 잃지 않았다.
틈틈이 나오는 아이디어는 잘 메모하고, 다음 개선에 써먹을 수 있도록 백로그화했다.
- “이건 재고 관리까지 확장 가능하다”
- “여기서는 시간대별 리포트가 필요하다”
바이브코딩의 본질을 아래와 같이 정의할 수 있을 것 같다:
- 단순히 '코드를 대신 써주는 것'이 아님
- 문제를 풀고자 하는 의지를 빠르게 현실화하는 도구
- 개발 역량이 부족해도 문제 정의가 무엇보다 중요함
레슨 런
이번 프로젝트를 통해 얻은 인사이트는 아래와 같다:
1. 문제 정의 능력이 핵심 역량이다.
- 이제는 '어떻게 코딩할 것인가'보다 '무엇을 해결할 것인가'가 더 중요하다.
- 문제를 정의하고, 그 문제를 풀기 위한 접근법을 설계하는 능력이 진짜 경쟁력이다.
2. 문제 정의는 거창할 필요가 없다.
- 작은 불편함을 구조화하는 것이면 충분하다.
- 일상, 현장에서 체감한 '실제 문제'가 가장 좋은 출발점이다.
3. AI Agent는 빠른 실행을 도와주는 도구다.
- 단순히 개발 도구가 아니라, 머릿속 아이디어를 빠르게 현실화할 수 있게 도와주는 도구다.
- 특히, '구조화와 문제정의'라는 경험과 결합하면 더 강력한 시너지를 내는 듯.
4. 기술보다 중요한 것
- 기술 자체가 아니라 문제 해결을 향한 시선이 중요하다.
- 개발 역량이 부족해도 충분히 실행 가능하다.
- 중요한 건 '만들고자 하는 의지'다.
이 글이 AI Agent와 함께 무언가를 만들고 싶은 당신에게 작은 자극이 되길 바란다.
ⓒ 2025. 327roy All rights reserved.
