본문으로 건너뛰기

아키텍처 설계 원칙

1. 기본 원칙​

1.1 도메인 주도 설계 (DDD)​

1.2 클린 아키텍처​

  • 계층 간 명확한 경계
  • 의존성 규칙 준수
  • 외부 프레임워크로부터 도메인 보호
  • 테스트 용이성 확보

2. 기술 아키텍처​

2.1 서버리스 우선​

  • Cloud Run 기반 컨테이너 배포
  • 자동 스케일링 활용
  • 서버리스 서비스 우선 사용
  • 운영 복잡도 최소화

2.2 데이터 저장소​

  • PostgreSQL: 메인 데이터베이스
    • 트랜잭션이 필요한 데이터
    • 관계형 데이터
    • 정합성이 중요한 데이터
  • Redis: 캐시 및 세션
    • 임시 데이터
    • 세션 정보
    • 실시간 집계 데이터
    • 분산 락
  • FireStore: NoSQL 데이터베이스
    • 대용량 비정형 데이터
    • 실시간 데이터 동기화
    • 이벤트 로그 및 히스토리
    • 확장성이 중요한 데이터
    • 문서 기반 데이터

2.3 데이터 저장소 선택 기준​

  • 데이터 특성에 따른 저장소 선택
    • 관계형 데이터: PostgreSQL
    • 임시/캐시 데이터: Redis
    • 비정형/대용량 데이터: FireStore
  • 다중 저장소 패턴 적용
    • 데이터 일관성 유지 전략
    • 이벤트 기반 동기화
    • 폴리글랏 퍼시스턴스

2.4 이벤트 기반 통신​

  • GCP Pub/Sub 사용
  • 비동기 이벤트 처리
  • 이벤트 소싱 패턴 적용
  • 멱등성 보장

3. 보안 원칙​

3.1 인증 및 인가​

  • JWT 기반 인증
  • RBAC 기반 권한 관리

3.2 데이터 보안​

  • 전송 구간 암호화 (TLS)
  • 중요 데이터 암호화 저장
  • 접근 로그 기록
  • 보안 감사 지원

3.3 규제 준수 (GDPR)​

  • 개인정보 처리 아키텍처 설계
    • 데이터 최소화 원칙 적용
    • 개인정보 처리 흐름 명확화
    • 데이터 주체 권리 행사 지원 구조
  • 동의 관리 메커니즘
    • 동의 획득 및 철회 프로세스
    • 동의 이력 관리 구조
    • 목적별 동의 분리
  • 개인정보 보호 기술 적용
    • 저장 및 전송 시 암호화
    • 데이터 익명화/가명화 메커니즘
    • 접근 제어 및 감사 추적
  • 데이터 생명주기 관리
    • 보관 기간 설정 및 관리
    • 자동 삭제/익명화 메커니즘
    • 데이터 이동성 지원

3.4 데이터 호스팅 위치​

  • DiGA 및 GDPR 규제 준수를 위한 데이터 리전 제한
    • 모든 프로덕션 데이터는 독일 리전(europe-west3)에서만 호스팅
    • 백업 및 복제본 또한 EU 내 리전으로 제한
    • 독일 외부 리전으로의 데이터 이전 금지
  • 클라우드 서비스 선택 시 리전 제약 고려
    • Google Cloud 서비스 사용 시 europe-west3(프랑크푸르트) 리전 필수
    • 리전 제한이 있는 서비스의 경우 대안 검토
  • 데이터 저장소별 리전 설정
    • Cloud SQL (PostgreSQL): europe-west3 리전 인스턴스 사용, 백업도 동일 리전에 저장
    • BigQuery: 데이터셋 위치를 europe-west3로 설정, 쿼리 처리도 동일 리전에서 수행
    • Firestore: europe-west3 단일 리전 설정 사용 (멀티 리전 옵션 사용 금지)
    • Memorystore (Redis): europe-west3 리전 인스턴스 배포
    • Cloud Storage: europe-west3 리전 버킷만 사용, 데이터 클래스 선택 시 리전 제약 고려
  • 데이터 지역성 검증
    • 배포 파이프라인에서 리전 설정 검증
    • 정기적인 규정 준수 감사 수행
    • 서비스 제공업체의 데이터 위치 보증 문서 관리
  • 개발 및 테스트 환경 고려사항
    • 개발 및 테스트 환경도 가능한 europe-west3 리전 사용 권장

3.5 데이터베이스 스키마 구분 원칙​

  • 데이터 특성에 따른 스키마 구분
    • 개인정보 관련 데이터는 private 스키마에 저장
    • 비개인정보 데이터는 access_code 스키마에 저장
    • 도메인별 기능 데이터는 해당 도메인명 스키마에 저장 (예: time_machine)
    • 개인정보 포함 여부에 따라 스키마 저장 규칙이 우선 적용됨
  • 스키마 간 접근 정책
    • private 스키마는 엄격한 접근 제어 적용
    • 스키마 간 조인 시 개인정보 익명화/가명화 처리 필수
    • 데이터 계층 간 이동 시 개인정보 필터링 자동화
  • 스키마별 감사 및 로깅
    • private 스키마 접근은 모든 작업 감사 로깅
    • 개인정보 접근 및 변경에 대한 이력 추적
    • 비개인정보 스키마는 변경 작업만 로깅
  • 기술적 구현 가이드
    • ORM 설정에서 스키마 명시적 지정
    • 마이그레이션 파일에서 스키마 분리 관리
    • 도메인 모델 정의 시 스키마 속성 명시

3.5.1 공유 스키마 사용 정책​

  • 기본 원칙은 각 바운디드 컨텍스트가 자체 스키마를 소유하는 것이다.
  • 복수 컨텍스트가 동일 레코드를 직접 갱신해야 하고 다른 통합 패턴으로 해결이 불가능할 때에만 공유 스키마를 검토한다.
  • 공유 스키마에 테이블을 제안할 경우 반드시 아키텍처 리뷰에서 다음을 제시한다.
    1. 공유 데이터의 정의, 사용 컨텍스트, 소유권 및 규제 요구사항
    2. 도메인 이벤트/리드 모델/API 등 대안 검토 결과와 선택 근거
    3. 접근 제어, 감사, 마이그레이션 계획
  • 위 조건을 만족하지 못하면 다음 우선순위로 대안을 검토한다.
    1. 도메인 이벤트 발행 + 개별 리드 모델(선호)
    2. 컨텍스트 간 서비스 API 호출
    3. 뷰 또는 머티리얼라이즈드 뷰를 통한 읽기 전용 공유
  • external_identity* 테이블은 Auth 바운디드 컨텍스트가 소유하므로 auth 스키마에서 관리하며, 필요 시 지역 확장 모듈이 같은 스키마를 사용한다.

4. 확장성 원칙​

4.1 수평적 확장​

  • 상태를 갖지 않는 서비스 설계
  • 분산 캐시 활용
  • 로드 밸런싱 적용
  • 데이터베이스 샤딩 고려

4.2 성능 최적화​

  • 캐시 전략 수립
  • 비동기 처리 활용
  • 데이터베이스 인덱싱
  • N+1 문제 방지

5. 운영 원칙​

5.1 모니터링​

  • Cloud Monitoring 활용
  • 핵심 메트릭 정의
  • 알림 임계치 설정
  • 로그 중앙화

5.2 장애 대응​

  • 서킷 브레이커 패턴
  • 폴백 메커니즘
  • 재시도 전략
  • 장애 격리

6. 개발 프로세스​

6.1 버전 관리​

  • Git 기반 버전 관리
  • 브랜치 전략 준수
  • 코드 리뷰 필수
  • CI/CD 자동화

6.2 테스트​

  • 단위 테스트 필수
  • 통합 테스트 구현
  • E2E 테스트 자동화
  • 성능 테스트 정기 실행

7. API 설계​

7.1 RESTful API​

  • 리소스 중심 설계
  • HTTP 메서드 적절히 사용
  • 상태 코드 표준화
  • 버저닝 전략 수립

7.2 API 보안​

  • 인증/인가 적용
  • 입력값 검증
  • Rate Limiting
  • CORS 정책 설정

8. 시간 관리​

8.1 TimeMachine 원칙​

  • 시스템 시간 직접 사용 금지
  • TimeMachine 서비스 활용
  • 시간대 처리 표준화
  • 테스트 용이성 확보

변경 이력​

버전날짜작성자변경 내용
0.1.02025-03-17bok@weltcorp.com최초 작성
0.2.02025-03-19bok@weltcorp.comDiGA 및 GDPR 준수를 위한 데이터 호스팅 위치 원칙 추가
0.3.02025-04-10bok@weltcorp.com데이터베이스 스키마 구분 원칙 추가