클라우드 서비스 브로커: 멀티클라우드를 하나의 정책 계층으로 묶는 법

왜 클라우드마다 직접 API를 붙이면 관리가 무너지는가

팀마다 AWS·Azure·GCP API를 각자 스크립트로 두드리기 시작하면, 처음 몇 달은 빠르지만 곧 태그 누락·정책 편차·계정 구조 불일치가 쌓인다. 클라우드 서비스 브로커(CSB)는 멀티클라우드 자원과 서비스(Compute, DB, Messaging, SaaS 등)를 단일 카탈로그·정책 엔진으로 중개하는 계층이다. 사용자 요청을 정책 검증 후 각 공급자 API로 번역해 일관된 프로비저닝·수명주기 관리를 제공한다.

Open Service Broker API(OSBAPI)와 유사한 컨셉의 서비스 카탈로그·바인딩·프로비저닝 패턴을 적용하며, Terraform/Pulumi, Crossplane, 각 CSP 네이티브 카탈로그와 연동할 수 있다. 제품·표준의 세부 기능은 벤더별로 다르므로 최신 정보를 확인해야 한다. 브로커·오케스트레이터·마켓플레이스는 자주 섞여 쓰이지만 역할이 다르다 — 브로커는 정책·거버넌스 중심 중개 계층, 오케스트레이터는 실행·워크플로 중심, 마켓플레이스는 공급자 카탈로그 노출 중심이다. 엔터프라이즈에서는 브로커가 상위에서 거버넌스·정책을 통제하고 오케스트레이터·마켓플레이스를 그 아래서 연계하는 구조를 선호한다.

브로커를 이루는 다섯 겹

서비스 카탈로그·메타데이터 관리는 표준화된 서비스 템플릿(플레이버, 리전, 가용성 등)을 버전 관리하고, 종속성·수명주기·보안 태그를 모델링하며, 승인·배포 워크플로와 연계해 카탈로그 공개 범위를 통제한다.

정책·거버넌스 엔진은 Policy as Code(OPA/Rego 등)로 예산·위치·암호화·네트워크·태깅 규칙을 적용한다. 사전 검증(Admission)과 사후 지속 규정 준수(Continuous Compliance)를 이중으로 두고, 역할 기반 접근 제어와 불변 감사로그로 뒷받침한다.

프로비저닝·오케스트레이션 드라이버는 CSP API, OSBAPI, IaC(Terraform/Pulumi), Crossplane 등 여러 드라이버를 지원한다. 여기서 트랜잭션·롤백·아이템포턴시가 핵심이다 — 락과 동시성 제어로 경합·드리프트를 최소화하지 않으면 부분 실패가 곧 데이터 정합성 문제로 번진다.

비용·계정·과금(FinOps) 연계는 태그·코스트 센터를 자동 주입하고, 견적·시뮬레이션과 구매 옵션 최적화(예약·세이빙플랜)를 지원하며, 쇼백·차지백 리포트와 예산 초과 방지 알림을 생성한다. 관측성·컴플라이언스는 상태·SLO 모니터링, 구성 드리프트 탐지, 힐링 오토메이션을 맡고, 데이터 주권·규제 준수(암호화·키 관리·리전 제한)를 자동 적용하며 백업·스냅샷·수명주기 정책을 표준화한다.

요청 한 건이 흘러가는 경로

입력은 서비스 요청(카탈로그 항목, 파라미터, 예산/태그)과 사용자·프로젝트 컨텍스트다. 처리는 정책 검증 → 비용 추정 → 리소스 락 → 멀티클라우드 프로비저닝 → 검증/바인딩 → 관측·청구 연계로 이어진다. 성공하면 바인딩 정보(엔드포인트/크리덴셜)와 태그·과금정보, 감사로그가 출력되고, 실패하면 롤백·리트라이·에스컬레이션으로 넘어간다.

⤢✕

API 한도·Quota 초과 시에는 큐 대기·재시도로, 리전 가용성 부족 시에는 대체 카탈로그 플랜 제안으로 대응한다. 롤백 자체가 실패하면 보상 트랜잭션과 운영자 에스컬레이션으로 넘긴다.

직접 접근과 브로커 기반의 차이

지표	직접 프로비저닝	브로커 기반 프로비저닝
성능	단일 요청 지연 최소	정책/검증 오버헤드로 소폭 증가(수초 단위)
확장성	팀별 스크립트 편차 큼	카탈로그·드라이버 수평 확장 용이
일관성	표준·태그 누락 위험	정책·템플릿으로 강제 일관성
안정성	실패 시 수동 정리 필요	트랜잭션·롤백·아이템포턴시 내장
운영 편의	빠른 즉시성이나 관리 분산	셀프서비스+거버넌스 결합, 운영 가시성 향상

어디에 쓰이는가

엔터프라이즈 셀프서비스 포털은 사내 포털(ServiceNow/Backstage)에서 카탈로그를 제공하고 승인·정책 자동화를 연계하며, 프로젝트 온보딩 시 네트워크·보안 기본 세트를 자동 배포한다. 규제 산업 거버넌스는 리전 화이트리스트, KMS 강제, 로그 불변 저장 정책을 적용하고 데이터 분류 기반으로 저장소 레벨 암호화·접근통제를 일괄 집행한다.

DBaaS·메시징 서비스 중개는 표준 플랜(S, M, L) 템플릿으로 프로비저닝·백업·패치를 자동화하고, 바인딩 시 애플리케이션에 시크릿을 안전하게 전달한다. 비용 최적화·FinOps는 생성 시 태그를 강제 주입하고 비용 추정이 초과되면 생성을 차단하며, 예약·세이빙 플랜 추천과 사용률 리포트를 자동 배포한다.

보안·운영 모범사례와 트레이드오프

최소권한 원칙과 분리된 작업용 서비스 계정, 단방향 임시 크리덴셜 발급이 기본이다. Policy as Code(OPA/Rego), 드리프트 감지·자동 교정, 불변 감사로그(WORM 등)를 갖추고, 시크릿은 KMS/HSM·Vault로 관리하며 멀티리전 장애 대비와 보상 트랜잭션 테스트를 정례화한다. 다만 추가 지연·복잡도는 강제 일관성·추적성과 맞바꾸는 트레이드오프이고, 벤더·도구 종속 위험은 운영 표준화 이점과 맞바꾼다. 고급 CSP 기능이 브로커 계층에 최신 반영되기까지 지연이 있을 수 있어 최신 정보 확인이 필요하다.

브로커를 도입한 사례에서는 프로비저닝 리드타임이 5080% 단축되고 변경 실패율이 2040% 감소하며, 태깅·정책 준수율이 90% 이상 달성되고 비용이 10~20% 절감(태그·예약 최적화)되는 것으로 보고된다. 감사 대응 시간도 60% 이상 단축되지만, 조직·도메인별 편차에 따라 변동 폭은 크다.

도입 전략: 파일럿에서 전사 확산까지

요구·정책을 먼저 정의한다 — 카탈로그 우선순위 서비스를 선정하고 리전·보안·비용 가드레일을 세운다. 데이터 모델·태그 체계에서는 코스트 센터·환경·소유자 등 핵심 태그를 표준화하고 계정·프로젝트 구조를 정한다. 정책 as Code·승인 워크플로 단계에서 사전 검증 규칙, 예외 절차, 감사 기준을 확정한 뒤, 실행 드라이버와 파이프라인(Terraform/Pulumi/Crossplane 표준화, 아이템포턴시 키·락 구현)을 만든다.

관측성·SLO 단계에서는 프로비저닝 성공률, 평균 처리시간, 롤백 성공률, 정책 위반율을 SLO로 설정한다. 보안·비상 복구 단계에서는 시크릿 로테이션, 키 백업, 롤백·보상 트랜잭션 연습 시나리오를 정례화한다. 마지막으로 샌드박스→파일럿→전사 확산 순으로 단계적으로 롤아웃하며 카탈로그·정책 버전을 관리한다.