Skip to content

ADR-0004: 서비스 폴더 구조 v2 — User / Store / Marketing / Admin

이 ADR 은 ADR-0005 로 대체되었습니다. 쿠팡이츠 웹 구조(www / partners / store 3개 도메인 분리)를 검토한 결과 Partners 를 별도 서비스로 복귀하는 게 합리적이라 판단. ADR-0005 가 5-way 구조(User / Store / Marketing / Partners / Admin)로 확장합니다.

배경 (Context)

ADR-0003 직후 디렉터리 구조를 점검하던 중 두 가지 인사이트가 도출되었다.

  1. "Partners 포털은 본질적으로 웹페이지(=마케팅·랜딩)"partners.yumyum.im 의 핵심은 잠재 사장님에게 입점을 권유하는 정보 페이지. 로그인 후 매장 운영 도구는 별도 본질.
  2. 사장님이 매장을 운영하는 도구는 다채널 — 책상의 PC(웹포털) / 매장 현장의 모바일앱 / 카운터의 POS. 세 채널이 같은 도메인 모델을 공유. 묶는 게 자연스러움.

이로써 ADR-0003 의 4분할(User / Partners / Store / Admin)에서:

  • Partners 단독 서비스는 어휘 경계가 흐려짐 (Partners = "사장님" 인지, "사장님 + 법인/체인" 인지, "marketing 도메인" 인지)
  • Store 가 모바일앱 + POS 두 채널만 품기엔 사장님 운영 전반을 표현하기 부족함

결정 (Decision)

4 최상위 + Store 3채널 구조로 변경.

최상위 4개

코드명한국어사용자플랫폼
User냠냠픽업 App고객 (User)iOS / Android
Store사장님 운영 도구 (3채널 우산)사장님 (Merchant)Web + iOS/Android + Windows
Marketing마케팅 사이트잠재 고객 / 잠재 사장님 / 일반Web (www.yumyum.im + partners.yumyum.im)
Admin운영 어드민운영팀Web (내부)

Store 안의 3채널

코드명한국어플랫폼
Store-Portal사장님 운영 포털Web (로그인 후)
Store-App냠냠픽업 스토어앱iOS / Android
Store-POS냠냠픽업 POSWindows

명명 규약

  • NN- 숫자 prefix를 폴더·코드명에 적용 (10/20/30/40 …) — 정렬 안정성 + 추후 삽입 여유
  • 코드명은 kebab-case (예: yumyum-10-user)
  • 한국어 명칭은 마케팅·UI 노출용 (예: "냠냠픽업", "냠냠픽업 스토어")

적용 범위

  • 문서: /20-product/ 하위 4 폴더 + Store 안 3 폴더
  • Figma: 동일 명명
  • 코드 레포 / 빌드 산출물: 동일 명명
  • 앱스토어 등록명·마케팅명: 한국어 명칭 사용

근거 (Rationale)

1. 입점 안내(Marketing) ↔ 운영 포털(Store-Portal) 분리가 본질에 부합

  • partners.yumyum.im 으로 들어오는 사람: 로그인 안 한 잠재 사장님 → 마케팅 콘텐츠 / 입점 신청 진입
  • 입점 후 매장 세팅하는 사람: 로그인한 사장님 → 운영 도구
  • 두 사용자 맥락은 시간축·권한·가치 제안이 다름 → 같은 폴더에 묶으면 화면·라우팅·권한이 뒤섞임
  • Marketing 와 Store-Portal 로 나누면 로그인 경계 = 폴더 경계 가 자연스럽게 일치

2. Marketing 우산이 partners.yumyum.im 만이 아님

  • www.yumyum.im (사용자 앱 다운로드 랜딩)
  • partners.yumyum.im (사장님 입점 안내)
  • 매뉴얼 / FAQ / POS 다운로드 페이지 / 공지·블로그 등
  • 모두 로그인 없는 정적/마케팅 콘텐츠 라는 공통 본질 → Marketing 우산이 합리적

3. Store 가 3채널을 품는 게 사장님 도메인 일관성에 유리

  • 매장 / 메뉴 / 주문 / 영업 상태 등 도메인 모델이 세 채널 모두 동일
  • 채널 차이는 사용 맥락 만 다를 뿐 (책상 PC / 현장 모바일 / 카운터 POS)
  • 같은 우산에 두면 도메인 모델·용어·문서가 한 곳에 모임 → DRY

4. 숫자 prefix 의 효용

5. 고려한 대안

대안 A: ADR-0003 그대로 (Partners 별도 유지) (기각)

  • 기각: Partners 라는 이름이 "사장님" 인지 "마케팅 페이지" 인지 모호. 글로서리 정의로도 양립 어려움 (Partners = 법인·체인 상위 개념인데 페이지 도메인은 입점 안내 마케팅).

대안 B: Marketing 를 만들지 않고 Marketing 도 Store / User 안에 분산 (기각)

  • 기각: 로그인 경계가 흐려짐. www.yumyum.im 메인 랜딩이 어디 소속인지 모호.

대안 C: Store / POS 분리 (POS) (기각)

  • 기각: ADR-0003 결정과 동일 — 도메인 모델 공유. 같은 우산이 자연스러움.

결과 (Consequences)

긍정

  • 로그인 경계 = 폴더 경계 일치 → 라우팅·권한·UX 흐림 차단
  • 마케팅 / 정적 콘텐츠를 한곳(Marketing)에 모음 → SEO·CMS·디자인 일관성 ↑
  • 사장님 운영 도구 3채널을 한 우산(Store)에 모아 도메인 모델 공유
  • 숫자 prefix 로 추후 서비스 추가 시 정렬 안정

주의 / 후속 필요

  • Partners 글로서리 정의 보강 — 코드 도메인에서 "Partners" 단독 폴더가 사라졌으므로, 글로서리에 "Partners = B2B 상위 개념(법인·체인 본사·기업), 입점 도메인 명칭 (partners.yumyum.im) 으로 사용" 명시
  • Marketing 의 sub-페이지 트리 결정www.yumyum.impartners.yumyum.im 를 한 코드 레포로 다룰지, 분리할지 별도 검토
  • Phase 0 우선순위 재확인 — User App / Store-App / Store-POS / Admin 중 무엇을 먼저 (Phase 0 정식 ADR 또는 로드맵)
  • CLAUDE.md / README.md 폴더 표 업데이트 (20-product/ 설명에 새 구조 반영)

후속 작업

  • [x] /20-product/ 폴더 재편 (yumyum-10-user / yumyum-20-store / yumyum-30-marketing / yumyum-40-admin)
  • [x] yumyum-20-store/ 안에 store-10-portal / store-20-app / store-30-pos 골격
  • [x] /20-product/index.md 카탈로그 갱신
  • [x] ADR-0003 상태를 Superseded 로 표시
  • [x] 사이드바 config 갱신
  • [ ] 글로서리에 코드명 추가 (User, Store, Store-Portal 등)
  • [ ] Phase 0/1/2 정식 결정 ADR 또는 로드맵
  • [ ] Figma 파일 페이지명을 본 ADR 명명과 정합 확인
  • [ ] 코드 레포 신규 생성 시 본 ADR 명명 적용

냠냠픽업 — 지속가능한 중개수수료 2% 음식 픽업 서비스