HTML PDF 내보내기 vs 링크 공유
— 언제 무엇을?

ChatGPT나 Claude로 HTML 결과물을 만들었다. 이걸 팀원에게, 클라이언트에게 보여야 한다. "그냥 PDF로 뽑으면 되지 않나?"라는 생각이 먼저 든다. 틀린 말은 아니다. 그런데 막상 PDF를 보낸 뒤에 "버튼이 안 눌린다", "화면이 잘렸다"는 피드백이 날아온다. PDF가 잘못된 선택이었던 것이다.

두 방식의 차이는 생각보다 명확하다. 어느 쪽을 쓸지 기준만 잡으면 고민할 시간을 아낄 수 있다.

PDF 내보내기가 적합한 상황

PDF의 본질은 인쇄용 스냅샷이다. 보는 환경이 달라도 레이아웃이 그대로 유지되고, 서명·날인을 붙이거나 공식 문서로 보관할 때 형식이 깨지지 않는다는 점이 핵심이다.

• 계약서, 견적서, 보고서처럼 인쇄 또는 파일 보관이 목적인 경우
• 수신자가 인터넷 연결 없이 오프라인에서 열어야 하는 경우
• 콘텐츠가 확정되어 수정 불가 상태로 전달해야 하는 경우
• 전자서명이나 PDF 폼 필드가 필요한 경우

HTML을 PDF로 뽑으면 JavaScript, CSS 애니메이션, 폼 인터랙션이 모두 죽는다. 페이지 구분선이 콘텐츠 중간을 잘라버리는 문제도 흔하다.

링크 공유가 적합한 상황

AI가 만들어낸 HTML 결과물의 대부분은 브라우저에서 살아 움직이는 것들이다. 클릭 가능한 버튼, 탭 전환, 차트, 폼 — 이런 요소들은 PDF로 가는 순간 껍데기만 남는다. 링크 공유는 결과물 그대로를 전달한다.

• 프로토타입, 랜딩 페이지, 대시보드처럼 인터랙션이 핵심인 결과물
• 모바일에서도 바로 확인해야 할 때 (PDF 앱이 필요 없음)
• 피드백을 받으며 반복 수정이 예상되는 경우
• 수신자에게 다운로드 부담을 주지 않고 싶을 때
• 링크를 슬랙, 카카오톡, 이메일에 바로 붙여넣어 공유할 때

한눈에 비교

링크로 공유하는 법 — html.to

링크 공유가 맞는 상황이라면, 기존 방법들은 생각보다 벽이 높다. CodePen은 계정이 필요하고 파일 드롭이 안 된다. JSFiddle은 HTML·CSS·JS를 따로 붙여넣어야 한다. GitHub Gist는 HTML을 렌더링해주지 않는다. Glitch는 2025년 7월 서비스를 종료했다. Netlify Drop은 폴더 단위 업로드만 지원한다. tiiny.host는 비밀번호 보호가 유료다.

html.to는 이 카테고리에서 무료 + 계정 불필요 + 비밀번호 보호를 동시에 제공하는 유일한 서비스다. HTML 파일을 드롭하거나 코드를 붙여넣는 것만으로 공유 링크가 나온다.

사용 순서

1. AI(ChatGPT, Claude, Gemini, Cursor 등)가 생성한 HTML 코드를 복사하거나 .html 파일을 준비한다.
2. htmlto.puzl.co.kr에 접속해 에디터에 붙여넣거나 파일을 드롭한다.
3. 렌더링된 결과를 미리 확인한다. 레이아웃이 의도대로 나오는지 체크.
4. 민감한 내용이라면 비밀번호를 설정한다. AES-256-GCM 암호화, 제로 지식 방식.
5. SHARE를 누르면 링크가 클립보드에 복사된다.
6. 슬랙, 이메일, 카카오톡 어디든 링크를 붙여넣어 전달한다.

계정 없이도 링크는 영구 보존된다. 받는 사람은 앱 설치나 로그인 없이 브라우저 하나로 결과를 본다.

실무에서 쓰는 판단 기준

두 방식 중 어느 쪽을 쓸지 모를 때는 이 질문 하나로 결정한다.

수신자가 이 파일을 프린터로 뽑거나, 서명을 붙이거나, 영구 보관해야 하는가?

"그렇다"면 PDF다. 아니라면 링크 공유가 낫다. 프로토타입 검토, 기획안 리뷰, AI 결과물 확인 — 실무에서 마주치는 대부분의 상황은 링크 공유 쪽에 해당한다.

PDF는 완성본을 공식 채널로 보낼 때 쓴다. 링크는 살아있는 결과물을 빠르게 공유할 때 쓴다. 두 방식을 섞어 쓰되, 상황에 맞는 도구를 선택하면 된다.