최근 기술 블로그나 컨퍼런스에서 자주 등장하는 키워드를 하나 꼽으라면 플랫폼 엔지니어링(Platform Engineering)을 고르고 싶다.
개발과 운영을 하나의 흐름으로 한다는 DevOps의 중심 철학은 이미 보편적으로 인정되어 널리 퍼졌다. 하지만 마이크로서비스 아키텍처(MSA)가 보편화되고 클라우드 네이티브 생태계가 커지면서 개발자들의 부담은 점점 더 무거워졌다.
Kubernetes 설정부터 CI/CD 파이프라인, 모니터링, 보안 스캔 등 복잡한 인프라와 도구들 속에서 헤매는 데에 개발자가 더 많은 에너지를 쏟을 위험이 생기는 것이다. 물론 생성형 AI가 개발자의 작업을 보조해주는 경우가 많겠지만, 그렇다고 개발자가 느끼는 부담이 완전히 사라졌다고 말할 수는 없을 것이다.
개발자가 비즈니스 로직을 구현하는 과정에서 그 본질적인 업무 외에 추가로 알아야 하거나 신경 써야 하는 모든 부담을 인지 부하(Cognitive Load)라고 한다. 플랫폼 엔지니어링을 이야기할 때마다 인지 부하라는 개념이 함께 등장하곤 한다. 왜냐고?
복잡한 인프라와 도구를 잘 정리된 인터페이스 뒤로 숨겨 개발자의 인지 부하를 줄이는 것이 플랫폼 엔지니어링의 목표이기 때문이다.
IDP(Internal Developer Platform)는 플랫폼 엔지니어링 방법론을 기술적으로 구현하기 위해 등장한 시스템이다. 이름에서 알 수 있듯이 사내 개발자들이 사용하는 플랫폼이며, 개발 작업을 할 때 사용하는 툴과 인프라를 한 곳에서 접근할 수 있도록 만들어진 인터페이스이다. 보통은 웹 인터페이스로 구현된다.
플랫폼 엔지니어링으로 시작해서 개발자의 인지 부하, 그리고 IDP까지 살펴봤는데, 만약 IDP를 구현한다고 하면 어떤 툴을 사용해야 할까?
가장 먼저 검토해야 할 프로젝트는 단연 Backstage다. 그래서 이번 아티클에서는 CNCF가 관리하고 있는 대표적인 오픈소스 IDP 프레임워크 Backstage에 대해 알아보겠다.
1. CNCF에서 관리되는 Backstage
Backstage는 음악 스트리밍 전문 업체 Spotify가 CNCF에 기증한 이후, 현재 인큐베이팅(Incubating) 단계에서 관리되고 있는 프로젝트다.
보통 CNCF 프로젝트들은 졸업(Graduated) 단계에 이르러서야 업계의 ‘사실상 표준’으로 인정받는 경향이 있다. 하지만 Backstage는 예외적이다.
(출처: Spotify for Backstage)
Spotify의 발표에 따르면, Backstage는 2025년 IDP 시장에서 67% 비중을 차지했다고 한다. IDP를 제공하는 기타 SaaS 제품의 비중이 9%인 점을 보면 이미 ‘사실상 표준’에 가까운 수준인 것이다. 조직에서 IDP를 자체 구축(Homegrown)하는 비율이 13%인 것을 보더라도 Backstage의 비중은 유의미하다.
더욱이 주목할 점은 Backstage를 대하는 CNCF의 태도다. CNCF는 Backstage가 아직 졸업 전임에도 불구하고, 이례적으로 CBA(Certified Backstage Associate)라는 공식 인증 자격증 시험을 주관하고 있다. CBA는 Backstage의 역량을 평가하는 시험이며 참고로 필자도 최근 취득한 바 있다.
이런 점을 봤을 때 Backstage는 클라우드 네이티브 생태계 내에서 플랫폼 엔지니어라면 반드시 갖춰야 할 필수 역량으로 자리잡았음을 알 수 있다.
2. Backstage 유즈 케이스
Backstage는 단순히 여러 툴들의 접근점을 모아주는 대시보드로 끝나지 않고, 개발자가 서비스의 생애주기 전반을 관리할 수 있도록 도와준다. Backstage를 어떻게 활용할 수 있는지 3가지 유즈 케이스로 정리해봤다.
파편화된 서비스의 중앙 관리
(출처: Backstage 공식 문서)
MSA 환경에서 가장 흔한 질문은 ‘이 API는 누가 관리하는가?‘와 ‘이 서비스는 어떤 서비스와 의존 관계에 있는가?‘이다.
Backstage는 조직 내 모든 엔티티(서비스, 라이브러리, API 등)를 하나의 카탈로그로 통합한다. 이를 Backstage에서 소프트웨어 카탈로그(Software Catalog)라고 칭한다.
각 서비스의 소유주, 문서 링크, 배포 상태 등을 한눈에 파악할 수 있어 이런 정보를 찾기 위해 사내 메신저나 메일을 헤매는 시간을 획기적으로 줄여준다.
개발에 필요한 부수 작업 자동화
(출처: Backstage 공식 문서)
새로운 서비스를 시작할 때마다 레파지토리를 생성하고, CI/CD 파이프라인을 구축하며, 보안 스캔 도구를 연결하는 과정은 번거롭고 피로감이 쌓이는 일이다.
Backstage의 소프트웨어 템플릿(Software Templates) 기능을 사용하면 조직의 표준과 정책이 적용된 신규 프로젝트를 몇 번의 클릭만으로 생성할 수 있다.
이는 단순히 코드 스캐폴딩(Scaffolding, 초기 구조 설정)을 넘어 인프라 프로비저닝까지 자동화하므로, 개발자가 비즈니스 로직을 개발할 수 있는 환경을 손쉽게 만들 수 있게 된다.
코드로 관리되는 문서화
(출처: Backstage 공식 문서)
기술 문서는 코드와 멀어질수록 낡고 쓸모없어진다. Backstage의 TechDocs 기능은 소스 코드와 함께 관리되는 Markdown 문서를 자동으로 렌더링하여 중앙 포털에서 보여준다.
개발자는 익숙한 IDE에서 문서를 작성하고 Git으로 관리하며, 사용자는 분산된 위키가 아닌 Backstage이라는 통합 포털에서 모든 기술 문서를 검색하고 열람할 수 있다.
3. 국내에서 Backstage가 널리 사용되지 않는 이유
Backstage가 이토록 매력적인 도구임에도 불구하고 국내 업계에서의 확산 속도는 글로벌에 비해 다소 더딘 편이다. 그 이유를 정리해봤다.
제품이 아닌 ‘프레임워크’로서의 진입장벽
Backstage는 설치만 하면 바로 작동하는 SaaS나 솔루션이 아니다. Typescript와 React 기반의 프레임워크다.
즉, 우리 조직에 맞는 IDP를 만들기 위해 별도의 개발 공수가 필요한 것이다. 플랫폼을 관리하기 위해 또 다른 개발을 해야 한다는 점은 기업에 큰 부담으로 작용할 수 있다.
플랫폼 엔지니어링 전담 조직의 부재
Backstage를 도입하고 운영하려면 개발자 경험을 전담하는 플랫폼 팀이 필요하다. 하지만 국내에 많은 기업은 여전히 운영 중심의 DevOps 팀이나 SRE 팀으로 구성되어있는 경우가 많다.
개발자를 위한 내부 플랫폼을 고도화하고 관리할 전담 인력을 배정하기 어려운 조직 구조가 도입에 걸림돌이 될 수 있다.
마무리
모든 조직에 Backstage가 정답은 아니다. 하지만 아래와 같은 조직이라면 Backstage를 참고해보면 좋을 것이다.
- 엔지니어 수가 급증하여 커뮤니케이션 비용이 폭발적으로 증가한 조직
- 수십, 수백 개의 마이크로서비스를 관리하는 데에 한계가 온 조직
결국 Backstage는 단순히 새로운 도구로 볼 것이 아니라, 개발자의 경험을 하나의 포털로 관리하겠다는 조직의 의지가 필요한 시스템이다.
조직의 개발자들에게 오롯이 비즈니스 가치 창출에만 집중할 수 있는 환경을 제공하고 싶다면 Backstage가 좋은 기준점이 될 것이다.