플랫폼 엔지니어링 — 내부 개발자 플랫폼(IDP)이 데브옵스의 다음인 이유

몇 년 전만 해도 "데브옵스(DevOps)"가 모든 조직도의 유행어였다. 지금 그 자리를 플랫폼 엔지니어링(Platform Engineering)이 이어받는 분위기다. 핵심 개념은 이렇다. 개발자가 인프라의 복잡함과 직접 씨름하지 않도록, 내부 개발자 플랫폼(IDP)이라는 잘 닦인 길을 팀이 만들어 제공하는 것이다.

나는 "데브옵스를 도입했다"는 조직에서 개발자가 쿠버네티스 YAML, 테라폼, CI 파이프라인을 전부 손수 다루느라 정작 제품 코드를 못 짜는 광경을 자주 봤다. 모두가 모든 걸 알아야 한다는 이상은 현실에서 병목이 됐다. 플랫폼 엔지니어링은 그 반작용에서 나왔다.

데브옵스는 실패했나

그렇게 단정할 순 없다. 데브옵스가 심은 문화—자동화, 협업, 빠른 피드백—는 지금도 살아 있다. 다만 "개발자가 운영까지 다 책임진다"는 대목이 규모가 커지면 무너졌다. 인지 부하가 감당할 수 없이 커지기 때문이다. 클라우드, 쿠버네티스, 보안, 관측성까지 한 사람이 다 깊이 알기란 불가능에 가깝다.

플랫폼 엔지니어링은 이 부하를 재분배한다. 반복되는 복잡함은 플랫폼 팀이 한 번 풀어 제품으로 만들고, 나머지 개발자는 그 위에서 빠르게 움직인다. 데브옵스의 다음 단계라기보다, 데브옵스를 지속 가능하게 만드는 운영 방식에 가깝다.

여기서 열쇠가 되는 개념이 인지 부하(cognitive load)다. 사람이 한 번에 감당할 수 있는 복잡성에는 한계가 있다. 개발자가 도메인 로직에 쏟아야 할 집중력을 인프라의 세부에 빼앗기면, 결국 제품의 속도와 품질이 함께 떨어진다. 플랫폼 엔지니어링은 "모두가 모든 걸 안다"는 이상을 버리고, 복잡함을 감당할 사람과 몰라도 되는 사람을 명확히 나눈다. 이 분업이 규모가 커진 조직에서 속도를 되찾아주는 핵심이다.

IDP는 무엇으로 이뤄지나

골든 패스(golden path)

가장 중요한 개념이다. "이렇게 하면 배포·모니터링·보안이 알아서 챙겨지는" 표준 경로를 미리 깔아두는 것이다. 개발자는 벗어나고 싶으면 벗어날 수 있지만, 대부분은 잘 닦인 길을 따라가는 게 편하니 자연스럽게 표준화가 이뤄진다. 강제가 아니라 유인으로 통일하는 방식이다.

셀프서비스 인터페이스

새 서비스를 만들거나 환경을 띄우는 일을 티켓 없이 스스로 처리한다. 개발자 포털이나 CLI, API로 노출하는 경우가 많다. "인프라 팀에 요청하고 며칠 기다리는" 병목을 없애는 게 목표다.

도입할 때 흔히 하는 오해

가장 큰 오해는 "도구를 사면 끝"이라는 생각이다. 개발자 포털 하나 띄워놓는다고 플랫폼이 되지는 않는다. 핵심은 그 플랫폼을 제품처럼 다루는 태도다. 내부 개발자를 고객으로 보고, 그들이 실제로 뭘 불편해하는지 듣고, 로드맵을 세워 개선해야 한다. 아무도 안 쓰는 포털은 그저 또 하나의 유지보수 부담일 뿐이다.

규모도 고려해야 한다. 개발자가 몇 명뿐인 조직이라면 전담 플랫폼 팀을 두는 게 과할 수 있다. 이 접근은 팀이 여럿으로 늘어나고 중복되는 인프라 작업이 눈에 띄게 쌓일 때 진가를 발휘한다. 작을 땐 얇게 시작해 필요에 따라 키우는 편이 현명하다.

자주 묻는 질문

플랫폼 엔지니어링이 데브옵스를 대체하나요?

대체라기보다 진화에 가깝다. 데브옵스의 문화와 자동화를 유지하되, 개발자의 인지 부하를 플랫폼 팀이 덜어주는 구조로 재편한 것이다. 두 개념은 대립하지 않는다.

내부 개발자 플랫폼은 꼭 직접 만들어야 하나요?

아니다. 오케스트레이션·포털·배포 도구를 조합해 구축하는 경우가 많고, 상용·오픈소스 구성요소를 엮어 쓴다. 처음부터 거대하게 만들기보다 골든 패스 하나부터 시작하는 게 낫다.

작은 스타트업에도 필요한가요?

초기에는 과할 수 있다. 팀이 하나뿐이면 표준화의 이득이 크지 않다. 다만 여러 팀이 비슷한 인프라 작업을 중복으로 하고 있다면, 그때가 도입을 고민할 시점이다.