2026-09-28

빌드 단계 없이 어떤 브라우저에서든 열려야 하는 페이지라면, 여기에서 검토한 도구 중 특화된 옵션으로는 HTML 생성기가 가장 강력합니다. 이미 React와 Next.js를 사용하고 있다면 Vercel의 v0가 더 적합합니다. 호환 가능한 HTML 파일이 아니라 호스팅되는 앱이 필요하다면 Lovable, Bolt, Replit이 더 강력합니다.
이러한 차이는 마케팅에서 말하는 “AI 웹사이트 빌더”라는 범주가 암시하는 것보다 2026년에 더 중요해졌습니다. HTML은 웹의 기본 구성 요소로 남아 있습니다. HTML은 의미와 구조를 정의하고, CSS는 표현을 담당하며, JavaScript는 동작을 처리합니다. 이러한 분리를 건너뛰는 생성기는 페이지를 요청했을 때 프레임워크 프로젝트를 넘겨주는 경우가 많습니다.
사용할 수 있는 AI HTML과 단순히 태그를 쏟아내는 프롬프트를 구분하는 핵심 요소는 다음과 같습니다.
✅ 이식성 — CSS가 내장된 단일 파일(CSS와 JS는 필요한 경우에만 포함)로, 로컬이나 이메일 클라이언트 또는 모든 정적 호스팅에서 열 수 있어야 합니다
✅ 유형을 인식하는 규칙 — 이력서, 청구서, 랜딩 페이지, HTML 이메일은 서로 같은 레이아웃 규칙을 사용하지 않습니다
✅ 디자인 시스템 규율 — 일회성 16진수 값 대신 2~3가지 색상 팔레트, 간격 체계, 명확한 타이포그래피 계층을 사용해야 합니다
✅ 접근성 기본값 — div로 뒤섞인 구조 대신 시맨틱 HTML5, 키보드 포커스, 폼 레이블, WCAG AA 명암 대비를 제공해야 합니다
✅ 내보내기 마찰 — 파일을 즉시 사용할 수 있는지, 아니면 먼저 React/Next.js 앱을 컴파일해야 하는지를 확인해야 합니다
이러한 도구를 공정하게 비교하려면 가장 화려한 데모를 만들 수 있는 도구가 아니라 단일 파일을 얼마나 바로 사용할 수 있는지를 기준으로 점수를 매기는 것이 좋습니다.
실제 결과물의 상당 부분은 애플리케이션이 아니라 문서와 페이지이기 때문에 독립형 HTML은 여전히 중요합니다. 이력서, 청구서, 뉴스레터, 내부 대시보드 목업, 이벤트 페이지 또는 고객 미리보기는 오프라인에서 열리거나, 깔끔하게 인쇄되거나, 수신자가 이미 사용 중인 호스트에서 작동해야 하는 경우가 많습니다.
2026년 시장은 반대 방향으로 움직였습니다. Lovable, Bolt, Replit, v0를 비교하는 글은 “AI 웹사이트 빌더”를 작업 공간, 미리보기 URL, 종속성, 호스팅을 포함한 전체 제품 스택으로 다룹니다. 앱을 출시할 때는 유용합니다. 하지만 파일 하나가 필요할 때는 불필요한 부담입니다.
HTML은 웹 브라우저에 표시되도록 설계된 문서를 위한 표준 마크업 언어입니다. WHATWG HTML 표준은 여전히 문서를 미리 정의된 의미를 가진 요소의 트리로 정의합니다. 여기에는 header, nav, main, article, section, footer가 포함되며, 마크업을 우연히 렌더링하는 React 트리가 아닙니다. 생성기가 이러한 의미론을 무시하면 첫 번째 수정 작업을 시작하기도 전에 접근성과 유지 관리 부채를 떠안게 됩니다.
비용 측면에서도 일정한 패턴이 나타납니다. 공개 비교 자료에 따르면 무료 등급을 벗어나면 Bolt, Lovable, Replit Agents는 일반적으로 월 20달러 이상에서 시작합니다. 한 파일로 된 랜딩 페이지를 만들기 위해 앱 플랫폼 가격을 지불하는 것은 기능의 문제가 아니라 범주가 맞지 않는 선택입니다.
2026년에 실질적으로 물어야 할 질문은 “어떤 AI가 웹사이트를 만들 수 있는가?”가 아닙니다. 휴대 가능한 문서, React 컴포넌트, 호스팅되는 제품 중 무엇이 필요한지, 그리고 선택한 도구가 이러한 작업을 구분할 수 있는지가 핵심입니다.
가장 긴 기능 목록이 아니라 유형 인식, 반복 가능한 디자인 시스템, 시맨틱 마크업, 정직한 내보내기 경로를 살펴봐야 합니다. 유용한 평가 모델은 단일 파일 준비도입니다. 출력물이 바로 출시할 수 있는 페이지인지, 아니면 이제 직접 유지 관리해야 하는 프로젝트인지를 예측하는 6가지 차원으로 구성됩니다.
파일은 npm install, 번들러 또는 프레임워크 런타임 없이 브라우저에서 열려야 합니다. 별도의 스타일시트를 명시적으로 원하지 않는다면 CSS는 \u003cstyle\u003e 안에 있어야 합니다. JavaScript가 포함되는 경우 바닐라 방식의 점진적 향상을 따라야 하며, 스크립트를 꺼도 콘텐츠를 읽을 수 있어야 합니다.
랜딩 페이지, 포트폴리오, 문서, 대시보드, 폼, 이력서, 청구서, 제품 페이지, HTML 이메일은 서로 다른 규칙을 따릅니다. 청구서에는 인쇄용 스타일이 필요합니다. 이메일이 Gmail과 Outlook에서 제대로 표시되어야 한다면 Flexbox, Grid 또는 CSS 사용자 지정 속성에 의존할 수 없습니다. 모든 브리프에 하나의 “현대적인 SaaS” 스타일을 적용하는 생성기는 마케팅 사이트가 아닌 유형에서 실패합니다.
전문적인 HTML은 대부분 간격, 글꼴, 정렬로 구성됩니다. 사용자 지정 속성으로 정의된 작은 색상 팔레트, 일관된 간격 체계, 1.5~1.7 범위의 본문 줄 간격, 모바일 우선 브레이크포인트를 확인하세요. 장식적인 그라디언트보다 시각적 절제가 중요합니다. 생성된 레이아웃에서 가장 흔한 실패는 섹션이 지나치게 빽빽해지는 것입니다.
MDN의 HTML 참고 자료는 제목, 목록, 폼, 이미지, 랜드마크와 같은 구조를 언어의 역할로 설명합니다. 최소 기준은 시맨틱 랜드마크, UTF-8과 viewport 메타 정보, 눈에 보이는 :focus 스타일, 레이블이 지정된 폼 컨트롤, WCAG AA 명암 대비입니다. 폼과 탐색 메뉴에서 키보드 탐색은 선택 사항이 아닙니다.
첫 번째 초안을 만드는 일은 쉽습니다. 진짜 테스트는 다음 프롬프트가 매번 다른 레이아웃을 다시 생성하는 대신 동일한 문서에서 팔레트, 간격, 콘텐츠를 유지한 채 업데이트되는지입니다.
HTML을 어디에 둘 수 있는지 물어보세요. 답이 “이 호스트, 이 프레임워크, 이 결제 요금제 안에서”라면 플랫폼을 구매하는 것입니다. 답이 “어떤 브라우저, 어떤 정적 호스트, 나중에는 어떤 CMS에서도”라면 마크업을 구매하는 것입니다.
작업에 따라 차원별 가중치를 다르게 적용하세요. 고객에게 전달할 이력서나 청구서라면 컴포넌트 라이브러리보다 이식성과 인쇄용 CSS가 중요합니다. 이미 Vercel에서 운영 중인 Next.js 마케팅 사이트라면 HTML 파일로서는 더 부족하더라도 v0의 React 출력이 더 짧은 경로가 될 수 있습니다.
가장 먼저 살펴볼 차이는 무엇을 출력하는가입니다. HTML 생성기는 독립형 HTML 문서를 출력합니다. v0는 React/Next.js 형태로 UI를 출력합니다. Lovable, Bolt, Replit은 애플리케이션을 출력하거나 호스팅합니다. 이들을 서로 바꿔 사용할 수 있는 “AI HTML 도구”로 취급하면 종속성이 가려집니다.
| 기능 / 차원 | Vercel의 v0 | HTML 생성기 | Lovable | Bolt | Replit |
|---|---|---|---|---|---|
| 주요 출력 | React / Next.js UI, 일부 흐름에서는 HTML/CSS 컴포넌트도 제공 | CSS/JS가 내장된 독립형 HTML 파일 | 프롬프트로 생성하는 호스팅형 풀스택 앱 | 프롬프트로 생성하는 호스팅형 풀스택 앱 | 전체 앱을 위한 클라우드 IDE + Agent |
| 빌드 / 내보내기 | 일반적으로 일반 HTML이 되려면 정적 내보내기(npm run build)가 필요함 | 모든 브라우저에서 열림, 빌드 단계 없음 | 플랫폼 미리보기 및 호스팅 | 플랫폼 미리보기 및 호스팅 | 플랫폼 내 실행 및 배포 |
| 디자인 규칙 | Tailwind CSS 및 shadcn/ui 패턴 | 유형에 맞는 레이아웃, CSS 사용자 지정 속성, 간격 체계 | 앱 빌더 UI 규칙 | 앱 빌더 UI 규칙 | 생성된 스택에 따라 다름 |
| 백엔드 / 호스팅 | 프런트엔드 중심, Vercel과 함께 사용 | 없음 — 마크업만 제공 | 에이전시 워크플로에서 기본 호스팅을 전제로 함 | 에이전시 워크플로에서 기본 호스팅을 전제로 함 | 배포, 데이터베이스, 50개 이상의 언어 |
| 요금(2026년 기준) | 무료 크레딧, 유료 요금제는 일반적으로 약 20달러의 Premium 기준으로 언급됨 | 제한된 사용량의 무료 등급, Plus 월 20달러(30배 사용량) | 무료 / Starter 월 20달러 / Pro 월 50달러 | 무료 / Pro 월 20달러 | 무료 / Core 월 25달러 / Teams 사용자당 월 40달러 |
| 가장 적합한 용도 | UI 컴포넌트를 반복 작업하는 React 팀 | 휴대 가능한 페이지, 이메일, 이력서, 청구서, 정적 사이트 | 제품 UI를 빠르게 출시하는 경우 | 빠른 풀스택 프로토타입 | 전체 개발 수명 주기 |
v0는 강력한 UI 생성기이지만 단일 파일 HTML 전문 도구는 아닙니다. 리뷰에 따르면 v0는 텍스트로 React, HTML, CSS 컴포넌트를 생성하며, 무료 등급은 월 100크레딧으로 언급됩니다. 2026년 비교 자료에서는 v0의 Premium 요금제를 약 20달러 기준으로 제시합니다.
v0의 강점은 Next.js 생태계 안에서 디자인을 코드로 변환하는 것입니다. Tailwind, shadcn/ui, 반복적인 프롬프트 개선을 활용할 수 있습니다. HTML 작업에서의 한계는 내보내기 마찰입니다. 호스팅 가이드에 따르면 v0 프로젝트를 어디에서나 실행할 수 있는 파일로 바꾸려면 일반적으로 Next.js 정적 내보내기와 out 폴더 업로드가 필요합니다. 세련된 컴포넌트를 얻을 수는 있지만, 더블 클릭으로 열리는 문서를 자동으로 얻게 되는 것은 아닙니다.
HTML 생성기는 한 가지 작업을 중심으로 만들어졌습니다. 제공된 콘텐츠를 세련되고 독립적인 HTML 파일로 변환하는 것입니다. 랜딩 페이지, 포트폴리오, 문서, 이메일, 뉴스레터, 대시보드, 폼, 프레젠테이션, 이력서, 블로그 게시물, 제품 페이지, 청구서, 이벤트 페이지 등 출력 유형을 추론하고 일반적인 템플릿이 아니라 유형에 맞는 구조를 적용합니다.
디자인 기본값을 살펴보면 앱 빌더보다는 문서 제작에 더 초점을 맞추고 있음을 알 수 있습니다. 팔레트는 제한적이며 사용자 지정 속성으로 정의됩니다. 간격은 일관된 체계를 사용합니다. 타이포그래피는 제목, 본문, 캡션을 구분합니다. 레이아웃은 모바일 우선입니다. 상호작용이 필요한 유형에만 바닐라 JS를 사용하며(탭, 모바일 탐색, 폼 검사 등), 핵심 콘텐츠는 스크립트 없이도 계속 사용할 수 있습니다.
물론 한계도 분명합니다. 앱을 호스팅하거나 데이터베이스를 연결하거나 카피 전략을 다시 작성하지는 않습니다. 일정에 따라 페이지를 다시 생성하지도 않습니다. React/Next.js를 표준으로 사용하는 팀은 컴포넌트 단위 작업에 여전히 v0를 선호할 것입니다. 파일이 아닌 시각적 캔버스를 원하는 디자이너에게는 WYSIWYG 빌더보다 덜 직관적으로 느껴질 수 있습니다.
Lovable은 AI 앱 빌더로 Bolt 및 Replit과 함께 반복적으로 묶이며, 공개된 요금은 무료 / Starter 월 20달러 / Pro 월 50달러로 제시됩니다. 에이전시 관련 글에서는 Lovable을 HTML 내보내기가 아니라 시간 단위로 측정되는 빌드 및 호스팅 워크플로로 다룹니다.
강점은 프롬프트에서 실행 중인 제품 UI까지 빠르게 도달하는 것입니다. 한계는 생성과 호스팅의 순환 구조를 구매하게 된다는 점입니다. 결과물이 이메일 템플릿이나 인쇄 가능한 청구서라면 플랫폼의 중심이 잘못된 곳에 있습니다.
Bolt는 같은 그룹에 속하며, 비교 자료에서는 무료 / Pro 월 20달러로 제시됩니다. 종속성과 미리보기 URL이 있는 세션에서 실행되는 프로토타입이 목표라면 경쟁력이 있습니다.
강점은 빠른 풀스택 스캐폴딩입니다. 한계는 출력물이 프로젝트라는 점입니다. 이식 가능하고 종속성이 없는 HTML은 기껏해야 부수적인 결과일 뿐, 제품 계약의 핵심이 아닙니다.
Replit은 이 그룹에서 가장 범위가 넓은 플랫폼입니다. 2026년 플랫폼 비교 자료에서는 Replit을 50개 이상의 언어, Agent 기반 앱 생성, 데이터베이스, 원클릭 배포를 제공하는 클라우드 IDE로 설명하며, Core는 월 25달러, Teams는 사용자당 월 40달러입니다.
강점은 HTML 생성기가 흉내 내서는 안 되는 백엔드를 포함해 실제 애플리케이션을 구축하고 호스팅할 수 있다는 점입니다. 한계는 Replit으로 시맨틱하고 인쇄에 적합한 이력서를 만드는 것이 편지지를 인쇄하기 위해 공장을 사용하는 것과 같다는 점입니다. 협업, 컴퓨팅, 배포는 필요할 때만 장점이 됩니다.
적응형 디자인 인텔리전스는 색상을 선택하기 전에 규칙을 선택함으로써 품질을 높입니다. 모든 브리프를 동일한 히어로와 카드 레이아웃으로 감싸는 대신 문서 유형에 구조를 맞춥니다. 이것이 디자인된 것처럼 보이는 마크업과 생성된 것처럼 보이는 마크업의 차이입니다.
실제로는 유형 인식이 아키텍처를 결정합니다. 랜딩 페이지에는 완전한 \u003chead\u003e가 들어갑니다. 여기에는 charset, viewport, title, 페이지를 공유할 때 필요한 공유 메타데이터가 포함됩니다. 이력서나 청구서에는 페이지 나누기와 여백이 종이에서도 유지되도록 @media print가 들어갑니다. HTML 이메일에는 Outlook과 Gmail에서 Flexbox, Grid, 사용자 지정 속성이 안정적으로 작동하지 않기 때문에 테이블 기반 레이아웃과 인라인 CSS가 사용됩니다. 대시보드에는 탭이나 모바일 탐색 메뉴가 적합할 수 있지만, 정적인 글에는 필요하지 않습니다.
그런 다음 디자인 품질은 장식이 아니라 제약에서 나옵니다.
W3Schools의 HTML 자료와 HTML.com의 초급 가이드는 여전히 태그를 입문 단계로 가르칩니다. 하지만 제작 품질은 대부분 해당 태그를 둘러싼 시스템에서 결정됩니다. 생성된 페이지를 빽빽하고 채도가 높은 “AI 스타일”과 비교하는 것이 모델이 생성한 섹션 수를 세는 것보다 더 나은 품질 보증 방법입니다.
HTML 생성기는 원시 텍스트, 브리프, 스크린샷, URL, 와이어프레임, 업로드된 이미지처럼 정리되지 않은 입력도 받아들이며, 사용자를 계속 질문하기보다 유형을 추론하도록 설계되어 있습니다. 이는 개발자가 아닌 사용자에게 도움이 됩니다. 하지만 그에 따른 한계도 있습니다. 입력한 내용을 정리할 뿐, 카피가 약하다고 알려주지는 않습니다. 레이아웃 아이디어가 아직 확정되지 않았다면 UI/UX 리뷰어의 디자인 비평이나 UI/UX 프로토타입 생성기의 목업과 함께 사용하는 것이 더 나은 순서인 경우가 많습니다.
결과물이 JavaScript 프레임워크와 독립적으로 이동해야 한다면 바닐라 HTML을 생성해야 합니다. 이메일, 인쇄물, 첨부 파일, 정적 호스팅, LMS 업로드, 또는 “이 파일을 열고 의견을 남겨 주세요”와 같은 상황이 여기에 해당합니다. 반면 결과물이 기존 Next.js 코드베이스에 들어가 컴포넌트로 유지 관리된다면 React를 생성해야 합니다.
v0의 중심은 플랫폼 비교 자료에 명확하게 드러납니다. v0는 Tailwind와 shadcn/ui를 사용한 React 및 Next.js UI를 전문으로 하며, 백엔드 개발은 처리하지 않습니다. 이는 제품 팀에는 장점입니다. 하지만 컨퍼런스 안내문 하나를 만들 때는 비용 부담이 됩니다.
다음과 같은 경우에는 바닐라 HTML이 더 적합합니다.
npm을 실행하지 않을 채용 담당자, 변호사 또는 고객에게 전달하는 경우이미 라우팅, Tailwind 기반 디자인 시스템, 배포 파이프라인을 갖추고 있다면 React/Next.js가 더 적합합니다. 그런 환경에서는 단일 HTML 파일을 JSX로 변환하는 것보다 v0 컴포넌트를 저장소에 복사하는 편이 빠릅니다. 인증, 데이터, 서버가 필요한 애플리케이션의 일부로 페이지를 만든다면 Replit이 적합합니다.
반대 의견이지만 근거에 부합하는 관점도 있습니다. 많은 “AI 웹사이트”가 문서인 척하는 앱이기 때문에 실패합니다. HTML 표준 자체의 작성 모델은 여전히 요소의 의미, 콘텐츠 모델, 문서입니다. 생성기가 프레임워크 런타임 없이 유효한 문서를 출력하지 못한다면 엄밀한 의미에서 HTML 생성기가 아닙니다.
나중에 동일한 콘텐츠의 인쇄에 충실하거나 편집 가능한 형제가 필요하다면 PDF 생성기와 Word 생성기를 사용할 수 있습니다. 두 도구는 React 앱이 문서인 척하도록 만들지 않고, HTML이 잘 처리하지 못하는 형식인 페이지 단위의 인쇄 제어와 변경 내용 추적 편집을 담당합니다.
첫 번째 프롬프트에서 출력 유형, 제약 조건, 콘텐츠를 지정하고 처음부터 다시 시작하는 대신 동일한 파일을 수정하면 제작 환경에 적합한 HTML을 얻을 수 있습니다. 대부분의 실패는 “웹사이트를 만들어 줘”처럼 작업을 구체적으로 정의하지 않아 모델이 유행하는 앱 셸을 선택하기 때문에 발생합니다.
HTML 생성기에서는 일반적으로 다음과 같은 한 번의 브리프로 작업을 진행합니다.
사용할 수 있는 마크업을 생성하는 첫 번째 프롬프트는 다음과 같습니다.
"단일 파일 HTML 이력서, 인쇄 친화적 구성, WCAG AA 명암 대비, 외부 CSS 없음. 이름: Jordan Hale. 직무: 제품 디자이너. 네이비와 따뜻한 회색 팔레트. 경력, 기술, 연락처 푸터를 포함해 주세요. 모바일 우선으로 만든 다음 데스크톱에 맞춰 주세요."
유용한 수정 프롬프트는 범위를 좁게 유지합니다.
"동일한 팔레트와 간격 체계를 유지하세요. 섹션 사이의 여백을 늘리고, 링크에 눈에 보이는 포커스 스타일을 추가하며, 사이드바가 타임라인을 가리지 않도록
@media print를 추가하세요."
이메일에서는 명시적으로 요청하지 않으면 Flexbox가 생성됩니다.
"Apple Mail, Gmail, Outlook용 HTML 이메일. 테이블 기반 레이아웃, 인라인 CSS만 사용, 최대 너비 600px, 웹 안전 글꼴. Flexbox, Grid, 사용자 지정 속성은 사용하지 마세요."
v0의 경로는 다르며 컴포넌트 워크플로로 다뤄야 합니다. UI를 설명하고 채팅으로 반복 수정한 다음, 실제로 Vercel 외부에서 실행되는 파일이 필요하다면 정적으로 내보내고 컴파일된 HTML/CSS/JS를 호스팅해야 합니다. 이 추가 빌드 단계는 Next.js 팀에는 허용할 만하지만, 청구서 한 장을 만들 때는 불필요합니다.
어떤 생성기의 HTML이든 출시하기 전 품질 점검 목록은 다음과 같습니다.
header, nav, main, footer)와 단 하나의 h1을 확인합니다:focus 표시 여부를 확인합니다HTML 생성기의 무료 등급에는 제한된 사용량이 포함되며, 유료 요금제는 월 20달러부터 시작하고 무료 제공량의 30배를 제공합니다. 이는 Bolt Pro 및 Lovable Starter와 비슷한 가격대이지만, 지출 대상은 호스팅된 앱 컴퓨팅이 아니라 문서 생성입니다.
프런트엔드 실무자들은 AI HTML이 신중한 구현자처럼 동작할 때, 즉 의미론, 간격, 제약 조건을 지킬 때 신뢰하는 경향이 있습니다. 반대로 테마 모음처럼 동작하면 신뢰하지 않습니다. 핵심적인 구분은 “AI 대 직접 코딩”이 아닙니다. 생성기가 자신이 수행하는 HTML 작업을 알고 있는지 여부입니다.
“페이지가 27인치 모니터에서 현대적으로 보이는지가 핵심이 아닙니다. 네트워크를 끄고, 뷰포트를 줄이고, 인쇄하거나, 탭 키로 이동했을 때도 파일이 여전히 문서로 남아 있는지가 중요합니다. 컴포넌트 라이브러리에서 시작하는 생성기는 첫 번째 스크린샷을 최적화합니다. 문서 유형에서 시작하는 생성기는 이메일 클라이언트, 인쇄 대화상자, 번들러를 절대 실행하지 않을 사람처럼 마지막 단계의 사용 환경을 최적화합니다.”
“팀이 플랫폼을 필요 이상으로 구매하는 경우도 많습니다. 브리프가 포트폴리오, 캠페인 랜딩 페이지 또는 청구서라면 실제 간격 체계와 시맨틱 랜드마크가 포함된 독립형 HTML 파일이 더 작고 정직한 결과물입니다. 컴포넌트로 유지 관리할 화면에는 React 생성기를 사용하고, 백엔드가 필요한 제품에는 클라우드 IDE를 사용하세요. 세 가지 모두에 하나의 추상화를 사용하면 월 25달러짜리 포장지 안에 접근성이 떨어지는
div범벅이 생깁니다.”“접근성도 조용하지만 중요한 차별점입니다. 명암 대비, 레이블, 포커스 스타일이 기본값으로 제공되면 비용이 적게 들지만, 나중에 정리하는 스프린트가 되면 비용이 커집니다. 장식용 요소를 거부하고 JavaScript를 선택 사항으로 유지하는 HTML 생성기는 데모 영상이 편집되는 방식이 아니라 실제 웹의 작동 방식에 맞춰져 있습니다.”
— Jenova 제품 팀, 문서 생성 및 프런트엔드 시스템 담당(AI Agent 설계 8년)
대부분의 AI 빌더는 접근성, 이메일, 인쇄를 별도의 출력 모드로 인코딩하지 않는 한 이러한 작업을 제대로 처리하지 못합니다. 접근성, HTML 이메일, 인쇄는 테마가 아닙니다. 같은 파일 확장자를 공유하지만 서로 호환되지 않는 레이아웃 계약입니다.
접근성. HTML의 역할은 의미와 구조를 제공하는 것입니다. WHATWG 사양은 요소를 의미론과 연결하고 사용자 에이전트가 접근성 매핑을 노출하도록 요구합니다. 레이블이 없는 입력 필드, 클릭만 가능한 div 버튼, 누락된 대체 텍스트, 포커스 링이 없는 페이지를 출력하는 생성기는 시각적 목업을 만드는 것이지 페이지를 만드는 것이 아닙니다. HTML 생성기의 명시된 기준은 WCAG AA 명암 대비, 시맨틱 HTML5, 키보드 탐색, 눈에 보이는 포커스, 적절한 레이블입니다. 이는 차별화 요소가 아니라 매번 프롬프트로 요청하지 않아도 제공되어야 하는 기본 조건입니다.
이메일 템플릿. 가장 큰 차이가 나타나는 부분입니다. 최신 CSS 레이아웃은 적합한 도구가 아닙니다. 호환 가능한 HTML 이메일에는 여전히 테이블, 인라인 CSS, 최대 너비 컨테이너, 대체 글꼴, 웹 안전 색상이 필요하며 Gmail, Outlook, Apple Mail을 기준으로 설계해야 합니다. React/Tailwind 파이프라인은 Chrome에서 완벽하게 보이더라도 Outlook에서는 무너질 수 있습니다. 생성기가 이메일에 맞춰 아키텍처를 전환하지 않는다면 이메일용으로 사용하지 마세요.
인쇄 레이아웃. 이력서, 청구서, 보고서에는 @media print가 필요합니다. 그렇지 않으면 종이를 낭비하고 콘텐츠를 숨기게 됩니다. 인쇄용 CSS는 이러한 유형에서는 핵심 요구 사항이지만 웹 대시보드에서는 불필요한 요소입니다. 유형을 인식하는 도구는 이를 자동으로 적용하지만, 일반적인 앱 빌더는 보통 그렇지 않습니다.
JavaScript 정책. 상호작용은 선택 사항이어야 합니다. 아코디언, 모바일 탐색, 유효성 검사, 다크 모드 토글, 캐러셀 등이 이에 해당합니다. 기본적으로 프레임워크 JS를 사용하는 방식은 이메일, 인쇄, 오프라인 열기와 맞지 않습니다. 바닐라 방식의 점진적 향상은 문서를 온전히 유지합니다.
종속성. 외부 글꼴과 아이콘 CDN은 정당한 이유가 있을 수 있습니다. 하지만 컴포넌트 라이브러리에 대한 숨겨진 요구 사항은 종속성입니다. 독립형 파일은 더 정직하게 실패합니다. 렌더링되지 않으면 즉시 확인할 수 있습니다.
이 비교에 포함된 어떤 도구도 모든 상황에 적합하지는 않습니다. Vercel/React 저장소 안에서는 여전히 v0가 더 적합합니다. 실제 제품을 구축하는 경우에는 Lovable, Bolt, Replit이 더 적합합니다. 결과물이 페이지 자체라면 HTML 생성기가 더 적합합니다. 즉, 구조화되고 반응형이며 다른 사람에게 전달할 수 있을 만큼 접근성을 갖추고, 요청하지 않은 프레임워크가 없는 페이지를 만들 때 적합합니다.