플랫폼 엔지니어링 02 - 내부 개발자 플랫폼의 구조

포털이 전부가 아니다

지난 포스트에서 플랫폼 엔지니어링과 IDP의 개념을 정리했다. 그렇다면 IDP의 내부는 실제로 어떻게 구성되어 있는가?

IDP는 단일 도구가 아니다. 여러 역량이 레이어로 쌓인 구조이며, 이 레이어 각각을 플레인(plane)이라고 부른다. 포털 하나를 도입했다고 해서 IDP가 완성되는 것이 아니라, 다섯 개의 플레인이 유기적으로 연결되어야 비로소 플랫폼으로서 기능하게 되는 것이다.

다섯 개의 플레인

┌─────────────────────────────────────────┐
│         개발자 인터페이스 플레인          │  ← 포털, CLI, API
├─────────────────────────────────────────┤
│        통합 및 전달 플레인               │  ← CI/CD, GitOps, 아티팩트
├─────────────────────────────────────────┤
│        리소스 관리 플레인                │  ← 컴퓨트, DB, 큐
├─────────────────────────────────────────┤
│       보안 및 거버넌스 플레인            │  ← RBAC, 정책, 컴플라이언스
├─────────────────────────────────────────┤
│         관측 가능성 플레인               │  ← 로그, 메트릭, 트레이스
└─────────────────────────────────────────┘

각 플레인이 하는 일

개발자 인터페이스 플레인은 개발자가 실제로 접촉하는 부분이다. Backstage 같은 포털이나 CLI, API가 여기에 해당하며, 서비스를 생성하고, 배포 상태를 확인하고, 문서를 찾는 곳이다. 이 플레인의 완성도가 낮으면 나머지 플레인이 아무리 뛰어나도 개발자에게 도달하지 못하기 때문에 사실상 플랫폼 전체의 가치가 떨어지게 된다.

통합 및 전달 플레인은 코드가 프로덕션에 도달하기까지의 여정을 담당한다. CI 파이프라인, 아티팩트 레지스트리, 배포 오케스트레이션, GitOps 컨트롤러가 이 플레인의 구성 요소이다. 개발자가 코드를 푸시하면 이후 과정은 자동으로 진행되는 것이 이상적인 모습이다.

리소스 관리 플레인은 인프라를 프로비저닝하는 역할을 맡는다. 데이터베이스, 메시지 큐, 스토리지 버킷, 컴퓨트 클러스터 등이 대상이며, 개발자가 인터페이스에서 요청하면 이 플레인이 실제 리소스를 생성하는 구조이다.

보안 및 거버넌스 플레인은 조직의 규칙을 적용하는 곳이다. RBAC, 네트워크 정책, 시크릿 관리, 컴플라이언스 검증이 이 플레인에서 이루어진다. 개발 속도를 유지하면서도 보안 기준을 충족시키는 것이 이 플레인의 목적이다.

관측 가능성 플레인은 피드백 루프를 완성하는 마지막 조각이다. 로그, 메트릭, 트레이스, 대시보드, 알림이 여기에 포함된다. 이 플레인이 없으면 개발자는 자신이 배포한 서비스가 어떤 상태인지 알 수 없게 되어, 말 그대로 블랙박스에 배포하는 상황에 놓이게 되는 것이다.

플레인이 연결되는 방식

개발자가 포털에서 "새 서비스 생성"을 클릭한다고 가정해 보자. 그 한 번의 클릭으로 레포가 스캐폴딩되고, CI 파이프라인이 연결되고, 데이터베이스와 네임스페이스가 프로비저닝되고, RBAC과 네트워크 정책이 적용되고, 로깅과 메트릭 수집까지 설정된다. 다섯 개 플레인이 하나의 동작으로 전부 움직이는 것이다. 개발자가 실제로 한 것은 클릭 한 번에 불과하지만, 그 뒤에서는 플랫폼 전체가 협력하여 완전한 서비스 환경을 구성하는 셈이다.

만들기 vs 사기

이 모든 것을 밑바닥부터 구축하는 조직은 없다. 진짜 의사결정은 어디까지 직접 만들고 어디부터 외부 솔루션을 도입할 것인가에 있다.

대부분의 팀은 결국 혼합 방식으로 귀결된다. CI나 모니터링처럼 범용적인 영역은 기존 제품을 구매하고, 개발자 포털이나 내부 API처럼 조직 고유의 요구사항이 있는 부분은 직접 만들고, 나머지는 오픈소스를 조합하여 채우는 것이다. 중요한 것은 처음부터 전체를 완성하려 하지 않는 것이다. 가장 마찰이 큰 워크플로 하나를 골라서 해결하고, 거기서부터 점진적으로 확장해 나가면 된다.

피해야 할 두 가지 함정

첫 번째 함정은 뒤에 아무것도 없는 포털이다. 겉으로는 깔끔한 UI를 갖추고 있지만, 실제로 인프라를 프로비저닝하는 기능이 없다면 개발자의 기대만 높여놓고 실망시키는 결과를 낳게 된다.

두 번째 함정은 인터페이스 없는 강력한 인프라이다. 자동화가 아무리 정교하더라도 개발자가 접근할 수 있는 경로가 없다면 활용되지 못한다. 결국 다시 티켓을 올리고 담당자를 기다리는 기존 방식으로 돌아가게 되는 것이다.

양쪽 모두가 갖추어져야 플랫폼으로서 의미를 가진다. 다섯 개 플레인으로 구성된 아키텍처는 현재 무엇이 구축되어 있고, 다음에 무엇을 만들어야 하며, 어디에 빈틈이 있는지를 보여주는 지도 역할을 하는 것이다.

다음 포스트에서는 모든 플랫폼 의사결정의 기준이 되어야 할 개발자 경험을 다룬다.