🏢 멀티테넌트(Multi-Tenancy) 정리
💡 개념 요약
| 구분 | 설명 |
|---|
| 정의 | 하나의 애플리케이션 또는 인프라에서 여러 고객(테넌트) 의 데이터를 분리하여 사용하는 구조 |
| 목적 | 리소스 절감, 유지보수 효율성, 확장성 향상 |
| 테넌트(Tenant) | 서비스를 사용하는 개별 고객, 회사, 또는 조직 |
| 예시 | 하나의 SaaS 시스템을 여러 기업이 함께 사용하되, 각 기업의 데이터는 분리되어 관리됨 |
⚙️ 멀티테넌트 구조 유형
| 유형 | 설명 | 장점 | 단점 |
|---|
| ① DB 공유 / 스키마 공유 | 하나의 DB와 스키마를 여러 테넌트가 함께 사용하며, 각 테넌트는 tenant_id로 구분 | 운영비용 최소화, 관리 용이 | 데이터 격리 수준 낮음, 보안 취약 가능 |
| ② DB 공유 / 스키마 분리 | 하나의 DB 내에서 테넌트별로 별도 스키마를 생성 | 격리 수준 향상, 관리 효율적 | 스키마 관리 복잡도 증가 |
| ③ DB 분리 | 테넌트마다 별도의 DB 인스턴스를 가짐 | 최고 수준의 데이터 보안과 독립성 | 리소스 소모 많음, 유지보수 비용 증가 |
🧱 핵심 구성요소
| 구성요소 | 설명 |
|---|
| Tenant Identifier | 테넌트를 구분하는 고유 ID (예: tenant_id) |
| Tenant Context | 요청(Request)마다 어떤 테넌트의 요청인지 식별하기 위한 컨텍스트 |
| Tenant Resolver | HTTP Header, 도메인, 토큰 등을 분석해 어떤 테넌트의 요청인지 판단 |
| Tenant DataSource | 각 테넌트에 맞는 DB 또는 스키마를 선택하여 연결 관리 |
🧩 구현 방식 예시 (Spring 기반)
| 방식 | 설명 |
|---|
| 1️⃣ Schema-based Multi-Tenancy | Hibernate의 MultiTenantConnectionProvider 와 CurrentTenantIdentifierResolver 사용 |
| 2️⃣ Database-based Multi-Tenancy | 테넌트별 DataSource를 등록하고, 요청 시 해당 DB로 라우팅 |
| 3️⃣ Hybrid 방식 | 일부 핵심 고객은 전용 DB, 일반 고객은 공유 스키마 방식 혼합 적용 |
🔐 멀티테넌트의 장단점
| 구분 | 장점 | 단점 |
|---|
| 운영 측면 | 리소스 절약, 자동화 용이, 단일 코드베이스 유지 가능 | 특정 테넌트 장애가 전체에 영향 가능 |
| 보안 측면 | 중앙 통제 가능 | 격리 수준 낮으면 데이터 누출 위험 |
| 개발 측면 | 공통 코드 재사용 가능 | 테넌트별 커스터마이징 어려움 |
☁️ 실제 사용 사례
| 서비스 | 설명 |
|---|
| Salesforce | 대표적인 멀티테넌트 SaaS, 모든 고객이 하나의 시스템 인스턴스 공유 |
| AWS RDS / Aurora | DB 레벨 멀티테넌시 지원으로 다수의 고객 DB를 효율적으로 관리 |
| Atlassian (Jira, Confluence) | 고객별 논리적 데이터 분리 및 공용 애플리케이션 코드 운영 |
🧭 선택 가이드
| 상황 | 추천 아키텍처 |
|---|
| 스타트업 / MVP 단계 | DB 공유 + 스키마 공유 |
| 성장 중인 SaaS 서비스 | DB 공유 + 스키마 분리 |
| 대기업 / 금융권 서비스 | DB 분리 (고보안 환경) |
🧭 DDD (Domain-Driven Design) 아키텍처 정리
💡 개념 요약
| 구분 | 설명 |
|---|
| 정의 | DDD(Domain-Driven Design, 도메인 주도 설계)는 비즈니스 도메인 중심으로 소프트웨어를 설계하는 방법론 |
| 목적 | 비즈니스 규칙과 요구사항을 코드 구조에 직접 반영하여, 유지보수성과 이해도를 높이는 것 |
| 핵심 철학 | “코드는 도메인을 표현해야 한다.” → 도메인의 언어(Ubiquitous Language)를 코드로 옮긴다. |
🧱 주요 개념
| 개념 | 설명 |
|---|
| Domain (도메인) | 문제를 해결하고자 하는 비즈니스 영역 (예: 주문, 결제, 재고 등) |
| Entity (엔티티) | 고유 식별자를 가지며, 생명주기가 있는 객체 (예: Order, User) |
| Value Object (값 객체) | 식별자가 없고, 값 자체로 동등성 판단 (예: Money, Address) |
| Aggregate (집합체) | 엔티티와 값 객체의 묶음, 일관성 유지 단위 |
| Aggregate Root | 집합체의 대표 엔티티로, 외부 접근은 루트를 통해서만 가능 |
| Repository (저장소) | 엔티티/집합체를 저장하고 조회하는 추상 계층 |
| Service (도메인 서비스) | 특정 엔티티에 속하지 않는 비즈니스 로직을 담당 |
| Domain Event | 도메인 내에서 발생한 중요한 사건 (예: 주문 생성됨, 결제 완료됨) |
| Ubiquitous Language | 개발자와 도메인 전문가가 공유하는 공통 언어 |
⚙️ DDD 아키텍처 계층 구조
DDD는 일반적으로 4개의 계층으로 구성된다.
| 계층 | 설명 | 예시 |
|---|
| 1️⃣ Presentation Layer (표현 계층) | 사용자 인터페이스, API 요청 처리 | Controller, View |
| 2️⃣ Application Layer (응용 계층) | 비즈니스 흐름 조정, 트랜잭션 관리 | Service, Use Case |
| 3️⃣ Domain Layer (도메인 계층) | 핵심 비즈니스 로직, 엔티티/도메인 서비스 | Entity, DomainService |
| 4️⃣ Infrastructure Layer (인프라 계층) | 외부 시스템, DB, 메시징 등과의 연동 | Repository 구현, 외부 API |
💡 핵심은 Domain Layer가 시스템의 중심이 되어야 한다는 점이다.
🧩 DDD 설계 흐름 예시
1️⃣ 도메인 분석
→ 비즈니스 전문가와 협업하여 핵심 개념과 규칙을 도출
2️⃣ Ubiquitous Language 정의
→ 도메인 전문가와 개발자가 공통된 용어를 사용
3️⃣ Bounded Context 설정
→ 시스템을 도메인별로 나누고, 경계를 명확히 구분
4️⃣ 도메인 모델 설계
→ Entity, Value Object, Aggregate 정의
5️⃣ 리포지토리와 서비스 구현
→ 도메인 로직을 중심으로 Repository, Application Service 작성
6️⃣ 인프라 연동
→ DB, 외부 API, 메시지 큐 등과 연결
🧱 Bounded Context (경계 컨텍스트)
| 구분 | 설명 |
|---|
| 정의 | 하나의 도메인 모델이 유효한 논리적 경계 영역 |
| 역할 | 도메인 충돌 방지, 팀 간 독립적인 개발 가능 |
| 예시 | 주문(Order), 결제(Payment), 배송(Shipping) 등으로 분리 |
💬 각 컨텍스트 간 통신은 이벤트, API, 메시징 등을 통해 이루어진다.
🧩 DDD 예시 구조 (Spring 기준)
📦 com.example.order
┣ 📂 application # 응용 서비스 계층
┃ ┗ OrderService.java
┣ 📂 domain # 도메인 계층
┃ ┣ 📂 model
┃ ┃ ┣ Order.java
┃ ┃ ┣ OrderItem.java
┃ ┃ ┗ Money.java
┃ ┗ 📂 repository
┃ ┗ OrderRepository.java
┣ 📂 infrastructure # 인프라 계층
┃ ┣ JpaOrderRepository.java
┃ ┗ PaymentGatewayClient.java
┗ 📂 presentation # 표현 계층
┗ OrderController.java
🔗 전통적인 Layered Architecture와 비교
| 구분 | Layered Architecture | DDD Architecture |
|---|
| 중심 축 | 데이터 / DB 중심 | 비즈니스 도메인 중심 |
| 주요 목표 | 데이터 CRUD 중심 | 비즈니스 로직 표현 |
| 장점 | 단순하고 빠른 개발 | 복잡한 비즈니스 로직에 유리 |
| 단점 | 유지보수 시 도메인 복잡성 증가 | 초기 설계 비용 높음 |
☁️ SaaS 기반 설계 (Software as a Service Architecture)
💡 개념 요약
| 구분 | 설명 |
|---|
| 정의 | SaaS(Software as a Service)는 소프트웨어를 설치하지 않고, 인터넷을 통해 서비스 형태로 제공하는 모델 |
| 특징 | 사용자는 클라우드 환경에서 브라우저나 API를 통해 접근하며, 설치나 유지보수가 필요 없음 |
| 대표 서비스 | Google Workspace, Salesforce, Slack, Zoom, Notion 등 |
| 핵심 가치 | 빠른 배포, 자동 업데이트, 낮은 초기 비용, 유연한 확장성 |
⚙️ SaaS 아키텍처 핵심 구성요소
| 구성요소 | 설명 | 예시 |
|---|
| Multi-Tenancy (멀티테넌시) | 하나의 애플리케이션 인스턴스로 여러 고객(테넌트)을 서비스 | DB 공유형 / 분리형 |
| Scalability (확장성) | 트래픽 증가 시 자동으로 인프라 확장 | AWS Auto Scaling, Kubernetes |
| Configurability (설정 가능성) | 고객별로 기능/정책을 다르게 설정할 수 있는 구조 | 요금제별 기능 차등 |
| Security (보안) | 데이터 격리, 인증, 암호화 등 필수 | OAuth2, JWT, HTTPS |
| Monitoring (모니터링) | 서비스 상태, 트래픽, 에러 등을 실시간 관리 | Prometheus, Grafana |
🧩 SaaS 계층 구조
| 계층 | 역할 | 예시 구성 |
|---|
| 1️⃣ Presentation Layer (표현 계층) | 사용자 인터페이스(UI) 및 API 엔드포인트 | React, Vue.js, REST API |
| 2️⃣ Application Layer (응용 계층) | 비즈니스 로직, 서비스 규칙 구현 | Spring Boot, NestJS |
| 3️⃣ Domain Layer (도메인 계층) | 핵심 비즈니스 규칙과 도메인 모델 관리 | DDD 기반 설계 |
| 4️⃣ Infrastructure Layer (인프라 계층) | 데이터베이스, 메시징, 외부 API 연동 | AWS RDS, Kafka, Redis |
🧱 SaaS 핵심 기술 구성
| 기술 요소 | 설명 | 사용 예시 |
|---|
| API Gateway | 인증, 라우팅, 트래픽 제어 | Nginx, Kong, AWS API Gateway |
| Load Balancer | 요청을 여러 서버로 분산 | AWS ELB, Nginx, HAProxy |
| Database | 테넌트별 데이터 저장 | PostgreSQL, MongoDB |
| Authentication / Authorization | 사용자 인증 및 권한 관리 | OAuth2, Keycloak, JWT |
| CI/CD | 지속적 통합 및 배포 자동화 | GitHub Actions, Jenkins, ArgoCD |
| Containerization | 서비스 독립성과 배포 효율성 향상 | Docker, Kubernetes |
🧭 멀티테넌시 설계 패턴 (Multi-Tenant Architecture)
| 유형 | 설명 | 장점 | 단점 |
|---|
| ① DB 공유 / 테이블 분리 | 하나의 DB에서 테넌트를 구분 (tenant_id) | 관리 용이, 비용 절감 | 데이터 격리 취약 |
| ② DB 공유 / 스키마 분리 | 동일 DB 내에서 테넌트별 스키마 분리 | 보안 강화, 논리적 분리 | 스키마 관리 복잡 |
| ③ DB 분리형 | 테넌트별 독립 DB 운영 | 최고 수준 보안, 장애 격리 | 인프라 비용 증가 |
💡 SaaS 초기에는 스키마 분리형으로 시작하고, 엔터프라이즈 고객 증가 시 DB 분리형으로 확장하는 전략이 일반적이다.
☁️ SaaS 운영 아키텍처 개념도
📦 SaaS Application
┣ 📂 Frontend (React, Vue)
┣ 📂 Backend (Spring Boot / Node.js)
┣ 📂 Database (Multi-Tenant)
┣ 📂 API Gateway
┣ 📂 Auth Server (JWT / OAuth2)
┗ 📂 Monitoring & Logging (Grafana, Loki)
🔐 SaaS 보안 설계 포인트
| 구분 | 주요 내용 |
|---|
| 인증(Authentication) | OAuth2, SSO(Single Sign-On), JWT 기반 인증 |
| 인가(Authorization) | RBAC(Role-Based Access Control) 적용 |
| 데이터 격리(Data Isolation) | 테넌트 ID 기반 접근 제어 |
| 암호화(Encryption) | 전송 중 HTTPS, 저장 시 AES256 암호화 |
| 감사 로그(Audit Log) | 사용 내역 및 변경 이력 기록 |
🧩 SaaS 개발 시 고려사항
| 항목 | 설명 |
|---|
| 확장성 | 트래픽 급증에도 안정적인 서비스 제공 가능해야 함 |
| 고가용성(HA) | 장애 발생 시에도 서비스 중단 없이 운영 |
| 비용 효율성 | 멀티테넌시를 활용한 자원 공유 극대화 |
| 버전 관리 | 고객별 기능 차별화 및 롤백 가능 구조 |
| 자동화 | 배포, 테스트, 모니터링 자동화 필수 |
🔗 SaaS vs On-Premise 비교
| 구분 | SaaS | On-Premise |
|---|
| 설치 방식 | 클라우드 기반, 웹 브라우저로 접근 | 로컬 서버에 직접 설치 |
| 유지보수 | 제공자가 전담 | 사용자가 직접 수행 |
| 비용 구조 | 구독형 (월/년 단위) | 초기 구축비용 발생 |
| 배포 속도 | 자동 업데이트 가능 | 수동 패치 필요 |
| 확장성 | 즉시 확장 가능 | 하드웨어 제약 있음 |
⚛️ React Hook 정리 가이드
💡 React Hook 개념 요약
| 구분 | 설명 |
|---|
| 정의 | React 16.8 버전부터 도입된 기능으로, 클래스형 컴포넌트 없이 상태(state)와 생명주기(lifecycle) 로직을 사용할 수 있게 해주는 함수형 컴포넌트용 기능 |
| 핵심 목적 | 코드 재사용성 향상, 함수형 컴포넌트의 기능 확장, 복잡한 로직 단순화 |
| 특징 | 함수형 컴포넌트 내부에서만 사용 가능, 조건문·반복문 내에서 사용 불가 |
| 명명 규칙 | 모든 Hook은 use로 시작해야 함 (예: useState, useEffect) |
🧱 주요 Hook 정리
| Hook | 주요 기능 | 특징 | 주 사용 사례 |
|---|
| useState | 상태(State) 관리 | 컴포넌트의 상태값을 저장하고 갱신할 수 있음 | 입력 폼, 토글, 카운터 등 |
| useEffect | 사이드 이펙트(Effect) 관리 | 렌더링 이후 실행되는 부수 효과 처리 | API 호출, 구독, DOM 조작 |
| useContext | 전역 상태 관리 | Context API를 통한 데이터 전달 | 다크모드, 사용자 정보 공유 |
| useReducer | 복잡한 상태 관리 | useState의 확장형으로, 리듀서 패턴 적용 | Todo 리스트, 상태 트랜잭션 관리 |
| useMemo | 메모이제이션 | 값 계산 결과를 캐싱하여 성능 최적화 | 연산량이 많은 계산 최적화 |
| useCallback | 함수 메모이제이션 | 함수를 캐싱하여 불필요한 렌더링 방지 | Props로 함수 전달 시 |
| useRef | DOM 또는 변수 참조 | 렌더링과 무관한 데이터 저장 | 포커스 제어, 이전 값 저장 |
| useLayoutEffect | 동기식 Effect 처리 | useEffect와 유사하지만, DOM 변경 직후 동기 실행 | 레이아웃 측정, 애니메이션 초기화 |
| useImperativeHandle | 부모가 자식의 메서드 제어 | forwardRef와 함께 사용 | 컴포넌트 외부에서 내부 기능 제어 |
| useId | 고유 ID 생성 | 서버/클라이언트 모두에서 유니크한 ID 보장 | 접근성(ARIA) 속성 설정 |
| useTransition | 비동기 상태 전환 관리 | 렌더링 우선순위를 낮춰 UI 지연 방지 | 대규모 렌더링 최적화 |
| useDeferredValue | 입력 지연 처리 | 입력 지연 시 렌더링 부담 완화 | 실시간 검색, 자동완성 기능 |
🔍 주요 Hook 상세 비교
🧩 useState vs useReducer
| 항목 | useState | useReducer |
|---|
| 목적 | 단순한 상태 관리 | 복잡한 상태 로직 관리 |
| 상태 업데이트 방식 | setState(value) | dispatch(action) |
| 적합한 상황 | 토글, 카운터, 입력값 등 | 여러 상태가 상호작용하는 복잡한 로직 |
const [count, setCount] = useState(0);
setCount(prev => prev + 1);
const reducer = (state, action) => {
switch(action.type) {
case "INCREMENT": return state + 1;
default: return state;
}
};
const [state, dispatch] = useReducer(reducer, 0);
⚡ useEffect vs useLayoutEffect
| 항목 | useEffect | useLayoutEffect |
|---|
| 실행 시점 | 브라우저 렌더링 이후 비동기 실행 | DOM 변경 직후 동기 실행 |
| 주 사용 목적 | 데이터 요청, 이벤트 등록 | 레이아웃 조정, DOM 측정 |
| 렌더링 차단 여부 | ❌ 렌더링 차단하지 않음 | ✅ 렌더링 차단 가능 (주의 필요) |
useEffect(() => console.log("비동기 실행"));
useLayoutEffect(() => console.log("동기 실행"));
🧠 useMemo vs useCallback
| 항목 | useMemo | useCallback |
|---|
| 리턴 타입 | 계산된 값(Value) | 메모이제이션된 함수(Function) |
| 용도 | 연산 결과 캐싱 | 함수 재생성 방지 |
| 적용 대상 | 값 계산이 많은 경우 | Props로 함수 전달 시 렌더링 방지 |
const value = useMemo(() => heavyCalculation(data), [data]);
const handleClick = useCallback(() => setCount(count + 1), [count]);
🧩 고급 Hook
| Hook | 설명 | 활용 예시 |
|---|
| useImperativeHandle | 부모가 자식 컴포넌트 내부의 메서드에 접근할 수 있도록 제어 | 모달 창, 스크롤 제어 |
| useTransition | 비동기 상태 전환을 분리하여 렌더링 최적화 | 입력 시 UI 끊김 방지 |
| useDeferredValue | 값 업데이트를 지연시켜 성능 향상 | 실시간 검색창 구현 |
| useId | 고유 ID 생성 (서버/클라이언트 일관성 유지) | 폼 요소의 접근성 향상 |
🔗 Hook 사용 시 주의사항
| 항목 | 설명 |
|---|
| 1️⃣ Hook은 함수 컴포넌트 최상단에서만 호출 | 조건문, 반복문, 중첩 함수 내에서는 사용 불가 |
2️⃣ Hook은 함수명 use로 시작해야 함 | 사용자 정의 Hook(useCustom) 작성 시도 동일 규칙 적용 |
| 3️⃣ 의존성 배열(dependency array) 관리 | 잘못된 의존성 설정은 무한 렌더링 초래 가능 |
| 4️⃣ Custom Hook으로 로직 분리 | 중복 로직은 커스텀 훅으로 추출하여 재사용성 확보 |
🧾 요약
| 핵심 포인트 | 설명 |
|---|
| ⚛️ Hook의 목적 | 함수형 컴포넌트에서 상태, 생명주기, 로직 분리 가능 |
| 🧱 기본 Hook | useState, useEffect, useContext |
| 🚀 성능 최적화 Hook | useMemo, useCallback, useDeferredValue |
| 🔄 고급 제어 Hook | useReducer, useRef, useTransition |
| 🧩 Custom Hook | 공통 로직을 재사용 가능한 형태로 추출 |
| ⚠️ 주의사항 | Hook은 항상 컴포넌트의 최상단에서만 호출 |
🚀 프로젝트 구상 정리
🧩 프로젝트 개요
| 구분 | 설명 |
|---|
| 프로젝트 주제 | 멀티테넌트 + DDD 아키텍처 + SaaS 기반 서비스 |
| 핵심 목표 | 사용자 가입 시 자동으로 독립된 DB 및 권한 구조를 생성하는 SaaS 시스템 구축 |
| 핵심 기술 | React Hook (useEffect, useMemo, useState) 관리 및 활용 |
🏗️ 구현 서브도메인
| 서브도메인 | 설명 |
|---|
| 멀티테넌트 (Multi-Tenant) | 하나의 애플리케이션 인스턴스로 여러 사용자를 지원하며, 각 사용자의 데이터는 분리 관리 |
| DDD 아키텍처 (Domain-Driven Design) | 도메인 중심의 설계를 통해 비즈니스 로직을 명확히 정의 |
| SaaS 기반 설계 | 클라우드 환경에서 서비스형 소프트웨어 제공 구조로 확장성 및 자동화 강화 |
⚙️ 핵심 기능 설계
| 기능 | 설명 |
|---|
| 회원가입 시 DB 자동 생성 | 신규 회원 가입 시 전용 DB 또는 스키마 자동 생성 |
| API 데이터 복사 기능 | 신규 DB 생성 시 초기 데이터를 자동 복사 |
| 권한 부여 시스템 | DB 생성 시 해당 사용자에게 관리자 권한 부여 |
| 권한 관리 구조 | 사용자별 권한(Role)에 따라 접근 제어 및 데이터 격리 |
⚡ React Hook 관리 중요성
React의 주요 Hook을 효율적으로 관리하여 성능 및 상태 일관성을 유지해야 함.
| Hook | 역할 | 활용 포인트 |
|---|
| useState | 상태 관리 | 사용자 입력, UI 상태 제어 |
| useEffect | 사이드 이펙트 관리 | DB 생성, API 요청, 권한 로딩 처리 |
| useMemo | 성능 최적화 | 복잡한 연산이나 API 응답 캐싱 |
💡 Hook 간의 의존성을 명확히 설정하여 불필요한 렌더링 방지 필요
🧭 기대 효과
| 항목 | 기대 결과 |
|---|
| 서비스 확장성 | 멀티테넌트 구조로 사용자 증가에도 안정적인 운영 가능 |
| 관리 효율성 | DDD 설계를 통한 모듈화 및 유지보수 용이 |
| 보안성 강화 | 사용자별 DB 및 권한 분리로 데이터 접근 통제 |
| 성능 최적화 | React Hook 관리로 렌더링 최소화 및 UX 향상 |
