관리형 클라우드 인프라: 포함되는 내용, 포함되지 않는 내용, 그리고 왜 중요한가
I’m happy to translate the article for you, but I’ll need the full text you’d like translated. Could you please paste the content (excluding the source line you already provided) here? Once I have the article, I’ll keep the source line unchanged and translate the rest into Korean while preserving the original formatting and markdown.
“Managed”는 범위 경계이다
경계가 서면으로 명시되지 않으면 관리형 서비스를 제공받는 것이 아닙니다. 클라우드 제공업체는 이를 공유 책임이라고 표현합니다: 제공업체는 기본 클라우드 플랫폼을 보호하고; 사용자는 그 위에 배포하고 구성하는 것을 보호합니다.
관리형 클라우드 인프라에 포함되는 내용
이것은 수동으로 수행하던 작업을 대신해 비용을 지불하는 항목들입니다.
1. 공급자 소유 구성 요소의 가동 시간
공급자는 자신이 운영하는 계층(컨트롤 플레인, 스토리지 서비스, DR 서비스)에 대한 SLA를 공개해야 합니다. SLA에 명시되지 않은 한 “전체 스택” 가동 시간을 가정하지 마세요.
2. 관리형 계층에 대한 패치
공급자는 일반적으로 자신이 소유한 부분(플랫폼, 관리형 컨트롤 플레인, 관리형 서비스 런타임)에 대해 패치를 수행합니다. 계약서에 별도 명시되지 않는 한 OS, 노드 풀, 애플리케이션 의존성은 여전히 고객의 책임입니다.
3. 그들의 계층에 대한 모니터링 + 알림
실제 관리형 서비스는 다음을 제공합니다:
- 플랫폼 메트릭 및 상태 체크
- 알림 라우팅 + 에스컬레이션
- 그들이 담당하고 담당하지 않는 범위를 명시한 지원 경계
4. 백업/DR 기본 기능
보통 복제 및 장애 조치 메커니즘을 제공받습니다. 그러나 애플리케이션 일관성, 복구 검증, 복구 연습은 여전히 직접 관리해야 합니다.
5. 그들의 계층에 대한 변경 관리
문서화된 유지보수 창, 버전 정책, 공급자 소유 구성 요소에 대한 업그레이드 경로를 기대하세요. 관리형 쿠버네티스 컨트롤 플레인이 일반적인 예시입니다.
포함되지 않은 항목
이곳에서 대부분의 “관리형” 기대가 깨집니다.
- Identity and access configuration – 클라우드 모델 전반에 걸쳐 신원 및 접근 정책을 직접 관리합니다. IAM이 잘못되면 “관리형” 서비스가 여러분을 구해주지 못합니다.
- Your data and how it’s protected – 제공업체는 암호화 기능을 제공합니다. 여러분은 데이터 분류, 키 보관, 접근 패턴, 보존 기간을 선택합니다.
- Your network intent – 제공업체가 물리 네트워크를 운영합니다. 라우트, 방화벽 규칙, 전용 연결, 세분화 등을 여러분이 직접 설정합니다. 여기서의 잘못된 설정은 여전히 프로덕션에 영향을 미칩니다.
- Your application behavior – 제공업체는 플랫폼을 유지합니다. 배포 설정 오류, 비효율적인 쿼리, 메모리 누수 등은 여러분이 직접 해결해야 합니다.
- Restore testing (often missed) – 일부 재해 복구(DR) 서비스는 관리형 기능에 정기적인 복구 테스트를 명시적으로 포함하지 않습니다. 복구 테스트를 하지 않으면 복구가 아니라 단순히 저장만 된 것입니다.
계약에 포함시켜야 할 책임 매트릭스
이 표를 SOW에 붙여 사고 발생 시 참고하세요.
| 레이어 | 제공자 책임 (일반) | 귀하의 책임 (일반) |
|---|---|---|
| 데이터센터 + 하드웨어 | 전원, 랙, 물리적 보안 | — |
| 가상화 | 호스트/하이퍼바이저 기본 설정 | 게스트 OS (VM을 운영하는 경우) |
| 관리형 Kubernetes 컨트롤 플레인 | API 서버, etcd, 컨트롤‑플레인 업그레이드 | RBAC, 어드미션 정책, 네임스페이스, 워크로드 |
| 워커 노드 | 서비스 티어에 따라 다름 | 노드 OS 패치, 런타임, 애드‑온 (명시적으로 관리되지 않는 한) |
| 백업/DR 엔진 | 복제 + 오케스트레이션 | 복구 테스트, 애플리케이션 일관성, 복구 검증 |
| 보안 | “클라우드 자체” 제어 | “클라우드 내” 구성, 아이덴티티, 데이터 |
왜 중요한가
이것은 사고 수학이며, 조달 잡담이 아닙니다.
더 빠른 사고 라우팅
경계가 명확하면, 문제의 소유자를 두고 45 분을 논쟁하지 않습니다. 올바른 티켓을 열고 진행합니다.
더 깔끔한 RTO/RPO 계획
공급자는 재해 복구(DR)를 위해 <15 min RTO와 <5 min RPO와 같은 목표를 제시할 수 있지만, 애플리케이션은 여전히 복구 검증 및 전환 단계가 필요하며, 이는 스트레스 상황에서도 실행할 수 있어야 합니다.
“놀라운” 비용 감소
관리형 서비스는 운영 작업 부담을 줄여줍니다. 하지만 취약한 애플리케이션 설계나 부실한 변경 관리로 인한 엔지니어링 작업을 없애지는 못합니다.
AceCloud.ai와 함께 보는 모습
“관리형” 범위를 실제 서비스 페이지와 시행 가능한 진술에 매핑:
- Managed Kubernetes Control Plane – 프로덕션 워크로드에 대해 HA 운영 및 99.99 % 가동 시간 SLA를 명시합니다. 이를 RACI에서 “제공자가 컨트롤 플레인을 소유한다”는 것으로 간주하십시오.
- Cloud uptime SLA statement – AceCloud는 연간 “52 분”이라는 명시적인 다운타임 계산을 포함한 99.99 % 가동 시간 주장을 게시합니다. 범위와 일치한다면 해당 문구를 SOW에 사용하십시오.
- Disaster Recovery service – DR 오케스트레이션을 문서화하고 RTO/RPO 주장을 게시합니다(복제 페이지에 <15 / <5 수치 포함). 또한 DR 테스트 기능과 같은 제한 사항을 명시합니다. 기능과 제한 사항을 모두 런북에 포함시키십시오.
- Fully managed private cloud – 요구 사항이 격리 + “다른 사람이 플랫폼을 운영”이라면, 이는 퍼블릭 멀티‑테넌트 트레이드오프 없이 관리형 인프라 패턴에 해당합니다.
구매 체크리스트
이 질문들을 하고 서면으로 답변을 받으세요:
- SLA는 무엇이며, 어떤 구성 요소에 적용되나요? (control plane vs nodes vs storage vs network)
- 누가 무엇을 패치하나요? (control plane, node OS, CNI, ingress, runtime)
- 지원 범위는 무엇인가요? (제외되는 항목, 지원이 무효화되는 경우, “best effort”이란 무엇인지)
- 백업 및 복구는 어떻게 작동하나요? (RTO/RPO, 복구 단계, 복구 테스트 주기)
- 업그레이드는 어떻게 진행되나요? (maintenance windows, rollback, version policy)
결론
관리형 클라우드 인프라는 경계가 명확할 때 효과적입니다. 제공자가 제어하는 계층—컨트롤 플레인 유지보수, 플랫폼 패치, 모니터링, 재해 복구 메커니즘—에 대한 Day‑2 운영을 아웃소싱합니다. 그러나 아이덴티티, 데이터 보호 선택, 네트워크 의도, 워크로드 구성은 여전히 여러분이 소유합니다. 계약서에 RACI를 명시하고, 그에 따라 복구 스크립트와 사고 대응 런북을 작성하십시오.