hansoo/Obsidian
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

초기 커밋

Browse Source
This commit is contained in:
hansoo
2025-03-26 18:16:46 +09:00
commit 266674cc0e
67 changed files with 14235 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

44
ZELLYY/zellyy core/README.md Normal file
View File

@@ -0,0 +1,44 @@
# ZELLYY Core
여러 ZELLYY 서비스의 공통 기능을 제공하는 코어 시스템입니다.
## 기능
- 사용자 인증 및 관리 (SSO)
- 통합 데이터베이스 스키마
- 공통 UI 컴포넌트
- 서비스 간 데이터 공유 API
## 연동 서비스
- 적자 탈출 가계부
- Subscription Manager
- ZELLYY Card
## 기술 스택
- Backend: Supabase
- Frontend: React
- UI Design: Lovable
- 개발: Windsurf
## 확장성 고려사항
### 인프라 확장성
- **수평적 확장**: 서비스 컴포넌트의 독립적 스케일링
- **부하 분산**: 지역별 Edge Functions 및 CDN 활용
- **멀티 리전 배포**: 지역별 지연 시간 최소화
### 데이터베이스 확장성
- **샤딩 전략**: 사용자 기반 데이터 파티셔닝
- **읽기 복제본**: 읽기 작업의 분산 처리
- **백업 및 복구**: 안정적인 데이터 보존 및 복구 계획
### 시스템 모듈성
- **마이크로서비스**: 필요에 따라 모듈 분리 가능한 구조
- **API 게이트웨이**: 트래픽 제어 및 서비스 라우팅
- **서비스 디스커버리**: 동적 서비스 등록 및 발견
## 설치 및 실행 방법
(세부 내용 추가 예정)

144
ZELLYY/zellyy core/architecture.md Normal file
View File

@@ -0,0 +1,144 @@
# ZELLYY Core 아키텍처
## 시스템 구조
```
+---------------------+
| Frontend Apps |
| +-------+ +-------+ |
| |적자탈출| | 구독 | |
| |가계부 | |매니저 | |
| +-------+ +-------+ |
+----------+----------+
|
+----------v----------+
| ZELLYY Core API |
| |
| - 사용자 인증/관리 |
| - SSO 서비스 |
| - 공통 데이터 관리 |
+----------+----------+
|
+----------v----------+
| Supabase |
| +-------+ +-------+ |
| | Auth | |Database| |
| +-------+ +-------+ |
+---------------------+
```
## 데이터 모델
### 사용자 (Users)
- id: UUID (Supabase Auth와 연동)
- email: String
- name: String
- created_at: Timestamp
- last_login: Timestamp
- services: Array<String> (사용 중인 서비스 목록)
- auth_provider: String (google, apple, email 등 인증 제공자)
- auth_provider_id: String (제공자 측 사용자 ID)
- avatar_url: String (프로필 이미지 URL)
### 서비스 접근 권한 (Service_Access)
- user_id: UUID (FK: Users)
- service_id: UUID (FK: Services)
- access_level: String
- granted_at: Timestamp
### 서비스 (Services)
- id: UUID
- name: String
- description: String
- api_endpoint: String
## 인증 흐름
1. 사용자가 어느 서비스에서든 로그인 (이메일/비밀번호, 구글 또는 애플 계정 사용)
2. ZELLYY Core에서 인증 처리
- 소셜 로그인의 경우 해당 제공자의 OAuth 흐름을 통해 인증
- 최초 로그인 시 사용자 정보 생성 및 연결
3. JWT 토큰 발급 및 사용자 서비스 접근 권한 확인
4. 해당 서비스로 리다이렉트 및 SSO 세션 유지
## 소셜 로그인 통합 흐름
```
+-------------+ +--------------+ +---------------+
| 사용자 |---->| ZELLYY Front |---->| 구글/애플 OAuth |
+-------------+ +--------------+ +---------------+
^ ^ |
| | v
| | +---------------+
| +------------| ZELLYY Core |
| | Auth Handler |
| +---------------+
| |
| v
| +---------------+
+-------------------------------| Supabase |
| Auth & DB |
+---------------+
```
## 확장성을 위한 아키텍처 설계
### 1. 서비스 계층 분리
```
+-------------------+
| 클라이언트 |
+--------+----------+
|
+--------v----------+
| API Gateway | <-- 트래픽 제어, 로드 밸런싱
+--------+----------+
|
+--------v----------+ +----------------+
| Core Services +---->+ Cache Layer | <-- Redis 클러스터
+--------+----------+ +----------------+
|
+--------v----------+
| Database Layer | <-- 읽기 복제본, 샤딩
+-------------------+
```
### 2. 분산 시스템 패턴
- **Circuit Breaker**: 장애 전파 방지 및 빠른 실패 처리
- **Bulkhead**: 서비스 간 영향 격리
- **Throttling**: API 사용량 제한 및 서비스 보호
- **Saga**: 분산 트랜잭션 처리
- **CQRS**: 읽기/쓰기 작업 분리로 성능 최적화
### 3. 성능 확장 전략
#### 캐싱 계층
- **분산 캐시**: Redis 클러스터를 활용한 세션, 토큰, 자주 사용되는 데이터 캐싱
- **엣지 캐싱**: CDN을 통한 정적 자원 및 API 응답 캐싱
- **멀티 레벨 캐싱**: 클라이언트 → 엣지 → 서버 단계별 캐싱
#### 데이터베이스 확장
- **수직적 확장**: 리소스 증가를 통한 초기 성능 개선
- **수평적 확장**: 샤딩을 통한 데이터 분산
- **읽기/쓰기 분리**: 마스터-슬레이브 구조로 읽기 부하 분산
### 4. 인증 시스템 확장
- **토큰 관리**: 중앙화된 JWT 발급 및 검증
- **세션 저장소**: Redis를 활용한 분산 세션 관리
- **토큰 갱신**: 효율적인 리프레시 토큰 처리
- **세션 동기화**: 멀티 인스턴스 간 세션 정보 동기화
### 5. 모니터링 및 탄력성
- **상태 모니터링**: 서비스 상태 실시간 추적
- **자동 스케일링**: 트래픽에 따른 자동 확장 구성
- **장애 감지**: 이상 징후 조기 발견
- **자동 복구**: 장애 발생 시 자동 대응 체계
### 6. API 버전 관리
- **하위 호환성**: 이전 버전 API 지원
- **점진적 도입**: 새로운 기능의 단계적 출시
- **API 문서 자동화**: OpenAPI 스펙을 통한 문서 관리

170
ZELLYY/zellyy core/core-service-communication.md Normal file
View File

@@ -0,0 +1,170 @@
# ZELLYY Core와 서비스 간 통신 설계
## 개요
이 문서는 ZELLYY Core와 각 서비스(적자 탈출 가계부, Subscription Manager, ZELLYY Card) 간의 통신 구조와 API 설계를 정의합니다.
## 통신 아키텍처
### 기본 원칙
1. **API 게이트웨이 패턴** - 모든 요청은 ZELLYY Core API 게이트웨이를 통해 라우팅
2. **JWT 기반 인증** - 모든 서비스 간 통신은 JWT 토큰으로 인증
3. **이벤트 기반 통신** - 서비스 간 데이터 동기화는 이벤트 기반으로 구현
### 통신 흐름
```
클라이언트 → ZELLYY Core API → 개별 서비스 API
↑ ↓
└─ Supabase Auth
```
## API 엔드포인트 구조
### Core API (공통)
```
/api/v1/auth # 인증 관련 API
/login # 로그인
/register # 회원가입
/refresh-token # 토큰 갱신
/logout # 로그아웃
/verify-email # 이메일 인증
/api/v1/users # 사용자 관리 API
/me # 현재 사용자 정보
/services # 사용자의 서비스 접근 권한
/profile # 프로필 관리
/api/v1/services # 서비스 관리 API
/list # 사용 가능한 서비스 목록
/switch # 서비스 전환
/access # 서비스 접근 권한 관리
```
### 서비스별 API
각 서비스는 다음 패턴으로 API를 제공:
```
/api/v1/{service-name}/... # 서비스별 고유 API
```
예: 적자 탈출 가계부 API
```
/api/v1/budget/accounts # 계좌 관리
/api/v1/budget/transactions # 거래 내역
/api/v1/budget/categories # 카테고리 관리
/api/v1/budget/reports # 리포트 생성
```
## 인증 및 권한 부여
### JWT 구조
```javascript
{
"sub": "user-uuid", // 사용자 ID
"iss": "zellyy-core", // 토큰 발행자
"exp": 1634567890, // 만료 시간
"iat": 1634564290, // 발행 시간
"services": ["budget", "subscription"], // 접근 가능한 서비스
"roles": { // 서비스별 사용자 역할
"budget": "admin",
"subscription": "user"
}
}
```
### 권한 검증 흐름
1. 클라이언트가 요청 시 JWT를 Authorization 헤더에 포함
2. Core API 게이트웨이에서 토큰 유효성 검증
3. 요청된 서비스에 대한 접근 권한 확인
4. 권한이 있으면 요청을 해당 서비스로 라우팅, 없으면 403 Forbidden 반환
## 데이터 공유 메커니즘
### 서비스 간 직접 데이터 접근
제한된 상황에서만 허용:
```javascript
// 예: 구독 관리자가 가계부 데이터에 접근해야 하는 경우
const subscriptionCost = await coreAPI.fetchFromService({
service: 'budget',
endpoint: '/api/v1/budget/transactions',
query: {
category: 'subscriptions',
timeframe: 'monthly'
}
});
```
### 이벤트 기반 데이터 동기화
서비스 간 데이터 일관성을 위한 이벤트 발행/구독 패턴:
```javascript
// 이벤트 정의 예시
{
"type": "transaction.created",
"service": "budget",
"payload": {
"user_id": "user-uuid",
"amount": 9900,
"category": "subscription",
"description": "Netflix 월 구독"
},
"timestamp": "2023-10-18T15:30:00Z"
}
```
## 에러 처리 및 로깅
### 표준 에러 응답 형식
```json
{
"error": {
"code": "auth/invalid-credentials",
"message": "이메일 또는 비밀번호가 올바르지 않습니다.",
"details": { ... }
},
"requestId": "req-uuid-123456"
}
```
### 중앙 집중식 로깅
모든 서비스는 구조화된 로그를 Core의 중앙 로깅 시스템으로 전송:
```javascript
logger.info('user.login.success', {
userId: 'user-uuid',
service: 'budget',
device: 'mobile-ios',
ipAddress: '192.168.1.1'
});
```
## API 버저닝 및 하위 호환성
1. **URL 기반 버저닝** - `/api/v1/...`, `/api/v2/...`
2. **점진적 변경** - 하위 호환성을 유지하며 API 발전
3. **폐기 정책** - API 변경 시 충분한 마이그레이션 기간 제공
## 성능 최적화
1. **API 캐싱** - 자주 요청되는 데이터 캐싱
2. **일괄 요청** - 여러 리소스를 한 번에 요청할 수 있는 배치 API 제공
3. **필드 필터링** - 클라이언트가 필요한 필드만 요청할 수 있는 기능
## 다음 단계
1. API 게이트웨이 구현 및 테스트
2. 서비스별 API 스펙 상세 정의
3. 인증 및 권한 부여 시스템 구현
4. 모니터링 및 로깅 인프라 설정
```

258
ZELLYY/zellyy core/data-security.md Normal file
View File

@@ -0,0 +1,258 @@
# ZELLYY Core 데이터 보안 전략
## 개요
이 문서는 ZELLYY Core 시스템의 데이터 보안 전략과 구현 방안에 대해 설명합니다. 데이터의 기밀성, 무결성, 가용성을 보장하기 위한 계층적 보안 접근법을 설명합니다.
## 보안 설계 원칙
### 심층 방어 (Defense in Depth)
**다중 보안 계층**
- 네트워크 보안
- 애플리케이션 보안
- 데이터 보안
- 사용자 인증 및 권한 관리
**보안 경계 설정**
- 보안 영역 분리
- 영역 간 보안 통제
- 최소 권한 접근 정책
### 제로 트러스트 모델
**기본 원칙**
- 내부 네트워크와 외부 네트워크 모두 신뢰하지 않음
- 모든 접근 요청은 항상 검증
- 지속적인 인증 및 권한 부여
**구현 요소**
- 다중 인증(MFA) 의무화
- 세분화된 접근 제어
- 지속적인 모니터링 및 검증
## 데이터 분류 및 보호
### 데이터 분류 체계
**민감도 기반 분류**
```
+------------------------+----------------------+------------------------+
| 높음 (민감 정보) | 중간 (내부 정보) | 낮음 (공개 정보) |
+------------------------+----------------------+------------------------+
| - 개인식별정보(PII) | - 내부 운영 데이터 | - 마케팅 자료 |
| - 결제 정보 | - 분석 데이터 | - 공개 API 설명서 |
| - 인증 크리덴셜 | - 구성 설정 | - 공개 서비스 정보 |
+------------------------+----------------------+------------------------+
| 엄격한 보안 통제 적용 | 중간 수준 보안 통제 | 기본 보안 통제 적용 |
+------------------------+----------------------+------------------------+
```
**데이터 라벨링 전략**
- 자동 데이터 분류 시스템
- 메타데이터 기반 라벨링
- 정책 기반 보호 조치 적용
### 데이터 암호화
**저장 데이터(Data at Rest) 암호화**
- 데이터베이스 행 수준 암호화
- 테이블럿/필드 수준 암호화
- 디스크 수준 암호화(FDE)
**전송 중 데이터(Data in Transit) 암호화**
- TLS 1.3 이상 적용
- 인증서 관리 및 갱신 자동화
- 안전한 키 교환 프로토콜
**처리 중 데이터(Data in Use) 보호**
- 메모리 보호 기술
- 안전한 컴퓨팅 환경
- 데이터 마스킹 및 토큰화
### 암호화 키 관리
**키 계층 구조**
- 마스터 키
- 데이터 암호화 키
- 세션 키
**키 수명 주기 관리**
```
┌───────────┐ ┌───────────┐ ┌───────────┐ ┌───────────┐
│ 키 생성 │ ──> │ 키 활성화 │ ──> │ 키 교체 │ ──> │ 키 보관 │
└───────────┘ └───────────┘ └───────────┘ └───────────┘
│ │
│ ▼
│ ┌───────────┐
└───────────────────────────>│ 키 삭제 │
└───────────┘
```
**키 보호 메커니즘**
- 하드웨어 보안 모듈(HSM) 활용
- 키 분할 및 쿼럼 기반 접근
- 키 사용 감사 및 모니터링
## 접근 제어
### 인증 시스템
**다중 인증(MFA) 구현**
- 지식 기반(비밀번호)
- 소유 기반(OTP, 모바일 인증)
- 생체 인증(필요시)
**세션 관리**
- 안전한 세션 생성 및 만료
- 동시 세션 제한
- 비정상 세션 탐지 및 종료
**소셜 로그인 보안 강화**
- OAuth 2.0 + PKCE 사용
- 철저한 제공자 검증
- 추가 인증 계층 적용
### 권한 관리
**역할 기반 접근 제어(RBAC)**
- 역할 정의 및 최소 권한 할당
- 역할 계층 구조 설계
- 권한 승인 워크플로우
**속성 기반 접근 제어(ABAC)**
- 사용자 속성(직무, 위치 등)
- 자원 속성(민감도, 소유권)
- 컨텍스트 속성(시간, 위치, 장치)
**데이터 수준 보안**
- 행 수준 보안(RLS) 구현
- 열 수준 암호화 및 마스킹
- 동적 데이터 접근 필터링
### API 보안
**인증 및 권한 부여**
- API 키 관리
- JWT 기반 인증
- OAuth 2.0 / OpenID Connect 통합
**요청 제한 및 방어**
- 속도 제한(Rate Limiting)
- API 사용량 할당량 설정
- 비정상 요청 패턴 차단
**API 보안 모니터링**
- 요청/응답 로깅 및 분석
- 보안 취약점 자동 감지
- API 사용 패턴 분석
## 위협 탐지 및 대응
### 보안 모니터링
**실시간 모니터링**
- 로그 집계 및 분석
- 행동 기반 탐지
- 이상 징후 알림
**보안 정보 및 이벤트 관리(SIEM)**
- 중앙 집중식 로그 관리
- 상관관계 분석 규칙
- 자동화된 위협 정보 통합
**취약점 관리**
- 정기적인 취약점 스캔
- 패치 관리 프로세스
- 위험 기반 우선순위 설정
### 침해 대응
**사고 대응 계획**
```
1. 준비 → 2. 탐지 및 분석 → 3. 봉쇄 → 4. 제거 → 5. 복구 → 6. 교훈
```
**대응 절차**
- 에스컬레이션 경로 및 담당자
- 증거 수집 및 보존
- 내외부 커뮤니케이션 지침
**복구 전략**
- 백업 기반 시스템 복원
- 단계적 서비스 재개
- 보안 강화 조치 구현
### 보안 자동화
**보안 오케스트레이션 및 자동화(SOAR)**
- 반복 작업 자동화
- 이벤트 기반 대응 워크플로우
- 플레이북 기반 대응
**지속적 보안 검증**
- 자동화된 보안 테스트
- 구성 드리프트 감지
- 보안 회귀 방지
## 규정 준수 및 감사
### 데이터 보호 규정
**주요 규정 준수**
- GDPR(유럽 일반 데이터 보호 규정)
- CCPA/CPRA(캘리포니아 소비자 개인정보 보호법)
- PIPA(한국 개인정보 보호법)
**개인정보 보호**
- 데이터 최소화 원칙
- 개인정보 처리 근거 관리
- 정보 주체 권리 보장
**국가별/지역별 데이터 현지화**
- 데이터 상주 요구사항 준수
- 국가간 데이터 전송 관리
- 지역별 규제 모니터링
### 보안 감사 및 평가
**정기 보안 평가**
- 내부 보안 감사
- 외부 침투 테스트
- 코드 보안 검토
**컴플라이언스 증명**
- SOC 2 인증
- ISO 27001 준수
- 산업별 표준 인증
**감사 증적(Audit Trail)**
- 변경 불가능한 감사 로그
- 특권 사용자 활동 감사
- 데이터 접근 내역 기록
## 보안 구현 로드맵
### 1단계: 기본 보안 인프라 구축 (1-2개월)
- 인증 시스템 강화 (MFA 포함)
- 기본 암호화 구현
- 초기 보안 모니터링 설정
### 2단계: 고급 데이터 보호 구현 (2-4개월)
- 데이터 분류 및 라벨링 시스템
- 암호화 키 관리 시스템 구축
- 열/행 수준 보안 구현
### 3단계: 위협 탐지 및 대응 체계 구축 (3-6개월)
- SIEM 솔루션 도입
- 자동화된 위협 탐지 규칙 설정
- 침해 대응 계획 및 프로세스 개발
### 4단계: 보안 자동화 및 지속 개선 (6-12개월)
- 보안 오케스트레이션 구현
- 지속적인 보안 검증 파이프라인
- 보안 성숙도 평가 및 개선
## 결론
ZELLYY Core의 데이터 보안은 기술적 보안 조치뿐만 아니라 적절한 정책, 프로세스, 조직적 조치의 조합을 통해 달성됩니다. 계층적 방어 전략과 제로 트러스트 모델은 시스템과 데이터를 다양한 위협으로부터 보호하는 프레임워크를 제공합니다. 이러한 포괄적인 보안 접근 방식은 사용자 신뢰를 구축하고 비즈니스 연속성을 보장하며 규정 준수 요구사항을 충족하는 데 필수적입니다.

111
ZELLYY/zellyy core/database-integration.md Normal file
View File

@@ -0,0 +1,111 @@
# ZELLYY 서비스 데이터베이스 통합 계획
## 개요
이 문서는 ZELLYY Core와 각 서비스(적자 탈출 가계부, Subscription Manager, ZELLYY Card)의 데이터베이스 통합 방안을 설명합니다.
## 통합 원칙
1. **단일 Supabase 인스턴스** - 모든 서비스는 하나의 Supabase 인스턴스를 공유
2. **스키마 분리** - 서비스별로 독립된 스키마 사용
3. **공통 테이블 공유** - 사용자 정보 등 공통 데이터는 Core 스키마에서 관리
4. **Row-Level Security (RLS)** - 서비스별 데이터 접근 제어
## 스키마 구조
```
supabase
├── core # ZELLYY Core 스키마
│ ├── users # 사용자 정보
│ ├── services # 서비스 정보
│ └── service_access # 사용자-서비스 접근 권한
│
├── budget # 적자 탈출 가계부 스키마
│ ├── accounts # 계좌 정보
│ ├── categories # 지출/수입 카테고리
│ ├── transactions # 거래 내역
│ └── budgets # 예산 계획
│
├── subscription # Subscription Manager 스키마
│ ├── subscriptions # 구독 정보
│ ├── payment_history # 결제 내역
│ └── reminders # 구독 알림 설정
│
└── card # ZELLYY Card 스키마
├── cards # 카드 정보
├── benefits # 카드 혜택
└── usages # 카드 사용 내역
```
## 데이터 관계 관리
### 외래 키 전략
각 서비스의 데이터는 `core.users` 테이블의 사용자 ID를 외래 키로 참조합니다:
```sql
-- 예: 적자 탈출 가계부의 계좌 테이블
CREATE TABLE budget.accounts (
id UUID PRIMARY KEY DEFAULT uuid_generate_v4(),
user_id UUID REFERENCES core.users(id) ON DELETE CASCADE,
name TEXT NOT NULL,
-- 기타 필드
);
```
### Row-Level Security (RLS) 정책
각 테이블에는 사용자별 접근 제어를 위한 RLS 정책을 적용합니다:
```sql
-- 예: 계좌 테이블의 RLS 정책
CREATE POLICY "사용자 본인의 계좌만 접근 가능"
ON budget.accounts
FOR ALL
USING (auth.uid() = user_id);
```
## 데이터 마이그레이션 계획
기존 '적자 탈출 가계부'의 데이터베이스를 통합 스키마로 마이그레이션하는 단계:
1. **스키마 생성**: `budget` 스키마 생성
2. **테이블 이동**: 기존 테이블을 새 스키마로 이동
3. **외래 키 업데이트**: `core.users` 테이블을 참조하도록 외래 키 수정
4. **RLS 정책 적용**: 모든 테이블에 적절한 RLS 정책 설정
5. **데이터 검증**: 마이그레이션 후 데이터 무결성 확인
## 서비스별 데이터 접근
각 서비스는 자신의 스키마와 `core` 스키마에만 접근할 수 있도록 설계:
1. **서비스별 데이터베이스 역할 생성**
```sql
CREATE ROLE budget_service;
GRANT USAGE ON SCHEMA core TO budget_service;
GRANT USAGE ON SCHEMA budget TO budget_service;
GRANT ALL PRIVILEGES ON ALL TABLES IN SCHEMA budget TO budget_service;
GRANT SELECT ON core.users TO budget_service;
```
2. **API 접근 제어**
- 각 서비스별 API 키를 생성하여 적절한 권한 범위 설정
- Core API를 통한 인증 및 권한 검증
## 성능 최적화
1. **인덱스 전략**
- 사용자 ID 기반 인덱스 추가
- 자주 조회되는 필드에 적절한 인덱스 설정
2. **캐싱 전략**
- 사용자 세션 및 자주 사용되는 데이터 캐싱
- 서비스별 캐시 무효화 정책 수립
## 다음 단계
1. 기존 '적자 탈출 가계부' 데이터베이스 스키마 상세 분석
2. 'Subscription Manager'와 'ZELLYY Card'의 요구사항 수집 및 스키마 설계
3. 공통 필드 및 관계 정의
4. 테스트 데이터베이스에서 통합 스키마 검증
5. 마이그레이션 스크립트 작성 및 테스트
```

252
ZELLYY/zellyy core/high-availability.md Normal file
View File

@@ -0,0 +1,252 @@
# ZELLYY Core 고가용성 아키텍처
## 개요
이 문서는 ZELLYY Core 시스템의 고가용성(High Availability, HA) 아키텍처에 대해 설명합니다. 서비스 중단 없이 안정적으로 운영하기 위한 설계 원칙과 구현 방안을 제시합니다.
## 고가용성 설계 원칙
### 1. 단일 장애점(Single Point of Failure) 제거
**인프라 중복성**
- 여러 가용 영역(AZ)에 걸친 서비스 배포
- 서버, 네트워크, 스토리지 컴포넌트 중복 구성
- 데이터베이스 클러스터 구성
**장애 격리**
- 장애 도메인 분리
- 서비스 간 독립적 배포 및 운영
- 컨테이너화를 통한 애플리케이션 격리
### 2. 자동화된 장애 대응
**자동 장애 감지**
- 상태 확인(Health Check) 시스템 구축
- 분산 모니터링으로 장애 조기 감지
- 이상 징후 탐지 알고리즘 적용
**자동 복구 메커니즘**
- 자가 치유(Self-healing) 시스템 구현
- 상태가 불량한 서버 자동 대체
- 서비스 재시작 및 재배포 자동화
## 멀티 리전 아키텍처
### 글로벌 배포 전략
```
+--------------------+
| DNS Load Balancer |
+--------+-----------+
|
+-------------------------------+
| | |
+------v-----+ +-----v------+ +-----v------+
| Region A | | Region B | | Region C |
| (Primary) | | (DR Site) | | (Edge) |
+------+-----+ +-----+------+ +-----+------+
| | |
+-------------------------------+
|
+--------v-----------+
| Global Data Sync |
+--------------------+
```
**리전별 서비스 특성화**
- 주 리전(Primary): 모든 서비스 및 데이터 처리
- 재해 복구(DR) 리전: 장애 대비 복제 환경
- 엣지 리전: 정적 콘텐츠 및 캐싱
**글로벌 트래픽 관리**
- 지리적 라우팅으로 가장 가까운 리전으로 트래픽 유도
- 리전 장애 시 자동 우회 라우팅
- 부하에 따른 동적 트래픽 분산
### 데이터 동기화 전략
**글로벌 데이터 일관성**
- 멀티 리전 데이터베이스 복제
- 데이터 일관성 모델 선택 (강한 일관성 vs. 최종 일관성)
- 분산 트랜잭션 관리
**복제 지연 관리**
- 복제 지연 모니터링
- 지연 임계값 설정 및 알림
- 복제 최적화 전략
## 서비스 연속성
### 장애 조치(Failover) 전략
**자동 장애 조치**
```
1. 상태 모니터링 시스템이 장애 감지
2. 장애 발생 리전/서비스 격리
3. 대기 시스템으로 트래픽 전환
4. 장애 리전/서비스 복구 시도
5. 복구 완료 후 정상 운영 재개
```
**수동 장애 조치**
- 계획된 유지보수를 위한 수동 장애 조치 절차
- 테스트 환경에서 장애 조치 시뮬레이션
- 장애 조치 체크리스트 및 롤백 계획
### 재해 복구 계획(DRP)
**복구 시나리오**
- 단일 서비스 장애: 개별 서비스 재시작 또는 대체
- 가용 영역 장애: 다른 AZ의 인스턴스로 자동 전환
- 리전 장애: DR 리전으로 서비스 전환
- 광범위한 재해: 백업에서 새 환경 구축
**복구 목표**
- 복구 시간 목표(RTO): 서비스별 차등 적용
* 핵심 서비스: 5분 이내
* 일반 서비스: 15분 이내
* 비핵심 서비스: 1시간 이내
- 복구 지점 목표(RPO): 데이터 중요도에 따라 차등 적용
* 핵심 데이터: 거의 실시간 (1분 이내)
* 일반 데이터: 5분 이내
* 통계/로그 데이터: 1시간 이내
## 데이터베이스 고가용성
### Supabase PostgreSQL HA 구성
**PostgreSQL 클러스터 구성**
- 1 Primary + 2 Replica 구성
- 자동 장애 조치 설정
- 연결 풀 관리
**백업 전략**
- 일간 전체 백업
- 지속적인 WAL(Write-Ahead Log) 아카이빙
- Point-in-Time Recovery(PITR) 지원
### 다중 데이터베이스 전략
**데이터베이스 샤딩**
- 사용자 ID 기반 수평 샤딩
- 서비스별 수직 샤딩
- 샤드 관리 및 라우팅 시스템
**읽기/쓰기 분리**
- 쓰기 작업은 Primary로 라우팅
- 읽기 작업은 Replica로 분산
- 읽기 일관성 레벨 설정
## 애플리케이션 고가용성
### 무상태(Stateless) 설계
**세션 관리**
- 분산 세션 스토어(Redis) 활용
- 클라이언트 측 상태 관리 최소화
- JWT 기반 인증으로 서버 상태 의존성 감소
**캐싱 전략**
- 다층 캐싱 구현
- 캐시 일관성 유지
- 캐시 장애 대응 전략
### API 게이트웨이 고가용성
**API 게이트웨이 클러스터**
- 여러 가용 영역에 분산 배치
- 로드 밸런싱 및 자동 확장
- 장애 감지 및 자동 복구
**서비스 디스커버리**
- 동적 서비스 등록 및 발견
- 상태 기반 라우팅
- 서비스 버전 관리
## 스토리지 고가용성
### 파일 스토리지 중복성
**객체 스토리지 복제**
- 리전 내 여러 가용 영역에 걸친 복제
- 리전 간 비동기 복제
- 버저닝 기반 데이터 보호
**콘텐츠 분산 전략**
- CDN을 통한 정적 콘텐츠 캐싱
- 원본 대체(Origin Shield) 구현
- 장애 시 대체 경로 제공
### 데이터 지속성 보장
**데이터 내구성 목표**
- 99.999999999%(11 9's) 이상의 데이터 내구성
- 다중 계층 데이터 보호
- 일관된 백업 및 복원 절차
**데이터 검증**
- 체크섬 기반 데이터 무결성 검증
- 정기적인 복원 테스트
- 데이터 감사 및 모니터링
## 모니터링 및 운영
### 고가용성 모니터링
**실시간 상태 대시보드**
- 서비스 가용성 지표
- 리전 및 가용 영역 상태
- SLA 준수 모니터링
**분산 로깅 시스템**
- 중앙 집중식 로그 수집
- 로그 분석 및 알림
- 장애 패턴 탐지
### 사전 예방적 운영
**용량 계획**
- 정기적인 성능 검토
- 성장 추세 분석
- 확장 계획 수립
**정기 유지보수**
- 계획된 유지보수 일정
- 영향 최소화 전략
- 무중단 배포 절차
## 테스트 및 검증
### 고가용성 테스트
**정기적인 DR 훈련**
- 분기별 재해 복구 시뮬레이션
- 장애 조치 절차 훈련
- 복구 시간 측정 및 개선
**카오스 엔지니어링**
- 제어된 환경에서 장애 주입
- 시스템 복원력 테스트
- 장애 대응 개선
### 성능 테스트
**부하 테스트**
- 정상 부하의 3-5배 처리 검증
- 자동 확장 기능 테스트
- 병목 현상 식별 및 해결
**장기 실행 테스트**
- 장기간(7일 이상) 연속 운영 테스트
- 메모리 누수 및 성능 저하 모니터링
- 자원 사용 패턴 분석
## 다음 단계
1. 현재 시스템의 고가용성 수준 평가
2. 주요 단일 장애점 식별 및 제거 계획 수립
3. 멀티 리전 아키텍처 설계 및 구현
4. 자동 장애 조치 시스템 개발
5. 종합적인 재해 복구 계획 수립 및 테스트
6. 고가용성 모니터링 체계 구축
```

62
ZELLYY/zellyy core/implementation-plan.md Normal file
View File

@@ -0,0 +1,62 @@
# ZELLYY Core 구현 계획
## 1단계: 기초 인프라 구축 (1-2주)
- Supabase 프로젝트 설정
- 데이터베이스 스키마 설계 및 구현
- 기본 인증 시스템 구축
- 이메일/비밀번호 인증
- 구글 OAuth 연동
- 애플 로그인 연동
- 개발 환경 설정
## 2단계: API 개발 (2-3주)
- 사용자 관리 API 개발
- 회원가입/로그인/로그아웃
- 소셜 계정 연결 및 관리
- 프로필 관리
- 권한 관리
- 서비스 연동 API 개발
- 서비스 접근 토큰 발급
- 서비스 간 데이터 공유
- SSO 구현
- 세션 관리
- 서비스 간 전환
## 3단계: SDK 개발 (1-2주)
- 각 서비스에서 사용할 JavaScript/TypeScript SDK 개발
- 인증 및 API 호출 래퍼 함수 구현
- 소셜 로그인 통합 헬퍼
- 에러 처리 및 로깅
## 4단계: UI 컴포넌트 개발 (1-2주)
- 로그인/회원가입 폼
- 소셜 로그인 버튼
- OAuth 리다이렉트 처리
- 프로필 관리 페이지
- 소셜 계정 연결/해제
- 서비스 전환 인터페이스
- 공통 디자인 시스템 적용
## 5단계: 테스트 및 통합 (1-2주)
- 단위 및 통합 테스트
- 각 서비스와의 연동 테스트
- 소셜 로그인 흐름 테스트
- 성능 및 보안 테스트
## 6단계: 배포 및 모니터링 (1주)
- CI/CD 파이프라인 구축
- 배포 자동화
- 모니터링 및 알림 시스템 구축
## 일정
총 예상 소요 기간: 7-12주
```
| 단계 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 |
|----------|---------|---------|---------|---------|---------|---------|---------|---------|---------|---------|---------|---------|
| 1단계 | X | X | | | | | | | | | | |
| 2단계 | | | X | X | X | | | | | | | |
| 3단계 | | | | | | X | X | | | | | |
| 4단계 | | | | | | | X | X | | | | |
| 5단계 | | | | | | | | | X | X | | |
| 6단계 | | | | | | | | | | | X | |
```

427
ZELLYY/zellyy core/scalability-plan.md Normal file
View File

@@ -0,0 +1,427 @@
# ZELLYY Core 확장성 계획
## 개요
이 문서는 ZELLYY Core 시스템의 확장성 전략과 구현 방안에 대해 설명합니다. 사용자 수 증가와 서비스 다양화에 따른 안정적인 성능을 보장하기 위한 계획을 포함합니다.
## 확장성 핵심 요소
### 1. 기술적 확장성 (Technical Scalability)
#### 인프라 확장성
**클라우드 인프라 전략**
- Supabase의 자동 확장 기능 활용
- 서버리스 아키텍처 채택 (Firebase Functions, Supabase Edge Functions)
- 정적 컨텐츠 CDN 배포
**컨테이너화 및 오케스트레이션**
- Docker 컨테이너화로 일관된 환경 구성
- Kubernetes를 통한 서비스 관리 (필요시)
- 자동 확장 정책 구현
**글로벌 배포 전략**
- 지역별 서비스 배치
- Edge Computing을 통한 지연 시간 최소화
- 멀티 리전 데이터 복제
#### 데이터베이스 확장성
**데이터 파티셔닝**
```sql
-- 사용자 ID 기반 샤딩 예시
CREATE TABLE users_shard_1 (LIKE core.users INCLUDING ALL);
CREATE TABLE users_shard_2 (LIKE core.users INCLUDING ALL);
-- 샤딩 함수
CREATE OR REPLACE FUNCTION get_shard_for_user(user_id UUID)
RETURNS TEXT AS $$
BEGIN
RETURN 'users_shard_' || (('x' || substring(user_id::text, 1, 8))::bit(32)::int % 2 + 1)::text;
END;
$$ LANGUAGE plpgsql;
```
**읽기 복제본 구성**
- 읽기 작업 전용 데이터베이스 인스턴스
- 마스터-슬레이브 구조 구축
- 복제 지연 모니터링
**연결 풀링 및 캐싱**
- 데이터베이스 연결 효율적 관리
- 결과 캐싱으로 반복 쿼리 최소화
- 인덱스 최적화 전략
### 2. 시스템 아키텍처 확장성
#### 마이크로서비스 아키텍처
**서비스 분리 전략**
- 기능 기반 서비스 모듈화
- 독립적 배포 및 확장 가능한 구조
- 서비스 간 통신 표준화
**예시 서비스 구성**
```
zellyy-core
├── auth-service # 인증 및 권한 관리
├── user-service # 사용자 프로필 관리
├── notification-service # 알림 처리
├── analytics-service # 데이터 분석
└── integration-service # 외부 서비스 연동
```
**서비스 디스커버리**
- 동적 서비스 등록 및 발견
- 상태 기반 라우팅
- 로드 밸런싱
#### API 설계
**API 계층화**
- 공개 API (클라이언트용)
- 내부 API (서비스 간 통신)
- 관리 API (시스템 관리용)
**API 게이트웨이 구현**
- 요청 라우팅 및 로드 밸런싱
- 속도 제한 및 할당량 관리
- 인증 및 권한 검증
**API 버전 관리**
```
/api/v1/auth/login # 현재 버전
/api/v2/auth/login # 새 기능이 추가된 버전
```
### 3. 성능 확장성
#### 캐싱 전략
**멀티 레벨 캐싱**
```
클라이언트 캐시 → CDN 캐시 → API 게이트웨이 캐시 → 서비스 캐시 → 데이터베이스
```
**캐시 무효화 전략**
- 이벤트 기반 캐시 갱신
- TTL(Time-to-Live) 기반 만료
- 버전 태그를 통한 캐시 관리
**캐시 저장소 구성**
- Redis 클러스터 구성
- 메모리 사용량 모니터링
- 캐시 히트율 분석
#### 비동기 처리
**메시지 큐 시스템**
- AWS SQS, RabbitMQ 또는 Kafka 활용
- 작업 우선순위 설정
- 재시도 및 데드레터 큐 전략
**이벤트 기반 아키텍처**
```javascript
// 이벤트 게시 예시
async function publishUserRegisteredEvent(userData) {
await eventBus.publish('user.registered', {
userId: userData.id,
timestamp: new Date().toISOString(),
service: 'auth-service'
});
}
// 이벤트 구독 예시
eventBus.subscribe('user.registered', async (event) => {
await notificationService.sendWelcomeEmail(event.userId);
await analyticsService.trackSignup(event);
});
```
**백그라운드 작업 처리**
- 장기 실행 작업 분리
- 배치 처리 최적화
- 작업 상태 추적
### 4. 운영 확장성
#### 모니터링 및 알림
**모니터링 지표**
- 시스템 지표: CPU, 메모리, 디스크, 네트워크
- 애플리케이션 지표: 응답 시간, 에러율, 요청 수
- 비즈니스 지표: 활성 사용자, 트랜잭션 수, 전환율
**로깅 전략**
- 구조화된 로그 형식
- 중앙화된 로그 저장소
- 로그 분석 및 검색 도구 (ELK, Grafana)
**알림 체계**
- 임계값 기반 알림
- 이상 탐지 알림
- 에스컬레이션 정책
#### 자동화된 운영
**CI/CD 파이프라인**
- 자동 빌드 및 테스트
- 블루/그린 배포
- 점진적 출시 (Canary Releases)
**인프라 자동화**
- Infrastructure as Code (Terraform, AWS CDK)
- 자동 확장 구성
- 자가 복구 메커니즘
**장애 대응 자동화**
- 장애 탐지 및 격리
- 자동 롤백 메커니즘
- 장애 분석 및 보고
### 5. 비즈니스 확장성
#### 멀티테넌시(Multi-tenancy)
**테넌트 격리 전략**
- 스키마 기반 분리
- 행 수준 보안 정책 (RLS)
- 테넌트별 리소스 할당
**테넌트 온보딩 자동화**
- 셀프서비스 등록 흐름
- 자동 리소스 프로비저닝
- 구성 템플릿
**청구 및 사용량 추적**
- 테넌트별 리소스 사용량 측정
- 사용량 기반 과금 모델
- 사용량 보고서 생성
#### 국제화 및 지역화
**다국어 지원**
- 번역 관리 시스템
- 동적 언어 전환
- 지역별 콘텐츠 최적화
**지역별 규정 준수**
- GDPR, CCPA 등 데이터 보호 규정
- 지역별 데이터 상주 요건
- 규제 변경에 따른 유연한 대응
**지역별 서비스 사용자화**
- 지역별 결제 방식 지원
- 문화적 차이를 고려한 UI/UX
- 지역별 서비스 가용성 설정
### 6. 고가용성 아키텍처 (High Availability)
#### 멀티 리전 배포
**리전 간 서비스 분산**
- 지리적으로 분산된 데이터 센터 활용
- 글로벌 트래픽 라우팅 (AWS Global Accelerator, Cloudflare 등)
- 리전별 장애 격리
**액티브-액티브 구성**
- 모든 리전에서 동시에 서비스 제공
- 지역 기반 라우팅으로 가장 가까운 리전으로 접속
- 글로벌 부하 분산
**액티브-패시브 구성** (비용 효율적 대안)
- 주 리전에서 서비스 제공, 다른 리전은 대기 상태
- 자동 장애 감지 및 장애 조치
- 정기적인 장애 조치 테스트
#### 무중단 운영
**롤링 업데이트 전략**
```
1. 전체 서버 중 일부(예: 20%)를 서비스에서 제외
2. 해당 서버에 새 버전 배포
3. 정상 작동 확인 후 다시 서비스에 포함
4. 다음 서버 그룹에 대해 반복
```
**블루-그린 배포**
- 두 개의 동일한 환경(블루/그린) 유지
- 새 버전을 그린 환경에 배포하고 테스트
- 트래픽을 블루에서 그린으로 전환
- 문제 발생 시 블루로 즉시 롤백
**서킷 브레이커 패턴**
- 서비스 장애 시 자동 차단으로 연쇄 장애 방지
- 부분적 기능 저하로 핵심 기능 유지
- 자동 복구 메커니즘
#### 데이터 고가용성
**데이터베이스 복제**
- 동기식 복제: 트랜잭션 일관성 보장
- 비동기식 복제: 성능 최적화
- 지역 간 복제로 재해 복구 지원
**데이터 백업 전략**
- 정기적인 전체 백업 (일간/주간)
- 지속적인 증분 백업
- 백업 자동화 및 검증
- 복구 프로세스 정기 테스트
**복구 시간 목표(RTO)와 복구 시점 목표(RPO)**
- RTO: 서비스 중단 후 복구까지 허용 시간 (예: 15분)
- RPO: 허용 가능한 최대 데이터 손실 기간 (예: 5분)
- 서비스 중요도에 따른 차별화된 RTO/RPO 설정
### 7. 스토리지 확장 전략
#### 계층형 스토리지 아키텍처
**데이터 접근 패턴 기반 스토리지 분리**
- 핫 데이터: 자주 접근되는 데이터는 고성능 스토리지
- 웜 데이터: 가끔 접근되는 데이터는 표준 스토리지
- 콜드 데이터: 거의 접근되지 않는 데이터는 저비용 아카이브 스토리지
**자동 데이터 계층화**
```javascript
// 예: 데이터 이동 정책 설정
const storageTieringPolicy = {
hotToCold: {
accessThreshold: '30days', // 30일 동안 접근되지 않으면
destinationTier: 'standardStorage' // 표준 스토리지로 이동
},
coldToArchive: {
accessThreshold: '90days', // 90일 동안 접근되지 않으면
destinationTier: 'archiveStorage' // 아카이브 스토리지로 이동
}
};
```
**스토리지 비용 최적화**
- 데이터 압축 및 중복 제거
- 자동 만료 정책 설정
- 사용량 모니터링 및 비용 분석
#### 파일 스토리지 확장
**객체 스토리지 활용**
- Supabase Storage 또는 AWS S3 기반 확장 가능한 스토리지
- CDN 연동으로 전역 콘텐츠 배포
- 버저닝 지원으로 파일 변경 이력 관리
**메타데이터 관리**
- 파일 메타데이터 분리 저장
- 검색 최적화 인덱스 구현
- 태그 기반 파일 관리
**파일 처리 자동화**
- 서버리스 함수를 사용한 이미지 리사이징
- 동영상 인코딩 파이프라인
- OCR 및 콘텐츠 분석으로 검색 기능 강화
#### 데이터베이스 스토리지 확장
**수직적 파티셔닝 (테이블 분할)**
- 자주 사용되는 열과 그렇지 않은 열 분리
- 대용량 텍스트/BLOB 데이터 외부 저장소로 분리
- 테이블 간 조인 최적화
**시계열 데이터 샤딩**
```sql
-- 시간별로 분할된 테이블 예시
CREATE TABLE logs_2023_q1 PARTITION OF logs
FOR VALUES FROM ('2023-01-01') TO ('2023-04-01');
CREATE TABLE logs_2023_q2 PARTITION OF logs
FOR VALUES FROM ('2023-04-01') TO ('2023-07-01');
```
**자동 아카이빙**
- 오래된 데이터 자동 압축 및 아카이브
- 아카이브 테이블의 인덱스 최적화
- 아카이브 데이터 접근 API 구현
#### 확장 가능한 검색 기능
**검색 엔진 통합**
- Elasticsearch 또는 Algolia 활용
- 전문 검색(Full-text search) 최적화
- 검색 결과 캐싱
**분산 인덱싱**
- 샤딩된 인덱스로 검색 부하 분산
- 실시간 인덱스 업데이트
- 검색 쿼리 최적화
**검색 인프라 확장**
- 검색 트래픽에 따른 자동 확장
- 쿼리 분석 및 성능 최적화
- 지연 로딩 및 페이징 전략
## 확장성 테스트 전략
### 부하 테스트
**성능 테스트 도구**
- JMeter, k6 또는 Locust 활용
- 실제 사용 패턴 기반 시나리오
- 점진적 부하 증가 테스트
**병목 현상 식별**
- APM 도구를 통한 성능 병목 식별
- 데이터베이스 쿼리 최적화
- 리소스 사용량 프로파일링
**확장 임계값 설정**
- 자동 확장 트리거 포인트 결정
- 알림 임계값 설정
- 용량 계획 기준 수립
### 재해 복구 및 고가용성
**백업 전략**
- 정기적인 자동 백업
- 지역 간 데이터 복제
- 복구 시간 목표(RTO) 및 복구 시점 목표(RPO) 설정
**장애 시뮬레이션**
- 카오스 엔지니어링 원칙 적용
- 계획된 장애 주입 테스트
- 복구 절차 검증
**지속적인 가용성 모니터링**
- 서비스 상태 대시보드
- 가용성 지표 추적
- 사고 대응 프로세스 최적화
## 구현 로드맵
### 1단계: 기반 확장성 구축 (1-3개월)
- Supabase 확장 설정 최적화
- 기본 모니터링 시스템 구축
- 캐싱 계층 구현
### 2단계: 서비스 분리 및 모듈화 (3-6개월)
- 핵심 서비스 분리 및 API 게이트웨이 구현
- 메시지 큐 기반 비동기 처리 도입
- CI/CD 파이프라인 고도화
### 3단계: 글로벌 확장 및 고가용성 (6-12개월)
- 멀티 리전 배포 구현
- 데이터베이스 샤딩 및 읽기 복제본 구성
- 재해 복구 시스템 구축
- 고가용성 아키텍처 구현
- 스토리지 계층화 시스템 도입
- 자동 백업 및 복원 시스템 구축
### 4단계: 최적화 및 운영 자동화 (12개월+)
- 자동화된 성능 최적화
- 자가 복구 시스템 구현
- 고급 분석 및 AI 기반 운영 지원
- 고급 스토리지 관리 시스템 구현
- 데이터 보존 및 컴플라이언스 자동화
- 스토리지 비용 최적화 시스템 개발
## 결론
ZELLYY Core의 확장성은 기술적 측면뿐만 아니라 비즈니스 성장에도 중요한 요소입니다. 이 계획은 사용자 수 증가, 서비스 다양화, 글로벌 확장에 유연하게 대응할 수 있는 기반을 제공합니다. 특히 고가용성 아키텍처와 스토리지 확장 전략을 통해 서비스의 안정성을 보장하고 데이터 증가에 효율적으로 대응할 수 있습니다. 정기적인 검토와 업데이트를 통해 변화하는 요구사항에 적응할 수 있는 확장성 전략을 유지하는 것이 중요합니다.

251
ZELLYY/zellyy core/sso-implementation.md Normal file
View File

@@ -0,0 +1,251 @@
# ZELLYY Core SSO 구현 계획
## 개요
이 문서는 ZELLYY Core의 Single Sign-On (SSO) 구현 방안과 소셜 로그인(구글, 애플) 통합에 대해 설명합니다.
## SSO 구현 전략
### 지원하는 인증 방식
1. **이메일/비밀번호** - 기본 인증 방식
2. **구글 OAuth** - 구글 계정을 통한 로그인
3. **애플 로그인** - 애플 계정을 통한 로그인 (iOS 앱 필수)
### Supabase Auth 활용
ZELLYY Core는 Supabase Auth를 활용하여 SSO를 구현합니다. Supabase는 다음 기능을 제공합니다:
- 소셜 로그인 통합 (Google, Apple, Github 등)
- JWT 토큰 관리
- 사용자 세션 관리
- 보안 설정 (2FA, 비밀번호 정책 등)
## 소셜 로그인 구현 단계
### 1. 제공자 등록 및 설정
#### 구글 OAuth 설정
1. Google Cloud Console에서 프로젝트 생성
2. OAuth 2.0 클라이언트 ID 생성
3. 승인된 리디렉션 URI 설정:
```
https://[PROJECT_ID].supabase.co/auth/v1/callback
```
4. 클라이언트 ID와 비밀번호를 Supabase 설정에 등록
#### 애플 로그인 설정
1. Apple Developer 계정에서 App ID 등록
2. Sign in with Apple 서비스 활성화
3. 서비스 ID 생성 및 도메인 검증
4. 승인된 리디렉션 URI 설정
5. 키 생성 및 Supabase 설정에 등록
### 2. 프론트엔드 구현
#### 로그인 버튼
```jsx
import { supabase } from './supabaseClient';
const SocialLoginButtons = () => {
const handleGoogleLogin = async () => {
await supabase.auth.signInWithOAuth({
provider: 'google',
options: {
redirectTo: 'https://app.zellyy.com/auth/callback'
}
});
};
const handleAppleLogin = async () => {
await supabase.auth.signInWithOAuth({
provider: 'apple',
options: {
redirectTo: 'https://app.zellyy.com/auth/callback'
}
});
};
return (
<div className="social-login">
<button onClick={handleGoogleLogin} className="google-btn">
Google로 계속하기
</button>
<button onClick={handleAppleLogin} className="apple-btn">
Apple로 계속하기
</button>
</div>
);
};
```
#### OAuth 콜백 처리
```jsx
import { useEffect } from 'react';
import { useLocation, useNavigate } from 'react-router-dom';
import { supabase } from './supabaseClient';
const AuthCallback = () => {
const location = useLocation();
const navigate = useNavigate();
useEffect(() => {
// URL에서 인증 정보 추출
const handleAuthCallback = async () => {
const { error } = await supabase.auth.getSession();
if (error) {
console.error('인증 오류:', error);
navigate('/login?error=auth_callback_error');
return;
}
// 성공적으로 인증됨
navigate('/dashboard');
};
handleAuthCallback();
}, [navigate]);
return <div>로그인 처리 중...</div>;
};
```
### 3. 백엔드 구현
#### 사용자 프로필 동기화
새 사용자가 소셜 로그인으로 가입할 때 추가 정보를 저장하는 Supabase 함수:
```sql
-- Supabase 함수로 auth.users 테이블에서 core.users로 사용자 정보 동기화
CREATE OR REPLACE FUNCTION public.handle_new_user()
RETURNS TRIGGER AS $$
BEGIN
INSERT INTO core.users (id, email, name, auth_provider, auth_provider_id, avatar_url)
VALUES (
NEW.id,
NEW.email,
COALESCE(NEW.raw_user_meta_data->>'full_name', NEW.email),
NEW.provider,
NEW.provider_id,
NEW.raw_user_meta_data->>'avatar_url'
);
-- 기본 서비스 접근 권한 부여 (예: 처음 가입한 서비스)
INSERT INTO core.service_access (user_id, service_id, access_level)
SELECT
NEW.id,
id,
'user'
FROM core.services
WHERE name = 'budget'; -- 예시: 적자 탈출 가계부를 기본 서비스로 설정
RETURN NEW;
END;
$$ LANGUAGE plpgsql SECURITY DEFINER;
-- 트리거 설정
CREATE TRIGGER on_auth_user_created
AFTER INSERT ON auth.users
FOR EACH ROW EXECUTE PROCEDURE public.handle_new_user();
```
#### 서비스 간 인증 상태 공유
쿠키 또는 localStorage를 사용한 SSO 세션 관리:
```javascript
// ZELLYY Core API 서비스
export const checkAndRefreshSession = async () => {
const { data, error } = await supabase.auth.getSession();
if (error || !data.session) {
// 세션이 없거나 만료됨
return { isAuthenticated: false };
}
// 세션 활성 연장
if (data.session.expires_at - Date.now() / 1000 < 3600) {
// 만료 1시간 전이면 갱신
await supabase.auth.refreshSession();
}
return {
isAuthenticated: true,
user: data.session.user,
accessibleServices: await getUserServices(data.session.user.id)
};
};
// 사용자의 접근 가능한 서비스 목록 조회
const getUserServices = async (userId) => {
const { data, error } = await supabase
.from('service_access')
.select(`
service:service_id (
id,
name,
description,
api_endpoint
),
access_level
`)
.eq('user_id', userId);
if (error) throw new Error('서비스 접근 권한 조회 실패');
return data.map(item => ({
...item.service,
accessLevel: item.access_level
}));
};
```
## 통합 사용자 경험
### 1. 최초 로그인
1. 사용자가 어느 ZELLYY 서비스에서든 "구글로 로그인" 버튼 클릭
2. 구글 OAuth 인증 화면으로 리다이렉트
3. 인증 후 ZELLYY Core로 리다이렉트
4. 최초 로그인인 경우:
- 사용자 프로필 정보 저장
- 접근한 서비스에 대한 권한 부여
- 환영 화면 표시
5. 로그인 완료 후 원래 서비스로 리다이렉트
### 2. 서비스 간 전환
사용자가 이미 로그인한 상태에서 다른 ZELLYY 서비스 접근 시:
1. 서비스는 로컬 스토리지 또는 쿠키에서 토큰 확인
2. ZELLYY Core API에 토큰 검증 요청
3. 유효한 토큰이면 자동 로그인 처리
4. 접근 권한이 없는 서비스의 경우 권한 요청 화면 표시
### 3. 로그아웃
1. 어느 서비스에서든 로그아웃 시 ZELLYY Core 로그아웃 API 호출
2. 모든 서비스에서 인증 토큰 삭제
3. SSO 세션 종료
## 보안 고려사항
1. **PKCE 인증 흐름**: OAuth에 PKCE(Proof Key for Code Exchange) 사용
2. **토큰 관리**: 짧은 수명의 액세스 토큰과 리프레시 토큰 사용
3. **HTTPS**: 모든 통신은 HTTPS로 암호화
4. **CORS 설정**: API에 적절한 CORS 정책 적용
5. **CSP(Content Security Policy)**: 적절한 CSP 헤더 설정
## 다음 단계
1. 구글 및 애플 개발자 계정 설정 및 OAuth 클라이언트 등록
2. Supabase Auth 설정 및 테스트
3. 로그인 UI 컴포넌트 개발
4. 소셜 로그인 통합 테스트
5. 서비스 간 SSO 흐름 테스트
```

279
ZELLYY/zellyy core/storage-management.md Normal file
View File

@@ -0,0 +1,279 @@
# ZELLYY Core 스토리지 관리 전략
## 개요
이 문서는 ZELLYY Core 시스템의 데이터 및 스토리지 관리 전략을 설명합니다. 스토리지 요구 사항이 증가함에 따라 확장성, 성능, 비용 효율성을 유지하기 위한 접근 방식을 설명합니다.
## 스토리지 요구사항 분석
### 데이터 유형 및 특성
**구조화된 데이터**
- 사용자 정보 및 인증 데이터
- 서비스 구성 및 설정
- 트랜잭션 및 관계형 데이터
**비구조화된 데이터**
- 사용자 업로드 파일 (이미지, 문서 등)
- 로그 및 분석 데이터
- 백업 및 아카이브 데이터
**데이터 증가 예측**
- 사용자 데이터: 월 10% 증가
- 트랜잭션 데이터: 월 15-20% 증가
- 미디어 파일: 월 25-30% 증가
- 로그 및 분석: 월 40% 증가
## 스토리지 아키텍처
### 계층형 스토리지 모델
```
+-------------------------------------------+
| 데이터 계층 |
+-------------------------------------------+
| 핫 스토리지 | 웜 스토리지 | 콜드 스토리지 |
| (고성능) | (표준) | (아카이브) |
| - 활성 사용자 | - 최근 트랜잭션 | - 오래된 로그 |
| - 현재 세션 | - 최근 로그 | - 백업 |
| - 캐시 데이터 | - 최근 파일 | - 아카이브 |
+-------------------------------------------+
| 액세스 빈도: | 액세스 빈도: | 액세스 빈도: |
| 매우 높음 | 중간 | 낮음 |
| 지연 시간: | 지연 시간: | 지연 시간: |
| < 10ms | < 100ms | < 1000ms |
+-------------------------------------------+
```
**데이터 라이프사이클 관리**
- 데이터 생성 시점부터 아카이브/삭제까지 자동화된 정책
- 사용 패턴에 따른 스토리지 계층 간 자동 이동
- 규제 준수를 위한 데이터 보존 정책
### 데이터베이스 스토리지
**관계형 데이터 관리**
- PostgreSQL 테이블 파티셔닝
- 자동 테이블 압축
- 수명 주기별 데이터 분리
**시계열 데이터 최적화**
```sql
-- 시계열 데이터를 위한 분할 테이블 예시
CREATE TABLE metrics (
time_bucket TIMESTAMP NOT NULL,
metric_name TEXT NOT NULL,
metric_value FLOAT NOT NULL,
source TEXT NOT NULL
) PARTITION BY RANGE (time_bucket);
-- 월별 파티션 생성 예시
CREATE TABLE metrics_y2023m01 PARTITION OF metrics
FOR VALUES FROM ('2023-01-01') TO ('2023-02-01');
CREATE TABLE metrics_y2023m02 PARTITION OF metrics
FOR VALUES FROM ('2023-02-01') TO ('2023-03-01');
```
**인덱스 관리 전략**
- 자주 쿼리되는 필드에 인덱스 최적화
- 사용 빈도에 따른 인덱스 조정
- 파티션별 인덱스 관리
### 파일 및 객체 스토리지
**객체 스토리지 구성**
- Supabase Storage 또는 Amazon S3 호환 스토리지 활용
- 버킷 및 폴더 구조화
- 액세스 패턴 기반 스토리지 클래스 선택
**미디어 처리 파이프라인**
```
+----------+ +-----------+ +----------+ +----------+
| 원본 업로드 | --> | 처리/변환 | --> | 스토리지 | --> | CDN 배포 |
+----------+ +-----------+ +----------+ +----------+
|
v
+-----------+
| 메타데이터 |
| 데이터베이스|
+-----------+
```
**콘텐츠 전송 최적화**
- CDN을 통한 글로벌 배포
- 이미지/비디오 최적화
- 적응형 비트레이트 스트리밍
## 스토리지 확장 전략
### 수평적 확장
**데이터베이스 샤딩**
- 사용자 ID 기반 샤딩
- 지리적 위치 기반 샤딩
- 샤드 간 조정 및 관리
**분산 파일 시스템**
- 객체 스토리지의 멀티 리전 복제
- 동적 용량 확장
- 지역 최적화 액세스
### 수직적 확장
**스토리지 성능 최적화**
- 고성능 스토리지 계층 (SSD) 활용
- 메모리 기반 캐싱 계층
- 리소스 증설을 통한 확장
**IOPS 및 처리량 관리**
- 워크로드 특성에 따른 스토리지 프로비저닝
- 버스트 용량 계획
- 성능 병목 모니터링
### 하이브리드 스토리지 전략
**온프레미스와 클라우드 통합**
- 중요 데이터는 로컬 스토리지 보관
- 대용량 및 덜 중요한 데이터는 클라우드로 이동
- 통합 스토리지 관리 인터페이스
**스토리지 마이그레이션 전략**
- 데이터 중단 없는 마이그레이션
- 단계적 데이터 이전 계획
- 마이그레이션 검증 프로세스
## 데이터 보호 및 규정 준수
### 백업 및 복구 전략
**백업 정책**
- 일일 증분 백업
- 주간 전체 백업
- 월간 아카이브 백업
- 오프사이트(다른 리전) 백업 복제
**데이터 복구 프로세스**
```
+-------------------+ +-------------------+ +-------------------+
| 1. 백업 선택 | --> | 2. 복구 환경 준비 | --> | 3. 데이터 복원 |
+-------------------+ +-------------------+ +-------------------+
|
+-------------------+ +-------------------+ +-------------------+
| 6. 운영 전환 | <-- | 5. 데이터 검증 | <-- | 4. 정합성 확인 |
+-------------------+ +-------------------+ +-------------------+
```
**복구 지점 목표(RPO) 및 복구 시간 목표(RTO)**
- 중요 데이터: RPO 15분, RTO 1시간
- 일반 데이터: RPO 1시간, RTO 4시간
- 아카이브 데이터: RPO 24시간, RTO 24시간
### 데이터 보존 및 삭제 정책
**데이터 보존 정책**
- 사용자 데이터: 계정 삭제 후 30일
- 트랜잭션 데이터: 7년
- 로그 데이터: 90일 활성, 1년 아카이브
- 서비스 설정: 영구 보존
**규정 준수 데이터 보존**
- GDPR, CCPA 등 규정 기반 데이터 처리
- 법적 보존(Legal hold) 관리
- 보존 증명 문서화
**안전한 데이터 삭제**
- 소프트 삭제 (논리적 삭제)
- 하드 삭제 (물리적 삭제)
- 데이터 삭제 증명 및 감사
### 암호화 및 데이터 보안
**저장 데이터 암호화**
- 데이터베이스 TDE(Transparent Data Encryption)
- 객체 스토리지 서버 측 암호화
- 암호화 키 관리 시스템
**전송 중 데이터 암호화**
- TLS/SSL 통신
- VPN 터널링
- API 간 통신 암호화
**액세스 제어 및 감사**
- 역할 기반 액세스 제어(RBAC)
- 최소 권한 원칙 적용
- 모든 액세스 시도 로깅 및 감사
## 스토리지 모니터링 및 최적화
### 성능 모니터링
**핵심 성능 지표**
- 읽기/쓰기 지연 시간
- IOPS 및 처리량
- 저장 용량 사용률
- 캐시 히트율
**알림 및 대응**
- 용량 임계값 알림
- 성능 저하 감지
- 자동 스케일링 트리거
### 비용 최적화
**스토리지 비용 분석**
- 서비스별 스토리지 비용 할당
- 계층별 비용 추적
- 사용 패턴 기반 비용 예측
**스토리지 최적화 전략**
- 자주 접근하지 않는 데이터 저비용 계층으로 이동
- 중복 데이터 제거
- 압축 및 최적화 정책
**데이터 수명 주기 자동화**
```javascript
// 예: 자동 계층화 정책
const storageRules = [
{
dataType: 'userUploads',
hotStorageDuration: '30days',
warmStorageDuration: '90days',
coldStorageThreshold: 'accessCount < 5',
retentionPeriod: '7years',
},
{
dataType: 'applicationLogs',
hotStorageDuration: '7days',
warmStorageDuration: '30days',
archiveThreshold: '90days',
deletionThreshold: '1year',
}
];
```
## 구현 로드맵
### 1단계: 기반 스토리지 아키텍처 설계 (1-2개월)
- 데이터 유형 및 특성 분석
- 스토리지 요구사항 정의
- 계층형 스토리지 아키텍처 설계
### 2단계: 초기 구현 (2-3개월)
- 데이터베이스 파티셔닝 구현
- 객체 스토리지 설정
- 백업 및 복구 시스템 구축
### 3단계: 확장성 기능 구현 (3-6개월)
- 자동 계층화 시스템 개발
- 분산 스토리지 구성
- 성능 모니터링 도구 통합
### 4단계: 고급 기능 및 최적화 (6-12개월)
- 데이터 수명 주기 자동화
- 비용 최적화 시스템 구현
- 규정 준수 관리 도구 통합
## 결론
ZELLYY Core의 스토리지 관리 전략은 확장성, 성능, 비용 효율성, 데이터 보호를 종합적으로 고려합니다. 계층형 스토리지 아키텍처는 다양한 데이터 유형과 액세스 패턴을 효율적으로 지원하며, 자동화된 데이터 라이프사이클 관리는 운영 오버헤드를 최소화합니다. 이러한 접근 방식은 데이터 볼륨이 증가하고 사용 패턴이 변화함에 따라 ZELLYY Core가 효율적으로 확장할 수 있는 기반을 제공합니다.