# Platform Engineering이란? SRE 현장 가이드 URL: https://upstreamapi.com/ko/journal/platform-engineering-iran Type: blog Locale: ko Published: 2026-09-19 Updated: 2026-09-19 --- > Platform engineering이란 제품 팀과 인프라 사이의 셀프 서비스 레이어를 구축하는 전문 분야입니다. 내부 개발자 플랫폼, 팀 구조, DORA 메트릭과 골든 패스를 다룹니다. 2026년 중반 기준으로 'platform engineering iran'이라는 검색어는 구글에서 월 약 18,000건 조회됩니다. Platform engineering이란 제품 팀과 원시 인프라 사이에 위치하는 셀프 서비스 레이어, 즉 내부 개발자 플랫폼(IDP)을 설계하고 운영하는 전문 분야입니다. 이것이 DevOps의 리브랜딩인지, SRE의 승격인지, 아니면 엔지니어링 조직이 작동하는 방식의 실질적인 구조적 전환인지 의문이 있다면: 세 번째가 맞습니다. 이 글은 CI/CD 입문서가 아닙니다. 플랫폼 팀을 구축 중이거나 그 투자를 리더십에 정당화해야 하는 platform engineer, SRE 리드, 엔지니어링 매니저를 위한 지도입니다. ## Platform Engineering은 새 라벨을 붙인 DevOps가 아닙니다 DevOps는 실천 방식과 문화적 규범의 집합입니다. Platform engineering은 제품을 가진 팀 토폴로지입니다. 이 구분은 운영상 중요합니다. DevOps 문화는 개발자들이 자신의 배포를 소유하도록 독려합니다. 플랫폼 팀은 그 소유권을 규모에서 실용적으로 만드는 기계를 구축합니다. CI/CD 파이프라인 템플릿, 배포 추상화, 옵저버빌리티 스택, 시크릿 관리, 비용 가드레일을 내부 제품으로 셀프 서비스 인터페이스를 통해 애플리케이션 팀에 제공합니다. 엔지니어 20명 규모에서 이 구분은 학문적입니다. 80명이 넘으면, 이것은 두 명의 ops 인력에 병목된 인프라 지식과 티켓 없이 어떤 팀이든 사용할 수 있는 포장된 길의 차이가 됩니다. SRE와의 관계는 경쟁이 아닌 보완입니다. SRE는 프로덕션에서 시스템이 작동하는 방식을 개선합니다. Platform engineering은 조직이 소프트웨어를 출시하는 행위를 확장하는 방식을 개선합니다. 실제로 많은 플랫폼 팀이 SRE 팀에서 성장합니다. ## 내부 개발자 플랫폼(IDP)이 실제로 담고 있는 것 IDP는 단일 도구가 아닙니다. 일반적으로 다음 시스템들의 조합입니다. - 배포 메커니즘 (Kubernetes, 서버리스 런타임 또는 그 위에 관리형 추상화) - 사전 승인된 설정을 포함한 CI/CD 파이프라인 템플릿 - 범위가 지정된 접근 및 순환을 갖춘 시크릿 매니저 - 서비스 유형별 사전 구성된 대시보드를 포함한 옵저버빌리티 스택 (메트릭, 로그, 트레이스) - 무엇이 어디서 실행되며 누가 소유하는지 문서화하는 서비스 카탈로그 - 2026년 사실상 표준인 Backstage를 통해 위 모든 것을 단일 인터페이스로 노출하는 개발자 포털 핵심 설계 결정은 추상화 수준입니다. 날 것의 Kubernetes를 노출하면 개발자들은 Helm 차트 디버깅에 시간을 씁니다. 너무 많이 추상화하면 엣지 케이스와 비표준 워크로드에 대응하는 능력을 잃습니다. 플랫폼 팀의 역할은 수정 없이 80%의 사용 사례를 커버하는 추상화 수준을 찾고, 아래로 내려가야 하는 팀을 위한 탈출구를 문서화하는 것입니다. ![소프트웨어 개발자가 터미널에서 배포 파이프라인을 보고 있는 모습](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/upstreamapi/2026-09/29154c-inline1.webp) ## 플랫폼 엔지니어링 투자를 촉발하는 팀 규모 보편적인 임계값은 없지만, 포스트모텀과 DORA 연구는 일관된 범위를 가리킵니다. 엔지니어 30명 이하: 전담 플랫폼 팀의 오버헤드가 가치를 초과합니다. 피처 팀에 내재된 SRE 지향 엔지니어 몇 명으로 충분합니다. 30명에서 80명 사이: 개별 팀의 인지 부하가 복잡해지기 시작합니다. 배포 지식이 소수에게 집중됩니다. 온콜 로테이션이 얇아집니다. 공통 인시던트 패턴이 나타납니다. 개발자가 공유 인프라 문제, 즉 권한, 네트워킹 설정, 시크릿 순환에서 막혀 ops 담당자가 가용해질 때까지 기다립니다. 그 대기 시간이 신호입니다. 엔지니어 80명 이상: 전담 플랫폼 팀은 더 이상 선택 사항이 아닙니다. DORA State of DevOps 2025에 따르면 내부 개발자 플랫폼을 사용하는 팀은 그렇지 않은 팀보다 3.5배 더 자주 배포했고, 변경 실패율은 25% 낮았습니다. 이러한 결과는 우연히 오지 않습니다. 플랫폼이 조정 비용을 흡수했기 때문에 옵니다. ## DORA 데이터가 플랫폼 팀에 대해 말하는 것 DORA 메트릭은 활동이 아닌 결과를 측정하기 때문에 유용한 렌즈입니다. 고성능 플랫폼 팀은 지속적으로 두 개의 DORA 메트릭을 움직입니다. 배포 빈도와 변경 실패율입니다. 표준화된 배포 파이프라인은 코드가 프로덕션에 도달하는 방식의 분산을 줄입니다. SLO 위반 시 자동 롤백 게이트는 감지와 대응 사이의 시간을 압축하여 MTTR을 줄입니다. 2025 DORA 보고서는 더 미묘한 패턴도 발견했습니다. 플랫폼 도입률이 높은 팀은 계획되지 않은 작업 비율이 낮았습니다. 계획되지 않은 작업은 배포 빈도의 조용한 저하제입니다. 스프린트 속도에는 나타나지 않습니다. 팀이 출시할 계획과 실제로 출시된 것의 격차에서 나타납니다. 플랫폼 팀이 DORA에서 자주 부족한 부분은 변경 리드 타임입니다. 플랫폼을 구축하면 프로세스가 추가됩니다. 잘못 설계된 프로세스는 리드 타임을 늘립니다. 이 트레이드오프는 분기별 검토에서 사후에 발견하기보다 의도적으로 검토할 가치가 있습니다. ## 내부 플랫폼 함정: 플랫폼이 병목이 될 때 내부 플랫폼 효과는 플랫폼 엔지니어링 컨퍼런스 발표에서 아무도 이야기하지 않는 실패 모드입니다. 작동 방식은 이렇습니다. 모든 내부 사용 사례를 서비스하려는 플랫폼 팀이 점점 더 일반적인 추상화를 구축합니다. 각 새 요구 사항이 수용됩니다. 시간이 지나면서 플랫폼은 범용 인프라 시스템이 됩니다. 제한된 대역폭과 전담 온콜 로테이션 없는 소규모 팀이 유지 관리하는 Kubernetes나 Terraform의 더 나쁜 버전입니다. 결과: 대체한 오픈 소스 대안보다 느리고 사용하기 어려운 플랫폼. 플랫폼 팀은 티켓 큐가 됩니다. 프로덕션까지의 시간이 늘어납니다. 엔지니어들이 플랫폼을 우회합니다. 진단 질문: 플랫폼 팀이 제품을 구축하고 있습니까, 서비스를 구축하고 있습니까? 제품은 의견이 담긴 인터페이스를 가지고, 일부 사용 사례를 명시적으로 범위 밖으로 받아들이며, 도입률을 측정합니다. 서비스는 모든 요청을 만족시키려 하고 티켓 해결 시간으로 측정됩니다. 제품은 확장됩니다. 서비스는 그렇지 않습니다. 실용적인 테스트: 플랫폼 팀의 백로그가 플랫폼 전체 개선보다 개별 애플리케이션 팀의 일회성 요청으로 가득 차 있다면, 팀은 서비스 모드로 이탈한 것입니다. 수정 방법은 플랫폼이 지원하는 것과 지원하지 않는 것을 정의하고, 그 범위를 공개하며, 범위 밖 요청을 탈출구 문서로 리디렉션하는 것입니다. ![플랫폼 엔지니어링 마이크로서비스 아키텍처의 추상적 시각화](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/upstreamapi/2026-09/fc0645-inline2.webp) ## 셀프 서비스 vs 골든 패스: 플랫폼을 정의하는 설계 결정 이 두 용어는 관련이 있지만 동일하지 않으며, 혼동하면 잘못된 플랫폼 설계를 낳습니다. 셀프 서비스는 개발자가 티켓을 열지 않고 필요한 것을 프로비저닝할 수 있음을 의미합니다. 골든 패스는 기본적으로 보안 스캐닝, 컴플라이언스 체크, 옵저버빌리티 설정을 처리하는 코드에서 프로덕션까지의 권장되고 사전 테스트된 경로입니다. 골든 패스 없는 셀프 서비스는 규모에서 혼돈을 낳습니다. 모든 팀이 자체 배포 토폴로지를 발명합니다. 설정 오류의 blast radius가 예측 불가능해집니다. 의미 있는 셀프 서비스 없는 골든 패스는 마찰을 낳습니다. 개발자들이 모든 이탈에 대해 플랫폼 팀의 검토를 기다립니다. 플랫폼이 지원 팀이 아닌 컴플라이언스 관료제로 인식됩니다. 생산적인 조합: 대다수의 프로덕션 워크로드를 커버하는 잘 조명된 골든 패스와 이탈할 정당한 이유가 있는 팀을 위한 문서화된 탈출구. 탈출구는 승인이 아닌 서면 정당화를 요구해야 합니다. 플랫폼 팀은 분기별로 탈출구 패턴을 검토하고 도입률에 따라 골든 패스에 흡수할지 결정합니다. ## 플랫폼 팀이 결과를 내고 있는지 측정하는 방법 자신의 가치를 증명하지 못하는 플랫폼 팀은 결국 예산이 삭감되거나 피처 팀으로 흡수됩니다. 엔지니어링 리더십에서 효과가 있는 메트릭들입니다. **도입률**: 프로덕션 배포에 플랫폼의 골든 패스를 사용하는 애플리케이션 팀의 비율. 12개월 후 60% 미만의 비율은 플랫폼이 실제 문제를 해결하지 못하고 있다는 신호입니다. **배포 빈도 델타**: 플랫폼을 사용하는 팀과 여전히 자체 파이프라인을 관리하는 팀의 배포 빈도 비교. 6개월 내 양의 델타가 가장 명확한 ROI 신호입니다. **첫 번째 배포까지의 시간 (TF1D)**: 새 서비스가 플랫폼을 통해 처음으로 프로덕션에 도달하는 데 걸리는 시간. 잘 구축된 IDP는 초기 설정에서 2시간 이내에 표준 서비스를 프로덕션에 올려야 합니다. **Ops 티켓 비율**: 플랫폼 팀 작업 중 애플리케이션 팀의 요청에 응답하는 것 대 플랫폼 기능을 구축하는 것의 비율. 반응형 작업 40% 이상은 경고 신호입니다. 플랫폼이 서비스 데스크가 됐다는 뜻입니다. **P99 복구 시간**: 프로덕션에서 무언가 깨질 때 해결되거나 롤백될 때까지 걸리는 시간. SLO 기반 배포 자동화가 이 숫자에 직접 영향을 미칩니다. 새벽 3시에 수동으로 계산하고 싶지 않은 것입니다. ## 제대로 된 플랫폼 팀이 어떻게 보이는지 Series B-D 회사 (엔지니어 50-500명)의 platform engineering 팀은 일반적으로 이렇게 운영됩니다. - 아키텍처 방향을 소유하고 애플리케이션 팀 리드와 관계를 유지하는 플랫폼 리드 또는 스태프 엔지니어 - 분산 시스템, 인프라 또는 SRE 배경을 가진 시니어 엔지니어 2-4명 - 애플리케이션 엔지니어가 특정 통합 문제를 가져올 수 있는 주간 플랫폼 오피스 아워 - 플랫폼 자체에 대한 명시적인 SLA (지원 서비스뿐만 아니라) - 애플리케이션 팀 리드와 함께 검토하는 분기별 로드맵 팀은 애플리케이션 팀의 결과로 성공을 측정합니다. 배포 빈도, MTTR, 계획되지 않은 인프라 작업에 소비된 시간. 자체 인프라 업타임이 아닙니다. 투자를 시작하기 전에 물어볼 가치가 있는 질문: 애플리케이션 팀이 제품과 아무 관련 없는 인프라 문제에 스프린트 용량의 20% 이상을 소비하고 있습니까? 그렇다면 플랫폼 ROI 계산은 간단합니다. 그렇지 않다면, 해결하려는 문제가 존재하기 전에 조직 오버헤드를 구축하고 있는 것입니다. 잘 된 platform engineering은 보이지 않습니다. 포스트모텀에는 "03:47에 자동 롤백 트리거됨, 03:47에 인시던트 해결"이라고 적힙니다. 엔지니어링 매니저는 페이지를 받지 않습니다. 아무도 알아채지 못합니다. 그것이 목표입니다. ## FAQ ### Platform engineering과 DevOps의 차이는 무엇입니까? DevOps는 팀이 개발부터 프로덕션까지 소프트웨어를 소유하도록 독려하는 실천 방식과 문화적 원칙의 집합입니다. Platform engineering은 팀 토폴로지입니다. 전담 팀이 내부 사용을 위한 플랫폼을 구축하고 유지합니다. 엔지니어 80명 이하에서는 이 구분이 학문적입니다. 그 이상에서는 구조적 필요가 됩니다. ### 내부 개발자 플랫폼(IDP)이란 무엇입니까? IDP는 플랫폼 팀이 내부 사용을 위해 구축하고 유지하는 도구, 워크플로우, 추상화의 집합입니다. 일반적으로 배포 파이프라인, 서비스 카탈로그, 시크릿 매니저, 옵저버빌리티 스택 (메트릭, 로그, 트레이스), Backstage 같은 개발자 포털이 포함됩니다. ### 전담 플랫폼 팀을 언제 시작해야 합니까? 대부분의 실무 데이터는 30-80명의 엔지니어를 변곡점으로 봅니다. 30명 미만은 오버헤드가 정당화되지 않습니다. 80명 초과는 전담 플랫폼 팀이 구조적 필요가 됩니다. 선행 신호: 개발자가 공유 인프라 문제를 기다리는 대기 시간이 증가하고 있습니까? ### 플랫폼 팀이 가장 직접적으로 영향을 미치는 DORA 메트릭은 무엇입니까? 배포 빈도와 변경 실패율이 주요 레버입니다. DORA State of DevOps 2025에 따르면 IDP를 사용하는 팀은 3.5배 더 자주 배포하고 변경 실패율이 25% 낮았습니다. 잘 운영된 플랫폼 팀은 SLO 위반 시 자동 롤백을 통해 MTTR도 압축합니다. ### Platform engineering의 골든 패스란 무엇입니까? 골든 패스는 플랫폼 팀이 구축하고 유지하는 코드에서 프로덕션까지의 의견이 담긴 사전 테스트된 경로입니다. 보안 스캐닝, 컴플라이언스 체크, 옵저버빌리티 설정을 기본으로 처리합니다. 표준 서비스의 80%를 커버해야 하며, 나머지를 위한 탈출구가 있어야 합니다. ### 내부 플랫폼 효과란 무엇입니까? 플랫폼 팀이 모든 가능한 내부 사용 사례를 만족시키려 추상화를 과도하게 일반화할 때 나타납니다. 결국 대체한 기반 오픈 소스 도구보다 느리고 사용하기 어려운 시스템이 됩니다. 진단 신호: 팀 백로그가 플랫폼 개선보다 일회성 요청으로 가득 찬 경우입니다. ### 플랫폼 팀의 성과를 어떻게 측정합니까? 도입률 (60% 이상), 배포 빈도 델타 (플랫폼 사용 팀 대 비사용 팀), TF1D (첫 배포까지의 시간, 목표 2시간 이내), Ops 티켓 비율 (반응형 작업 40% 미만), P99 복구 시간이 핵심 메트릭입니다.