html.to vs Google Sites —
페이지 빌더 vs 즉시 공유

Google Sites는 드래그&드롭으로 팀 위키나 사내 포털을 만드는 도구다. Google Workspace 계정만 있으면 무료로 쓸 수 있고, Drive·Docs·Sheets와 자연스럽게 연결된다. 조직 내부용 정보 허브를 빠르게 세우는 데는 충분하다.

html.to는 다른 문제를 푼다. ChatGPT·Claude·Cursor 같은 AI 도구가 뽑아낸 HTML 파일을 — 계정도, 호스팅 설정도 없이 — 30초 안에 공유 링크로 바꾼다. 페이지를 만드는 도구가 아니라, 이미 만들어진 HTML을 전달하는 도구다. 두 서비스가 겹쳐 보여도 풀려는 문제가 전혀 다르다.

한눈에 비교

Google Sites이 잘하는 것

팀 포털, 사내 wiki, 프로젝트 문서 허브를 세울 때 Google Sites는 여전히 합리적인 선택이다. Google Workspace를 이미 쓰는 조직이라면 별도 비용 없이 Drive 파일을 페이지에 직접 임베드하고, Docs로 내용을 편집하며, 구성원 권한을 Google 계정 단위로 관리할 수 있다.

빌더 인터페이스가 직관적이어서 개발 지식 없는 팀원도 페이지 구조를 바꾸고 섹션을 추가할 수 있다. 지속적으로 갱신되는 팀 내부 문서, 온보딩 가이드, 정기 보고용 대시보드처럼 계속 편집해야 하는 콘텐츠에 잘 맞는다.

html.to가 더 나은 상황

다음 세 상황 중 하나라면 Google Sites는 적합한 선택지가 아니다.

• AI가 만든 HTML을 바로 보내야 할 때. Claude Artifacts나 ChatGPT가 뽑아낸 .html 파일에는 <script> 태그와 인라인 JS가 가득하다. Google Sites는 이 코드를 실행하지 않는다. html.to는 코드를 그대로 렌더링해 AI가 의도한 인터랙션까지 온전히 전달한다.
• 계정 없이 익명으로 공유해야 할 때. 외부 클라이언트나 행사 참가자에게 결과물을 보내는 상황에서 Google 계정 생성을 요구하면 마찰이 생긴다. html.to는 보내는 사람도, 받는 사람도 계정이 없어도 된다. 링크만 클릭하면 브라우저에서 바로 열린다.
• 링크에 비밀번호를 걸어야 할 때. 초안 검토, 내부 프리뷰, 가격표처럼 특정 수신자만 봐야 하는 HTML이라면 AES-256-GCM으로 암호화된 비밀번호를 링크에 붙일 수 있다. Google Sites의 공개/비공개 토글은 Google 계정 단위로만 통제되어 이런 유스케이스를 커버하지 못한다.

선택 기준

만들어야 한다면 Google Sites. 이미 만들어진 HTML을 전달해야 한다면 html.to.

결정 기준은 단순하다. 드래그&드롭으로 페이지를 구성하는 행위가 필요한가, 아니면 손에 쥔 HTML 파일을 링크로 바꾸는 행위가 필요한가.

Google Sites는 페이지 빌더다. 텍스트 블록을 배치하고, 이미지를 넣고, Google Drive 파일을 임베드하는 편집 인터페이스가 핵심이다. 반면 html.to는 편집 기능이 없다. 코드를 붙여넣거나 파일을 드롭하면 즉시 링크가 나온다. 이 차이가 두 서비스의 사용 맥락을 갈라놓는다.

AI 도구를 쓰는 기획자나 개발자가 시제품을 클라이언트에게 보내는 상황, Cursor가 만든 컴포넌트 데모를 팀에 공유하는 상황, 비밀번호로 보호된 가격표를 링크로 전달하는 상황 — 이 세 시나리오에서 Google Sites는 답이 아니다. 설치도, 가입도, 호스팅 설정도 없이 30초 안에 끝내야 한다면 html.to로 온다.