
두 명의 AI 빌더에게 동일한 브리프를 주었습니다. 하지만 그들 중 누구도 승리하지 못했습니다!
요약
AI 앱 빌더인 Bolt.new와 Lovable을 대상으로 동일한 브리프를 제공하여 제품 구현 능력을 비교 실험했습니다. Lovable은 데이터 모델과 엔지니어링 측면에서 뛰어난 성능을 보였으나, 실제 사용자 흐름(User Flow) 구현에는 한계를 드러냈습니다.
핵심 포인트
- Lovable은 데이터 모델, 경로, 브랜드 구현 등 엔지니어링 작업에서 높은 정확도를 보임
- 복잡한 요구사항을 단 몇 분 만에 구현하여 초기 개발 리스크를 크게 줄임
- 하지만 실제 사용자 경험(UX)과 핵심 기능 흐름 구현에는 미흡한 점이 발견됨
- AI 빌더 사용 시 엔지니어링 결과물뿐만 아니라 사용자 흐름 검증이 필수적임
지난달, 저는 사이드 프로젝트로 작은 제품을 만드는 데 시간을 보냈습니다.
Formula 1 레이스 주말 동안 환대 산업(hospitality)을 운영하는 사람들을 위한 도구입니다.
VIP 게스트, 패독(paddock) 출입 권한, 그리고 연습 주행(practice), 예선(qualifying), 본선(race)에 걸쳐 각 개인을 위한 3일간의 일정(itinerary)을 추적하는 사람들 말이죠.
이것은 장난감 시장이 아닙니다.
F1의 패독 클럽(Paddock Club)은 지난 시즌 티켓당 약 7,000달러의 가격으로 65,000명의 고객에게 서비스를 제공했습니다. 이는 4억 5천만 달러 이상의 매출이며, 매년 10%씩 성장하고 있습니다.
이러한 숫자 뒤에는 누군가가 실제 조정(coordination) 작업을 수행하고 있습니다. 그 사람이 바로 제가 설계 대상으로 삼은 사용자입니다.
직접 만들기 전에, 저는 한 가지 실험을 진행했습니다.
실험
저는 하나의 상세한 브리프(brief)를 작성했습니다. 데이터 모델(Data model), 경로(routes), 브랜드(brand), F1 미학(aesthetic) 등 모든 것이 포함된 완전한 핸드오프 문서(handoff doc)였습니다.
그런 다음, 두 명의 AI 앱 빌더(AI app builders)에게 정확히 동일한 브리프를 전달했습니다.
- @boltnew
- @lovable
동일한 단어, 동일한 날짜, 추가적인 유도(steering) 없음.
저는 단순히 미리보기(previews)만 훑어본 것이 아닙니다. 실제 헤드리스 브라우저(headless browser)로 두 서비스 모두에 로그인하여 모든 화면을 클릭해 보았습니다. 대시보드(Dashboard), 게스트(guests), 일정 빌더(itinerary builder), 공유 흐름(share flow), 공개 게스트 페이지, 심지어 잘못된 링크까지 확인했습니다.
Lovable이 한 일

Lovable은 순종적이었습니다.
- 문서에 있는 달력을 읽고 정확하게 파악했습니다. 6월 이후부터 시작하여 정확한 주말 날짜, 심지어 새로운 마드리드 라운드까지 맞췄습니다.
- 요청한 대로 이메일 전송 기능을 스텁(stubbed) 처리했습니다.
- 경로(Routes), 데이터 모델(data model), 액세스 티어 배지(access-tier badges), CSV 가져오기(CSV import), 색상별로 구분된 일정(colour-coded itinerary)까지 모두 갖춰져 있었습니다.
- 브랜드 마크(brand mark)도 진심으로 괜찮았습니다. 강력한 엔지니어링(engineering) 능력을 보여주었습니다. 지루한 작업의 70%를 단 몇 분 만에 리스크를 제거(de-risked)했습니다.
그다음, 저는 이 제품이 존재하는 유일한 목적을 수행해 보려고 했습니다.
게스트에게 일정을 제공하는 것 말이죠.
찾을 수 없었습니다.
그 흐름은 "0 assigned"라고 적힌 2픽셀 크기의 회색 라벨 뒤에 파묻혀 있었습니다. 가이드도, 빈 상태(empty state)에 대한 안내도 없었으며, 거의 보이지 않는 수준이었습니다. 제가 직접 스펙(spec)을 작성했음에도 불구하고, 제 자신의 핵심 기능을 찾을 수 없었습니다. 이것은 사소한 트집이 아닙니다. 제품이 존재해야 하는 단 하나의 목적에서 실패했다는 뜻입니다.
Bolt가 한 일

Bolt는 직관은 더 좋았지만, 규율은 더 부족했습니다.
- 게스트를 할당하는 방식은 명확했습니다. 게스트가 일정 항목 바로 위에 칩(chip) 형태로 나타났으며, 폼(form) 내부에서 처리되었습니다. Lovable이 숨겨버렸던 바로 그 워크플로우(workflow)였습니다.
- 타이포그래피(Typography)는 더 차분했습니다. 모든 곳에 대문자를 쓰는 대신 타이틀 케이스(Title Case)를 사용했습니다.
- 게스트 링크를 버튼 뒤에 숨기는 대신 평문(plaintext)으로 전체 링크를 보여주었습니다.
그다음 저는 캘린더(calendar)를 살펴보았습니다.
Bolt는 제 문서를 무시하고 자신만의 문서를 만들어냈습니다. 바레인을 1라운드로 설정해 버린 것입니다.
또한 일정에 없는 레이스들을 가져왔습니다. F1 팬들에게 이것은 즉각적으로 신뢰도를 떨어뜨리는 요소입니다. 그들은 2초 만에 이를 알아챌 것입니다.
결국 저는 진정한 트레이드오프(trade-off) 상황에 놓였습니다.
- Lovable: 데이터에는 충실하지만, UX(사용자 경험)가 약함.
- Bolt: UX는 날카롭지만, 사실 관계에 부주의함.
둘 다 전송할 수 있는 수준이 아니었습니다. 그리고 바로 이 부분이 저에게 실제로 무언가를 가르쳐준 대목입니다.
왜 그들은 그토록 유사했을까?
캘린더 버그와 할당 흐름을 제외하면, 두 앱은 마치 형제처럼 보였습니다.
둘 다 다크 모드(dark mode)를 기본값으로 사용했습니다. 둘 다 같은 폰트, 거의 검은색에 가까운 배경 위의 같은 네온 레드 색상, 같은 대문자 라벨, 동일한 카드들이 나열된 동일한 플랫 그리드(flat grid)를 사용했습니다. 단 하나의 이미지도 없었습니다. 두 개의 서로 다른 회사, 두 개의 서로 다른 모델임에도 화면은 거의 동일했습니다.
이것은 우연이 아닙니다. 이것이 바로 브리프(brief)의 결과입니다.
제가 시각적 요소를 과하게 지정(over-specified)했습니다. 정확한 헥스 코드(hex codes), 정확한 폰트, 날카로운 모서리까지 말이죠. 모든 토큰(token)에서 당신은 디자인 공간을 대략 하나의 정답으로 축소시켜 버립니다. 브리프가 "디자인"을 한 것입니다. 도구들은 그저 그것을 채워 넣었을 뿐입니다. 이 유사함은 둘 중 어느 쪽이 시작하기도 전에 이미 내재되어 있었습니다.
또 다른 결정적인 증거가 있습니다. 제가 사용한 헤드리스 브라우저 (headless browser)에는 다크 모드 (dark-mode) 설정이 되어 있지 않았음에도 불구하고, 두 앱 모두 어쨌든 다크 모드로 렌더링되었습니다. 두 앱 모두 라이트 모드 (light option) 옵션을 만들지 않았습니다. 제 브리프 (brief)에 '거의 검은색에 가까운 배경'이라고 명시했기 때문에, 그들은 그냥 다크 모드로 간 것입니다.
교훈
토큰 (Tokens)은 디자인이 아닙니다.
헥스 코드 (hex code)와 폰트 이름 (font name)은 화면을 만들어낼 뿐입니다. 그것들은 계층 구조 (hierarchy)나, 무엇을 제외할 것인가에 대한 의도적인 선택을 만들어내지 못합니다. 제 브리프는 모든 페인트(색상)를 지정했을 뿐 건축(구조)은 지정하지 않았기에, 두 도구 모두 F1 컬러를 입은 똑같이 안전한 관리자 패널 (admin panel)을 기본값으로 내놓았습니다.
진정한 디자인은 제가 단 한 번도 글로 적지 않은 부분이었습니다. 레이아웃 (Layout). 강조 (Emphasis). 눈이 가장 먼저 머무는 곳. 무엇을 덜어낼 것인가.
그래서 저는 그것을 다시 만들었고, 가장 먼저 버린 것은 저 자신의 미적 취향이었습니다.
- 기본은 라이트 모드, 다크 모드는 감옥이 아닌 선택 사항으로.
- 에디토리얼 (Editorial) 및 이미지 중심. 감정을 전달하는 것은 단순한 그래픽이 아닌 실제 회로 사진.
- 개성을 위한 Space Grotesk, 차분한 독서를 위한 Inter.
- 레드는 페인트처럼 칠하는 것이 아니라, 강조색 (accent)으로 절제하여 사용.
- 그리고 Bolt가 제대로 해낸 단 한 가지, 게스트를 할당하는 발견 가능한 칩 (chip) 기반의 방식은 유지했습니다.
같은 문제. 같은 범주의 도구들. 하지만 완전히 다른 결과물. 차이는 기술이 아니라 판단력 (judgment)에 있었습니다.
만약 당신이 AI 도구나 팀원에게 브리프를 준다면, 충분한 방향을 제시하는 것과 오직 당신만이 내려야 할 단 하나의 결정을 실수로 넘겨주는 것 사이의 경계는 어디일까요?
AI 자동 생성 콘텐츠
본 콘텐츠는 Dev.to AI tag의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기