프레젠테이션 한 벌이 HTML 파일 하나에 담긴다는 것 — 단일 파일 로컬 우선 웹앱은 클라우드 문서 스위트에 도전하는가
프레젠테이션 한 벌이 HTML 파일 하나에 담긴다는 것 — 단일 파일 로컬 우선 웹앱은 클라우드 문서 스위트에 도전하는가
클라우드 문서 스위트의 시대는 560KB 짜리 HTML 파일 하나에 도전받는가, 아니면 중앙 관리와 협업의 편의 앞에 다시 무너지는가.
도입 — 618 점, 그리고 파일 하나
2026 년 7 월, Hacker News 의 첫 페이지 맨 위를 AI 가 아닌 프로젝트 하나가 차지했다. 제목은 “Show HN: Bento — An entire PowerPoint in one HTML file (edit+view+data+collab)”. 618 점을 받으며 그날 AI 를 제외한 스토리 가운데 1 위에 올랐다. 요즘 HN 의 상단은 대개 모델과 에이전트가 점거하는 자리다. 그 자리를 비집고 올라온 것이 “PowerPoint 한 벌을 HTML 파일 하나에 담았다” 는, 언뜻 소박해 보이는 도구였다는 사실 자체가 이 사건의 성격을 말해 준다.
Bento 가 표방하는 것은 단순하다. 편집, 뷰어, 애니메이션, 데이터 관리, 인쇄, 그리고 실시간 협업까지 — 프레젠테이션 도구가 하는 일 전부를 약 560KB 크기의 HTML 파일 단 하나에 담았다는 것이다. 클라우드 로그인이 필요 없고, 최초 로드 이후에는 오프라인에서 동작하며, 이메일에 첨부하거나 파일 전송으로 그대로 건네줄 수 있다. 이 글은 Bento 라는 특정 제품의 리뷰가 아니다. 618 점이 실제로 반응한 대상 — 단일 파일, 로컬 우선(local-first) 웹 애플리케이션이라는 패턴 — 을 렌즈 삼아, 지난 십수 년 산업을 지배해 온 클라우드 문서 스위트가 자기 완결적이고 데이터를 소유하며 오프라인에서 동작하는 문서에 정말로 도전받고 있는지를 묻는다.
현상 — Bento 는 무엇이고 왜 화제인가
기술적 실체부터 정확히 보자. Bento 는 하나의 .html 파일이다. 브라우저에서 그 파일을 열면, 슬라이드를 만들고 고치는 에디터가 뜨고, 발표 모드로 넘기면 애니메이션이 붙은 뷰어가 되며, 표와 데이터를 다루는 기능과 인쇄 출력까지 그 안에 들어 있다. 별도의 설치 과정이 없고, 계정을 만들 필요가 없으며, 서버에 문서를 업로드하지도 않는다. 문서는 파일 그 자체다. 이 구조가 주는 가장 직접적인 효용은 배포 마찰의 소거다. 설치 안내도, 로그인 화면도, “이 링크에 접근 권한이 없습니다” 도 없다. 파일을 건네면 받은 쪽은 브라우저로 열기만 하면 된다.
여기에 화제성을 더한 지점이 두 가지다. 첫째는 실시간 협업이다. 순수한 로컬 파일이 어떻게 여러 명의 동시 편집을 지원하느냐는 당연한 의문에 대해, Bento 는 암호화된 릴레이(encrypted relay) 를 통한 협업 편집을 제시한다. 즉 협업이 필요한 순간에만 암호화된 중계 경로로 편집 내용을 주고받고, 그 외에는 파일이 자기 안에서 완결된다. 둘째는 에이전트 통합이다. Bento 는 Claude Code 와 연동되어 기존 슬라이드 덱을 변환하도록 설계되었다고 소개한다. 사람이 만든 덱을 코딩 에이전트가 읽고 고치고 재구성하는 대상이 될 수 있다는 뜻이다. 문서가 곧 파일이고, 파일이 곧 에이전트가 다룰 수 있는 텍스트 자산이라는 점이 여기서 매끄럽게 이어진다.
Show HN 스레드의 반응은 대체로 뜨거웠다. 환영의 정서를 몇 갈래로 요약하면 이렇다(이하 특정 문장 인용이 아니라 스레드 전반의 공기를 요약한 것이다). 단일 파일 배포가 설치 마찰을 없앤다는 점, 데이터를 자기 손에 쥐는 로컬 우선 소유권과 벤더 종속(lock-in) 의 부재, 최초 로드 이후 오프라인에서도 동작한다는 점, 그리고 “내가 필요한 모든 것이 파일 하나에 다 들어 있다는 사실이 만족스럽고, 동료와 에이전트에게 건네기 쉽다” 는 감각이 반복해서 등장했다. 특히 마지막 대목은 이 도구가 겨냥한 시장의 정서를 압축한다. SaaS 벤더가 버그를 고쳐 주지 않거나 우리가 원하는 기능을 넣어 주지 않아 지친 팀들에게, 파일 하나로 완결되는 도구는 오래 비어 있던 자리를 채워 준다는 것이다.
이 반응의 무게중심은 “프레젠테이션 도구가 하나 더 나왔다” 가 아니었다. 그것은 배포와 소유의 형태에 대한 반응이었다. 문서가 클라우드 계정에 매인 레코드가 아니라 손에 쥘 수 있는 파일로 돌아왔다는 것 — 618 점은 대체로 그 지점에 던져진 표였다.
심층 — 로컬 우선이라는 오래된 이상과 새 계산서
Bento 가 새로 발명한 것은 없다. 정확히 말하면, 그것이 잘한 일은 두 개의 오래된 계보를 하나의 실용적 산물로 합류시킨 것이다. 그 계보를 짚어야 이 반응의 크기를 이해할 수 있다.
첫째 계보는 단일 파일 HTML 애플리케이션의 역사다. 이 아이디어의 정전(正典)은 TiddlyWiki 다. 2004 년 Jeremy Ruston 이 만든 이 개인 위키는, 자기 자신을 저장할 수 있는 하나의 HTML 파일이라는 발상을 대중화했다. 애플리케이션과 그것이 담은 데이터가 같은 파일 안에 공존하고, 그 파일을 복사하면 프로그램과 데이터가 통째로 복제된다. 서버도, 데이터베이스도, 계정도 없이 문서가 스스로 완결되는 이 형태는 이후 이십여 년간 소수의 열렬한 지지자를 거느려 왔다. 최근에는 SQLite 를 WebAssembly 로 컴파일해 브라우저 안에서 데이터베이스째 돌리는 단일 파일 앱들이 그 계보를 현대적으로 잇고 있다. Bento 는 이 오래된 형식을, 가장 흔하고 가장 지겹도록 SaaS 화된 대상 — 프레젠테이션 — 에 적용했다.
둘째 계보는 로컬 우선 소프트웨어(local-first software) 운동이다. 2019 년 Ink & Switch 의 Martin Kleppmann, Adam Wiggins, Peter van Hardenberg, Mark McGranaghan 이 발표한 에세이 “Local-first software: You own your data, in spite of the cloud” 는 이 흐름에 이름과 강령을 주었다. 그들이 제시한 일곱 가지 이상은 다음과 같다. 네트워크 왕복 없이 즉각 반응할 것(빠름), 여러 기기에서 데이터가 동기화될 것(멀티 디바이스), 네트워크 없이도 읽고 쓸 수 있을 것(오프라인), 여러 사용자가 동시에 협업할 수 있을 것(협업), 벤더가 사업을 접어도 데이터가 살아남을 것(장수), 종단 간 암호화로 프라이버시가 지켜질 것(프라이버시), 그리고 벤더가 사용자의 접근과 사용을 제약할 수 없을 것(사용자 통제). 이 목록을 Bento 의 소개 문구 옆에 나란히 놓으면 겹침이 명료하게 드러난다. 오프라인 동작, 로그인 불요, 파일 소유, 이메일 첨부로의 이동성 — Bento 는 이 강령의 상당 부분을 프레젠테이션이라는 좁은 영역에서 구현해 보인 사례다.
로컬 우선 운동이 오래 씨름해 온 가장 어려운 항목은 “오프라인” 과 “협업” 의 동시 충족이다. 서버가 진실의 단일 원천(single source of truth) 이 아니라면, 각자 오프라인에서 편집한 결과를 나중에 충돌 없이 합치는 문제가 생긴다. 이 문제의 표준적 해법이 CRDT(Conflict-free Replicated Data Type) 다. Automerge(Ink & Switch 계열) 나 Yjs(Kevin Jahns) 같은 라이브러리는, 여러 복제본이 각자 독립적으로 변경된 뒤에도 수학적으로 같은 상태로 수렴하도록 병합을 정의한다. Bento 의 암호화된 릴레이가 내부적으로 어떤 병합 전략을 쓰는지 공개된 사실만으로는 단정할 수 없다[가정]. 다만 분명한 것은, “파일 하나가 오프라인으로 완결되면서 동시에 실시간 협업도 한다” 는 약속이 공짜가 아니라는 점이다. 그 약속을 지키려면 릴레이든 CRDT 든 어떤 형태의 협업 기반 구조가 파일 바깥에 있어야 한다. 그리고 바로 이 지점이 이 패턴의 이상과 현실이 갈라지는 첫 균열이다.
균열을 정직하게 이름 붙이는 편이 이 도구를 존중하는 길이다. 스레드에서 제기된 비판은 크게 세 갈래였다. 첫째, 협업의 실제 사용감이다. 여러 명이 동시에 편집할 때 텍스트 필드에서 포커스가 튕겨 나가는 문제가 보고되었다. 로컬 우선 협업이 흔히 부딪히는 커서·선택·포커스 동기화의 난제가 여기서도 그대로 드러난 셈이다. 둘째, 브라우저별 성능이다. Firefox 에서 애니메이션이 끊기거나 느리다는 지적이 있었다. 단일 파일 안에 모든 렌더링과 애니메이션 로직을 담는 구조는 엔진별 최적화 편차에 그대로 노출된다. 셋째, 확장성의 한계다. 여러 사용자가 Bento 를 Reveal.js 와 비교했다. Reveal.js 는 Mermaid.js 같은 임의의 라이브러리를 슬라이드에 끼워 넣기 쉽고, 무엇보다 수직 슬라이드(vertical slides) — 하나의 주제를 아래로 깊게 분기시켜 청중에 따라 보여 줄 내용을 달리하는 구조 — 를 지원한다. 그 수직 슬라이드가 Reveal.js 의 가장 강력한 기능 중 하나인데, 단일 파일로 봉인된 Bento 에서는 임의 라이브러리 임베드가 어렵고 그런 분기 구조를 잃었다는 아쉬움이 나왔다(이상은 직접 인용이 아니라 스레드에 흐른 정서를 요약한 것이다).
가장 뼈아픈 비판은 마지막 하나다. “아무것도 외부로 통신하지 않는다” 는 취지의 약속에도 불구하고, Cloudflare 비컨(beacon) 이 관측되었다는 지적이 나왔다. 이것은 사소한 트집이 아니라 이 패턴의 정체성을 건드리는 긴장이다. 로컬 우선 도구가 파는 것은 기능이 아니라 신뢰 — “당신의 데이터는 당신의 것이고, 이 파일은 몰래 어디로도 연락하지 않는다” 는 신뢰 — 이기 때문이다. 그 신뢰의 표면에 예상치 못한 외부 통신 한 줄이 관측되는 순간, 단일 파일 로컬 우선의 세일즈 포인트 전체가 흔들린다. 제작자가 이 불일치를 인지하고 조사에 나섰다는 점은 건강한 대응이지만, 사건 자체는 중요한 교훈을 남긴다. “아무것도 통신하지 않음” 은 마케팅 문구가 아니라 검증 가능한 속성이어야 하며, 분석 비컨 한 줄, 폰트 CDN 하나, 텔레메트리 한 조각이 그 속성을 조용히 무너뜨릴 수 있다는 것이다. 로컬 우선을 표방하는 도구는 이 속성을 사용자가 직접 확인할 수 있게 — 네트워크 탭을 열면 아무 요청도 없도록 — 만들어야 그 약속이 강령이 아니라 사실이 된다.
전망 — 단일 파일이 이기는 자리, 클라우드가 이기는 자리
그렇다면 실무자와 팀에게 이 패턴은 무엇을 의미하는가. 유혹적인 결론은 “SaaS 는 끝났고 파일이 돌아온다” 는 것이겠지만, 그 결론은 트레이드오프의 절반만 본 것이다. 판단의 축은 “파일이냐 클라우드냐” 라는 취향의 문제가 아니라, 문서의 수명·통제·규모라는 세 좌표 위에서 결정된다.
단일 파일 로컬 우선이 명백히 이기는 자리부터 보자. 상호작용이 일회적이거나 수명이 짧은 문서 — 한 번 발표하고 마는 덱, 클라이언트에게 그대로 건네는 제안서, 저장소에 커밋해 버전 관리하고 싶은 기술 슬라이드 — 에서 이 패턴은 순수한 이득이다. 계정도 권한 설정도 없이 파일을 건네면 끝이고, 받는 쪽은 십 년 뒤에 열어도 같은 파일이 같은 결과를 낸다(장수 이상의 실현). 오프라인이 기본값이어야 하는 환경 — 비행기, 보안 격리망, 네트워크가 불안정한 현장 — 에서도 강하다. 그리고 결정적으로, 문서가 파일이라는 것은 그것이 코딩 에이전트가 읽고 고칠 수 있는 텍스트 자산이 된다는 뜻이다. Bento 가 Claude Code 연동을 앞세운 것은 우연이 아니다. 문서를 클라우드 API 뒤에 숨은 불투명한 레코드가 아니라 손에 쥔 파일로 되돌리는 순간, 그것은 사람과 에이전트 양쪽 모두에게 직접 조작 가능한 대상이 된다. 이것이 이 패턴이 지금 이 시점에 반향을 일으킨 진짜 이유다. 에이전트의 시대에는 “파일” 이 다시 일급 시민이 된다.
반대로 클라우드 문서 스위트가 이기는 자리도 분명하다. 애초에 조직들이 Google Workspace 와 Microsoft 365 로 옮겨 간 이유는 편집 기능이 뛰어나서가 아니라, 파일이 흩어질 때 생기는 문제들을 중앙에서 풀어 주기 때문이었다. 누가 무엇에 접근할 수 있는지 관리하는 접근 제어, 퇴사자의 문서를 회수하는 계정 관리, “3 주 전 버전으로 되돌려 달라” 를 처리하는 서버 측 버전 관리, 감사 로그, 규정 준수(compliance), 그리고 수천 명이 같은 문서 체계를 공유할 때 필요한 거버넌스. 단일 파일 모델은 이 전부를 사용자에게 되돌려 주는 대신, 그 관리 부담도 함께 되돌려 준다. 파일이 이메일과 파일 전송으로 자유롭게 복제된다는 것은 곧, 어느 것이 최신본인지, 누가 그 사본을 가졌는지, 유출된 사본을 어떻게 회수할지가 통제 불가능해진다는 뜻이기도 하다. 소유와 이동성의 이면은 확산과 파편화다.
그래서 세 가지 시나리오를 나란히 두는 편이 정직하다. 낙관적으로 보면, CRDT 기반 로컬 우선 협업이 성숙하고 브라우저 성능이 고르게 올라오면서, 개인과 소규모 팀의 문서가 대거 파일로 회귀한다 — 클라우드는 진짜로 중앙 거버넌스가 필요한 조직 문서에만 남는다. 비관적으로 보면, 협업의 사용감(포커스 튐, 병합 충돌), 브라우저 편차(Firefox 성능), 그리고 “정말 아무것도 통신하지 않는가” 라는 신뢰 문제가 발목을 잡아, 단일 파일 도구는 다시 소수 애호가의 취미로 남고 대중은 편의 앞에 클라우드로 되돌아간다 — 십수 년 전 데스크톱 앱이 그랬듯이. 현실적으로 가장 그럴듯한 것은 이분법이 아니라 병존이다. 문서의 성격에 따라 파일과 클라우드가 나뉘고, 그 사이를 잇는 “로컬 우선이되 선택적으로 동기화되는” 하이브리드 — 파일로도 존재하고 필요할 때 암호화 릴레이나 CRDT 로 합쳐지는 형태 — 가 표준이 된다. Bento 의 암호화된 릴레이는 이미 그 하이브리드의 초기 형태다.
결론 — 파일 하나가 던진 질문
리드 질문으로 돌아가자. 클라우드 문서 스위트의 시대는 560KB 짜리 HTML 파일 하나에 도전받는가. 정직한 답은 “도전받되, 아직 무너지지 않는다” 이다. Bento 가 받은 618 점은 클라우드에 대한 반란표라기보다, 문서가 다시 손에 쥘 수 있는 것이었으면 좋겠다는 오래된 갈망의 표출이다. 그 갈망은 진짜이고 정당하다. TiddlyWiki 가 이십 년 전 증명했고, 로컬 우선 강령이 강령으로 정리했으며, 이제 에이전트의 시대가 “파일” 을 다시 일급 시민으로 끌어올리면서 그 갈망에 새 동력을 주고 있다.
그러나 단일 파일 모델이 클라우드를 대체하려면, 그것이 포기한 것들 — 중앙 관리, 서버 측 버전 관리, 접근 제어, 규모의 거버넌스 — 을 조직이 감당할 수 있는 형태로 되돌려 주거나, 애초에 그것들이 필요 없는 영역에 자신을 한정해야 한다. 그리고 무엇보다, “아무것도 통신하지 않는다” 는 약속을 마케팅이 아니라 검증 가능한 사실로 지켜야 한다. Cloudflare 비컨 한 줄에 흔들린 신뢰가 그 조건의 무게를 증명한다.
결국 이 사건이 남긴 것은 승패의 판정이 아니라 축의 재발견이다. 데이터 소유·이동성·오프라인 대(對) 협업·중앙 관리·규모 — 이 오래된 트레이드오프의 진자가, 클라우드 십수 년 뒤에 다시 파일 쪽으로 한 번 튀었다. 파일 하나가 던진 질문은 “클라우드를 버릴 것인가” 가 아니다. 그것은 “우리가 편의의 대가로 무엇을 클라우드에 넘겼는지, 그리고 그중 무엇을 파일로 되찾고 싶은지” 를 각자의 문서마다 다시 계산해 보라는 요구다. 그 계산서는 문서마다 다르게 나온다. 그 다름을 인정하는 것이 이 진자를 이해하는 유일한 방법이다.
출처: