Skip to content
Published on

내부 개발자 플랫폼(IDP) 2026 — Backstage / Port / OpsLevel / Cortex / Compass / Roadie 심층 비교

Authors

"플랫폼 엔지니어링이 DevOps를 대체한 게 아니다. DevOps의 약속을 드디어 제품으로 만든 것이다." — 어느 SRE 리드

이번 글은 2026년 5월 기준 IDP(Internal Developer Platform) 시장 지도다. Backstage가 CNCF를 졸업하고 사실상 표준이 된 한편, Spotify는 자체적으로 Portal for Backstage라는 상용 패키지를 내놨고, Roadie는 매니지드 Backstage로 YC 출신답게 빠르게 자리를 잡았다. 그 옆에는 Port, OpsLevel, Cortex, Configure8, Humanitec 같은 SaaS 진영이 "Backstage는 무겁다"를 마케팅 포인트로 삼아 시장을 가져가고 있다. Atlassian Compass는 Jira/Confluence 생태계를 끼고 들어왔다.

이 글은 카탈로그, 스코어카드, 골든 패스, 셀프서비스 인프라, 소프트웨어 템플릿이라는 다섯 개의 핵심 개념을 축으로 각 도구를 비교한다. 마지막에는 한국의 당근, 토스, 일본의 CyberAgent CIU, Mercari 사례를 짚고 "우리 팀이 IDP를 도입해야 하는가"라는 의사결정 가이드로 마무리한다.

1. 2026년 IDP 지도 — 왜 다시 플랫폼 엔지니어링인가

2020년대 초반 DevOps가 "모두가 모든 것을 한다"로 해석되면서 부작용이 쌓였다. 백엔드 엔지니어가 Kubernetes 매니페스트를 직접 작성하고, Terraform을 손으로 짜고, GitHub Actions 워크플로를 매일 깎고, Helm 값 파일을 환경별로 다섯 개씩 관리했다. 결과적으로 "기능 개발에 쓰는 시간 30%, 인프라/도구에 쓰는 시간 70%"라는 인지 부하가 생산성을 갉아먹었다.

플랫폼 엔지니어링은 이 인지 부하를 내부 제품으로 흡수하자는 운동이다. 그 결과물이 IDP다. 2026년 시장은 크게 네 부류로 나뉜다.

  • 오픈소스 표준: Backstage (CNCF graduated, 2024)
  • 매니지드 Backstage: Spotify Portal, Roadie
  • SaaS 카탈로그/스코어카드: Port, OpsLevel, Cortex, Atlassian Compass, Configure8
  • 셀프서비스 인프라 오케스트레이션: Humanitec, Crossplane 기반 도구

Gartner는 2026년까지 대규모 소프트웨어 엔지니어링 조직의 80%가 플랫폼 팀을 갖출 것이라고 예측했다. 실제로 Stack Overflow Developer Survey 2025에서는 응답자의 38%가 "회사에 별도의 플랫폼 팀이 있다"고 답했다.

2. IDP 핵심 개념 — 카탈로그 / Scorecard / Golden Path / 셀프서비스

IDP를 평가할 때 공통 어휘가 있다. 다섯 개의 축으로 정리한다.

1) Software Catalog (소프트웨어 카탈로그). 회사가 보유한 모든 서비스, 라이브러리, API, 데이터 파이프라인을 한 곳에서 검색할 수 있는 메타데이터 저장소다. Backstage의 catalog-info.yaml이 사실상 표준이 됐다.

2) Scorecard (스코어카드). 서비스가 충족해야 하는 기준의 체크리스트다. "테스트 커버리지 70% 이상", "Datadog 알림 설정", "런북 존재", "오너 명시" 같은 항목을 자동으로 검사하고 점수를 매긴다. OpsLevel과 Cortex가 이 기능을 강하게 밀고, Backstage는 Tech Insights 플러그인으로 비슷한 걸 구현한다.

3) Golden Path (골든 패스). 신규 서비스를 만들 때 따라야 할 권장 경로다. "Go 서비스 = chi 라우터 + zap 로거 + OTel + GitHub Actions 표준 워크플로". 골든 패스에서 벗어나는 건 가능하지만, 그러려면 명시적으로 정당화해야 한다.

4) Self-Service Infrastructure (셀프서비스 인프라). 개발자가 티켓을 끊지 않고 직접 새 데이터베이스, 큐, S3 버킷을 만들 수 있는 워크플로다. 백엔드는 Crossplane이나 Terraform Cloud로 구성하고, 프런트엔드는 Backstage Software Template이나 Port Action으로 노출한다.

5) Software Template (소프트웨어 템플릿). 새 리포지터리/서비스의 보일러플레이트를 자동 생성하는 스캐폴더. Backstage @backstage/plugin-scaffolder가 대표. Cookiecutter, Yeoman의 IDP 버전이라 보면 된다.

이 다섯 개 중에 카탈로그는 IDP의 심장이다. 카탈로그 없는 IDP는 그냥 위키다.

3. Backstage — CNCF 졸업, 사실상 표준

Backstage는 Spotify가 2020년 오픈소스로 공개한 IDP 프레임워크다. 2022년 CNCF Incubating, 2024년 Graduated 단계로 진입했다. React + Node.js + TypeScript로 작성됐고, 플러그인 아키텍처가 강점이다.

아키텍처 핵심:

# catalog-info.yaml — Backstage의 사실상 표준 메타데이터
apiVersion: backstage.io/v1alpha1
kind: Component
metadata:
  name: payment-service
  description: 결제 처리 서비스
  annotations:
    github.com/project-slug: myorg/payment-service
    pagerduty.com/integration-key: PD123
    datadoghq.com/service-name: payment
spec:
  type: service
  lifecycle: production
  owner: team-payments
  system: payments
  dependsOn:
    - resource:postgres-payments
    - component:user-service

Backstage의 장점:

  • 플러그인 생태계가 압도적으로 크다 (2026년 기준 200개 이상의 공식/커뮤니티 플러그인)
  • 완전 오픈소스, 데이터 락인 없음
  • CNCF 졸업으로 거버넌스가 안정적
  • 모든 주요 클라우드에서 자체 호스팅 가능

Backstage의 단점:

  • 셋업이 무겁다. 첫 프로덕션 배포까지 평균 3-6개월
  • React/Node.js 풀스택 운영 역량이 필요
  • 플러그인 호환성 깨짐이 잦았다 (1.0 이후 안정화 진행 중)
  • UI 커스터마이징은 코드를 직접 만져야 한다

누가 써야 하나: 100명 이상 엔지니어 조직, 인프라/플랫폼 팀이 5명 이상 있는 곳, 데이터 락인을 절대 피하고 싶은 곳. Netflix, Spotify, American Airlines, Expedia, LinkedIn, Twilio 등이 자체 호스팅 중이다.

4. Spotify Portal for Backstage — 상용 패키지

2024년 Spotify는 Backstage를 만든 본가답게 Portal for Backstage라는 상용 제품을 발표했다. 오픈소스 Backstage 위에 Spotify 사내에서 검증된 프리미엄 플러그인 묶음을 얹은 형태다.

포함되는 주요 플러그인:

  • Soundcheck: Spotify가 내부에서 쓰던 스코어카드 시스템. OpsLevel/Cortex의 직접 경쟁자
  • Skill Exchange: 사내 멘토링/세컨드먼트 매칭
  • Insights: Backstage 사용 분석 대시보드
  • RBAC: 권한 관리 (오픈소스에는 기본 RBAC만 있음)
  • AiKA: AI Knowledge Assistant. 사내 문서/카탈로그를 LLM으로 검색

가격 모델은 시트당 월 단가로 알려져 있고, 자체 호스팅 Backstage 인스턴스에 플러그인을 설치하는 방식이다. 즉 호스팅은 본인이 하지만 프리미엄 기능을 라이선스로 산다.

누가 써야 하나: Backstage를 이미 자체 운영 중인데 스코어카드/AI 검색/RBAC을 직접 구현하기 싫은 조직. "Backstage 본가 보증"이 의사결정 기준이 되는 보수적인 엔터프라이즈.

5. Roadie — 매니지드 Backstage (YC)

Roadie는 Y Combinator 출신 스타트업으로 호스팅된 Backstage를 제공한다. 즉 Backstage 운영을 외주 주는 것과 같다.

특징:

  • Backstage 코어를 그대로 사용, 락인 최소화
  • 30개 이상의 통합이 즉시 작동 (GitHub, GitLab, PagerDuty, Datadog, Sentry, AWS, GCP, ArgoCD)
  • TechDocs (Backstage의 문서 시스템)가 박스 안에 들어있음
  • 스코어카드 기능 내장 (Soundcheck나 OpsLevel과 유사)
  • 가격: 사용자당 월 단가, 작은 팀은 무료 티어 가능

Roadie를 고려할 이유:

  1. Backstage가 좋은데 운영 인력이 없음
  2. 6개월 걸릴 셋업을 1주일로 단축하고 싶음
  3. 카탈로그 데이터는 GitHub에 그대로 두고 싶음 (catalog-info.yaml이 살아있음)

한계: 깊은 커스터마이징은 자체 호스팅보다 제한적이다. 일부 플러그인은 매니지드 환경에서 작동하지 않는다.

6. Port — 의견 있는 빠른 IDP

Port는 2022년 텔아비브에서 시작한 IDP SaaS다. 2024년 Series B 라운드를 마쳤다. "Backstage는 무겁다, 우리는 가볍고 의견이 강하다"가 핵심 메시지.

Port의 데이터 모델은 Backstage와 다르다. Backstage는 Component / API / Resource / System / Domain이라는 고정 종류를 쓰지만, Port는 사용자가 직접 Blueprint(엔티티 종류)를 정의한다. 예:

# Port Blueprint 예시
identifier: microservice
title: Microservice
icon: Microservice
schema:
  properties:
    language:
      type: string
      enum: [Go, TypeScript, Python, Rust]
    tier:
      type: string
      enum: [tier-1, tier-2, tier-3]
    on_call:
      type: string
      format: user
    slo:
      type: number
relations:
  team:
    target: team
    required: true
  database:
    target: postgres_instance
    many: true

Port의 강점:

  • 셋업 1일 ~ 1주일. Backstage 대비 압도적으로 빠르다
  • Self-service actions: "새 마이크로서비스 생성", "스테이징 환경 부팅" 같은 액션을 GUI로 정의
  • Datadog/PagerDuty/AWS와의 통합이 박스에서 작동
  • UI가 예쁘고 비기술자 친화적

Port의 약점:

  • 카탈로그 데이터가 Port 클라우드에 저장됨 (락인 우려)
  • 플러그인 생태계는 Backstage 대비 훨씬 좁다
  • 깊은 커스터마이징은 Backstage보다 제한적

누가 써야 하나: 50-300명 규모 엔지니어링 조직, 빠른 도입이 중요한 곳, 플랫폼 팀이 2-3명 수준인 곳.

7. OpsLevel — 서비스 소유권

OpsLevel은 2018년 캐나다에서 시작한 IDP SaaS다. **서비스 카탈로그 + 스코어카드(품질 등급)**가 핵심.

OpsLevel의 차별화 포인트는 Maturity Rubric이다. 각 서비스를 A~F 등급으로 자동 평가한다:

  • A 등급: 테스트 커버리지 90%+, SLO 정의, 런북 있음, 온콜 로테이션 명시, OTel 계측
  • F 등급: 오너 미상, 알림 없음, 문서 없음

이 등급은 매일 자동 계산되고 팀별 대시보드에 표시된다. CTO가 "왜 우리 팀 평균이 C인가"를 묻기 시작하면 변화가 일어난다.

OpsLevel의 강점:

  • Rubric 시스템이 직관적이고 강력하다
  • GitHub/Jira/PagerDuty/Datadog 통합이 깊다
  • 서비스 소유권 추적이 가장 정교하다 (오너 부재 서비스를 자동 탐지)

약점:

  • Backstage만큼 카탈로그 자체가 유연하지는 않다
  • 가격이 비싼 편 (시트당 월 30~50달러대로 알려짐)
  • 셀프서비스 인프라 액션은 Port보다 약하다

누가 써야 하나: "우리 회사 서비스 품질이 들쭉날쭉하다, 측정부터 시작해야 한다"가 핵심 문제인 조직.

8. Cortex — 엔지니어링 우수성

Cortex는 OpsLevel과 사실상 같은 시장을 본다. 둘은 자주 비교되며 입찰에서 맞붙는다. Cortex는 2019년 미국에서 시작했고 Series C까지 진행했다.

Cortex가 OpsLevel과 다른 점:

  • Scorecard 엔진이 더 표현력 있다. CQL이라는 자체 쿼리 언어로 임의의 조건을 정의 가능
  • Initiative 개념: "분기 OKR로 모든 서비스에 OTel 도입" 같은 캠페인을 도구 안에서 추적
  • Eng Intelligence: DORA 메트릭, 배포 빈도, MTTR을 자동 수집해 대시보드화
  • AI 기반 Cortex Copilot: 카탈로그 자연어 검색

누가 써야 하나: OpsLevel과 거의 동일. 입찰 시점에 데모해보고 팀 취향에 맞는 쪽을 골라야 한다. 일반적으로 OpsLevel은 좀 더 "엄격한 거버넌스", Cortex는 좀 더 "유연한 캠페인" 느낌이다.

9. Atlassian Compass — Jira/Confluence와의 통합

Atlassian이 2023년 12월 GA로 출시한 Compass는 Jira, Confluence, Bitbucket 사용자에게 직격 메시지를 보낸다. "이미 우리 도구를 쓰니까 IDP도 같은 곳에서 쓰세요."

Compass의 데이터 모델은 Backstage의 catalog-info.yaml과 호환된다 (compass.yml이라는 거의 동일한 포맷 사용). 즉 Backstage에서 Compass로, 또는 그 반대로 이동이 쉽다.

Compass의 강점:

  • Jira 티켓, Confluence 페이지, Bitbucket PR과의 통합이 네이티브
  • Atlassian Rovo (AI) 통합으로 "이 서비스 누가 마지막으로 배포했지?"를 자연어로 물을 수 있음
  • 가격이 합리적 (사용자당 월 단가, Atlassian 패키지 할인)
  • Scorecard 기능 내장

약점:

  • 플러그인 생태계는 Backstage 대비 빈약
  • Atlassian 생태계 밖과는 통합이 약함 (GitHub, GitLab, PagerDuty 등이 가능은 하지만 1급 시민은 아님)
  • 셀프서비스 액션 기능은 약함

누가 써야 하나: 이미 Atlassian 스택을 쓰는 조직. "IDP 도입 결정"보다 "Atlassian 결제 추가" 쪽이 정치적으로 쉬운 경우가 많다.

10. Humanitec / Configure8 — 새로운 진영

Humanitec는 IDP라는 단어보다 Platform Orchestrator라는 표현을 좋아한다. 핵심은 Score라는 워크로드 명세 포맷이다 (CNCF Sandbox 프로젝트). Score는 환경별 Kubernetes 매니페스트를 자동 생성하는 IaC 추상 계층이다.

# score.yaml — Humanitec/Score 예시
apiVersion: score.dev/v1b1
metadata:
  name: hello-world
containers:
  hello:
    image: nginx:latest
    variables:
      DB_HOST: ${resources.db.host}
      DB_USER: ${resources.db.user}
resources:
  db:
    type: postgres

이 한 파일로 dev/staging/prod 환경의 Kubernetes 매니페스트 + Helm + Terraform이 모두 생성된다. 셀프서비스 인프라의 백엔드를 만들고 싶을 때 강력하다.

Configure8은 Y Combinator 출신 신규 진입자다. 2024년 GA. Port와 비슷한 카탈로그+액션 모델이지만, "더 가볍고 더 의견 있다"가 마케팅 메시지. 스타트업/스케일업 시장을 노린다.

Effx라는 이름을 기억하는 사람도 있을 텐데, 2022년 LinkedIn에 인수됐고 이후 LinkedIn 내부 IDP로 흡수됐다. 한때 IDP 시장의 다크호스였지만 외부 제품으로는 더 이상 존재하지 않는다.

11. DORA / SPACE 메트릭 — IDP가 측정하는 것

IDP가 측정하는 핵심 지표는 두 프레임워크에서 온다.

DORA (DevOps Research and Assessment) 4 키 메트릭:

  1. Deployment Frequency: 얼마나 자주 프로덕션에 배포하는가
  2. Lead Time for Changes: 코드 커밋부터 프로덕션 배포까지 걸리는 시간
  3. Change Failure Rate: 배포가 사고를 유발하는 비율
  4. Mean Time to Recovery (MTTR): 사고에서 복구까지 걸리는 시간

DORA 2024 리포트는 "Elite" 등급 조직이 하루 여러 번 배포, 1시간 미만 리드 타임, 5% 미만 실패율, 1시간 미만 복구 시간을 보인다고 정의한다.

SPACE 프레임워크 (Microsoft Research, 2021):

  • Satisfaction and well-being
  • Performance
  • Activity
  • Communication and collaboration
  • Efficiency and flow

SPACE는 DORA가 다루지 못하는 "개발자 만족도", "흐름(flow)", "협업 품질"을 측정한다. 실제 IDP 도구들의 채택 패턴은:

  • Cortex Eng Intelligence: DORA 자동 수집 + SPACE 일부
  • OpsLevel: Maturity Rubric이 SPACE의 Performance/Efficiency를 대신
  • Port: DORA 대시보드 내장
  • Backstage: Tech Insights + 자체 플러그인 조합으로 직접 구현

핵심은 수집보다 정의가 어렵다는 점이다. "배포 1회"의 정의가 팀마다 다르다 (PR 머지? 카나리 시작? 100% 트래픽?). IDP 도구를 도입한다고 이 정의 작업이 사라지지 않는다.

12. Backstage vs Port — 자체 호스팅 vs SaaS

가장 자주 부딪히는 결정이 Backstage(자체 호스팅) vs Port(SaaS)다. 다섯 가지 축으로 비교한다.

BackstagePort
셋업 시간3~6개월1~7일
운영 비용플랫폼 팀 2~5명 필요시트 구독료만
데이터 락인거의 없음 (자체 호스팅)중간 (Port 클라우드 저장)
커스터마이징무제한 (코드)중간 (Blueprint + Action)
플러그인 수200+60+
가격 (100명 조직 연간)인건비 50~100만 달러 + 인프라시트당 월 20~50달러

일반적 가이드:

  • 엔지니어 50명 미만 → Roadie 또는 Port (셋업 비용이 결정적)
  • 50~300명 → Port, OpsLevel, Cortex, Compass 중 하나
  • 300명 이상 → Backstage 자체 호스팅 + Spotify Portal 또는 자체 플러그인

이 룰의 예외는 항상 있다. 30명짜리 핀테크가 Backstage를 자체 호스팅하기도 하고 (보안/락인 정책 때문에), 1,000명짜리 게임 회사가 Port를 쓰기도 한다 (속도 우선).

13. 한국 (당근, 토스) / 일본 (CyberAgent, Mercari) IDP 사례

한국 — 당근 (Karrot): 당근은 2022년부터 자체 Backstage 기반 IDP를 운영한다. 사내 명칭은 "Karrot Platform" 또는 "DX Console". catalog-info.yaml을 모든 마이크로서비스에 강제하고, Soundcheck 스타일 스코어카드로 SLO 준수, 보안 패치 적용, 비용 가시성을 측정한다. 2024년 이후 자체 LLM 기반 카탈로그 검색을 추가했다.

한국 — 토스 (Toss): 토스는 내부적으로 "토스 개발자 플랫폼"이라 부르는 자체 IDP를 운영한다. 초기에는 Backstage를 평가했지만 최종적으로 자체 구축을 선택했다. 이유는 (1) 금융권 보안 요구사항, (2) 토스의 모노레포 구조와 맞춤형 빌드 시스템이 Backstage 추상화와 충돌. 자체 카탈로그, 자체 셀프서비스 인프라(쿠버네티스 네임스페이스 생성, RDS 생성), 자체 DORA 대시보드를 갖췄다.

일본 — CyberAgent CIU (CyberAgent group Infrastructure Unit): CyberAgent는 그룹사 전체에 공통 인프라를 제공하는 CIU라는 조직이 있다. CIU는 Cycloud라는 자체 IDP를 운영하며, Kubernetes/OpenStack 기반 멀티 테넌트 인프라를 그룹사 100여 개 자회사에 셀프서비스로 제공한다. 외부 SaaS IDP를 도입하지 않은 이유는 (1) 다수 자회사를 묶는 격리 요건, (2) 비용 절감.

일본 — Mercari: Mercari는 2020년대 초반 Backstage를 평가했고, 2023년 자체 구축한 "Microservices Platform"의 일부로 통합했다. 카탈로그는 catalog-info.yaml 호환 포맷을 쓰지만, UI는 Mercari가 자체 React 앱으로 구현했다. Spinnaker, ArgoCD, Datadog, Sentry 통합을 자체 플러그인으로 작성했다. Mercari Engineering 블로그에 상세한 시리즈 글이 있다.

공통 패턴: 글로벌 빅테크/스케일업은 자체 호스팅(또는 자체 구축) 비중이 높고, 100~500명 규모 한국/일본 스케일업은 SaaS(특히 Port/OpsLevel) 도입이 빠르게 증가하고 있다.

14. 우리 팀이 IDP를 도입해야 하나 — 의사결정 가이드

5단계 체크리스트:

1단계: 문제가 존재하나?

  • 신규 입사자 첫 배포까지 평균 며칠 걸리는가? (1주 초과 → 문제)
  • "이 서비스 오너가 누구지?" 질문에 답이 안 나오는가? (예 → 문제)
  • 보안 패치 적용 SLA를 못 지키는가? (예 → 문제)
  • 인시던트 발생 시 런북을 찾는 데 30분 이상 걸리는가? (예 → 문제)

3개 이상 해당하면 IDP 도입을 검토해야 한다. 2개 이하라면 위키 정비로도 충분할 수 있다.

2단계: 조직 규모 매칭

엔지니어 수추천
~30명위키 + GitHub README + 자작 스크립트로 충분. IDP 비용 정당화 어려움
30~80명Port 또는 Roadie. 셋업 빠른 SaaS가 정답
80~300명Port, OpsLevel, Cortex, Compass, Configure8 중 하나. 입찰 진행
300명 이상Backstage 자체 호스팅 + Spotify Portal 검토. 플랫폼 팀 5명+ 확보

3단계: 플랫폼 팀 인력

IDP는 "도구 사면 끝"이 아니다. 카탈로그 데이터를 채우고, 스코어카드 규칙을 정의하고, 골든 패스 템플릿을 만들고, 개발자에게 사용법을 트레이닝하는 인력이 필요하다. **최소 1.5명 (FTE)**이 6개월 이상 전담해야 의미 있는 결과가 나온다.

4단계: 카탈로그 데이터 소스

서비스 메타데이터를 어디서 가져올 것인가?

  • 이미 catalog-info.yaml을 쓰고 있다 → Backstage/Compass/Roadie가 자연스러움
  • 모든 정보가 위키/Confluence에 흩어져 있다 → Port가 마이그레이션 도구가 좋음
  • 모든 정보가 Jira/Confluence에 있다 → Compass

5단계: 측정 목표

IDP 도입 후 측정할 KPI를 미리 정한다:

  • Time to First Deploy (신규 입사자 첫 배포까지 시간) — 30일 → 7일
  • Service Owner Coverage (오너가 명시된 서비스 비율) — 60% → 95%
  • Scorecard Average — 평균 등급 C → B
  • Self-Service Action Adoption (셀프서비스로 처리된 인프라 요청 비율) — 0% → 40%

6개월 후 이 숫자가 안 움직이면 도입이 실패했거나, 데이터 채우기에 실패했거나, 둘 중 하나다.


IDP는 마법이 아니다. 컨텍스트와 거버넌스를 코드로 옮긴 것일 뿐이다. 도구 선택은 두 번째 문제고, 첫 번째 문제는 "우리 회사가 무엇을 표준이라 부를 것인가"를 결정하는 정치적 합의다. 이 합의가 있으면 Backstage든 Port든 어느 도구로도 성공한다. 합의가 없으면 어느 도구를 사도 위키만 더 만드는 결과로 끝난다.

참고 / References