Bolt.new 및 Lovable 사용 시 제품 관리자가 겪는 문제점
제품 관리자(PM)는 AI를 활용한 앱의 신속한 프로토타이핑을 위해 Bolt.new와 Lovable에 매력을 느낍니다. 이 도구들은 '아이디어를 몇 초 만에 앱으로'라는 약속을 내세워, PM이 전체 개발팀 없이도 기능적인 UI나 MVP를 만들 수 있게 해줍니다. 하지만 실제 사용자 피드백은 여러 가지 문제점을 드러냅니다. 일반적인 불만 사항으로는 비효율성을 초래하는 투박한 UX, 팀과의 협업 어려움, 기존 툴체인과의 제한적인 통합, 장기적인 제품 계획에 대한 지원 부족, 그리고 불충분한 분석 또는 추적 기능 등이 있습니다. 아래에서 주요 문제점(사용자 직접 의견 포함)을 분석하고 각 도구가 어떻게 평가되는지 비교해 보겠습니다.
효율성을 저해하는 UX/UI 문제점
Bolt.new과 Lovable 은 모두 최첨단이지만 완벽하지는 않으며, PM들은 종종 작업 속도를 늦추는 UX/UI 문제점들을 마주합니다:
-
예측 불가능한 AI 동작 및 오류: 사용자들은 이러한 AI 빌더가 자주 오류를 발생시키거나 예기치 않은 변경을 일으켜 지루한 시행착오를 겪게 한다고 보고합니다. 한 비기술 사용자는 버튼 하나를 추가하는 데 *“3시간 동안 반복적인 오류”*를 겪으며 모든 토큰을 소진했다고 설명했습니다. 실제로 Bolt.new는 프로젝트가 기본적인 프로토타입을 넘어설 때 *“빈 화면, 누락된 파일, 부분 배포”*를 생성하는 것으로 악명이 높았습니다. 이러한 예측 불가능성 때문에 PM들은 AI의 결과물을 일일이 확인해야 합니다. 한 G2 리뷰어는 Lovable의 프롬프트가 *“예상치 않게 변경되어 혼란스러울 수 있다”*고 지적했으며, 앱 로직이 꼬이면 “다시 정상 궤도로 돌려놓는 데 많은 노력이 필요하다” – 어떤 경우에는 전체 프로젝트를 다시 시작해야 했다고 언급했습니다. PM이 빠르게 진행하려 할 때 이러한 초기화 및 재작업은 좌절감을 안겨줍니다.
-
높은 반복 비용 (토큰 및 시간): 두 플랫폼 모두 사용량 제한 모델(Bolt.new는 토큰, Lovable은 메시지 크레딧)을 사용하며, 이는 효율적인 실험을 방해할 수 있습니다. 여러 사용자들이 Bolt의 토큰 시스템이 과도하게 소모적이라고 불평합니다 – 한 사용자는 *“생각보다 훨씬 많은 토큰이 필요하다”*고 썼으며, *“데이터베이스를 연결하는 순간… [AI]가 한두 번의 프롬프트만으로는 해결하기 어려운 문제에 부딪힐 것”*이라고 덧붙였습니다. 그 결과, 허용량을 소진하는 반복적인 프롬프트 및 수정 주기가 발 생합니다. 또 다른 좌절한 Bolt.new 사용자는 이렇게 비꼬았습니다: “토큰의 30%는 앱을 만드는 데 사용됩니다. 나머지 70%는… Bolt가 만든 모든 오류와 실수를 해결하는 데 사용됩니다.” 이에 대한 답글도 있었습니다: “정말 맞아요! [저는] 한 달에 벌써 세 번이나 [구독을] 갱신했어요!”. Lovable의 사용 모델도 예외는 아닙니다 – 기본 티어는 간단한 앱에도 충분하지 않을 수 있습니다 (한 리뷰어는 *“기본 요금제에 가입했지만 간단한 앱을 만드는 데도 충분하지 않다”*고 말하며, 다음 티어의 비용이 급격히 상승한다고 언급했습니다). PM들에게 이는 프로토타입을 반복하는 데만 한도에 도달하거나 추가 비용을 발생시킨다는 의미이며, 이는 명백한 효율성 저해 요인입니다.
-
제한적인 사용자 정의 및 UI 제어: 두 도구 모두 UI를 빠르게 생성하지만, 사용자들은 세부 조정 기능이 부족하다는 점을 발견했습니다. 한 Lovable 사용자는 속도를 칭찬하면서도 *“사용자 정의 옵션이 다소 제한적”*이라고 아쉬워했습니다. 기본 제공 템플릿은 보기 좋지만, 기본적인 수정 이상으로 조정하는 것은 번거로울 수 있습니다. 마찬가지로 Lovable의 AI는 때때로 변경해서는 안 되는 코드를 변경합니다 – 한 사용자는 *“새로운 것을 추가할 때 변경되어서는 안 되는 코드를 변경한다”*고 지적했으며, 이는 PM의 작은 변경이 의도치 않게 앱의 다른 부분을 손상시킬 수 있음을 의미합니다. 반면 Bolt.new는 초기에는 시각적 편집 기능을 거의 제공하지 않았습니다. 모든 작업은 프롬프트나 백그라운드 코드 편집을 통해 이루어졌는데, 이는 비개발자에게는 부담스러운 일이었습니다. (Lovable은 레이아웃 및 스타 일 변경을 위한 “시각적 편집” 모드를 도입하기 시작했지만, 아직 초기 액세스 단계입니다.) 강력한 WYSIWYG 편집기나 드래그 앤 드롭 인터페이스(두 도구 모두)의 부재는 코드를 깊이 파고들고 싶지 않은 PM들에게는 고통스러운 부분입니다. Lovable 자체 문서에서도 이러한 격차를 인정하며, 미래에 더 많은 드래그 앤 드롭 기능을 제공하여 프로세스를 “비기술 사용자에게 더 접근하기 쉽게” 만들겠다고 명시하고 있습니다 – 이는 현재 사용 편의성이 여전히 개선될 여지가 있음을 암시합니다.
-
UI 워크플로우 결함: 사용자들은 플랫폼 사용의 원활함을 방해하는 작은 UX 문제점들을 지적했습니다. 예를 들어 Bolt.new에서는 배포 대상을 구성하지 않은 상태에서도 사용자가 “배포”를 클릭할 수 있도록 인터페이스가 허용하여 혼란을 야기했습니다 (사용자는 *“배포를 시도했지만 Netlify를 구성하지 않았다면 구성하라는 메시지를 띄워야 한다”*고 제안했습니다). Bolt는 또한 편집기에 diff 또는 기록 보기가 없었습니다; 기존 개발 도구와 달리 *“무엇을 변경하는지 설명은 하지만… 실제 코드에는 diff가 표시되지 않는다”*고 했습니다. 이는 PM이 각 반복에서 AI가 무엇을 변경했는지 이해하기 어렵게 만들어 학습과 신뢰를 저해합니다. 또한 Bolt의 세션 채팅 기록은 매우 짧아서 이전 지침을 검토하기 위해 멀리 스크롤할 수 없었습니다 – 이는 잠시 자리를 비웠다가 나중에 돌아와서 맥락이 필요한 PM에게는 문제입니다. 이러한 인터페이스 결함들은 변경 사항과 상태를 추적하는 데 추가적인 정신적 부담을 의미합니다.
요약하자면, Bolt.new는 완성도보다는 순수한 성능을 우선시하는 경향이 있어 PM들이 거친 부분으로 인해 어려움을 겪을 수 있는 반면, Lovable의 UX는 더 친숙하지만 여전히 깊이 면에서는 제한적입니다. 한 비교는 다음과 같이 말했습니다: “Bolt.new는 순수한 속도와 완전한 제어를 원한다면 훌륭합니다… 풀스택 앱을 빠르게 생성하지만, 프로덕션을 위해 정리해야 할 부분이 많을 것입니다. Lovable은 더 구조적이고 디자인 친화적이며… 기본적으로 더 깔끔한 코드를 제공합니다.” 제품 관리자에게 그 “정리” 시간은 심각한 고려 사항이며, 많은 사람들이 이러한 AI 도구가 초기 개발 시간에서 절약해 주는 부분을 디버깅 및 조정 시간으로 부분적으로 되돌려 받는다는 것을 발견했습니다.
협업 및 팀 워크플로우 마찰
PM의 역할 중 중요한 부분은 디자이너, 개발자, 다른 PM 등 팀과 협력하는 것이지만, Bolt.new와 Lovable 모두 다인 협업 및 워크플로우 통합 측면에서 한계를 가지고 있습니다.
-
내장 협업 기능 부족: 두 도구 모두 실시간 다중 사용자 협업(예: Google Docs 또는 Figma)을 염두에 두고 개발되지 않았습니다. 프로젝트는 일반적으로 단일 계정에 연결되어 한 번에 한 사람만 편집할 수 있습니다. 이러한 사일로(고립)는 팀 환경에서 마찰을 일으킬 수 있습니다. 예를 들어, PM이 Bolt.new에서 프로토타입을 신속하게 만들더라도, 디자이너나 엔지니어가 동시에 로그인하여 동일한 프로젝트를 수정할 수 있는 쉬운 방 법이 없습니다. 인수인계가 번거롭습니다. 일반적으로 코드를 내보내거나 저장소에 푸시하여 다른 사람이 작업하도록 해야 합니다(아래에서 언급했듯이 Bolt의 경우 이마저도 쉽지 않았습니다). 실제로 일부 사용자는 이 도구들로 생성한 다음 코드를 다른 곳으로 옮기는 방법을 사용합니다. 한 Product Hunt 토론 참가자는 Bolt나 Lovable을 사용하여 아이디어를 얻은 후 *“내 GitHub에 올리고 Cursor를 사용하여 빌드를 마쳤다”*고 인정했습니다. 이는 본질적으로 팀 개발을 위해 다른 도구로 전환하는 것입니다. 이는 지속적인 협업을 위해 사용자들이 Bolt/Lovable 환경을 벗어나야 할 필요성을 느낀다는 것을 나타냅니다.
-
버전 제어 및 코드 공유: 초기에 Bolt.new는 내장된 Git 통합 기능이 없었습니다. 한 개발자는 이를 “말도 안 되는” 간과라고 지적하며 *“내 코드가… Git에 있기를 전적으로 원한다”*고 말했습니다. 네이티브 버전 제어 기능이 없으면 Bolt의 결과물을 팀의 코드베이스에 통합하는 것이 번거로웠습니다. (Bolt는 다운로드 가능한 코드 ZIP 파일을 제공했으며, 이를 GitHub에 푸시하기 위한 타사 브라우저 확장 프로그램이 등장했습니다.) 이는 개발자와 협업하려는 PM의 작업 흐름을 방해할 수 있는 추가 단계입니다. 대조적으로 Lovable은 “락인(lock-in) 없음, GitHub 동기화” 기능을 자랑하며, 사용자가 저장소를 연결하고 코드 업데이트를 푸시할 수 있도록 합니다. 이는 팀에게 판매 포인트가 되었습니다. 한 사용자는 *“Git 통합(협업 팀 환경)을 위해 Lovable을 사용했다”*고 언급한 반면, Bolt는 빠른 단독 작업에만 사용되었다고 했습니다. 이러한 측면에서 Lovable은 팀 인수인계를 용이하게 합니다. PM은 앱을 생성하고 즉시 코드를 GitHub에 올려 개발자가 검토하거나 이어서 작업할 수 있도록 할 수 있습니다. Bolt.new는 이후 StackBlitz를 통해 GitHub 커넥터를 추가하며 개선을 시도했지만, 커뮤니티 피드백에 따르면 여전히 원활하지 않습니다. Git을 사용하더라도, AI 기반 코드는 기계 생성된 것이고 때로는 자명하지 않기 때문에 문서 없이는 팀이 파악하기 어려울 수 있습니다.
-
워크플로우 통합 (디자인 및 개발 팀): 제품 관리자는 종종 디자이너를 초기에 참여시키거나, 자신이 만드는 것이 디자인 사양과 일치하는지 확인해야 합니다. 두 도구 모두 여기서 통합을 시도했지만(아래에서 더 자세히 논의), 여전히 마찰이 있습니다. 개발자에게 Bolt.new의 한 가지 장점은 기술 스택에 대한 더 직접적인 제어를 허용한다는 것입니다. Lovable의 창립자가 언급했듯이 *“어떤 프레임워크든 사용할 수 있게 해준다”*는 점은 기술을 선택하고 싶어 하는 개발 팀원을 만족시킬 수 있습니다. 그러나 이러한 유연성은 Bolt가 가이드형 PM 도구라기보다는 개발자의 놀이터에 가깝다는 것을 의미합니다. 대조적으로 Lovable의 구조화된 접근 방식(권장 스택, 통합 백엔드 등)은 개발자의 자유를 제한할 수 있지만, 비엔지니어가 선호하는 더 안내된 경로를 제공합니다. 팀에 따라 이러한 차이는 문제점이 될 수 있습니다. Bolt는 너무 무의견하게 느껴지거나 (PM이 팀이 싫어하는 설정을 실수로 선택할 수 있음), Lovable은 너무 제약이 많게 느껴질 수 있습니다 (개발 팀이 선호하는 프레임워크를 사용하지 않음). 어느 경우든, 프로토타입을 팀의 표준에 맞추려면 추가적인 조정이 필요합니다.
-
외부 협업 도구: Bolt.new와 Lovable 모두 일반적인 협업 스위트와 직접 통합되지 않습니다(알림을 위한 직접적인 Slack 통합, 이슈 추적을 위한 Jira 통합 등이 없음). 이는 도구 내의 모든 업데이트나 진행 상황을 팀에 수동으로 전달해야 한다는 의미입니다. 예를 들어, PM이 프로토타입을 만들고 피드백을 원한다면, 배포된 앱 또는 GitHub 저장소 링크를 이메일/Slack을 통해 직접 공유해야 합니다. 플랫폼이 팀에 자동으로 알리거나 프로젝트 티켓에 연결하지 않습니다. 팀 워크플로우와의 이러한 통합 부족은 의사소통의 공백으로 이어질 수 있습니다. PM은 Figma와 같은 디자인 도구에서 할 수 있는 것처럼 Bolt/Lovable 내에서 작업을 할당하거나 특정 UI 요소에 대해 팀원에게 댓글을 남길 수 없습니다. 모든 것은 도구 외부에서 임시방편으로 처리되어야 합니다. 본질적으로 Bolt.new와 Lovable은 설계상 단일 사용자 환경이며, 이는 PM이 다중 사용자 환경에서 사용하고자 할 때 어려움을 초래합니다.
요약하자면, Lovable은 팀 시나리오에서 Bolt.new보다 약간 우위에 있습니다 (GitHub 동기화 및 비코더가 따르기 쉬운 구조화된 접근 방식 덕분입니다). 단독으로 작업하는 제품 관리자는 Bolt의 개인주의적인 설정을 용인할 수 있지만, 다른 사람을 참여시켜야 한다면 팀이 수동 프로세스를 만들지 않는 한 이 도구들은 병목 현상이 될 수 있습니다. 협업의 공백은 사용자들이 작업을 내보내고 다른 곳에서 계속하는 주요 이유입니다. AI는 프로젝트를 빠르게 시작할 수 있지만, 협업하여 진행하려면 여전히 기존 도구가 필요합니다.
다른 도구와의 통합 문제
현대적인 제품 개발은 디자인 플랫폼, 데이터베이스, 타사 서비스 등 다양한 도구 모음을 포함합니다. PM(제품 관리자)들은 기존 툴킷과 잘 연동되는 소프트웨어를 중요하게 생각하지만, Bolt.new와 Lovable은 제한적인 통합 생태계를 가지고 있어 종종 해결책을 찾아야 합니다:
-
디자인 도구 통합: 제품 관리자들은 종종 디자인 목업이나 와이어프레임으로 작업을 시작합니다. Bolt와 Lovable 모두 이를 인지하고 디자인을 가져오는 방법을 도입했지만, 이 기능에 대한 사용자 피드백은 엇갈립니다. Bolt.new는 디자인에서 코드를 생성하기 위해 Figma 가져오기 기능(Anima 플러그인 기반)을 추가했지만, 기대만큼의 성과를 내지 못했습니다. 초기 테스터는 홍보 영상에서 완벽하고 간단한 가져오기 기능을 보여주었지만, *“작동하지 않는 부분은 어떻게 되는가? 만약 어떤 도구가 판도를 바꿀 것이라면, 쉬운 것뿐만 아니라 복잡성도 다룰 수 있어야 한다.”*라고 언급했습니다. 실제로 Bolt는 매우 깔끔하지 않은 Figma 파일에서 어려움을 겪었습니다. Bolt의 Figma 통합을 사용해본 한 UX 디자이너는 기본 레이아웃 외에는 만족스럽지 않다고 느꼈으며, 이 통합이 *“복잡한 디자인에서는 흔들릴 수 있다”*고 지적했습니다. Lovable은 최근 Builder.io 통합을 통해 자체 Figma-to-code 파이프라인을 출시했습니다. 이는 잠재적으로 더 깔끔한 결과를 낼 수 있지만(Builder.io가 Figma를 해석하여 Lovable에 전달하기 때문), 새로 출시된 기능 이라 아직 널리 검증되지 않았습니다. 적어도 한 비교에서는 Lovable이 *“더 나은 UI 옵션(Figma/Builder.io)”*과 더 디자인 친화적인 접근 방식을 제공한다고 칭찬했습니다. 그럼에도 불구하고, *“업데이트 생성 속도가 약간 느리다”*는 점은 디자인의 완성도를 위한 절충안으로 보고되었습니다. PM들에게 중요한 점은 디자인 가져오기가 항상 클릭 한 번으로 간단하지 않다는 것입니다. AI의 기능에 맞게 Figma 파일을 조정하거나 가져온 후 생성된 UI를 정리하는 데 시간을 할애해야 할 수 있습니다. 이는 디자이너와 AI 도구 간의 워크플로우에 마찰을 더합니다.
-
백엔드 및 데이터베이스 통합: 두 도구 모두 프런트엔드 생성에 중점을 두지만, 실제 앱에는 데이터와 인증이 필요합니다. Bolt.new와 Lovable 모두 선택한 솔루션은 Supabase(호스팅된 PostgreSQL 데이터베이스 + 인증 서비스)와의 통합입니다. 사용자들은 이러한 통합이 존재한다는 점을 높이 평가하지만, 실행에는 미묘한 차이가 있습니다. 초기에는 Bolt.new의 Supabase 통합이 기초적인 수준이었고, Lovable의 통합은 비교적 *“더 긴밀하고 [더] 간단하다”*고 평가되었습니다. Lovable의 창업자는 Lovable 시스템이 데이터베이스 통합 시에도 ‘막히는’ 경우가 적도록 미세 조정되었다고 강조했습니다. 그럼에도 불구하고, Supabase를 사용하려면 PM이 데이터베이스 스키마에 대한 어느 정도의 이해를 가지고 있어야 합니다. Lovable에 대한 Medium 리뷰에서, 저자는 Supabase에 수동으로 테이블을 생성하고 데이터를 업로드한 다음, API 키를 통해 연결하여 완전히 작동하는 앱(예: 티켓팅 앱의 이벤트 및 장소)을 얻어야 했습니다. 이 과정은 가능했지만, 사소하지는 않았습니다. 데이터 모델의 자동 감지 기능이 없으므로, PM이 직접 정의해야 합니다. 연결에 문제가 발생하면 디버깅은 다시 사용자의 몫입니다. Lovable은 도움을 주려고 노력하지만(Supabase 연결 중 오류가 발생했을 때 AI 어시스턴트가 지침을 제공), 완벽하지는 않습니다. Bolt.new는 사용자 불만 이후 최근에야 “Supabase 통합에 많은 개선 사항을 적용했습니다”. 그 전에는 한 사용자가 말했듯이, *“Bolt는 프런트엔드 작업을 처리하지만 백엔드 도움은 거의 제공하지 않는다”*고 했습니다. 간단한 사전 설정 외에는 서버 로직에 대해 스스로 해결해야 했습니다. 요약하자면, 두 도구 모두 백엔드 통합을 가능하게 했지만, 이는 피상적인 통합입니다. PM들은 Supabase가 제공하는 기능에 제한될 수 있습니다. 더 커스텀한 것(예: 다른 데이터베이스 또는 복잡한 서버 로직)은 지원되지 않습니다(예를 들어, Bolt와 Lovable은 Python/Java와 같은 언어로 임의의 백엔드 코드를 생성하지 않습니다). 이는 제품 요구 사항이 기본적인 CRUD 작업을 넘어설 때 답답함을 유발할 수 있습니다.
-
타사 서비스 및 API: 현대 제품의 핵심 부분은 서비스(결제 게이트웨이, 지도, 분석 등)에 연결하는 것입니다. Lovable과 Bolt는 API를 통합할 수 있지만, 사전 구축된 플러그인이 아닌 프롬프트 인터페이스를 통해서만 가능합니다. 예를 들어, Reddit의 한 사용자는 AI에게 *“날씨 API가 필요해”*와 같이 말하면, 도구가 인기 있는 무료 API를 선택하고 API 키를 요청하는 방법을 설명했습니다. 이는 인상적이지만, 동시에 불투명합니다. PM은 AI가 적합한 API를 선택하고 호출을 올바르게 구현할 것이라고 신뢰해야 합니다. 통합을 위한 앱 스토어나 그래픽 설정이 없습니다. 모든 것은 프롬프트를 어떻게 작성하느냐에 달려 있습니다. 결제 또는 이메일과 같은 일반적인 서비스의 경우, Lovable은 이를 내장함으로써 우위를 점하는 것으로 보입니다. 창업자에 따르면, Lovable은 기능 중 *“결제 + 이메일 통합”*을 포함하고 있습니다. 만약 사실이라면, 이는 PM이 Lovable에게 Stripe 결제 양식을 추가하거나 통합 서비스를 통해 이메일을 보내도록 더 쉽게 요청할 수 있음을 의미합니다. 반면 Bolt의 경우 API 호출을 통해 수동으로 설정해야 할 수도 있습니다. 그러나 이에 대한 문서는 부족합니다. 이는 클릭 한 번으로 설정하는 방식이 아닌 AI 에이전트를 통해 처리될 가능성이 높습니다. 명확하고 사용자 친화적인 통합 모듈의 부족은 문제점으로 간주될 수 있습니다. 새로운 것을 통합하려면 시행착오가 필요하며, AI가 특정 서비스를 모르면 PM은 난관에 부딪힐 수 있습니다. 본질적으로, 통합은 가능하지만 “플러그 앤 플레이” 방식은 아닙니다.
-
엔터프라이즈 툴체인 통합: 제품 관리 툴체인(티켓 관리를 위한 Jira, 알림을 위한 Slack 등) 자체와의 통합에 있어서는 Bolt.new와 Lovable 모두 현재 즉시 사용 가능한 기능을 제공하지 않습니다. 이 플랫폼들은 독립적으로 작동합니다. 결과적으로, 이를 사용하는 PM은 다른 시스템을 수동으로 업데이트해야 합니다. 예를 들어, PM이 Jira에 사용자 스토리(“사용자로서 X 기능을 원합니다”)를 가지고 있고 Lovable에서 해당 기능을 프로토타입으로 만들더라도, Lovable 내에서 해당 스토리를 완료로 표시할 방법이 없습니다. PM은 Jira로 이동하여 직접 처리해야 합니다. 마찬 가지로, Bolt가 빌드를 완료했을 때 Slack 봇이 “프로토타입이 준비되었습니다”라고 알리지 않습니다. PM은 미리보기 링크를 가져와 공유해야 합니다. 이러한 격차는 이 도구들의 초기 초점을 고려할 때 놀라운 일은 아니지만, 팀 환경에서 워크플로우 효율성을 저해합니다. 본질적으로 이는 컨텍스트 전환입니다. Bolt/Lovable에서 빌드 작업을 한 다음, PM 도구로 전환하여 진행 상황을 기록하고, 팀에 보여주기 위해 커뮤니케이션 도구로 전환해야 할 수도 있습니다. 통합된 소프트웨어는 이를 간소화할 수 있지만, 현재 그 부담은 PM에게 있습니다.
요컨대, Bolt.new와 Lovable은 일부 기술 영역(특히 데이터용 Supabase)에서 잘 통합되지만, 제품 관리자들이 매일 사용하는 더 넓은 도구 생태계에 통합되는 데는 미흡합니다. Lovable은 내장된 경로(예: 원클릭 배포, 직접 GitHub 연동, 일부 내장 서비스)를 제공하는 데 약간 더 진전을 보인 반면, Bolt는 종종 외부 서비스(Netlify, 수동 API 설정)를 필요로 합니다. NoCode MBA 리뷰는 이를 명확히 대조합니다. “Lovable은 내장된 게시 기능을 제공하는 반면, Bolt는 Netlify와 같은 외부 서비스에 의존한다”. 이러한 격차를 메우기 위한 노력(수동으로 코드를 복사하거나, 타사 플러그인을 만지작거리거나, 다른 시스템에 업데이트를 다시 입력하는 등)은 원활한 경험을 추구하는 PM들에게 진정한 불편함입니다.
제품 기획 및 로드맵 관리의 한계
빠른 프로토타입 구축을 넘어, 제품 관리자는 기능을 기획하고, 로드맵을 관리하며, 제품이 발전할 수 있도록 보장할 책임이 있습니다. 이 점에서 Bolt.new와 Lovable의 범위는 매우 좁습니다. 이들은 앱을 만드는 데 도움을 주지만, 더 광범위한 제품 기획이나 지속적인 프로젝트 관리를 위한 도구는 제공하지 않습니다.
-
백로그 또는 요구사항 관리 부재: 이러한 AI 앱 빌더는 백로그, 사용자 스토리 또는 작업의 개념을 포함하지 않습니다. 제품 관리자는 Bolt.new나 Lovable을 사용하여 기능을 나열하고 구조화된 방식으로 하나씩 처리할 수 없습니다. 대신, 개발은 프롬프트("X를 만드세요", "이제 Y를 추가하세요")에 의해 진행되며, 도구는 그에 따라 앱을 생성하거나 수정합니다. 이는 임시 프로토타입 제작에는 효과적이지만, 관리되는 로드맵으로 이어지지는 않습니다. 제품 관리자가 특정 기능의 우선순위를 정하거나 릴리스 계획을 세우려면 여전히 외부 도구(예: Jira, Trello 또는 간단한 스프레드시트)가 필요합니다. AI는 보류 중인 사항이나 기능 간의 관계를 알려주지 않습니다. 프로젝트 타임라인이나 의존성에 대한 개념이 없으며, 오직 사용자가 제공하는 즉각적인 지시만 따릅니다.
-
대규모 프로젝트 관리의 어려움: 프로젝트가 복잡해질수록 사용자들은 이러한 플랫폼이 한계에 부딪힌다는 것을 알게 됩니다. 한 G2 리뷰어는 Lovable에 대해 *“포트폴리오를 확장하기 시작하면서 복잡하거나 대규모 프로젝트를 처리할 도구가 많지 않다는 것을 깨달았다”*고 언급했습니다. 이러한 의견은 Bolt.new에도 적용됩니다. 이 들은 '그린필드' 방식의 소규모 앱에 최적화되어 있습니다. 여러 모듈, 사용자 역할, 복잡한 로직 등을 포함하는 상당한 규모의 제품을 구축하려고 하면 프로세스가 다루기 어려워집니다. 기본 코드 프레임워크가 제공하는 것 외에는 모듈이나 패키지에 대한 지원이 없습니다. 또한 두 도구 모두 기존 코드베이스에 연결할 수 없으므로, AI가 생성한 개선 사항을 장기 프로젝트에 점진적으로 통합할 수 없습니다. 이는 성숙한 제품의 반복적인 개발에는 적합하지 않다는 의미입니다. 실제로 Lovable로 구축된 프로토타입이 실제 제품이 되어야 할 경우, 팀은 특정 규모에 도달하면 종종 도구 외부에서 이를 다시 작성하거나 리팩터링합니다. 제품 관리자 관점에서 이러한 한계는 Bolt/Lovable의 결과물을 일회용 프로토타입이나 시작점으로 취급해야 하며, 확장될 실제 제품으로 보아서는 안 된다는 것을 의미합니다. 해당 도구 자체는 그러한 여정을 지원하지 않습니다.
-
AI 생성의 일회성 특성: Bolt.new와 Lovable은 지속적인 개발 환경이라기보다는 마법사처럼 작동합니다. 이들은 초기 아이디어 구상 단계에서 빛을 발합니다(아이디어가 있으면 프롬프트를 입력하고 기본적인 앱을 얻습니다). 그러나 제품 진행 상황에 대한 지속적인 기획 및 모니터링을 위한 기능은 부족합니다. 예를 들어, "스프린트 1: 로그인 구현 (AI 완료), 스프린트 2: 프로필 관리 구현 (할 일)" 등을 삽입할 수 있는 로드맵 타임라인 개념이 없습니다. 또한 이전 버전으로 쉽게 되돌리거나 새 기능을 브랜치할 수도 없습니다. 이는 제품 개발의 표준 관행입니다. 이로 인해 제품 관리자는 종종 '