"Public Web Store 가 default. 세 private 경로가 unlisted store, Workspace-private store, group-policy force-install. Lesson 4 가 각각 언제 맞는지, 각자 비용 뭔지, sideload 시도 dead-end 회피 법 map."
왜 그냥 sideload 안 하는가
순진한 private-distribution 생각: .crx build, server 에 host, user 가 download 하고 double-click. Chrome desktop 이 점진적으로 이 경로 닫음. 오늘, .crx 를 chrome://extensions 에 드래그하면 standard Chrome 이 'This extension can't be added' 경고 생성. 정당한 sideload 가 필요:
- Developer mode + Load unpacked — 각 user 가 developer mode toggle, Chrome 을 디렉토리에 point. 동작하지만 모든 user 가 re-download 하고 re-load 해서 re-update 필요. Auto-update 없음.
- Enterprise policy force-install — managed Chrome 설치, extension 의 ID + update URL list 하는 group policy.
첫 번째가 one-person team 엔 fine, 열 명엔 untenable. 두 번째가 team 이 managed Chrome 사용하면 (대부분 큰 org 가 Google Workspace 나 Active Directory 통해 사용) great; 안 하면 useless.
경로 1 — Web Store 의 Unlisted
'just barely public' 경로. Submission flow 가 public listing 과 동일 — privacy policy / screenshot / review / 모든 것. 차이는 visibility: extension 이 검색 결과, category browsing, Web Store 의 추천에 나타나지 안 함. URL 가진 누구든 one click 으로 install.
장점: 무료, auto-update 동작, sideload pain 없음, Enterprise infrastructure 필요 없음. 단점: Web Store review 필요 (5 분에서 일주일), URL 찾는 누구든 install 가능 (실제 access control 이 아닌 obscurity 통한 보안).
Indie dev team, 몇 tester 가진 작은 open-source 프로젝트, public-search 노출 없이 Chrome auto-update 원하는 누구에 맞는 답.
경로 2 — Workspace-private store
Team 이 Google Workspace 사용하면, Chrome admin console 이 Workspace domain user 만 보이는 extension publish 하게 해 줘. Extension submission 이 private store 로 가고; domain user 가 chrome.google.com/webstore 에서 public 처럼 봄; domain 바깥 user 는 절대 안 봄.
장점: Workspace identity 통한 실제 access control, auto-update 동작, normal 한 거 너머 install 경고 없음. 단점: Workspace admin setup 필요, Workspace 비용 들음, Workspace domain user 만 access.
실제 private app store 경험 원하는 Google Workspace 의 medium team (20–500 명) 에 맞음.
경로 3 — Group policy force-install
Chrome 이 Windows 에서 registry/policy mechanism, Mac 에서 plist, Linux 에서 managed pref 지원해서 extension force-install. Admin 이 extension 의 ID 와 update URL 지정; Chrome 이 org 의 모든 managed Chrome profile 에 auto-install. User 가 chrome://extensions 에서 extension 봄 하지만 uninstall 못 함 (admin 이 install 소유).
장점: granular per-OU 제어, install 위한 user action 필요 없음, permission 제한과 결합 가능. 단점: managed Chrome 필요 (Workspace, Microsoft AD, Jamf 등), update URL 이 Chrome-format .xml endpoint 여야, .xml 과 .crx versioned file 둘 다 host 책임.
중앙 admin control 가진 org-wide auto-install 필요한 large org (500+ 명) 에 맞음.
Self-hosted update endpoint
Self-hosted 경로 (Path 3 minus Workspace) 가면, Chrome 이 update 위해 poll 하는 XML endpoint 필요:
<?xml version='1.0' encoding='UTF-8'?>
<gupdate xmlns='http://www.google.com/update2/response' protocol='2.0'>
<app appid='your-extension-id'>
<updatecheck codebase='https://your-cdn.example.com/clipdeck-1.0.0.crx' version='1.0.0' />
</app>
</gupdate>Chrome 이 이 URL 을 스케줄 (하루 몇 번) 로 poll. Release 할 때 XML 의 version 과 codebase 를 새 .crx 가리키도록 update; Chrome 이 다음 poll 때 download.
결정 tree
- Public-facing extension? → Public Web Store.
- Team 이 Google Workspace 사용하고 org-only visibility 원함? → Workspace-private store.
- 작은 private team, 'URL 가진 누구든 install' 와 함께 살 수 있음? → Unlisted Web Store.
- Force-install + admin control 필요한 큰 managed-Chrome org? → Group policy + self-hosted .crx + XML endpoint.
- 한 사람, team 없음? → 그냥 developer mode + Load unpacked 계속 사용. distribute 해야 한다는 규칙 없음.