웹 MVP 파일 저장: 선택·권한·지원 환경·완료 신호를 나누는 5가지 기준
웹 MVP 파일 저장: 선택·권한·지원 환경·완료 신호를 나누는 5가지 기준
직접 답변: 웹 MVP에서 사용자가 만든 문서나 내보내기 파일을 기기에 저장하게 하려면 “저장 기능을 표시한 상태”, “사용자가 파일 위치를 선택한 상태”, “브라우저가 쓰기 권한을 허용한 상태”, “쓰기 스트림을 닫아 저장이 끝난 상태”, “사용자가 실제 파일을 다시 열어 확인한 상태”를 분리해 기록해야 합니다. 저장 버튼이 보이거나 파일 선택창이 열렸다는 관찰 하나만으로 모든 브라우저에서 저장이 끝났다고 판단할 수는 없습니다.
Chrome 개발자 문서는 File System Access API가 사용자의 허가 뒤 로컬 파일·폴더와 상호작용할 수 있게 한다고 설명합니다. 다만 지원 범위와 브라우저 UI는 환경마다 다르며, 이 글은 웹 MVP의 저장 흐름을 검수하는 방법입니다. 서비스 출시, 사용자 증가, 데이터 보존, 보안 인증 또는 특정 브라우저 지원을 보장하지 않습니다.
저장 기능과 저장 완료를 먼저 분리합니다
웹 MVP에서 “파일을 저장했다”는 말에는 서로 다른 상태가 섞이기 쉽습니다. 어떤 팀은 다운로드 링크가 생성된 것을 저장 완료로 기록하고, 어떤 팀은 저장 대화상자가 열린 것을 권한 완료로 기록합니다. 하지만 사용자의 선택과 브라우저의 쓰기 권한, 앱의 데이터 생성, 실제 디스크 반영은 같은 신호가 아닙니다.
Chrome 개발자 문서에 따르면 파일 선택기는 보안 컨텍스트와 사용자 동작 안에서 호출되어야 합니다. 따라서 페이지가 로드된 뒤 자동으로 저장 대화상자를 띄우는 설계보다, 사용자가 내용을 확인한 뒤 명시적으로 누른 저장 행동에서 선택기를 시작하는 편이 기술 조건과 사용자 의도를 함께 확인하기 쉽습니다.
관찰한 상태: 다음 확인
저장 버튼이 보임: 클릭 뒤 실제 선택기 호출과 지원 여부
선택기가 열림: 사용자의 취소·파일명·저장 위치 선택
파일 핸들을 받음: 읽기·쓰기 권한 상태와 오류 처리
쓰기 요청을 보냄: 스트림 종료와 예외 처리
완료 메시지가 보임: 사용자가 다시 연 파일의 내용 확인
이 다섯 기록을 분리하면 개발팀은 브라우저 기능 문제를, 운영팀은 저장 안내 문제를, QA는 데이터 생성·저장 실패를 모두 “내보내기 오류”로 뭉뚱그리지 않고 해결할 수 있습니다.
기준 1: 저장 버튼보다 사용자의 명시적 행동을 확인합니다
File System Access API의 showSaveFilePicker()는 사용자가 저장할 파일 이름과 위치를 고르게 하는 진입점입니다. Chrome 개발자 문서는 이 호출이 사용자 제스처 안에서 이뤄져야 한다고 안내합니다. 저장 직전에 긴 변환이나 서버 응답을 기다리도록 만들면, 실제 저장 대화상자가 열리기 전에 사용자 동작의 맥락이 사라질 수 있습니다.
MVP에서는 “저장”을 누른 시점에 무엇을 먼저 할지 정해야 합니다. 예를 들어 견적서 PDF를 생성하는 기능이라면, 저장 위치 선택을 먼저 받고 그 다음 파일 내용을 생성할지, 생성 실패 가능성을 먼저 사용자에게 알려 둘지 검토합니다. 어느 순서를 택하든 선택기 표시 실패, 사용자 취소, 생성 실패, 쓰기 실패를 하나의 성공 안내로 표시하지 않는 것이 중요합니다.
지원 여부도 저장 화면이 열렸을 때가 아니라 기능 진입 전에 확인합니다. Chrome 문서는 관심 있는 picker 메서드가 존재하는지로 기능 감지를 예시합니다. 이 검사는 “이 환경에서 API가 감지됨”을 기록하는 용도이며, 사용자 권한이나 파일 저장 성공을 대신하지 않습니다. 감지되지 않는 환경에는 일반 다운로드나 서버 저장처럼 서비스가 실제로 제공하는 대체 경로만 안내하고, 제공하지 않는 경로를 가능한 것처럼 쓰지 않습니다.
우리 웹 MVP의 파일 저장 흐름과 대체 경로 점검하기
기준 2: 선택한 파일과 쓰기 권한을 같은 상태로 보지 않습니다
사용자가 파일 선택기에서 위치를 정하면 앱은 파일 핸들을 받을 수 있습니다. 그러나 기존 파일을 바꾸거나 새 내용을 쓰는 단계에서는 쓰기 권한을 별도로 확인해야 할 수 있습니다. Chrome 개발자 문서는 createWritable() 호출 때 쓰기 권한을 확인하며, 허용되지 않으면 예외가 발생할 수 있다고 설명합니다.
따라서 “사용자가 파일을 골랐으니 저장된다”라고 가정하지 말고, 읽기와 읽기·쓰기 권한을 나눠서 기록하세요. WICG File System Access 명세도 권한 모드를 read와 readwrite로 구분합니다. 이 구분은 법률 고지나 보안 인증의 결론이 아니라, 화면에서 받아야 할 동의와 앱이 수행하려는 동작의 범위를 같은 말로 오해하지 않기 위한 구현·QA 기준입니다.
파일·폴더 핸들을 IndexedDB에 보관해 다음 세션에 다시 쓰는 설계도 별도 검수 대상입니다. Chrome 개발자 문서는 권한이 세션 사이에 항상 유지되는 것은 아니므로 queryPermission()으로 상태를 확인하고 필요하면 requestPermission()을 호출하라고 안내합니다. 지난번에 열렸던 폴더가 보인다는 관찰과 지금 이 사용자가 다시 쓰기를 허용했다는 사실은 다릅니다.
기준 3: 쓰기 요청과 디스크 반영을 분리합니다
파일 핸들을 받았다고 해서 데이터가 자동으로 저장되지는 않습니다. Chrome 개발자 문서의 기본 흐름은 파일 핸들에서 createWritable()을 얻고, write()로 내용을 보낸 뒤 close()로 스트림을 닫는 방식입니다. 이 문서는 스트림을 닫기 전에는 변경 내용이 디스크에 기록되지 않는다고 설명합니다.
그래서 MVP의 완료 토스트는 버튼 클릭 직후보다, 쓰기와 종료가 모두 끝난 시점에 표시하는 편이 정확합니다. 저장 중 브라우저가 닫히거나 앱이 예외를 받았을 때는 “저장됨” 메시지를 남기기보다 실패 또는 상태 미확인을 분리하세요. 파일 크기나 해시 같은 값을 보여 주려면 그 값이 실제로 언제 계산됐는지와 어떤 파일에 대응하는지도 확인해야 합니다.
다음 간단한 QA 기록을 남길 수 있습니다.
지원 감지 결과와 검사한 브라우저·기기 조건을 기록합니다.
저장 버튼 클릭 뒤 선택기가 열렸는지와 취소 경로를 확인합니다.
파일명·확장자·허용 형식이 현재 기능 목적과 맞는지 확인합니다.
쓰기 권한 거절·예외 시 사용자에게 보이는 안내와 데이터 보존 상태를 확인합니다.
close()뒤 파일을 다시 열어 예상한 내용인지 확인하고, 확인하지 못한 환경은 미확인으로 남깁니다.
기준 4: API 지원과 대체 경로를 같은 제품 범위로 쓰지 않습니다
Chrome 개발자 문서는 File System Access API를 완전히 폴리필할 수 없다고 설명합니다. 파일 열기는 , 새 파일 저장은 download 링크, 폴더 선택은 비표준 webkitdirectory로 일부 근사할 수 있지만, 동일한 권한·덮어쓰기·폴더 동작을 제공한다고 볼 수는 없습니다.
이 차이는 사업계획이나 출시 문구에도 영향을 줍니다. “문서를 기기에 저장할 수 있다”라는 기능 설명에는 어떤 브라우저·기기에서 어떤 저장 방식을 제공하는지, 기존 파일을 덮어쓸 수 있는지, 다운로드만 가능한지, 사용자가 저장 위치를 선택하는지 같은 범위를 붙이는 편이 안전합니다. 지원하지 않는 환경에서 서버에 자동 보관된다고 추정하거나, 다운로드가 로컬 파일 편집 권한과 같다고 표현하면 실제 사용 경험과 어긋날 수 있습니다.
파일을 브라우저에 올려 검토하는 흐름이 함께 있다면 앱 MVP 문서 업로드: 파일 선택·검증·실패 안내를 나누는 5가지 기준도 참고할 수 있습니다. 연결 글은 사용자가 파일을 서비스에 제공하는 입력 단계에 집중하고, 이 글은 웹 MVP가 사용자가 선택한 기기 위치로 결과물을 저장하는 단계에 집중합니다.
기준 5: 저장 기능을 성과나 보안 수준의 증명으로 연결하지 않습니다
저장 흐름이 매끄럽다는 것은 특정 조건에서 파일 선택·권한·쓰기·완료 안내를 검수했다는 기술적 관찰입니다. 그것만으로 고객 데이터가 안전하게 보존됐다는 결론, 규제 충족, 사용자 이탈 감소, 재방문 증가, 매출 효과를 도출할 수는 없습니다. 저장 시점, 실패율, 재다운로드, 실제 파일 열람, 동의된 분석 이벤트와 사업 성과는 서로 다른 데이터입니다.
초기 팀은 구현 여부·관찰 조건·알려진 예외·대체 경로·재검증 담당자를 한 표로 남기면 좋습니다. 이는 특정 브라우저 API를 반드시 도입하라는 권고가 아니라, 웹 MVP에서 파일 저장을 사용자 선택과 실제 완료까지 검증 가능한 작업으로 나누는 방법입니다.
자주 묻는 질문
저장 대화상자가 열리면 파일 저장이 끝난 건가요?
아닙니다. 대화상자가 열렸다는 것은 사용자가 파일 위치를 선택할 수 있는 단계에 들어갔다는 관찰입니다. 사용자의 선택, 쓰기 권한, 앱의 쓰기 처리, 스트림 종료, 다시 열어 본 파일 내용은 따로 확인해야 합니다.
저장 버튼을 페이지가 열리자마자 자동 실행해도 되나요?
Chrome 개발자 문서는 파일 선택기 호출에 사용자 제스처와 보안 컨텍스트가 필요하다고 안내합니다. 대상 브라우저의 실제 동작을 확인하되, 사용자가 명시적으로 저장을 요청한 행동에서 선택기를 시작하도록 설계하는 편이 조건과 의도를 함께 확인하기 쉽습니다.
지난번에 고른 폴더를 다음 실행에도 바로 쓸 수 있나요?
파일·폴더 핸들을 저장하는 설계는 가능하지만, 권한은 세션 사이에 항상 유지되는 것이 아닐 수 있습니다. 다시 사용할 때는 현재 권한 상태를 확인하고, 필요한 경우 사용자에게 다시 허용을 요청하는 흐름을 검수하세요.
이 기능이 있으면 모든 브라우저에서 같은 저장 경험을 제공하나요?
그렇지 않습니다. File System Access API의 지원과 대체 경로는 브라우저·기기마다 다를 수 있습니다. 기능 감지, 실제 저장 시험, 미지원 환경의 대체 경로를 각각 기록하고 확인하지 못한 환경을 같은 결과로 추정하지 마세요.