Platform Docs

Membloc App & Platform Hardening Plan

/platform/membloc-app-platform-hardening-plan

Membloc App & Platform Hardening Plan

Last updated: 2026-04-12

목적: membloc-app을 실제 생활 도구 수준으로 다듬고, 동시에 membloc-app-engine / membloc-developer-portal이 이 기본 모듈군을 플랫폼 관점에서 수용할 수 있도록 확장 계획을 정의한다.

1. 현재 기준선

App 기준선

현재 앱에는 아래 기본 모듈군이 들어가 있다.

운영
- shopping
- chores
- bills
- health
- meal
일정/계획
- calendar
- travel
- projects
- school
- shared_budget
추억/기록
- memories
- archives
- family_story
- growth_journal

현재 상태 요약:

모듈 레지스트리와 런처는 기본 라인업을 인지한다.
홈에는 빠른 실행, 모듈별 preview card, 최근 활동 피드가 붙어 있다.
대부분의 신규 모듈은 “목록 + 생성 + 상태 변경 + 홈 카드 + 활동 피드”까지는 가능하다.

하지만 아래는 아직 공통적으로 부족하다.

상세 화면 밀도와 편집 UX
수정/삭제 흐름의 일관성
reminder / notification
모듈 간 deep link와 cross-module reference
캘린더와의 양방향 연결 완성도

Engine / Portal 기준선

현재 membloc-app-engine / membloc-developer-portal은 외부 퍼블리셔 모듈 플랫폼의 MVP까지는 들어가 있다.

현재 이미 있는 것:

퍼블리셔 등록 / 심사
모듈 draft CRUD / submit / approve / reject
assets upload
API key
webhook
analytics
docs / SDK / partner portal

현재 아직 부족한 것:

기본 모듈군에 대한 category / template 전략
모듈 유형별 권장 데이터 모델 / UX 가이드
review checklist의 카테고리별 구체화
portal에서 “어떤 모듈을 만들지”를 도와주는 starter lane
엔진에서 category 기반 템플릿, 샘플 manifest, module starter metadata 제공

2. 목표

이번 hardening의 목표는 두 개다.

앱 모듈군을 “데모 수준”에서 “반복 사용 가능한 생활 도구” 수준으로 올린다.
엔진/포털도 이 모듈군을 퍼블리셔 관점에서 확장 가능한 플랫폼으로 만든다.

즉:

App lane
- 사용자가 실제로 매일 쓰기 편해야 한다
Platform lane
- 외부 퍼블리셔가 비슷한 주제의 모듈을 만들 때 길을 잃지 않아야 한다

3. Workstream A: App Hardening

A1. 공통 UX 규칙 정리

모든 모듈에 공통으로 필요한 것:

상세 화면 구조 통일
- 요약 카드
- 상태 / 담당자 / 일정 / 메모
- 하위 항목 리스트
수정 / 삭제 / 상태 변경 UX 통일
- BottomSheet 기반 편집
- 삭제 전 확인 다이얼로그
- 완료 / 취소 / 보관 액션 위치 일관화
홈 카드 규칙 통일
- 오늘/이번 주 기준 숫자
- 최대 2~3줄 preview
활동 피드 규칙 통일
- eventType naming
- title / summary 문장 톤

왜 먼저 해야 하냐면:

모듈 수가 늘수록 개별 화면보다 공통 규칙이 더 중요해진다
지금은 모듈마다 생성/상태 변경 방식이 조금씩 달라질 위험이 있다

A1 완료 기준

신규 모듈 1개를 만들 때
- 리스트
- 상세
- 생성
- 수정
- 삭제
- 상태 변경 의 기본 골격을 같은 규칙으로 넣을 수 있어야 한다

A2. Reminder / Notification Layer

우선 reminder 대상:

bills
health
school
calendar
projects

초기 원칙:

앱 내부 reminder badge / home card 우선
push는 2차

1차 구현:

overdue / upcoming 계산 고도화
홈 카드 우선순위 정렬
오늘/내일 기준 alert surface

2차 구현:

FCM local + remote reminder
reminder preferences

A2 완료 기준

사용자가 홈만 봐도
- 오늘 놓치면 안 되는 것
- 이미 밀린 것 을 바로 알 수 있음

A3. Cross-Module Link Layer

핵심 연결:

meal -> shopping
- 장보기 힌트로 shopping list 생성
projects -> shared_budget
- 프로젝트와 공동 예산 연결
projects -> calendar
- 마감일 / 행사 일정 연결
school -> calendar
- 학교 행사 일정 canonical link
health -> calendar
- 병원/검사 일정 canonical link
growth_journal -> memories
- 성장 기록에서 추억 사진 참조
family_story -> archives / memories
- 이야기와 사진/문서 연결

원칙:

문자열 링크 금지
ModuleEntityRef 기반으로 연결
상세 화면에서 “관련 항목 열기” 가능해야 함

A3 완료 기준

최소 4개 연결 흐름이 실제 상세 화면에서 작동

A4. 모듈별 다듬기 우선순위

Tier 1

먼저 다듬을 모듈:

bills
health
school
projects

이유:

생활 운영에 직접 연결
reminder와 상세 UX 효과가 가장 큼

필수 보강:

edit sheet
delete confirmation
detail polish
overdue visual emphasis

Tier 2

meal
shared_budget

필수 보강:

meal <-> shopping link
budget history filters
project/budget linking

Tier 3

family_story
growth_journal

필수 보강:

memory/archive attachment
prompt system 고도화
pinned / highlight UX polish

4. Workstream B: Engine Expansion

B1. Category System 재정의

현재 marketplace category는 generic하다. 앞으로는 아래 product category를 플랫폼 표준으로 삼는 게 맞다.

operations
planning
finance
health
education
memory
food
hobby

이 category는

module manifest
marketplace filter
portal create flow
docs navigation

모두에 공통으로 써야 한다.

B1 완료 기준

engine module schema / API / docs가 위 category 체계를 일관되게 사용

B2. Starter Template Metadata

외부 퍼블리셔는 “무슨 모듈을 만들지”보다 “어떻게 시작할지”에서 더 막힌다.

필요한 것:

category별 starter template metadata
예:
- health starter
- finance starter
- planning starter
- memory starter

각 starter가 포함해야 할 것:

권장 manifest 필드
권장 permissions
권장 webhook events
권장 analytics metric
UX checklist

B2 완료 기준

portal에서 새 모듈 생성 시 “빈 draft” 말고 starter 선택 가능

B3. Review Readiness를 Category-aware로 확장

현재 review readiness는 일반 metadata 중심이다. 이제 카테고리별 요구사항을 분리해야 한다.

예:

health
- privacy / support 더 엄격
finance
- legal/accuracy warning
education
- 대상 연령 / 보호자 설명
memory
- content handling / delete policy

B3 완료 기준

admin review 화면에서 category별 체크포인트가 표시

B4. Analytics Metric 확장

현재 analytics는 installs/uninstalls/apiCalls/errors 중심이다.

카테고리별 예시:

health
- check completion count
finance
- tracked item count
planning
- active item count
memory
- created entry count

주의:

category별 custom analytics는 1차엔 표준 metric registry로만 설계
실제 집계는 2차

5. Workstream C: Developer Portal Expansion

C1. “Create Module”을 Product-aware로

현재 portal의 create module은 generic form이다.

필요한 것:

“무슨 종류의 모듈을 만들 건가요?”를 먼저 묻는 화면
category 선택 후 starter 적용

C2. Docs 연결 강화

portal 안에서 category별 docs로 바로 연결해야 한다.

예:

health module 만들기
- health starter guide
finance module 만들기
- finance starter guide

C3. Publisher Dashboard 확장

필요한 것:

category별 module distribution
draft stuck reason
review checklist completion
required fields progress

6. 실행 순서

가장 현실적인 순서는 아래다.

Phase H1. App Hardening Foundation

공통 edit/delete UX
reminder 계산 규칙
detail layout 규칙

Phase H2. Tier 1 App Modules Polish

bills
health
school
projects

Phase H3. Cross-module Links

meal -> shopping
projects -> shared_budget / calendar
school -> calendar
health -> calendar
growth -> memories
family_story -> memories / archives

Phase P1. Engine Category Layer

category taxonomy
starter template metadata
review readiness extension

Phase P2. Portal Productization

category-first create flow
starter selection
docs jump
dashboard progress

7. 리스크

리스크 1. 모듈 수는 늘었지만 UX 일관성이 떨어질 수 있음

대응:

공통 detail/edit pattern 먼저

리스크 2. cross-module link가 ad hoc string reference로 흐를 수 있음

대응:

ModuleEntityRef만 사용

리스크 3. 퍼블리셔 포털이 너무 generic해서 실제 module creation productivity가 낮을 수 있음

대응:

starter template과 category-aware flow를 먼저 넣음

리스크 4. health/finance category는 review 기준이 더 엄격해야 함

대응:

category-specific readiness 분리

8. 바로 다음 액션

다음 액션은 아래가 맞다.

membloc-app에서 공통 edit/delete UX lane 설계
bills / health / school / projects 순으로 detail polish
meal -> shopping, projects -> shared_budget link 구현
membloc-app-engine에 category taxonomy 및 starter metadata 설계 추가
membloc-developer-portal에 category-first create flow 설계

9. 결론

이제 Membloc은 “모듈이 거의 없는 가족 앱” 단계는 지났다.

다음 단계는 두 가지다.

앱 안에서는 모듈을 실제 생활 도구 수준으로 다듬고
플랫폼 쪽에서는 이 모듈군을 외부 퍼블리셔가 재현 가능하게 만든다

즉, 다음 분기 목표는 “모듈 수 확장”보다 “모듈군 제품화 + 플랫폼화”가 맞다.

SDK assets

Static SDK files

JavaScript runtime and TypeScript definitions are served from this docs app.

membloc-sdk.js membloc-sdk.d.ts