6. 시험 빈출 핵심 토픽

핵심 인사이트 (3줄 요약)

1. 본질: 클라우드 기술사는 IaaS/PaaS/SaaS의 책임 공유 모델부터 컨테이너 오케스트레이션, MSA 패턴, 서버리스, DevOps, 데이터 엔지니어링에 이르기까지 전체 스택을 관통하는 융합적 사고력을 검증한다.
2. 가치: 단순 개념 암기가 아니라, 아키텍처 결정의 trade-off를 정량적 지표(TPS, Latency, RTO, MTBF)로 논증할 수 있는지를 평가하여, 실무에서의 정확한 의사결정 능력을 시험한다.
3. 융합: 클라우드-native 설계는 네트워크, 스토리지, 보안, 비용(FinOps)과 분리 불가능하며, 기술사 답안에서는 이러한 횡단적 연결고리를 명시적으로 서술해야 높은 점수를 받을 수 있다.

Ⅰ. 개요 및 필요성 (Context & Necessity)

시험에서 자주 출제되는 이유

정보관리기술사와 컴퓨터응용시스템기술사에서 클라우드 아키텍처가 핵심 주제로 자리 잡은 배경에는 세 가지 구조적 요인이 존재한다. 첫째, 클라우드가 더 이상 선택이 아닌 필수 인프라로 전환되면서 기술사도 단순 CLI 조작이 아닌 시스템 설계层次的 사고를 요구한다. 둘째, 클라우드-native 환경에서는 온프레미스 시절의 수직적 설계(단일 서버, 단일 DB)가 통하지 않으며, 복수 기술 영역(가상화, 컨테이너, 네트워크, 스토리지, 보안)이 하나로 융합된 통합적 사고가 필요하다. 셋째, 시험 평가 기준이 단순 정의 나열에서 아키텍처 비교, 설계 의사결정, 장애 대응 전략으로 이동하면서候补자는 실제 서비스 경험을 논술에 녹여내야 한다.

기술사 시험의特殊的 평가 기준

시험관眼中的 완벽한 답안이란 관련 개념을 열거하는 것이 아니라, 다음과 같은 연결 고리를 명시적으로 보여주는 것이다. 클라우드 서비스 모델(IaaS/PaaS/SaaS)을 선택할 때 관리 책임의 경계(Shared Responsibility Model)를 먼저 설명하고, 그 경계에 따라 팀의 운영 부담과 비용 구조가 어떻게 달라지는지를 논증해야 한다. 또한 동일하게 "Auto Scaling"이라고 해도, K8s의 HPA와 클라우드 네이티브의 CA는 다른 계층에서 동작하며 어떤 임계치 조합이 효과적인지를 구체적으로 서술해야 한다.

📢 섹션 비유

마치 요리사 시험에서 отдель 요리법 암기보다, 손님 취향에 맞는 조합과 시즌 식재료 특성을 고려한 전체 메뉴 설계 능력을 검증하는 것과 같다.

Ⅱ. 아키텍처 및 핵심 원리 (Deep Dive)

시험 빈출 핵심 개념 체계도

이 도식은 클라우드 기술사 시험에서 80% 이상 출제되는 핵심 개념들의 상호 관계를 보여준다. 중앙의 클라우드 서비스 모델에서 출발하여, 좌측은 인프라抽象化 단계(IaaS → PaaS → SaaS), 우측은 설계 패턴(MSA, Serverless, Event-Driven), 하단은 운영 도구(CI/CD, GitOps, SRE)를 각각 배치하였다.

        [Cloud Service Models]
              IaaS | PaaS | SaaS
                 Shared Responsibility
    ┌──────────────┼──────────────────┐
    │              │                  │
 [Infra Abstraction]        [Design Patterns]
  ┌─────┴─────┐          ┌────┴────┐
  │Virtualiza-│          │MSA|Pat- │
  │tion       │          │terns   │
  ├───────────┤          ├────────┤
  │Containers │          │Server- │
  │K8s        │          │less    │
  ├───────────┤          ├────────┤
  │Microserv- │          │Event   │
  │ices       │          │Driven  │
  └─────┬─────┘          └────┬────┘
        │                    │
    [Orchestration]       [Data Eng]
     ┌───┴───┐           ┌───┴────┐
     │K8s    │           │ETL|ELT│
     │GitOps │           │DataLake│
     │SRE    │           │Stream  │
     └───────┘           └────────┘

이 체계도의 핵심은 각 영역이 독립적으로 존재하지 않고 좌→우, 상→하로 깊이 연결되어 있다는 점이다. 예를 들어 "Auto Scaling"이라는 키워드 하나만拎더라도, IaaS 층에서는 VM 实例 수 조정이되고, PaaS 층에서는 Container Replica 数 조정으로, K8s 층에서는 HPA/CABPK 形態로 각기 다른 메커니즘으로 동작한다. 시험에서 이러한 대응 관계를 명확히 서술해야 가점 을 받을 수 있다.

빈출 기술 간 동작 메커니즘 비교도

이 그림은 흔히 혼동되는 기술 조합들을 각기 다른 동작 계층과 트리거 조건으로 구분하여 나타낸다. 자주 출제되는 서로 게이트웨이 패턴과 서비스 메시의 차이, Saga 패턴과 2PC의 동작 시점 차이, 그리고 스트림 처리와 배치 처리의 시간 창概念을 명확히 구분해야 한다.

┌─────────────────────────────────────────────────────────────┐
│              빈출 기술 동작 비교 다이어그램                      │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  [API Gateway]          [Service Mesh]                     │
│   - L7 Routing          - Sidecar Proxy                     │
│   - Auth/Throttle       - mTLS (상호 인증)                  │
│   - Rate Limit          - Traffic Management               │
│   위치: Client ↔ MS    위치: 각 Pod 옆                     │
│                                                             │
│  ┌─────────────────┐      ┌─────────────────────────────┐ │
│  │   Saga Pattern   │      │   2PC (Two-Phase Commit)   │ │
│  │ Local Tx +       │      │ Coordinator가 Lock 보유     │ │
│  │ Compensation      │      │ Blinding Blocking 유발    │ │
│  │ 비동기 最终적     │      │ 동기적 即時 一致성           │ │
│  │ Eventual Consist- │      │ Strong Consistency          │ │
│  │ ency             │      │                             │ │
│  └─────────────────┘      └─────────────────────────────┘ │
│                                                             │
│  [Stream Processing]      [Batch Processing]               │
│  실시간 창(Window)        주기적 일괄 처리                   │
│  Kafka/Flink/Spark       Spark/Hadoop MR                  │
│  └ms~sec 지연            └min~hour 지연                    │
│                                                             │
└─────────────────────────────────────────────────────────────┘

이 비교도의 핵심 관찰 포인트는 다음과 같다. API Gateway와 Service Mesh는 둘 다 "프록시"라는 이름을 사용하지만, 위치와 책임이 완전히 다르다. API Gateway는 Client-Ingressの間に位置하여 공통 인증,流量整形,请求聚合을 담당하고, Service Mesh는 각 서비스 Pod마다 Sidecar 형태로 배치되어 서비스 간 통신 보안(mTLS), 분산 추적, 회복탄력성(Circuit Breaker)을 담당한다. 따라서 시험에서 "Service Mesh를 도입하면 API Gateway가 불필요하다"는 답안은 部分 correto이지만 完全한 정답이 아니다. 둘은 보완적 관계이며, API Gateway가 L7 라우팅을, Service Mesh가 L4~L7 서비스 간 통신을 담당하는 것이 바람직한 분리이다.

빈출 장애 시나리오 전파 흐름

이 그림은 MSA 환경에서 하나의 DB 장애가 전체 시스템으로 전파되는 과정을 단계별로 보여준다. 기술사 시험에서는 이러한 장애 전파 경로를 분석하고, 각 단계에서 어떤 아키텍처 패턴(Circuit Breaker, Bulkhead, Fallback)을 적용해야 하는지를 서술해야 한다.

[Client A] --요청--> [API Gateway]
                           │
                    [Service A] ---조회--> [DB Master]
                           │                    │
                    [Circuit Open]           [Deadlock]
                           │                    │
                    [Fallback Cache] ← 회복 시도  │
                           │                    │
              [连锁적 전파 차단] ----X-----> [Service B], [Service C]

이 장애 전파도의 핵심은 ①단계에서 DB Master의 Deadlock이 서비스 A의 응답 지연으로, ②단계에서 Circuit Breaker가 Open되면서 Service B와 C로의连锁적 전파를 차단하는 메커니즘이다. 실무에서는 이 Circuit Breaker의 임계치 설정이 중요하며, 너무 짧으면 정상 트래픽도 차단하고 너무 길면 장애가 확산될 위험이 있다.

📢 섹션 비유

마치 도시의 신호등 시스템처럼, 어떤 교차로에서 사고가 발생해도 옆 블록으로 사고가 퍼지지 않도록绕道 표시를自動表示하고, 사고 구역에서는 우회 경로를 실시간 안내하는 것과 같다.

Ⅲ. 융합 비교 및 다각도 분석 (Comparison & Synergy)

시험 대비 핵심 비교표: 클라우드 서비스 모델의 책임 경계

시험 빈출 기술 조합 비교표

📢 섹션 비유

마치 외식점의厨房에서 각 조리사에 전문 분업(肉类担当, 면류担当, 소스担当)을 두되,itchen Manager(마스터 쉐프)가 전체 메뉴 완성도를 관리하는 것과 같다. 전문分化하되 전체 조화不全이 없어야 한다.

Ⅳ. 실무 적용 및 기술사적 판단 (Strategy & Decision)

시나리오 1: 대규모 트래픽 폭주 — 설계 의사결정 과정

문제 상황: 온라인 시험 플랫폼에서 수험자 10만 명이 동시에 접속하는 상황에서, 평소 트래픽의 500배가 집중되어 서버가 응답 불가 상태에 빠졌다.

기술사적 판단 과정:

1. 첫 번째 분석: 전통적인 Scale-up(서버 사양 증가) 방식은 물리적 제한이 있어 즉각 대응이 불가능하다. 따라서 Scale-out 방식과 이벤트驱动 구조로의 전환이 필요하다.

2. 두 번째 분석: 단일 데이터베이스가 단일 장애점이므로, 읽기 전용 복제본(Read Replica)과 쓰기용 DB를 분리하는 CQRS 패턴을 적용해야 한다.

3. 세 번째 분석: 외부 의존 서비스(결제, 알림)의 장애가 자가 시스템에 영향을 주지 않도록, Circuit Breaker 패턴을 적용하여 격벽을 설정한다.

4. 네 번째 분석: 이러한 분산 구조를 Kubernetes에 배포할 경우, HPA와 Cluster Autoscaler의 연동으로 트래픽 변화에 실시간 대응할 수 있다.

시나리오 2: 레거시 모놀리식 → MSA 점진적 전환

문제 상황: 15년 된 대규모 모놀리식 ERP 시스템을 클라우드-native MSA로 재설계해야 하지만, 동시에 서비스를 중단할 수 없는 제약이 있다.

기술사적 판단 — 스트랭글러 피그 패턴 적용:

이 설계의 핵심은 ① 기존 시스템 앞단에 API Gateway를 배치하여 모든 트래픽을 일단 수렴시키고, ② 신규 도메인 기능을 MSA로 먼저 개발하여Gateway에 등록하며, ③ 레거시 기능의 트래픽 비율이 일정 임계치(통상 5% 이하)가 될 때까지 점진적 라우팅 전환을 수행한다.

안티패턴: 기술사 답안에서 자주 발견되는致命的 실수

📢 섹션 비유

마치 항구에서 화물 선박의 화물을 분할하여 여러 척의 선박에 나눠 싣는 것처럼, 하나의 큰 시스템을 작은 독립 서비스로 분리하되, 각 선박의 적하량(부하)과 항로(네트워크 경로)를 전체 관제실에서 실시간 모니터링하는 것과 같다.

Ⅴ. 기대효과 및 결론 (Future & Standard)

기술사 합격자를 위한 정량적 효과 정리

시험 출제 경향과 향후 전망

최근 정보관리기술사와 컴퓨터응용시스템기술사에서 나타나는 뚜렷한 경향은 다음과 같다. 첫째, 단일 기술 개념보다 두 가지 이상 기술의 조합과 그 trade-off를 묻는 문제가 증가하고 있다. 예를 들어 "Kubernetes와 Serverless의 조합이 적합한 상황과 그렇지 않은 상황을 구체적 수치로 논하시오"과 같은 문형이다. 둘째, 실제 장애 시나리오와 복구 절차를 묻는 문제가 증가하고 있어, 후보자는 단순 이론 암기를 넘어 실제 운영 경험을 논술에 녹여낼 능력이 요구된다. 셋째, 클라우드 비용(FinOps)과 아키텍처 결정의 관계를 묻는 문형이 새롭게 출제되고 있다.

참고 표준 및 공식 문서

📢 섹션 비유

마치 요리사 자격증 시험이 요리의 全과정을 관통하는食品安全衛生부터 plated dish의 完成도까지 일관된 기준을 요구하는 것처럼, 클라우드 기술사 시험도 인프라抽象化부터 운영 자동화, 비용 최적화에 이르기까지 全스택 관통적 사고력을 검증한다.

📌 관련 개념 맵 (Knowledge Graph)

• (IaaS | PaaS | SaaS): 클라우드 서비스 모델의 진화적 계층 구조로서, 관리 책임의 경계가 이동한다
• (Kubernetes | HPA | CA): 컨테이너 오케스트레이션의 3단계 확장 메커니즘으로, Pod 수평 확장-리소스 조정-노드 수 확장 각 단계가 다르다
• (MSA | Saga | CQRS): 분산 시스템의 상태 관리 패턴으로, 2PC의 대안으로서 결과적 일관성을 선택한다
• (DevOps | GitOps | SRE): 운영 자동화의 진화적 계층으로, 코드로서 인프라를 관리하고 서비스 신뢰성을 측정한다
• (Data Lake | Data Warehouse | Data Lakehouse): 데이터 저장 패러다임의 진화로서, Schema-on-Read에서 ACID 트랜잭션 지원으로 확대되었다

👶 어린이를 위한 3줄 비유 설명

클라우드는 하늘에 있는 아주 큰 컴퓨터 집합이에요. 우리가 집에서 컴퓨터를 다 사두면浪费이지만, 필요한 만큼만 빌려 쓰면 엄마 아빠가 전기요금 내듯이 사용한 만큼만 돈을 내면 돼요. 만약 사용자가 너무 많아지면, 구름이 자동으로 컴퓨터를 더 많이 만들어서 모두가 빠르게 사용할 수 있게 해준답니다!