What is Platform Engineering

분류: Layer 5 - 플랫폼 엔지니어링 & 자동화 | 작성일: 2026-03-21

이 문서는 layer-intro.mdx 다음에 읽는 첫 일반 토픽이다. 레이어 도입부에서 잡은 전체 경로를 바탕으로 플랫폼 엔지니어링의 기본 언어와 판단 기준을 구체화한다. IDP(Internal Developer Platform, 내부 개발자 플랫폼) 구현 세부사항은 이후 internal-developer-platform.mdx에서 다룬다.

1. 한 줄 정의

플랫폼 엔지니어링은 개발자가 인프라, 배포, 권한, 관찰 가능성 같은 공통 작업을 셀프서비스로 안전하게 처리할 수 있도록 내부 플랫폼을 제품처럼 만드는 엔지니어링이다.

핵심은 “도구를 많이 붙이는 것”이 아니다. 개발자가 기능을 출시할 때 매번 Kubernetes, 네트워크, IAM, CI/CD, 로그 설정을 모두 직접 이해해야 한다면 제품 개발보다 운영 세부사항에 머리가 묶인다. 플랫폼은 이 반복 복잡성을 표준 경로와 자동화 뒤로 내려 보내고, 개발자는 제품 도메인과 코드에 집중하게 만든다.

처음 읽을 때는 아래 문장만 잡으면 된다.

개발자 경험(DX): 개발자가 기능을 만들고 배포하는 과정에서 겪는 마찰의 총합이다.
셀프서비스: 티켓을 기다리지 않고, 정해진 UI·CLI·API로 필요한 환경을 직접 만든다.
Golden Path: 조직이 권장하는 안전하고 빠른 표준 경로다. 강제 표준이 아니라 “이 길이 가장 쉽다”는 제품 경험이어야 한다.
가드레일: 자유롭게 쓰되 보안·비용·운영 리스크를 자동으로 막는 제약이다.
Platform as a Product: 플랫폼 팀은 내부 개발자를 고객으로 보고, 채택률·피드백·문서·지원 경험을 개선한다.

2. 왜 중요한가

개발팀이 작을 때는 “배포 한번 도와주세요”, “S3 읽기 권한 하나만 주세요” 같은 요청을 사람이 처리해도 버틸 수 있다. 팀과 서비스 수가 늘면 같은 방식이 곧 병목이 된다.

상황	티켓 운영 중심	플랫폼 엔지니어링 중심
새 서비스 생성	개발자가 인프라 팀에 요청하고 며칠 기다린다.	템플릿으로 저장소, 배포 파이프라인, 모니터링이 함께 생성된다.
권한 추가	요청자, 리소스, 환경, 만료일을 사람이 반복 확인한다.	정책 검증을 통과한 범위 안에서 셀프서비스로 발급된다.
배포 실패	각 팀이 다른 로그 위치와 다른 절차를 찾아야 한다.	표준 대시보드, 배포 로그, 롤백 경로가 같은 위치에 있다.
운영 리스크	빠르게 처리하려고 예외와 수동 변경이 쌓인다.	가드레일과 감사 로그가 기본 경로 안에 들어 있다.

BackOps 관점에서는 특히 직접적이다. BackOps 업무는 개발 조직이 제품을 더 빠르고 안전하게 내보내도록 돕는 일이다. 반복 요청을 관찰하고, 표준화 가능한 경로를 만들고, 실패했을 때 원인을 좁히기 쉽게 만드는 것은 플랫폼 엔지니어링의 출발점이다.

2.5 선행 한계 -> DevOps 티켓 운영에서 셀프서비스 플랫폼으로

플랫폼 엔지니어링은 DevOps를 대체하려고 등장한 개념이 아니다. DevOps가 말한 “개발과 운영의 협력”을 조직 규모가 커져도 실행 가능하게 만들기 위해, 반복 운영 지식을 제품화된 내부 플랫폼으로 흡수한 흐름에 가깝다.

선행 방식의 한계는 세 가지다.

개발자 인지 부하가 과해진다. 기능 하나를 배포하려고 VPC, IAM, 컨테이너 런타임, CI/CD, 로그, 알림, 보안 정책까지 알아야 한다.
인프라 팀이 반복 티켓 처리자가 된다. 권한 추가, 환경 생성, 배포 설정처럼 같은 요청이 계속 들어오면 고부가가치 개선보다 대기열 처리에 시간을 쓴다.
표준이 문서에만 있고 실행 경로에는 없다. “우리 회사 배포 표준”이 문서에 있어도, 실제로는 팀마다 다른 스크립트와 예외가 생긴다.

해결 메커니즘은 frontmatter의 lineage_oneliner처럼 외재적 인지 부하를 플랫폼 레이어로 내려보내는 것이다. 예를 들어 새 NestJS 서비스를 만들 때 개발자가 VPC, IAM, ECS/EKS, 로그 그룹, 알림, 배포 파이프라인을 각각 학습하게 두지 않는다. 플랫폼은 “새 서비스 생성”이라는 하나의 셀프서비스 Golden Path로 묶고, 그 뒤에서 조직 표준을 자동 적용한다.

DORA는 이 방향을 하위 복잡성 추상화와 개발자 인지 부하 감소로 설명한다. 여기서 중요한 표현은 “shift down”이다. 보안·테스트·운영 책임을 무조건 개발자에게 더 왼쪽으로 밀어 넣는 것이 아니라, 반복 복잡성은 플랫폼 아래로 내리고 개발자는 단순한 경로를 사용하게 한다.

3. 핵심 개념 1: DX와 인지 부하

DX(Developer Experience)는 개발자가 제품 코드를 만들고 운영 환경에 올리기까지 겪는 경험이다. 좋은 DX는 단순히 UI가 예쁜 포탈이 아니다. 개발자가 “내가 지금 제품 문제를 풀고 있는가, 아니면 주변 도구를 맞추느라 시간을 쓰고 있는가”를 가르는 운영 체계다.

나쁜 DX의 전형적인 흐름은 이렇다.

개발자가 새 기능을 만든다.
배포하려면 인프라 팀에 티켓을 작성해야 한다.
티켓이 평균 2~3일 대기한다.
설정 중 요구사항이 모호해서 다시 확인한다.
최종 배포까지 1~2주가 걸린다.

좋은 DX에서는 같은 작업이 이렇게 바뀐다.

개발자가 개발자 포탈이나 CLI에서 “새 서비스 생성”을 실행한다.
5분 안에 저장소, 배포 파이프라인, 기본 알림, 서비스 카탈로그 등록이 끝난다.
실패하면 어느 단계에서 왜 실패했는지 로그와 재시도 경로가 보인다.

인지 부하 3유형

Team Topologies의 인지 부하 모델은 플랫폼 엔지니어링을 이해하는 좋은 출발점이다. 인지 부하는 개발자가 일을 할 때 머릿속에 동시에 담아야 하는 정보량이다.

인지 부하 3유형과 플랫폼의 역할

내재적 부하

업무 자체의 본질적 복잡성이다. 결제 규칙, 정산 로직, 상품 정책처럼 제품 도메인 사고가 여기에 속한다.

플랫폼이 없애면 안 된다. 개발자가 이해하고 축적해야 하는 핵심 역량이다.

외재적 부하

업무 본질과 직접 관련 없는 부가 작업이다. Terraform 작성, IAM 권한 요청, 배포 대기, 로그 위치 찾기가 여기에 속한다.

플랫폼이 Golden Path와 자동화로 가장 먼저 줄여야 하는 대상이다.

크로스 도메인으로 보는 같은 원리

“외재적 인지 부하를 줄인다”는 원리는 플랫폼 엔지니어링만의 발명이 아니다. 소프트웨어 설계 전반에서 다른 이름으로 반복된다.

도메인	외재적 부하 제거 수단	개발자가 집중할 수 있는 것
Platform	Golden Path, 표준 템플릿, CI/CD 자동화	비즈니스 로직과 배포 결과
DB	ORM, 쿼리 빌더, 마이그레이션 도구	도메인 모델과 데이터 의미
API	OpenAPI, REST 컨벤션, SDK 생성	엔드포인트의 비즈니스 계약
보안	Policy-as-Code, 기본 권한 템플릿	필요한 접근 범위와 리스크

공통점은 복잡한 구현 세부사항을 추상화 뒤로 숨기는 것이다. 단, 추상화가 실패 메시지와 탈출구까지 숨기면 Golden Path가 아니라 Golden Cage가 된다.

4. 핵심 개념 2: 셀프서비스와 IDP

셀프서비스는 “티켓 없이 스스로 처리한다”는 뜻이다. 하지만 플랫폼 엔지니어링에서의 셀프서비스는 아무 권한이나 열어주는 것이 아니다. 조직이 허용한 표준 경로 안에서 요청, 검증, 실행, 기록, 실패 안내가 자동으로 이어지는 구조다.

일반적인 구현 방식은 세 가지다.

방식	예시	장점	주의점
포탈 UI	Backstage, Port, Cortex	새 개발자도 버튼과 문서로 접근하기 쉽다.	버튼만 있고 실제 자동화가 약하면 껍데기 포탈이 된다.
CLI	`platform new service`, `platform grant`	반복 작업과 로컬 개발 흐름에 잘 붙는다.	도움말, 실패 메시지, 인증 흐름이 부실하면 쓰이지 않는다.
API	Backstage Scaffolder API, 내부 provisioning API	AI 에이전트나 CI/CD가 같은 경로를 재사용할 수 있다.	감사 로그, 쿼터, 권한 경계가 반드시 필요하다.

IDP(Internal Developer Platform)는 이런 셀프서비스 경로를 모아 둔 내부 개발자 플랫폼이다. IDP의 핵심 산출물은 포탈 자체가 아니라, 개발자가 실제로 일을 끝낼 수 있는 경로다. 서비스 카탈로그, 템플릿, 배포 파이프라인, 권한 발급, 관찰 가능성, 문서가 서로 연결되어야 한다.

셀프서비스 worked example

예를 들어 user-service가 report-bucket을 읽어야 한다고 하자.

티켓 운영에서는 요청자가 “S3 권한 추가”라고 올리고, 인프라 담당자는 어느 환경인지, 어떤 버킷인지, 읽기인지 쓰기인지, 만료가 필요한지 다시 묻는다. 담당자가 바쁘면 며칠 대기하고, 급하면 콘솔에서 수동으로 정책을 붙인다. 나중에는 누가 왜 붙였는지 추적하기 어렵다.

플랫폼 경로에서는 요청이 하나의 명령이나 포탈 액션으로 표현된다.

platform grant s3-read \
  --service user-service \
  --bucket report-bucket \
  --env prod \
  --expires 2026-06-30

이 명령은 단순 편의 기능이 아니다. 뒤에서는 다음 검증이 함께 돈다.

검증	질문	실패 시 메시지 예
소유권	`user-service`의 owner가 요청자 팀인가?	“team-a는 user-service 권한을 요청할 수 없습니다.”
환경	prod 권한 요청에 승인 정책이 필요한가?	“prod 권한은 approver 1명이 필요합니다.”
범위	read만 필요한데 write 권한을 요청했는가?	“write 권한은 이 Golden Path에서 허용하지 않습니다.”
만료	임시 권한에 만료일이 있는가?	”임시 prod 권한은 expires가 필요합니다.”
감사	누가, 언제, 왜 요청했는가?	감사 로그에 request id를 남긴다.

이 예제에서 학습해야 할 것은 명령어가 아니라 구조다. 좋은 셀프서비스는 요청을 쉽게 만들고, 위험한 요청은 배포 전에 막으며, 실패했을 때 다음 행동을 알려준다.

실패 로그도 제품의 일부다

Backstage Scaffolder 같은 도구는 템플릿 실행을 task 단위로 관리한다. 성공했을 때 링크를 보여주는 것만으로는 부족하다. 실패한 step, 에러 메시지, 재시도 가능 여부가 보여야 개발자가 플랫폼 팀을 호출하지 않고 원인을 좁힐 수 있다.

{
  "id": "task-abc123",
  "status": "failed",
  "steps": [
    {
      "id": "publish",
      "status": "failed",
      "message": "Repository already exists"
    }
  ]
}

status: "failed"만 있고 실패 step이나 message가 비어 있다면 셀프서비스가 독립성을 주지 못한 것이다. 이 경우 다음 기능을 추가하기 전에 에러 메시지, 원인 설명, 재시도 방법을 먼저 제품화해야 한다.

5. 핵심 개념 3: Golden Path

Golden Path는 조직이 권장하는 안전하고 빠른 표준 경로다. CNCF(Cloud Native Computing Foundation, 클라우드 네이티브 컴퓨팅 재단)와 플랫폼 커뮤니티에서 널리 쓰는 표현이며, “잘 통합된 템플릿과 기능 조합으로 빠른 프로젝트 개발을 가능하게 하는 경로”라고 이해하면 된다.

중요한 경계가 있다. Golden Path는 강제 표준이 아니다.

강제 표준: “이 방식 외에는 배포할 수 없다.”
Golden Path: “이 방식으로 하면 가장 빠르고 안전하며 지원도 쉽다. 특수한 경우에는 벗어날 수 있지만 비용과 책임을 이해해야 한다.”

실제 Golden Path는 여러 요소가 함께 묶인 제품 경험이다.

구성 요소	포함 내용	예시 도구
소프트웨어 템플릿	기본 코드 구조, 테스트, Dockerfile, README	Backstage Scaffolder
인프라 프로비저닝	ECS/EKS, RDS, ALB, DNS, 시크릿	Terraform, Crossplane, Pulumi
CI/CD	빌드, 테스트, 이미지 푸시, 배포, 롤백	GitHub Actions, ArgoCD
관찰 가능성	로그, 대시보드, 알림, SLO(Service Level Objective, 서비스 수준 목표) 기본값	CloudWatch, Grafana, Datadog
보안	최소 권한, secret 관리, 이미지 스캔	IAM, Secrets Manager, Kyverno
문서와 소유권	서비스 설명, owner, runbook 링크	Backstage Catalog

Golden Path가 좋은지 확인하는 질문

처음 쓰는 개발자가 30분 안에 첫 성공을 볼 수 있는가?
실패했을 때 어느 단계에서 왜 실패했는지 보이는가?
표준 경로를 쓰면 보안·관찰 가능성·배포 기본값이 자동으로 따라오는가?
특수한 요구로 경로를 벗어날 때 비용과 책임이 명확한가?
플랫폼 팀이 직접 쓰지 않아도 제품팀이 계속 쓰고 싶어 하는가?

반례도 중요하다. 모든 것을 Golden Path로 만들 필요는 없다. 요청이 매번 다른 네트워크 예외, 특수 계정, 임시 방화벽 정책이라면 자동화 UI만 커지고 예외 처리가 본문이 된다. 이때는 셀프서비스보다 명확한 승인 절차, 위험한 요청의 로그 표준화, 별도 전문팀 상담 경로가 더 낫다.

6. 핵심 개념 4: 가드레일

가드레일은 개발자가 자유롭게 움직이되 위험한 범위를 자동으로 막는 제약이다. 플랫폼 엔지니어링에서 가드레일은 “안전한 기본값”과 “자동 차단”을 동시에 제공한다.

예를 들어 서비스 생성 요청에서 CPU, 메모리, owner 태그를 검사한다고 하자. 아래 예시는 OPA(Open Policy Agent, 정책을 코드로 검사하는 엔진)의 Rego 문법을 쓴다. 문법을 외우기보다 “요청을 배포 전에 기계적으로 검사한다”는 역할을 보면 된다.

package ecs.guardrails

deny[msg] {
  input.cpu > 2048
  msg := "CPU는 2048 유닛(2 vCPU)을 초과할 수 없습니다."
}

deny[msg] {
  input.memory > 4096
  msg := "메모리는 4096MB를 초과할 수 없습니다."
}

deny[msg] {
  not input.tags.owner
  msg := "모든 리소스에 owner 태그가 필요합니다."
}

학습 포인트는 OPA 문법 자체가 아니다. 셀프서비스가 안전하려면 “요청 -> 정책 검증 -> 승인 또는 거부 -> 이유 설명 -> 감사 기록”이 한 경로에 있어야 한다는 점이다.

요청	가드레일 결과	개발자가 배워야 할 것
CPU 4096, Memory 8192	거부	기본 Golden Path의 용량 상한을 넘었다. 예외 절차나 별도 아키텍처 검토가 필요하다.
owner 태그 없음	거부	비용·장애·권한 추적을 위해 소유권은 필수 메타데이터다.
prod DB write 권한	거부 또는 승인 필요	위험 범위가 크므로 자동 발급보다 승인과 감사가 필요하다.

가드레일의 silent failure

가드레일은 “차단 수”만 보면 잘 작동하는 것처럼 보일 수 있다. 실제로는 우회와 드리프트가 조용히 쌓이면 보호 효과가 사라진다.

실패 유형	발생 시나리오	관찰 신호	먼저 볼 것
예외가 영구 면제가 됨	임시 승인된 정책 예외가 만료 없이 남는다.	`exempt` 비율 증가, 예외 만료일 누락	OPA decision log, 예외 승인 목록
shadow pipeline	팀이 표준 CI/CD 밖에서 배포한다.	배포 이벤트가 있는데 정책 로그가 없다.	배포 감사 로그, CI/CD 이벤트
템플릿 드리프트	Golden Path v2가 나왔지만 서비스가 v1에 머문다.	오래된 템플릿 버전의 서비스 비율 증가	서비스 카탈로그, GitOps diff
콘솔 수동 변경	IaC와 실제 인프라가 달라진다.	Terraform plan에 unexpected diff 반복	Terraform plan, drift detection

따라서 플랫폼 팀은 정책 위반 차단 수뿐 아니라 우회 시도, 예외 만료, 드리프트 해소 시간도 함께 봐야 한다.

7. Platform as a Product

플랫폼은 내부 고객을 위한 제품이다. 이 문장이 중요한 이유는 플랫폼 팀의 성공 기준을 바꾸기 때문이다. “포탈을 만들었다”가 아니라 “개발자가 자발적으로 쓰고, 실제 병목이 줄었고, 실패했을 때 스스로 다음 행동을 찾는다”가 성공이다.

제품처럼 운영한다는 것은 최소한 다음을 포함한다.

제품 사고	플랫폼에서의 의미
고객 이해	개발자 인터뷰, 티켓 분석, 온보딩 관찰로 실제 마찰을 찾는다.
MVP	가장 반복적이고 표준화 가능한 요청 하나부터 자동화한다.
채택률	플랫폼을 쓰는 팀과 안 쓰는 팀의 차이를 본다.
피드백 루프	실패 로그, 서베이, 지원 채널을 다음 개선에 반영한다.
문서	사용법뿐 아니라 실패 원인과 탈출 경로를 설명한다.

좋은 플랫폼은 “우리가 표준을 만들었으니 따라라”가 아니라 “이 길이 기존 방식보다 빠르고 안전해서 자연스럽게 쓰인다”에 가깝다. Spotify의 Backstage 사례에서 자주 인용되는 교훈도 이 지점이다. Backstage는 유일한 해결책이 아니라 더 나은 해결책이어야 했다. 채택을 강제하면 플랫폼이 아니라 황금 우리가 된다.

8. Team Topologies와 플랫폼 팀의 위치

플랫폼 엔지니어링은 도구만의 문제가 아니라 팀 경계의 문제다. Team Topologies는 팀을 네 가지 유형으로 나누어 각 팀이 떠안는 인지 부하를 줄이려 한다.

Team Topologies 팀 유형

Stream-aligned Team

비즈니스 가치를 직접 전달하며 고객 문제 해결에 집중한다.

대부분의 제품 개발팀이 여기에 속하고, 플랫폼의 내부 고객이 된다.

Platform Team

Stream-aligned Team이 셀프서비스로 인프라와 공통 기능을 쓰게 만든다.

IDP, Golden Path, 공통 배포/관찰 가능성 플랫폼을 제품처럼 운영한다.

Enabling Team

보안, 테스트, 성능 같은 전문성을 다른 팀에 전파하고 코칭한다.

기술 도입 초기의 학습 곡선을 낮춰야 할 때 효과적이다.

Complicated-subsystem Team

ML 모델, 결제 엔진, 암호화 모듈처럼 깊은 전문성이 필요한 서브시스템을 소유한다.

일반 제품팀이 계속 떠안기에는 인지 부하가 너무 높은 영역이다.

플랫폼 팀의 고객은 Stream-aligned Team이다. 플랫폼 팀이 인프라를 대신 운영해주는 헬프데스크가 되면 병목은 그대로 남는다. 반대로 개발팀이 플랫폼 없이 모든 운영 세부사항을 떠안으면 외재적 부하가 다시 제품팀으로 밀려온다. 좋은 플랫폼 팀은 표준 경로를 만들고, 예외의 비용을 설명하며, 반복 질문이 줄어들도록 제품을 개선한다.

9. 무엇을 먼저 플랫폼화할 것인가

플랫폼 엔지니어링은 큰 IDP부터 만드는 프로젝트가 아니다. 첫 MVP는 반복 빈도와 표준화 가능성이 높은 작은 병목이어야 한다.

예를 들어 한 달간 infra-request 42건 중 S3 읽기 권한 요청이 18건이라면, 전체 인프라 포탈보다 “권한 셀프서비스”가 더 좋은 시작점일 수 있다.

질문	좋은 후보 신호	나쁜 후보 신호
실제 고통인가?	월 3회 이상 반복되고 대기 시간이 길다.	누군가 “있으면 좋겠다”고만 말한다.
표준화 가능한가?	요청의 70~80%가 같은 입력으로 표현된다.	매번 예외 조건이 달라 UI 분기만 늘어난다.
실패 반경이 작은가?	기본값과 승인 절차로 위험을 제한할 수 있다.	한 번의 실수가 prod 데이터 손상으로 이어진다.
자동화 가치가 큰가?	반복 티켓 처리 시간이 눈에 띄게 줄어든다.	자동화 유지보수가 수동 처리보다 비싸다.
관찰 가능한가?	채택률, 실패율, 처리 시간을 측정할 수 있다.	성공 여부를 감으로만 판단해야 한다.

BackOps에서 바로 계산해볼 수 있는 가치

작은 수치 계산이 플랫폼 후보를 고르는 데 도움이 된다.

이번 달 인프라 요청 42건
그중 권한 추가 18건
건당 평균 대기 + 처리 시간 2시간

월 회수 가능 시간 = 18건 * 2시간 = 36시간

이 숫자는 “플랫폼이 멋져 보인다”보다 강하다. 권한 셀프서비스가 처리 시간을 2시간에서 10분으로 줄이고 실패 원인 문의도 줄인다면, 다음 투자를 설득할 근거가 생긴다. 반대로 자동화 후에도 권한 요청 비중이 43%에서 30% 아래로 내려가지 않거나, 실패 요청의 절반 이상이 “왜 거부됐는지 모르겠다”는 문의로 이어지면 문제를 해결한 것이 아니라 티켓 양식을 UI로 옮긴 것이다.

10. 생산성 측정: DORA와 flow metric

플랫폼의 가치는 “도구를 만들었다”가 아니라 흐름이 좋아졌다는 증거로 설명해야 한다. DORA(DevOps Research and Assessment) 지표와 flow metric은 그 증거를 만드는 언어다.

차원	측정 대상	측정 방법	BackOps 적용 예
Flow Time	개발자가 방해 없이 일하는 시간	하루 중 집중 코딩 시간, 티켓 대기 시간	인프라 요청 대기 시간 측정
Friction	인지적·시스템적 방해	개발자 서베이, 반복 티켓 분석	가장 많은 요청 유형 파악
Throughput	커밋에서 배포까지 흐름	DORA 리드 타임, 배포 빈도	CI/CD 파이프라인 시간 측정
Capacity	시간 배분	기능 개발, 유지보수, 비계획 작업 비율	운영 요청 처리 시간 비율

플랫폼 성숙도는 대략 다음과 같은 방향으로 관찰할 수 있다. 숫자는 조직마다 다르므로 목표값을 그대로 베끼기보다 추세를 보아야 한다.

단계	Golden Path 채택률	배포 빈도	변경 리드 타임	해석
Level 0: 수동	0%	주 1회 이하	1~4주	팀마다 방식이 다르고 티켓 대기가 많다.
Level 1: 부분 자동화	30~50%	주 1회	2~7일	일부 스크립트는 있지만 표준 경험이 약하다.
Level 2: Golden Path 운영	70~80%	일 1회	1일 이하	표준 경로가 실제로 채택되고 있다.
Level 3: 고도화	90%+	온디맨드	시간 단위	자동화, 관찰 가능성, 가드레일이 통합되어 있다.

핵심은 Golden Path 채택 팀과 미채택 팀의 차이를 보는 것이다. 채택 팀의 리드 타임과 수동 요청 수가 실제로 줄지 않는다면 플랫폼이 생산성을 높였다고 말하기 어렵다.

11. 자주 헷갈리는 개념 비교

개념 A	개념 B	차이점
Platform Engineering	DevOps	DevOps는 문화와 협업 원칙이고, Platform Engineering은 그 원칙을 셀프서비스 플랫폼으로 실행 가능하게 만드는 엔지니어링이다.
Platform Engineering	SRE	SRE는 안정성과 신뢰성 운영에 초점이 강하고, Platform Engineering은 개발자 경험과 전달 흐름에 초점이 강하다.
Platform Team	Infra Team	Infra Team은 인프라 운영 자체에 집중하기 쉽고, Platform Team은 개발자가 직접 쓸 수 있는 제품화된 경로를 만든다.
Golden Path	강제 표준	Golden Path는 권장 경로이고 우회 가능성을 설명한다. 강제 표준은 우회를 막는다.
셀프서비스	무제한 권한	셀프서비스는 정책 검증과 감사 로그가 붙은 안전한 경로다.

12. 실패 신호: Golden Cage와 조직 저항

플랫폼 엔지니어링의 대표 실패는 Golden Cage다. 겉으로는 예쁜 포탈과 버튼이 있지만, 내부 동작이 불투명하고 우회가 어렵고 실패하면 플랫폼 팀만 기다려야 하는 상태다.

Golden Cage의 자가진단 질문은 간단하다.

내일 이 플랫폼을 선택사항으로 만들면, 개발자들이 여전히 쓰겠는가?

대답이 “아니오”라면 플랫폼이 개발자의 문제를 줄인 것이 아니라 통제 레이어를 하나 더 만든 것일 수 있다.

실패 신호	의미	먼저 고칠 것
채택률이 10~30%에서 멈춘다.	개발자가 표준 경로의 가치를 못 느끼거나 기존 방식보다 불편하다.	개발자 인터뷰, 첫 성공 시간, 온보딩 문서
실패 문의가 계속 플랫폼 팀으로 온다.	에러 메시지와 로그가 충분하지 않다.	task log, 실패 step, 재시도 경로 노출
예외 요청이 계속 늘어난다.	Golden Path가 실제 요구를 담지 못하거나 너무 좁다.	예외 유형 분석, 템플릿 옵션 재설계
shadow pipeline이 생긴다.	표준 경로가 느리거나 과도하게 통제적이다.	배포 흐름 시간, 정책 승인 시간
플랫폼 팀이 기능보다 유지보수에 대부분의 시간을 쓴다.	DIY 범위가 조직 규모를 넘었다.	관리형 서비스, 범위 축소, plugin 전략

조직 저항도 실패 신호다. 기존 인프라 팀은 “내 역할이 없어지는 것 아닌가”를 걱정할 수 있고, 개발팀은 “또 다른 복잡한 도구를 배워야 하나”라고 느낄 수 있다. 이때 플랫폼 엔지니어링을 설득하는 방식은 역할을 빼앗는 것이 아니라 반복 작업을 줄여 더 높은 가치의 설계와 개선으로 이동시키는 것이다.

13. 실무에서 어디에 쓰이나

플랫폼 엔지니어링은 다음 영역에서 자주 나타난다.

내부 개발자 포탈: 서비스 카탈로그, 소유자, 문서, 배포 상태를 한 곳에서 보여준다.
서비스 스캐폴딩: 새 서비스 저장소, 기본 코드, CI/CD, 관찰 가능성을 함께 만든다.
인프라 프로비저닝: Terraform, Pulumi, Crossplane 등으로 환경 생성을 자동화한다.
셀프서비스 권한: IAM, DB 계정, 시크릿 접근을 정책 기반으로 발급한다.
표준 CI/CD: 빌드, 테스트, 배포, 롤백 경로를 일관되게 만든다.
관찰 가능성 기본값: 로그, 메트릭, 알림, 대시보드가 서비스 생성과 함께 붙는다.
정책 자동화: OPA, Kyverno 같은 도구로 보안과 비용 가드레일을 적용한다.

14. 현재 업무와 연결점

BackOps 업무에서 플랫폼화 후보를 찾으려면 “내가 자주 처리하는 요청”보다 “개발자가 자주 막히는 흐름”을 먼저 본다.

BackOps 업무	플랫폼 엔지니어링으로 확장되는 방향
수동 배포 지원	CI/CD 템플릿, 롤백 경로, 배포 실패 로그 표준화
인프라 요청 처리	셀프서비스 프로비저닝과 정책 검증
권한 요청 처리	최소 권한 템플릿, 승인 워크플로, 감사 로그
개발자 온보딩 지원	서비스 스캐폴딩, 카탈로그, Golden Path 문서
장애 대응	관찰 가능성 기본값, SLO, 알림 라우팅

Product Engineering과도 연결된다. 제품 기능은 코드만으로 출시되지 않는다. 배포, 권한, 관찰, 롤백, 실험 설정이 함께 움직여야 사용자가 실제로 가치를 경험한다. 플랫폼을 내부 제품처럼 운영하는 사고는 나중에 product discovery, UX flow, product analytics, feature flag, experiment loop를 이해하는 기반이 된다.

15. 선택 심화: 2025~2026 트렌드 미리보기

이 절은 첫 회독 필수 내용이 아니다. 플랫폼 엔지니어링의 기본 개념을 잡은 뒤, 시장과 도구 흐름을 읽을 때 참고한다. 통계와 시장 수치는 발표 기관과 시점에 따라 달라지므로, 실제 의사결정에는 최신 원문을 다시 확인해야 한다.

시장 신호를 읽는 법

트렌드 수치는 “우리도 당장 큰 플랫폼 팀을 만들자”는 결론이 아니라, 어떤 문제가 업계 공통 문제로 커졌는지 보는 신호다.

자료	관찰할 신호	첫 회독에서 남길 해석
Gartner Platform Engineering	2026년까지 대형 소프트웨어 엔지니어링 조직의 80%가 플랫폼 팀을 둘 것이라는 전망	플랫폼 팀은 실험적 유행이 아니라 조직 규모 문제에 대한 표준 대응이 되고 있다.
DORA Platform Engineering	2025년 기준 IDP 사용 조직 90%, 전담 플랫폼 팀 76%라는 채택 신호	포탈 보유 자체보다 개발자 독립성, 피드백, 전달 성과를 함께 봐야 한다.
State of Platform Engineering Vol.4	500명 이상의 실무자 조사에서 AI-native, shifting down, 역할 변화가 핵심 주제로 등장	AI와 플랫폼은 별개 트렌드가 아니라 셀프서비스 경로를 누가 호출하느냐의 문제로 만난다.
DX: Backstage and the Developer Portal Market	Backstage가 IDP 도입 조직에서 강한 점유율을 보인다는 조사 신호	Backstage는 중요한 기준점이지만, 채택률과 제품 경험이 약하면 도구 우위가 성공을 보장하지 않는다.
Roadie: Platform Engineering in 2026	DIY Backstage의 유지보수 비용과 관리형·하이브리드 접근 논의	”오픈소스라 무료”가 아니라 운영 인력, 보안 패치, plugin 유지비까지 계산해야 한다.

Shift Down과 AI 통합

2025~2026년 플랫폼 엔지니어링 자료에서 자주 보이는 흐름은 “Shift Down”과 AI 통합이다. Shift Down은 운영 복잡성을 애플리케이션 개발자에게 계속 넘기지 않고 플랫폼 레이어로 내려보내자는 표현이다. 이 문서의 핵심인 외재적 인지 부하 감소와 같은 방향이다.

AI 통합은 세 가지 형태로 나타난다.

AI-assisted scaffolding: 개발자가 자연어로 “user-service 만들어줘”라고 요청하면, AI가 팀의 표준 템플릿을 고르고 필요한 파라미터를 채운다.
자동 이상 감지: 배포 후 메트릭 이상을 탐지하고 관련 로그와 변경 이력을 묶어 보여준다.
정책 안내: 요청이 가드레일에 막혔을 때 정책 이유와 수정 방법을 설명한다.

여기서 중요한 점은 AI를 예외 사용자로 두지 않는 것이다. AI 에이전트가 플랫폼 API를 호출한다면 인간 개발자와 같은 RBAC(Role-Based Access Control, 역할 기반 접근 제어), 쿼터, 감사 로그, 가드레일을 적용해야 한다.

사람 개발자 -> Backstage UI -> 서비스 생성
AI 에이전트 -> Backstage API -> 서비스 생성

공통으로 필요한 것:
- 동일한 Golden Path
- 동일한 권한 경계
- 동일한 감사 로그
- 동일한 실패 메시지

DIY 플랫폼과 관리형 서비스

Backstage 같은 오픈소스 IDP를 직접 운영할지, Roadie·Cortex·Port 같은 관리형 또는 상용 도구를 조합할지는 조직 규모와 유지보수 역량에 따라 달라진다.

시그널	DIY 위험 신호	권장 판단
전담 유지보수 인원	3 FTE 미만	전체 IDP 직접 구축보다 관리형 또는 작은 자동화부터 검토한다.
내부 채택률	3개월 후 30% 미만	도구 문제가 아니라 실제 마찰을 잘못 고른 것인지 확인한다.
유지보수 비율	기능 개발보다 운영 유지보수가 더 크다.	plugin 범위 축소나 관리형 전환을 검토한다.
조직 규모	엔지니어 30명 미만	GitHub Template, Terraform 모듈, 간단한 CLI로 충분할 수 있다.
도입 속도	6~12개월 기다릴 수 없다.	완전 자체 구축보다 기존 도구 조합이 현실적이다.

기업 사례에서 남길 교훈

Spotify의 Backstage는 많은 팀과 서비스가 생기면서 “무슨 서비스가 있고, 누가 소유하며, 어떻게 배포되는가”를 찾기 어려워진 문제에서 출발했다. 교훈은 Backstage 자체가 아니라, 내부 도구가 더 나은 선택지여야 한다는 점이다.

Netflix 사례에서 배울 점은 완전 자체 구축보다 오픈소스 기반 + 필요한 UI/플러그인 커스터마이징이 현실적인 선택일 수 있다는 것이다. 플랫폼 팀의 일은 모든 것을 직접 만드는 것이 아니라, 조직의 병목을 줄이는 조합을 찾는 것이다.

BACK 스택 미리보기

2026년 전후 플랫폼 엔지니어링 자료에서는 BACK 스택이라는 표현도 자주 보인다.

Backstage: 개발자 포탈과 서비스 카탈로그
ArgoCD: GitOps 기반 배포 자동화
Crossplane: Kubernetes 기반 인프라 프로비저닝
Kyverno: Kubernetes 정책 관리와 보안 규정 준수

첫 회독에서는 이름만 알아도 충분하다. 중요한 것은 특정 도구 암기가 아니라, 포탈·배포·프로비저닝·정책이 셀프서비스 경로 안에서 함께 움직인다는 구조다.

16. 선택 부록: 내가 직접 확인해볼 것

이 부록은 실습용이다. 긴 명령을 외우는 것이 목표가 아니라, 플랫폼화 후보를 찾고 관찰 지표를 만드는 연습이 목표다.

1단계: 반복 요청 목록 만들기

최근 한 달의 Slack, GitHub Issues, Jira에서 인프라·배포·권한 요청을 모은다.

gh issue list --label "infra-request" --state all --limit 50

관찰할 것은 명령 출력 자체가 아니라 패턴이다.

#45  [infra-request] 스테이징 환경 추가 요청
#42  [infra-request] user-service S3 권한 추가
#38  [infra-request] prod DB 읽기 전용 계정 생성
#35  [infra-request] 새 서비스 ECS 설정 요청

다음 질문으로 분류한다.

월 3회 이상 반복되는가?
요청 입력이 5개 이하의 파라미터로 표현되는가?
실패해도 되돌릴 수 있는가?
승인이나 감사 로그가 필요한가?
자동화 후 처리 시간과 실패율을 측정할 수 있는가?

2단계: 인지 부하 간이 측정

개발자 3명에게 아래 질문을 던져본다.

1. 코드 작성 외에 가장 시간이 많이 드는 작업은?
   - 인프라 설정
   - 배포 대기
   - 권한 요청
   - 환경 설정
   - 문서 찾기

2. 이번 주에 티켓 작성 -> 대기 -> 처리로 소비한 시간은?
   - 0시간
   - 1~2시간
   - 3~4시간
   - 5시간 이상

3. 배포할 때 가장 불안한 점은?

응답에서 가장 자주 나오는 외재적 인지 부하가 첫 플랫폼화 후보가 된다.

3단계: Backstage Scaffolder를 관찰만 해보기

Backstage를 바로 도입하라는 뜻이 아니다. 템플릿 실행이 어떤 구조로 관리되는지 관찰하는 실습이다.

npx @backstage/create-app@latest

관찰 포인트는 세 가지다.

템플릿 입력값이 무엇인지
실행 task가 어떤 step으로 나뉘는지
실패했을 때 어느 step과 message가 보이는지

API로 보면 task 생성과 상태 확인은 대략 이런 구조다.

curl -X POST http://localhost:7007/api/scaffolder/v2/tasks \
  -H 'Content-Type: application/json' \
  -d '{"templateRef":"template:default/nestjs-service","values":{"name":"user-service","owner":"team-backend"}}'

curl http://localhost:7007/api/scaffolder/v2/tasks/task-abc123

처음에는 성공보다 실패 로그를 본다. 실패 원인을 읽고 다음 행동을 알 수 있다면 셀프서비스의 기본 조건을 갖춘 것이다.

17. 복습 체크리스트

플랫폼 엔지니어링 복습 체크리스트

플랫폼 엔지니어링을 개발자 셀프서비스 플랫폼 관점에서 한 문장으로 설명할 수 있다.
Developer Experience가 외재적 인지 부하를 줄이는 문제와 연결된다는 점을 설명할 수 있다.
Golden Path와 강제 표준의 차이를 설명할 수 있다.
셀프서비스에는 가드레일, 감사 로그, 실패 메시지가 함께 필요하다는 점을 설명할 수 있다.
Platform Engineering, DevOps, SRE의 차이를 개발자 경험과 안정성 초점으로 비교할 수 있다.
현재 팀에서 플랫폼 엔지니어링 관점으로 개선할 반복 작업을 1개 이상 말할 수 있다.

퀴즈

플랫폼 엔지니어링이 줄여야 하는 인지 부하는 내재적, 외재적, 관련적 중 무엇인가?

힌트: 비즈니스 로직 자체를 없애는 것이 아니다.

정답 보기

외재적 인지 부하다. Terraform, IAM, 배포 대기처럼 제품 기능 구현의 본질이 아닌 반복 운영 복잡성을 플랫폼이 흡수한다. 내재적 부하와 관련적 부하는 개발자가 이해하고 축적해야 할 영역이다.

18. 5줄 요약

플랫폼 엔지니어링은 개발자를 위한 셀프서비스 플랫폼을 제품처럼 만드는 엔지니어링이다.
핵심 가치는 외재적 인지 부하를 줄여 개발자가 제품 도메인에 집중하게 하는 것이다.
Golden Path는 강제 표준이 아니라 가장 쉽고 안전한 권장 경로여야 한다.
셀프서비스는 가드레일, 감사 로그, 실패 메시지와 함께 있을 때 안전하다.
BackOps에서 반복 요청을 자동화하고 측정 가능한 흐름으로 바꾸는 것이 플랫폼 엔지니어링의 시작이다.

19. 추가 학습 키워드

Team Topologies, Backstage, Port, Cortex, Platform as a Product, Cognitive Load, Developer Productivity, Golden Path, Guardrail, DORA Metrics, Flow Metrics, CNCF Platforms White Paper

20. 추천 리소스

CNCF Platforms White Paper — 클라우드 네이티브 플랫폼의 정의와 구현 가이드
DORA: Platform Engineering — 플랫폼 엔지니어링과 소프트웨어 전달 성과의 연결
What is a Golden Path — Red Hat — Golden Path의 개념과 구현 관점
Backstage Software Templates — Scaffolder task와 템플릿 실행 구조
Microsoft Learn: Start Your Platform Engineering Journey — 플랫폼 엔지니어링 여정의 단계별 안내
State of Platform Engineering Vol.4 — 플랫폼 엔지니어링 커뮤니티 조사와 트렌드