Platform Engineering: Internal Developer Platform 구축 방법

소프트웨어 시스템이 점점 더 복잡해지면서 - 마이크로서비스, Kubernetes, 멀티클라우드, CI/CD 파이프라인, 관측성 스택 - 개발자들은 인프라에 더 많은 시간을 쓰고 제품 구축에는 더 적은 시간을 쓰고 있습니다. Platform Engineering은 복잡성을 추상화하고 개발자에게 더 빠른 배포를 위한 셀프서비스 도구를 제공하는 내부 플랫폼을 만들어 이 문제를 해결합니다.

Gartner는 2027년까지 **소프트웨어 엔지니어링 조직의 80%**가 플랫폼 팀을 설립할 것으로 예측합니다. 이 가이드에서는 Platform Engineering이 무엇인지, 왜 중요한지, 그리고 Internal Developer Platform을 처음부터 구축하는 방법을 살펴보겠습니다.

Platform Engineering이란?

Platform Engineering은 소프트웨어 엔지니어링 조직을 위한 셀프서비스 기능을 가능하게 하는 도구 체인과 워크플로를 설계하고 구축하는 분야입니다. 그 결과물은 Internal Developer Platform (IDP) - 개발자와 인프라 사이에 위치하는 계층입니다.

Platform Engineering vs DevOps

Platform Engineering은 DevOps의 대체가 아닙니다 - 다음 단계의 진화입니다. DevOps는 "네가 만들면, 네가 운영해"라고 했습니다. Platform Engineering은 "우리가 만들기와 운영을 쉽게 만들어 줄게"라고 말합니다.

측면	DevOps	Platform Engineering
초점	문화와 실천	제품과 셀프서비스
접근방식	각 팀이 인프라 관리	플랫폼 팀이 인프라 추상화
인지 부하	높음 (각 팀이 모든 것을 학습)	낮음 (골든 패스 제공)
결과물	CI/CD 파이프라인, IaC 스크립트	Internal Developer Platform
사용자	모든 엔지니어링	플랫폼 팀이 엔지니어링 서비스

Platform Engineering이 중요한 이유

인지 부하 문제

일반적인 현대 조직에서 개발자는 다음을 이해해야 합니다:

• Git 워크플로와 브랜치 전략
• CI/CD 파이프라인 설정
• 컨테이너 빌드와 레지스트리 관리
• Kubernetes 매니페스트와 Helm Charts
• 클라우드 제공업체 서비스 (AWS/GCP/Azure)
• 네트워킹, DNS, TLS 인증서
• 모니터링, 로깅, 알림 설정
• 데이터베이스 프로비저닝과 마이그레이션
• 보안 정책과 규정 준수

이것은 실제 제품에서 집중력을 빼앗는 엄청난 인지 부담입니다.

골든 패스

Platform Engineering은 골든 패스 개념을 도입합니다 - 일반적인 작업을 위한 의견이 담긴, 잘 지원되고 문서화된 경로입니다. 골든 패스는 강제가 아닙니다; 개발자는 벗어날 수 있지만, 플랫폼은 올바른 것을 쉬운 것으로 만듭니다.

새 마이크로서비스 생성을 위한 골든 패스 예시:

1. 개발자가 포털에서 "새 백엔드 서비스"를 선택
2. 언어/프레임워크 선택 (Node.js, Go, Python)
3. 플랫폼이 자동 생성: Git 리포지토리, CI/CD 파이프라인, Kubernetes 네임스페이스, 모니터링 대시보드, 알림 규칙
4. 개발자가 리포지토리를 클론하고 즉시 코딩 시작

Internal Developer Platform 구축

레이어 1: Developer Portal

포털은 개발자를 위한 단일 진입점입니다. 가장 인기 있는 오픈소스 옵션은 Backstage (Spotify가 만들었으며, 현재 CNCF 프로젝트)입니다.

핵심 기능:

• 서비스 카탈로그: 모든 서비스, 소유자, 문서, 의존성
• 소프트웨어 템플릿: 모범 사례가 내장된 새 서비스 스캐폴딩
• 기술 문서: 코드로서의 문서, 렌더링 및 검색 가능
• 플러그인 생태계: 커스텀 기능으로 확장 가능

# backstage/catalog-info.yaml
apiVersion: backstage.io/v1alpha1
kind: Component
metadata:
  name: user-service
  description: Manages user accounts and authentication
  annotations:
    github.com/project-slug: myorg/user-service
    backstage.io/techdocs-ref: dir:.
spec:
  type: service
  lifecycle: production
  owner: team-auth
  system: identity-platform
  dependsOn:
    - resource:postgresql-main
  providesApis:
    - user-api

레이어 2: 인프라 추상화

개발자는 Terraform이나 Kubernetes YAML을 직접 작성해서는 안 됩니다. 플랫폼이 추상화를 제공해야 합니다.

도구:

• Crossplane: Kubernetes 네이티브 인프라 프로비저닝
• Terraform 모듈: 사전 구축되고 테스트된 인프라 모듈
• Pulumi: 실제 코드로서의 인프라 (TypeScript, Python, Go)

# Example: Crossplane composition for a database
apiVersion: database.example.com/v1
kind: PostgreSQLInstance
metadata:
  name: user-db
spec:
  size: small        # Abstraction: small = 2 vCPU, 4GB RAM
  version: "16"
  backup: daily
  team: auth-team

RDS 파라미터, VPC 서브넷, 보안 그룹, 백업 정책을 구성하는 대신, 개발자는 size: small과 backup: daily만 지정합니다. 플랫폼이 나머지를 처리합니다.

레이어 3: CI/CD 표준화

팀마다 각자의 파이프라인을 만들지 않도록 CI/CD를 표준화합니다.

# .github/workflows/platform-ci.yml
# Teams just include the shared workflow
name: Build and Deploy
on:
  push:
    branches: [main]

jobs:
  pipeline:
    uses: myorg/platform-workflows/.github/workflows/standard-pipeline.yml@v2
    with:
      language: node
      deploy-target: production
    secrets: inherit

핵심 실천사항:

• 팀이 포함(복사가 아닌)하는 공유 CI/CD 템플릿
• 자동 보안 스캐닝 (SAST, 의존성 감사)
• 표준화된 배포 전략 (카나리, 블루/그린)
• 헬스 체크 실패 시 자동 롤백

레이어 4: 관측성

사전 구성된 모니터링으로 개발자가 즉시 대시보드와 알림을 받습니다.

• 메트릭: Prometheus + Grafana, 서비스별 표준 대시보드
• 로깅: 중앙 집중 수집이 포함된 구조화된 로깅 (Loki, ELK)
• 트레이싱: OpenTelemetry를 활용한 분산 트레이싱
• 알림: 합리적인 기본값이 적용된 PagerDuty/Opsgenie 연동

성공 측정

플랫폼이 잘 작동하는지 어떻게 알 수 있을까요? 다음 메트릭을 추적하세요:

DORA 메트릭

• 배포 빈도: 코드가 프로덕션에 도달하는 빈도
• 변경 리드 타임: 커밋에서 프로덕션까지의 시간
• 변경 실패율: 장애를 유발하는 배포의 비율
• 평균 복구 시간: 인시던트 후 서비스를 복원하는 시간

플랫폼 특화 메트릭

• 첫 배포까지의 시간: "새 서비스"에서 첫 프로덕션 배포까지 소요 시간
• 개발자 만족도 (NPS): 사용자를 정기적으로 설문 조사
• 셀프서비스 비율: 티켓 없이 처리되는 인프라 요청의 %
• 골든 패스 채택률: 권장 경로를 따르는 서비스의 %

흔한 실수

1. 너무 일찍 너무 많이 만들기

거창한 비전이 아닌 가장 큰 고통점부터 시작하세요. 배포가 고통스럽다면 거기서 시작하세요. 프로비저닝에 몇 주가 걸린다면 거기서 시작하세요.

2. 플랫폼을 제품으로 다루지 않기

플랫폼 팀에는 프로덕트 매니저, 사용자 리서치, 피드백 루프가 필요합니다. 개발자가 여러분의 고객입니다 - 그들의 니즈를 이해하세요.

3. 끌어들이는 대신 강제하기

최고의 플랫폼은 개발자의 삶을 더 쉽게 만들기 때문에 자발적으로 채택됩니다. 사용을 강제해야 한다면, 플랫폼이 충분히 좋지 않다는 뜻입니다.

4. 개발자 경험 무시하기

끔찍한 UX의 플랫폼은 사용되지 않습니다. 명확한 문서, 도움되는 에러 메시지, 빠른 피드백 루프에 투자하세요.

시작하기

첫 번째 IDP를 구축하기 위한 실용적인 로드맵:

최소 실행 가능 플랫폼

1. 서비스 카탈로그 (Backstage) - 무엇이 존재하고 누가 소유하는지 파악
2. 하나의 서비스 템플릿 - 가장 일반적인 서비스 유형을 위한 골든 패스
3. 표준화된 CI/CD - 팀이 포함하는 공유 파이프라인
4. 기본 문서 - 플랫폼 사용법, 도움을 받을 수 있는 곳

이 MVP는 2-3명의 엔지니어 팀으로 2-3개월 내에 구축할 수 있습니다.

결론

Platform Engineering은 첫날부터 완벽한 플랫폼을 만드는 것이 아닙니다. 개발자의 인지 부하를 점진적으로 줄여 제품 구축에 집중할 수 있게 하는 것입니다. 작게 시작하고, 영향을 측정하고, 개발자 피드백을 기반으로 반복하세요.

Platform Engineering에 투자하는 조직은 상당한 경쟁 우위를 갖게 됩니다: 더 빠른 딜리버리, 더 행복한 개발자, 그리고 더 안정적인 시스템.

리소스:

• Team Topologies - 플랫폼 팀을 대중화한 책
• Backstage - Spotify의 오픈소스 개발자 포털
• CNCF Platforms White Paper - 커뮤니티 정의와 모범 사례
• platformengineering.org - 커뮤니티, 이벤트, 리소스