Cloud Digital Leader의 2026년 8월 개정 출제 범위에서 도메인 6 "Google Cloud 운영으로 확장하기"는 비중이 약 10%로 줄었지만, 새로 들어온 세부 항목이 많습니다. 시스템의 성능과 신뢰성을 지연 시간·트래픽·포화도·오류로 측정하는 방법, 중복·복제·확장 가능한 인프라·백업으로 복원력을 설계하는 방법, Cloud Monitoring부터 Cloud Profiler까지의 Google Cloud Observability, 그리고 비용 측면에서 할당량 정책, 예산 임계값 규칙, Cloud Billing 보고서, Dynamic Workload Scheduler와 사람·프로세스·기술의 역할을 묻습니다.
이 글은 운영의 기본 용어에서 시작해 4가지 골든 시그널, SLI·SLO·SLA와 오류 예산, 복원력 설계, Observability 도구, 비용을 통제하는 장치와 FinOps 순서로 정리합니다. SLI·SLO·SLA의 기본 정의, DevOps, 예산과 약정 사용 할인은 비용 관리와 운영 우수성에서 먼저 다뤘습니다.
---
운영의 기본 용어: 운영 우수성, 신뢰성, 고가용성
출제 범위는 클라우드 운영의 기본 용어를 알아보라고 요구합니다. 셋은 비슷해 보이지만 초점이 다릅니다.
| 용어 | 뜻 | 예 | |------|------|------| | 운영 우수성 | 시스템을 효율적으로 운영하고 계속 개선하는 능력 | 배포 자동화, 모니터링, 장애 후 개선 | | 신뢰성 | 시스템이 기대한 대로 꾸준히 동작하는 정도 | 사용자가 요청할 때마다 올바른 결과를 받음 | | 고가용성 | 장애가 나도 서비스를 계속 제공하는 능력, 보통 가동 시간 비율로 표시 | 한 영역이 멈춰도 다른 영역에서 서비스 지속 |
가용성 숫자에 9가 하나 늘 때마다 허용되는 중단 시간은 10분의 1로 줄어듭니다.
| 가용성 | 한 달 허용 중단 시간 (약) | |------|------| | 99% | 7시간 18분 | | 99.9% | 43분 50초 | | 99.99% | 4분 23초 | | 99.999% | 26초 |
시험 팁: 가용성 목표가 높을수록 비용과 복잡성도 커집니다. 모든 서비스에 99.999%가 필요한 것은 아니며, 비즈니스에 맞는 목표를 정하는 것이 운영 우수성입니다.
---
4가지 골든 시그널: 무엇을 측정할까
자동차 계기판에 수백 개의 표시등을 달 수는 없습니다. 운전자는 속도, 연료, 엔진 온도 같은 핵심만 봅니다. Google의 SRE는 사용자에게 보이는 서비스를 측정할 때 지표를 네 가지만 고를 수 있다면 지연 시간, 트래픽, 오류, 포화도를 보라고 말합니다. 출제 범위도 시스템의 성능과 신뢰성을 측정하는 방법으로 이 네 가지를 듭니다.
!4가지 골든 시그널인 지연 시간, 트래픽, 오류, 포화도를 SLI로 측정해 SLO와 비교하는 흐름
| 시그널 | 무엇을 보나 | 예 | |------|------|------| | 지연 시간(Latency) | 요청을 처리하는 데 걸리는 시간 | 결제 요청의 95%가 300밀리초 안에 응답 | | 트래픽(Traffic) | 시스템에 들어오는 수요의 양 | 초당 요청 수, 동시 접속자 수 | | 오류(Errors) | 실패한 요청의 비율 | 서버 오류(5xx) 응답 비율, 잘못된 결과 | | 포화도(Saturation) | 시스템이 얼마나 꽉 찼는지 | CPU, 메모리, 디스크, 대기열 사용률 |
포화도는 문제가 생기기 전에 미리 알려 준다는 점에서 특별합니다. 다른 세 가지는 이미 사용자가 영향을 받은 뒤에 나빠지지만, 포화도가 한계에 가까워지면 장애가 나기 전에 용량을 늘릴 수 있습니다.
시험 팁: "사용자가 체감하는 응답 속도"는 지연 시간, "서비스가 받는 요청의 양"은 트래픽, "자원이 한계에 가까운지"는 포화도입니다.
---
SLI, SLO, SLA와 오류 예산
골든 시그널을 숫자로 관리하는 도구가 SLI, SLO, SLA입니다. 측정하고, 목표를 세우고, 고객과 약속하는 순서입니다.
| 구분 | 역할 | 예 | |------|------|------| | SLI(서비스 수준 지표) | 실제로 측정한 값 | 이번 달 성공한 요청 비율 99.95% | | SLO(서비스 수준 목표) | 팀이 정한 내부 목표 | 한 달 동안 성공 요청 비율 99.9% 이상 | | SLA(서비스 수준 계약) | 고객과 맺은 계약상 약속, 어기면 보상 | 99.5% 미만이면 요금 일부를 크레딧으로 돌려줌 |
SLO는 SLA보다 엄격하게 잡습니다. 내부 목표를 조금 어겨도 고객과의 약속은 지킬 수 있도록 여유를 두는 것입니다.
오류 예산: 실패해도 되는 양
오류 예산은 100%에서 SLO를 뺀 값입니다. SLO가 99.9%라면 오류 예산은 0.1%로, 한 달 약 43분의 중단이나 요청 100만 건 중 1,000건의 실패가 허용된다는 뜻입니다.
예산이 남아 있으면: 새 기능 배포와 실험처럼 위험이 따르는 변경을 진행 예산을 다 쓰면: 새 배포를 멈추고 안정성을 높이는 데 집중
이렇게 하면 "빨리 출시하자"는 개발팀과 "안정성이 먼저"라는 운영팀이 감이 아니라 데이터로 합의할 수 있습니다. SRE는 여기에 장애를 사람 탓으로 돌리지 않고 원인과 개선책에 집중하는 비난 없는 사후 분석, 반복적인 수작업을 자동화로 줄이는 원칙을 함께 씁니다.
시험 팁: "오류 예산이 바닥났다"면 정답은 새 기능 출시를 멈추고 신뢰성 개선에 집중하는 것입니다. "SLO가 99.9%일 때 오류 예산은?"이라면 0.1%입니다.
---
복원력 있는 인프라와 프로세스 설계
비행기는 엔진이 하나 멈춰도 날 수 있게 엔진을 둘 이상 답니다. 출제 범위는 복원력을 설계하는 방법으로 중복, 복제, 확장 가능한 인프라, 백업을 듭니다.
| 기법 | 의미 | Google Cloud 예 | |------|------|------| | 중복(Redundancy) | 같은 역할의 구성 요소를 여럿 두어 하나가 멈춰도 계속 동작 | 여러 영역에 VM을 나눠 둔 관리형 인스턴스 그룹, 부하 분산 | | 복제(Replication) | 데이터 사본을 다른 위치에 계속 맞춰 둠 | Cloud SQL 고가용성 구성(다른 영역에 대기 인스턴스), Spanner 멀티 리전, 멀티 리전 Cloud Storage | | 확장 가능한 인프라 | 부하에 따라 자원을 자동으로 늘리고 줄임 | 자동 확장, Cloud Run, Cloud Load Balancing | | 백업 | 특정 시점의 사본을 따로 보관해 실수나 랜섬웨어 이후 복구 | Cloud SQL 자동 백업, 디스크 스냅샷, Backup and DR Service |
복제와 백업은 다릅니다. 복제는 실시간으로 사본을 맞추기 때문에 누군가 실수로 데이터를 지우면 그 삭제도 함께 복제됩니다. 백업은 과거 시점의 사본이라 이런 실수에서 되돌릴 수 있습니다.
재해 복구를 계획할 때는 두 가지 목표를 먼저 정합니다.
| 목표 | 질문 | 예 | |------|------|------| | RTO(복구 목표 시간) | 장애 후 얼마 안에 서비스를 다시 열어야 하나? | 4시간 안에 복구 | | RPO(복구 목표 시점) | 데이터를 최대 얼마만큼 잃어도 되나? | 최근 15분 이내 데이터까지 복구 |
시험 팁: "실수로 삭제한 데이터를 어제 상태로 되돌린다"는 백업입니다. "한 영역이 멈춰도 데이터베이스가 계속 동작"은 다른 영역에 대기 인스턴스를 두는 복제(고가용성 구성)입니다.
---
Google Cloud Observability: 시스템을 들여다보는 다섯 도구
출제 범위는 Google Cloud Observability(예전 이름 Stackdriver, operations suite)로 운영을 현대화하는 방법을 묻고 다섯 도구를 이름으로 듭니다.
| 도구 | 하는 일 | 답하는 질문 | |------|------|------| | Cloud Monitoring | 지표 수집, 대시보드, 알림, 가동 시간 확인 | 지금 시스템이 정상인가? | | Cloud Logging | 로그를 모아 저장하고 검색하고 분석 | 무슨 일이 있었나? | | Cloud Trace | 요청 하나가 여러 서비스를 거치는 동안 구간별 지연을 추적 | 어디서 느려졌나? | | Cloud Profiler | 운영 중인 애플리케이션에서 CPU와 메모리를 많이 쓰는 코드를 낮은 부하로 계속 분석 | 어떤 코드가 자원을 많이 쓰나? | | Error Reporting | 애플리케이션 오류를 모아 같은 종류끼리 묶고 새 오류를 알림 | 어떤 오류가 새로 생겼나? |
예전 자료에 나오는 Cloud Debugger는 2023년 5월 31일에 서비스가 종료되어 지금 목록에는 없습니다.
시험 팁: "마이크로서비스 중 어느 구간이 응답을 늦게 만드는지 찾는다"는 Cloud Trace, "어떤 함수가 CPU를 가장 많이 쓰는지 찾아 비용을 줄인다"는 Cloud Profiler입니다.
---
운영의 다른 축: 비용을 통제하는 장치
운영을 확장한다는 것은 신뢰성뿐 아니라 비용도 통제한다는 뜻입니다. 출제 범위는 클라우드 사용량을 통제하는 장치로 할당량 정책, 예산 임계값 규칙, Cloud Billing 보고서, Dynamic Workload Scheduler, Spot VM을 듭니다.
| 장치 | 하는 일 | 사용을 실제로 막나? | |------|------|------| | 예산과 임계값 규칙 | 실제 비용이나 예상 비용이 정한 비율을 넘으면 알림, Pub/Sub로 자동 조치 연결 가능 | 알림 전용 예산은 막지 않음 (일부 서비스는 프로젝트 지출 한도 예산 지원) | | 할당량 | 프로젝트가 쓸 수 있는 리소스와 API 호출의 양을 제한 | 예, 넘으면 요청이 실패 | | Cloud Billing 보고서 | 프로젝트, 서비스, 라벨별 비용 추이를 시각화 | 아니요 (가시성 제공) | | Spot VM | 남는 용량을 크게 할인, 언제든 회수될 수 있음 | 해당 없음 (비용 절감) | | Dynamic Workload Scheduler | GPU와 TPU를 용량이 생길 때 시작하거나 기간을 정해 예약 | 해당 없음 (비용 절감) |
사람, 프로세스, 기술: 클라우드 비용은 누가 관리하나
온프레미스에서는 장비를 살 때 재무팀이 한 번 승인하면 끝이었지만, 클라우드에서는 엔지니어가 버튼 하나로 비용을 만듭니다. 그래서 Google은 재무 거버넌스를 사람, 프로세스, 기술 세 축으로 설명합니다.
사람: 재무팀 혼자가 아니라 재무, 엔지니어링, 비즈니스가 함께 비용을 책임지고, 이를 조율하는 중앙 팀(FinOps 팀)을 둠 프로세스: 예산 수립, 정기적인 비용 검토, 부서별 비용 배분, 사용량 예측 기술: Cloud Billing 보고서, 예산 알림, 라벨, 할당량, 비용 최적화 권장 사항
시험 팁: "실수로 너무 많은 VM이 만들어져 비용이 폭증하는 것을 확실히 막는다"는 할당량입니다. "예산의 80%에 도달하면 알린다"는 예산 임계값 규칙입니다. "클라우드 비용을 누가 책임지나"는 여러 팀의 공동 책임이 정답입니다.
---
시험 핵심 정리
시험장 가기 전 마지막으로 확인할 핵심 포인트입니다.
| 구분 | 핵심 암기 사항 | |------|------| | 운영 우수성 · 신뢰성 · 고가용성 | 효율적 운영과 개선 · 기대대로 꾸준히 동작 · 장애에도 계속 서비스 | | 99.9% vs 99.99% | 한 달 약 43분 vs 약 4분 중단 허용 | | 4가지 골든 시그널 | 지연 시간 · 트래픽 · 오류 · 포화도 | | 포화도 | 자원이 얼마나 꽉 찼는지, 장애 전에 경고 | | SLI · SLO · SLA | 측정값 · 내부 목표 · 고객과의 약속(SLO가 더 엄격) | | 오류 예산 | 100% - SLO, 다 쓰면 배포를 멈추고 안정성 개선 | | 중복 · 복제 | 구성 요소를 여럿 · 데이터 사본을 다른 위치에 | | 복제 vs 백업 | 실시간 사본(삭제도 복제) vs 과거 시점 사본(실수에서 복구) | | RTO · RPO | 얼마 안에 복구 · 데이터를 얼마나 잃어도 되나 | | Cloud Trace · Cloud Profiler | 어디서 느려졌나 · 어떤 코드가 자원을 많이 쓰나 | | Error Reporting | 오류를 모아 묶고 새 오류를 알림 | | 할당량 vs 예산 | 사용을 막음 vs 알림 (알림 전용 예산은 막지 않음) | | 재무 거버넌스 | 사람 · 프로세스 · 기술, 여러 팀의 공동 책임 |
---