20장. Figma, Lovable, v0와의 비교
20장. Figma, Lovable, v0와의 비교

같은 경기처럼 보이지만, 사실은 종목이 다르다
Claude Design을 이야기하면 거의 자동으로 세 가지 이름이 따라붙습니다. Figma, Lovable, v0. 그래서 사람들은 자꾸 이렇게 묻습니다. "그래서 누가 이기는 건데?"
문제는 이 질문 자체가 절반쯤 빗나가 있다는 데 있습니다. 네 도구는 모두 화면을 만들고, 프로토타입을 만들고, 때로는 코드와도 연결됩니다. 겉모습만 보면 같은 운동장에 선 것처럼 보입니다. 하지만 실제로는 출발점이 다릅니다. Figma는 디자인 파일과 공유 캔버스에서 시작하고, Lovable은 아이디어에서 시작하며, v0는 필요한 컴포넌트 하나에서 시작합니다. Claude Design은 이미 존재하는 코드베이스와 디자인 흔적에서 시작합니다.1
이 차이를 이해하면 비교가 훨씬 쉬워집니다. 누가 더 똑똑한가를 묻기보다, 지금 내 일이 어디에서 시작되는가를 먼저 봐야 합니다. 빈 종이 위에서 시작하는 팀과, 이미 운영 중인 제품을 확장하는 팀은 당연히 다른 도구가 맞습니다.
먼저, 네 도구를 한 장으로 정리해보자
| 도구 | 출발점 | 가장 강한 결과물 | 잘 맞는 사람 | 약한 지점 |
|---|---|---|---|---|
| Claude Design | 기존 코드베이스와 디자인 맥락 | 온브랜드 프로토타입, 슬라이드, 핸드오프 번들 | PM, 창업자, 제품 엔지니어, 마케터 | 실시간 멀티플레이어 협업, 정밀한 최종 디자인 운영 |
| Figma | 디자인 파일과 공유 캔버스 | 정교한 UI 설계, 컴포넌트 라이브러리, 팀 리뷰 | 디자이너, 디자인 조직, 크로스펑셔널 팀 | 비디자이너의 진입장벽, 빠른 초안 생성 속도 |
| Lovable | 자연어 아이디어 | 배포 가능한 풀스택 앱 MVP | 비개발자 창업자, 인디 해커, 초기 실험 팀 | 기존 브랜드/기존 제품과의 정합성, 장기 거버넌스 |
| v0 | 필요한 컴포넌트 프롬프트 | React/Tailwind UI 조각 | 프론트엔드 개발자 | 제품 흐름 설계, 팀 리뷰, 넓은 맥락 반영 |
표만 보면 간단해 보이지만, 실제 선택은 더 미묘합니다. 중요한 건 기능 개수가 아니라 팀의 기준 자산입니다. 우리 팀에서 진짜 기준이 되는 것은 무엇일까요? 디자인 파일인가, 아이디어인가, 컴포넌트인가, 아니면 이미 운영 중인 레포인가. 이 질문 하나가 도구 선택의 절반을 끝냅니다.1
Figma: 팀이 함께 생각하는 캔버스가 필요할 때
Figma의 강점은 여전히 매우 선명합니다. 여러 사람이 같은 파일에서 동시에 작업하고, 컴포넌트 라이브러리를 운영하고, 버전을 비교하고, 코멘트와 리뷰를 남기고, 최종적으로 개발자에게 명세를 건네는 흐름에서 Figma는 여전히 표준에 가깝습니다. 특히 디자인 시스템을 오래 운영해 온 조직이라면, Figma는 단순한 편집기가 아니라 팀의 시각 언어를 관리하는 본부에 가깝습니다.2
그래서 다음과 같은 상황에서는 Figma가 가장 안전합니다. 디자이너 셋이 동시에 같은 흐름을 검토해야 하거나, 모바일과 웹의 컴포넌트 변형을 정밀하게 관리해야 하거나, 픽셀 단위 정렬과 상호작용 명세가 중요한 경우입니다. 이런 일은 "대화로 대충 맞추기"보다 "캔버스 위에서 정확히 합의하기"가 더 중요합니다.
다만 Figma가 모든 시작점에 친절한 것은 아닙니다. PM이 회의 직후 거친 기능 아이디어를 바로 보여주고 싶을 때, 창업자가 오늘 밤 투자자 미팅용 시안을 급히 만들어야 할 때, 마케터가 랜딩 메시지의 방향을 세 가지 버전으로 빨리 비교하고 싶을 때는 Figma의 강점이 오히려 무게로 느껴질 수 있습니다. 즉, Figma는 아주 강한 도구지만 항상 가장 빠른 첫 도구는 아닙니다.2
Lovable: 아이디어를 바로 살아 있는 앱으로 보고 싶을 때
Lovable의 핵심은 간단합니다. "설명하면 돌아가는 앱을 만든다." 이 도구는 예쁜 화면 몇 장보다, 실제로 접속 가능한 웹앱을 빠르게 만드는 쪽에 무게가 실려 있습니다. 프런트엔드뿐 아니라 데이터베이스, 인증, 배포 같은 인프라까지 한 덩어리로 묶어 주기 때문에, 비개발자 창업자나 초기 MVP 팀에게 특히 매력적입니다.3
그래서 제품이 아직 없고, 코드베이스도 없고, 무엇보다 이번 주 안에 살아 있는 데모 URL이 필요하다면 Lovable이 아주 현실적인 선택이 됩니다. 투자자에게 보여줄 초기 제품, 내부 실험용 도구, 고객 인터뷰에 쓸 데모 같은 작업에서 강합니다. 말 그대로 "아이디어를 앱처럼 보이게 만드는 속도전"에 최적화되어 있습니다.34
하지만 기존 제품을 확장하는 단계로 오면 이야기가 달라집니다. 이미 운영 중인 서비스의 브랜드 규칙, 컴포넌트 언어, 디자인 토큰, 팀의 코드 관습을 그대로 이어 받아야 하는 상황에서는 Lovable이 시작점 자체를 다르게 잡습니다. 그래서 결과물이 충분히 훌륭해 보여도, 팀 입장에서는 "우리 것"이 아니라 "잘 만든 새 것"처럼 느껴질 수 있습니다. 이 차이는 작아 보여도 실무에서는 큽니다. 초반엔 멋진 데모였는데, 나중엔 기존 제품과 접합하느라 시간이 더 드는 이유가 바로 여기 있습니다.14
v0: 화면 하나, 컴포넌트 하나가 급할 때
v0는 네 도구 중 가장 개발자 친화적인 성격이 강합니다. 이 도구의 질문은 대개 이렇습니다. "대시보드 카드 하나 빨리 만들어줘." "가입 폼 UI 하나 뽑아줘." "Tailwind로 이 섹션 구성해줘." 즉, 제품 전체의 흐름이나 조직의 디자인 운영보다, 당장 필요한 화면 조각을 빠르게 코드로 얻는 일에 초점을 둡니다.1
이런 특성 덕분에 프론트엔드 개발자에게는 무척 실용적입니다. 이미 프로젝트 구조를 이해하고 있고, 생성된 컴포넌트를 직접 손볼 수 있으며, shadcn/ui나 Tailwind 중심의 작업에 익숙하다면 v0는 아주 빠른 출발점이 됩니다. 거창한 기획 회의 없이도 필요한 블록을 뚝딱 만들어 넣기 좋습니다.
반대로 말하면, v0는 제품 전체 맥락을 대신 책임져 주는 도구는 아닙니다. 누가 어떤 흐름으로 이 화면을 쓰는지, 기존 브랜드가 어떤 인상을 줘야 하는지, 여러 직군이 이 안을 어떻게 검토할지 같은 문제는 v0의 핵심 범위 밖에 있습니다. 그래서 v0는 "무엇을 만들지 아직 모르는 단계"보다는, "무엇을 만들지는 알고 있고 이제 그 부품이 필요하다"는 단계에서 더 빛납니다.1
Claude Design: 이미 있는 제품을 자연스럽게 키울 때
Claude Design이 다른 도구와 가장 분명하게 갈라지는 지점은 레포를 읽고 시작한다는 점입니다. GitHub 저장소와 디자인 파일을 연결하면 Tailwind 설정, CSS 변수, 글꼴 선언, 로고, 컴포넌트 이름 같은 흔적을 바탕으로 현재 제품의 시각 언어를 추출합니다. 말하자면 새 옷을 처음부터 디자인하기보다, 이미 입고 있는 옷장의 문법을 먼저 읽는 방식입니다.15
이 때문에 Claude Design은 특히 기존 제품을 확장할 때 힘을 발휘합니다. 이미 출시된 SaaS에 새 기능을 붙이거나, PM이 기능 흐름을 빠르게 시각화한 뒤 엔지니어와 바로 구현 논의를 하거나, 창업자가 현재 제품과 톤이 맞는 피치덱과 랜딩 시안을 동시에 만들고 싶을 때 유리합니다. Claude Code와의 핸드오프까지 이어지면, 디자인과 구현 사이의 번역 손실도 꽤 줄어듭니다.5
물론 이것이 Figma를 무효화한다는 뜻은 아닙니다. Claude Design은 공유 캔버스 중심의 정밀 협업 도구라기보다, 기존 맥락을 반영한 빠른 생성과 핸드오프 도구에 가깝습니다. 또 Lovable처럼 처음부터 풀스택 앱을 즉시 배포하는 데 초점을 둔 것도 아니고, v0처럼 컴포넌트 한 조각을 제일 빠르게 뽑는 도구도 아닙니다. Claude Design의 자리는 꽤 분명합니다. 이미 있는 제품을, 덜 어긋나게, 더 빨리 확장하는 자리입니다.15
결국 선택 기준은 "무엇이 기준 자산인가"다
여기서 가장 유용한 판단법은 기능 비교표보다 더 단순합니다. 우리 팀이 지금 무엇을 기준으로 일하고 있는지 묻는 것입니다.
디자인 파일이 기준 자산이라면 Figma가 중심입니다. 팀 리뷰, 컴포넌트 거버넌스, 최종 정교화가 중요하다는 뜻입니다.
막연한 아이디어가 기준 자산이라면 Lovable이 강합니다. 일단 작동하는 제품을 보여줘야 하기 때문입니다.
필요한 UI 부품이 기준 자산이라면 v0가 빠릅니다. 화면 한 조각을 만드는 속도가 중요합니다.
운영 중인 코드베이스가 기준 자산이라면 Claude Design이 유리합니다. 기존 제품과 맞물리는 새 기능을 만들어야 하기 때문입니다.1
이 기준은 생각보다 강력합니다. 같은 "랜딩 페이지 만들기"라도 상황에 따라 답이 완전히 달라집니다. 브랜드가 없는 신사업 테스트용 랜딩이면 Lovable이 맞을 수 있고, 이미 서비스가 운영 중이며 기존 톤과 맞는 신규 페이지라면 Claude Design이 더 자연스럽습니다. 디자이너 팀이 여러 안을 검토하고 최종 배포 기준 파일을 남겨야 한다면 Figma가 중심이 됩니다. 페이지 안의 특정 가격표 컴포넌트만 빨리 코딩하고 싶다면 v0가 더 빠를 수 있습니다.
실전에서 가장 자주 맞는 조합들
현실에서는 하나만 쓰는 팀보다, 둘 이상을 이어 쓰는 팀이 훨씬 많습니다. 잘하는 팀은 도구를 한 명의 왕으로 세우지 않고, 각 도구를 제일 잘하는 구간에 배치합니다.
조합 1: 0에서 1을 검증하는 스타트업
처음부터 코드도 없고 디자인 시스템도 없다면, Lovable로 아이디어를 살아 있는 앱처럼 만들어 보는 흐름이 잘 맞습니다. 고객 반응이 붙고 제품 방향이 정해지면 그때 Figma로 디자인 시스템을 정리하거나, 코드베이스가 생긴 뒤 Claude Design으로 확장 워크플로를 옮기는 편이 자연스럽습니다.34
조합 2: 운영 중인 SaaS의 신규 기능 추가
이미 제품이 있고 레포도 살아 있다면 Claude Design이 초반 속도를 크게 올려줍니다. PM이 기능 흐름을 만들고, 엔지니어가 맥락을 이해하고, 필요하면 디자이너가 Figma에서 최종 정교화를 하는 식입니다. 이때 v0는 세부 컴포넌트를 실험하는 보조 도구로 붙일 수 있습니다.15
조합 3: 디자이너가 있는 팀의 AI 활용
디자인 조직이 이미 Figma 중심으로 굴러간다면, Figma를 버릴 이유는 많지 않습니다. 대신 Claude Design을 초기 탐색, 빠른 시안 생성, 온브랜드 프로토타입용 앞단으로 두고, 최종 파일 운영과 리뷰는 Figma에서 하는 구조가 현실적입니다. "탐색은 대화형으로, 확정은 캔버스에서"라는 식입니다.25
조합 4: 프론트엔드 개발자의 속도전
화면 흐름이 아니라 컴포넌트 생산성이 병목이라면 v0가 무척 효율적입니다. 다만 기존 서비스 전체와의 톤을 맞춰야 하는 기능 작업이라면, 먼저 Claude Design으로 큰 흐름과 시각 방향을 잡고, 세부 구현에서 v0나 직접 코딩으로 들어가는 편이 더 덜 어긋납니다.1
도구를 고를 때 꼭 던져야 할 일곱 가지 질문
비교표보다 더 실전적인 방법은, 아래 질문에 답해보는 것입니다.
지금 만드는 것이 새 제품인가, 아니면 기존 제품의 확장인가?
결과물로 필요한 것이 공유 가능한 데모 URL인가, 디자인 파일인가, 코드 컴포넌트인가?
브랜드와 디자인 시스템이 주로 Figma 파일에 있나, 아니면 코드베이스에 녹아 있나?
이 작업은 한 사람이 끝까지 밀 수 있나, 아니면 여러 사람이 같은 캔버스에서 동시에 검토해야 하나?
제일 시급한 것은 제품 흐름 합의인가, 시각 정교화인가, 구현 속도인가?
화면뿐 아니라 인증, 데이터베이스, 배포까지 한 번에 필요한가?
생성 결과를 사람이 많이 다듬을 수 있나, 아니면 처음부터 팀 맥락에 가깝게 나와야 하나?
이 질문에 답하면 도구 선택이 놀랄 만큼 선명해집니다. 예를 들어 "새 제품이고, URL이 필요하고, 백엔드도 같이 필요하다"면 Lovable 쪽으로 기웁니다. "기존 제품 확장이고, 코드베이스가 있고, 팀 톤을 바로 반영해야 한다"면 Claude Design이 맞습니다. "세 명의 디자이너가 한 파일에서 리뷰해야 한다"면 Figma입니다. "로그인 카드 하나 오늘 안에 넣어야 한다"면 v0가 빠릅니다.
마지막으로, 누가 최고인가가 아니라 누가 병목을 없애는가
이 장의 결론은 아주 단순합니다. Figma, Lovable, v0, Claude Design은 같은 왕좌를 두고 싸우는 도구가 아닙니다. 각자 없애는 병목이 다릅니다.
Figma는 팀 협업과 정밀 설계의 병목을 줄입니다. Lovable은 아이디어를 작동하는 앱으로 바꾸는 병목을 줄입니다. v0는 프론트엔드 부품 생산의 병목을 줄입니다. Claude Design은 기존 제품 맥락을 반영한 디자인-코드 핸드오프의 병목을 줄입니다.1235
그래서 좋은 선택은 "무조건 이것만 쓴다"가 아닙니다. 더 좋은 선택은 "우리 팀에서 지금 제일 비싼 번역 단계가 어디인가"를 찾는 것입니다. 말이 화면으로 바뀌는 데 시간이 오래 걸린다면 Claude Design이나 Lovable이 도와줄 수 있습니다. 화면이 팀 합의로 굳어지는 데 시간이 오래 걸린다면 Figma가 필요합니다. 구현 시작점이 너무 느리다면 v0가 잘 맞습니다.
도구 종교전은 늘 시끄럽지만, 실무는 의외로 조용합니다. 결국 남는 질문은 하나입니다. 지금 우리 팀의 다음 병목은 무엇인가? 그 질문에 정직하게 답하면, 어떤 도구를 써야 하는지도 꽤 정직하게 드러납니다.
참고
1Claude Design vs Figma, Lovable, and v0: They're Not Solving the Same Problem
2Claude Design vs Figma: Can Anthropic's New Tool Replace Your Design Stack?
3Claude vs Lovable: Which AI Platform Performs Better?
4Claude Design vs Lovable (2026): Pick Your Poison
5Claude Design: Anthropic's new product aiming to bypass Figma
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.