12월 21, 2025
33 분 읽기

클라우드 아키텍트 면접 질문: 설계, 마이그레이션, 보안

interview
career-advice
job-search
클라우드 아키텍트 면접 질문: 설계, 마이그레이션, 보안
Milad Bonakdar

Milad Bonakdar

작성자

멀티 클라우드 설계, 마이그레이션, 마이크로서비스, 재해 복구, 제로 트러스트, 비용 의사결정을 실전 질문으로 준비하세요.


소개

클라우드 아키텍트 면접은 보통 신뢰성과 비용, 관리형 서비스와 이식성, 중앙 표준과 팀 자율성, 보안 통제와 배포 속도 사이의 트레이드오프를 어떻게 판단하는지 확인합니다. 좋은 답변은 비즈니스 목표, 제약 조건, 목표 아키텍처, 위험, 출시 후 운영 모델까지 설명합니다.

이 가이드를 통해 멀티 클라우드 전략, 마이그레이션 계획, 마이크로서비스, 서비스 메시, 재해 복구, 제로 트러스트, 비용 최적화 질문을 연습하세요.


멀티 클라우드 전략

1. 멀티 클라우드 전략을 어떻게 설계합니까?

답변: 멀티 클라우드는 복원력, 비용 최적화 및 벤더 종속 방지를 위해 여러 클라우드 공급자를 활용합니다.

주요 고려 사항:

Loading diagram...

아키텍처 패턴:

1. Active-Active:

  • 워크로드가 여러 클라우드에서 동시에 실행됩니다.
  • 공급자 간에 로드 밸런싱됩니다.
  • 최대 가용성

2. Active-Passive:

  • 프로덕션을 위한 기본 클라우드
  • 재해 복구를 위한 보조 클라우드
  • 비용 효율적

3. 클라우드 독립적 서비스:

  • 이식성을 위해 Kubernetes 사용
  • 클라우드 전반의 IaC를 위한 Terraform 사용
  • 표준화된 CI/CD 파이프라인

과제:

  • 관리 복잡성
  • 데이터 전송 비용
  • 기술 요구 사항
  • 일관된 보안 정책

희소성: 일반적 난이도: 어려움


2. 클라우드 마이그레이션을 어떻게 계획하고 실행합니까?

답변: 클라우드 마이그레이션에는 신중한 계획, 위험 평가 및 단계적 실행이 필요합니다.

마이그레이션의 7가지 R:

Loading diagram...

마이그레이션 전략:

1. Rehost (Lift and Shift):

  • 애플리케이션을 최소 변경으로 이동
  • 데이터센터를 빠르게 종료해야 할 때 유용
  • 마이그레이션 후 최적화가 필요한 경우가 많음

2. Relocate:

  • 애플리케이션 변경 없이 플랫폼 또는 가상화 워크로드 이동
  • 대상 클라우드가 호환되는 이전 경로를 제공할 때 유용
  • 네트워크, ID, 백업, 라이선스 가정 검증

3. Replatform:

  • 관리형 데이터베이스나 컨테이너 플랫폼으로 이동하는 등 제한적 변경
  • 마이그레이션 속도와 운영 개선의 균형

4. Refactor/Re-architect:

  • 클라우드 네이티브 확장성, 복원력, 배포 속도를 위해 재설계
  • 가장 큰 노력이 필요하므로 가치가 높은 시스템에 적용

5. Repurchase:

  • 애플리케이션을 SaaS로 교체
  • 예: 맞춤 CRM을 관리형 CRM 플랫폼으로 대체

6. Retire:

  • 더 이상 비즈니스 가치를 만들지 않는 애플리케이션 폐기

7. Retain:

  • 규정 준수, 지연 시간, 비용, 순서상 이유로 시스템을 그대로 유지

마이그레이션 단계:

# 마이그레이션 평가 도구
class MigrationAssessment:
    def __init__(self, application):
        self.app = application
        self.score = 0
    
    def assess_cloud_readiness(self):
        factors = {
            'architecture': self.check_architecture(),
            'dependencies': self.check_dependencies(),
            'data_volume': self.check_data_volume(),
            'compliance': self.check_compliance(),
            'performance': self.check_performance_requirements()
        }
        
        # 마이그레이션 복잡성 계산
        complexity = sum(factors.values()) / len(factors)
        
        if complexity < 3:
            return "Rehost - 낮은 복잡성"
        elif complexity < 6:
            return "Replatform - 중간 복잡성"
        else:
            return "Refactor - 높은 복잡성"
    
    def generate_migration_plan(self):
        return {
            'phase_1': '평가 및 계획',
            'phase_2': '개념 증명',
            'phase_3': '데이터 마이그레이션',
            'phase_4': '애플리케이션 마이그레이션',
            'phase_5': '테스트 및 유효성 검사',
            'phase_6': '전환 및 가동',
            'phase_7': '최적화'
        }

마이그레이션 실행:

1. 평가:

  • 애플리케이션 및 종속성 목록 작성
  • 비용 분석 (TCO)
  • 위험 및 제약 조건 식별

2. 계획:

  • 애플리케이션별 마이그레이션 전략 선택
  • 성공 기준 정의
  • 롤백 계획 생성

3. 파일럿 마이그레이션:

  • 중요하지 않은 애플리케이션부터 시작
  • 접근 방식 유효성 검사
  • 프로세스 개선

4. 데이터 마이그레이션:

# 예: AWS DMS를 사용한 데이터베이스 마이그레이션
aws dms create-replication-instance \
    --replication-instance-identifier migration-instance \
    --replication-instance-class dms.t2.medium

# 마이그레이션 작업 생성
aws dms create-replication-task \
    --replication-task-identifier db-migration \
    --source-endpoint-arn arn:aws:dms:region:account:endpoint/source \
    --target-endpoint-arn arn:aws:dms:region:account:endpoint/target \
    --migration-type full-load-and-cdc

5. 전환 전략:

  • Big Bang: 한 번에 모두 (위험)
  • Phased: 점진적 마이그레이션 (안전)
  • Parallel Run: 두 환경 모두 실행

위험 완화:

  • 포괄적인 테스트
  • 자동화된 롤백 절차
  • 성능 기준선
  • 보안 유효성 검사
  • 비용 모니터링

희소성: 매우 일반적 난이도: 중간-어려움


마이크로서비스 아키텍처

3. 마이크로서비스 아키텍처를 어떻게 설계합니까?

답변: 마이크로서비스는 애플리케이션을 작고 독립적인 서비스로 분해합니다.

아키텍처:

Loading diagram...

주요 원칙:

1. 서비스 독립성:

  • 각 서비스는 자체 데이터를 소유합니다.
  • 독립적인 배포
  • 기술 다양성 허용

2. 통신:

# 동기식 (REST API)
import requests

def get_user(user_id):
    response = requests.get(f'http://user-service/api/users/{user_id}')
    return response.json()

# 비동기식 (메시지 큐)
import pika

def publish_order_event(order_data):
    connection = pika.BlockingConnection(pika.ConnectionParameters('rabbitmq'))
    channel = connection.channel()
    channel.queue_declare(queue='orders')
    channel.basic_publish(
        exchange='',
        routing_key='orders',
        body=json.dumps(order_data)
    )
    connection.close()

3. API 게이트웨이:

  • 단일 진입점
  • 인증/인가
  • 속도 제한
  • 요청 라우팅

4. 서비스 검색:

  • 동적 서비스 등록
  • 상태 점검
  • 로드 밸런싱

이점:

  • 독립적인 확장
  • 기술 유연성
  • 결함 격리
  • 빠른 배포

과제:

  • 분산 시스템 복잡성
  • 데이터 일관성
  • 테스트 복잡성
  • 운영 오버헤드

희소성: 매우 일반적 난이도: 어려움


4. 마이크로서비스에서 서비스 메시를 어떻게 구현합니까?

답변: 서비스 메시는 트래픽 관리, 보안 및 관찰 가능성을 처리하는 서비스 간 통신을 위한 인프라 계층을 제공합니다.

아키텍처:

Loading diagram...

주요 기능:

1. 트래픽 관리:

  • 로드 밸런싱
  • 회로 차단
  • 재시도 및 시간 초과
  • 카나리아 배포
  • A/B 테스팅

2. 보안:

  • mTLS 암호화
  • 인증
  • 권한 부여 정책

3. 관찰 가능성:

  • 분산 추적
  • 메트릭 수집
  • 액세스 로깅

Istio 구현:

# 트래픽 라우팅을 위한 가상 서비스
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: reviews-route
spec:
  hosts:
  - reviews
  http:
  - match:
    - headers:
        user-type:
          exact: premium
    route:
    - destination:
        host: reviews
        subset: v2
      weight: 100
  - route:
    - destination:
        host: reviews
        subset: v1
      weight: 90
    - destination:
        host: reviews
        subset: v2
      weight: 10

---
# 로드 밸런싱을 위한 대상 규칙
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: reviews-destination
spec:
  host: reviews
  trafficPolicy:
    loadBalancer:
      simple: LEAST_REQUEST
    connectionPool:
      tcp:
        maxConnections: 100
      http:
        http1MaxPendingRequests: 50
        maxRequestsPerConnection: 2
  subsets:
  - name: v1
    labels:
      version: v1
  - name: v2
    labels:
      version: v2

회로 차단기 구성:

apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: circuit-breaker
spec:
  host: payment-service
  trafficPolicy:
    outlierDetection:
      consecutiveErrors: 5
      interval: 30s
      baseEjectionTime: 30s
      maxEjectionPercent: 50

mTLS 보안:

apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
  name: default
  namespace: production
spec:
  mtls:
    mode: STRICT

---
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: allow-read
spec:
  action: ALLOW
  rules:
  - from:
    - source:
        principals: ["cluster.local/ns/default/sa/frontend"]
    to:
    - operation:
        methods: ["GET"]

Kiali를 사용한 관찰 가능성:

# 관찰 가능성 애드온으로 Istio 설치
istioctl install --set profile=demo

# Kiali, Prometheus, Grafana, Jaeger 배포
kubectl apply -f samples/addons/

# Kiali 대시보드에 액세스
istioctl dashboard kiali

서비스 메시 비교:

기능IstioLinkerdConsul
복잡성높음낮음중간
성능좋음우수함좋음
기능포괄적필수적포괄적
학습 곡선가파름완만함중간
리소스 사용량높음낮음중간

사용 시기:

  • 공유 트래픽, ID, 관찰 가능성 정책이 운영 부담을 정당화하는 마이크로서비스 환경
  • 고급 트래픽 관리 필요
  • 보안 요구 사항 (mTLS)
  • 다중 클러스터 배포
  • 관찰 가능성 요구 사항

희소성: 일반적 난이도: 어려움


디자인 패턴

5. 회로 차단기 패턴을 설명하고 언제 사용해야 하는지 설명하십시오.

답변: 회로 차단기는 분산 시스템에서 연쇄적 오류를 방지합니다.

상태:

  1. Closed: 정상 작동
  2. Open: 오류가 감지되면 요청이 즉시 실패합니다.
  3. Half-Open: 서비스 복구 여부 테스트
from enum import Enum
import time

class CircuitState(Enum):
    CLOSED = "closed"
    OPEN = "open"
    HALF_OPEN = "half_open"

class CircuitBreaker:
    def __init__(self, failure_threshold=5, timeout=60, success_threshold=2):
        self.failure_threshold = failure_threshold
        self.timeout = timeout
        self.success_threshold = success_threshold
        self.failures = 0
        self.successes = 0
        self.last_failure_time = None
        self.state = CircuitState.CLOSED
    
    def call(self, func, *args, **kwargs):
        if self.state == CircuitState.OPEN:
            if time.time() - self.last_failure_time > self.timeout:
                self.state = CircuitState.HALF_OPEN
                self.successes = 0
            else:
                raise Exception("회로 차단기가 OPEN 상태입니다.")
        
        try:
            result = func(*args, **kwargs)
            self.on_success()
            return result
        except Exception as e:
            self.on_failure()
            raise e
    
    def on_success(self):
        self.failures = 0
        if self.state == CircuitState.HALF_OPEN:
            self.successes += 1
            if self.successes >= self.success_threshold:
                self.state = CircuitState.CLOSED
    
    def on_failure(self):
        self.failures += 1
        self.last_failure_time = time.time()
        if self.failures >= self.failure_threshold:
            self.state = CircuitState.OPEN

# 사용법
breaker = CircuitBreaker()
result = breaker.call(external_api_call, user_id=123)

사용 사례:

  • 외부 API 호출
  • 데이터베이스 연결
  • 마이크로서비스 통신
  • 타사 통합

희소성: 일반적 난이도: 중간-어려움


이벤트 기반 아키텍처

6. 이벤트 기반 아키텍처를 설명하고 언제 사용해야 하는지 설명하십시오.

답변: **이벤트 기반 아키텍처 (EDA)**는 이벤트를 사용하여 분리된 서비스 간에 트리거하고 통신합니다.

아키텍처:

Loading diagram...

핵심 개념:

1. 이벤트:

  • 발생한 변경 불가능한 사실
  • 관련 데이터 포함
  • 타임스탬프

2. 이벤트 생산자:

  • 이벤트 게시
  • 소비자를 알지 못함

3. 이벤트 소비자:

  • 이벤트 구독
  • 비동기적으로 처리

4. 이벤트 버스/브로커:

  • 이벤트 라우팅
  • 예: Kafka, RabbitMQ, AWS EventBridge

Kafka 구현:

from kafka import KafkaProducer, KafkaConsumer
import json
from datetime import datetime

# 이벤트 생산자
class OrderEventProducer:
    def __init__(self):
        self.producer = KafkaProducer(
            bootstrap_servers=['localhost:9092'],
            value_serializer=lambda v: json.dumps(v).encode('utf-8')
        )
    
    def publish_order_created(self, order_id, customer_id, items, total):
        event = {
            'event_type': 'OrderCreated',
            'event_id': str(uuid.uuid4()),
            'timestamp': datetime.utcnow().isoformat(),
            'data': {
                'order_id': order_id,
                'customer_id': customer_id,
                'items': items,
                'total': total
            }
        }
        self.producer.send('order-events', value=event)
        self.producer.flush()

# 이벤트 소비자
class InventoryEventConsumer:
    def __init__(self):
        self.consumer = KafkaConsumer(
            'order-events',
            bootstrap_servers=['localhost:9092'],
            value_deserializer=lambda m: json.loads(m.decode('utf-8')),
            group_id='inventory-service'
        )
    
    def process_events(self):
        for message in self.consumer:
            event = message.value
            if event['event_type'] == 'OrderCreated':
                self.reserve_inventory(event['data'])
    
    def reserve_inventory(self, order_data):
        # 재고 예약 로직
        print(f"주문 {order_data['order_id']}에 대한 재고 예약")
        # InventoryReserved 이벤트 게시

이벤트 소싱 패턴:

# 현재 상태 대신 이벤트 저장
class EventStore:
    def __init__(self):
        self.events = []
    
    def append(self, event):
        self.events.append(event)
    
    def get_events(self, aggregate_id):
        return [e for e in self.events if e['aggregate_id'] == aggregate_id]

# 이벤트에서 상태 재구성
class OrderAggregate:
    def __init__(self, order_id):
        self.order_id = order_id
        self.status = 'pending'
        self.items = []
        self.total = 0
    
    def apply_event(self, event):
        if event['type'] == 'OrderCreated':
            self.items = event['data']['items']
            self.total = event['data']['total']
        elif event['type'] == 'OrderPaid':
            self.status = 'paid'
        elif event['type'] == 'OrderShipped':
            self.status = 'shipped'
    
    def rebuild_from_events(self, events):
        for event in events:
            self.apply_event(event)

CQRS (Command Query Responsibility Segregation):

Loading diagram...

이점:

  • 느슨한 결합
  • 확장성
  • 유연성
  • 감사 추적 (이벤트 소싱)
  • 실시간 처리

과제:

  • 최종 일관성
  • 이벤트 스키마 진화
  • 디버깅 복잡성
  • 중복 이벤트 처리

사용 사례:

  • 전자 상거래 주문 처리
  • 실시간 분석
  • IoT 데이터 처리
  • 마이크로서비스 통신
  • 감사 및 규정 준수 시스템

희소성: 일반적 난이도: 어려움


재해 복구

7. 재해 복구 전략을 어떻게 설계합니까?

답변: DR은 중단 시 비즈니스 연속성을 보장합니다.

주요 메트릭:

  • RTO (복구 시간 목표): 최대 허용 가능한 가동 중지 시간
  • RPO (복구 시점 목표): 최대 허용 가능한 데이터 손실

DR 전략:

전략RTORPO비용복잡성
백업 및 복원시간시간낮음낮음
Pilot Light중간중간
Warm Standby높음중간
Active-Active거의 0 또는 워크로드에 따라 다름가장 높음높음

구현 예제:

Loading diagram...

자동화:

# 자동화된 장애 조치 스크립트
def initiate_failover():
    # 1. 기본 쓰기 중지
    stop_primary_writes()
    
    # 2. 보조 데이터베이스 승격
    promote_secondary_to_primary()
    
    # 3. DNS 업데이트
    update_route53_failover()
    
    # 4. DR 리전 서비스 시작
    start_dr_services()
    
    # 5. 상태 확인
    verify_dr_health()
    
    # 6. 팀에 알림
    send_alert("DR 리전으로 장애 조치 완료")

테스트:

  • 워크로드 중요도에 따른 정기적인 DR 훈련
  • 자동화된 테스트
  • 런북 문서화
  • 사고 후 검토

희소성: 매우 일반적 난이도: 어려움


보안 및 규정 준수

8. 클라우드 아키텍처에서 제로 트러스트 보안을 어떻게 구현합니까?

답변: 제로 트러스트는 묵시적 신뢰를 가정하지 않고 모든 것을 확인합니다.

원칙:

  1. 명시적으로 확인
  2. 최소 권한 액세스
  3. 침해 가정

구현:

Loading diagram...

구성 요소:

1. ID 및 액세스:

# 예: 조건부 액세스 정책
policies:
  - name: "민감한 앱에 MFA 필요"
    conditions:
      applications: ["finance-app", "hr-system"]
      users: ["all"]
    controls:
      - require_mfa: true
      - require_compliant_device: true
      - allowed_locations: ["corporate-network", "vpn"]

2. 네트워크 분할:

  • 마이크로 세분화
  • 서비스 메시 (Istio, Linkerd)
  • 네트워크 정책

3. 암호화:

  • 저장 데이터
  • 전송 중인 데이터
  • 종단 간 암호화

4. 지속적인 모니터링:

  • 실시간 위협 탐지
  • 행동 분석
  • 자동화된 응답

희소성: 일반적 난이도: 어려움


비용 최적화

9. 여러 클라우드 공급자에서 비용을 어떻게 최적화합니까?

답변: 멀티 클라우드 비용 최적화 전략:

1. 워크로드 배치:

  • 가격 모델 분석
  • 데이터 전송 비용 고려
  • 지역별 가격 차이 활용

2. 예약 용량:

  • AWS Reserved Instances
  • Azure Reserved VM Instances
  • GCP Committed Use Discounts

3. 스팟/선점형 인스턴스:

# 비용 비교: 최신 클라우드 계산기 값을 입력
def compare_options(options):
    return sorted(options, key=lambda option: (
        option["monthly_cost"],
        option["operational_risk"],
        option["commitment_months"]
    ))

4. 모니터링 및 거버넌스:

  • 통합 비용 대시보드
  • 예산 알림
  • 태그 기반 비용 할당
  • 자동화된 리소스 정리

5. 아키텍처 최적화:

  • 가변 워크로드를 위한 서버리스
  • 자동 스케일링 정책
  • 스토리지 계층화
  • 정적 콘텐츠를 위한 CDN

희소성: 매우 일반적 난이도: 중간-어려움


결론

클라우드 아키텍트 면접에서는 암기한 다이어그램보다 실제 의사결정 능력이 더 중요합니다. 다음 내용을 설명할 수 있도록 준비하세요.

  1. 멀티 클라우드: 왜 하나 이상의 공급자가 필요한지, 어떤 복잡성이 생기는지
  2. 마이그레이션: 7R 옵션, 의존성 파악, 단계적 전환, 롤백, 마이그레이션 후 최적화
  3. 마이크로서비스: 경계, 데이터 소유권, API 계약, 복원력, 운영 비용
  4. 서비스 메시: mTLS, 트래픽 정책, 관찰 가능성이 추가 플랫폼 계층을 정당화하는 경우
  5. 디자인 패턴: 서킷 브레이커, 사가, CQRS, 멱등성, 재시도, 타임아웃
  6. 이벤트 기반 시스템: 이벤트 계약, 순서, 중복 처리, 스키마 진화, 최종 일관성
  7. 재해 복구: RTO/RPO, 리전 전략, 런북, 테스트, 복구 증거
  8. 보안: ID 중심 접근, 최소 권한, 암호화, 세분화, 로깅, 침해 가정 사고
  9. 비용 최적화: 라이트사이징, 약정, 태깅, 유휴 리소스 정리, 데이터 전송, FinOps 거버넌스

답변할 때는 비즈니스 제약을 먼저 말하고, 트레이드오프를 명확히 한 뒤, 프로덕션에서 설계를 어떻게 검증할지 설명하세요.

Newsletter subscription

실제로 효과가 있는 주간 커리어 팁

최신 인사이트를 받은 편지함으로 직접 받아보세요

다음 면접은 이력서 하나로 결정됩니다

몇 분 만에 전문적이고 최적화된 이력서를 만드세요. 디자인 기술은 필요 없습니다—입증된 결과만 있으면 됩니다.

내 이력서 만들기

이 게시물 공유

75% ATS 거부율을 극복하세요

4개 중 3개의 이력서는 사람의 눈에 닿지 않습니다. 우리의 키워드 최적화는 통과율을 최대 80%까지 높여 채용 담당자가 실제로 당신의 잠재력을 볼 수 있도록 합니다.