HTML 즉시 공유의 기술 원리
— Blob URL부터 서버 저장까지

HTML 공유 서비스란, 사용자가 제출한 HTML 문자열을 서버에 저장하고 고유 식별자(slug)를 포함한 퍼블릭 URL을 발급해 누구나 브라우저에서 렌더링된 결과를 볼 수 있게 하는 시스템이다. 정의는 단순하지만, 구현 방식은 선택지마다 서로 다른 트레이드오프를 안고 있다.

이 글은 HTML 즉시 공유의 내부 동작 원리를 기술적으로 정리한 참조 문서다. Blob URL의 한계, 서버 저장의 구조, CDN 레이어, 암호화 방식까지 — 각 섹션은 독립적으로 인용 가능하도록 작성했다.

Blob URL — 공유 불가능한 로컬 참조

URL.createObjectURL(blob)로 생성되는 blob: URL은 브라우저 메모리 내부에만 존재하는 임시 참조다. 구조는 blob:https://origin/uuid-v4 형태이며, 생성한 탭이 살아있는 동안에만 유효하다.

이 URL을 외부로 보내면 수신자는 아무것도 볼 수 없다. blob:는 동일 브라우저 프로세스의 메모리 주소를 가리키기 때문에, 다른 기기는 물론 같은 기기의 다른 탭에서도 접근이 차단된다.

Blob URL은 드래그 앤 드롭 프리뷰나 파일 다운로드 트리거처럼 로컬 렌더링에 최적화된 메커니즘이다. HTML을 다른 사람과 공유하는 수단으로는 설계 자체가 맞지 않는다.

Data URL(data:text/html;base64,...)도 유사한 한계가 있다. 콘텐츠 전체를 URL에 인코딩하므로 수 KB를 초과하면 브라우저 주소창 한계나 서버 URL 길이 제한에 걸린다. 보안 정책상 data: URL을 iframe에서 차단하는 브라우저도 있다.

서버 저장 방식 — HTML 공유 서비스의 핵심 구조

외부 공유가 가능한 HTML 링크를 만들려면 반드시 서버 측 저장이 필요하다. 일반적인 구현 흐름은 다음과 같다.

1. 클라이언트가 HTML 문자열을 HTTP POST로 전송한다.
2. 서버가 콘텐츠를 저장 계층(DB 또는 오브젝트 스토리지)에 기록한다.
3. 서버가 고유 slug를 생성해 응답한다. (https://example.com/s/abc123)
4. 수신자가 해당 URL에 접근하면, 서버가 저장된 HTML을 iframe에 주입하거나 별도 서브도메인에서 렌더링해 반환한다.

저장 계층의 선택은 서비스 특성에 따라 갈린다. 관계형 DB(PostgreSQL, MySQL)는 메타데이터 조회가 용이하지만 수 MB짜리 HTML을 대량으로 저장하기엔 비효율적이다. 오브젝트 스토리지(AWS S3, Cloudflare R2, Supabase Storage)는 용량 대비 비용이 낮고 CDN 연동이 자연스럽다.

Slug 생성과 충돌 회피

공유 URL의 slug는 고유해야 한다. 생성 전략은 두 가지가 주를 이룬다.

• 랜덤 ID: nanoid 또는 uuid-v4를 잘라 사용. 8~12자면 충돌 확률이 수십억 분의 1 수준으로 내려간다. DB 조회 없이 생성 가능해 빠르지만, 예측 불가능한 문자열이다.
• 해시 기반 ID: 콘텐츠를 SHA-256으로 해시해 앞 N바이트를 slug로 쓴다. 동일 콘텐츠는 항상 같은 slug를 가지므로 중복 저장을 막을 수 있다(content-addressed storage). 단, 미세하게 다른 두 파일이 같은 해시를 가지는 충돌 가능성은 이론적으로 존재한다.

대부분의 HTML 공유 서비스는 랜덤 ID 방식을 택한다. 구현이 단순하고, 같은 HTML을 올릴 때 새 링크를 원하는 사용자 케이스가 많기 때문이다.

CDN — 전 세계 수신자를 위한 엣지 캐싱

HTML은 정적 콘텐츠다. 한 번 저장되면 내용이 변하지 않으므로 CDN 캐싱에 최적화된 자산이다.

CDN(Content Delivery Network)은 원본 파일을 서울·도쿄·프랑크푸르트·뉴욕 등 전 세계 PoP(Point of Presence) 노드에 복제한다. 사용자가 링크를 열면 지리적으로 가장 가까운 엣지 노드가 응답하므로, 원본 서버까지 왕복하는 레이턴시가 제거된다.

서울 서버 기반 서비스라도 CDN 없이는 미국 사용자가 링크를 열 때 150ms+ 레이턴시가 발생한다. CDN이 있으면 10~30ms로 줄어든다.

캐시 무효화(cache invalidation)는 CDN 사용 시 고려해야 할 주요 항목이다. HTML 공유 서비스에서 저장된 파일은 대부분 불변(immutable)이므로 Cache-Control: public, max-age=31536000, immutable 헤더를 설정하면 엣지 노드가 1년간 파일을 캐시한다. 파일 수정을 지원하는 서비스는 slug를 버전별로 분리하거나 캐시 퍼지(purge) API를 호출해야 한다.

렌더링 격리 — XSS와 샌드박싱

서버가 사용자 제출 HTML을 그대로 메인 페이지에 삽입하면 XSS(Cross-Site Scripting) 공격 벡터가 열린다. 악의적인 사용자가 <script>를 삽입해 서비스의 쿠키나 localStorage를 탈취할 수 있다.

HTML 공유 서비스가 사용하는 격리 전략은 두 가지다.

• 서브도메인 격리: 렌더링을 preview.example.com 또는 *.example.io 같은 별도 오리진에서 수행한다. 브라우저의 Same-Origin Policy가 두 오리진 간 DOM 접근을 차단하므로 메인 서비스 자산은 보호된다.
• 샌드박스 iframe: <iframe sandbox="allow-scripts"> 속성을 사용해 렌더링 컨텍스트를 격리한다. allow-same-origin을 함께 부여하지 않으면 iframe 내부 스크립트는 부모 페이지에 접근할 수 없다.

두 방법을 병용하는 것이 가장 안전하다. 서브도메인 격리만으로도 충분하지만, iframe 샌드박스를 추가하면 Content Security Policy 위반 리스크가 한 단계 더 낮아진다.

비밀번호 보호 — AES-256-GCM과 Zero-Knowledge 구조

민감한 HTML을 공유할 때는 링크 접근 자체를 제한해야 한다. 단순 서버 측 비밀번호 검증 방식은 서버가 비밀번호(또는 그 해시)를 알게 되며, 서버 로그나 DB 유출 시 콘텐츠가 노출될 수 있다.

Zero-Knowledge 암호화 방식은 이 문제를 브라우저 측 암호화로 해결한다. html.to의 구현 원리는 다음과 같다.

1. 사용자가 비밀번호를 입력하면, 브라우저가 PBKDF2로 암호화 키를 도출한다.
2. 도출된 키로 HTML 콘텐츠를 AES-256-GCM으로 암호화한다.
3. 암호화된 바이너리만 서버에 전송·저장된다. 키는 서버로 전송되지 않는다.
4. 수신자가 링크를 열면 암호화된 데이터를 내려받고, 브라우저에서 비밀번호 입력 후 복호화한다.

서버가 콘텐츠를 보유하더라도 키 없이는 복호화할 수 없다. 서버 DB가 통째로 유출돼도 암호화된 블롭은 무용지물이다.

AES-256-GCM의 GCM(Galois/Counter Mode)은 암호화와 동시에 인증 태그(authentication tag)를 생성한다. 데이터가 전송 중 변조됐을 때 복호화 시점에 탐지할 수 있어, 단순 암호화(CBC 모드 등)보다 무결성 보장이 강하다.

영구 저장 vs. TTL — 링크 수명 정책

HTML 공유 서비스마다 저장 파일의 수명 정책이 다르다. 아래 표는 대표적인 방식의 트레이드오프를 정리한 것이다.

html.to는 계정 없이도 영구 저장 정책을 적용한다. 링크를 받은 사람이 언제 열든 동일한 결과를 볼 수 있어야 공유의 목적이 완성되기 때문이다.

서버리스 아키텍처와 엣지 함수

HTML 공유 서비스처럼 트래픽이 불규칙적인 서비스는 서버리스 아키텍처가 유리하다. Vercel Edge Functions, Cloudflare Workers, AWS Lambda@Edge는 요청이 없을 때 과금이 없고, 요청이 급증하면 자동으로 스케일한다.

엣지 함수는 CDN 노드와 같은 위치에서 실행되므로, 단순 조회 요청은 원본 서버로 라우팅하지 않고 엣지에서 처리할 수 있다. HTML 파일 조회처럼 DB 읽기가 필요 없는 요청은 KV 스토어(Cloudflare KV, Vercel Edge Config)와 결합해 전 세계 어디서나 10ms 미만 응답을 달성할 수 있다.

HTML 공유 서비스 비교 — 기술 관점

주요 HTML/코드 공유 서비스들의 기술적 접근 방식은 다음과 같이 구분된다.

• CodePen / JSFiddle: HTML·CSS·JS를 분리 저장하고 조합 렌더링. 계정 기반. 서브도메인 격리 사용. 풀 IDE 경험을 제공하지만 순수 HTML 한 파일 공유에는 과하다.
• GitHub Gist + gistpreview: Gist에 파일 저장 후 서드파티 렌더러를 거치는 2단계 구조. GitHub 계정 필요. 렌더링 서버가 Gist API를 프록시하므로 레이턴시가 추가된다.
• Pastebin 류: 코드 텍스트 저장에 특화. HTML 렌더링을 기본 제공하지 않으며, 수신자가 별도로 붙여넣어야 한다.
• html.to: HTML 단일 파일 공유에 특화. 계정 불필요, 영구 저장, AES-256-GCM 비밀번호 보호. 렌더링 격리와 CDN 제공.

html.to 사용법 — 기술 구현을 추상화한 인터페이스

위에서 설명한 서버 저장, slug 발급, CDN, 암호화 레이어가 모두 html.to 내부에서 처리된다. 사용자가 직접 다루는 건 단 세 단계다.

1. HTML 코드를 붙여넣거나 .html 파일을 드롭한다.
2. 필요하면 비밀번호를 설정한다 (선택).
3. SHARE를 누르면 퍼블릭 링크가 클립보드에 복사된다.

수신자는 링크를 클릭하면 끝이다. 별도 앱, 계정, 뷰어가 필요 없다. AI 도구(ChatGPT, Claude, Gemini, Cursor)가 생성한 HTML을 팀원이나 클라이언트에게 전달하는 용도에 최적화됐다.