Leyve Docs

다크모드

저장소 네이밍 — 상세 규칙 ​

상태: 확정

적용 대상: Leyve 제품·서비스·플랫폼 저장소

정본: 이 문서

요약: 저장소 네이밍 — 한눈에 보기

1. 결정 ​

저장소 이름은 사용자가 들어오는 surface, 업무 규칙을 소유하는 domain, 실제로 배포되는 component 또는 platform을 구분해서 표현합니다.

text
# 사용자 접점
leyve-{surface-id}-{client-platform}

# 업무 백엔드
leyve-{domain}-{backend-component}

# 공유 실행 기반
leyve-{shared-platform}

# 예외: 하나의 surface가 UI와 durable backend를 한 단위로 소유
leyve-{surface-id}

핵심 결정은 다음과 같습니다.

  1. console, customer-portal, staff-portal, customer-kiosk, staff-kiosk, partner-center, ops-center, www를 표준 surface ID로 사용합니다.
  2. bare portal, kiosk, center는 신규 저장소에서 사용하지 않습니다.
  3. customer는 개인과 사업자 고객을 모두 포함합니다. consumer는 사용하지 않습니다.
  4. staff는 고객사 직원을 뜻합니다. Leysys 본사 운영자는 ops입니다.
  5. surface는 client platform 또는 bff와, domain은 service, api, worker와 결합합니다.
  6. service는 백엔드 업무 서비스이며 full-stack을 뜻하지 않습니다.
  7. suffix 없는 full-stack surface는 코드·데이터·배포 경계가 실제로 하나일 때만 ADR로 승인합니다.

이 문서는 국제 표준 규격을 주장하지 않습니다. 전 세계 모든 조직에 적용되는 단일 저장소 이름 표준은 없습니다. 널리 쓰이는 customer portal, partner center, backoffice, BFF, bounded context, adaptive UI의 의미를 Leyve의 사용자·권한·배포 경계에 맞게 고정한 내부 표준입니다.

2. 이름 문법 ​

2.1 사용자 접점 ​

text
leyve-{surface-id}-{client-platform}

예:

text
leyve-console-web
leyve-customer-portal-ios
leyve-ops-center-android

surface-id는 하나의 완성된 식별자입니다. customer-portal처럼 audience와 experience type이 결합된 값도 하나의 surface ID로 취급합니다.

2.2 업무 백엔드 ​

text
leyve-{domain}-{backend-component}

예:

text
leyve-billing-service
leyve-auth-api
leyve-subscription-worker

console, portal, center는 업무 domain이 아닙니다. 접점을 없애도 billing, CRM 같은 업무 능력은 남으므로 surface와 domain을 같은 축으로 취급하지 않습니다.

2.3 Form factor가 실제 배포 경계인 경우 ​

text
leyve-{surface-id}-{form-factor}-{client-platform}

예:

text
leyve-console-mobile-web
leyve-console-tablet-ios
leyve-staff-kiosk-tablet-android

surface와 domain의 토큰 순서는 바꾸지 않습니다.

text
brand → surface-id → form factor(선택) → client-platform
brand → domain → backend-component

모든 토큰은 영문 소문자 kebab-case를 사용합니다. api, bff, ios처럼 업계에서 통용되는 약어 외에는 임의 축약을 만들지 않습니다.

2.4 Full-stack surface 예외 ​

한 surface의 UI, durable backend 업무 책임, 데이터 소유권, 배포·장애 경계가 실제로 하나라면 component suffix를 생략할 수 있습니다.

text
leyve-{surface-id}

작은 server route가 함께 있다는 이유로 이 예외를 사용하지 않습니다. 신규 저장소가 suffix를 생략하려면 제13절의 항목을 ADR로 먼저 승인해야 합니다.

3. 최종 Surface 체계 ​

3.1 고정 목록과 정렬 순서 ​

문서, 카탈로그, 대시보드에서 surface 저장소를 나열할 때는 다음 순서를 사용합니다.

순서surface ID정의
1console고객사 관리자·실무자가 Leyve 핵심 업무를 수행하는 기본 workspace
2customer-portal고객이 자신의 정보·계약·서비스를 이용하는 self-service 접점
3staff-portal고객사 직원이 개인 업무와 직원 self-service를 처리하는 접점
4customer-kiosk고객이 공용 단말에서 조회·결제 등 짧은 업무를 처리하는 접점
5staff-kiosk고객사 직원이 공용 터치 단말에서 출퇴근·휴가 등 빠른 업무를 처리하는 접점
6partner-center총판·리셀러가 자기 고객·결제·운영을 관리하는 backoffice
7ops-centerLeysys 본사가 고객·파트너·CRM·결제·정책을 통합 관리하는 backoffice
8www불특정 방문자에게 브랜드·제품 정보와 문의 경로를 제공하는 공개 접점

권장 카탈로그 정렬값은 각각 10, 20, 30, 40, 50, 60, 70, 80입니다.

text
leyve-console-web

leyve-customer-portal-web
leyve-staff-portal-web

leyve-customer-kiosk-web
leyve-staff-kiosk-web

leyve-partner-center-web
leyve-ops-center-web

leyve-www-web

3.2 Audience 어휘 ​

audience의미포함하지 않는 대상
customerLeyve와 이용·계약 관계인 개인·사업자 계정 및 그 대표 사용자 persona총판·리셀러, Leysys 본사 운영자
staff고객사 또는 현장 조직 소속자의 employee self-service personaLeysys 본사 직원, 파트너 관리자
partnerLeysys의 총판·리셀러와 그 관리 사용자일반 고객, Leysys 본사 운영자
opsLeysys 본사에서 고객·파트너·플랫폼을 운영하는 사용자고객사 직원, 파트너 사용자

consumer는 일반적으로 최종 개인 소비자의 뉘앙스가 강합니다. Leyve 고객에는 개인사업자와 법인사업자가 포함되므로 더 넓고 계약 관계가 분명한 customer를 사용합니다.

staff는 회사의 내부 직원이라는 상대적 표현이므로 주체를 반드시 고정해야 합니다. Leyve 네이밍에서 staff는 고객사 직원이고, Leysys 본사 직원은 ops입니다.

3.3 Experience type 어휘 ​

experience type판정 기준
portal사용자가 자기 정보·계약·서비스를 조회하거나 요청하는 self-service
kiosk공유 단말, 짧은 세션, 터치 중심, 제한된 빠른 업무라는 사용 방식
center다른 고객·조직·결제·운영 대상을 관리하는 역할 기반 backoffice

portal과 center는 화면 모양이 아니라 권한 방향으로 구분합니다.

  • portal: 자신의 정보와 서비스를 이용합니다.
  • center: 관리 권한으로 다른 대상과 운영 흐름을 관리합니다.

kiosk는 태블릿의 동의어가 아닙니다. 휴대폰·태블릿·데스크톱 어느 크기에서도 구현될 수 있으며, 공유 단말과 짧은 흐름이라는 사용 방식이 핵심입니다.

3.4 허용 조합 ​

기본 surface 문법으로 허용하는 audience × experience type 조합은 다음 여섯 개입니다.

text
customer + portal
staff    + portal
customer + kiosk
staff    + kiosk
partner  + center
ops      + center

console과 www는 audience 접두어를 붙이지 않는 예약된 독립 surface입니다.

다음 조합은 신규 저장소에서 사용하지 않습니다.

text
portal
kiosk
center
consumer-portal
consumer-kiosk
staff-center
admin-center

새로운 audience × experience 조합이 필요하면 이름부터 만들지 말고 사용자, 권한, 데이터 범위, 독립 배포 필요성을 ADR로 먼저 확정합니다.

4. Client platform과 Form factor ​

4.1 Client platform ​

현재 승인된 client platform은 다음 세 가지입니다.

text
web
ios
android
  • web: 브라우저로 제공되는 앱입니다. SPA, SSR, SSG를 모두 포함하며 정적 파일만을 뜻하지 않습니다.
  • ios: iOS/iPadOS 계열에서 제공되는 native 또는 hybrid 앱입니다.
  • android: Android 계열에서 제공되는 native 또는 hybrid 앱입니다.

macos, windows 등 새로운 client platform은 저장소에서 먼저 사용하지 않고 ADR로 표준 목록에 추가합니다. 플랫폼을 이름에 직접 적을 수 있으므로 의미가 모호한 app suffix는 기본값으로 사용하지 않습니다.

4.2 반응형·adaptive 기본값 ​

form factor가 없으면 해당 platform이 지원하는 화면 크기에 반응형 또는 adaptive로 대응한다는 뜻입니다.

text
leyve-console-web       # 지원하는 web 화면 크기에 반응
leyve-console-ios       # 지원하는 iOS/iPadOS 화면 크기에 적응
leyve-console-android   # 지원하는 Android mobile/tablet 화면 크기에 적응

4.3 별도 앱에만 Form factor 추가 ​

허용하는 form factor는 다음 세 가지뿐입니다.

text
mobile
tablet
desktop

화면 크기별로 저장소, 빌드, 배포 경계가 실제로 분리될 때만 추가합니다.

text
leyve-console-mobile-web
leyve-console-tablet-web
leyve-console-desktop-web

leyve-console-mobile-ios
leyve-console-tablet-ios

leyve-console-mobile-android
leyve-console-tablet-android

CSS breakpoint, 레이아웃 차이, 태블릿 사용 비중만으로 저장소를 나누지 않습니다. iphone, ipad, galaxy 같은 제품명은 사용하지 않습니다.

허용되는 대표 조합은 다음과 같습니다.

client platformform factor 생략허용할 수 있는 분리형 form factor
web반응형 webmobile, tablet, desktop
iosiOS/iPadOS adaptive appmobile, tablet
androidAndroid adaptive appmobile, tablet

desktop-ios, desktop-android처럼 platform이 지원하지 않는 조합은 사용하지 않습니다.

4.4 iOS·Android를 함께 빌드하는 저장소 ​

현재 표준은 하나의 저장소가 하나의 client platform delivery boundary를 가진다고 가정합니다. Capacitor, React Native, Flutter 등으로 한 저장소에서 iOS와 Android 산출물을 함께 만든다면 다음 중 하나를 아키텍처 ADR로 먼저 결정합니다.

  1. platform별 delivery 저장소와 공유 package로 분리
  2. multi-platform monorepo를 유지하고 새로운 표준 token을 추가

이 결정 전에는 -app, -mobile, 하나의 임의 platform suffix를 사용하지 않습니다. 현재 문서는 multi-platform repository name을 미리 승인하지 않습니다.

5. Scope와 Component 호환 규칙 ​

scope 종류권장 component 또는 platform기본적으로 피할 조합
Surfaceweb, ios, android, bffservice, api, worker
Domainservice, api, workerweb, ios, android
Shared platformserver, gatewaysurface·domain 전용 suffix
Full-stack surface 예외suffix 없음, ADR 필수service, app으로 full-stack 표현

교차 예외는 다음 두 경우만 인정합니다.

  1. 한 surface만을 위한 백엔드 조합 계층은 {surface-id}-bff로 표현합니다.
  2. 하나의 domain을 위한 화면이 실제로 독립 제품·진입점·배포 단위라면 ADR 승인 후 {domain}-{client-platform}을 사용할 수 있습니다.

따라서 아래 이름은 기본적으로 만들지 않습니다.

text
leyve-console-service
leyve-ops-center-service
leyve-partner-center-service
leyve-console-api
leyve-ops-center-api

화면별 인증 흐름, 읽기 모델, API 조합은 BFF가 담당하고 핵심 업무 규칙과 데이터 불변식은 domain service 또는 기존 leyve-server가 담당합니다.

6. Backend component 정의 ​

6.1 bff ​

Backend for Frontend입니다. 특정 surface가 필요로 하는 인증 흐름, 여러 API의 조합, 응답 변환, 화면 전용 읽기 모델을 담당합니다.

text
leyve-console-bff
leyve-customer-portal-bff
leyve-ops-center-bff

BFF에 여러 domain의 핵심 업무 규칙을 복제하지 않습니다. surface마다 이름을 맞추기 위해 빈 BFF 저장소를 미리 만들지도 않습니다.

다음 서버 코드는 BFF로 분류하지 않습니다.

  • web 저장소와 함께 배포되는 SSR, form action, surface 지원 route → 계속 {surface-id}-web
  • durable 결제 callback·webhook·업무 mutation → 해당 domain service 또는 worker
  • provider adapter와 provider secret 소유 → 해당 공통 domain/platform backend

BFF는 surface 전용 조합 계층이지 surface에 필요한 모든 서버 코드의 통칭이 아닙니다.

6.2 service ​

하나의 bounded context와 업무 규칙을 소유하고 독립적으로 배포되는 백엔드 서비스입니다.

text
leyve-billing-service
leyve-crm-service
leyve-subscription-service

service는 full-stack을 뜻하지 않습니다.

6.3 api ​

API 계약과 배포 생명주기가 service 구현과 실제로 분리될 때 사용합니다.

text
leyve-auth-api

service가 HTTP API를 제공한다는 이유만으로 api 저장소를 추가하지 않습니다. 특정 surface만을 위한 API 조합 계층이라면 bff가 더 정확합니다.

6.4 worker ​

큐 소비, 배치, 스케줄 작업처럼 비동기 실행이 독립적으로 배포·확장·격리될 때 사용합니다.

text
leyve-billing-worker

같은 프로세스에서 실행되는 단순 background job은 별도 저장소로 만들지 않습니다.

6.5 server ​

여러 업무 영역을 함께 제공하는 공유 백엔드 또는 모놀리스입니다.

text
leyve-server

server와 service의 차이는 크기가 아니라 소유 경계입니다.

  • 여러 업무 영역을 하나의 배포 단위가 소유하면 server
  • 하나의 bounded context가 독립 배포되면 {domain}-service

leyve-server가 이미 담당하는 기능을 같은 책임의 {domain}-service로 중복 생성하지 않습니다. 분리할 때는 데이터 소유권, 호출 경계, 전환 순서를 ADR에 기록합니다.

6.6 gateway ​

제품 전체의 공통 ingress, 라우팅, 인증 위임, rate limit 등 경계 기능을 담당합니다.

text
leyve-gateway

gateway에는 domain 업무 규칙을 넣지 않습니다. gateway가 하나의 surface만을 위해 응답을 조합한다면 그 역할은 BFF에 더 가깝습니다.

7. Surface별 경계 ​

7.1 Console ​

console은 고객사 관리자와 권한을 가진 실무자가 Leyve의 핵심 업무를 수행하는 기본 workspace입니다.

  • 자기 조직의 상품·업무 모듈 사용
  • 고객사 내부 운영, 회계, 임대차, 관리비 등 핵심 업무
  • 고객사 사용자·권한·설정 관리

console은 Leysys 본사 최고 관리 화면이 아닙니다. 본사 운영 화면은 ops-center입니다.

console과 staff-portal 사용자가 일부 겹칠 수는 있지만 목적이 다릅니다.

  • console: 권한을 가진 관리자·실무자의 핵심 업무 workspace
  • staff-portal: 직원 개인의 신청·조회 중심 self-service

7.2 Customer Portal과 Staff Portal ​

customer-portal은 개인·개인사업자·법인사업자 고객이 자신의 정보와 서비스를 이용하는 접점입니다.

staff-portal은 고객사 직원이 개인 기기에서 급여명세, 휴가, 근무 정보 등 자신의 직원 업무를 이어서 처리하는 접점입니다.

둘 다 self-service이지만 audience와 인증·권한 경계가 다르므로 이름을 분리합니다. 같은 사람이 법인 고객의 대표 사용자이면서 그 조직의 직원일 수는 있습니다. 이 경우 사람의 소속 하나로 surface를 고르지 않고 현재 수행하는 업무·권한 컨텍스트로 고릅니다.

  • 계약 계정, 고객 정보, 고객이 구매한 서비스의 self-service → customer-portal
  • 급여, 휴가, 근태 등 employee self-service → staff-portal

7.3 Customer Kiosk와 Staff Kiosk ​

customer-kiosk는 고객이 공용 또는 현장 단말에서 사용하는 접점입니다.

  • 일반 조회와 안내
  • 본인 확인 후 결제
  • 접수·발급 등 짧은 업무
  • 완료 또는 timeout 후 세션·개인정보 초기화

staff-kiosk는 고객사 직원이 공용 단말에서 빠르게 사용하는 업무 접점입니다.

  • 출근·퇴근 기록
  • 휴가 신청·잔여 휴가 확인
  • 근무 상태 확인
  • 최소 권한과 짧은 세션

태블릿에서 주로 사용하더라도 기본 이름은 각각 leyve-customer-kiosk-web, leyve-staff-kiosk-web입니다. tablet 전용 저장소·빌드·배포가 따로 있을 때만 -tablet-web을 사용합니다.

7.4 Partner Center와 Ops Center ​

두 center는 CRM, 고객, 결제 같은 유사한 기능을 사용하지만 관리 권한과 데이터 범위가 다릅니다.

partner-center ​

총판·리셀러가 자신의 사업 범위 안에서 운영합니다.

  • 자기 조직과 산하 고객 관리
  • 고객 계약·구독·사용량 확인
  • 소속 직원과 권한 관리
  • Leysys에 납부할 결제·청구·정산 확인

ops-center ​

Leysys 본사가 플랫폼 전체를 운영합니다.

  • 직접 고객과 파트너 관리
  • 고객·파트너 CRM, 계약, 구독, 결제 내역
  • 파트너 청구·수납·정산
  • 운영 예외 처리, 정책, 감사, 최고 관리자 기능

본사 영업, 재무, 고객 지원은 우선 ops-center 내부 모듈과 역할로 구분합니다. 별도 팀, 권한 경계, 제품 책임자, 배포 주기, 장애 격리가 실제로 필요해질 때만 독립 surface를 검토합니다.

두 center는 같은 domain backend를 사용할 수 있지만 tenant와 권한 범위는 반드시 백엔드가 검증합니다.

text
partner-center-web
  → partner-center-bff
    → customer / partner / billing domain

ops-center-web
  → ops-center-bff
    → 같은 domain, Leysys operations scope

7.5 WWW ​

www는 로그인 후 핵심 업무를 수행하는 제품 surface가 아니라 불특정 방문자를 위한 공개 홍보·정보 surface입니다.

  • 브랜드와 회사 소개
  • 제품·기능·가격 안내
  • 고객 사례와 콘텐츠
  • 게시판, 상담·도입 문의
  • portal, console 등 제품 surface로의 진입

기본 이름은 다음과 같습니다.

text
leyve-www-web

www는 surface이고 web은 client platform이므로 두 토큰은 중복이 아닙니다. 실제 hostname이 바뀌더라도 공개 홍보 surface의 역할이 같다면 이름을 유지할 수 있습니다.

SSR 서버, 게시판 조회, 문의 폼, 이메일 전송 route가 있다는 사실만으로 web을 빼지 않습니다. 주 제공물이 브라우저 앱이고 서버 기능이 그 surface를 지원한다면 leyve-www-web입니다.

8. 표준 저장소 예시 ​

8.1 Web surface ​

text
leyve-console-web

leyve-customer-portal-web
leyve-staff-portal-web

leyve-customer-kiosk-web
leyve-staff-kiosk-web

leyve-partner-center-web
leyve-ops-center-web

leyve-www-web

8.2 Surface BFF ​

필요한 surface에만 생성합니다.

text
leyve-console-bff
leyve-customer-portal-bff
leyve-partner-center-bff

위 목록은 대표 예시이며 surface별 BFF 생성 체크리스트가 아닙니다. 실제 독립 조합 계층이 없으면 BFF 저장소도 만들지 않습니다.

8.3 Domain backend ​

text
leyve-auth-service
leyve-billing-service
leyve-crm-service
leyve-subscription-worker

Domain 저장소는 카탈로그에서 알파벳순으로 나열합니다. Surface 저장소에는 제3.1절의 고정 순서를 적용합니다.

8.4 Shared platform ​

text
leyve-gateway
leyve-server

9. Web, Backend, Full-stack 판정 ​

web은 정적 배포 방식이 아니라 사용자에게 제공되는 client platform을 뜻합니다.

저장소 책임이름
브라우저 UI가 주 제공물이며 SSR·서버 route가 surface를 지원leyve-{surface-id}-web
한 surface 전용 API 조합 계층이 독립 배포leyve-{surface-id}-bff
하나의 업무 domain과 규칙을 독립 소유leyve-{domain}-service
여러 domain을 하나의 공유 backend가 소유leyve-server
UI와 durable backend 업무 책임을 한 surface가 함께 소유하고 한 단위로 배포leyve-{surface-id} — ADR 예외

full-stack surface는 component suffix를 생략할 수 있지만 드문 예외입니다. 같은 저장소에 frontend와 작은 SSR·form route가 함께 있다는 사실만으로 full-stack으로 판정하지 않습니다. 데이터 소유권, durable 업무 규칙, 배포·장애 경계가 실제로 하나인지 확인하고 ADR로 승인해야 합니다.

독립 결제 callback·webhook·provider adapter를 web 또는 BFF 책임으로 흡수하지 않습니다. 이 코드는 provider-neutral domain service, worker 또는 공통 platform 경계에 둡니다.

의미가 모호한 -app과 full-stack을 뜻하는 -service는 사용하지 않습니다.

10. 생성 판단 순서 ​

새 저장소를 만들기 전에 다음 순서로 판단합니다.

  1. 사용자에게 직접 제공되는 접점인가?
    • 공개 홍보·정보 → www
    • 고객사 관리자·실무자의 핵심 workspace → console
    • 자기 정보·서비스 self-service → audience + portal
    • 공유 단말의 짧은 터치 업무 → audience + kiosk
    • 고객·조직·결제 운영 backoffice → audience + center
  2. 어느 client platform에 배포하는가?
    • web, ios, android
  3. 한 저장소가 iOS와 Android를 함께 산출하는가?
    • 맞으면 이름을 만들기 전에 multi-platform architecture ADR 작성
  4. 화면 크기별 저장소·빌드·배포가 실제로 분리되는가?
    • 아니면 form factor 생략
    • 맞으면 mobile, tablet, desktop 중 하나 추가
  5. UI와 durable backend가 하나의 surface·데이터·배포 경계인가?
    • 맞으면 ADR 승인 후 leyve-{surface-id}
  6. 한 surface만을 위한 독립 조합 backend인가?
    • {surface-id}-bff
  7. 하나의 업무 능력과 규칙을 소유하는가?
    • {domain}-service
  8. API 계약 또는 비동기 실행이 별도로 배포되는가?
    • {domain}-api 또는 {domain}-worker
  9. 여러 업무 영역을 함께 제공하는 공유 backend인가?
    • leyve-server
  10. 제품 전체의 공통 ingress인가?
  • leyve-gateway
  1. 기존 leyve-server나 다른 저장소와 책임이 중복되는가?
  • 중복이면 새 저장소를 만들지 않고 기존 책임을 사용하거나 extraction ADR을 작성

위 질문에 명확히 답하지 못하면 저장소를 먼저 만들지 않습니다.

11. 피해야 할 이름과 권장 대안 ​

피해야 할 이름이유권장 대안
leyve-portal-webaudience가 없음leyve-customer-portal-web
leyve-kiosk-webaudience가 없음leyve-customer-kiosk-web
leyve-center-web운영 주체가 없음leyve-ops-center-web
leyve-consumer-portal-web사업자 고객을 충분히 포괄하지 못함leyve-customer-portal-web
leyve-console-servicesurface가 domain 규칙을 소유하는 것처럼 보임화면 전용은 leyve-console-bff, 업무는 {domain}-service
leyve-console-apisurface 조합 API인지 domain API인지 모호함화면 전용은 leyve-console-bff
leyve-service어떤 업무 backend인지 알 수 없음leyve-{domain}-service
leyve-console-app실행 platform과 delivery 경계가 드러나지 않음단일 platform은 -web, -ios, -android; multi-platform은 ADR
leyve-console-mobileform factor만 있고 platform이 없음leyve-console-mobile-web 등
leyve-console-iphone특정 제품명에 종속leyve-console-mobile-ios
leyve-console-ipad특정 제품명에 종속leyve-console-tablet-ios

12. 기존 저장소와 -proto ​

이 표준은 신규 저장소와 장기 운영 이름에 즉시 적용합니다. 기존 저장소를 이 문서 변경과 동시에 물리적으로 rename하지는 않습니다.

-proto는 component가 아니라 prototype 단계의 lifecycle marker입니다. 기존 leyve-console-proto 같은 이름은 GitHub, 로컬 checkout, 패키지 참조, CI, Amplify, 환경변수, 배포 URL, 문서를 한 번에 전환하는 별도 migration에서 다룹니다.

기존 legacy 이름이 남아 있다는 이유로 bare portal, kiosk, center 또는 surface-specific service를 신규 저장소에 복제하지 않습니다.

13. 예외와 변경 관리 ​

이 체계는 저장소 수를 기계적으로 늘리기 위한 목록이 아닙니다. 독립적인 코드 소유권과 배포 경계가 있을 때 이름을 부여하는 규칙입니다.

기본 조합에서 벗어나거나 기존 저장소를 분리·통합·rename할 때는 ADR에 다음을 기록합니다.

  • 해결하려는 문제
  • 사용자와 권한 범위
  • 코드와 데이터 소유권
  • 빌드·배포·장애 격리 경계
  • 호출 방향과 인증·권한 검증 위치
  • 기존 저장소와의 중복 제거 계획
  • 이름을 선택한 이유와 검토한 대안
  • GitHub·CI·배포·DNS·문서 전환 순서

14. 참고한 업계 용례와 패턴 ​