Folio 실행 패키지와 PWA

같은 Binder를 전달하는 방식은 하나가 아니다. Web 패키지는 생성된 사이트를 Folio 실행 파일 하나로 묶어 전달하고, 앱처럼 설치는 공개 사이트에 PWA manifest와 service worker를 더한다. 둘 다 Markdown source를 바꾸지 않지만 배포 위치, 접근 제어와 offline 경계는 다르다.

어떤 형식을 선택할까

필요	권장 출력	이유
파일 하나를 Windows 사용자에게 전달	Folio Web 패키지	site 결과와 viewer를 실행 파일로 묶음
비밀번호나 만료일이 있는 파일 전달	보호된 Folio 패키지	생성 시 password·expiry를 주입
URL로 공개하고 브라우저 설치 제공	Public PWA	manifest와 service worker를 제공
비밀번호가 필요한 웹 게시	보호 게시	PWA 설치는 비활성화하고 접근 제어를 우선
Android 설치 파일	현재 대상 아님	Android package는 공개 현재 기능으로 취급하지 않음

패키지는 인터넷 배포가 아니다. PWA는 데스크톱 실행 파일이 아니다. “설치 가능”이라는 공통 표현만 보고 두 결과를 같은 것으로 다루지 않는다.

공통 준비

1. 정적 사이트 artifact 만들기의 검사를 먼저 통과한다.
2. 결과에 index.html, 하위 route와 필요한 asset이 있는지 확인한다.
3. Site 제목, 언어, base URL과 공개 범위를 저장한다.
4. 출력 파일이나 공개 URL에 비밀값이 포함되지 않는지 확인한다.
5. 같은 이름의 기존 결과 파일을 보존할지 교체할지 결정한다.

패키지와 PWA는 실패한 정적 결과를 고쳐 주지 않는다. 누락된 image와 잘못된 link도 그대로 묶이므로 공통 preflight를 먼저 닫는다.

Web 패키지 화면 읽기

출력 왼쪽에서 Web 패키지를 선택하면 오른쪽에 다음 상태가 나타난다.

• 선택 대상: 현재 Binder의 site
• 상태: 설정 준비 여부
• 출력 파일: 저장된 .exe 경로
• 접근: 공개 또는 비밀번호 필요
• package 사전 확인: 실행 전에 다시 볼 경계

출력 경로 지정과 저장

1. 출력 파일에서 .exe 경로를 선택한다.
2. Binder source 폴더와 구분되는 결과 폴더를 권장한다.
3. 파일 이름에 release나 대상 이름을 포함한다.
4. 설정을 저장한다.
5. 다른 출력 항목으로 이동했다가 돌아와 경로가 유지되는지 확인한다.

출력 경로는 Binder의 source authority를 바꾸지 않는다. 경로가 저장돼도 .exe가 원본이 되는 것은 아니며, 다음 실행에서 같은 경로를 다시 사용할 수 있게 하는 설정일 뿐이다.

이번 실증에서는 .exe 확장자의 출력 경로를 저장하고 다시 읽어 동일하게 유지되는 것을 확인했다.

공개 패키지 만들기

공개 패키지는 실행할 때 별도 암호를 요구하지 않는다.

1. Site 접근 제어에서 제한없음을 선택한다.
2. 출력 경로를 확인한다.
3. package 사전 확인에서 설정 누락이 없는지 확인한다.
4. 실행 버튼을 선택한다.
5. 완료 뒤 결과 파일이 실제로 생성됐는지 확인한다.
6. 파일 크기가 viewer만 있거나 0바이트에 가까운 비정상 결과가 아닌지 확인한다.

공개 패키지는 전달이 편하지만 수신자 제한을 제공하지 않는다. 민감한 문서를 공개 모드로 묶지 않는다.

비밀번호 보호 패키지

1. 접근 제어에서 비밀번호를 선택한다.
2. 이번 실행에 사용할 값을 입력한다.
3. 출력 파일과 source 범위를 다시 확인한다.
4. 패키지를 만든다.
5. 별도의 안전한 채널로 수신자에게 비밀번호를 전달한다.

비밀번호 값은 session 입력이다. 예제 Markdown, screenshot, 로그, evidence JSON과 저장 가능한 일반 Site 설정에 평문으로 남기지 않는다. “비밀번호 사용” 상태는 기록할 수 있지만 실제 문자열은 기록하지 않는다.

만료일 적용

기간 제한을 켜면 설정한 일수를 기준으로 package 생성 시 만료일이 계산된다.

1. 기간 제한을 켠다.
2. 허용 일수를 입력한다.
3. 시스템 날짜와 timezone을 확인한다.
4. package를 만든다.
5. 생성 로그에는 원시 비밀번호 대신 기간 적용 여부와 일수만 남긴다.

만료는 source Markdown을 삭제하지 않는다. 기간이 끝나도 Binder는 남고, 새 기간으로 package를 다시 만들 수 있다. 기존 수신자에게 이미 전달한 파일을 원격으로 회수하는 기능으로 해석하지 않는다.

실제 결과 검증

최소 검사는 다음과 같다.

• .exe 파일이 선택한 경로에 있다.
• 파일 크기가 정적 site와 Folio viewer를 포함할 만큼 충분하다.
• public mode와 password mode를 혼동하지 않았다.
• 만료를 사용했다면 계산된 날짜가 의도와 같다.
• evidence나 로그에 raw password가 없다.
• package 생성 전후 Markdown 해시가 같다.

이번 자동 실증에서는 9,904,172바이트 Folio 실행 파일을 실제 생성했고 password 주입과 7일 만료 적용을 확인했다. 다만 두 번째 Windows 장치에서의 수동 실행, 잘못된 비밀번호, 만료일 이후 실행은 별도 release 수동 검증으로 남긴다.

Public PWA 만들기

PWA는 게시된 공개 사이트를 브라우저에서 설치할 수 있게 하는 web output이다.

1. Site 접근 제어를 제한없음으로 둔다.
2. 출력에서 앱처럼 설치를 선택한다.
3. PWA 사용을 켠다.
4. 앱 이름, 짧은 이름, 설명, theme color와 background color를 확인한다.
5. 정적 사이트를 다시 만든다.
6. 결과 root의 site.webmanifest와 sw.js를 확인한다.
7. HTTPS로 게시한 뒤 지원 브라우저에서 설치 진입점을 확인한다.

실증 manifest는 다음 핵심 값을 가졌다.

항목	확인 값
name	Glif 출력 실습
short_name	Glif Output
display	standalone
icons	3개
service worker	생성됨

설치와 offline의 실제 경계

PWA가 생성됐다고 모든 브라우저가 같은 설치 버튼을 보여 주지는 않는다. HTTPS, manifest 유효성, icon, service worker, browser 정책을 함께 충족해야 한다.

Glif의 PWA offline 범위는 app shell과 같은 origin의 정적 asset을 중심으로 한다. 다음을 보장한다고 해석하지 않는다.

• Binder source와 양방향 동기화
• 모든 외부 embed의 offline 재생
• 외부 API와 analytics의 offline 동작
• 설치 후 자동으로 최신 source를 보존하는 backup
• 모든 desktop·mobile browser에서 동일한 prompt

설치된 PWA도 정적 publish 결과의 한 소비 표면이다. 원본 편집은 Glif의 Binder에서 한다.

보호 게시에서 PWA를 끄는 이유

비밀번호 또는 기간 제한 웹 게시에서는 PWA 설치 surface를 공개 모드와 같은 무게로 제공하지 않는다. 보호 page와 cache 경계가 섞이면 이전 공개 asset이나 service worker가 남을 수 있기 때문이다.

Glif는 보호 게시를 감지하면 fail closed로 처리한다.

• public PWA 활성 상태를 거부한다.
• service worker를 제거한다.
• 설치용 manifest를 비활성 manifest로 바꾼다.
• display는 browser가 된다.
• icon 목록은 비운다.

이 동작은 오류가 아니라 접근 제어가 설치 편의보다 우선한다는 정책이다. 보호 사이트를 다시 public으로 바꾸면 정적 결과를 재생성하고 새 manifest·service worker를 확인한다.

전체 상호작용 보기

아래 영상은 앱 창 안에서 Web 패키지와 앱처럼 설치를 전환하고, public·password·expiry와 보호 PWA 경계를 확인하는 7.4초 실증이다.

재생성할 때의 순서

1. Markdown과 asset을 수정한다.
2. 정적 artifact를 다시 만들고 route를 검사한다.
3. package라면 기존 출력 파일의 release 이름을 확인한다.
4. password와 expiry를 이번 실행에 다시 적용한다.
5. PWA라면 public 접근 여부를 다시 판단한다.
6. manifest와 service worker가 현재 접근 정책과 맞는지 확인한다.
7. 이전 결과를 새 결과로 잘못 전달하지 않도록 해시나 release 메모를 남긴다.

예상과 다를 때

출력 경로가 비어 있다

• .exe 경로를 다시 선택하고 Site 설정을 저장한다.
• 폴더 쓰기 권한과 이미 실행 중인 같은 이름의 파일을 확인한다.
• Binder 폴더를 이동했다면 이전 절대 경로를 다시 지정한다.

패키지가 생성되지 않는다

• 정적 결과의 index.html 존재 여부를 먼저 확인한다.
• Folio runtime이 현재 release에 포함됐는지 확인한다.
• password mode인데 값이 비어 있지 않은지 확인한다.
• 만료를 켰다면 날짜 계산이 유효한지 확인한다.
• 실패한 결과를 성공 파일처럼 남기지 말고 실제 파일 크기와 수정 시각을 확인한다.

PWA 설치가 보이지 않는다

• 사이트가 public인지 확인한다.
• HTTPS와 site.webmanifest 응답을 확인한다.
• manifest의 name, icon과 display를 검사한다.
• sw.js가 같은 origin과 scope에서 등록되는지 browser 개발 도구로 확인한다.
• 보호 게시라면 설치 비활성화가 의도된 결과다.

이전 service worker가 남는다

• 보호 게시 결과에서 sw.js가 제거됐는지 확인한다.
• 브라우저의 service worker registration과 Glif PWA cache를 지운 뒤 다시 연다.
• public↔protected 전환 뒤 정적 결과를 새로 만들었는지 확인한다.

실증 범위와 남은 수동 검증

이번 시나리오는 PB-23, PB-24, PB-25, PB-26, PB-28을 다음 근거로 확인했다.

• .exe 출력 경로 저장과 재로드
• native Folio 실행 파일 생성
• raw password를 evidence에 남기지 않은 password 적용
• 7일 expiry 적용
• public manifest, icon 3개와 service worker 생성
• 보호 게시에서 protected_publish, display: browser, icon 0개와 service worker 제거
• 전체 과정 전후 Markdown source 해시 보존

다음은 이 자동 증거가 주장하지 않는다.

• 별도 Windows 장치에서 package 실행
• 잘못된 비밀번호와 만료 이후의 수동 실행 화면
• 모든 browser·운영체제의 설치 prompt
• 외부 resource를 포함한 완전한 offline 동작
• 내부 임시 폴더 정리 구현 세부사항

release 전에는 이 다섯 항목을 수동 matrix에 추가하고, 문제가 생기면 실제 package·manifest·service worker와 source를 함께 보존해 재현한다.