# 플랫폼 엔지니어링의 모든 것: 왜 필요하고, 어떻게 구축하며, 성공은 어떤 모습인가

> Clean Markdown view of GeekNews topic #29603. Use the original source for factual precision when an external source URL is present.

## Metadata

- GeekNews HTML: [https://news.hada.io/topic?id=29603](https://news.hada.io/topic?id=29603)
- GeekNews Markdown: [https://news.hada.io/topic/29603.md](https://news.hada.io/topic/29603.md)
- Type: GN+
- Author: [neo](https://news.hada.io/@neo)
- Published: 2026-05-18T09:30:02+09:00
- Updated: 2026-05-18T09:30:02+09:00
- Original source: [lucavall.in](https://www.lucavall.in/blog/platform-engineering-end-to-end)
- Points: 12
- Comments: 1

## Topic Body

- 내부 엔지니어를 사용자로 삼아 **내부 제품을 구축·운영하는 조직적 규율**로서, 단순히 DevOps 리브랜딩이나 Kubernetes 클러스터 관리와는 본질적으로 다른 영역  
- 2025 DORA 보고서에 따르면 조직의 90%가 최소 하나의 내부 플랫폼을 도입했으며, **플랫폼 품질이 AI 도구의 가치 창출 여부를 직접 예측**하는 지표로 부상  
- 클라우드와 오픈소스가 무한한 프리미티브를 제공하면서 각 팀이 제각기 파이프라인을 구축하는 **"과잉 일반화 늪(over-general swamp)"** 문제를 해결하는 것이 핵심 존재 이유  
- 플랫폼을 실제 제품으로 대하고, **중앙값 개발자를 위한 소프트웨어 추상화·메타데이터 레지스트리·운영 SLO**를 갖추는 것이 성공의 구조적 조건  
- 좋은 플랫폼은 개발자가 존재를 잊을 정도로 자연스럽게 작동하며, **나쁜 플랫폼은 AI 도구가 혼란을 증폭**시키는 반면 좋은 플랫폼은 처리량을 증폭시킴  
  
---  
  
### 플랫폼 엔지니어링이 존재하는 이유  
- ## 과잉 일반화 늪(Over-General Swamp)  
  - 클라우드와 OSS가 큐, 오브젝트 스토어, 데이터베이스, CI 러너, 서비스 메시 등 **무한한 프리미티브**를 제공하면서 각 애플리케이션 팀이 서로 다른 선택을 하게 됨  
  - 1년 후 모든 서비스가 **자체 배포 파이프라인, 재시도 로직, 모니터링 관례, 미묘하게 잘못된 IAM 바인딩**을 갖는 "글루 코드의 늪"으로 변질  
  - 선택지의 폭발과 더 높은 운영 기대치(24/7 가동, 보안, 컴플라이언스, 비용 관리)가 이 늪을 만든 두 가지 원인  
  - 실제 랜딩존 프로젝트에서 20개 팀이 VPC, IAM, 예산 알림용 **거의 동일한 Terraform 모듈을 각자 재발명**하며 각기 다른 버그를 가진 사례 존재  
- ## 플랫폼 엔지니어링이 실제로 하는 네 가지  
  - 개발자가 보는 **프리미티브를 제한**하여 큐레이션된 방식으로만 사용하도록 유도  
  - 반복적 배관 작업을 공유 서비스로 흡수해 **애플리케이션별 글루 코드를 감소**  
  - 기반 프리미티브 변경 시 플랫폼 팀이 한 번만 처리하여 **마이그레이션 비용을 중앙화**  
  - 개발자가 리눅스 커널 전문가가 되지 않고도 **자신이 만든 것을 직접 운영**할 수 있도록 지원  
  - DevOps는 "개발자가 운영을 소유하라"였고, 플랫폼 엔지니어링은 "그 운영을 위한 좋은 도구를 **실제 제품으로** 제공하겠다"는 것  
  - DORA 2025 역량 페이지에서도 **도구 카테고리가 아닌 사회기술적(sociotechnical) 규율**로 정의  
  
### 다섯 가지 기둥(Pillars)  
- ## 큐레이션된 제품 접근(Curated Product Approach)  
  - 플랫폼이 지원하는 것과 지원하지 않는 것을 **의도를 가지고 결정**  
  - 팀이 Pub/Sub 대신 Kafka를 원할 때 "문서 링크는 여기"가 아니라 "지원 범위와 이유, 맞지 않을 경우의 오프램프"를 안내  
  - **거절하는 것도 업무의 일부**  
- ## 소프트웨어 기반 추상화(Software-Based Abstractions)  
  - 플랫폼은 위키가 아닌 **소프트웨어**이며, 인터페이스는 API, CLI, SDK  
  - 개발자가 **작은 선언적 파일**을 작성하는 것만으로 프로덕션급 서비스를 프로비저닝할 수 있어야 함  
  - CNCF 산하 **Score 프로젝트**가 대표 사례로, 워크로드 스펙 하나로 데이터베이스, 토픽, 서비스 계정, 배포를 자동 프로비저닝  
    - 개발자는 내부적으로 Cloud SQL, Pub/Sub, Cloud Run인지 알 필요 없음  
- ## OSS 커스터마이징과 메타데이터 레지스트리  
  - 바닐라 Argo CD나 Backstage를 그대로 쓰지 않고, **조직에 맞는 플러그인·기본 정책·통합**을 적용해 운영  
  - 메타데이터 레지스트리(서비스 카탈로그)가 없으면 누가 무엇을 소유하고, 의존 관계가 어떻고, 실제 무엇이 실행 중인지 **파악 불가**  
  - **Backstage**가 이 레이어의 사실상 표준 OSS 프레임워크로, 270개 이상 조직이 프로덕션에서 운영  
    - CNCF가 Certified Backstage Associate, Certified Cloud Native Platform Engineering Associate 인증을 출시  
    - Backstage, Port, Cortex 등 무엇을 사용하든 "어떤 서비스가 존재하고, 누가 소유하며, 의존 관계는 무엇인지"에 대한 **단일 진실 원천(single source of truth)** 필요  
- ## 광범위한 사용자 기반 서비스  
  - 내부 플랫폼은 소수의 매우 목소리 큰 고객을 보유하지만, **중간값(median) 개발자의 중간값 작업**을 잘 지원하는 것이 목적  
  - 엘리트 사용자만을 위해 구축하면 나머지 팀이 플랫폼을 우회하면서 **섀도우 플랫폼**이 탄생  
- ## 파운데이션으로 운영  
  - 플랫폼이 다운되면 회사가 다운되므로 **24/7 온콜, 실제 SLO, 실제 변경 관리, 지원 부담**이 수반  
  - "도구"가 아닌 **"바닥(floor)"** 역할이며, 위에 구축되는 모든 것이 바닥이 견딘다고 가정  
  
### 시작 시기와 방법  
- ## 플랫폼 팀을 너무 일찍 만들지 말 것  
  - 엔지니어 10명 규모에서는 플랫폼 팀이 아닌 **협력(cooperation)** 이 필요  
    - 한 명이 배포 스크립트, 다른 한 명이 Terraform을 관리하고, 관례에 합의하면 충분  
  - 1~2명으로 너무 일찍 팀을 구성하면 그들이 **티켓 큐**가 되고 나머지 조직은 수동적으로 변함  
  - 보통 엔지니어 **50명 이후**, 다수의 배포 대상이 생기고 "새 서비스 배포 방법"에 대한 정답을 아무도 모를 때 팀 구성이 적절  
- ## 기존 인프라 조직 전환  
  - 인프라/SRE 팀을 플랫폼 조직으로 전환할 때 가장 어려운 부분은 기술이 아닌 **문화**  
  - 인프라 담당자는 "안 된다"의 게이트키퍼 역할에 익숙하지만, 플랫폼 담당자는 **"쉬운 예스를 제공하는 사람"** 이 되어야 함  
    - 고객과 많이 대화하기  
    - 운영자뿐 아니라 **도구 구축을 즐기는 소프트웨어 엔지니어** 채용·육성  
    - "새 클러스터 배포"보다 "200개 팀을 5% 빠르게 만들었다"가 인정받도록 **보상 체계 갱신**  
  - PM을 위에 뿌리고 끝내는 것이 가장 흔한 실패 모드이며, 이는 플랫폼이 아닌 **연극(theater)** 을 만들어냄  
  
### 플랫폼 팀 구축  
- ## 네 가지 역할  
  - **Software Engineer**: API, SDK, 포털 등 플랫폼의 제품 표면 구축  
  - **Systems Engineer**: Kubernetes, Linux, 네트워킹, 클라우드 컨트롤 플레인 등 기반 프리미티브에 정통  
  - **Reliability Engineer**: 운영 품질, 온콜, SLO, 관측성에 집중  
  - **Systems Specialist**: 데이터베이스, 보안, 네트워킹 등 깊은 도메인 전문가  
  - 소프트웨어 집중이 과하면 아름다운 포털이 실제 부하에서 무너지고, 시스템 집중이 과하면 **견고한 클러스터를 아무도 티켓 없이 사용 불가**  
- ## 채용  
  - **고객 공감(customer empathy)** 을 최우선으로 채용해야 함  
  - 좌절한 앱 개발자와 통화 후 문제를 명확히 이해하고 나올 수 없는 엔지니어는 적합하지 않음  
  - 공감 없는 기술적 탁월함은 **정확하지만 아무도 쓰지 않는 플랫폼**을 만들어냄  
  - 소프트웨어 역할에는 동일한 레벨 매트릭스를 쓰되, 시스템 스페셜리스트는 시장 가치와 스킬이 소프트웨어 엔지니어 래더에 깔끔하게 매핑되지 않으므로 **유연한 직함** 허용  
- ## 관리자 및 기타 역할  
  - 훌륭한 플랫폼 엔지니어링 관리자의 세 가지 공통 특성: **실제 플랫폼 운영 경험**, 장기 멀티쿼터 프로젝트 배포 경험, **디테일에 대한 집착**  
    - 플랫폼은 디테일에 보상을 주며, 드물어 보여 건너뛴 1% 케이스가 지원 시간의 80%를 차지  
  - PM, 테크니컬 라이터, 개발자 애드보킷, 지원 엔지니어 모두 중요하지만 **엔지니어링 팀이 충분히 성숙한 후에** 채용  
  - 4명 플랫폼 팀에 조기 투입된 PM은 **로드맵 모양의 의자**가 될 뿐  
  
### 제품으로서의 플랫폼  
- ## 내부 고객은 더 어려움  
  - 내부 고객은 **이탈이 어려운 캡티브 사용자**이며, 강한 의견과 약한 제품 감각을 가짐  
  - 원하는 것(want)을 말하지만 실제로 필요한 것(need)과 다른 경우가 많음  
  - 플랫폼이 자신의 일을 대신 해주길 요구하지, 일을 잘 할 수 있는 도구를 요구하지 않음  
  - 그들 옆에 앉아 하나의 변경을 배포하기 위해 **몇 번 컨텍스트 스위칭을 하는지** 관찰하는 것이 실제 백로그  
- ## 디스커버리, 로드맵, 실패 모드  
  - 플랫폼 디스커버리는 A/B 테스트가 아닌 **파일럿**으로 수행하며, 친화적 팀과 실제 배포 후 리드 타임 감소를 측정  
  - 로드맵의 네 가지 시간 지평  
    - **Vision**(다년): 플랫폼의 방향  
    - **Strategy**(연간): 올해의 베팅  
    - **Goals and Metrics**(분기~연간): 성공의 정의  
    - **Milestones**(분기): 실제 배포 대상  
  - 자주 팀을 무너뜨리는 실패 모드  
    - **마이그레이션 비용 과소평가** (항상 예상의 2~3배)  
    - 사용자의 새 기능에 대한 **변경 예산 과대평가**  
    - 안정성이 실제 문제인데 **기능 추가**에 집중  
    - 엔지니어링 팀 규모 대비 **PM이 너무 많음** (엔지니어 5명에 PM 2명이면 문제)  
  
### 플랫폼 운영  
- ## 온콜은 선택이 아님  
  - 파운데이션으로 운영하므로 **24/7 커버리지는 비협상 사항**  
  - "만든 사람이 운영한다(you build it, you run it)"가 여기서도 적용되며, 이는 처벌이 아닌 **피드백 루프**  
  - 단일 엔지니어가 주당 수회 이상 페이지를 받으면 **스케줄이 아닌 시스템을 수정**해야 함  
  - 번아웃된 플랫폼 엔지니어는 나쁜 플랫폼을 배포  
- ## 지원: 업무의 숨겨진 절반  
  - 컨퍼런스에서 거의 다루지 않는 영역이지만 플랫폼 엔지니어링의 **핵심 절반**  
  - 네 단계 프레임워크  
    - 1단계: 지원 레벨 공식화 (P0 vs P3, 응답 시간 등)  
    - 2단계: 비중요 지원을 온콜과 분리하여 "CronJob 추가 방법" 질문이 **누군가를 깨우지 않도록** 함  
    - 3단계: 볼륨이 정당화되면 **전담 지원 스페셜리스트** 채용  
    - 4단계: 규모에 맞는 **엔지니어링 지원 조직** 구축  
  - 1단계를 건너뛰면 엔지니어가 시간의 절반을 **Slack DM 응답**에, 나머지 절반을 **불만**에 소비  
- ## 운영 피드백  
  - **SLO와 SLA**는 필수이며, 에러 버짓은 유용하지만 선택 사항  
  - **Synthetic 모니터링**이 사용자가 티켓을 제출하기 전에 실패 모드를 포착  
  - Operational 리뷰는 녹색 대시보드를 흘끗 보는 것이 아닌 **실제 데이터 검토를 강제**  
  - DORA 2025 데이터에서 사용자 경험과 가장 높은 상관관계를 보인 플랫폼 역량은 **작업 결과에 대한 명확한 피드백** — 실패 시 무엇이 실패했고 어떻게 해야 하는지 사용자가 정확히 알아야 함  
  
### 계획과 전달  
- ## 장기 프로젝트에는 제안 문서가 필요  
  - 마이그레이션, 리아키텍처, 새 컨트롤 플레인 등 플랫폼 프로젝트는 **분기 단위**로 소요  
  - 좋은 제안서의 필수 요소: 해결하려는 문제, 수혜자, 범위, **명시적으로 범위 밖인 것**, 성공의 정의  
  - 코드 작성 전에 문서를 먼저 쓰고 리뷰받은 후 **구체적 마일스톤이 있는 실행 계획**으로 전환  
  - "장기 수렁(long slog)" 실패 모드 — 프로젝트가 수년간 끌리고 아무도 이유를 기억하지 못함 — 는 **거의 항상 이 단계를 건너뛴 결과**  
- ## 바텀업 로드맵 계획  
  - 플랫폼 로드맵의 네 가지 업무 유형: **KTLO(keep-the-lights-on)**, 리더십 명령, 자체 결정 시스템 개선, 직접적 고객 요청  
  - 고객 수요만으로 순위를 매길 수 없으며, **KTLO가 1순위, 명령이 2순위**, 나머지는 이해관계자와 솔직한 논의 필요  
- ## 격주 성과와 도전(Biweekly Wins and Challenges)  
  - 2주마다 짧은 문서 작성: 배포한 것(성과), 막힌 것(도전), 짧고 공개적이며 과장 없이  
  - 세 가지 동시 효과: 팀이 **진행 상황을 명확히 표현**, 이해관계자에게 **실제 상황 전달**, 도전을 조기에 노출해 **리더십 지원 유도**  
  - 성과만 있는 문서는 **아무도 신뢰하지 않는 문서**이므로 도전을 생략하지 말 것  
  
### 리아키텍처와 마이그레이션  
- ## v2 대신 리아키텍처  
  - 플랫폼이 낡았을 때 "v2를 만들자"는 본능은 **거의 항상 오답**  
  - v2 프로젝트 실패 이유: v1 투자 동결, 예상보다 긴 소요 시간, v2 마이그레이션 비용이 회피한 리아키텍처 비용보다 높음  
  - 기존 플랫폼 내에서 리아키텍처하고, 가능한 한 **호환성을 유지**하며, 하위 환경·느린 롤아웃·트랜치 기반 마이그레이션 활용  
  - 네 가지 계획 단계  
    - 최종 아키텍처 목표를 **크게 사고**  
    - 마이그레이션 비용 반영 (항상 2~3배)  
    - 지속 투자를 정당화하는 **12개월 주요 성과** 식별  
    - 리더십 동의 확보, 기다릴 준비  
- ## 보안은 아키텍처적  
  - 구축 후에 보안을 덧붙이는 것은 불가능하며, 아키텍처가 설계 시점부터 **최소 권한, 격리, 추적 가능성**을 강제해야 함  
  - 모든 팀이 올바른 IAM 바인딩을 기억해야 하는 플랫폼이라면, 팀이 아니라 **플랫폼에 버그가 있는 것**  
- ## 마이그레이션: 과소평가되는 어려운 문제  
  - 가장 흔한 안티패턴  
    - 모든 팀에게 클립보드와 데드라인을 주고 **스스로 마이그레이션하라고 요구**  
    - 명확한 온램프·오프램프 없이 **명령만 내리기**  
    - 특이 사용 사례의 **롱 테일 과소평가**  
  - 쉬운 마이그레이션 엔지니어링 방법  
    - 사용 메타데이터를 추적해 **구 버전 사용자를 정확히 파악**  
    - 200개 팀이 마이그레이션해야 하면 앱 팀이 아닌 **플랫폼 팀이 스크립트를 작성**  
    - 새 시스템이 구 API를 사용하는 **투명한 마이그레이션** 아키텍처 설계  
    - 새 팀이 셀프서비스할 수 있을 정도로 **온램프를 명확히 문서화**  
  - 명령(mandate)은 한두 번만 효과가 있으며, 그 이후엔 소음이 됨  
  - 대부분의 경우 새 경로를 충분히 좋게 만들어 **구 경로가 자연히 시들도록** 하는 것이 최선  
- ## 서비스 종료(Sunsetting)  
  - 제품을 없애는 것을 두려워하지 말 것  
  - 반쯤 지원되는 배포 시스템 7개보다 **견고한 배포 시스템 1개**가 우월하며, 서비스 종료는 성숙한 팀의 특성  
  
### 이해관계자 관계  
- ## 파워-관심 그리드(Power-Interest Grid)  
  - 이해관계자를 **권한(power)과 관심도(interest)** 두 축으로 매핑  
    - 높은 권한·높은 관심: 정기 업데이트와 협의  
    - 낮은 권한·낮은 관심: 상태 페이지로 충분  
  - 관심 낮은 VP에게 Kubernetes 업그레이드 정보를 제공하며 **팀 시간 낭비 금지**  
- ## 과잉 공유 없는 소통  
  - 투명하되 과하지 않게 — 시니어 리더는 세 가지 gRPC 재시도 전략 논쟁이 아닌, **마일스톤 달성 여부와 리스크**를 알아야 함  
  - 1:1 미팅을 신중하게 활용하고 기대치·약속을 **보이는 곳에 추적**  
- ## 관계를 망치지 않고 거절하기  
  - "이 기능을 추가하면 마이그레이션이 한 분기 밀리며, 이는 회사에 $X 비용"처럼 **비즈니스 임팩트를 명확히**  
  - "타협과 함께 예스", "거절하되 경로 제시", 때로는 **섀도우 플랫폼을 허용**하는 것이 싸우는 비용보다 나을 수 있음  
  - 예산 시즌에는 인원별이 아닌 **팀·역량 단위로 묶어** 제시하고, 무엇을 줄이고 유지할지 강한 의견을 가져야 함 — 그렇지 않으면 **재무 부서가 대신 결정하며 잘못 결정**  
  
### 성공의 모습  
- ## 정렬된 플랫폼(Aligned)  
  - 목적 정렬(왜 존재하는지), 전략 정렬(베팅이 팀 간 일관), **계획 정렬(마일스톤 충돌 없음)** 필요  
  - 런타임 팀은 모두 Kubernetes를 원하고 관측성 팀은 모든 프레임워크를 지원하려 할 때 **정렬 불일치** 발생  
    - 상충하는 고객 가이드, 중복 작업, 중간에 낀 분노한 개발자로 표면화  
    - 합의(consensus)가 아닌 **원칙 있는 리더십**으로 해결  
- ## 신뢰받는 플랫폼(Trusted)  
  - 신뢰는 천천히 쌓이고 **단 한 번의 나쁜 마이그레이션으로 상실**  
  - 운영 방식(장애 시 소통, 약속 이행), 투자 방식(판매한 큰 베팅 실제 배포), **전달 우선순위**에서 신뢰 형성  
  - "과결합 플랫폼(overcoupled platform)" 사례: 지나치게 많은 커스텀 로직을 플랫폼에 넣어 모든 변경에 수개월 소요 — 해결책은 추가 엔지니어링이 아닌 **범위에 대한 가정 도전**  
    - 때로 신뢰 문제는 너무 적게가 아니라 **너무 많이 하고 있기 때문**  
- ## 복잡성을 관리하는 플랫폼  
  - 소프트웨어 복잡성은 불가피하나, **우발적 복잡성(accidental complexity)** 은 아님  
  - 환원 불가능한 문제 복잡성과 인간 조정의 부실, 같은 문제를 두 번 푸는 섀도우 플랫폼, 무한 성장이 만드는 **우발적 복잡성을 구분**  
  - 세 가지 실용적 레버  
    - **성장 통제**: 모든 것을 지원하는 플랫폼은 아무것도 잘 지원하지 못함, 범위를 명시  
    - **제품 디스커버리**를 무엇을 추가할지뿐 아니라 **무엇을 중단할지** 파악에 활용  
    - **섀도우 플랫폼 관리**: 팀이 병렬 솔루션을 만들면 플랫폼에 실제 부족한 것이 있거나 누군가 영역 확장 중이라는 신호 — 둘 다 대응 필요  
- ## 사랑받는 플랫폼(Loved)  
  - 세 가지 형태  
    - **"그냥 작동하는" 사랑**: 대부분의 사용자가 플랫폼을 인식하지 못하고, 배포가 되고, CI가 통과 — **지루한 것이 최고의 칭찬**  
    - **"해킹 같은" 사랑**: 별도 설명 없이 명백히 올바른 동작을 하는 CLI 커맨드 같은 **작은 기쁨**  
    - **"명백한" 사랑**: 설문 점수, 리텐션, 유기적 채택, 다른 팀에 플랫폼을 추천  
  - 플랫폼이 사랑받으면 예산 요청 시 사람들이 **대신 싸워주지만**, 단순 허용이면 한 번의 나쁜 인시던트로 **대체될 위기**  
  
### 실전 우선순위  
- 제로부터 시작하거나 재구축할 때의 대략적 순서  
  - 1순위: 지원 범위를 결정하고 **문서화하며 방어**  
  - 2순위: 위키가 아닌 **소프트웨어 추상화에 투자** (Score, Crossplane, 자체 SDK 등 실제 API가 있는 소프트웨어)  
  - 3순위: **메타데이터 레지스트리** 구축 (Backstage 등으로 무엇이 어디서 실행되고 누가 소유하는지 파악)  
  - 4순위: 가장 시끄러운 팀이 아닌 **중간값 팀을 위해 구축**  
  - 5순위: SLO, 온콜, 지원 티어 등 **운영을 일급 기능으로** 취급  
  - 6순위: 시스템 역량만큼 **공감 능력을 기준으로 채용**  
  - 7순위: 격주 성과·도전, 투명한 로드맵, 솔직한 이해관계자 관리 등 **무자비한 소통**  
  - 8순위: 필요 없는 것을 **종료, 통합, 거절**  
- DORA 데이터와 일관되게, 플랫폼 품질은 **AI 채택을 포함한 모든 것의 배수** — 나쁜 플랫폼은 AI 도구가 혼란을 증폭, 좋은 플랫폼은 처리량을 증폭  
- **로켓을 만들기 전에 바닥을 먼저 만들어야 함**

## Comments



### Comment 57708

- Author: kalista22
- Created: 2026-05-18T14:43:43+09:00
- Points: 1

내부 소통이 무엇보다 중요하다고 생각합니다.