bolt.new로 웹앱 빠르게 만든 개발기: 아이디어에서 배포 직전까지 막힌 지점들

2026년 07월 04일

0 Views

bolt.new로 웹앱 빠르게 만든 개발기: 아이디어에서 배포 직전까지 막힌 지점들

bolt.new는 “일단 돌아가는 웹앱”을 가장 빨리 확인하고 싶을 때 꽤 강합니다. 이번에는 간단한 고객 문의 분류 대시보드를 만든다는 가정으로 화면 생성, 기능 추가, Supabase 연결, 배포 준비까지 진행해보니 결론은 명확했습니다. 초기 프로토타입은 빠르지만, 인증·DB·권한·배포 안정화는 별도 점검이 필요합니다.

이 글에는 제휴(어필리에이트) 링크가 포함될 수 있으며, 링크를 통해 가입·구매 시 소정의 수수료를 받을 수 있습니다. 추천은 실제 사용 경험에 기반합니다.

오늘 만들 화면 1개를 정하고, bolt.new에서 UI부터 생성해본 뒤 Supabase 연결 여부를 판단해보세요.

특히 React나 Next.js 구조를 어느 정도 아는 사람에게 더 잘 맞습니다. 완전 노코드라기보다, AI가 만든 코드를 바로 실행해보며 고치는 브라우저 기반 개발환경에 가깝습니다.

먼저 30분만 테스트해보세요.
만들 기능 3개를 적고, bolt.new에 한 번에 넣지 말고 화면 → 데이터 → 배포 순서로 요청하면 실패 확률이 줄어듭니다.

이번 셋업: bolt.new, Supabase, GitHub를 붙여본 흐름

처음 프롬프트는 짧게 시작했습니다. “고객 문의 CSV를 업로드하면 카테고리별로 필터링하고, 처리 상태를 바꿀 수 있는 관리자 대시보드” 정도로 요구했습니다. bolt.new는 StackBlitz 기반으로 실행 환경을 바로 띄워주기 때문에, 로컬 설치 없이 화면을 확인할 수 있었습니다.

첫 결과물은 예상보다 빨랐습니다. 사이드바, 테이블, 검색창, 상태 배지, 더미 데이터까지 한 번에 만들어졌습니다. 다만 여기서 욕심내서 “로그인, Supabase 저장, CSV 파싱, 권한 관리, 배포까지 해줘”라고 한 번에 요청하면 오류가 늘어납니다.

실제로 잘 먹힌 요청 방식

가장 안정적이었던 방식은 기능을 쪼개는 것이었습니다. 첫 요청은 UI만, 두 번째는 상태 관리, 세 번째는 Supabase 테이블 스키마, 네 번째는 CSV 업로드처럼 나눴습니다. 오류가 나면 “전체를 다시 만들어줘”보다 “이 컴포넌트에서 발생한 TypeScript 오류만 수정해줘”가 더 낫습니다.

예를 들어 CSV 업로드에서 한글 컬럼명이 깨지는 문제가 생겼을 때는 Papa Parse 사용 여부, 인코딩, 컬럼 매핑을 따로 지정하니 수정 방향이 빨라졌습니다. 이 부분은 ChatGPT나 Claude에 에러 로그만 던져서 원인을 교차 확인해도 좋습니다.

막힌 지점: 데이터와 인증은 생각보다 빨리 복잡해진다

UI 프로토타입은 빠르지만, 실제 서비스처럼 쓰려면 Supabase Row Level Security, 로그인 세션, 환경변수 관리가 중요해집니다. bolt.new 안에서 환경변수를 넣고 테스트할 수는 있지만, 운영 배포 전에는 GitHub에 올린 뒤 Vercel 또는 Netlify에서 다시 점검하는 편이 안전합니다.

또 하나의 함정은 AI가 패키지를 추가하면서 버전 충돌을 만들 수 있다는 점입니다. 설치 로그를 읽지 않고 계속 “고쳐줘”만 반복하면 의존성이 더 꼬일 수 있습니다. 이때는 package.json을 확인하고, 불필요한 라이브러리를 줄이는 것이 빠릅니다.

비교해보면: 어떤 도구를 언제 쓰면 좋을까

도구	강점	주의할 점	추천 상황
bolt.new	브라우저에서 생성·실행·수정이 빠름	복잡한 백엔드는 검증 필요	MVP 화면과 간단한 CRUD
Cursor	기존 코드베이스 수정에 강함	로컬 개발환경 이해가 필요	운영 프로젝트 리팩터링
Claude Code	터미널 기반 작업 흐름에 적합	명령 실행 범위 관리 필요	테스트·수정 반복 자동화
Lovable	앱 기획부터 화면 생성까지 부드러움	세밀한 코드 제어는 확인 필요	비개발자 MVP 초안

구체 예시: 문의 관리 대시보드라면 이렇게 나눴습니다

가상의 SaaS 운영팀이 매일 들어오는 문의를 분류한다고 해보겠습니다. 첫날 목표를 “로그인까지 완성”으로 잡지 않고, CSV 업로드 → 문의 목록 표시 → 상태 변경 → 카테고리 필터까지만 잡으면 bolt.new에서 1차 데모를 빠르게 만들 수 있습니다.

그다음 Supabase에 inquiries 테이블을 만들고, id, customer_email, category, status, created_at 컬럼을 붙입니다. 저장까지 확인되면 GitHub로 내보내 Cursor에서 코드 정리, 타입 보강, 에러 처리 문구를 다듬는 흐름이 좋았습니다.

자주 하는 실수 하나: 프롬프트에 제품 전체를 넣는 것

가장 흔한 실패는 처음부터 “Notion 같은 협업툴을 만들어줘”처럼 범위가 큰 요청을 하는 것입니다. 그러면 화면은 그럴듯하지만 내부 상태와 데이터 구조가 금방 꼬입니다.

대신 이렇게 시작해보세요. “모바일에서도 읽기 쉬운 문의 목록 화면을 만들고, 더미 데이터 10개를 넣어줘. 상태는 pending, in_progress, done 세 가지로 보여줘.” 이 정도면 결과를 보고 다음 요청을 붙이기 쉽습니다.

FAQ

bolt.new만으로 실제 배포까지 가능한가요?

간단한 앱은 가능합니다. 하지만 운영용이라면 GitHub에 저장한 뒤 Vercel, Netlify 같은 배포 환경에서 환경변수, 빌드 로그, 보안 설정을 다시 확인하는 것을 권합니다.

코딩을 거의 몰라도 쓸 수 있나요?

화면 초안은 만들 수 있습니다. 다만 에러 메시지, 패키지 설치, 데이터베이스 연결에서 막힐 수 있어 기본적인 HTML, React, API 개념을 알면 훨씬 수월합니다.

Cursor와 같이 써야 하나요?

필수는 아니지만 추천합니다. bolt.new로 빠르게 뼈대를 만들고, Cursor에서 파일 단위 리팩터링과 테스트 보강을 하면 코드 품질을 올리기 좋습니다.

무료로 충분히 테스트할 수 있나요?

요금과 사용량 제한은 자주 바뀝니다. 짧은 프로토타입은 무료 또는 낮은 사용량에서 가능할 수 있지만, 장시간 생성·수정 작업 전에는 공식 가격 페이지를 확인하세요.

오늘 바로 할 다음 행동

새 서비스를 만들 생각이라면 기능 목록을 10개 쓰지 말고, 사용자가 처음 보는 화면 1개만 정하세요. 예를 들면 “CSV를 올리면 표로 정리되는 화면”처럼 눈으로 확인 가능한 단위가 좋습니다.

그 화면을 bolt.new에서 만든 뒤, 저장이 필요하면 Supabase, 코드 정리가 필요하면 Cursor, 반복 수정이 많으면 Claude Code로 넘기면 됩니다. 빠르게 시작하되, 운영에 가까워질수록 공식 문서와 배포 로그를 확인하는 습관이 결과물을 살립니다.

bolt.new로 웹앱 빠르게 만든 개발기: 아이디어에서 배포 직전까지 막힌 지점들