Finops

플랫폼 엔지니어링, 이제는 선택이 아니다 플랫폼 엔지니어링은 이미 산업 표준이 되었다. 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 적용 범위 등이 논의됐다. ...

왜 지금 ‘현대화’가 FinOps의 화두인가 클라우드 지출과 AI 인프라 비용이 동시에 급증하면서, FinOps Foundation은 2026년 프레임워크에 ‘AI 기술 카테고리’와 ‘Executive Strategy Alignment’를 새로 추가했다. FinOps.org의 2026 프레임워크 개편 안내에 따르면, FinOps는 이제 단순 비용 최적화 기능을 넘어 경영진과 투자 결정을 연결하는 전략 파트너로 확장되고 있다. 그 안에서도 VM(가상머신) 현대화, 즉 오래된 인스턴스 패밀리를 최신 세대로 교체하는 작업은 여전히 가장 손쉽게 실현 가능한 절감 기회로 꼽힌다. 가격이 아니라 ‘단위 작업당 비용’으로 봐야 한다 신형 인스턴스는 시간당 요금이 더 비싸 보이는 경우가 많다. 하지만 SPEC CPU2017 같은 표준 벤치마크로 정규화하면 순위가 뒤집힌다. Google Cloud 팀이 실제로 SPEC CPU2017을 GCP 머신 패밀리 전반에 적용해 분석한 시리즈 벤치마크는, 가격/성능 비율이 세대와 아키텍처에 따라 크게 달라짐을 보여준다. 즉 ‘시간당 얼마’가 아니라 ‘요청당·작업 단위당 얼마’로 봐야 진짜 절감 폭이 드러난다. ...

📋 밋업 한눈에 보기 이 밋업은 클라우드 VM(가상머신)을 구형 인스턴스에서 신형 인스턴스로 교체하는 ‘VM 모더나이제이션’을 엔지니어링과 FinOps(재무 운영) 양쪽 관점에서 어떻게 접근해야 하는지를 다뤘다. 발표자는 What(무엇을 옮길지), When(언제 옮길지), Worth(그만한 가치가 있는지)라는 3단계 프레임워크를 제시하며, 리스트 가격이 아닌 실제 협상 요율과 커밋먼트(약정 할인) 만료 시점을 함께 고려해야 진짜 절감액을 알 수 있다고 강조했다. Google Cloud의 N2에서 N4로의 업그레이드 사례를 들어 spend-based commitment와 resource-based commitment 전략을 비교했고, ProsperOps가 만든 무료 가격 비교 도구인 VMPricify도 시연했다. Q&A에서는 하이퍼스케일러의 신형 하드웨어 용량 부족 문제, 온프레미스-투-클라우드 전환과의 차이, AI 시대 FinOps 프레임워크 확장 등이 논의됐다. ...