CNCF Ambassador이자 Platform Engineering TCG 조직자인 Atulpriya Sharma는 플랫폼 엔지니어링에서 더 중요한 질문은 조직이 플랫폼을 구축했는지가 아니라 개발자들이 실제로 그 기능과 어떻게 상호작용하는지라고 본다. 아직 공식 플랫폼이 없는 조직은 대개 흩어진 스크립트와 개인의 지식에 의존하는 반면, 다른 조직은 개발자 포털과 CLI 인터페이스, 미리 정의된 경로를 갖추고도 여전히 요청을 수작업으로 처리할 수 있다. 두 경우 모두 문제의 핵심은 팀이 플랫폼 기능을 소비하는 인터페이스의 성숙도에 있다.
이 글은 CNCF 플랫폼 엔지니어링 성숙도 모델을 바탕으로 한다. 이 모델은 투자, 도입, 인터페이스, 운영, 측정의 다섯 가지 측면을 독립적으로 평가한다. 각 측면에는 임시적, 운영적, 확장 가능, 최적화의 네 단계가 있다. 모델에 따르면 조직은 하나의 단위로 함께 발전하지 않는다. 한 측면에서는 앞서가면서 다른 측면에서는 뒤처질 수 있다. 이 분석은 개발자가 사용하는 모델, CLI 인터페이스, 포털, API 등 인터페이스 측면에 초점을 맞춘다.
플랫폼 인터페이스의 네 단계
첫 번째 단계에서 조직은 사용자 지정 절차에 의존한다. 수작업 요청, 팀마다 다른 프로세스, 사람에서 사람으로 전수되는 지식이 이에 해당한다. 플랫폼에 공식 명칭이 없다고 해서 실제로 플랫폼이 존재하지 않는 것은 아니다. 특정 엔지니어에게 데이터베이스 설정을 반복해서 요청하는 메시지는 관리되지 않는 형태일지라도 현재 플랫폼의 인터페이스를 나타낸다.
두 번째 단계는 표준화된 도구다. 여기서는 골든 패스 또는 포장된 경로, 그리고 기능을 제공하고 모니터링하기 위한 일관된 문서, 템플릿, 인터페이스가 등장한다. 결과는 대체로 긍정적으로 보인다. 도입률이 높아지고, 신규 직원의 온보딩이 빨라지며, 지표가 개선된다. 하지만 예상된 경로를 벗어나는 요청은 여전히 플랫폼 팀의 개입을 필요로 한다. 따라서 인터페이스는 통일되어 있지만 셀프서비스 방식으로 완결되지는 않는다.
세 번째 단계에서는 셀프서비스 솔루션이 등장한다. 개발자는 대부분의 일상적인 요청을 플랫폼 팀을 거치지 않고 처리할 수 있다. 이 단계는 지표에만 의존하기보다 팀의 행동을 측정한다. 일상적인 프로비저닝 티켓이 줄어들고, 신규 엔지니어가 플랫폼을 직접 사용하기 시작하며, 플랫폼 팀의 업무는 개별 요청을 실행하는 일에서 요청을 관리하는 프레임워크를 개선하는 일로 전환된다. 저자가 제시한 사례에 따르면, 일부 조직은 셀프서비스 구성 옵션을 추가한 뒤 예외 요청이 40%에서 60%까지 감소했다고 보고했다.
네 번째 단계인 통합 서비스에서는 플랫폼 기능이 일상적인 업무 도구의 투명한 일부가 된다. 새로운 서비스를 만들 때 모니터링, 로깅, 보안이 자동으로 통합될 수 있으며, 보안 정책은 개발자에게 수작업으로 협상하도록 요구하는 대신 플랫폼을 통해 규칙을 적용한다. 플랫폼은 거의 보이지 않게 되고, 개발자가 인프라를 생각해야 하는 일이 얼마나 드문지가 성공의 척도가 된다.
조직은 왜 두 번째 단계에서 멈추는가?
분석은 반복적으로 나타나는 네 가지 문제를 제시한다. 첫 번째는 대기열 문제다. 골든 패스는 일반적인 상황을 다루지만, 대규모 조직에서는 예외적인 상황이 업무의 30%를 차지할 수 있다. 저자는 한 소매 조직의 사례를 제시한다. 이 조직은 Helm 차트와 ArgoCD를 사용해 Kubernetes를 배포하는 골든 패스를 도입했고, 6개월 만에 도입률이 85%에 도달했다. 그러나 40건의 예외 사례가 누적되면서 팀은 업무 시간의 60%를 경로 밖의 구성에 사용하게 됐다.
두 번째는 전문성 격차다. 플랫폼 팀이 범용 기능을 구축하더라도 전문 팀의 요구에 정확히 맞지 않을 수 있으며, 이로 인해 해당 팀들은 자체 대안을 개발하게 된다. 세 번째는 유지보수의 함정이다. 새로운 기능 하나하나가 업데이트, 테스트, 그리고 취약점이 발견되거나 Kubernetes가 업그레이드될 때의 수정 작업을 위한 추가 표면을 의미한다. 저자는 오래된 Helm 차트 인터페이스, 클라우드 제공업체별 의존성, 네트워크 가정이 누적되어 업데이트 자체가 위험해진 사례를 언급한다.
네 번째 문제는 경직성이다. 골든 패스는 설계 당시에는 타당했던 가정을 반영하지만, 기술과 프로세스, 팀의 요구가 변화하면 제약으로 바뀔 수 있다. 그러면 예외와 섀도 인프라가 늘어나고, 플랫폼 팀은 기본 인터페이스를 개선하는 대신 개별 솔루션을 생산하는 공장으로 변한다.
실제로 무엇이 달라지는가?
첫 번째 단계에서 두 번째 단계로 이동하려면 새로운 포털을 구축하기 전에 이미 존재하는 것을 명명하라고 저자는 제안한다. 가장 빈번하고, 시간이 많이 들며, 표준화 가능성이 높은 요청을 파악한 뒤, 카탈로그를 확장하기 전에 하나의 골든 패스를 실제로 개선해야 한다.
두 번째 단계에서 세 번째 단계로 이동하려면 플랫폼 팀이 반드시 거쳐야 하는 인간 연결 고리로 남는 것을 중단해야 한다. 이를 위해 골든 패스를 구성 가능하게 만들고, 검증된 옵션과 정책으로 강제되는 제약을 제공해야 한다. 고정된 값을 사용하는 대신 정당한 사례를 위한 출구도 마련해야 한다. 또한 분석은 요청을 자동화하기 전에 측정할 것을 권고한다. 미디어 부문의 한 사례에서는 3개월 동안 요청을 기록한 결과 요청 유형의 20%가 전체 물량의 80%를 차지한다는 사실이 발견됐다. 이 유형을 우선 셀프서비스로 구축하자 6개월 동안 적체가 60% 감소했다.
또한 인터페이스를 제품으로 다뤄야 하며, 백엔드 기능만을 제품으로 보아서는 안 된다. 검색 가능성, 검증 규칙, 계약, 예상하지 못한 요청을 처리하는 방식은 모두 제품의 일부다. 네 번째 단계에 가까워지면 자동화는 개발자가 선택해 실행하는 방식에서 벗어나 Git, 개발 환경, CI/CD 시스템 내부의 정책에 의해 적용되는 지능형 기본값으로 이동한다. 동시에 보안, 데이터베이스, 모니터링 팀 사이에서 기능의 소유권을 명확한 계약에 따라 분배해야 한다.
certi.news의 해석
이 글이 주목하는 실제 변화는 개발자 플랫폼의 성공 기준이 출시된 도구와 경로의 수에서 사용자가 얻는 자율성의 정도로, 다시 이러한 기능이 업무 흐름에 얼마나 깊이 통합되는지로 이동한다는 점이다. 이는 플랫폼 팀에 중요하다. 겉으로는 도입률을 높이면서도 실행 부담을 예외와 유지보수의 대기열로 이전할 수 있기 때문이다.
다만 여기 제시된 사례와 수치는 저자가 조직들과의 상호작용에서 얻은 관찰로 제시한 것이며, 동일한 비율이 모든 조직에 적용된다는 것을 입증하는 독립적인 정량 연구는 아니다. 또한 네 번째 단계에 도달하려면 계약과 정책, 소유권 분배의 성숙도가 필요하며, 포털을 구매하거나 AI 에이전트를 추가하는 것만으로는 이러한 요소를 제공할 수 없다. 결론은 중요한 열린 질문을 제기한다. 개발자를 위해 설계된 셀프서비스 인터페이스가 반드시 AI 에이전트가 소비할 수 있는 인터페이스인 것은 아니다. AI 에이전트는 인간의 업무 흐름과 다른 빈도와 패턴으로 API를 다룬다. 따라서 기계가 소비할 수 있는 인터페이스의 성숙도가 플랫폼 팀이 다음 단계에서 측정해야 할 대상이 될 수 있다.