플랫폼 엔지니어링: 개발자에게 '포장된 길'을 깔아주는 일

들어가며: "Hello World 하나 띄우는 데 3주"

어느 회사에 개발자가 입사했다. 실력은 좋다. 첫 임무는 간단하다. 작은 API 서비스 하나를 프로덕션에 올리는 것.

이 이야기가 남 얘기 같지 않다면, 당신은 이미 플랫폼 엔지니어링이 풀려는 문제를 몸으로 알고 있는 것이다.

같은 일을 다른 회사에서는 이렇게 한다.

이 두 장면의 차이를 만드는 일. 그게 플랫폼 엔지니어링(Platform Engineering) 이다.

이 글은 그 말이 정확히 무슨 뜻이고, 왜 하필 지금 나왔으며, 2026년 AI 에이전트의 시대에 왜 오히려 더 중요해졌는지를 처음부터 끝까지 따라간다.

1장. 한 문장 정의 — 그리고 도로 이야기

2018년, Thoughtworks의 에반 보처(Evan Bottcher)가 이 개념에 처음 쓸 만한 정의를 붙였다.

"셀프서비스 API, 도구, 서비스, 지식, 그리고 지원의 기반(foundation)을, 매력적인 사내 제품(compelling internal product)으로 엮어놓은 것."

문장이 길지만 핵심은 세 단어다.

도로 비유가 이 개념을 거의 다 설명한다

국가가 국민에게 이렇게 말한다고 생각해 보자. "이동의 자유를 드립니다. 차도 직접 만들고, 길도 직접 뚫으세요."

말은 자유롭지만 결과는 참혹하다. 모두가 각자 진흙탕에 바퀴 자국을 내고, 아무도 목적지에 제때 못 간다. 그래서 현실의 국가는 고속도로를 깔고, 차선을 긋고, 가드레일을 치고, 표지판을 세운다.

그러면 운전자는 '길 뚫기'가 아니라 '운전' 에만 집중할 수 있다. 그리고 결정적으로 — 고속도로를 반드시 타야 하는 건 아니다. 국도로 갈 수도 있고, 산길로 갈 수도 있다. 다만 그렇게 하면 시간과 위험을 본인이 감당한다.

플랫폼 팀은 회사 안의 도로공사팀이다. 개발자가 "내 서비스"라는 차를 몰고 목적지(프로덕션)까지 가는 길을 깔아주는 사람들.

2장. 왜 이 말이 나왔나 — 20년짜리 사건 기록

플랫폼 엔지니어링은 어느 날 갑자기 발명된 개념이 아니다. 좋은 아이디어가 현실에서 부작용을 일으켰고, 그 부작용을 고치려는 시도로 나왔다. 그 인과를 순서대로 따라가 보자.

2-1. 벽 너머로 던지기 (2000년대 초)

옛날 IT 조직에는 뚜렷한 벽이 있었다. 한쪽에는 개발(Dev), 다른 쪽에는 운영(Ops).

개발팀의 목표는 변화다. 새 기능을 빨리 내보내야 성과가 난다. 운영팀의 목표는 안정이다. 아무 일도 안 일어나야 성과가 난다. 두 팀의 인센티브가 정면으로 충돌한다.

그래서 개발팀은 코드를 짜서 "벽 너머로 던지고(throw it over the wall)" 잊어버렸다. 새벽 3시에 서버가 죽으면 깨는 건 운영팀이었다. 운영팀은 방어적으로 배포를 막았다. 배포 주기가 분기 단위로 늘어났다.

2-2. 아마존의 선언 (2006)

아마존 CTO 베르너 보겔스(Werner Vogels)가 이 벽을 부수는 한 문장을 던졌다.

"You build it, you run it." — 만든 사람이 운영한다.

새벽 3시에 깨는 사람이 코드를 짠 사람이라면, 그 사람은 깨지 않을 코드를 짜게 된다. 보겔스는 "개발자에게 운영 책임을 준 것이 서비스 품질을 크게 끌어올렸다"고 회고했다. 아마존이 거대한 모놀리스를 분산 서비스 플랫폼으로 쪼개고 폭발적으로 확장할 수 있었던 조직적 뿌리가 여기다.

2-3. 데브옵스의 탄생 (2009)

2009년, 오라일리 벨로시티 콘퍼런스에서 Flickr의 존 올스포(John Allspaw)와 폴 해먼드(Paul Hammond)가 "하루에 10번 이상 배포하기: Flickr의 Dev와 Ops 협력" 이라는 발표를 했다. 당시로선 충격적인 숫자였다.

이 발표를 영상으로 본 벨기에의 컨설턴트 패트릭 드보아(Patrick Debois) 가 "이건 이름이 필요하다"고 생각했고, 2009년 10월 벨기에 겐트에서 첫 DevOpsDays 를 열었다. 그가 홍보용으로 만든 트위터 해시태그가 #DevOps 였다.

2-4. 그 사이, PaaS의 첫 시도 (2007~2011)

한편 다른 쪽에서는 아예 인프라를 감춰버리는 시도가 있었다. Heroku(2007) 다.

git push heroku main

이 한 줄이면 배포가 끝났다. 마법 같았다. Heroku 엔지니어들은 여기서 얻은 교훈을 12-Factor App(2011) 이라는 12가지 원칙으로 정리했고, 이건 지금도 유효한 고전이다.

하지만 큰 조직은 Heroku를 쓰지 않았다. 이유는 두 가지였다.

• 통제 불가: 규제, 데이터 주권, 네트워크 정책, 비용 구조를 회사 맘대로 못 바꾼다.
• 탈출구 없음: 요구사항이 PaaS의 상상 밖으로 나가는 순간 방법이 없다.

그래서 회사들은 다시 클라우드의 원시 자원(raw primitives) 으로 돌아갔다. 통제권은 되찾았다. 대신 복잡도도 통째로 되찾았다.

2-5. 쿠버네티스, 그리고 복잡도 폭발 (2014~2020)

2014년 구글이 쿠버네티스를 오픈소스로 공개한다. 컨테이너 오케스트레이션의 사실상 표준이 됐다. 그리고 그 주변에 CNCF 생태계가 폭발적으로 자란다 — 서비스 메시, GitOps, 시크릿 관리, 정책 엔진, 관측성, 수백 개.

쿠버네티스 전도사였던 켈시 하이타워(Kelsey Hightower)가 남긴 유명한 문장이 있다.

"쿠버네티스는 플랫폼을 만들기 위한 플랫폼이다. 더 나은 출발점이지, 종착점이 아니다."

문제는 많은 조직이 이 '출발점'을 개발자에게 그대로 던졌다는 것이다. 그리고 여기서 데브옵스의 아름다운 이상이 배신당한다.

2-6. 진짜 진단이 나오다 — 인지 부하 (2019)

여기서 결정적인 개념이 등장한다. 인지 부하(cognitive load) 다.

원래 교육심리학 용어다. 1988년 존 스웰러(John Sweller)가 정리한 이론인데, 사람의 작업 기억은 용량이 정해져 있고 그 용량은 세 종류로 나뉘어 소모된다.

크게 보기

2019년, 매튜 스켈튼(Matthew Skelton)과 마누엘 파이스(Manuel Pais)가 《팀 토폴로지(Team Topologies)》 를 출간한다. 이 책이 플랫폼 엔지니어링의 이론적 뼈대를 세웠다.

책의 핵심 주장은 이렇다. 팀의 인지 부하가 한계를 넘으면, 아무리 좋은 사람을 뽑아도 흐름(flow)이 멈춘다. 그러니 조직 설계의 목표는 "각 팀의 인지 부하를 감당 가능한 수준으로 유지하는 것"이어야 한다.

그리고 네 가지 팀 유형을 제시했다.

플랫폼 팀의 존재 이유가 여기서 딱 한 문장으로 정의된다. "스트림 정렬 팀의 외재적 인지 부하를 흡수하는 것."

이 책은 또 하나의 중요한 용어를 만들었다. TVP(Thinnest Viable Platform, 최소 존속 플랫폼) — 플랫폼은 거대할 필요가 없다. 잘 관리된 위키 한 페이지도 플랫폼일 수 있다.

2-7. 이름이 붙고, 산업이 되다 (2019~2023)

3장. 놓치면 안 되는 핵심 개념 7가지

① IDP — 플랫폼(Platform)과 포털(Portal)은 다르다

같은 약자 IDP가 두 가지를 가리켜서 헷갈린다.

포털만 있고 플랫폼이 없으면 예쁜 링크 모음집이 된다. 플랫폼만 있고 포털이 없으면 강력하지만 아무도 찾지 못한다. 둘 다 필요하다.

② 골든 패스 / 포장된 길 — 강제가 아니라 기본값

Spotify는 골든 패스(Golden Path), Netflix는 포장된 길(Paved Road) 이라 부른다. 이름은 다르지만 철학은 같다.

Spotify의 정의가 명료하다. 골든 패스란 "의견이 담겨 있고(opinionated), 지원되는(supported) 경로" 다. 이 두 단어가 다 중요하다.

• 의견이 담겨 있다 = 선택지를 줄여준다. "언어 뭐 쓰지?"라는 고민을 대신 해준다.
• 지원된다 = 그 길로 가면 누군가가 뒤를 봐준다. 문제가 생기면 도와줄 팀이 있다.

그래서 이 길을 벗어나는 건 금지되지 않는다. 다만 벗어나는 순간 지원이 사라지고, 그 운영 부담을 스스로 진다. 그것만으로 대부분은 길 위에 남는다.

③ 플랫폼 = 제품 (Platform as a Product)

이게 플랫폼 엔지니어링과 '이름만 바꾼 운영팀'을 가르는 가장 결정적인 기준이다.

여기서 나오는 유명한 진단이 있다. "티켓 큐로 돌아가는 플랫폼 팀은, 이름만 바꾼 공유 서비스 팀이다."

④ 셀프서비스 — 사람이 끼어드는 순간 병목이다

문서가 아무리 훌륭해도, 새 환경 하나 만드는 데 누군가의 승인이 필요하면 그건 셀프서비스가 아니다. 플랫폼의 가치는 "대기 시간이 0에 수렴하는가"로 측정된다.

⑤ 가드레일 vs 게이트 — 이 차이가 문화를 결정한다

"프로덕션 DB에 공개 IP를 붙이려 하면 배포가 실패한다" — 이건 가드레일이다. 사람을 기다리지 않고, 규칙은 코드에 적혀 있으며, 실패 메시지가 왜 안 되는지와 대안을 알려준다.

⑥ TVP — 작게 시작하라

《팀 토폴로지》의 Thinnest Viable Platform 은 플랫폼 엔지니어링에서 가장 실용적인 조언일지도 모른다.

플랫폼을 시작할 때 가장 흔한 실패는 "2년짜리 사내 Heroku 프로젝트" 를 기획하는 것이다. 2년 후 완성되면, 그때는 아무도 그걸 원하지 않는다.

TVP는 정반대다. "지금 가장 아픈 것 하나만, 지금 할 수 있는 가장 얇은 방법으로." 잘 관리된 위키 한 페이지, 스크립트 하나, 잘 만든 템플릿 레포 하나 — 그것도 플랫폼이다.

⑦ 역콘웨이 법칙 — 팀 구조가 아키텍처를 만든다

콘웨이의 법칙(1967): "시스템 구조는 그것을 만든 조직의 소통 구조를 닮는다."

역콘웨이 전략은 이걸 뒤집는다. 원하는 아키텍처가 있으면, 그 아키텍처에 맞게 팀을 먼저 배치하라. 플랫폼 팀을 만드는 것 자체가 이미 아키텍처적 결정이다.

4장. 실제로 어떻게 작동하는가 — 사례들

사례 1. Spotify — 파편화와 싸운 이야기

Spotify는 자율적인 스쿼드(squad) 문화로 유명했다. 각 팀이 스스로 기술을 고른다. 이 자유가 혁신을 낳았지만, 규모가 커지자 끔찍한 부작용을 낳았다.

Spotify의 답이 골든 패스 + Backstage 였다.

골든 패스는 영역별로 만들어졌다 — 백엔드, 클라이언트, 데이터 엔지니어링, 데이터 사이언스, 머신러닝, 웹, 오디오 처리. 각 영역에 "이렇게 하면 됩니다"라는 지원되는 경로가 하나씩 생겼다.

그리고 그 경로를 실행 가능한 형태로 만든 것이 Backstage의 Scaffolder 다.

숫자로 본 결과는 이렇다.

Spotify는 2020년 Backstage를 오픈소스로 공개했고, 이후 CNCF에 기부했다. 2026년 1월 기준 3,400개 이상의 조직과 Spotify 외부의 200만 명 이상의 개발자가 쓴다. Netflix, IKEA, American Airlines, Expedia, HBO Max, Zalando, HelloFresh, Peloton, Unity, Splunk 같은 이름이 여기에 있다.

사례 2. Netflix — 자유와 책임, 그리고 포장된 길

Netflix의 문화는 "자유와 책임(Freedom & Responsibility)" 이다. 강제하지 않는다. 그러면 플랫폼은 어떻게 성립할까?

Netflix의 답은 우아하다. 강제하는 대신, 포장된 길을 압도적으로 편하게 만든다.

Netflix의 포장된 길에는 마이크로서비스 RPC, 서비스 디스커버리와 등록, OS 이미지, 애플리케이션 런타임, 설정 관리, 메트릭, 로깅, 트레이싱, 대시보드, 알림, 스트림 처리가 들어 있다. CD 도구인 Spinnaker 는 그중 가장 유명한 조각이다.

특히 흥미로운 건 보안 접근이다. Netflix 앱보안 팀은 "보안 리뷰를 더 많이 하기"로 확장하지 않았다. 대신 안전한 기본값을 포장된 길에 미리 깔았다. 개발자가 골든 패스를 타면 보안 검토를 따로 통과할 필요가 거의 없다 — 이미 안전한 방식으로 만들어지기 때문이다.

사례 3. 아디다스 — 숫자가 가장 선명한 사례

아디다스는 플랫폼 엔지니어링 효과가 숫자로 가장 또렷하게 남은 사례다.

이전: 개발자가 개발용 VM 하나를 받으려면 — 잘 풀리면 30분, 나쁘면 반 주에서 일주일. 서비스 릴리스 주기는 4~6주.

이후:

주목할 점: 아디다스가 해결한 것은 "기술적으로 불가능했던 문제"가 아니다. 원래도 가능했지만 매번 며칠씩 걸리던 일을, 몇 분으로 만든 것뿐이다. 그 차이가 릴리스 주기를 40배 이상 압축했다.

사례 4. 그리고 실패담 — 이게 더 중요하다

가트너의 유명한 예측은 이렇다. 2026년까지 대형 소프트웨어 조직의 80%가 플랫폼 엔지니어링 팀을 갖게 된다 (2022년 45% → 2025년 55% → 2026년 80%).

그런데 이 예측에는 훨씬 덜 인용되는 단서 조항이 붙어 있다.

5곳 중 4곳이 만들지만, 3곳 중 1곳도 성과를 못 낸다. 왜 그럴까? 실패 패턴은 놀라울 만큼 반복적이다.

5장. 2026년 — 플랫폼의 사용자가 사람만이 아니게 되었다

여기서부터가 지금 이 시점의 이야기다.

크게 보기

5-1. "코드 작성 비용이 0이 된다"는 착시

AI 코딩 에이전트가 보편화되면서, 자연스러운 의문이 생겼다.

"AI가 뭐든 뚝딱 만들어주는데, 재사용 가능한 사내 플랫폼을 왜 굳이 만들지? 그냥 팀마다 필요할 때 에이전트한테 만들어달라고 하면 되잖아?"

2026년 에반 미거(Evan Meagher)가 이 질문에 정면으로 답한 글을 썼다. 논지는 간결하다.

"코드 작성 비용이 0으로 간다"는 전제 자체가 틀렸다. 비용은 극적으로 떨어졌다. 하지만 0이 아니다. 토큰은 실제 자원을 소모하고, 예산은 여전히 유한하다.

그렇다면 레버리지의 경제학은 하나도 안 변했다.

미거는 한 가지 아이러니도 지적한다. 똑같은 AI가 정반대의 두 주장에 동원된다는 것.

• 재사용에 찬성: "AI가 인기 프레임워크의 베스트 프랙티스를 잘 아니까, 유명한 걸 써야 AI가 잘 도와준다."
• 재사용에 반대: "AI가 만들어주니까, 프레임워크 없이 우리 것만 만들면 된다."

둘 다 그럴듯하게 들린다. 하지만 토큰 비용을 계산에 넣는 순간 균형이 한쪽으로 기운다.

5-2. DORA 2025 — AI는 거울이다

구글 클라우드의 DORA 보고서는 소프트웨어 전달 성과 연구의 가장 신뢰받는 축이다. 2025년판의 결론은 플랫폼 엔지니어링 논의에 결정적인 데이터를 제공한다.

특히 흥미로운 세부 발견이 하나 있다. DORA 2025 데이터에서 개발자 경험과 가장 강하게 상관된 플랫폼 역량은 화려한 기능이 아니었다. 그건 "내 작업의 결과에 대해 명확한 피드백을 준다" 였다.

좋은 로그, 좋은 진단, 좋은 에러 메시지. 개발자가 사람을 부르지 않고 스스로 문제를 풀 수 있게 하는 것.

그리고 이 발견은 다음 이야기로 정확히 이어진다.

5-3. 인지 부하 = 컨텍스트 윈도우

여기가 이 글에서 가장 하고 싶은 이야기다.

2019년 팀 토폴로지가 진단한 인간의 인지 부하와, 2026년 우리가 씨름하는 에이전트의 컨텍스트 예산은 — 같은 문제의 두 얼굴이다.

5-4. 에이전트를 위한 플랫폼 — 무엇이 달라지는가

2026년 CNCF는 이 변화를 "에이전틱 엔터프라이즈를 위한 플랫폼 엔지니어링" 이라는 이름으로 정리했다. 핵심 주장은 이렇다.

기존의 내부 개발자 플랫폼은 하나의 가정 위에 세워졌다 — "사용자는 사람이다." 그 가정이 깨졌다.

AI 에이전트는 이제 레포를 읽고, PR을 열고, 인프라를 조회하고, 장애를 트리아지하고, 배포 워크플로를 트리거한다. 즉 에이전트는 플랫폼의 1급 사용자가 되었다.

여기서 두 가지 중요한 변화가 일어난다.

변화 1 — 관리 대상이 넓어진다. 예전에는 '애플리케이션'이 유일한 1급 객체였다. 이제는 리소스(데이터베이스, 스토리지, API, AI 모델, 시크릿)와 에이전트 자체가 각각 자기 수명주기·소유권·거버넌스를 가진 1급 객체가 된다.

변화 2 — 인터페이스는 갈라지되 거버넌스는 하나여야 한다. 사람은 포털과 CLI로, 에이전트는 MCP 서버로 접근한다. 하지만 "누가 무엇을 할 수 있는가" 라는 규칙은 하나여야 한다. 그렇지 않으면 에이전트가 조직의 정책 우회로가 된다.

5-5. 그래서 2026년의 플랫폼 팀이 실제로 하는 일

6장. 그래서 우리 조직은 어디서 시작하나

여기까지 읽고 "우리도 해야겠는데"라는 생각이 들었다면, 가장 하지 말아야 할 일부터 말하겠다. 2년짜리 사내 PaaS 구축 프로젝트를 기획하지 마라. 그건 거의 항상 실패한다.

우리 플랫폼이 진짜인지 확인하는 7가지 질문

마치며: 60년 된 경제학의 새 이름

플랫폼 엔지니어링은 새로운 기술이 아니다. 새로운 도구 카테고리도 아니다.

그것은 레버리지라는, 소프트웨어 공학이 60년간 붙들고 있던 오래된 아이디어에 붙은 새 이름이다. 한 번 잘 만들어서 여러 번 쓰자. 서브루틴이 그랬고, 라이브러리가 그랬고, 프레임워크가 그랬고, 클라우드가 그랬다.

그리고 매번 같은 반론이 나왔다. "이제 만드는 게 쉬워졌으니 재사용은 필요 없다." 매번 틀렸다. 만드는 비용이 떨어질 때마다 사람들은 더 많이 만들었고, 그래서 조율 비용이 새로운 병목이 되었기 때문이다.

2026년에도 같은 일이 벌어지고 있다. AI 덕분에 코드는 값싸졌다. 그 결과 코드는 훨씬 더 많아졌다. 그러면 무엇이 희소해지는가?

• 무엇이 어디 있는지 아는 것
• 무엇이 안전한지 아는 것
• 무엇이 이미 존재하는지 아는 것
• 그리고 그 지식을 사람과 기계 모두에게 값싸게 전달하는 것

이것이 정확히 플랫폼 팀의 일이다.

다시 도로 이야기로 돌아가자. 좋은 도로의 미덕은 화려함이 아니다. 아무도 도로에 대해 생각하지 않아도 목적지에 도착한다는 것이다. 훌륭한 플랫폼도 같다. 개발자가 "우리 플랫폼 좋네"라고 감탄하는 순간보다, 플랫폼의 존재를 잊고 자기 문제에만 몰두하는 순간이 진짜 성공이다.

2026년에 달라진 건 딱 하나다.

그 길 위를 달리는 것이, 이제 사람만이 아니라는 것.

참고 자료

• Evan Meagher, "Platform engineering still matters", 2026 — 이 글의 출발점
• Matthew Skelton & Manuel Pais, Team Topologies: Organizing Business and Technology Teams for Fast Flow, IT Revolution, 2019
• Evan Bottcher, "What I Talk About When I Talk About Platforms", martinfowler.com, 2018
• Platform Engineering 커뮤니티, "The story of platform engineering"
• Spotify Engineering, "How We Use Golden Paths to Solve Fragmentation in Our Software Ecosystem", 2020
• Backstage by Spotify — CNCF 프로젝트, 내부 개발자 포털
• Netflix Technology Blog, "Scaling Appsec at Netflix" — 포장된 길과 보안
• InfoQ, "The Paved PaaS to Microservices at Netflix", QCon New York 2017
• Kubernetes.io, adidas Case Study
• Google Cloud, 2025 DORA Report — State of AI-assisted Software Development
• DORA, Capabilities: Platform engineering
• CNCF, "Platform engineering for the agentic enterprise", 2026
• Gartner, Platform Engineering topic page
• CNCF TAG App Delivery, Platforms White Paper
• John Allspaw & Paul Hammond, "10+ Deploys per Day: Dev and Ops Cooperation at Flickr", O'Reilly Velocity, 2009
• Werner Vogels, "A Conversation with Werner Vogels" (ACM Queue, 2006) — "You build it, you run it"