[Platform Engineering] Day 1: Internal Developer Platform - 개념과 등장 배경

서론: DevOps의 다음 단계

DevOps는 개발과 운영의 경계를 허물었다. 그 결과 개발자가 직접 인프라를 다루게 됐지만, 새로운 문제가 생겼다. 팀마다 쿠버네티스 클러스터를 다르게 구성하고, 배포 파이프라인이 서비스마다 제각각이며, 신규 입사자가 개발 환경을 세팅하는 데 며칠이 걸린다.

Platform Engineering은 이 문제를 해결하기 위해 등장했다.

1. Platform Engineering이란

Platform Engineering은 소프트웨어 엔지니어링 조직에 셀프서비스 인프라와 개발자 도구를 제공하는 규율이다.

핵심 산출물은 Internal Developer Platform(IDP) 이다. IDP는 개발자가 인프라·배포·모니터링·보안 정책을 직접 요청하지 않고 셀프서비스로 이용할 수 있도록 추상화된 플랫폼이다.

전통적 흐름:
  개발자 → (티켓) → 인프라팀 → (수동 작업) → 환경 준비 (며칠 소요)

IDP 흐름:
  개발자 → (셀프서비스 UI/CLI) → IDP → (자동화) → 환경 준비 (분 단위)

2. 왜 지금 Platform Engineering인가

2.1 인프라 복잡성 증가

쿠버네티스, 서비스 메시, 멀티 클라우드, 옵저버빌리티 스택이 결합되면서 모든 개발자가 인프라 전문가가 되기를 기대하는 것은 비현실적이 됐다.

2.2 인지 부하 감소 필요

Team Topologies에서 말하는 “인지 부하(cognitive load)”다. 개발자가 비즈니스 로직이 아닌 인프라 운영에 시간을 쓰면 생산성이 낮아진다.

2.3 표준화를 통한 보안·컴플라이언스

플랫폼이 보안 정책과 컴플라이언스를 기본값으로 내장하면, 개발자가 의도치 않게 정책을 위반할 가능성이 줄어든다.

3. IDP의 핵심 구성 요소

구성 요소	역할
Service Catalog	서비스/애플리케이션 등록·조회
Self-Service Portal	환경 생성, 배포, 롤백
Scaffolding	신규 서비스 템플릿·코드 생성
CI/CD 통합	표준 빌드·배포 파이프라인
시크릿·설정 관리	환경별 설정 및 시크릿 주입
관측성 연동	로그·메트릭·트레이스 자동 연결

4. Platform Team의 역할

플랫폼 팀은 내부 개발자가 고객인 제품 팀이다.

• 개발자를 고객으로 취급하고 피드백을 수집한다
• 플랫폼 자체를 제품으로 운영한다 (버전, 문서, SLO)
• 강제가 아닌 유인(golden path)으로 표준화를 유도한다

플랫폼 팀이 개발자에게 쓰도록 강요하는 순간 채택률이 떨어진다.

5. IDP vs 단순 자동화 도구

구분	자동화 스크립트	IDP
범위	특정 작업	전체 개발자 워크플로우
*	소비자	인프라팀	모든 개발자
추상화	낮음	높음
확장성	팀 의존적	셀프서비스

6. Day 1 체크리스트

1. 현재 개발자가 인프라/배포 작업에 소비하는 시간을 측정했다.
2. 팀마다 다른 배포 방식과 설정의 편차를 파악했다.
3. Platform Engineering 도입의 목표(인지 부하 감소, 표준화, 속도)를 정의했다.
4. 플랫폼 팀을 제품 팀으로 운영하기 위한 고객(개발자) 피드백 채널을 마련했다.

다음 글 예고

Day 2에서는 Golden Path 설계를 다룬다. 개발자가 자연스럽게 따르게 되는 표준화된 경로를 어떻게 설계하고, 기존 자유도와 어떻게 균형을 맞추는지 살펴본다.