24P by GN⁺ 3일전 | ★ favorite | 댓글 6개
  • Hyperclay는 모든 UI, 로직, 데이터가 하나의 HTML 파일에 통합되는 방식의 웹앱 제작을 지원함
  • 파일 자체에서 변경 즉시 즉각적인 수정 및 실시간 공유가 가능하며, 앱의 외형과 동작, 편집 방식까지 직접 제어할 수 있음
  • 별도의 빌드·배포 과정, 데이터베이스 또는 복잡한 백엔드 없이 즉시 실행·저장 구조를 제공함
  • HTML 파일 하나만으로 브라우저, 서버, 오프라인 등 어디서나 앱을 실행하고, 모든 변경사항이 버전 관리 및 복구됨
  • 현대 웹 개발의 복잡성을 줄이고, 실시간으로 살아 있는 인터랙티브 앱을 누구나 쉽게 만들 수 있게 설계함

소개: HTML 파일 하나로 만드는 살아 있는 웹앱, Hyperclay

  • Hyperclay는 프로그래머가 복잡한 인프라 관리 없이, 하나의 이식 가능한 HTML 파일로 제품을 빚듯 웹앱을 만드는 경험을 제공함
  • 기존 웹 개발에서 필수였던 설정 파일, 빌드, 프레임워크, 배포 파이프라인 등을 없애고, 파일 한 개만으로 완결되는 구조를 목표로 함

핵심 컨셉 및 장점

  • 앱이 하나의 HTML 파일로 구성
  • 시각적 UI를 통해 파일 자체를 실시간으로 편집할 수 있고, 이 편집 내용이 바로 앱의 상태로 영구 저장
  • UI, 로직, 데이터가 모두 한 파일 안에 동적으로 포함되어 있음
  • 사용자는 문서처럼 앱을 즉시 수정하고, 변경사항을 바로 공유·다운로드하여 오프라인 사용도 가능함
  • "Google Docs for interactive code"라는 비유처럼, 공유와 수정, 소유권 제어가 자유로움

주요 기능 요약

  • 직접 조작: 앱이 실행되는 동안 바로 편집 가능함. 컴파일, 새로고침 없이 변경이 즉시 반영됨
  • What you see is what you build: UI를 수정하거나 소스 코드를 직접 편집하면 곧바로 앱이 바뀌며 중간 계층 없음
  • 진정한 이식성: 앱을 HTML 파일로 내보내어 어디에서나(서버·오프라인) 동일하게 실행 가능함. 모든 저장시 버전 관리가 적용되어 복구 가능함
  • 이 모든 것이 특별한 기술 없이, 오직 표준 HTML 파일 한 개로 이루어짐

기술적 구조

  • Hyperclay는 NodeJS 서버와 클라이언트 측 JS 라이브러리로 구성됨
  • HTML 페이지가 자체적으로 DOM을 수정하면, 변경된 document.body.outerHTML을 서버에 보내고, 이 HTML 파일 자체가 갱신됨
  • 체크박스의 checked 속성 등 앱 내의 변경 사항이 영구적으로 HTML 코드에 저장되어, 다음 접속에서도 동일한 상태를 재현할 수 있음
  • 버전 관리읽기/쓰기 권한 관리 지원

실제 예시

  • 직접 편집 가능한 블로그, 근무 시간 체크리스트 등 모든 앱을 HTML 한 파일로 작성 및 저장 가능함
  • contenteditable 속성이나, <input type="checkbox" persist> 형태로 바로 앱의 상태를 문서에 기록함

배경 및 문제의식

  • 매년 수십 개의 웹사이트를 제작하며, 웹앱 코딩이 글쓰기만큼 자연스러웠으면 하는 니즈가 있었음
  • 전통적인 정적 웹사이트는 변경사항이 휘발적임(사용자 행위가 저장되지 않음)
  • 데이터 영속성을 웹에 구현하려면, 데이터베이스·API·템플릿·계정 시스템 구축 등 과도한 작업이 필요함
  • 프로토타입, 간단한 도구, 개인 개발 로그, 블로깅 등 빠르게 만들고 실시간으로 수정, 공유하고 싶은 요구에 비효율적임

Hyperclay의 해결 방식

  • HTML 한 파일에 UI·상태·동작이 통합됨
  • 마치 데스크탑 앱을 여는 것처럼 손쉽게 열고 곧바로 수정, 결과를 온라인에 바로 반영 가능함
  • 영속적(shared, cloneable, persistent)인 디지털 오브젝트 개념을 제시함
  • 웹사이트 빌더, 문서·도표·프레젠테이션 툴, 대시보드, 블로그, 설문·퀴즈 제작, 데이터 시각화 등 다양한 도구에 적용 가능함

전체 개념 요약

  • 웹앱 대부분은 이미 HTML을 사용함
  • 중간 단계를 생략하면 HTML 파일이 전체 데이터베이스/ API/ UI 역할을 하여, 스택이 단 몇 줄로 단순화됨
  • 개발자는 복잡성을 줄이고, 최소한의 코드로도 사용성과 유지관리가 우수한 앱을 만들 수 있음

Hyperclay 사용 예시

  • 블로그, 체크리스트 등 어떤 앱이든 단 한 개 HTML로 작성·배포·공유·편집 가능함
  • <div contenteditable>내 블로그!</div> 형태로 바로 사용 가능, <input type="checkbox" persist>로 각 상태가 문서에 영구 기록됨

결론

  • Hyperclay는 웹 개발의 번거로움 없이, 누구나 가볍고 이식성이 뛰어난 인터랙티브 웹앱을 제작하고, 실시간으로 공유·저장·복구할 수 있는 새로운 방법을 제시함
  • 개발자, 디자이너 뿐 아니라 누구든 쉽게 사용할 수 있는 차세대 웹앱 플랫폼

이거 예전에 널리고 널렸던 웹 에디터들과 동작 원리가 유사하지만 html 파일 하나만으로도 된다는 게 흥미롭군요. 개인적으론 이것도 일종의 Proof-of-Concept인것 같기도 하지만 솔직히 이걸 잘만 활용한다면 어떻게 될련지 궁금하기도 합니다.

이거 동작 방식이 그냥 https://news.hada.io/topic?id=19611 과거 올라왔던 에디터 동작방식하고 동일한데요? 여기에 저도 서버에서 셀프호스팅을 위해 nodejs로 간단한 백엔드 붙여서 에디터로 작성한 post 저장하게 하고, index.html 에 목록 불러와서 보여주는 기능 2개 붙여서 간단한 블로그 게시판으로 쓰는데 둘러보니 동일한 느낌인데요

재미있네요!
보안이 어떨라나 궁금하네요.

흥미로운 아이디어네요. tiddlyWIki도 재밌었는데

Hacker News 의견
  • Hyperclay는 NodeJS 서버와 프론트엔드 JS 라이브러리를 통해 HTML 페이지가 DOM을 업데이트하고, 변경된 .html 소스를 교체해서 페이지를 지속적으로 최신 상태로 유지할 수 있음
    예를 들어 체크박스를 클릭하면 checked 속성이 추가되고, 이 상태의 document.body.outerHTML을 Hyperclay로 전역에 저장해서 다음 방문 때 그대로 반영됨
    자동 버전 관리와 읽기/쓰기 권한 관리도 지원함
    개발자와 콘텐츠 편집자 역할이 동일할 때 가장 유용하다고 생각함, 여러 편집자가 동시에 사용하면 서로 변경사항을 덮어쓸 수 있어서
  • 만약 NodeJS 서버가 필수라면 완전히 self-contained HTML 파일만으로는 불가능한 것 같아 혼란스러움
  • 이 내용을 홈페이지에 그대로 추가했음
    참고로 개발자가 fork한 모든 앱에 "DOM 기반 스키마 마이그레이션"을 푸시할 수 있는 방법을 구현 중임
  • TiddlyWiki가 영감을 줬다고 들었는데, TiddlyWiki의 핵심은 서버가 필요 없는 구조 아니었는지 궁금함
    실제로 간단한 웹앱 만들다 보면 서버가 필요하게 되는 지점이 오긴 하는데, 서버 없는 접근방식과 서버 결합이 약간 모순처럼 느껴짐
    그래도 장점이라면 크로스 디바이스 접근성 향상이고, 온라인 편집이 쉬울 것 같음
    나의 경우 텍스트 에디터에서 휴대폰으로 편집하고 동기화앱으로 랩탑에 싱크함
  • 웹 표준이 file:// 프로토콜로 실행되는 로컬 파일 페이지에서 더 나은 지원을 해줬으면 좋겠음
    단순한 HTML/Vue 미니앱을 만들 때마다 여러 문제가 생겨 항상 우회 방법을 찾아야 했음
    예를 들어 로컬 HTML 파일이 로컬 JS 모듈 임포트가 안되거나, 다른 로컬 파일(오디오 등) 열기가 불가능함
    무분별한 접근을 막기 위해 제한이 필요한 건 이해하지만, 특정 확장자나 디렉터리 명시로 허용해주는 방식이 있으면 좋겠음
    매번 웹 서버를 띄우는 게 너무 번거롭고 과하게 느껴져서, 그냥 URL만 입력하면 바로 앱이 실행되는 게 이상적임
    • 생성기 타입 웹앱에서 큰 제약은 HTTPS로 로드된 페이지만이 클립보드 API를 사용할 수 있어서, file:///에서는 복사 기능이 동작하지 않음
      빌드·의존성 없는 완전 오프라인 앱도 이 한계 때문에 버튼 대신 텍스트 영역으로 대체해야 해서 번거로움
      로컬 서버 구동엔 VS Code devcontainer를 활용하면 자동으로 서버가 올라가고, 명령어 추가로 로컬에서도 HTTPS 가능함
    • 예전 Windows에는 HTA 방식이 있었는데, 확장자가 다른 HTML 파일로 브라우저 메뉴 없이 파일 시스템 접근 권한이 있었음
      보안적으로는 취약했지만, 요즘 Electron 기반으로 폴더·sqlite db 정도 접근 가능한 현대판도 쓸만할 듯
      Orca 같이 브라우저·DOM 없이 캔버스만 제공하는 wasm 앱 빌더도 대안임
    • 로컬 HTML 파일의 위험성을 이해는 하지만, 브라우저에 "오프라인 전용" 모드가 생겨서 로컬 파일시스템과 외부 페이지를 분리해 접근할 수 있으면 좋겠음
      완벽한 해결은 안 되겠지만, 간단하고 직관적으로 브라우저를 제한적 로컬 서버로 쓸 수 있어서 충분히 유용할 것 같음
    • HTML을 로컬 플랫폼으로 잠그기 시작한 것에 어느 정도 불만이 있었음
      그래도 오디오·자바스크립트 등 어느 정도는 동작하고, 웹 서버 띄우는 것도 python/node로 바로 실행되니 크게 어렵지 않음
      터미널에 "webserver_here" 명령 추가하거나 상시 유지해두면 해결
      오히려 로컬 HTML의 위험성이 커져 더 엄격한 경계를 원하게 됨
    • 최근 여기, 여기에서 비슷한 고민을 했었음
      지금은 localStorage와 수동 내보내기/가져오기만이 대안임
      Hyperclay에서 아이디어를 얻었는데, Electron Fiddle처럼 1회 설치만 하고 여러 미니앱 불러오는 일렉트론 앱 구상에 관심 있음
  • Hyperclay 기술적 구현 방식이 궁금했음
    단순히 localStorage 얘기인 건지, 아니면 FileSystemAPI로 파일을 직접 덮어쓰는 건지 등 상세 동작 원리가 설명이 부족했음
    사용자가 저장할 때 "다른 이름으로 저장" 다이얼로그 없이 자동으로 반영되는지도 궁금함
    • Hyperclay에는 두 가지 방식이 있음
      1. 호스팅: 여러 HTML 앱이 자신의 /save 엔드포인트를 호출해 HTML을 저장하고 덮어씌움(백업·버전관리 제공)
      2. 로컬: 오픈소스 Hyperclay Local(링크)을 내려받아 개인적으로 운영, 역시 /save 엔드포인트를 호출해 백업 가능, 직접 서버에 커스터마이즈해 호스팅 가능(auth만 구현하면 됨)
    • 글쎄, 이걸 한 단계 더 나가면 서버 구문 추가한 PHP, WordPress와 본질적으로 닮지 않음?
      시스템이 다중화되면서 점점 복잡해져서 실질적 개선보단 오히려 부담이 늘어나는 순환임을 느꼈음
    • "모던 웹 개발의 잡음을 무시하고 내가 원하는 경험을 만든다"라는 메시지가 짧은 텍스트와 밈 이미지 사이에 섞여있는 연출이 조금 이상하게 느껴졌음
      내가 원하는 경험은 핵심 설명과 흐름 있는 뒷이야기, 꼭 필요한 부분만의 다이어그램임
    • 서버에 DB가 있고, HTML을 저장하는 구조임
      즉 JSON(변경 내용만 따로 저장) 기반이 아니라 HTML 전체 시점마다 저장하는 느낌임
    • 이해하기로는 HTML 파일 자체가 갱신됨
      폼, 속성, 태그 등 변경 내역이 HTML 소스에 직접 반영되는 구조임
  • WWW 원래 비전에 다시 가까워지는 느낌임
    초창기 웹 브라우저(NeXT용 Tim Berners-Lee 앱)도 에디터 기능이 포함된 것이었음
    초창기 HTML 편집이 웹에서 사라진 이유는
    1. HTTP PUT 메서드가 없어서 수정된 HTML을 웹에 저장 못하고 로컬에만 저장할 수 있었음
    2. Mosaic 등 브라우저는 복잡도 등 이유로 편집 기능 제외하고 배포되면서 대중화 방향이 달라짐
    • 읽기/주석/쓰기 가능한 웹은 오래전부터 바랐던 웹의 모습임
      Hyperclay처럼 각 페이지마다 독자적인 툴킷을 만드는 것도 멋지지만, 정말 바람직한 건 브라우저(유저 에이전트) 레벨에서 어디서든 사용 가능한 표준 툴이 제공되는 거라고 생각함
    • W3C가 Amaya라는 웹 에디터를 10여년 간 유지했음
      좋은 아이디어였고 테스트베드 역할도 충실했다고 생각
      없어져서 아쉽긴 하지만, 초기 비전에 명확히 부합했음
    • TBL(팀 버너스 리) 초기 맥락에선 로컬 저장=웹 저장이었음
      대학 워크스테이션에서 NFS 등 네트워크 공유를 활용해 실질적으로 파일이 공개 저장되고 동일한 머신 주소로 접근 가능했음
      SGI 워크스테이션에서는 네트워킹 설정만 하면 완벽하게 바로 동작했음
      또한 웹의 초점은 정보를 구조화하는 데 있었고, 외형보다는 내용이 더 중요했음
      시간이 지나면서 WYSIWYG 모델과 테이블/디브 남용 등 외형에 집착하게 돼 초심이 흐려짐
      누구나 이해 가능한 단순한 설계를 하는 게 정말 어려운데, 현재는 소수 전문가 집단만 이해하는 꽤 복잡한 구조가 됐음
      HTML이 여전히 쉽게 쓸 수 있는데 현대 개발에서는 복잡한 전문 기술이 된 점을 아쉬워함
      원래 TBL이 지향한 맥락을 잘 이해하는 소수만 남은 것 같음
    • "웹 브라우저도 에디터"라는 부분에 대해
      요즘 브라우저는 다 개발자 도구를 통해 라이브로 HTML/JS/CSS 수정 가능하니 모두 에디터 아니냐고 생각하게 됨
      다들 devtools 안 쓰는 건지, vanilla JS/HTML이 아닌 React나 TS만 쓰는 건지 궁금함
      크롬·파이어폭스·사파리 계열은 모두 브라우저 내장 IDE 수준 기능을 제공하니 직접 코딩도 가능함
  • Hyperclay를 확인해보니 DOM(가상 DOM)을 활용하는 구조인 것 같음
    Shopify 스타일의 정책 및 법적인 안내도 좀 추가되면 더 좋겠음
    내 HN 프로필을 보면 왜 이게 멋지다고 생각하지만 법적 부분이 필요하다고 느끼는지 알 수 있음
  • 게임 세이브 파일에도 비슷한 방법을 시도해본 경험이 있음
    첫 번째 줄은 <!DOCTYPE html><html><head><script>const rawData = 형태, 두 번째 줄엔 전체 상태를 담음
    저장 버튼을 누르면 document.documentElement.outerHTML을 받아 최신 상태로 두 번째 줄을 바꿔서 다운로드함
    서버 없이도 동작함
    관련 코드
    • 크롬에서 아래 data: URL 북마크를 만들어 탭 하나에 메모장 스타일 에디터를 띄워두고, 탭만 안 닫으면 state가 유지됨
      data:text/html,<html><head><title>Notepad</title><style>html,body{margin:0;padding:0;}textarea{padding:10px;font-family:Courier;font-size:16px;height:100%;width:100%;border:none;outline:none;}</style></head><body><textarea style="height:100%;width:100%;font-size:16px;padding:10px;"></textarea><script>document.getElementsByTagName('textarea')[0].focus()</script></body></html>  
      
    • 나도 비슷하게, 단일 HTML 파일로 동작하는 게임을 만듦
      텍스트 수정 후 새로운 로컬 버전으로 저장 가능
      안드로이드+Brave 브라우저에서는 잘 되는데, iOS+Safari에서는 지원이 안 됨
  • TiddlyWiki도 이 분야의 20년 이상 역사를 가진 툴임
    Hyperclay는 다중 사용자/Multi-tenancy와 DB 기반 영속성에 더 중점을 두는 구조로 보임
    TiddlyWiki도 참고할 만함
  • 누군가 Windows 98 HTA 아카이브를 재발견한 듯한 프로젝트임
    HTA 위키
    • HTA는 원조 Electron 느낌임
      다만 예전 IE 환경에선 디버깅이 지옥이었음
    • HTA는 시대를 앞선 좋으면서도(동시에 끔찍한) 기술이었음
      그냥 웹페이지처럼 보이지만, IE 전용에 로컬 프로세스 실행 권한까지 있었음
      영속성 관리가 문제였고, 유사성은 매우 제한적임
    • 그 전엔 Outlook Web Access가 비슷한 역할을 했던 듯함
      Outlook on the web
    • 나도 똑같은 생각이라 댓글 달려고 했음
  • 독특한 아이디어라 생각해 언젠가 꼭 시도해보고 싶음
    사이트도 살펴보니 전체적으로 마음에 드는데, 현실적으로 제한점이 어디서 드러나는지 궁금함
    보안 측면: 내가 페이지를 바꿀 수 있다면, 다른 사람도 가능한지? 권한은 어떻게 관리하는지?
    코드량, 로직이 많아지면 관리가 어려워지는 시점이 언제인지? 데이터량 증가 시 어떻게 되는지?
    예를 들어 맥주 관리 앱을 내가 만들면, 다른 사용자가 내 데이터 없이 별도로 앱만 복사해서 사용할 수 있는지 궁금함
    • 보안: SquareSpace 등 거의 모든 웹사이트 빌더와 동일한 신뢰 모델임
      사용자가 자기 사이트를 자유롭게 바꿀 수 있음
      만약 사용자가 신뢰를 어기면 유료 계정 접근권, 그리고 남에게 손해 발생시 책임이 따름
    • 수정 권한: 앱을 만든 사람 누구나 수정 가능
      "signups" 기능 활성화 시 다른 사용자도 앱을 쉽게 fork할 수 있고, 원본으로 추적 가능
      fork 앱에 업데이트 푸시 기능도 구현 중임
    • 유지보수 난이도: NomadList의 Pieter Levels도 단일 index.php만으로 월 $60k 앱을 운영하니, 결국 코드를 어떻게 정리하느냐, 불필요한 부분을 어떻게 견디느냐에 달렸다고 생각함
    • 다른 사람들이 앱을 fork해서 자신의 데이터만 저장하도록 운영할 수 있음
      앞으로 협업 기능도 넣을 계획이지만, 지금은 1인 사용자에 가장 적합함
  • 이 아이디어가 참신하게 느껴짐
    Webstrates 프로젝트에서도 비슷한 내용을 실험하고 있음
    DOM을 지속성 계층으로 활용해 소규모 그룹용 협업 소프트웨어를 만들고 있는데, Hyperclay는 이 메커니즘을 전통적인 웹페이지에 그대로 활용한다는 차이가 있음
    최근에는 MyWebstrates처럼 로컬 우선 방식을 시도 중임
    Webworker를 활용해 Hyperclay도 오프라인 편집 지원 가능할지 궁금함
    • Clemens, Webstrates에 깊이 감명받은 사람임
      작년에 Hyperclay를 구상하면서 처음 알게 됐음
      Hyperclay의 로컬 퍼스트 버전을 정말 해보고 싶고, 오프라인 편집이 개인 소프트웨어의 기둥이라고 생각함
      혹시 비디오콜로 의견 교환 가능한지 궁금함