html.to vs Glitch
— 서비스 종료 이후 최선의 대안

Glitch는 오랫동안 개발자와 교육자들이 애용하던 플랫폼이었다. Node.js 앱을 브라우저에서 바로 포크하고, 수업용 프로토타입을 URL 하나로 나눠줄 수 있었다. 그런 편의가 2025년 7월 8일에 끝났다. 서비스가 완전히 종료됐고, 기존에 올려뒀던 프로젝트도, 공유 링크도 더 이상 작동하지 않는다.

반면 html.to는 처음부터 목표가 달랐다. 서버 사이드 런타임이 아니라 단일 HTML 파일의 즉시 공유에 집중한다. ChatGPT나 Claude가 만들어준 HTML을 붙여넣으면 30초 안에 링크가 생긴다. 계정도, 저장소도, 빌드 파이프라인도 없다. Glitch를 쓰던 이유가 "URL 하나로 결과물을 보여주는 것"이었다면, html.to가 그 자리를 채운다.

기능 비교

Glitch이 잘하는 것

솔직하게 적는다. Glitch는 HTML 파일 하나를 공유하는 도구가 아니었다. Node.js, Express, SQLite까지 돌릴 수 있는 풀스택 샌드박스였다. 수업 시간에 학생들이 교수의 프로젝트를 "Remix" 버튼 하나로 포크해 자기 버전을 만드는 경험은 탁월했다. 서버 사이드 로직이 필요한 프로토타입, 외부 API를 호출하는 데모, 실시간 코드 협업 — 이 영역에서 Glitch는 독보적이었다.

그 기능들은 이제 모두 사라졌다. 회고의 의미 외에는 선택지가 되지 못한다.

html.to가 더 나은 상황

• AI가 만든 HTML을 즉시 공유해야 할 때. ChatGPT나 Claude Artifacts에서 생성된 HTML 코드를 복사해 붙여넣으면 끝이다. 렌더링 결과를 확인하고 SHARE를 누르면 30초 안에 링크가 생긴다. 받는 사람은 클릭 한 번으로 브라우저에서 결과를 본다.
• 민감한 내용을 담은 HTML을 보호해야 할 때. 클라이언트용 제안서, 사내 기획안, 초안 단계의 UI — 공개하고 싶지 않은 파일에 비밀번호를 걸 수 있다. AES-256-GCM 암호화로 처리되고, 서버는 평문을 보지 못한다.
• 개발 환경 없이 결과물을 전달해야 할 때. 기획자, 디자이너, 비개발자도 html.to를 쓴다. 코드 에디터도, GitHub 계정도, 터미널도 필요 없다. .html 파일을 드래그해 올리거나 코드를 붙여넣으면 그게 전부다.

선택 기준

Glitch는 더 이상 선택지가 아니다. 결정 기준은 단순해진다. 필요한 게 서버 사이드 런타임과 데이터베이스까지 갖춘 풀스택 샌드박스라면, Replit이나 CodeSandbox 같은 다른 플랫폼을 봐야 한다. 그쪽은 설정도 많고 계정도 필요하다.

필요한 게 HTML 파일 하나를 URL로 바꾸는 것이라면, html.to가 지금 당장 쓸 수 있는 선택지다. AI 도구가 만들어준 결과물을 링크로 전달하고, 원하면 비밀번호까지 걸고, 계정 없이 무료로 — 그게 전부다.

Glitch가 사라진 빈자리를 모두 채울 단일 서비스는 없다.
하지만 "링크 하나로 HTML을 보여준다"는 역할에서, html.to는 지금 작동한다.