세상에 내보내기 — 스토어 등록, 유지보수, 그리고 그 다음 (시리즈 완결편)

작성자:


브라우저 확장프로그램 시리즈 (5/5)
만들었다면 이제 내보낼 차례예요. 크롬 웹 스토어와 엣지 애드온 스토어에 어떻게 등록하는지, 심사에서 왜 자주 거절되는지, 발행 후에 뭘 해야 하는지. 그리고 더 깊이 가고 싶을 때 갈 수 있는 다음 여정까지 짚어드릴게요. 시리즈의 마지막 편입니다.

들어가며 — “만들었다”와 “세상에 나갔다” 사이

많은 튜토리얼이 “확장 완성! 끝!” 에서 멈춰요. 그런데 사실 여기서부터가 진짜 시작이에요.

혼자 로컬에서 쓰는 확장과 수백 명, 수만 명이 쓰는 확장은 완전히 다른 물건이에요. 배포 과정에서 심사를 거쳐야 하고, 사용자 피드백에 대응해야 하고, 버전 업데이트를 관리해야 해요. 그리고 그 모든 과정에 처음 겪는 사람은 잘 모르는 함정들이 있어요.

이 편은 4편에서 만든 “웹페이지 분석기” 확장을 기준으로 실제 배포까지 따라가요. 그리고 시리즈를 마무리하면서 “그 다음은 뭘 공부하면 좋은지” 도 안내해드릴게요.

1부. 배포 전 체크리스트 — 준비물 챙기기

스토어 등록 페이지에 들어가서 필요한 게 하나라도 없으면 짜증나요. 미리 다 준비해두세요.

✅ 필수 준비물

1. 아이콘 파일 (3종)

  • 16×16 — 툴바 아이콘
  • 48×48 — 관리 페이지
  • 128×128 — 스토어 등록

PNG 포맷, 배경 투명 권장. 디자인 툴이 없으면 Figma(무료), Canva, Iconify에서 만들 수 있어요.

2. 스토어용 이미지

  • 스토어 아이콘: 128×128 PNG
  • 스크린샷: 1280×800 또는 640×400 (최소 1개, 최대 5개)
  • (선택) 프로모션 타일: 440×280 PNG
  • (선택) 마키(대형) 프로모션 이미지: 1400×560 PNG

3. 설명문

  • 짧은 설명 (최대 132자) — 검색 결과에 뜨는 문구
  • 상세 설명 — 기능, 사용법, 특이사항 정리
  • 카테고리 선택 — “생산성”, “개발자 도구” 등

4. 개인정보 처리방침 확장이 사용자 데이터를 조금이라도 건드린다면 반드시 필요해요. 간단한 웹페이지 하나면 돼요. 깃허브 Pages, 개인 블로그, 노션 공개 페이지 등에 올려두고 URL만 제출하면 됩니다.

최소한의 개인정보 처리방침 템플릿:

# [확장 이름] 개인정보 처리방침

[확장 이름]은 다음과 같이 개인정보를 처리합니다.

## 수집하는 정보
- 로컬 설정 정보 (다크 모드 ON/OFF 등)
- 위 정보는 사용자 기기에만 저장되며 외부로 전송되지 않습니다.

## 수집하지 않는 정보
- 개인 식별 정보 (이름, 이메일 등)
- 브라우징 히스토리
- 페이지 내용
- 쿠키·비밀번호 등 민감 정보

## 제3자 공유
일체 없습니다.

## 연락처
문의: your-email@example.com

최종 수정: YYYY-MM-DD

✅ 코드 체크리스트

1. 권한 최소화
manifest.json의 permissions 배열을 다시 한 번 검토하세요. 정말 필요한 것만 남기세요.

// ❌ 과한 권한
{ "permissions": ["tabs", "history", "cookies", "<all_urls>"] }

// ✅ 최소 권한
{ "permissions": ["storage", "activeTab"] }

과도한 권한은 심사 거절 1순위 이유예요.

2. 불필요한 파일 제거

  • console.log 디버깅 코드
  • 주석 처리된 코드
  • .DS_Store, node_modules/, .git/ 같은 숨김·로컬 파일
  • 사용하지 않는 이미지

3. 버전 번호 확정
manifest.json의 version은 첫 출시라면 "1.0.0" 정도로.

4. 배포용 ZIP 압축
프로젝트 폴더 안의 파일들을 선택해서 ZIP으로 압축하세요. 폴더 자체가 아니라 내용물만 포함돼야 해요.

✅ my-analyzer.zip
   ├── manifest.json
   ├── popup.html
   ├── ...

❌ my-analyzer.zip
   └── my-analyzer/
       ├── manifest.json
       └── ...

2부. 크롬 웹 스토어 등록

전 세계 크롬 사용자에게 도달하는 길이에요.

개발자 계정 등록

  1. Chrome Web Store Developer Dashboard 접속
  2. 구글 계정으로 로그인
  3. 일회성 $5 등록비 결제 (평생 한 번만)

등록비는 개인 계정당 한 번이에요. 나중에 확장을 몇 개 올리든 추가 비용은 없어요.

확장 업로드 및 정보 입력

  1. 대시보드에서 새 항목 클릭
  2. 준비한 ZIP 파일 업로드
  3. 다음 정보 입력:
    • 상세 설명: 기능, 사용법, 지원하는 사이트 등
    • 카테고리: “생산성”, “개발자 도구” 등
    • 언어: 한국어, 영어 등 (복수 가능)
    • 스크린샷: 최소 1개, 실제 동작 모습
    • 아이콘: 128×128
    • 개인정보 처리방침 URL

권한 정당화 설명 (중요!)

permissions에 뭐가 들어있든, 각 권한이 왜 필요한지 정당화해야 해요. 이 칸을 대충 채우면 거절 확률이 올라가요.

좋은 예시:

activeTab: 사용자가 확장 아이콘을 클릭했을 때만 현재 탭에 접근해
페이지 분석 기능을 제공합니다.

storage: 사용자가 설정한 다크 모드 선호도를 저장하여
브라우저를 재시작해도 설정이 유지되도록 합니다.

나쁜 예시:

확장이 동작하려면 필요합니다.

심사 과정

제출 후 심사는 보통 1~3일, 길면 일주일 걸려요. 결과는 이메일로 옵니다.

통과 시: 몇 시간 뒤 스토어에 노출.

거절 시: 이유가 이메일로 옴. 수정 후 재제출하면 됨 (재제출 수 제한 없음).

자주 거절되는 이유 Top 5

  1. 권한 과다 요구 vs 실제 기능 불일치
    • 해결: 권한 최소화 + 정당화 설명 구체적으로
  2. 개인정보 처리방침 부재 또는 부실
    • 해결: 간단하더라도 실제 URL에 접근 가능한 방침 페이지 준비
  3. 설명이 기능을 정확히 반영하지 않음
    • 해결: “이런 거 저런 거 다 함” 같은 모호한 설명 금지. 정확히 뭘 하는지 명시.
  4. Single Purpose 정책 위반
    • 크롬 웹 스토어는 한 확장 = 한 목적 원칙을 강조해요. 여러 관련 없는 기능을 한 확장에 넣으면 거절.
    • 해결: 하나의 명확한 목적에 집중.
  5. 코드 난독화
    • 난독화된 코드는 심사 불가. 압축(minify)은 OK, 난독화(obfuscate)는 NO.

3부. 엣지 애드온 스토어 등록

엣지는 크롬 대비 덜 알려져 있지만, 등록비가 무료이고 심사도 상대적으로 빨라서 놓치면 아까워요. 크롬용 확장을 거의 그대로 올릴 수 있어요.

등록 절차

  1. Microsoft Partner Center 접속
  2. 마이크로소프트 계정으로 로그인
  3. 개발자 등록 — 무료, 즉시 완료
  4. 새 확장 추가 → ZIP 업로드 → 정보 입력

크롬에 올린 ZIP을 그대로 써도 거의 다 동작해요. manifest v3 규격이 호환되거든요.

심사 특징

  • 심사 기간: 보통 24~72시간
  • 심사 기준: 크롬보다 살짝 여유 있는 편
  • 업데이트 반영: 승인 후 즉시

크롬·엣지 나란히 운영 팁

두 스토어에 같은 확장을 올리면 두 스토어의 리뷰·다운로드가 각각 쌓여요. 초기에는 엣지 쪽 리뷰가 빠르게 쌓여서 크롬 쪽으로 유입되는 효과도 생깁니다.

파일 관리 팁: 깃허브 태그나 릴리스를 활용해 버전별 ZIP 파일을 보관하세요. 스토어별로 약간씩 다르게 올려야 할 때 (예: 스토어별 홍보 문구) 유용해요.

4부. 발행 후 — 유지보수의 진짜 시작

출시되면 끝이 아니에요. 사용자가 붙기 시작하면 새 과제가 생겨요.

사용자 피드백 관리

스토어 리뷰
매일 한 번씩 체크하세요. 별점 4점 이상의 호평은 SNS나 블로그에 사용 후기로 인용할 수 있어요. 1~2점 리뷰는 버그 리포트일 가능성이 높으니 빠르게 확인.

버그 리포트 대응
스토어 리뷰는 짧아서 정보가 부족해요. 설명에 이슈 트래커 링크를 추가하는 게 좋아요. 깃허브 이슈나 구글폼 정도면 충분.

예시 설명 말미:

🐛 버그 신고나 기능 제안:
https://github.com/[your-id]/my-analyzer/issues

버전 업데이트하기

새 버전 배포 순서는 이래요.

  1. 코드 수정 + 테스트
  2. manifest.json의 version 올리기 (1.0.0 → 1.0.1)
  3. 새 ZIP 생성
  4. 스토어 대시보드에서 기존 확장 → 새 패키지 업로드
  5. 변경사항 기록
  6. 제출 → 재심사

버전 번호 규칙:

  • 패치 (버그 수정): 1.0.0 → 1.0.1
  • 마이너 (기능 추가): 1.0.1 → 1.1.0
  • 메이저 (큰 변경): 1.1.0 → 2.0.0

업데이트 전 꼭 확인할 것:

  • 이전 버전 사용자의 chrome.storage 데이터가 깨지지 않는지
  • 새 권한을 추가했다면 사용자 동의 재요청됨 (일부 사용자 이탈 가능)
  • 만약 주요 기능 변경이 있다면 릴리스 노트를 상세하게

성장 지표 추적

대시보드에서 확인할 수 있는 지표들:

  • 주간 활성 사용자 — 얼마나 많은 사람이 실제로 쓰는지
  • 별점 분포 — 만족도
  • 설치·제거 추이 — 유입과 이탈
  • 국가별 분포 — 어느 지역 사용자가 많은지

제거율이 높다면 (설치하고 금방 삭제하는 비율) 뭔가 사용자 기대와 다른 거예요. 리뷰 확인 + 본인이 직접 “신규 사용자 관점”으로 다시 써보기.

5부. 수익화 전략 — 현실적으로

2편에서 살짝 언급했지만, 이번엔 구체적으로 볼게요.

모델 1: 완전 무료 + 오픈소스

가장 흔한 경로예요. 깃허브에 공개하고 커뮤니티 기여를 받아요. 돈은 안 되지만 이력서·개발자 브랜딩에 강력해요. 여러 명이 쓰기 시작하면 기업에서 채용 제안 오는 일도 있어요.

모델 2: Freemium

기본 기능 무료, 고급 기능 유료. 대표적인 방식이에요.

  • 결제 처리: Stripe, Paddle, LemonSqueezy
  • 라이선스 관리: 자체 서버 또는 Gumroad
  • 일반적 가격: 월 $3~10, 라이프타임 $20~50

예: 번역 확장은 기본 번역은 무료, AI 요약·히스토리는 유료.

모델 3: Pay-once

한 번 결제하면 평생 사용. 복잡한 구독 관리가 필요 없어요. 번아웃 방지에 좋아요.

모델 4: 본 서비스 유입 채널

확장 자체는 무료인데, 본 서비스(웹앱, SaaS)의 진입점 역할을 해요. 예: Notion Web Clipper는 무료지만 Notion 서비스로 사용자를 끌어들여요.

모델 5: 기업 스폰서십

사용자 기반이 커지면 관련 기업에서 파트너십·스폰서십 제안이 올 수 있어요.

돈보다 중요한 것

솔직히 말하면, 확장프로그램 자체로 큰 돈을 벌기는 어려워요. 월 수십만 원 정도면 꽤 성공한 축이에요. 대신:

  • 포트폴리오 효과
  • 오픈소스 커뮤니티 인지도
  • 본 서비스로의 유입
  • 수만 명이 쓰는 제품을 만들었다는 경험 자체

이 비금전적 가치들이 오히려 장기적으로 크게 돌아와요.

6부. 다음 여정 — 더 깊이 가고 싶다면

이 시리즈는 입문이에요. 여기서 더 가려면 다음 길들이 있어요.

🔧 기술적 심화

1. 확장프로그램 전용 프레임워크 도입

순수 JS로 만드는 게 슬슬 한계에 달하면 프레임워크를 도입할 때예요.

  • Plasmo — “확장계의 Next.js”. React·TypeScript·핫리로드 지원. 생산성이 압도적으로 올라가요.
  • WXT — Plasmo 대안. Vite 기반이라 가볍고 빠름.
  • CRXJS — 기존 Vite 프로젝트에 확장 빌드 기능 추가.

2. 파이어폭스 포팅

Chromium-only에서 벗어나려면 Firefox까지 커버.

  • webextension-polyfill 으로 browser.* 네임스페이스 통일
  • Firefox Add-ons 개발자 등록 (무료)
  • 대부분의 코드는 그대로 동작, 미묘한 API 차이만 분기 처리

3. 고급 API 학습

  • declarativeNetRequest — 네트워크 요청 제어
  • webNavigation — 페이지 탐색 이벤트
  • debugger — Chrome DevTools 프로토콜 활용
  • nativeMessaging — 네이티브 앱과 통신
  • enterprise.* — 기업용 정책 관리

4. 보안·프라이버시 강화

  • Content Security Policy 강화
  • 민감 데이터 암호화 (Web Crypto API)
  • OAuth 2.0 제대로 구현 (chrome.identity)

📦 프로젝트 관리 고도화

1. CI/CD 자동화

  • GitHub Actions로 빌드·테스트·배포 자동화
  • 예: PR 머지 시 자동으로 ZIP 빌드, 릴리스 태그 생성
  • chrome-webstore-upload 같은 라이브러리로 스토어 업로드까지 자동화 가능

2. 테스트 전략

  • 단위 테스트: Jest + @sinonjs/sinon-chrome으로 Chrome API 모킹
  • E2E 테스트: Puppeteer로 실제 확장 로드하고 테스트
  • 수동 테스트 체크리스트: 주요 사이트별 동작 확인

🌱 커뮤니티 참여

1. 오픈소스 공개

깃허브에 공개하면 다른 사람의 기여를 받을 수 있어요. README에 다음을 꼭 넣으세요.

  • 설치 방법
  • 개발 가이드
  • CONTRIBUTING.md
  • LICENSE (MIT 추천)

2. 콘텐츠 발행

만든 과정을 블로그 시리즈로 쓰세요. (지금 여러분이 읽는 이 시리즈처럼요!) 검색 유입도 생기고 개인 브랜딩에도 좋아요.

3. 확장 개발자 커뮤니티

7부. 시리즈를 마무리하며

5편을 거쳐오면서 우리는 이런 여정을 했어요.

1편 — 확장프로그램의 세계가 어떻게 생겼는지 봤어요. Chromium 생태계, Manifest V3, 할 수 있는 것과 없는 것의 경계, 수익 구조 현실.

2편 — 12가지 기능 영역과 난이도별 프로젝트 아이디어 25개를 정리했어요. 여러분이 만들 첫 확장의 윤곽이 이때 잡혔죠.

3편 — 확장의 4가지 구성 요소(manifest·popup·background·content script)를 해부했어요. 메시지 패싱이라는 소통 방식도요. 이 지도로 공식 문서를 읽을 수 있게 됐어요.

4편 — 실제로 손으로 만들었어요. 웹페이지 분석기 + 다크 모드 토글. 앞 세 편의 이론이 실제 코드에서 어떻게 쓰이는지 전부 경험하셨어요.

5편 (지금) — 세상에 내보내는 방법과 그 다음 여정까지. 배포, 심사, 유지보수, 수익화, 성장 경로.

이제 여러분은

  • ✅ 확장프로그램 생태계를 이해하고 있어요
  • ✅ 아이디어를 보면 실현 가능한지 판단할 수 있어요
  • ✅ 4가지 구성 요소와 메시지 통신을 이해해요
  • ✅ 처음부터 끝까지 하나의 확장을 만들 수 있어요
  • ✅ 스토어에 배포하는 전 과정을 알아요
  • ✅ 다음 단계로 뭘 공부해야 할지 감이 있어요

이 정도면 “브라우저 확장프로그램 개발을 할 줄 안다” 고 말할 수 있는 수준이에요. 이력서에 한 줄, 포트폴리오에 링크 하나를 추가할 자격이 있어요.

마지막 한마디

확장프로그램은 웹 개발의 숨은 놀이터예요. 백엔드 인프라 없이도, 마케팅 예산 없이도, 혼자서 수만 명에게 가치를 전달할 수 있는 흔치 않은 플랫폼이에요. 그리고 그 기술 스택은 여러분이 이미 아는 HTML/CSS/JS예요.

뭔가 불편하신 거 있으세요? 매일 웹에서 반복하는 지긋지긋한 작업이 있나요? 그게 여러분의 첫 확장 아이디어예요. 이 시리즈에서 배운 걸로 만들고, 스토어에 올리고, 여러분처럼 그 불편을 겪던 사람들에게 나눠주세요.

5편을 여기까지 따라오신 모든 분께 진심으로 감사드려요. 여러분의 첫 확장프로그램, 너무 기대돼요. 스토어에 올리시면 꼭 공유해주세요! 🎉

그럼, 다음엔 여러분이 만든 확장에서 만나요. 👋




댓글 남기기