Platform-Engineering

오늘의 기술 토픽 Platform Engineering 이번 브리프는 최근 클라우드 네이티브 생태계에서 핵심 화두로 떠오른 Platform Engineering을 중심으로 정리한 내용이다. 개발자가 인프라 세부사항을 몰라도 셀프서비스로 필요한 리소스를 프로비저닝할 수 있게 만드는 것이 핵심 목표이며, 이를 위해 Internal Developer Platform(IDP), GitOps, Kubernetes 기반 추상화 도구들이 함께 언급된다. 실제 밋업 발표는 없었으나, 관련 기술들을 초심자 관점에서 소개하고 학습 방향을 제시한다. 🔑 핵심 요점 Platform Engineering은 개발자 생산성을 높이기 위해 인프라를 ‘제품’처럼 설계하고 운영하는 접근 방식이다. 핵심 목표는 개발자가 티켓을 넣지 않고도 셀프서비스로 환경과 리소스를 얻을 수 있게 하는 것이다. Backstage 같은 IDP 툴은 서비스 카탈로그와 셀프서비스 포털 역할을 한다. Kubernetes는 플랫폼 엔지니어링의 사실상 표준 실행 기반으로 자리잡았다. Crossplane 같은 도구는 클라우드 리소스를 Kubernetes API로 추상화해 셀프서비스 프로비저닝을 가능하게 한다. GitOps는 플랫폼 변경 사항을 코드로 관리하고 자동 배포하는 표준 운영 방식으로 자리잡고 있다. 🛠 핵심 기술 쉽게 이해하기 Platform Engineering Platform Engineering은 조직 내부의 개발자들이 애플리케이션을 더 빠르고 안전하게 배포할 수 있도록 인프라와 툴체인을 ‘내부 제품’처럼 설계하고 운영하는 분야다. 단순히 인프라를 관리하는 것을 넘어, 개발자 경험(Developer Experience)을 최우선으로 고려한다. ...

오늘의 기술 토픽 Internal Developer Platform (IDP) Internal Developer Platform(IDP)은 개발자가 인프라 세부사항을 몰라도 셀프서비스로 애플리케이션을 배포하고 운영할 수 있도록 플랫폼 엔지니어링 팀이 제공하는 통합 도구 모음입니다. 쿠버네티스와 클라우드 인프라가 복잡해지면서 개발자의 인지 부하를 줄이고 배포 속도를 높이기 위한 목적으로 등장했습니다. Backstage 같은 개발자 포털, Crossplane 같은 인프라 추상화 도구, Argo CD 같은 GitOps 배포 도구가 IDP의 핵심 구성 요소로 자주 함께 언급됩니다. 최근에는 플랫폼을 하나의 내부 ‘제품’으로 취급하며 개발자 경험(DX)을 개선하는 방향으로 발전하고 있습니다. ...

오늘의 기술 토픽 Platform Engineering 이번 자료는 실제 밋업 발표 대신, 최근 개발자 커뮤니티에서 화두인 Platform Engineering을 중심으로 정리한 압축 브리프입니다. Platform Engineering은 개발자가 인프라나 배포 과정을 직접 신경 쓰지 않고도 빠르게 서비스를 만들 수 있도록, 셀프서비스 플랫폼을 구축하는 접근 방식을 말합니다. Backstage, Crossplane, Kubernetes 같은 도구들이 이 플랫폼을 구성하는 대표적인 조각으로 함께 다뤄집니다. 전체 흐름은 ‘플랫폼을 하나의 제품처럼 만들어 내부 개발자에게 제공한다’는 방향으로 수렴합니다. 🔑 핵심 요점 Platform Engineering은 개발자 경험(DevEx)을 개선하기 위해 내부 플랫폼을 하나의 제품처럼 설계하고 운영하는 접근이다. 핵심 목표는 개발자가 인프라 복잡도를 직접 다루지 않고도 셀프서비스로 배포/운영할 수 있게 만드는 것이다. Backstage 같은 개발자 포털은 여러 도구와 문서를 한곳에 모아 플랫폼 사용성을 높이는 역할을 한다. Crossplane은 클라우드 리소스를 Kubernetes API로 선언적으로 관리해 플랫폼 자동화의 기반이 된다. Kubernetes는 대부분의 Platform Engineering 사례에서 표준 실행 환경으로 자리잡고 있다. 골든 패스(golden path)를 제공해 팀마다 다른 방식으로 인프라를 다루는 혼란을 줄이는 것이 중요한 흐름이다. 🛠 핵심 기술 쉽게 이해하기 Platform Engineering Platform Engineering은 개발팀이 애플리케이션을 더 쉽고 빠르게 만들고 배포할 수 있도록, 별도의 플랫폼팀이 셀프서비스 도구와 표준 워크플로우를 설계하는 조직적/기술적 접근입니다. 단순히 인프라를 자동화하는 것을 넘어, 플랫폼 자체를 하나의 내부 제품처럼 관리한다는 점이 특징입니다. ...

오늘의 기술 토픽 Infrastructure as Code with Crossplane 이번 글에서는 실제 밋업 발표 대신, Crossplane을 중심으로 한 Infrastructure as Code(IaC) 생태계를 정리한다. Crossplane은 Kubernetes API를 확장해 클라우드 리소스를 선언적으로 관리할 수 있게 해주는 도구로, Terraform과 같은 전통적 IaC 도구와 비교되며 최근 플랫폼 엔지니어링 진영에서 주목받고 있다. Crossplane과 함께 자주 언급되는 Argo CD, Terraform, Kubernetes Operator 패턴을 함께 살펴보고, 이 생태계가 어디로 향하고 있는지 정리한다. 🔑 핵심 요점 Crossplane은 Kubernetes Custom Resource와 Controller 패턴을 이용해 클라우드 인프라를 코드로 관리하는 오픈소스 프로젝트다. 기존 Terraform이 CLI와 상태 파일 기반이라면, Crossplane은 Kubernetes API 서버를 통해 리소스를 선언적으로 관리한다는 차이가 있다. Crossplane의 Composition 기능을 사용하면 여러 클라우드 리소스를 하나의 커스텀 API로 추상화해 팀 내부에 제공할 수 있다. Argo CD와 결합하면 GitOps 방식으로 인프라 변경 사항을 자동 배포할 수 있다. 플랫폼 엔지니어링 트렌드에서 Crossplane은 ‘내부 개발자 플랫폼(IDP)‘을 만드는 핵심 빌딩 블록으로 자리잡고 있다. 처음 시작할 때는 Provider 설치와 간단한 Managed Resource 생성부터 연습하는 것이 좋다. 🛠 핵심 기술 쉽게 이해하기 Crossplane Crossplane은 Kubernetes API를 확장하여 AWS, GCP, Azure 같은 클라우드 리소스를 Kubernetes 커스텀 리소스처럼 선언적으로 정의하고 관리할 수 있게 해주는 오픈소스 프로젝트다. Kubernetes를 다뤄본 사람이라면 익숙한 YAML 매니페스트로 인프라를 표현할 수 있다. ...

플랫폼 엔지니어링, 이제는 선택이 아니다 플랫폼 엔지니어링은 이미 산업 표준이 되었다. Broadcom(VMware)의 Pankaj Gupta와 Platform Engineering의 Sam Barlien이 공동 집필한 Platform Engineering 2.0 백서에 따르면 대부분의 조직이 이미 내부 개발 플랫폼(IDP)을 도입했고, 다수는 전담 플랫폼 팀까지 운영하고 있다. 문제는 ‘도입 여부’가 아니라 ‘무엇을 위한 플랫폼인가’로 바뀌었다는 점이다. 2022~2023년의 플랫폼 엔지니어링 1.0은 애플리케이션 개발자의 인지 부하(cognitive load)를 줄이고 golden path를 표준화하는 데 초점을 맞췄지만, platformengineering.org의 소개 글이 지적하듯 이 모델은 AI 워크로드, 자율 에이전트, 다중 페르소나 조직을 전혀 상정하지 않은 채 설계됐다. ...

📋 밋업 한눈에 보기 이 밋업은 Sam과 Pankaj가 최근 발표한 리포트를 바탕으로 platform engineering이 어떻게 진화하고 있는지 다뤘다. 기존 platform engineering 1.0이 애플리케이션 개발자의 인지 부하 감소에만 집중했던 것과 달리, AI 에이전트·데이터 과학자·보안팀 등 새로운 페르소나가 늘어나면서 플랫폼이 그에 맞춰 확장돼야 한다는 점을 강조했다. AI-native 플랫폼, 다중 페르소나 지원, 임베디드 FinOps, security shift-down, composable 설계라는 다섯 가지 기둥으로 platform engineering 2.0을 정의했고, Q&A에서는 DevOps 엔지니어의 역할 변화, 에이전트 페르소나의 필요성, FinOps 적용 범위 등이 논의됐다. ...

DevOps 다음은 왜 플랫폼 엔지니어링인가 DevOps는 애플리케이션 팀에게 인프라를 직접 다룰 자유를 줬지만, 그 대가로 모든 팀이 YAML과 IAM, 네트워크 정책을 각자 재발명하는 ‘인지 부하 폭증’을 낳았다. 이 문제를 해결하기 위해 등장한 것이 플랫폼 엔지니어링이다. CNCF는 이를 “플랫폼 팀이 제공하는 능력의 계층으로, 제품 팀이 하부 인프라에 대한 깊은 전문성 없이도 서비스를 빌드·배포·운영할 수 있게 하는 것"이라 정의하며, 골든 패스(Golden Path)를 “가드레일이지 게이트가 아니다"라고 못박는다 (CNCF Platforms White Paper). 실제로 DORA의 2025 State of AI-assisted Software Development 보고서에 따르면 조직의 90%가 내부 개발자 플랫폼(IDP)을 이미 운영 중이고 76%는 전담 플랫폼 팀을 두고 있다. 더 중요한 발견은, AI 도입률이 90%에 달하는 지금 AI는 그 조직의 기존 엔지니어링 시스템을 ‘증폭’할 뿐이라는 점이다. 플랫폼이 부실하면 AI도 그 부실함을 그대로 증폭시킨다. ...

📋 밋업 한눈에 보기 Akamai의 플랫폼 엔지니어가 500개 이상의 클러스터와 8000개 이상의 애플리케이션을 운영하는 사내 Internal Developer Platform 아키텍처를 소개한 발표다. DevOps 셀프서비스 피로에서 platform engineering이 어떻게 태동했는지, 관리 클러스터(SRE 소유)와 애플리케이션 클러스터(서비스 팀 소유)를 Argo CD와 Crossplane으로 GitOps하게 관리하는 구조, Kyverno·Cilium·Istio로 구현한 zero-trust 보안, 그리고 kagent를 활용한 AI 트러블슈팅 실험까지 다뤘다. 발표 후에는 플랫폼 버전 관리, 업그레이드 전략, 책임 분담 모델에 대한 활발한 질의응답이 이어졌다. 🔑 핵심 요점 Platform engineering은 각 팀이 개별적으로 YAML, IAM, 티켓 프로세스를 배워야 했던 DevOps 셀프서비스의 피로에서 출발했다. 플랫폼을 ‘제품’으로, 내부 개발자를 ‘고객’으로 취급하고 문서화와 피드백 루프, 채택률을 성공 지표로 삼는 것이 핵심 원칙이다. 관리 클러스터와 애플리케이션 클러스터를 분리하고, Argo CD와 Crossplane으로 전체 인프라와 애플리케이션을 GitOps 방식으로 관리한다. Kyverno로 정책을 강제하고 Cilium과 Istio로 네트워크 계층의 zero-trust(세그멘테이션, mTLS)를 구현하며, RBAC은 OIDC/SSO와 연동된다. 플랫폼 컴포넌트 전체를 하나의 버전으로 번들링해 배포하며, 업그레이드와 롤백도 git commit 단위로 이루어진다. kagent 같은 AI 에이전트를 도입해 자연어로 클러스터 상태를 질의하고 진단하는 실험을 진행 중이다. DORA 리포트를 인용하며 플랫폼 엔지니어링 도입이 소프트웨어 딜리버리 성과와 개발자 생산성 향상에 실제로 기여한다고 설명했다. 🛠 핵심 기술 쉽게 이해하기 Argo CD Git 저장소에 선언된 상태를 기준으로 Kubernetes 클러스터를 자동으로 동기화해주는 GitOps 배포 도구다. 사람이 직접 kubectl apply를 실행하는 대신, 컨트롤러가 Git의 변경 사항을 감지해 클러스터에 반영한다. ...