• 내부 엔지니어를 사용자로 삼아
  내부 제품을 구축·운영하는 조직적 규율로서, 단순히 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 도구가 혼란을 증폭, 좋은 플랫폼은 처리량을 증폭
  로켓을 만들기 전에 바닥을 먼저 만들어야 함

댓글과 토론