docs.membloc.com

membloc docs

제품, 플랫폼, 운영 문서를 한곳에서 읽는 Membloc 공식 문서 포털입니다.

homepartner portal

Membloc Phase 2 Rebrand Plan

Last updated: 2026-04-12

목적: 1차 리브랜딩(사용자 노출 브랜드 변경) 이후, 기술 식별자와 배포 인프라까지 Membloc 기준으로 옮기는 2차 리브랜딩 계획을 정의한다.

1. 현재 상태

이미 끝난 것

  • 사용자 노출 앱/포털 카피를 Membloc로 변경
  • GitHub 저장소를 membloclabs 조직으로 이관
    • membloclabs/membloc-app
    • membloclabs/membloc-app-engine
    • membloclabs/membloc-developer-portal

아직 남아 있는 것

  • Firebase project ID는 여전히 homblabs-a1e67
  • Firebase Auth / Firestore / Storage 실제 데이터 이전은 미수행
  • 문서/SDK namespace의 homb 잔여 문맥 정리 필요

2026-04-12 진행 반영

  • local repo 디렉터리명: membloc-*로 정리
  • Go module path: github.com/membloclabs/membloc-app-engine
  • Flutter package: membloc_app
  • Android applicationId / iOS bundle id: com.membloclabs.membloc
  • Firebase app 등록:
    • Android 1:854204240417:android:ba3b71af070c6e2e298960
    • iOS/macOS 1:854204240417:ios:5e1df51cbb34b5cb298960
    • Web 1:854204240417:web:62b5e3ec529ae386298960

2. Phase 2 목표

2차 리브랜딩의 목표는 아래 4가지를 맞추는 것이다.

  1. 제품 외부 접점의 URL을 membloc.com 체계로 정렬
  2. SDK / webhook / runtime namespace를 membloc 기준으로 재정의
  3. repo / package / module path를 새 브랜드 기준으로 정렬
  4. 기존 homb 클라이언트/모듈과의 호환성을 일정 기간 유지

3. 리스크 원칙

이번 단계는 1차보다 위험하다. 이유는 아래와 같다.

  • URL 변경은 외부 접근 경로를 깨뜨릴 수 있음
  • SDK namespace 변경은 기존 WebView 모듈을 깨뜨릴 수 있음
  • webhook header 변경은 third-party endpoint 검증 로직을 깨뜨릴 수 있음
  • repo/package/module path rename은 build, import, CI, deploy를 깨뜨릴 수 있음
  • Firebase project 변경은 auth/storage/FCM 전체를 흔듦

따라서 원칙은 다음과 같다.

  • 사용자-facing URL 먼저
  • runtime contract는 alias 기간을 둔다
  • repo/package rename은 마지막에 한다
  • Firebase project rename은 별도 migration project로 다룬다

4. 작업 스트림

Stream A. Domain Cutover

목표:

  • 사용자와 파트너가 보는 도메인을 membloc.com 체계로 통일

대상:

  • membloc.com
  • developer.membloc.com
  • docs.membloc.com
  • 필요 시 api.membloc.com

작업:

  1. Vercel project 생성 및 연결
  2. developer.membloc.com을 membloc-developer-portal에 연결
  3. backend public endpoint가 있으면 api.membloc.com 정의
  4. Firebase Authorized Domains 갱신
  5. docs host 결정

완료 기준:

  • developer.membloc.com이 정상 서비스
  • 기존 developer.membloc.com 문구 제거 또는 redirect 안내

Stream B. SDK Namespace Transition

목표:

  • 모듈 개발자가 homb 대신 membloc namespace를 사용할 수 있게 함

현재:

  • window.homb
  • sdk.homb.app
  • @homb/module-sdk
  • X-Homb-*

목표:

  • window.membloc
  • https://docs.membloc.com/sdk/v1/membloc-sdk.js (현재 배포 경로)
  • @membloc/module-sdk
  • X-Membloc-*

전환 원칙:

  • alias 기간 운영
  • breaking cutover 금지

실행안:

  1. bridge 주입 시 window.homb와 window.membloc를 동시에 노출
  2. webhook header도 X-Homb-*와 X-Membloc-* 동시 송신
  3. SDK 문서는 membloc 표기를 우선으로 하고 homb alias 안내 포함
  4. deprecation 기간 종료 후 homb namespace 제거

완료 기준:

  • 새 모듈은 membloc namespace로 개발 가능
  • 구 모듈은 alias 기간 동안 정상 동작

Stream C. Repository / Package Rename

목표:

  • 코드 저장소와 패키지 이름도 브랜드와 일치시킴

후보:

  • membloc-app → membloc-app
  • membloc-app-engine → membloc-api 또는 membloc-engine
  • membloc-developer-portal → membloc-developer-portal

Go module 후보:

  • github.com/membloclabs/membloc-api

Flutter package 후보:

  • com.membloclabs.membloc

주의:

  • repo rename은 GitHub redirect가 있지만 CI/Vercel/GitHub Actions/외부 문서 모두 재검토 필요
  • Go module path rename은 import 전역 변경 필요
  • Flutter bundle/applicationId 변경은 Firebase app 재등록이 따라옴

권장 순서:

  1. GitHub repo rename
  2. remote URL 업데이트
  3. CI/CD secret/path 업데이트
  4. Go module path rename
  5. Flutter package/bundle rename

완료 기준:

  • repo 이름, package 이름, CI 경로가 모두 Membloc 기준으로 정렬

Stream D. Firebase / Infra Identity Migration

목표:

  • homblabs-a1e67 중심의 인프라 식별자를 새 브랜드에 맞게 재편

현재:

  • Firebase project: homblabs-a1e67
  • storage bucket: homblabs-a1e67.firebasestorage.app
  • bundle/applicationId: com.jmcunst.hombApp, com.jmcunst.homb_app

리스크:

  • auth user pool, storage, FCM, OAuth redirect, deep link, app ids 전체 영향

판단:

  • 이 작업은 별도 migration project로 분리해야 함
  • Phase 2 리브랜딩 본편에 포함하되, 실제 실행은 Phase 2.5 또는 infra migration wave로 분리

완료 기준:

  • 새 Firebase project 또는 naming policy 확정
  • cutover/rollback 문서화

5. 추천 순서

가장 안전한 순서는 아래다.

  1. developer.membloc.com 연결
  2. portal/docs/domain 문구 완전 정리
  3. window.membloc + X-Membloc-* alias 추가
  4. SDK 문서와 샘플을 membloc 기준으로 전환
  5. webhook consumer 가이드 업데이트
  6. repo rename
  7. Go module rename
  8. Flutter bundle/applicationId/Firebase migration

6. 호환성 전략

브라우저/모듈 runtime

  • window.homb 유지
  • window.membloc 추가
  • 내부 구현은 동일 bridge를 공유

Webhook

  • X-Homb-Signature, X-Homb-Event, X-Homb-Delivery 유지
  • X-Membloc-Signature, X-Membloc-Event, X-Membloc-Delivery 추가
  • 문서에는 Membloc header 우선 표기

SDK package

  • @homb/module-sdk 유지
  • @membloc/module-sdk 신규 publish
  • 동일 코드베이스에서 dual publish 가능 여부 검토

Repository rename

  • GitHub redirect 활용 가능
  • 단, CI/Vercel/import 경로는 수동 업데이트 필요

7. 결정이 필요한 항목

다음 6개는 실제 작업 전에 확정해야 한다.

  1. 최종 제품 표기

    • Membloc
    • membloc

  2. 공식 도메인 전략

    • membloc.com 유지
    • 별도 membloc.* 도메인 확보

  3. backend repo명

    • membloc-api
    • membloc-engine

  4. SDK 도메인

    • sdk.membloc.com
    • sdk.membloc.app

  5. webhook header alias 기간

    • 30일
    • 60일
    • 90일

  6. Firebase project migration 여부

    • 유지
    • 신규 project 생성 후 이전

8. 실행 체크리스트

즉시 시작 가능

  • developer.membloc.com project/domain 연결
  • portal/docs에서 developer.membloc.com 잔여 문구 제거
  • window.membloc alias 설계 문서화
  • webhook dual-header 설계

기술 전환 전 준비 필요

  • repo rename 대상명 확정
  • Go module rename impact 분석
  • Flutter applicationId/bundleId migration impact 분석
  • Firebase migration decision

9. 완료 정의

Phase 2 rebrand 완료는 아래 조건을 만족해야 한다.

  • 모든 공식 사용자 접점이 Membloc 브랜드 사용
  • 공식 도메인이 membloc.com 체계로 정리
  • SDK / webhook namespace가 membloc 기준으로 제공
  • repo / package / module path가 새 브랜드 기준으로 정리
  • 기존 homb 통합은 alias 기간 동안 정상 동작