1. 비교를 하게 된 배경
안녕하세요. 10년째 프론트엔드 개발을 하고 있는 황자립이라고 합니다.
저는 평소 스레드에서 choi.openai님의 글을 유심히 살펴보며, 업무에 도움이 될 만한 AI 서비스들을 발견할 때마다 Notion에 "써봐야지" 목록으로 차곡차곡 기록하곤 합니다.
그러던 중 며칠 전, Replit의 Agent 3 발표 소식을 접하게 되었습니다. "또 하나의 흥미로운 AI 웹 빌더가 등장했군." Notion에 기록하려고 열어보니, 그동안 미뤄두었던 "써봐야지" 항목들이 가득 쌓여있는 것을 발견했습니다. 마치 우리집 냉장고 마냥.
"이제 정말 냉털을 해야겠다"는 생각이 들었고. 하나씩 써보는 건, 중간도 하기 전에 지칠거 같아서, 동일한 프롬프트로 동시에 서비스를 비교하기로 결정했습니다. 그리고 비교를 다하고 글을 작성하는 이 시점에서 이 동시에 비교하는 방법이 AI 웹 빌더들을 테스트하기 꽤 괜찮은 방법이라는 생각이 들었습니다.
그래서 이번 기회에 Notion에 쌓여있던 "Bolt.new", "Replit", "MagicPath" 이 3가지 AI 웹 빌더와 기존에 즐겨 사용했던 v0, 그리고 많은 사람의 러버, Lovable까지 해서 5종의 AI 웹 빌더를 한 번에 비교 테스트해보기로 결심했습니다.
그리고 여기서 가장 괜찮은 결과로 실제 서비스 개발까지 이어가보려고 합니다.
2.선수 입장
1. v0.dev
2. Bolt.new
3. Lovable
4. Replit
5. MagicPath
가장 유명하고 SNS에서 이슈가 됐었던 5가지의 서비스 입니다.
그리고 클로드 Opus4.1 기준 각 서비스를 비교해달라고 한 결과입니다.
| 특징 | Bolt.new | v0.dev | Lovable | Replit | magicPath |
|---|---|---|---|---|---|
| 강점 | 속도 | UI 품질 | 완성도 | 자율성 | SVG/패턴 |
| 약점 | UI 디테일 | 백엔드 없음 | 속도 | 복잡함 | 웹앱 한계 |
| 초보자 | ⭐⭐⭐⭐ | ⭐⭐⭐ | ⭐⭐⭐⭐⭐ | ⭐⭐ | ⭐⭐⭐⭐⭐ |
| 백엔드 | ✅ | ❌ | ✅ | ✅ | ❌ |
| DB 연동 | 기본 | ❌ | Supabase | 모든 DB | ❌ |
| 배포 | Netlify | 수동 | 자동 | 자체 호스팅 | 이미지 export |
| 협업 | ❌ | ❌ | ✅ | ✅ | ❌ |
각 서비스 한 줄 정리를 했을때 다음과 같습니다.
🚀 Bolt.new
가장 빠르게 만들 수 있지만, 디자인 디테일은 아쉬움
초보자 추천 ⭐⭐⭐⭐
🎨 v0.dev
UI는 제일 예쁘지만, 백엔드 기능 없음 (프론트엔드만)
디자인 중요하면 선택
💜 Lovable
가장 완성도 높음, DB까지 자동 연결 (실제 서비스 가능)
초보자 최강 추천 ⭐⭐⭐⭐⭐
🤖 Replit
개발자스러운 도구, 모든 걸 할 수 있지만 복잡함
초보자 비추 ⭐⭐
🎨 magicPath
배경/패턴 만드는 도구 (웹앱 개발 도구 아님)
디자인 에셋용으로만 사용
이렇게 클로드는 소개를 해줬습니다. 좀 더 상세한 정보는 아래 링크에서 확인할 수 있습니다.
실제로 사용했을 때 경험과 비교해보면 좋을거 같습니다.
3. 실험 소개
3.1 실험 프로젝트 선정
일반적인 랜딩 페이지나 간단한 웹사이트는 각 AI 웹 빌더들이 이미 충분히 좋은 결과를 보여줄 것으로 예상했습니다. 따라서 좀 더 차별화된 평가를 위해 일반 랜딩페이지 또는 소개용 홈페이지보다 약간은 복잡한 조건을 가진 프로젝트를 선택했습니다.
선정된 프로젝트는 "친구와 만날 때 중간지점 찾기 서비스" 입니다. 얼마 몇해 전 Notion에 작성해뒀던 아이디어로 바쁘단 이유로 노션 구석에 쳐박혀있던 아이디어 입니다. 친구 또는 지인들과 만날 때 항상 애매했던 "어디가 중간지점일까?"라는 문제 의식에서 시작되었습니다. 이를 한번 웹 애플리케이션 형태로 풀어보겠습니다. 아래는 PRD의 일부입니다.
이 프로젝트가 실험에 적합했다고 판단한 이유
-
외부 API 연동: 지도 API, 주소 검색 API 등 외부 서비스 연동이 필수적이며, API 키 관리와 CORS 처리 등이 가능한지 확인
-
백엔드 연동이 어디까지 가능한지: 일부 웹 빌더 백엔드 연동이 가능하다고 명시, 사용자 데이터 저장, 세션 관리 등을 통해 각 웹 빌더의 풀스택 개발 역량 검증
-
상태 관리: 여러 위치 입력, 검색 결과, 계산된 중간지점 등 복잡한 상태를 관리하는 로직 구현 필요
-
모바일 최적화: GPS 연동, 터치 인터페이스, 반응형 디자인 등 모바일 환경에서의 사용성 고려사항 다수
-
종합 검증: 단순 UI가 아닌 아이디어 수준에서 일정 수준의 완성된 웹 애플리케이션까지의 구현 가능성 평가
3.1.1 실험 진행 방식
PRD 기반 단계별 구현
- Claude와 함께 작성한 상세한 PRD(Product Requirements Document)를 각 AI 웹 빌더에 전달
- 기능별로 순차적 구현 요청 (MVP → 고도화)
- 각 단계별 필수 구현 요소들을 명확히 정의
제한된 개입 원칙
- 의도대로 구현되지 않거나 에러 발생 시에만 버그 수정 요청
- 직접적인 코드 수정은 최대한 지양
- AI 웹 빌더의 순수한 역량 평가에 집중
3.1.2 실험 조건
무료 플랜 사용
- 모든 AI 웹 빌더는 가급적 무료 플랜으로만 작업하여, 일반 사용자들이 실제로 접근 가능한 수준에서의 성능을 평가합니다.
- 이를 통해 각 서비스의 무료 제공 범위와 제약사항도 함께 파악
3.1.2 라운드별 실험 설계
AI 웹빌더 4종 대결 - 라운드별 진행 상황
각 라운드는 기능의 복잡도를 점진적으로 높여가며, AI 웹 빌더들이 어디까지 구현 가능한지 단계별로 검증하는 방식으로 설계했습니다.
Round 1: 기본 UI 구현
목표: 중간지점 찾기 기본 화면 구성
- 지도 영역 (또는 시뮬레이션)
- 2-5명 출발지 입력
- 중간지점 계산 및 표시
- 각자 거리 표시
Round 2: 장소 추천 시스템
목표: 중간지점 근처 장소 추천 UI
- 카테고리 탭 (카페/음식점/술집)
- 장소 카드 디자인
- 평점, 거리, 태그 표시
- 필터/정렬 기능
Round 3: 실시간 투표
목표: 5명이 함께 장소 결정하는 투표 시스템
- 후보 선택 단계
- 실시간 투표 UI
- 프로그레스 바와 애니메이션
- 결과 발표
Round 4: 전체 플로우
목표: 투표→약속→벌칙까지 연결된 UX
- 단계별 자연스러운 전환
- 약속 시간 설정
- 지각 벌칙 설정
- 최종 확정 및 공유
참고: 각 라운드별로 사용했던 상세한 프롬프트와 기능 명세는 별도 포스트에서 공개할 예정입니다.
각각의 과정을 통해서 AI Web Builder 들을 동시에! 하나씩 테스트해보겠습니다.
