플랫폼 엔지니어링 05 - 플랫폼을 위한 Infrastructure as Code

IaC 없는 인프라는 부채다

개발자가 PostgreSQL 데이터베이스를 요청하면, 운영팀 누군가가 클라우드 콘솔에 접속하여 위저드를 클릭하고 설정 몇 개를 고른 뒤 커넥션 스트링을 보내주는 방식으로 처리하는 경우가 많다. 당장은 동작한다. 하지만 다음 사람이 같은 것을 요청했을 때 미묘하게 다른 설정을 받게 되거나, 원본 데이터베이스를 재생성해야 하는데 어떻게 구성했는지 아무도 기억하지 못하는 상황이 발생하면 문제가 드러나는 것이다.

IaC는 인프라를 선언적이고, 버전 관리되고, 반복 가능하게 만들어준다. 플랫폼 팀에게 이것은 선택의 영역이 아니다. 셀프서비스를 가능하게 하는 토대이기 때문이다.

추상화 레이어

그렇다면 개발자가 IaC를 직접 작성하면 되는 것인가? 그렇지 않다. 개발자가 Terraform이나 Crossplane을 직접 다루게 되면 플랫폼을 만든 의미가 사라지게 된다. 플랫폼 팀이 해야 할 일은 추상화 레이어를 구축하는 것이다. 개발자는 무엇이 필요한지만 선언하고, 그것을 어떻게 구현할지는 플랫폼이 처리하는 구조를 만드는 것이다.

개발자 요청:                 플랫폼이 변환:
┌─────────────────┐        ┌──────────────────────────────┐
│ "PostgreSQL DB  │  ──→   │ - RDS 인스턴스 (db.t3.medium) │
│  50GB,          │        │ - 보안 그룹                    │
│  스테이징"       │        │ - 서브넷 배치                  │
│                 │        │ - 백업 정책 (일간)              │
│                 │        │ - 모니터링 알림                 │
└─────────────────┘        └──────────────────────────────┘

이 구조에서 개발자는 보안 그룹이나 서브넷 배치를 알 필요가 없다. 플랫폼이 그러한 결정을 내장하고 있기 때문이다. 개발자에게는 간단한 인터페이스만 노출하고, 복잡한 인프라 결정은 플랫폼 내부에 캡슐화하는 것이 추상화 레이어의 핵심이다.

Terraform vs Pulumi vs Crossplane

세 가지 도구 중 어느 것이 정답이라고 단정할 수는 없다. Terraform은 가장 널리 사용되는 출발점이며 생태계가 가장 넓다. Crossplane은 이미 Kubernetes 중심으로 운영하는 환경에서 강점을 발휘한다. Pulumi는 별도의 도메인 특화 언어를 배우고 싶지 않은 팀에게 매력적인 선택지가 되는 것이다.

Crossplane: Kubernetes 네이티브 IaC

Crossplane이 주목받는 이유는 인프라 프로비저닝을 Kubernetes 리소스와 동일한 방식으로 다룰 수 있게 해주기 때문이다. 개발자가 이미 kubectl apply를 알고 있다면, 같은 워크플로로 클라우드 리소스까지 프로비저닝할 수 있게 되는 셈이다.

# 개발자가 제출하는 내용
apiVersion: database.platform.io/v1alpha1
kind: PostgreSQL
metadata:
  name: orders-db
spec:
  size: medium
  storage: 50Gi
  environment: staging

이 간단한 매니페스트 뒤에서 Crossplane Composition이 실제 클라우드 리소스로 확장하는 작업을 수행한다. RDS 인스턴스, 보안 그룹, 파라미터 그룹이 자동으로 생성되지만, 개발자는 그러한 복잡성을 직접 다룰 필요 없이 데이터베이스를 받게 되는 것이다.

셀프서비스 흐름

실제 셀프서비스가 동작하는 과정을 살펴보면 다음과 같다. 먼저 개발자가 카탈로그에서 필요한 리소스를 선택한다. UI, CLI, YAML 파일 등 여러 인터페이스가 제공될 수 있다. 이후 요청은 플랫폼의 정책에 따라 검증되는데, 크기 제한이나 네이밍 규칙, 허용 리전 등이 이 단계에서 확인된다. 검증을 통과하면 IaC 엔진이 리소스를 프로비저닝하고, 연결 정보가 시크릿과 엔드포인트 형태로 개발자에게 전달된다. 프로비저닝된 리소스는 개발자 포털에서 추적할 수 있게 된다.

이 과정을 통해 개발자는 몇 분 만에 데이터베이스를 받게 되고, 플랫폼 팀은 일관성과 컴플라이언스, 감사 추적을 별도의 수동 작업 없이 확보하게 되는 것이다.

진짜 차이

IaC가 없는 플랫폼은 결국 단계만 하나 추가된 티켓 시스템에 불과하다. 반면 IaC가 있으면 진정한 셀프서비스가 가능해진다. 개발자는 몇 분 만에 필요한 것을 받고, 모든 리소스는 일관되고 감사 가능하며 재현할 수 있는 상태가 유지되는 것이다.

결국 추상화 레이어의 존재 여부가 "우리는 Terraform을 씁니다"와 "우리는 플랫폼이 있습니다"를 가르는 차이인 셈이다.

다음 포스트에서는 개발자 포털을 다룬다. 서비스, 문서, 도구를 한 곳에서 찾을 수 있는 플랫폼의 정문에 해당하는 구성 요소이다.