2017년 Netflix는 소프트웨어 팀에 급진적인 자유를 주기로 결정했다. 수백 개 마이크로서비스 팀이 각자 독립적으로 배포한다. 그런데 "어떤 팀이 어떤 AWS 리소스를 소유하는가?"라는 질문에 아무도 답하지 못하는 상황이 됐다. 동시에 수천 개 EC2, RDS, Lambda가 있는데 어느 것이 어느 서비스에 속하는지 태그만으로는 불충분했다.
AWS Service Catalog, AppConfig, AppRegistry는 이 문제들의 대답이다. Service Catalog는 "권한 없는 개발자도 표준 인프라를 자가 서비스로 프로비저닝한다". AppConfig는 "코드 배포 없이 런타임 설정을 안전하게 변경한다". AppRegistry는 "흩어진 AWS 자산을 애플리케이션 단위로 묶는다". SOA-C02에서 이 세 서비스는 운영자가 조직 전체의 거버넌스와 일관성을 유지하는 도구로 다뤄진다.
Service Catalog의 핵심 문제 의식은 두 가지 상충하는 목표를 동시에 달성하는 것이다. "개발자에게 신속한 자가 서비스를 제공한다" + "조직의 보안 표준과 비용 정책을 반드시 준수한다". 이 두 목표는 보통 대립한다. 자유를 주면 표준이 흔들리고, 표준을 강제하면 병목이 생긴다.
Service Catalog의 해법은 Launch Constraint Role이다. 개발자는 카탈로그에서 제품을 클릭한다. 실제 CloudFormation 스택 생성은 Launch Constraint Role이 수행한다. 개발자는 S3 버킷을 만들 권한이 전혀 없어도, Service Catalog를 통해 표준 패키지를 프로비저닝할 수 있다. 그리고 그 표준 패키지 밖의 것은 절대 만들 수 없다.
💡 관련 이론: Service Catalog의 Launch Constraint는 소프트웨어 보안의 최소 권한 원칙(Principle of Least Privilege)의 정교한 구현이다. 단순히 권한을 제한하는 것이 아니라, "필요한 작업을 수행하는 대리인(Role)을 정의하고, 사용자는 그 대리인을 통해서만 작업"하는 위임(Delegation) 패턴이다. 이는 Unix의 setuid 비트(프로그램 실행 시 파일 소유자 권한으로 실행)와 동일한 원리다. 개발자 = 일반 유저, Launch Role = setuid 실행 파일, Service Catalog 제품 = 그 실행 파일이 수행하는 정해진 작업.
# Launch Role에 필요한 최소 권한 (Service Catalog가 이 Role로 CFn 실행)LaunchRole: Type: AWS::IAM::Role Properties: RoleName: ServiceCatalogLaunchRole AssumeRolePolicyDocument: Version: '2012-10-17' Statement: - Effect: Allow Principal: Service: servicecatalog.amazonaws.com Action: sts:AssumeRole # Permission Boundary 적용 (Launch Role이 더 강력한 권한 갖지 못하도록) PermissionsBoundary: arn:aws:iam::123456789012:policy/ServiceCatalogBoundary ManagedPolicyArns: - arn:aws:iam::aws:policy/CloudFormationFullAccess Policies: - PolicyName: WebStackProvisioning PolicyDocument: Version: '2012-10-17' Statement: - Effect: Allow Action: - ec2:* - ecs:* - rds:* - elasticloadbalancing:* - autoscaling:* Resource: '*'
Service Catalog + Permission Boundary의 조합은 AWS에서 가장 정교한 권한 위임 패턴 중 하나다. 구조는 이렇다: (1) 개발자(IAM User/Role)는 Service Catalog API를 호출할 권한만 갖는다. (2) Service Catalog가 Launch Role을 Assume한다. (3) Launch Role의 실제 권한 = (Launch Role의 IAM Policy) ∩ (Permission Boundary). Permission Boundary가 없으면 Launch Role이 무제한 권한을 가질 수 있어, 개발자가 Service Catalog를 통해 Admin 권한으로 임의 리소스를 만들 수 있다. 이를 "권한 에스컬레이션(Privilege Escalation)"이라 부르며, Permission Boundary가 이를 차단하는 가드레일이다.
가상의 사례로, 2023년 대형 제조업체 J사는 15개 사업부가 각각 AWS 계정을 운영하고 있었다. 각 사업부 개발팀이 독립적으로 EC2, RDS 등을 프로비저닝하다 보니 보안 그룹 설정이 제각각이었고, 일부 팀은 0.0.0.0/0으로 RDS를 열어두는 사태가 발생했다. 해결책으로 중앙 Platform Engineering 계정에서 "승인된 데이터베이스 패키지" 제품을 만들어 15개 사업부 계정에 Portfolio를 공유했다. 이후 어떤 사업부도 표준 패키지 밖의 RDS를 만들 수 없게 됐다. 6개월 후 보안 감사에서 "모든 RDS가 표준 구성을 준수함"을 확인했다.
2003년 Google의 Jeff Dean과 Sanjay Ghemawat이 발표한 MapReduce 논문에는 "시스템의 많은 파라미터가 런타임에 조정 가능해야 한다"는 원칙이 있다. 현대 분산 시스템에서 이 원칙은 "Feature Flag"로 구체화됐다. 코드를 재배포하지 않고도 기능을 켜고 끌 수 있어야 한다.
AWS AppConfig는 이 Feature Flag와 동적 설정 배포를 위한 관리형 서비스다. 단순히 설정값을 저장하는 것이 아니라, 점진적 배포(Progressive Delivery), 사전 검증(Validation), 자동 롤백(Auto Rollback)을 제공한다.
AppConfig 핵심 구성 요소:
요소
역할
예시
Application
최상위 컨테이너
OrderService, UserService
Environment
배포 환경
dev, staging, prod
Configuration Profile
설정 출처와 타입
Hosted / S3 / Parameter Store
Hosted Configuration
AppConfig 내장 저장소
Feature Flags 전용 타입 지원
Deployment Strategy
배포 방식과 속도
Linear, Exponential, AllAtOnce, Canary
Validator
배포 전 검증
JSON Schema, Lambda
Extension
이벤트 후크
배포 시작/완료/롤백 시 Lambda 호출
Deployment Strategy 전체:
전략 이름
동작
적합 상황
AppConfig.AllAtOnce
즉시 100% 전환
dev 환경, 긴급 패치
AppConfig.Linear50PercentEvery30Seconds
30초마다 50%씩 (총 60초)
빠른 배포, 낮은 위험
AppConfig.Linear20PercentEvery6Minutes
6분마다 20%씩 (총 30분)
표준 프로덕션 배포
AppConfig.Canary10Percent20Minutes
10% → 20분 대기 → 100%
새 기능 조심스럽게
Custom
완전 커스텀 (GrowthFactor, BakeTime, GrowthType)
특수 요구사항
Custom Deployment Strategy 생성:
# 점진 배포: 5%에서 시작해 30% 성장, 10분 Bake Timeaws appconfig create-deployment-strategy \ --name "Cautious5Percent" \ --description "5%에서 시작, 10분 간격, 10분 bake time" \ --deployment-duration-in-minutes 50 \ --final-bake-time-in-minutes 10 \ --growth-factor 30 \ --growth-type EXPONENTIAL \ --replicate-to NONE# 배포 완료 후 10분 Bake Time 동안 알람 감시# Bake Time 중 알람 발생 시 자동 롤백
⚠️ 함정: AppConfig Deployment Strategy의 FinalBakeTimeInMinutes는 배포가 100%에 도달한 후 추가로 대기하는 시간이다. 이 시간 동안에도 CloudWatch Alarm을 감시한다. 알람이 발생하면 자동 롤백이 시작된다. 많은 운영자가 "100% 배포 완료 = 배포 종료"로 착각하지만, FinalBakeTimeInMinutes가 있으면 그 시간이 지나야 배포가 COMPLETE 상태가 된다. AllAtOnce 전략에 FinalBakeTimeInMinutes=10을 추가하면, 즉시 100%에 도달하지만 10분 후에 배포가 완전히 확정된다.
AppConfig Lambda 클라이언트 통합:
# Lambda에서 AppConfig를 효율적으로 사용하는 패턴# Lambda Extension(AWS AppConfig Agent)이 로컬 HTTP 서버로 설정 캐시import urllib.requestimport jsondef get_config(): """ AppConfig Lambda Extension이 로컬 2772 포트에서 설정 제공. Extension이 자동으로 캐시 + 폴링 처리. 직접 AppConfig API를 호출하는 것보다 훨씬 효율적. """ url = ( "http://localhost:2772/applications/OrderService" "/environments/prod/configurations/FeatureFlags" ) req = urllib.request.Request(url) response = urllib.request.urlopen(req) config = json.loads(response.read()) return configdef handler(event, context): config = get_config() flags = config.get('values', {}) if flags.get('new_checkout_flow', {}).get('enabled', False): return process_new_checkout(event) else: return process_legacy_checkout(event)
AppConfig의 점진적 배포(Progressive Delivery)는 Martin Fowler가 2010년 정의한 "Feature Toggle" 패턴의 AWS 관리형 구현이다. Fowler는 Feature Toggle을 4가지 타입으로 분류했다: (1) Release Toggles(배포 중 임시), (2) Experiment Toggles(A/B 테스트), (3) Ops Toggles(운영 스위치), (4) Permission Toggles(계층별 접근). AppConfig는 주로 Release Toggles와 Ops Toggles를 지원한다. 자동 롤백은 제어 이론의 피드백 제어 루프다: CloudWatch Alarm이 에러율 임계값을 감지하면 AppConfig가 교정 액션(롤백)을 실행한다.
AppConfig Validator 심화:
# Lambda Validator: 비즈니스 규칙 검증def validate_handler(event, context): """ AppConfig가 배포 전 이 Lambda를 호출. 유효하지 않으면 예외를 raise하여 배포 차단. """ import json, base64 # 설정 내용 디코딩 config = json.loads(base64.b64decode(event['content'])) # 검증 1: feature flag가 100개를 초과하면 거부 flags = config.get('flags', {}) if len(flags) > 100: raise Exception(f"Feature flag 수가 100개를 초과합니다: {len(flags)}개") # 검증 2: 알 수 없는 flag 이름이 있으면 거부 allowed_flags = {'new_checkout_flow', 'recommendation_engine_v2', 'dark_mode'} unknown = set(flags.keys()) - allowed_flags if unknown: raise Exception(f"알 수 없는 feature flag: {unknown}") # 검증 3: flag가 활성화될 때 필수 속성 확인 for flag_name, flag_value in config.get('values', {}).items(): if flag_value.get('enabled') and flag_name == 'new_checkout_flow': # 새 결제 플로우 활성화 시 payment_provider 필수 if 'payment_provider' not in flag_value: raise Exception("new_checkout_flow 활성화 시 payment_provider 필수") print("Validation passed") # 예외 없이 반환하면 검증 통과
AppRegistry의 "Application as a First-Class Citizen" 접근은 DORA(DevOps Research and Assessment) 지표의 "Deployment Frequency"와 "Change Failure Rate"를 측정하는 단위가 개별 리소스가 아니라 "서비스(Application)"이어야 한다는 통찰에서 나왔다. 운영 관점에서 "EC2 i-abc123이 CPU 90%"는 정보가 적지만, "OrderService의 CPU가 90%"는 즉각적인 비즈니스 영향도를 알 수 있다. AppRegistry는 이 추상화를 AWS 레벨에서 공식적으로 지원한다.
Service Catalog, AppConfig, AppRegistry는 각각 독립적으로 사용할 수 있지만, 함께 사용하면 더 강력해진다.
조직 수준 거버넌스 플랫폼 아키텍처
============================================================
[플랫폼팀]
│
├── Service Catalog에 표준 제품 등록
│ (웹 스택, ML 스택, 데이터 스택)
│
├── AppConfig로 환경별 설정 관리
│ (Feature Flags, 알고리즘 파라미터)
│
└── AppRegistry로 애플리케이션 자산 등록
(메타데이터, 비용센터, SLA)
[개발팀]
│
├── Service Catalog 카탈로그에서 표준 인프라 선택
│ → Launch Constraint Role로 프로비저닝
│ → Provisioned Product = Stack
│
├── Stack을 AppRegistry Application에 연결
│ → Application Manager에서 통합 뷰
│
└── AppConfig로 런타임 설정 변경
→ 코드 재배포 없이 Feature Flag 토글
→ Canary 배포로 안전하게 적용
→ 알람 연동으로 자동 롤백
[운영팀]
│
├── Application Manager에서 애플리케이션 단위 상태 확인
├── AppConfig 배포 상태 및 자동 롤백 모니터링
└── Service Catalog Provisioned Products로 표준 준수 감사
가상의 사례로, 2024년 전자상거래 K사는 50개 마이크로서비스를 운영하며 두 가지 문제가 있었다. 첫째, 각 팀이 다른 방식으로 인프라를 구성해 보안 감사 시 "표준 미준수" 항목이 항상 나왔다. 둘째, 새 기능을 배포할 때마다 전체 서비스를 다운시켰다. 해결책: (1) Service Catalog로 5가지 표준 인프라 패턴(웹, 데이터, 배치, 실시간, 분석)을 제품화하고 모든 팀이 이 중에서만 선택하도록 했다. (2) AppConfig Feature Flags로 새 기능을 코드에 포함시키되 비활성화 상태로 배포, 이후 점진적으로 활성화했다. (3) AppRegistry로 50개 서비스의 자산을 Application 단위로 정리해 OpsCenter에서 서비스별 운영 이슈를 추적했다. 결과: 보안 감사 "표준 미준수" 0건, 배포 관련 장애 67% 감소.
📝 연습 문제
선택지를 클릭하면 정답·해설이 펼쳐집니다.
문제 1
회사가 개발자에게 표준 VPC + RDS 인프라를 자가 서비스로 제공하면서, 개발자가 다른 종류 리소스를 직접 만들 수 없게 강제하려 한다. 어떤 도구를 사용해야 하는가?
문제 2
Lambda 함수의 Feature Flag를 코드 재배포 없이 토글하고 싶다. 새 설정이 배포되는 동안 에러율이 급증하면 자동으로 이전 설정으로 돌아가야 한다. 가장 적합한 도구는?
문제 3
AppConfig 배포 전 설정값의 JSON 구조가 올바른지 자동으로 검증하려 한다. 어떤 기능을 사용해야 하는가?
문제 4
AppConfig 배포에서 FinalBakeTimeInMinutes: 10을 설정했다. AllAtOnce 전략으로 배포했을 때 동작은?
문제 5
개발팀이 Service Catalog에서 "Standard Web Stack" 제품을 프로비저닝하려 한다. 개발자의 IAM 권한에는 EC2, RDS 생성 권한이 없다. 어떻게 프로비저닝이 가능한가?
문제 6
50개 마이크로서비스를 운영하는 회사가 각 서비스별 AWS 비용, 알람, 운영 이슈를 한 화면에서 확인하고 싶다. 어떤 도구 조합이 가장 적합한가?