--- title: "파비콘 안에 웹사이트를 숨겨 넣은 개발자, 진짜 됨" published: 2026-06-20T05:33:59.000Z canonical: https://jeff.news/article/4186 --- # 파비콘 안에 웹사이트를 숨겨 넣은 개발자, 진짜 됨 한 개발자가 웹사이트의 파비콘 이미지를 작은 저장소처럼 사용해 HTML을 픽셀 RGB 값 안에 넣고, 브라우저에서 다시 읽어 렌더링하는 실험을 했다. 208바이트짜리 HTML payload에 4바이트 길이 헤더를 붙여 총 212바이트를 만들었고, 이를 9x9 픽셀 PNG 안에 87% 사용률로 저장했다. - 어떤 개발자가 파비콘 안에 웹사이트 내용을 숨겨 넣는 실험을 함 - 파비콘은 브라우저 탭에 뜨는 작은 아이콘임 - 그런데 결국 파비콘도 이미지이고, 이미지는 픽셀이고, 픽셀은 바이트라는 식으로 접근함 - 결론부터 말하면 됐음. 실용성은 별로 없지만 꽤 개발자스러운 장난임 - 핵심 아이디어는 HTML을 픽셀의 RGB 값에 직접 밀어 넣는 것 - 픽셀 하나에는 빨강, 초록, 파랑 값이 있고 각각 1바이트로 볼 수 있음 - 그러면 픽셀 하나에 총 3바이트를 저장할 수 있음 - 브라우저 입장에서는 그냥 색상값인데, 만든 사람 입장에서는 그게 HTML 바이트가 되는 셈임 - 저장 과정은 생각보다 단순함 - 먼저 작은 HTML payload를 `TextEncoder`로 UTF-8 바이트 배열로 바꿈 - 그 앞에 payload 길이를 나타내는 4바이트 헤더를 붙임 - 길이 헤더가 필요한 이유는 이미지 끝에 남는 빈 픽셀이 있을 수 있어서, 실제 데이터가 어디서 끝나는지 알아야 하기 때문임 - 이후 바이트를 순서대로 첫 픽셀의 R, G, B 채널에 넣고 다음 픽셀로 넘어감 > [!IMPORTANT] > 실험에 쓰인 HTML payload는 208바이트였고, 4바이트 길이 헤더까지 합쳐 총 212바이트였음. 픽셀당 3바이트를 저장하니 9x9 픽셀, 즉 81픽셀짜리 이미지면 충분했음. - 최종 파비콘은 그냥 노이즈 이미지처럼 보임 - 212바이트를 담기 위해 필요한 픽셀은 71개 - 정사각형 이미지로 만들려면 최소 9x9 픽셀이 필요함 - 9x9 이미지는 총 81픽셀이라 용량은 239바이트 수준이고, 실제 사용률은 87%였다고 함 - 흔한 파비콘보다도 작은 이미지 안에 작은 HTML 문서가 들어간 셈임 - 읽어오는 쪽도 브라우저 기본 기능만으로 처리함 - 파비콘을 이미지로 로드함 - 이미지를 캔버스에 그림 - Canvas API로 픽셀 데이터를 읽음 - RGB 값을 다시 바이트 배열로 재구성함 - 앞의 4바이트에서 payload 길이를 읽고, 그 길이만큼 잘라 UTF-8 텍스트로 디코딩함 ```mermaid sequenceDiagram participant 파비콘 participant 브라우저 participant 캔버스 participant 자바스크립트 participant 문서 브라우저->>파비콘: 이미지로 로드 브라우저->>캔버스: 파비콘 그리기 자바스크립트->>캔버스: 픽셀 RGB 값 읽기 자바스크립트->>자바스크립트: 바이트 배열과 길이 헤더 복원 자바스크립트->>문서: HTML로 디코딩해 렌더링 ``` - 중요한 단서는 ‘파비콘만으로 웹사이트가 완성되는 건 아니다’라는 점임 - 파비콘에는 웹사이트의 내용, 즉 HTML payload가 들어 있음 - 하지만 그걸 읽어서 복원할 자바스크립트 부트스트랩 로더는 별도로 필요함 - 데모에서는 `Render Website` 버튼을 누르면 파비콘을 읽고, HTML을 디코딩한 뒤, 현재 페이지를 복원된 내용으로 바꾸는 방식임 - 대안도 몇 가지 있음 - SVG 파비콘 안에 마크업을 직접 넣고 페이지 로드시 읽는 방식 - PNG의 `tEXt`, `zTXt`, `iTXt` 같은 comment chunk를 쓰는 방식 - 여러 해상도의 아이콘을 담을 수 있는 ICO 포맷을 활용하는 방식 - 다만 이 글의 재미는 그런 정석 저장 공간이 아니라 RGB 픽셀을 억지 저장소로 쓴 데 있음 - 실용성은 거의 없음 - 저장 가능한 데이터가 너무 작음 - 어차피 복원용 자바스크립트가 필요함 - 작은 HTML 문서를 배포하는 더 좋은 방법은 이미 널림 - 그래도 웹 플랫폼이 어디까지 말이 되는지 찔러보는 실험으로는 꽤 맛있음 --- ## 기술 맥락 - 이 실험의 선택은 “파비콘을 저장소로 쓴다”는 거예요. 파비콘은 원래 아이콘이지만, 브라우저가 결국 이미지 파일로 로드하니까 픽셀 RGB 값을 데이터 슬롯처럼 다룰 수 있거든요. - 왜 굳이 RGB 채널이냐면 구현이 제일 직관적이기 때문이에요. HTML 문자열을 UTF-8 바이트로 바꾸고, 그 바이트를 R, G, B 순서로 넣으면 별도 포맷 설계 없이도 데이터를 이미지 안에 심을 수 있어요. - 길이 헤더 4바이트를 앞에 붙인 것도 꽤 중요한 결정이에요. 9x9 이미지는 81픽셀이라 총 239바이트를 담을 수 있지만 실제 payload는 208바이트라 빈 공간이 남거든요. 어디까지가 진짜 HTML인지 모르면 디코딩 결과가 깨질 수 있어요. - 복원 단계에서 Canvas API를 쓴 이유는 브라우저 안에서 이미지 픽셀을 직접 읽을 수 있는 표준적인 방법이기 때문이에요. 파비콘을 캔버스에 그리고 RGB 값을 다시 바이트 배열로 만들면, 서버나 네이티브 코드 없이도 원래 HTML을 되살릴 수 있어요. - 다만 이건 배포 기술이라기보다 경계 실험에 가까워요. 파비콘에 내용은 들어가지만 실행을 시작할 로더는 별도로 필요해서, ‘웹사이트 전체가 파비콘 하나에 들어갔다’기보다는 ‘웹사이트 콘텐츠를 파비콘 픽셀에 숨겼다’가 더 정확해요. ## 핵심 포인트 - HTML 바이트를 PNG 픽셀의 RGB 채널에 직접 기록해 파비콘을 데이터 저장소처럼 사용했다 - payload 208바이트와 4바이트 길이 헤더를 합쳐 212바이트를 저장했고, 9x9 픽셀 이미지면 충분했다 - 브라우저는 파비콘을 이미지로 로드하고 canvas API로 픽셀을 읽어 원래 HTML을 복원했다 - 다만 자바스크립트 부트스트랩 로더가 필요해서 파비콘 하나만으로 완전한 웹사이트가 되는 건 아니다 ## 인사이트 쓸모는 거의 없지만 웹 플랫폼의 경계가 어디까지 열려 있는지 보여주는 꽤 재밌는 실험이다. 특히 ‘이미지는 픽셀이고 픽셀은 바이트’라는 단순한 관찰이 브라우저 API와 만나면 이런 장난도 실제 구현이 된다.