우연히 Filesystem Driver를 만들었어요. 브라우저용으로. 🤔
Source: Dev.to
문제 개요
데이터가 사라졌다. 오류도, 경고도, 스택 트레이스도 없이—그냥 사라졌다.
당신의 앱은 File System Access API를 사용해 파일을 쓴다. 몇 년 만에 가장 흥미로운 브라우저 기능 중 하나다. 사용자가 폴더를 선택하고, 서버 없이도 깨끗하고 네이티브하게 쓰기를 수행한다. 꿈이 아닌가?
하지만 모바일에서는 그 꿈이 조용히 사라지는 경우가 많다.
- 브라우저 프로세스가 백그라운드에서 종료된다(메모리가 부족할 때 안드로이드에서 흔히 발생).
- 이때 쓰기 가능한 스트림이 쓰기 중간에 있다.
- 오류가 발생하지 않으며, 쓰기가 단순히 완료되지 않는다.
실패 유형
- 프로세스 종료 – OS가 프로세스를 종료하고, 진행 중이던 쓰기가 사라진다.
- 핸들 만료 – 앱을 다시 열었지만, 이전에 얻은 파일 핸들이 이제는 오래되어 사용할 수 없다.
- 동시 쓰기 – 여러 쓰기를 동시에 수행하면 File System Access API가 경쟁 상태에 빠진다; 대부분이 조용히 실패하는데, 이는 API가 작업을 순차화하지 않기 때문이다.
세 가지 실패 모두 조용히 발생하며 데이터 손실을 초래한다.
해결책
모바일 브라우저를 위한 작은 내구성 레이어로 각 실패 유형을 해결했다:
- 선행 기록 버퍼 – 파일 시스템에 도달하기 전에 데이터를 큐에 저장한다.
- 파일명별 큐 – 같은 파일에 대한 쓰기가 순차적으로 이루어지도록 보장한다.
- IndexedDB 폴백 선반 – 파일 시스템을 사용할 수 없을 때 대기 중인 쓰기를 안전하게 저장한다.
- 복구 메커니즘 – 다음에 앱이 깨울 때 보관된 쓰기를 재실행한다.
이 구성 요소들을 합치면 선행 기록 로그(WAL) 시스템이 된다. 이는 PostgreSQL이 충돌 복구를 위해 사용하는 방식과 유사하지만, 브라우저 탭 안에서 구현된 것이다.
고찰: 브라우저를 운영 체제로 보기
이러한 문제들—쓰기 순서, 프로세스 수명 주기, I/O 내구성, 충돌 복구—는 전통적으로 OS 수준에서 해결되며, 웹 앱에서는 다루지 않는다. 불편한 진실은 브라우저가 이미 OS처럼 동작한다는 것이다:
- 프로세스 관리자가 있다(탭 수명 주기, 백그라운드 종료 정책).
- 자체 파일 시스템, 영구 저장소, 연산 파이프라인, 프로세스 격리를 제공한다.
대부분의 프레임워크는 여전히 브라우저를 서버 위의 단순 UI 레이어로 취급하지만, 플랫폼은 조용히 진화했다. Electron, Tauri, Capacitor와 같은 래퍼는 새로운 기능을 추가하기보다 브라우저가 이미 제공하는 OS와 유사한 기능을 노출할 뿐이다.
개발자에게 주는 의미
우리는 전환기의 순간에 있다. 브라우저 런타임은 1급 OS가 될 만큼 강력하지만, 많은 개발자는 여전히 이를 단순히 뷰 레이어로만 생각하고 개발한다. 이를 인식한 개발자는 브라우저 위에 직접 파일 시스템 드라이버, 프로세스 관리자, 내구성 레이어와 같은 시스템 서비스를 구축할 수 있다.
Gnoke Suite는 브라우저 안이 아니라 브라우저 그 자체로 실행되는 시스템 레이어를 제공하는 것을 목표로 한다. 이 미묘한 변화는 웹 기반 애플리케이션을 설계하는 방식을 바꿀 수 있다.
코드 보기
브라우저 파일 시스템 드라이버의 실용적인 구현을 보고 싶다면 다음을 확인하세요:
피드백 요청
조용한 쓰기 실패, 핸들 만료, 모바일 프로세스 종료와 같은 유사한 문제를 겪었다면 댓글에 경험을 공유해 주세요. 많은 사람들이 이 문제를 겪었지만, 이에 대해 글을 쓴 사람은 적다고 생각한다.