"기본은 공개 Web Store 야. 조용히 뿌리는 길은 셋 — unlisted store, Workspace 전용 store, group policy 강제 설치. 이 lesson에서 각각이 언제 맞는지, 값은 뭘 치러야 하는지, 그리고 sideload로 삽질하다 막다른 길에 서지 않는 법을 정리할게."
왜 그냥 sideload 하면 안 되나
가장 먼저 떠오르는 그림은 이거야. .crx를 만들어서 서버에 올리고, user가 받아서 더블클릭. 그런데 Chrome 데스크톱이 이 길을 몇 년에 걸쳐 차근차근 막아 놨어. 지금은 .crx를 chrome://extensions에 끌어다 놔도 평범한 Chrome 이면 'This extension can't be added' 경고만 떠. 제대로 sideload 하려면 둘 중 하나가 필요해:
- Developer mode + Load unpacked — 각자가 developer mode를 켜고 Chrome 한테 폴더를 짚어 줘야 해. 되긴 되는데, 갱신할 때마다 전원이 다시 받아서 다시 올려야 해. 자동 업데이트가 없거든.
- 기업 정책으로 강제 설치 — 관리되는 Chrome을 쓰는 환경에서, extension의 ID와 update URL을 group policy에 적어 두는 방식.
첫 번째는 혼자 쓸 땐 괜찮아. 열 명만 돼도 못 버텨. 두 번째는 팀이 관리형 Chrome을 쓰고 있으면 (규모 있는 조직은 대개 Google Workspace 나 Active Directory로 쓰지) 아주 좋고, 안 쓰면 아예 쓸모가 없어.
길 1 — Web Store의 Unlisted
'간신히 공개' 쯤 되는 길이야. 제출 과정은 공개 등록이랑 똑같아 — 개인정보 처리방침, 스크린샷, 심사, 전부. 다른 건 노출뿐이야. 검색 결과에도, 분류 목록에도, 추천에도 안 나와. 대신 URL을 아는 사람은 누구나 한 번에 설치할 수 있어.
좋은 점은 공짜고, 자동 업데이트가 되고, sideload로 고생할 일이 없고, 기업 인프라도 필요 없다는 거야. 나쁜 점은 Web Store 심사를 거쳐야 하고 (5 분에서 일주일), URL을 알아낸 사람은 다 설치할 수 있다는 거지. 진짜 접근 제어가 아니라 '아무도 모를 거야' 에 기대는 방식이야.
혼자 하는 개발자, tester 몇 명 있는 작은 오픈소스 프로젝트, 검색에 안 뜨면서 Chrome 자동 업데이트는 받고 싶은 사람한테 맞는 답이야.
길 2 — Workspace 전용 store
팀이 Google Workspace를 쓴다면, Chrome 관리 콘솔에서 그 도메인 사람들한테만 보이는 extension을 낼 수 있어. 제출한 게 사내 store로 들어가고, 도메인 안 사람들은 평범한 Web Store 처럼 보게 되고, 도메인 밖 사람들은 아예 못 봐.
좋은 점은 Workspace 계정으로 진짜 접근 제어가 걸리고, 자동 업데이트가 되고, 평소보다 설치 경고가 더 붙지도 않는다는 거야. 나쁜 점은 Workspace 관리자가 세팅을 해 줘야 하고, Workspace 비용이 들고, 도메인 밖 사람은 손도 못 댄다는 거고.
관리되는 Workspace 조직에서 domain 또는 trusted-tester 단위 접근 제어가 필요할 때 맞아. 사람 수가 아니라 관리 경계가 선택 기준이야.
길 3 — Group policy 강제 설치
Chrome은 Windows 면 레지스트리와 정책, Mac 이면 plist, Linux 면 managed preference를 통해 extension을 강제로 깔 수 있어. 관리자가 extension의 ID와 update URL을 적어 두면, Chrome이 조직 안 모든 관리형 프로필에 알아서 설치해. user는 chrome://extensions에서 그걸 볼 수는 있어도 지우지는 못해. 설치의 주인이 관리자거든.
좋은 점은 조직 단위로 잘게 제어할 수 있고, user가 아무것도 안 해도 깔리고, 권한 제한이랑 같이 걸 수 있다는 거야. 나쁜 점은 관리형 Chrome이 있어야 하고 (Workspace, Microsoft AD, Jamf 같은 것들), update URL이 Chrome이 읽는 형식의 .xml 이어야 하고, 그 .xml 이랑 버전별 .crx를 직접 호스팅해야 한다는 거고.
인원수와 상관없이 강제 설치나 중앙 통제 업데이트가 필요한 관리형 조직에 맞아.
직접 호스팅하는 update endpoint
직접 호스팅하는 길로 간다면 (Workspace 없는 3 번), Chrome이 갱신을 확인하러 들를 XML 주소가 필요해:
<?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이 이 주소를 하루에 몇 번씩 들여다봐. 새 버전을 낼 때 XML의 version과 codebase를 새 .crx로 고쳐 두면, 다음에 들를 때 알아서 받아 가.
어느 길로 갈지
- 공개용이야? → 공개 Web Store.
- 팀이 Google Workspace를 쓰고 조직 안에서만 보이면 돼? → Workspace 전용 store.
- 작은 사적 팀이고 'URL 아는 사람은 깔 수 있음' 을 감수할 수 있어? → Unlisted Web Store.
- 관리형 Chrome을 쓰는 큰 조직이고 강제 설치랑 관리자 통제가 필요해? → Group policy + 직접 호스팅한 .crx + XML 주소.
- 혼자 쓰고 팀도 없어? → 그냥 developer mode + Load unpacked로 살아. 꼭 배포해야 한다는 법은 없어.