AP 과목A #10 — 클라우드·가상화·분산처리

0. 시험 기준

• 대상: 2026년 응용정보기술자시험(AP) 과목A
• 실러버스: IPA 응용정보기술자시험(레벨3) 실러버스 Ver.7.2
• 개정일: 2026-10-21
• 출처 확인일: 2026-10-21

1. 면책 고지

• 이 글은 비공식 학습 노트입니다. IPA(일본 정보처리추진기구)와 무관하며, IPA의 검토나 보증을 받지 않았습니다.
• 시험 범위·형식·실러버스는 변경될 수 있습니다. 시험 전에 반드시 IPA의 최신 공식 발표를 확인하세요.
• 이번 회차의 5문제는 모두 오리지널 문제입니다. 기출문제를 사용·인용·변형하지 않았습니다.
• 벤더 제품명과 변동 가능한 서비스 사양은 의도적으로 제외했습니다. 모든 수치 예시는 명시한 가정에서만 성립합니다.

2. 학습 목차

1. 시험 기준
2. 면책 고지
3. 공식 실러버스 대응
4. 용어 대조표
5. VM과 컨테이너
6. IaaS/PaaS/SaaS 책임 공유
7. 스케일업과 스케일아웃
8. 로드밸런싱과 분산처리
9. 장애 조건과 함정
10. 풀이 예제 A–D
11. 관련 회차(AP8/AP9)
12. 요약 시트
13. 자주 하는 실수
14. 연습 문제
15. 정답과 해설
16. 자기 점검
17. 1/3/7일 복습 계획
18. 출처

3. 공식 실러버스 대응 (Ver.7.2)

실러버스 위치	항목	이번 회차 해당 부분
대분류2 컴퓨터 시스템 / 중분류4 시스템 구성요소 / 1.(1)②	분산처리 시스템(분산 아키텍처, 기능 배분, 수평 기능 분산, 수평 부하 분산, 수직 기능 분산)	§8, §9, 예제 D
대분류2 / 중분류4 / 1.(2)	시스템 구성(클러스터, 로드 셰어링, 셰어드 에브리싱, 셰어드 낫싱, 밀결합/소결합, 가상화: 호스트형/하이퍼바이저형/컨테이너형, VM, 클라우드 컴퓨팅, SaaS, PaaS, IaaS)	§5, §6, §8
대분류2 / 중분류4 / 2.(1)②	용량 계획(부하, 사이징, 스케일아웃, 스케일업, 프로비저닝)	§7, 예제 A
대분류2 / 중분류5 소프트웨어 / 2.(3)①	가상화·클라우드용 OSS	§5 (개념만, 제품 사양 없음)
대분류3 기술요소 / 정보보안 관리	클라우드 서비스 책임 공유 모델, 계정 관리, 접근 권한 관리	§6
대분류7 / 중분류17 시스템 전략 / (2)①	클라우드 서비스(SaaS, PaaS, IaaS, 온디맨드, 클라우드 네이티브)	§6

4. 용어 대조표

한국어	日本語	English
가상 머신	仮想マシン（VM）	virtual machine (VM)
하이퍼바이저	ハイパーバイザー	hypervisor
게스트 OS	ゲストOS	guest OS
컨테이너	コンテナ	container
호스트 커널	ホストカーネル	host kernel
책임 공유 모델	責任共有モデル	shared responsibility model
스케일업	スケールアップ	scale-up
스케일아웃	スケールアウト	scale-out
로드밸런서	ロードバランサ（負荷分散装置）	load balancer
헬스 체크	ヘルスチェック	health check
단일 장애점	単一障害点（SPOF）	single point of failure (SPOF)
스티키 세션	スティッキーセッション	sticky session
멱등성	冪等性	idempotency
멱등 키	冪等キー	idempotency key
부분 장애	部分障害	partial failure
네트워크 분단	ネットワーク分断	network partition
스트래글러(지연 작업)	ストラグラー（遅延タスク）	straggler
데이터 편중	データの偏り（スキュー）	data skew

5. VM과 컨테이너

• VM: 하이퍼바이저가 가상 하드웨어를 제공하고, 그 위에서 VM마다 자체 게스트 OS(자체 커널 포함)가 동작합니다.
• 컨테이너: 컨테이너들은 호스트 OS 커널을 공유합니다. 커널이 프로세스와 자원(프로세스 보기, 파일 시스템, 네트워크, CPU/메모리 제한)을 격리하고, 컨테이너 이미지는 애플리케이션과 사용자 공간 의존성(라이브러리, 런타임, 설정)을 함께 패키징합니다.
• 컨테이너는 작은 VM이 아닙니다. 자체 게스트 OS 커널이 없으므로 호스트 커널과의 호환성에 의존합니다.

관점	VM	컨테이너
커널	VM마다 게스트 커널 1개	호스트 커널 공유
일반적인 기동	느린 경향(게스트 OS 부팅)	빠른 경향(프로세스 시작)
일반적인 집적도	낮은 경향(VM마다 게스트 OS 오버헤드)	높은 경향
일반적인 격리 경계	강한 경향(커널 분리)	약한 경향(커널 공유)

이는 일반적인 경향이며 절대적인 것이 아닙니다. 실제 결과는 구성과 워크로드에 따라 달라집니다.

6. IaaS/PaaS/SaaS 책임 공유 경계

P = 주로 사업자(제공자), C = 주로 고객(이용자). 온프레미스 열은 참고용입니다.

계층	온프레미스	IaaS	PaaS	SaaS
물리 설비 / 물리 네트워크	C	P	P	P
가상화 계층	C	P	P	P
게스트 OS	C	C	P	P
미들웨어 / 런타임	C	C	P	P
애플리케이션	C	C	C	P
데이터 / 아이덴티티 / 접근 / 설정	C	C	C	C

• IaaS → PaaS → SaaS로 갈수록 사업자가 관리하는 계층이 늘어납니다.
• 어떤 모델에서도 고객은 자신의 데이터, 계정, 접근 권한, 자신이 제어하는 설정에 대한 책임을 집니다(예: SaaS의 공유 설정, IaaS의 가상 네트워크/방화벽 설정).
• 주의: 이는 표준적인 개념 모델입니다. 정확한 경계는 사업자, 제품, 계약에 따라 다릅니다. 반드시 이용 약관과 계약에서 확인하세요.

7. 스케일업과 스케일아웃

관점	스케일업(수직)	스케일아웃(수평)
방법	한 대의 기기에 CPU/메모리 등을 증설	기기(노드) 대수를 늘림
장점	애플리케이션 변경이 대개 적거나 없음, 노드 간 조정 불필요	단계적으로 용량 증가 가능, 1대가 고장 나도 나머지가 동작할 수 있음
한계	하드웨어 상한, 비용이 급격히 증가, 정지가 필요한 경우가 많음	부하 분산·상태 공유·조정이 필요, 오버헤드 증가
상태/조정	상태가 한 곳에 있음	상태를 외부화·공유해야 하며 조정이 필요
병목	단일 기기 자체	공유 DB/스토리지, 로드밸런서, 조정 통신
장애 영향 범위	단일 기기가 SPOF	노드당 영향은 작지만 공유 구성요소는 여전히 SPOF

스케일링은 고가용성(HA)과 같지 않습니다. 용량을 늘린다고 해서 그것만으로 SPOF가 제거되거나 페일오버가 제공되지는 않습니다.

8. 로드밸런싱과 분산처리

• 로드밸런싱: 서로 독립적인 요청을 동등한 노드들에 나누어 보냅니다.
  • 라운드 로빈: 요청을 노드에 차례대로 할당합니다.
  • 최소 연결(least connections): 활성 연결 수가 가장 적은 노드에 할당합니다.
  • 헬스 체크: 주기적으로 노드를 점검하여 장애 노드를 분배 대상에서 제외합니다.
• 분산처리: 하나의 작업을 여러 노드에 나누어 처리합니다.
  • 태스크 분할(기능/단계별 분할)과 데이터 분할(데이터 범위별 분할).
  • 병렬화는 각 부분이 독립적인 범위에서만 시간을 단축합니다.
  • 조정 오버헤드(통신, 동기화, 결과 병합)가 추가됩니다.
  • 부분 장애: 일부 노드는 고장 나고 나머지는 계속 동작하므로, 작업은 실패한 부분을 감지·재시도·재할당해야 합니다.

9. 장애 조건과 함정

조건	문제가 되는 이유
단일 로드밸런서	이중화하지 않으면 LB 자체가 SPOF
공유 DB/스토리지	앱 노드를 스케일아웃해도 병목이자 SPOF가 됨
오래된(stale) 헬스 체크	다음 점검에서 감지될 때까지 장애 노드로 요청이 갈 수 있음
로컬 세션 상태 / 스티키 세션	해당 노드가 고장 나면 세션 소실, 스티키 라우팅은 페일오버가 아님
비멱등 작업의 재시도	작업이 중복될 수 있음(예: 이중 주문)
타임아웃의 모호성	타임아웃은 실패의 증거가 아님, 서버가 이미 처리를 완료했을 수 있음
데이터 편중 / 스트래글러	가장 느린 부분이 전체 완료 시간을 결정
네트워크 분단	노드가 상대의 고장과 도달 불가를 구별할 수 없음, 불일치 위험
메시지 중복 / 순서 뒤바뀜	수신 측에 중복 제거와 순서 제어가 필요
일관성 / 조정 요구사항	조정이 지연을 추가하고 처리량을 제한할 수 있음

분산한다고 해서 신뢰성이나 속도가 자동으로 향상되지는 않습니다. 구성요소가 늘면 장애 지점과 조정 비용도 늘 수 있습니다.

10. 풀이 예제

예제 A: 용량과 N+1

가정: 지속 부하 900 요청/초, 동일한 각 애플리케이션 노드의 목표 지연 시간 기준 검증된 사용 가능 용량 250 요청/초, 완전하고 균등한 분배, LB나 공유 백엔드의 병목 없음, 용량 저하나 오버헤드 없음.

• 평상시 최소: ⌈900 / 250⌉ = ⌈3.6⌉ = 4대
• 임의의 1대 손실을 견디려면: (N − 1) × 250 ≥ 900 → N − 1 ≥ 3.6 → N − 1 ≥ 4 → N ≥ 5
• 확인: 4대에서 1대를 잃으면 3 × 250 = 750 < 900(150 부족). 5대에서 1대를 잃으면 4 × 250 = 1000 ≥ 900.

이 계산은 위 가정에서만 성립합니다. 실제 설계에는 여유(headroom)와 측정(부하 테스트, 모니터링)이 필요하며, LB와 공유 백엔드의 용량도 고려해야 합니다.

예제 B: 세션과 페일오버

상황: 무상태(stateless)처럼 보이는 웹 노드 3대(W1, W2, W3)가 로드밸런서 뒤에 있지만, 세션은 각 노드의 메모리에만 저장됩니다. 스티키 세션이 활성화되어 있습니다.

1. 사용자 U는 스티키 세션으로 W2에 고정되며, U의 세션은 W2의 메모리에만 있습니다.
2. W2가 고장 납니다. LB는 (헬스 체크로 감지한 후) U를 W1 또는 W3로 보냅니다.
3. W1/W3에는 U의 세션이 없습니다 → U는 로그아웃되거나 진행 중이던 상태를 잃습니다.

스티키 세션은 같은 노드로 계속 라우팅할 뿐이며 페일오버를 제공하지 않습니다. 필요한 것: 외부화/복제된 세션 상태(예: 이중화된 세션 저장소) 또는 안전하게 재구성할 수 있는 상태(예: 재로그인, 재조회).

예제 C: 재시도와 멱등성

상황: 클라이언트가 주문(결제와 유사한) 요청을 보내고 응답을 기다리다 타임아웃됩니다. 서버는 이미 주문을 커밋했을 수 있습니다.

• 타임아웃은 실패의 증거가 아닙니다. 요청이 실패했을 수도, 성공했지만 응답이 유실되었을 수도, 아직 처리 중일 수도 있습니다.
• 무조건적인 재시도는 중복 주문을 만들 수 있습니다.
• 대책: 클라이언트는 요청에 고유한 멱등 키를 붙이고 재시도 시 같은 키를 재사용합니다. 서버는 처리한 키를 기록하고, 같은 키가 다시 오면 다시 처리하지 않고 첫 번째 결과를 반환합니다(중복 제거).

예제 D: 병렬화의 상한

가정: 서로 독립적이고 각각 정확히 1초 걸리는 태스크 100개, 워커 5개, 오버헤드 0, 완전한 균형.

• 이상적인 하한: 100 × 1초 ÷ 5 = 20초
• 이 가정에서 실제 시간은 20초 이상입니다. 조정, 편중/스트래글러, 장애는 시간을 늘릴 수만 있기 때문입니다.

실제 환경에서 일반적으로 정확히 5배 빨라진다고 주장하면 안 됩니다. 20초는 위 가정에서의 하한입니다.

11. 관련 회차

• AP8(신뢰성): 가용성, MTBF/MTTR, 직렬/병렬 가용성 공식은 AP8에서 다루며 이번 회차에서는 반복하지 않습니다.
• AP9(OS): 프로세스, 스케줄링, 메모리 관리의 내부 구조는 AP9에서 다루며, 이번 회차에서는 VM/컨테이너 비교를 위해 커널만 언급합니다.

12. 요약 시트

• VM = 가상 하드웨어 + VM마다 게스트 OS. 컨테이너 = 호스트 커널 공유 + 프로세스/자원 격리 + 사용자 공간 패키징.
• IaaS → PaaS → SaaS: 사업자가 관리하는 계층이 늘어남. 데이터·아이덴티티·접근·설정은 항상 고객 책임. 정확한 경계는 사업자·제품·계약에 따라 다름.
• 스케일업 = 더 큰 기기, 스케일아웃 = 더 많은 기기. 스케일링 ≠ HA.
• 로드밸런싱 = 독립 요청을 분배, 분산처리 = 하나의 작업을 분할.
• N+1: (N − 1) × 용량 ≥ 부하. 예제 A → 5대(그 가정에서만).
• 스티키 세션 ≠ 페일오버. 타임아웃 ≠ 실패. 재시도에는 멱등성이 필요.
• 병렬 처리 시간 ≥ 전체 작업량 ÷ 워커 수(오버헤드 0, 완전한 균형이 이상적인 경우).

13. 자주 하는 실수

• “컨테이너는 자체 OS를 가진 경량 VM이다” → 틀림. 호스트 커널을 공유합니다.
• “SaaS면 이용자에게는 보안 책임이 없다” → 틀림. 데이터·계정·접근·설정은 이용자 책임으로 남습니다.
• “스케일아웃하면 고가용성이 된다” → 그것만으로는 아님. LB와 공유 DB가 여전히 SPOF일 수 있습니다.
• “헬스 체크가 있으면 장애가 보이지 않는다” → 감지 지연이 있으며, LB 자체도 이중화가 필요합니다.
• “스티키 세션이 노드 장애로부터 세션을 지켜 준다” → 아님. 라우팅을 고정할 뿐입니다.
• “타임아웃 = 요청 실패이므로 그냥 다시 보내면 된다” → 중복이 발생할 수 있습니다.
• “워커 5개면 정확히 5배 빨라진다” → 속도 향상의 이상적인 상한일 뿐입니다.

14. 연습 문제(오리지널)

문제 1

가상 머신(VM)과 컨테이너에 대한 설명으로 가장 적절한 것은 무엇인가?

• ア: 컨테이너는 자체 게스트 OS 커널을 포함한 경량 VM이므로, 호스트와 무관하게 어떤 OS 커널이든 실행할 수 있다.
• イ: 하이퍼바이저형 가상화에서는 모든 VM이 호스트 OS 커널을 공유하므로 게스트 OS가 필요 없다.
• ウ: 각 VM은 하이퍼바이저가 제공하는 가상 하드웨어 위에서 게스트 OS를 실행하는 반면, 컨테이너는 호스트 OS 커널을 공유하면서 프로세스와 자원을 격리하고, 애플리케이션을 사용자 공간 의존성과 함께 패키징한다.
• エ: 컨테이너는 커널을 공유하기 때문에 항상 VM보다 강한 격리를 제공하며, 따라서 테넌트 분리에는 항상 더 나은 선택이다.

문제 2

IaaS, PaaS, SaaS의 책임 공유 모델에 대한 설명으로 가장 적절한 것은 무엇인가?

• ア: IaaS에서는 이용자가 구축한 가상 머신의 게스트 OS 패치를 일반적으로 사업자가 책임진다.
• イ: PaaS에서는 일반적으로 사업자가 OS와 런타임까지의 계층을 관리하고, 이용자는 애플리케이션, 데이터, 접근 설정을 관리한다. 다만 정확한 경계는 사업자의 약관과 계약에서 확인해야 한다.
• ウ: SaaS에서는 사업자가 모든 것을 관리하므로, 이용자는 데이터, 계정 관리, 접근 설정에 대해 책임이 없다.
• エ: 같은 서비스 모델 안에서는 모든 사업자와 계약에서 책임 경계가 동일하므로 계약을 확인할 필요가 없다.

문제 3

다음 가정에서, 임의의 노드 1대가 고장 나도 900 요청/초를 계속 처리하기 위해 필요한 최소 노드 수는 얼마인가?

가정: 지속 부하 900 요청/초, 동일한 각 노드의 목표 지연 시간 기준 검증된 사용 가능 용량 250 요청/초, 완전하고 균등한 분배, LB나 공유 백엔드의 병목 없음, 용량 저하나 오버헤드 없음.

• ア: 3
• イ: 4
• ウ: 8
• エ: 5

문제 4

로드밸런서 뒤에 웹 노드 3대가 있다. 세션 정보는 각 노드의 메모리에만 저장되며, 스티키 세션이 활성화되어 있다. 가장 적절한 설명은 무엇인가?

• ア: 노드가 고장 나면 그 노드의 메모리에만 있던 세션은 소실된다. 스티키 세션은 사용자를 같은 노드로 라우팅할 뿐 페일오버를 제공하지 않으므로, 세션 상태를 외부화 또는 복제하거나 안전하게 재구성할 수 있게 해야 한다.
• イ: 스티키 세션은 세션 데이터를 다른 노드에 복사하므로, 노드가 고장 나도 세션은 소실되지 않는다.
• ウ: 분배 방식을 라운드 로빈에서 최소 연결로 바꾸면, 노드 고장 시 세션이 자동으로 정상 노드로 이동한다.
• エ: 헬스 체크를 설정하면 로드밸런서는 장애 노드로 요청을 절대 보내지 않으며, 로드밸런서 자체도 단일 장애점이 되지 않는다.

문제 5

클라이언트가 주문 요청을 보내고 응답을 기다리다 타임아웃되었다. 서버는 이미 주문을 커밋했을 수 있다. 가장 적절한 설명은 무엇인가?

• ア: 타임아웃은 서버가 요청을 처리하지 않았다는 증거이므로, 클라이언트는 식별자 없이 같은 요청을 즉시 다시 보내야 한다.
• イ: 재시도 횟수를 무제한으로 늘리면 주문이 정확히 한 번 처리되는 것이 보장된다.
• ウ: 타임아웃은 실패의 증거가 아니므로, 클라이언트는 요청에 멱등 키를 붙이고 서버는 같은 키의 요청을 중복 제거하여 첫 번째 결과를 반환한다. 따라서 재시도해도 중복 주문이 생기지 않는다.
• エ: 주문 처리를 더 많은 서버에 분산하면 메시지 중복과 순서 뒤바뀜이 자동으로 사라지므로 멱등성은 필요 없다.

15. 정답과 해설

문제	정답
문제 1	ウ
문제 2	イ
문제 3	エ
문제 4	ア
문제 5	ウ

문제 1 — 정답: ウ

• ア: 오답. 컨테이너에는 자체 게스트 OS 커널이 없고 호스트 커널을 공유하므로 작은 VM이 아닙니다.
• イ: 오답. 하이퍼바이저형 가상화에서는 각 VM이 가상 하드웨어 위에서 자체 게스트 OS를 실행합니다.
• ウ: 정답. VM(가상 하드웨어 + 게스트 OS)과 컨테이너(호스트 커널 공유 + 격리 + 사용자 공간 패키징)의 차이를 정확히 설명합니다.
• エ: 오답. 커널 공유는 일반적으로 격리 경계를 강하게가 아니라 약하게 만들며, “항상”이라는 절대 표현은 성립하지 않습니다.

문제 2 — 정답: イ

• ア: 오답. IaaS에서 게스트 OS는 일반적으로 이용자 책임입니다.
• イ: 정답. 표준적인 PaaS 경계와 일치하며, 정확한 경계는 사업자와 계약에 따라 다르다는 단서도 포함합니다.
• ウ: 오답. SaaS에서도 데이터, 계정, 접근 권한, 설정은 이용자 책임으로 남습니다.
• エ: 오답. 정확한 경계는 사업자, 제품, 계약에 따라 다릅니다.

문제 3 — 정답: エ (5)

• ア: 오답. 3 × 250 = 750 < 900이므로 3대로는 평상시 부하도 처리할 수 없습니다.
• イ: 오답. 4는 평상시 최소(⌈900/250⌉ = 4)지만, 1대를 잃으면 3 × 250 = 750 < 900입니다.
• ウ: 오답. 8(4의 두 배)은 요건을 만족하지만 최소가 아닙니다.
• エ: 정답. (N − 1) × 250 ≥ 900 → N ≥ 5. 1대를 잃어도 4 × 250 = 1000 ≥ 900. 명시한 가정에서만 유효합니다.

문제 4 — 정답: ア

• ア: 정답. 로컬 메모리 세션은 노드 고장 시 소실되며, 스티키 세션은 페일오버를 제공하지 않습니다.
• イ: 오답. 스티키 세션은 라우팅을 고정할 뿐 세션 데이터를 복사하지 않습니다.
• ウ: 오답. 분배 알고리즘은 새 요청을 어디로 보낼지 정할 뿐 세션 상태를 옮기지 않습니다.
• エ: 오답. 헬스 체크에는 감지 지연(오래된 상태)이 있으며, 로드밸런서는 이중화하지 않으면 SPOF입니다.

문제 5 — 정답: ウ

• ア: 오답. 타임아웃은 실패의 증거가 아니며, 식별자 없이 다시 보내면 주문이 중복될 수 있습니다.
• イ: 오답. 무제한 재시도는 중복과 부하의 위험을 키울 뿐, 정확히 한 번 처리를 보장하지 않습니다.
• ウ: 정답. 멱등 키와 서버 측 중복 제거로 재시도를 안전하게 만듭니다.
• エ: 오답. 분산은 메시지 중복/순서 뒤바뀜을 없애지 않으며, 오히려 늘릴 수 있습니다.

16. 자기 점검

• 컨테이너가 작은 VM이 아닌 이유를 한 문장으로 설명할 수 있다.
• IaaS/PaaS/SaaS 책임 매트릭스를 채우고 계약 관련 단서를 말할 수 있다.
• 스케일업과 스케일아웃의 병목·장애 영향 범위 차이, 그리고 스케일링 ≠ HA인 이유를 말할 수 있다.
• 로드밸런싱과 분산처리를 구별하고 부분 장애 문제를 세 가지 들 수 있다.
• 예제 A에서 N ≥ 5를 도출하고 그 가정을 말할 수 있다.
• 스티키 세션이 페일오버가 아닌 이유를 설명할 수 있다.
• 타임아웃 후 무조건 재시도하면 주문이 중복될 수 있는 이유와, 멱등 키가 이를 막는 방법을 설명할 수 있다.
• 예제 D의 20초가 하한인 이유를 설명할 수 있다.

17. 1/3/7일 복습 계획

시점	할 일
1일차	요약 시트를 다시 읽고, 책임 매트릭스와 스케일업/아웃 표를 기억으로 다시 그리고, 문제 1–5를 다시 푼다.
3일차	예제 A와 D를 보지 않고 다시 도출하고, 예제 B와 C를 소리 내어 설명하고, 자주 하는 실수를 복습한다.
7일차	문제 1–5를 다시 풀고 각 오답 선택지가 틀린 이유를 설명하고, 자기 점검을 완료하고, AP8/AP9 관련 회차를 간단히 다시 본다.

18. 출처

• IPA, 응용정보기술자시험(레벨3) 실러버스 Ver.7.2 (공식 PDF, 인쇄 페이지 20–21, 32, 56, 107): https://www.ipa.go.jp/shiken/syllabus/omgdg50000005kq5-att/syllabus_ap_ver7_2.pdf (확인일 2026-10-21)