▲

브라우저는 샌드박스다

 (simonwillison.net)
1P by GN⁺ 7일전 | ★ favorite | 댓글 1개
  • 웹 플랫폼 개발자 Paul Kinlan은 코딩 에이전트를 위한 안전한 실행 환경으로서 브라우저의 가능성을 탐구함
  • 그는 브라우저가 이미 신뢰할 수 없는 코드를 실행하기 위한 강력한 샌드박스 구조를 갖추고 있다고 지적함
  • 이를 검증하기 위해 Co-do라는 데모를 제작, 브라우저 내에서 파일 접근·네트워크 통신·코드 실행을 모두 실험함
  • Co-do는 File System Access API, CSP 헤더와 <iframe sandbox> , WebAssembly in Web Workers를 활용함
  • 브라우저가 로컬 컨테이너 없이도 AI 에이전트 실행 환경으로 발전할 수 있음을 보여주는 사례임

브라우저를 샌드박스로 보는 관점

  • Google의 Paul Kinlan은 코딩 에이전트의 실행을 위해 강력한 샌드박스 환경이 필요하다고 판단함
    • 그는 브라우저가 지난 30년간 악성 코드나 신뢰할 수 없는 코드를 안전하게 실행하기 위해 발전해온 플랫폼임을 강조함
    • 이러한 특성이 에이전트 실행 환경으로서 브라우저를 활용할 수 있는 근거가 됨

브라우저 기반 샌드박스의 세 가지 핵심 요소

  • Kinlan은 샌드박스의 세 가지 핵심 요소로 파일 시스템 접근, 네트워크 접근 제어, 안전한 코드 실행을 제시함
    • File System Access API는 브라우저에서 로컬 파일을 다루는 기능을 제공하며, 현재는 Chrome 전용으로 알려짐
    • CSP(Content Security Policy) 헤더와 <iframe sandbox> 속성을 통해 네트워크 접근을 제어할 수 있음
    • WebAssembly와 Web Workers를 이용하면 격리된 환경에서 코드를 실행할 수 있음

Co-do 데모의 구성과 기능

  • Kinlan의 아이디어를 검증하기 위해 Co-do라는 데모 애플리케이션이 제작됨
    • 사용자는 폴더를 선택하고 LLM 제공자와 API 키를 설정함
    • Co-do는 CSP 승인 API 호출을 통해 LLM과 상호작용하며, 파일과 대화할 수 있는 채팅 인터페이스를 제공함
    • 이 구조는 Claude Cowork와 유사하지만, 대용량 로컬 컨테이너 없이 브라우저만으로 실행됨

<iframe sandbox>와 보안 기술의 한계

  • <iframe sandbox>의 문서화 부족이 주요 문제로 지적됨
    • 브라우저별 구현 차이가 크며, 관련 자료가 부족함
    • Kinlan은 이중 iframe(double-iframe) 기법을 통해 내부 프레임에 네트워크 규칙을 적용하는 방법을 제시함

추가 발견 및 실험

  • <input type="file" webkitdirectory> 속성이 Firefox, Safari, Chrome 모두에서 작동함이 확인됨
    • 이를 통해 브라우저가 전체 디렉터리의 읽기 전용 접근을 수행할 수 있음
    • 이를 시험하기 위해 webkitdirectory 데모가 제작되었으며, 향후 프로젝트에서도 활용 예정임

결론

  • 브라우저는 이미 보안 격리와 코드 실행을 위한 완성도 높은 플랫폼으로 발전해 있음
  • Co-do 사례는 브라우저가 AI 코딩 에이전트의 실행 환경으로 확장될 수 있음을 보여주는 실험적 증거임
▲
GN⁺ 7일전  [-]
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 중 브라우저에서 못 돌리는 게 거의 없음
답변달기