이 문서는 Organization / Service / Project의 개념과 경계를 설명하는 페이지입니다. 계정 생성, 조직 생성, 멤버 초대, 서비스 활성화, 프로젝트 생성 등의 실행 절차는 빠른 시작 가이드(Quick Start) 에서 안내합니다.

기본 계층 구조

Organization (조직)
├── Service A (예: Stablecoin Manager)
│   ├── Project 1 (Sandbox)
│   └── Project 2 (Production)
├── Service B (예: Wallet Hub / Wallet SDK 등)
│   └── Project 
├── Service C (예: Staking Hub)

조직 (Organization)

Organization은 DSRV Portal의 최상위 관리 단위이며, 일반적으로 한 고객사(회사/기관) 를 대표합니다. 기관 고객은 Organization 단위로 서비스 이용 계약, 사용자 관리, 서비스 활성화, 지갑(자산 관리) 등 운영의 뼈대를 구성하게 됩니다.

Organization이 존재하는 이유

목적	설명
고객사 단위 분리	서로 다른 기관 고객의 데이터·운영을 구조적으로 분리
운영 주체 정의	“누가 무엇을 운영하는가”의 기준 단위(기관/법인/팀)
서비스·프로젝트 묶음	동일 고객사 내 여러 서비스와 프로젝트를 한곳에서 관리

주요 특징

항목	설명
멀티 소속 가능	하나의 사용자 계정이 여러 Organization에 소속될 수 있음 (예: 그룹사/자회사 운영)
독립 운영	Organization마다 멤버 구성, 서비스 활성화 현황, 지갑/자산 관리가 독립적으로 관리됨
통합 진입점	DSRV Portal에서 서비스 설정 및 프로젝트 운영은 항상 “어느 Organization에서 작업하는지”를 기준으로 진행됨

서비스 (Service)

Service는 Organization 하위에서 활성화하여 사용하는 개별 제품 단위입니다. DSRV Portal은 하나의 콘솔에서 여러 서비스를 제공하며, 고객사는 필요한 서비스만 선택해 활성화하고 운영할 수 있습니다.

Service가 존재하는 이유

목적	설명
제품 단위 분리	Stablecoin, Staking, Wallet, Custody 등 제품/도메인별로 기능·데이터 모델이 다름
선택적 확장	고객사가 필요한 서비스만 도입하고 점진적으로 확장 가능
운영 책임 구분	서비스별 운영 범위(설정, 모니터링, API 연동 등)를 명확히 분리

서비스 예시

(환경에 따라 명칭/구성은 변동될 수 있으나, 문서 기준 대표 서비스는 아래와 같습니다.)

서비스	설명
Stablecoin Manager	스테이블코인 기반 결제·송금·정산 인프라
Staking Hub	스테이킹 운영/연동을 위한 인프라 및 관리 기능
Wallet Hub / Wallet SDK	MPC/TSS 기반 지갑 기능을 서비스/SDK 형태로 제공
Custody	기관 대상 자산 보관 및 운영 인프라
My Smart Account	Organization 단위 지갑 및 계정 운영(조직 지갑 관리)

프로젝트 (Project)

Project는 특정 Service 안에서 운영 환경과 데이터 경계를 분리하는 기본 단위입니다. 하나의 Organization은 동일한 Service 내에서 여러 개의 Project를 동시에 운영할 수 있으며, 각 Project는 서로 완전히 독립된 데이터 저장소와 설정을 가진 운영 단위로 동작합니다.

즉, Project는 단순히 Sandbox / Production을 나누기 위한 개념이 아니라, 서비스·사업·시스템 단위로 운영을 분리하기 위한 구조적 구분입니다.

Project가 존재하는 이유

목적	설명
운영 단위 분리	동일 서비스라도 사업, 시스템, 고객군 단위로 운영을 분리
데이터 경계 확보	고객·거래·설정 데이터가 Project 단위로 완전히 분리됨
연동 구조 표준화	API Key, Webhook, 정책을 Project 단위로 독립 관리
리스크 격리	특정 Project의 장애·오연동이 다른 Project에 영향 미치지 않도록 설계

📘
Project는 “환경”이 아니라 운영 컨텍스트 입니다. 하나의 회사가 여러 개의 데이터베이스와 연동 구조를 병렬로 운영하기 위한 단위입니다.

Project 유형

Project는 목적에 따라 Sandbox 또는 Production으로 구분되며, 각 Project는 서로 독립된 운영 단위로 설계되어 있으며 데이터와 설정이 완전히 분리됩니다.

유형	목적	네트워크 예시
Sandbox	개발, 테스트, 연동 검증	Testnet (Sepolia 등)
Production	실제 서비스 운영	Mainnet

📘
Sandbox / Production의 차이는 단순한 서버 구분이 아니라 데이터 사용 여부, 운영 통제 수준, 감사 대상 여부가 달라지는 구조적 분리를 의미합니다.

Project 단위로 독립 관리되는 항목

각 Project는 아래 항목들을 다른 Project와 완전히 분리하여 관리합니다.

항목	의미
API Key	Project 전용 Key 발급 (타 Project와 호환 불가)
데이터(고객·거래·설정)	Project별 독립 DB 구조
Webhook / Callback	Project별 엔드포인트 및 이벤트 설정
연동 정책 및 파라미터	수수료, 한도, 처리 방식 등 운영 정책 분리

📘
하나의 Service 안에 여러 Production Project가 존재할 수 있으며,각 Production Project는 서로 다른 실제 서비스 또는 시스템을 담당할 수 있습니다.

예외사항

DSRV Portal의 대부분의 서비스는 Project 단위로 운영되지만, 모든 서비스가 Project 구조를 사용하는 것은 아닙니다.

예를 들어, Staking Hub는 서비스 특성상 Organization 단위에서 직접 관리되며, 별도의 Project를 생성하지 않고 Organization 범위 내에서 운영됩니다. 이는 스테이킹 운영이 조직 단위의 자산과 정책을 기준으로 이루어지기 때문이며,

서비스의 성격에 따라 운영 단위가 Organization 또는 Project로 구분될 수 있음을 의미합니다.

권장 운영 구조

아래는 동일 Service에서 여러 개의 Project(DB)를 병렬 운영하는 전형적인 구조 예시입니다.

Organization: [회사명]
├── Stablecoin Manager
│   ├── Project: payment-sandbox        (개발/연동 테스트)
│   ├── Project: payment-production     (결제 서비스 운영)
│   ├── Project: settlement-production  (정산 시스템 운영)
│   └── Project: internal-production    (내부 운영/관리용)
├── Wallet Hub / Wallet SDK
│   ├── Project: sdk-sandbox
│   └── Project: sdk-production
├── Staking Hub

이 구조가 의미하는 바

하나의 회사가
- 여러 개의 실제 서비스
- 여러 개의 백엔드 시스템
- 서로 다른 운영 목적 를 동일 Service 내에서 Project 단위로 분리 운영할 수 있음
특정 Project의 장애·정책 변경·연동 이슈가 다른 Project나 다른 서비스에 직접적인 영향을 주지 않음

환경 분리 및 다중 Project 운영의 효과

구분	Sandbox	Production
목적	개발·테스트·검증	실제 서비스별 운영
API Key	테스트 전용	서비스/시스템별 전용
데이터	테스트 데이터	서비스별 실제 데이터
운영 리스크	낮음	Project 단위로 격리