▲
GN⁺ 3달전 | parent | ★ favorite | on: 브라우저는 샌드박스다(simonwillison.net)
Hacker News 의견들

  • 내 링크 블로그에 올린 글임. 전체 맥락을 이해하려면 반드시 원문인 The Browser is the Sandbox를 읽어야 함

    • 링크 블로그에 그런 안내 문구를 추가하는 게 좋을 것 같음. 나도 블로그에 연도 표시와 구독 안내를 넣었는데, 그 뒤로 같은 질문 메일이 확 줄었음. 덕분에 블로깅 계속 즐겁게 하고 있음
    • 당신의 꾸준함이 정말 인상적임. HN에서 당신 이름을 안 본 주가 없을 정도임. 개인적으로 LLM 비교 글은 취향이 아니지만, 지속성이 결국 브랜드가 된 것 같음. 앞으로도 응원함

  • Google이 NaCl을 만든 이유가 바로 WebAssembly의 샌드박스 표준화로 이어졌다고 생각함. DOM, JS, CSS도 렌더링 샌드박스로 작동함. 브라우저는 기능을 제한해 통합된 사용자 경험을 제공해야 함.
    IE와 구버전 Edge가 실패한 이유도 여기에 있음. Flash, ActiveX, Java Applet, Silverlight 같은 외부 샌드박스는 모두 사라졌고, asm.js와 WebAssembly의 안정화로 웹은 훨씬 깔끔해졌음. 참고로 Flash의 ActionScript는 ECMAScript와 TypeScript 설계에도 영향을 줬음

    • 나는 ActionScript 3를 정말 좋아했음. 예전에 AS3로 chime.tv라는 비디오 애그리게이터를 만들었는데 (TechCrunch 기사), 개발 과정이 정말 즐거웠음
    • Java는 ActionScript와 관련 없음. LiveScript가 Sun/Netscape의 비즈니스 협약으로 JavaScript로 이름이 바뀐 것뿐임
    • Silverlight는 꽤 괜찮았는데, 단종된 게 아쉬움

  • webkitdirectory 속성을 처음 봤을 때 나도 놀랐음. 수년간 웹앱을 만들어왔는데 이걸 놓쳤더라. 브라우저 샌드박스는 수십억 명이 의심스러운 링크를 클릭하며 검증한 보안 모델임.
    컨테이너를 매번 새로 띄우는 것보다 훨씬 성숙한 접근임. 다만 브라우저는 시스템 호출, 바이너리 실행, 하드웨어 접근이 불가능하다는 제약이 있음. AI 코딩에는 충분하지만, 일부 작업에는 한계가 있음

    • 나는 이 방식을 에이전트형 플로우 구축에 적합하다고 봄. 원본 파일을 직접 수정하지 않고 요약, 질의응답, 새 문서 생성 등으로 확장 가능함. 로컬 LLM을 쓰면서도 안전하게 툴 호출을 제한할 수 있음
    • 같은 이유로 NPM 개발자들도 NodeJS의 불안정한 API 대신 브라우저 샌드박스에서 실행 가능한 소스 코드 프로세서를 만드는 게 좋다고 생각함

  • systemd나 Linux의 사용자 권한 시스템이 샌드박스 논의에서 거의 언급되지 않는 게 흥미로움. 사실 이들도 꽤 강력하고 저비용 격리를 제공함

    • Unix 권한 모델은 원래 시스템이 사용자를 보호하기 위한 구조였음. 프로그램이 사용자의 권한으로 실행되기 때문에, 프로그램 자체가 악의적일 수 있다는 개념이 없었음. 오늘날에는 프로그램 간 보호가 필요함. 나도 한때 앱마다 별도 유저를 두는 방식을 시도했지만, 너무 비효율적이었음. 결국 capabilities 모델이 필요함. 관련해서 xkcd 1200이 잘 설명함
    • 대부분의 사람들은 여전히 Dockerfile만 작성하고 바로 배포하는 수준이라 이런 논의가 드뭄
    • Linux 커널에는 권한 상승 취약점이 많음. 신뢰할 수 있는 소프트웨어를 격리할 때는 괜찮지만, 악성 코드에는 무력함
    • AI 에이전트를 MacOS의 제한된 사용자 계정으로 격리하는 sandvault 같은 접근이 있음. 가볍고 범용적이라 꽤 괜찮은 아이디어로 보임
    • systemd로는 브라우저 내 JavaScript의 DNS나 HTTP 요청을 막을 수 없기 때문에, 이런 논의에 포함되기 어렵다고 생각함

  • File System Access API는 웹 발전의 큰 전환점임. co-do.xyz에서는 디렉터리를 선택해 AI가 내부 파일을 안전하게 다루게 할 수 있음. 이 API 덕분에 웹앱이 진짜 생산성 도구로 자리 잡았음

    • 배포 비용은 줄지만, 브라우저에서 상태를 관리하는 건 장기적으로 불안정했음. 나도 퍼블리싱 툴을 만들다 결국 LangGraph와 Celery로 돌아갔음. 인프라 절감보다 신뢰성 확보가 더 중요했음
    • 네이티브 UI가 여전히 우위에 있는 한, 웹앱이 완전한 1급 생산성 앱이 되긴 어려움
    • Safari와 Firefox에서는 아직 이 API 기능이 지원되지 않음

  • 브라우저 기반 실행이 흥미롭지만, 대부분의 실제 비즈니스 앱은 유지보수성과 보안, 데이터 접근성 때문에 클라우드 중심으로 이동했음. 로컬 실행은 개인 생산성에는 좋지만, 주류 앱에는 한계가 있음. 예전의 AppleScript, COM, DDE 같은 데스크톱 자동화 기능이 사라진 이유도 여기에 있음

    • COM은 여전히 Windows의 주요 API 전달 메커니즘으로 살아 있음. Windows 3.x 시절 DDE를 다루던 시절이 떠오름
    • 부트스트랩된 GenAI 앱에서는 브라우저로 추론을 오프로드하는 게 경제적 필수임. GPU 비용이 너무 커서, 사용자의 하드웨어가 사실상 유일한 무료 자원임

  • 브라우저에서 가능한 두 가지를 더 소개하고 싶음

    1. webcontainer로 NodeJS 프론트엔드와 백엔드를 브라우저에서 실행 가능함 (예: bolt.diy 프로젝트)
    2. jslinux와 x86 Linux 예시로, WebAssembly 기반의 완전한 Linux 환경을 브라우저에서 돌릴 수 있음
      이론적으로는 URL 하나로 꽤 완전한 에이전트 시스템을 구현할 수 있음
    • 나는 v86 실험을 진행 중임. LLM이 이를 파일시스템과 실행 환경처럼 다루게 하는 게 목표임. 다만 v86은 인터랙티브 UI 중심이라 프로그래밍적 제어가 쉽지 않음
    • webcontainers.io는 상용 비공개 솔루션이라, 오픈소스 플랫폼과 같은 수준으로 언급하는 건 부적절하다고 생각함

  • 예전에는 Chrome에서 File System Access API로 디렉터리 읽기/쓰기 권한을 요청할 수 있었지만, 탭을 새로고침하면 권한이 사라졌음. 지금은 개선되었는지 궁금함

    • 이제 지속적 권한 부여가 가능해졌음. Chrome 개발자 블로그에 자세히 설명되어 있음
    • 데스크톱 Chrome(Ubuntu)에서는 권한이 유지되지만, Android Chrome에서는 새로고침 시 디렉터리 접근이 사라짐. MDN 문서 참고

  • 이 방식은 파일 시스템만 샌드박싱함. 하지만 사람들은 이메일, 캘린더, 채팅, 소스 코드, 재무 데이터 등에도 연결하길 원함. 파일 시스템 보안은 시작일 뿐, 전체 데이터 생태계 보안은 여전히 과제임

  • 이 접근의 한계가 궁금함. 브라우저에서 Gemini CLI를 UX 개선 버전으로 구현할 수 있을까? 로컬 도구와도 연동 가능한가?

    • 완전히 가능하다고 단정하긴 어렵지만, 대부분의 도구가 JS 기반이라 브라우저에서 상당 부분 구현 가능함. 이제는 Node API 중 브라우저에서 못 돌리는 게 거의 없음