배포
zip 직접 전달, Web Store 업로드, self-host .crx와 update_url 셋의 트레이드오프와, .pem 키 관리 그리고 chrome이 외부 .crx를 차단하는 자리를 어떻게 우회하는지를 본다. build-and-package에서 dist/와 packages/extension.zip을 떨궜다는 가정 위에서 시작한다.
세 경로 한눈에
| 경로 | 받는 쪽 절차 | 자동 업데이트 | 검수 | 적합한 자리 |
|---|---|---|---|---|
| zip 직접 전달 | 압축 해제 후 chrome://extensions에서 Load unpacked | 없음 | 없음 | 동료 한두 명, 사내 PoC |
| Web Store 업로드 | 스토어에서 한 번 클릭 | 있음 (스토어가 처리) | 있음, 수일에서 수주 | 일반 공개 |
self-host .crx + update_url | 한 번 설치 후 자동 | 있음 (update.xml 갱신) | 없음 | 사내 배포, 통제된 사용자군 |
세 경로는 배타적이지 않다. 같은 확장을 사내에는 self-host로, 일반 사용자에게는 Web Store로 동시에 풀 수도 있다. 한쪽을 끊고 다른 쪽으로 넘기는 마이그레이션도 흔하다.
zip 직접 전달
pnpm run package가 떨군 packages/extension.zip을 그대로 보낸다. 받는 쪽은 압축을 풀고 chrome://extensions에서 개발자 모드를 켠 다음 "Load unpacked"로 그 폴더를 지정한다. 업데이트는 새 zip을 같은 절차로 다시 깐다. 자동 갱신은 없다.
PoC 단계에서는 충분하지만, 받는 쪽이 매번 같은 동작을 반복해야 한다. 사용자가 다섯 명을 넘어가기 시작하면 self-host로 넘긴다.
Web Store 업로드
업로드 직전에 갖춰야 할 것은 짧다.
- 일관된 아이콘 16, 32, 48, 128. 보통
public/icons/자리 - store listing 용 스크린샷 1280×800 또는 640×400
- 한 줄 설명과 자세한 설명. 권한이 왜 필요한지 명시. 특히
host_permissions는 거부 사유 1순위 - 비공개 배포 옵션. 검수 전 테스터 한정으로 먼저 풀 수도 있음
스크린샷 캡처 가이드와 store 콘텐츠 작성 절차는 expert 자리가 아니다. 화면을 보면서 따라가야 하는 단계라 비개발자용 매뉴얼 distribution에 같은 주제가 다른 호흡으로 정리돼 있다.
self-host .crx
가장 손이 가는 길이지만 통제가 필요한 사내 배포에서는 이 자리를 고른다.
.crx 만들기와 .pem 키
첫 .crx를 만들 때 chrome이 같이 떨구는 .pem 키 한 장이 그 확장의 신원이 된다. 같은 키로 서명한 .crx만 chrome이 같은 확장으로 인식한다. 키를 잃어버리면 같은 확장으로 업데이트할 수 없다. 사용자 전원에게 새 확장으로 다시 설치해 달라고 안내해야 한다는 뜻이다.
키는 git에 커밋하지 않는다. 1Password 또는 팀 비밀 저장소에 두고, 회전 정책을 ADR 한 장에 적어둔다. docs/adr/에 enterprise policy 채택 결정과 키 회전 절차가 한 장 들어있다.
update_url과 update.xml
manifest에 update_url을 한 줄 추가한다.
"update_url": "https://example.com/extension/update.xml"
update.xml은 chrome이 정의한 형식이 있다.
<?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://example.com/extension/extension-1.2.0.crx' version='1.2.0' />
</app>
</gupdate>
새 버전을 풀 때는 .crx를 같은 host의 새 경로에 올리고 update.xml의 version과 codebase만 갱신한다. chrome이 하루 한 번 정도 update_url을 폴링하면서 새 버전을 잡아간다. host 자리는 GitHub Pages, S3, 자체 도메인 어디든 정적 파일 서빙이 되면 된다.
chrome의 외부 .crx 차단
기본 정책으로 chrome은 Web Store가 아닌 자리에서 받은 .crx의 설치를 막는다. 사내 배포에서 풀어내는 길은 둘이다.
- enterprise policy의
ExtensionInstallAllowlist또는ExtensionInstallForcelist에 확장 ID와update_url을 등록한다. Windows는 레지스트리, macOS는 plist, Linux는/etc/opt/chrome/policies/managed/의 JSON으로 적는다. - 사용자가 unpacked로 직접 설치하게 한다. 이 경우 자동 업데이트는 비활성.
ID 등록과 도메인 결정은 한 번 정하면 되돌리기 비싸다. 그래서 이 결정도 ADR 한 장으로 남긴다. 어떤 도메인에서 update.xml을 호스팅할지, 키 회전 주기를 어떻게 잡을지가 거기 들어있다.
expert tier 끝
여기까지가 chrome-ext-base의 expert tier다. intro에서 guardrail 세 개를 짚고, architecture에서 의존 방향과 메시지 라우팅을 봤고, build-and-package에서 dist와 zip이 어떻게 떨어지는지를 본 다음, 여기서 그 산출물을 사용자 손까지 보내는 길 셋을 갈랐다.
비개발자 청중을 위한 단계별 안내, 화면 캡처, OS별 설치 분기는 비개발자용 매뉴얼에 같은 주제를 다른 호흡으로 풀어두었다.