ADR-0003: 서비스 폴더 구조 — 4-way 분할 (User / Partners / Store / Admin)
- 일자: 2026-05-10
- 상태: ⚠️ Superseded by ADR-0004 — 서비스 폴더 구조 v2 (2026-05-10)
- 결정자: cony@yumyum.im
- 관련: ADR-0001 — 수수료 정책, ADR-0002 — 사장님 앱 영문 표기, 용어 정의
이 ADR 은 ADR-0004 로 대체되었습니다. "Partners 포털은 본질적으로 웹사이트" 라는 인사이트를 반영하여, Partners 를 별도 서비스로 분리하지 않고 마케팅 사이트(Marketing) 와 사장님 운영 포털(Store-Portal) 로 분할했습니다. 결정 배경은 ADR-0004 참조.
배경 (Context)
/20-product/ 에 4개 제품군을 카탈로그로 정리하면서, 각 제품의 코드 / 디자인 / 문서 단위 명명 규약이 필요해졌다.
- 4개 제품군: 냠냠픽업 App / 사장님 포털 / 사장님 주문접수 / 운영 어드민
- 각 제품은 사용자 군이 명확히 다름 (B2C 고객 / B2B 입점 / B2B 운영 / 내부 운영팀)
- Figma 파일도 동일 구조로 분할되어 있음 (
User/Partners/Store/Admin) - 향후 코드 레포 / 문서 섹션 / Figma 페이지의 명명을 일치시키지 않으면 인지 비용이 누적됨
결정 (Decision)
서비스 단위 명명·폴더 구조를 YumYum- prefix + 사용자 군별 4-way 분할로 통일한다.
| 코드명 | 한국어 | 사용자 | 플랫폼 |
|---|---|---|---|
User | 냠냠픽업 App | 고객 (User) | iOS / Android |
Partners | 사장님 포털 | 사장님·법인·체인 (Partners) | Web (partners.yumyum.im) |
Store | 사장님 주문접수 | 사장님 (Merchant) | iOS/Android (스토어앱) + Windows (POS) |
Admin | 운영 어드민 | 냠냠픽업 운영팀 | Web (내부) |
적용 범위
- 문서: /20-product/ 하위에 4개 폴더 생성, 각 폴더
index.md= 서비스 개요 - Figma: 동일 명명 (
User,Partners, …) 사용 - 코드 레포 / 빌드 산출물: 동일 명명 사용 (예:
User-iOS,Partners-Web) - 앱스토어 등록명 / 마케팅명: 한국어 명칭 사용 (예: "냠냠픽업", "냠냠픽업 스토어")
Store 의 범위
- 스토어앱(iOS/Android) + POS(Windows) 두 채널을 같은 코드명 우산 아래 둠
- 이유: 둘 다 "사장님이 매장에서 주문을 받는다" 는 동일 가치 제안. 채널만 다를 뿐 도메인 모델·용어가 같음
- POS 를 별도 코드명(
POS)으로 분리하지 않음
근거 (Rationale)
1. 사용자 군별 분리가 가장 안정적인 경계
- B2C(User) / B2B 입점(Partners) / B2B 운영(Store) / 내부(Admin) — 권한·도메인·UX 모두 상이
- 플랫폼 기준(iOS / Web 등) 또는 기능 기준(주문 / 정산 등)으로 나누면, 시간이 지나며 경계가 흐려짐
- 사용자 군은 시간이 지나도 변하지 않는 가장 안정적인 축
2. 글로서리·기존 결정과 정합
User/Merchant/Partners/Store모두 용어 정의에 이미 표준 용어로 등재Partners는 도메인(partners.yumyum.im)과 직결Store는 ADR-0002 의Store App결정과 정확히 일치 —Store코드명이 곧 Store App + POS 의 우산
3. Figma·코드·문서 어휘 일치 → 인지 비용 ↓
- 디자이너가
Partners페이지 작업 → 개발자가Partners레포 본다 → 문서도 같은 이름 - 회의·슬랙·이슈에서 "스토어앱이요" / "사장님 앱이요" / "Merchant App 이요" 같은 용어 혼선 차단
4. 고려한 대안
대안 A: 기능 단위 분할 (예: 주문 / 결제 / 정산 / 회원) (기각)
- 장점: 백엔드 설계와 가까움
- 기각: 사용자 입장에서 의미 없음. 같은 "주문" 도 고객 vs 사장님 vs 운영팀이 보는 화면이 완전히 다름
대안 B: 플랫폼 단위 분할 (iOS / Android / Web / Windows) (기각)
- 장점: 빌드 파이프라인과 가까움
- 기각: 같은 사용자(사장님)가 두 플랫폼을 쓰는 경우(스토어앱 + POS)가 있어 분리되면 도메인 일관성 ↓
대안 C: User / Merchant / Admin 3-way (기각)
- 장점: 더 단순
- 기각:
Partners(입점·계약·마케팅)와Store(매장 운영)는 사장님이 사용하지만 사용 맥락이 완전히 다름. 한 폴더로 합치면 화면·권한·코드가 뒤섞임
결과 (Consequences)
긍정
- 4개 서비스의 명명 규약 통일 → Figma·코드·문서·회의 모두 같은 어휘 사용
- 신규 화면·기능 추가 시 소속 결정이 명확 ("사장님이 매출을 본다" → Partners 가 아니라 Store? 같은 모호함을 글로서리·ADR 로 해결 가능)
- Phase 0/1/2 우선순위 적용 시 단위가 명확 — Phase 0 = User + Store + Admin 최소, Phase 1 = Partners 셀프 입점 등
주의 / 후속 필요
- Phase 우선순위 결정 필요 — 본 ADR 은 폴더 구조만 결정. 어떤 서비스를 언제 만들지는 별도 합의 필요 (Phase 0/1/2 가설은 /20-product/ 표 참조, 정식 결정은 후속 ADR 또는 로드맵 문서)
- Store 우산 안의 App vs POS 분리 시점 — 둘이 화면·기능이 충분히 분기되면 후속 ADR 로
POS분리 검토 - 글로서리 추가 항목 필요 — 코드명(
User등)을 글로서리에 추가하여 검색 가능하게
후속 작업
- [x] /20-product/ 4개 폴더 생성 + 각
index.md골격 작성 - [x] /20-product/yumyum-user/screens.md 로 기존 화면 명세 이동 (이후 ADR-0004 에서
/20-product/yumyum-10-user/screens로 다시 이동) - [x] 사이드바 config 업데이트 (4개 서비스 노출)
- [ ] 글로서리에 코드명 4개 추가 (
User/Partners/Store/Admin) - [ ] Phase 0/1/2 정식 결정 ADR 또는 로드맵
- [ ] Figma 파일 페이지명 본 ADR 명명과 정합 확인
- [ ] 코드 레포 신규 생성 시 본 ADR 명명 적용