AI Coding Agent vs AI Website Builder: Claude Fable 5.2, We0, Lovable, Bolt는 어떻게 선택해야 할까?

Claude Fable 5.2의 등장으로 “하나의 Agent로 제품 전체를 처음부터 작성한다”는 말이 과거보다 현실적으로 들리게 되었다. 하지만 그것이 바꾼 것은 모델이 한 번의 작업에서 얼마나 많은 맥락을 이해하고 얼마나 많은 코드를 올바르게 수정할 수 있는가이지, 누가 도메인 연결, 로그인 인증, 결제 대사, 콘텐츠 백오피스, 출시 후 유지보수를 대신 해주는가는 아니다. 이 경계가 바로 AI Coding Agent와 AI Website Builder의 분수령이다.

한 줄 요약: AI 코딩 Agent는 최대한의 자유도를 주는 대신 엔지니어링과 운영 책임을 사용자가 진다. AI 웹사이트 빌더는 일부 자유도를 내주는 대신 이미 연결된 납품 경로를 제공한다. 잘못 선택했을 때의 비용은 보통 첫날 드러나지 않고, 출시 후 3개월째—문구를 수정할 백오피스, 결제를 받을 흐름, 검색엔진과 AI 검색이 이해할 수 있는 구조가 필요해질 때—드러난다.

Claude Fable 5.2가 가져온 변화

Anthropic은 2026년 11월 9일 Claude Fable 5.2와 Claude Mythos 5.2를 발표했으며, 두 모델은 동일한 기반 모델을 사용한다. Fable은 사이버 보안 및 생물 분야를 겨냥한 보호 장치를 갖추고 있어 모든 사용자에게 공개되며, Mythos는 검증 프로젝트를 통해 신청해야 한다. 발표 설명에서 주목할 점은 Anthropic 공지에서 확인할 수 있다:

• 출력 속도는 Fable 5.1보다 최대 30% 빠르며, 가격은 백만 입력 토큰당 8달러, 백만 출력 토큰당 40달러다. 선택형 fast mode는 생성 속도를 최대 2.5배 더 높일 수 있으며, 이 경우 백만 입력 토큰당 16달러, 출력 토큰당 80달러다.
• Agentic coding 평가 FrontierCode 2.0에서 Fable 5.2는 Xhigh effort 기준 49.1%, FrontierSWE v2는 69.9%를 기록해 이전 세대와 Opus 5.5보다 모두 높았다.
• 공식 권장은 대부분의 코딩 및 지식 작업을 Claude Opus 5.5에서 시작하고, 복잡도에 따라 Fable/Mythos로 올리거나 Sonnet, Haiku로 내리는 것이다. Fable 5.2는 Advisor 또는 Orchestrator로 멀티 Agent 협업에 참여할 수도 있다.

이 숫자들이 말하는 것은 단일 작업 능력의 상향 이동이지 제품 형태의 교체가 아니다. 발표 설명은 이를 웹사이트나 애플리케이션의 납품 플랫폼으로 정의하지 않는다. 그것은 Agent 능력을 제공하며, 코드 저장소, 실행 환경, 데이터, 배포 프로세스는 여전히 누군가가 구축하고 유지해야 한다.

먼저 세 가지 도구 형태를 구분한 뒤 선택하자

2026년 웹사이트 구축 실무 가이드는 선택 가능한 도구를 세 가지로 나눈다. 올인원 웹사이트 빌더(예: Wix), prompt-to-app 생성기(예: Lovable, v0), 그리고 자신의 코드 저장소에서 작업하는 코딩 Agent(예: Claude Code류)다. 장단점은 직설적으로 적혀 있다. 올인원 플랫폼은 홍보 사이트와 소규모 상점에 적합하지만 플랫폼 종속과 제한된 성능 제어가 대가다. prompt-to-app 생성기는 사용자 정의 인터페이스와 내보낼 수 있는 코드를 원하는 팀에 적합하지만 credit 또는 token 과금과 산출물의 수동 검수가 대가다. 저장소에서 작업하는 코딩 Agent는 완전한 통제와 버전 이력을 원하는 개발자에게 적합하지만 호스팅, 테스트, 배포를 모두 직접 해야 한다(참고: How to Build a Website With AI in 2026).

이 분류를 Fable 5.2와 함께 보면 분명해진다. Fable 5.2는 세 번째 범주의 ‘엔진’에 속하고, We0, Lovable, Bolt는 엔진, 인프라, 납품 프로세스를 묶은 계층이다. 둘은 같은 트랙의 경쟁 제품이 아니며, 실제로 비교해야 할 것은 ‘누가 납품 책임을 대신 지는가’다.

일곱 가지 차원 횡적 비교

표를 읽을 때 핵심은 하나다. 코드 제어와 배포 방식은 이탈 비용을 결정하고, 인증, 결제, CMS, 다국어는 출시 후 3개월의 운영 부담을 결정하며, 기술 장벽은 이 일을 누가 하고 지속할 수 있는지를 결정한다. 네 가지 인프라 중 하나가 빠지면 직접 보완해야 한다.

We0, Lovable, Bolt는 각각 ‘패키징’을 어디까지 했나

We0의 포지셔닝은 ‘웹사이트 구축에서 리드 확보까지의 AI 워크스페이스’다. 자연어로 요구사항을 설명하면 멀티 Agent 팀이 이를 실행 가능한 웹사이트로 전환하고, 시각적 캔버스에서 미세 조정한 뒤 원클릭으로 자체 도메인에 배포한다. 기능 목록에는 CMS 백오피스, SEO 및 GEO 최적화, 결제 흐름, 이커머스 독립 사이트, 다국어, 도메인 배포가 포함된다(참고: We0 공식 사이트). 강조점은 페이지 생성, 백오피스, 출시, 이후 성장을 같은 경로에 두는 것이지 프런트엔드 코드 한 벌만 납품하는 것이 아니다.

Lovable은 prompt-to-app 생성기 계열이다. 대화로 사용 가능한 인터페이스와 앱을 생성하고 credit으로 과금하며, 산출물을 받은 뒤 항목별 검수가 필요하다. 위 가이드도 ‘출력물 검토 필요’를 주요 트레이드오프 중 하나로 꼽는다.

Bolt는 인프라를 제품 안에 함께 넣었다. 대화형 앱 및 웹사이트 생성 외에도 Bolt Cloud는 호스팅, 데이터베이스, 사용자 관리와 인증, SEO 최적화, 사용자 정의 도메인, 분석을 제공하며, 공식 페이지는 작업에 따라 적합한 모델로 자동 라우팅한다고 설명한다(참고: Bolt 공식 사이트).

세 제품 모두 ‘패키징’ 방향으로 가고 있으며 차이는 강조점에 있다. Bolt는 클라우드 인프라에, We0는 페이지에서 콘텐츠 백오피스, 결제, 다국어, 리드 확보까지의 경로에 무게를 둔다. 판단 기준은 실용적이다. 당신에게 빠진 구간이 어디인가.

여섯 가지 질문에 하나씩 답하기

Claude Fable 5.2가 AI 웹사이트 빌더 도구를 직접 대체할 수 있나?

직접 대체할 수는 없다. 코드 산출과 수정 속도를 분명히 높여주지만, 사이트 납품에는 도메인, 배포, 폼과 리드 접수, 콘텐츠 백오피스, 출시 후 점검이 여전히 필요하다. 팀에 이런 부분을 감당할 엔지니어가 있으면 이런 Agent는 효율 배가 장치다. 그런 사람이 없으면 부족한 것은 더 강한 모델이 아니라 이미 연결된 납품 경로다.

프로그래밍을 모르는 사람은 어떤 것을 선택해야 하나?

웹사이트 빌더를 선택한다. 판단 기준은 ‘어떤 데모가 더 화려한가’가 아니라 ‘사람을 찾지 않고도 문구 수정, 페이지 추가, 이미지 교체, 배포를 할 수 있는가’다. 시각적 캔버스와 원클릭 배포는 코드를 작성할 수 있지만 코드의 옳고 그름을 사용자가 판단해야 하는 Agent보다 현실적이다.

완전한 SaaS를 만들려면 어떤 것을 선택해야 하나?

SaaS의 해자(moat)가 비즈니스 로직, 데이터 모델, 통합에 있다면 코딩 Agent가 더 적합하다. 저장소, 테스트, 버전 이력이 있고 향후 필요에 따라 리팩터링할 수 있다. 다만 인증, 과금, 백오피스, 컴플라이언스의 엔지니어링 작업을 미리 확보해야 하며, 이런 모듈은 보통 ‘한 번 생성’으로 장기간 안정적으로 운영할 수 없다.

기업 공식 웹사이트를 빠르게 하나만 만들고 싶다면?

웹사이트 빌더가 보통 더 경제적이다. 기업 공식 웹사이트의 어려움은 코드가 아니라 구조(홈, 제품과 서비스, 사례, 회사 소개, 문의), 검색 가능한 콘텐츠, 출시 후 지속적인 업데이트에 있다. 이 몇 가지를 이미 연결된 흐름에 두는 것이 프런트엔드 프로젝트를 처음부터 구축하는 것보다 빠르다.

로그인, 결제, CMS 백오피스가 필요할 때는 어떻게 선택하나?

먼저 플랫폼이 이를 기본 제공하는지 확인한 뒤 자체 구축 여부를 결정한다. 코딩 Agent로 직접 구축한다는 것은 각 항목을 선택, 통합, 테스트하고 자금 흐름에 책임을 진다는 뜻이다. 플랫폼을 쓴다면 백오피스가 편집 권한, 다국어, SEO와 GEO의 실제 요구를 충족하는지, 결제 채널이 목표 시장을 커버하는지 확인해야 한다.

이후 계속 반복 개선해야 한다면 어떤 역량에 주목해야 하나?

• 코드와 데이터를 내보낼 수 있는지, 이탈 비용은 얼마인지;
• 편집 가능한 캔버스와 콘텐츠 백오피스가 있어 비기술 동료가 셀프서비스로 개편할 수 있는지;
• 다국어와 구조화 콘텐츠를 지원해 이후 SEO/GEO를 하기 쉬운지;
• 배포와 롤백이 시각적인지, 문제가 생겼을 때 얼마나 빨리 복구할 수 있는지;
• 리드가 어디서 들어오고 어디로 떨어지는지, CRM이나 이메일 시스템에 연결할 수 있는지.

세 가지 전형적인 팀, 세 가지 조합 방식

두 명 창업팀이 B2B 공식 웹사이트를 만들 때: 공식 웹사이트는 웹사이트 빌더로 완성하고, 먼저 페이지 구조, 사례, 인용 가능한 사실 블록을 탄탄히 한다. 제품 프로토타입은 코딩 Agent로 검증하며, 리드 페이지는 엔지니어링 일정을 기다리지 않아도 된다.

엔지니어링 팀이 있는 SaaS 회사: 핵심 제품은 자체 저장소에서 Agent로 개발을 가속하고, 마케팅 사이트와 랜딩 페이지는 플랫폼에 맡겨 매번 이벤트 페이지마다 배포 프로세스를 거치지 않게 한다. 양쪽은 도메인 체계를 공유하지만 콘텐츠와 엔지니어링 책임은 분리한다.

Agency와 컨설턴트: 고객 사이트는 플랫폼으로 대량 납품하고 반복적인 점검과 리드 접수 프로세스를 고정한다. 깊은 맞춤화가 필요한 프로젝트는 Agent로 작성하며, credit이 아니라 프로젝트 단위로 가격을 책정한다.

출시는 시작일 뿐: 발견 가능성과 전환이 장기 비용이다

AI가 생성한 페이지는 본질적으로 초안이다. 배포 전에 최소 세 가지를 해야 한다:

1. 사실 검증: 가격, 서비스 범위, 자격, 연락처를 항목별로 추적 가능하게 하고, 모델이 지어낸 고객 평가와 ‘수만 기업에 서비스했다’ 같은 숫자를 삭제한다.
2. 구조와 발견 가능성: 페이지마다 H1 하나, 고유한 제목과 설명, 서버 측에서 크롤링 가능한 HTML, 올바른 sitemap과 robots.txt. 테스트 환경의 noindex를 운영에 올리지 않는다.
3. 성능과 전환 실측: Core Web Vitals의 통상 통과 기준은 LCP ≤ 2.5초, INP ≤ 200밀리초, CLS ≤ 0.1이며 75백분위로 판단한다(참고: 위 가이드). 폼은 실제로 한 번 제출해 리드가 사람과 시스템에 도달하는지 확인한다.

또 하나 자주 간과되는 차이는 콘텐츠 구조에 있다. AI가 생성한 프런트엔드는 재사용 가능한 컴포넌트와 통일된 콘텐츠 모델이 빠지기 쉬워, 내비게이션을 바꾸려면 페이지마다 복사해야 하고 장기 유지보수 비용이 오히려 올라간다. 페이지 생성과 CMS 관리를 분리하는 것이 더 안정적인 조합이다(참고: Can AI coding platforms replace traditional page builders?).

명확한 정책 리스크도 피해야 한다. Google의 스팸 콘텐츠 정책은 ‘생성형 AI로 새 가치가 없는 페이지를 대량 생산하는 것’을 scaled content abuse의 전형적인 예로 든다. 적지만 유용한 것이 많지만 비슷한 것보다 낫다.

자체 저장소에서 작업하기 전에 명령 한 줄로 대부분의 민망한 상황을 걸러낼 수 있다:

grep -rniE "lorem ipsum|example\.com|TODO|FIXME|api[_-]?key|secret" ./src

실행 가능한 선택 프로세스

1. 목표를 명확히 한다: 이번 버전이 리드를 가져오는 것인지, 요구를 검증하는 것인지, 완전한 제품 로직을 담는 것인지.
2. 필수 요구사항을 나열한다: 로그인, 결제, 백오피스, 다국어, 멀티 사이트를 항목별로 체크한다.
3. 팀 역량을 판단한다: 출시 후 48시간 안에 누가 고장 난 폼을 고칠 수 있는가?
4. 총비용을 계산한다: 구독료, 모델 token 비용, 엔지니어링 시간, 3개월 운영 시간을 같은 표에 넣는다.
5. 소규모로 시험 운영한다: 먼저 랜딩 페이지 하나 또는 하위 프로세스 하나로 검증한 뒤 메인 사이트 이전 여부를 결정한다.

의사결정 체크리스트—세 항목 이상 해당하면 AI 웹사이트 빌더 우선

• 팀에 코드를 장기 유지보수할 사람이 없다;
• 출시 시간이 분기가 아니라 주 단위다;
• 콘텐츠 백오피스, 다국어, 온라인 결제가 필요하다;
• 검색과 AI 인용에 노출될 콘텐츠 페이지를 지속적으로 생산해야 한다.

의사결정 체크리스트—세 항목 이상 해당하면 AI 코딩 Agent 우선

• 제품 로직 자체가 핵심 자산이며 깊은 맞춤화가 필요하다;
• 이미 엔지니어링 팀, 테스트, CI/CD가 있다;
• 내부 시스템이나 자체 데이터 소스에 연결해야 한다;
• 향후 자체 인프라로 이전할 계획이다.

자주 묻는 질문

Claude Fable 5.2란 무엇인가?

Anthropic이 2026년 11월 9일 발표한 모델 버전으로, Mythos 5.2와 동일한 기반 모델을 사용한다. 차이는 Fable이 더 강한 안전 보호 장치를 갖추고 모든 사용자에게 공개된다는 점이다. 개선은 코딩, 추론, 시각 작업에 집중되어 있으며, 공식 권장은 대부분의 일상 코딩과 지식 작업을 Opus 5.5에서 시작하는 것이다.

We0와 Lovable의 차이는 무엇인가?

We0는 페이지 생성, 콘텐츠 백오피스, 결제 흐름, 다국어, 도메인 배포를 같은 납품 경로에 둔다. Lovable은 prompt-to-app 생성기 노선으로 credit으로 과금하며 산출물 검수가 필요하다. 선택은 ‘패키징된 출시 경로’가 필요한지, ‘계속 개발할 수 있는 코드’가 필요한지에 달려 있다.

AI 웹사이트 빌더로 만든 사이트는 SEO가 더 나빠질까?

격차는 보통 플랫폼에서 오지 않고, 기술 기본 항목을 처리했는지에서 온다. 크롤링 가능한 HTML, 고유한 제목과 설명, 규격에 맞는 sitemap, 실제 콘텐츠와 구조화 데이터다. 이런 것은 플랫폼에서도 할 수 있으며, 오히려 자체 구축 프로젝트에서 자주 간과된다.

언제 둘을 함께 사용해야 하나?

흔한 조합은 공식 웹사이트, 랜딩 페이지, 콘텐츠 사이트는 플랫폼으로 지속 운영하고, 내부 시스템, 데이터 파이프라인, 복잡한 비즈니스 로직은 코딩 Agent로 개발하는 것이다. 둘은 브랜드와 도메인을 공유하지만 반복 주기를 분리해 서로 막히지 않게 한다.

관련 도구

• We0: 전시형 웹사이트와 리드 확보를 위한 AI 플랫폼으로, 자연어 웹사이트 구축, CMS 백오피스, 결제 흐름, 다국어, 도메인 배포를 아우른다.
• Bolt: 대화형으로 앱과 웹사이트를 생성하며 호스팅, 데이터베이스, 인증, 사용자 정의 도메인 등 클라우드 기능을 제공한다.
• Claude Fable 5.2 발표 설명: 해당 모델의 Agentic coding 평가 결과와 가격을 확인할 수 있다.

관련 링크

• Anthropic: Claude Fable 5.2와 Mythos 5.2
• How to Build a Website With AI in 2026: Tools and Steps
• Can AI coding platforms replace traditional page builders?
• We0 공식 사이트
• Bolt 공식 사이트

요약

Claude Fable 5.2는 단일 작업의 코딩 능력을 높였지만 납품 책임의 분업을 바꾸지는 않았다. 코딩 Agent는 자유도를 주고, 웹사이트 빌더는 이미 연결된 경로를 준다. 판단 방법은 세 가지 질문으로 정리할 수 있다. 출시 후 누가 유지보수하는가, 어떤 인프라(인증, 결제, 백오피스, 다국어)가 필요한가, 향후 코드를 이전할 계획인가. 먼저 랜딩 페이지 하나나 하위 프로세스 하나로 시험 운영하는 것이 두 형태 사이에서 반복 논쟁하는 것보다 빠르게 답을 얻는 방법이다.