[디지털 뱃지] 일일 스터디 Day 05
General(Public Cloud) & Developer(Architecture) 핵심 돌파
1. 오늘의 핵심 이론 설명
클라우드 공동 책임 모델(Shared Responsibility)과 서비스 모델 분류(IaaS/PaaS/SaaS)
멀티 클라우드 아키텍처 인프라를 설계할 때 거버넌스와 인프라 관리 범위를 규정하는 가장 기본적이고 강력한 기준입니다.
- 공동 책임 모델의 본질: 퍼블릭 클라우드 공급업체(CSP)와 인프라 이용 고객(Customer) 간의 보안 및 관리 책임 한계를 명확히 구분하는 원칙입니다. 물리 데이터 센터, 하드웨어 호스트 가상화 레이어 등은 **CSP의 책임(Security of the Cloud)**이며, 그 가상화 인프라 위에 배포되는 데이터, 게스트 OS, 방화벽 규칙 등은 **고객의 책임(Security in the Cloud)**입니다.
- 서비스 유형별 관리 스펙트럼:
- IaaS (Infrastructure as Service): 컴퓨팅 리소스, 공유 네트워크, 가상 스토리지의 하위 하드웨어만 공급받으며 엔지니어가 OS 수준부터 직접 튜닝하고 통제합니다.
- PaaS (Platform as Service): 런타임 프레임워크와 미들웨어 영역까지 플랫폼 형태로 공급받아 엔지니어는 인프라 관리 대신 오직 '애플리케이션 소스코드 배포'에만 집중합니다.
- SaaS (Software as Service): 엔드유저용 소프트웨어 형태로 완전 제공되어 데이터 설정 외에 하부 인프라 제어권이 없습니다.
MSA의 단일 진입점, API Gateway 패턴의 역할과 필요성
수많은 마이크로서비스로 쪼개진 백엔드 환경에서 클라이언트 엔드포인트를 하나로 통합하고 트래픽 관리를 단일화하는 필수 아키텍처 기술입니다.
- 라우팅 및 역방향 프록시(Reverse Proxy): 클라이언트는 내부 백엔드 아키텍처 구조나 개별 서비스의 가상 가용 엔드포인트 주소를 알 필요 없이, API Gateway의 단일 URL만 호출하면 Gateway가 요청을 해석하여 적절한 마이크로서비스 인스턴스로 분산(Proxying)해 줍니다.
- 공통 관심사 처리(Cross-Cutting Concerns)의 중앙화: 개별 마이크로서비스 컴포넌트마다 각각 구현해야 했던 **사용자 인증/인가(JWT 토큰 검증 등), 트래픽 제한(Rate Limiting), CORS 정책 선언, SSL 종단(SSL Termination)** 처리를 API Gateway가 최상위 레이어에서 일괄 수행하므로 개발 생산성이 비약적으로 증가합니다.
- 장애 격리 보조: 서킷 브레이커(Circuit Breaker) 패턴 등과 연계하여, 특정 백엔드 마이크로서비스 노드가 다운되더라도 게이트웨이 수준에서 안전하게 폴백(Fallback) 메시지를 리턴하여 전체 애플리케이션 가용성이 도미노처럼 무너지는 현상을 미연에 차단합니다.
2. 디지털 뱃지 레벨 1~2 예상 문제집
Q1. 퍼블릭 클라우드의 '공동 책임 모델(Shared Responsibility Model)' 관점에서, 고객(Customer)이 보안 및 설정에 대한 책임을 전적으로 부담해야 하는 영역과 가장 거리가 먼 것은?
2) 가상 컴퓨팅 서비스(IaaS)에 설치된 게스트 운영체제(OS) 패치 관리
3) 클라우드 물리 인프라 하이퍼바이저 가상화 레이어의 보안 및 하드웨어 결함 교체
4) 가상 네트워크 인바운드/아웃바운드 트래픽 제어를 위한 방화벽(Security Group) 규칙 구성
정답 및 해설 보기
정답: 3)
해설: 물리적 데이터 센터 자산 관리, 서버 호스트 인프라의 결함 유지보수, 하이퍼바이저 단의 보안 격리는 클라우드 공급업체(CSP)가 책임을 지는 'Security of the Cloud' 영역에 명확히 해당합니다.
Q2. 마이크로서비스 아키텍처(MSA)에서 구현되는 'API Gateway' 패턴의 핵심 역할에 대한 설명으로 올바르지 않은 것은?
2) 개별 마이크로서비스들이 가지고 있는 실제 물리 데이터베이스 인스턴스를 하나로 물리적으로 병합하여 동기화한다.
3) 최상위 진입 레이어에서 공통 관심사(인증/인가, SSL 종단, Rate Limiting)를 일괄 처리한다.
4) 클라이언트 앱이 단 하나의 대표 엔드포인트(URL)와 통신하여 내부 마이크로서비스들의 복잡성을 숨겨준다.
정답 및 해설 보기
정답: 2)
해설: API Gateway는 인바운드 트래픽 진입로의 역방향 프록시 역할을 수행하는 컴포넌트일 뿐이며, 백엔드 마이크로서비스들이 지향하는 데이터베이스 독립성(Database per Service) 구조를 침해하거나 물리 데이터베이스를 직접 하나로 통함/제어하지 않습니다.
💡 신기술 추가 지식 : 멀티/하이브리드 클라우드와 고속 전송 컨트롤
기업들이 프라이빗 클라우드(오케스트로 인프라 환경 등)와 퍼블릭 클라우드(AWS, Azure 등)를 결합한 하이브리드 아키텍처를 전방위로 채택함에 따라, 단순히 상위 진입점에서 프록시만 해주는 형태를 넘어 이종 가상화 클러스터 인프라 사이에서 고속으로 패킷과 디스크 IO 스트림을 오케스트레이션해 주는 고성능 라우팅/컨트롤 플레인 기술이 중요해졌습니다. 프라이빗 인프라의 강력한 보안 격리성과 퍼블릭 인프라의 오토스케일링 유연성을 단일 테넌트처럼 묶기 위해, 인프라 최하부 레이어의 소켓 스트리밍 및 네트워크 하드웨어 가속 기술(SR-IOV 등)을 결합하여 가상 머신(VM) 및 대형 가상 스토리지를 실시간 마이그레이션(Live Migration) 및 제어하는 아키텍처 설계 지식 역시 최신 엔지니어링 동향으로 확고히 부상하고 있습니다.
'Daily > 디지털 뱃지' 카테고리의 다른 글
| [디지털 뱃지] 일일 스터디 Day 07 (0) | 2026.05.28 |
|---|---|
| [디지털 뱃지] 일일 스터디 Day 06 (0) | 2026.05.27 |
| [디지털 뱃지] 일일 스터디 Day 04 (0) | 2026.05.25 |
| [디지털 뱃지] 일일 스터디 Day 03 (0) | 2026.05.24 |
| [디지털 뱃지] 일일 스터디 Day 02 (0) | 2026.05.24 |