[Daily morning study] Platform Engineering과 Internal Developer Platform (IDP) 개념

14 Nov 2026 in Daily morning study / Devops

#daily morning study

---

Platform Engineering이란

Platform Engineering은 개발자가 소프트웨어를 빠르고 안정적으로 빌드·배포·운영할 수 있도록 내부 플랫폼(Internal Developer Platform, IDP)을 설계하고 운영하는 엔지니어링 분야다.

전통적인 DevOps 모델에서는 개발자가 인프라 프로비저닝, 배포 파이프라인 설정, 모니터링 설정 등을 직접 처리해야 했다. 팀 규모가 커질수록 이 작업은 중복·비효율·오류의 원인이 됐다. Platform Engineering은 이를 플랫폼 팀이 “셀프 서비스 도구”로 추상화해 개발자에게 제공하는 방식으로 해결한다.

---

IDP (Internal Developer Platform)

IDP는 개발자가 인프라를 직접 다루지 않고도 애플리케이션을 배포·관리할 수 있게 하는 내부 플랫폼이다.

IDP가 제공하는 기능:

기능	설명
셀프 서비스 환경 프로비저닝	개발자가 클릭 또는 YAML 한 장으로 환경 생성
CI/CD 파이프라인 추상화	공통 파이프라인 템플릿 제공
서비스 카탈로그	조직 내 모든 서비스의 메타데이터·의존성 관리
비밀 관리 통합	Vault, AWS Secrets Manager 연결 단순화
로그·메트릭·트레이싱 연결	관측성(observability) 스택 자동 연결

IDP의 핵심은 개발자에게 “안전한 추상화(golden path)”를 제공하는 것이다. 개발자가 복잡한 Kubernetes 리소스를 직접 작성하는 대신, 플랫폼 팀이 정의한 표준 인터페이스를 통해 배포한다.

---

IDP vs PaaS

IDP와 PaaS(Heroku, Cloud Foundry 등)는 비슷해 보이지만 차이가 있다.

구분	PaaS	IDP
제어권	플랫폼 벤더	조직 내부 플랫폼 팀
커스터마이징	제한적	조직 요구에 맞게 완전 커스터마이징
인프라 선택	종속	멀티 클라우드·하이브리드 지원 가능
운영 주체	외부	내부 플랫폼 팀

---

대표 IDP 오픈소스 솔루션

Backstage (by Spotify)

가장 널리 쓰이는 IDP 프레임워크다. React 기반의 개발자 포털로, 서비스 카탈로그·소프트웨어 템플릿·문서를 한 곳에서 관리할 수 있다.

# Backstage 서비스 카탈로그 등록 예시
apiVersion: backstage.io/v1alpha1
kind: Component
metadata:
  name: payment-service
  description: 결제 처리 마이크로서비스
  annotations:
    github.com/project-slug: myorg/payment-service
spec:
  type: service
  lifecycle: production
  owner: payments-team
  system: checkout-system

Backstage에서 catalog-info.yaml을 저장소 루트에 추가하면 플랫폼이 자동으로 서비스를 인식·등록한다.

Port

노코드 중심의 IDP SaaS 솔루션이다. 개발자 포털을 JSON/YAML로 정의하고 GitHub·Jira·Kubernetes 등 도구와 통합한다.

Humanitec

IDP 엔진으로서 애플리케이션 배포 로직을 “Score” 명세로 추상화한다. 개발자는 인프라 세부 사항 없이 애플리케이션 의도(intent)만 기술하면 된다.

# Score 명세 예시 (Humanitec)
apiVersion: score.dev/v1b1
metadata:
  name: web-app
containers:
  web:
    image: myorg/web-app:latest
    resources:
      requests:
        cpu: "0.1"
        memory: "128Mi"
service:
  ports:
    www:
      port: 80
      targetPort: 8080

---

Golden Path

Golden Path는 플랫폼 팀이 조직 내 모범 사례를 녹여 만든 표준 개발·배포 경로다.

개발자가 새 서비스를 만들 때 Backstage의 소프트웨어 템플릿(scaffolder)을 통해 프로젝트를 생성하면:

1. 저장소 자동 생성 (GitHub 연동)
2. CI/CD 파이프라인 자동 구성 (GitHub Actions)
3. 쿠버네티스 Helm 차트 기본 구성 포함
4. 모니터링 대시보드 자동 프로비저닝 (Grafana)
5. 서비스 카탈로그 등록

이 과정을 개발자가 수동으로 처리하면 며칠 걸리는 작업이 수분으로 줄어든다.

---

Platform Engineering의 팀 구조

Platform Engineering에서는 플랫폼 팀이 별도로 존재한다. 이 팀의 고객은 외부 사용자가 아니라 내부 개발자다. 그래서 Thiago Ghisi, Manuel Pais 등 DevOps 연구자들은 플랫폼 팀을 “X-as-a-Service” 방식으로 운영해야 한다고 강조한다.

중요한 원칙:

• SLA를 가진 내부 제품처럼 운영: 플랫폼도 버전 관리, 릴리스 노트, 지원 채널을 갖춰야 한다.
• 개발자 경험(DX) 측정: DORA 메트릭 외에도 플랫폼 사용률, 개발자 만족도(NPS) 등을 측정한다.
• 옵트인 방식: 강제가 아닌 더 나은 경험을 통해 자연스럽게 채택되도록 한다.

---

IDP 도입 시 흔한 실수

1. 너무 이른 과도한 추상화 초기부터 완벽한 플랫폼을 만들려다 개발자의 실제 Pain Point를 놓친다. 먼저 개발자 인터뷰와 관찰을 통해 가장 반복적인 작업을 파악하고 거기서 시작하는 것이 중요하다.

2. 플랫폼 팀의 고립 플랫폼 팀이 개발 팀의 피드백 없이 독자적으로 개발하면 아무도 쓰지 않는 플랫폼이 된다. Embedded Platform Engineer를 도입하거나 정기적인 피드백 세션을 통해 현장 요구를 반영해야 한다.

3. 기존 도구의 무조건 교체 개발자가 익숙한 도구(GitHub, Terraform 등)를 교체하면 저항이 크다. IDP는 기존 도구를 통합하는 레이어로 접근하는 것이 현실적이다.

---

정리

Platform Engineering은 DevOps 문화의 다음 단계다. 조직이 커질수록 개발자가 직접 인프라를 다루는 방식은 비효율과 오류를 낳는다. IDP를 통해 개발자에게 셀프 서비스 경험을 제공하면 배포 빈도를 높이고, 인지 부하를 줄이며, 조직 전체의 엔지니어링 속도를 끌어올릴 수 있다.

Backstage를 중심으로 한 IDP 생태계는 계속 성장하고 있고, CNCF에서도 Platform Engineering을 주요 트렌드로 다루고 있다.