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

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