Backstage가 무료라는 환상

Eleanor · 5월 11, 2026, 6:23오전

라이선스가 무료라는 이유로 Backstage를 도입한 한국 조직이 늘고 있습니다. 그런데 Backstage 운영 비용은 연간 $750K-$1.25M, 3년 누적 $2M+입니다. 그리고 도입한 조직의 평균 사용률은 약 10%입니다.

Gartner는 2026년까지 대형 조직 80%가 플랫폼 팀을 가질 거라고 예측했고, 그 팀이 가장 많이 쓰는 Backstage는 IDP(Internal Developer Portal) 시장 89%를 점유합니다. 누적 3,400+ 조직 도입. 80% 도입과 10% 사용의 격차가 8-10배인데, 이 격차가 한국에서는 더 벌어질 가능성이 높습니다.

TL;DR

8-10배 격차: Backstage 도입률 80% vs 평균 사용률 10%. Spotify 자체는 99% 쓰지만 외부 조직 평균은 10%이고, 격차의 원인은 플랫폼 팀이 유지보수에 시간을 다 써서 개발자가 실제로 원하는 기능을 못 만든다는 점입니다.
TCO의 진짜 모습: 라이선스는 무료지만 3-15 FTE, 연간 $750K-$1.25M 인건비, 3년 누적 $2M+. 상용 대안(Roadie $22/dev, Port $30+/dev, Cortex $65/user) 대비 5-10배 차이. 500명 미만 엔지니어 조직에서 자체 운영 결정은 대부분 손해입니다.
한국에서 더 어려운 조건: 영어 기반 문서, React/TypeScript 전문 인력 부족, 한국 SI/결재 시스템 통합 어려움, 한국 도구 플러그인 부재. 한국 SI 업체가 대기업 PoC에서 default로 제안하는 패턴은 검토가 필요합니다.

1. 80%와 10%, 두 숫자가 가리키는 것

먼저 두 숫자를 분리해서 봐야 합니다. Gartner 예측 80%는 플랫폼 팀을 가진 조직 비율이고, 그 플랫폼 팀이 만든 Backstage IDP를 회사 안 개발자들이 실제로 쓰는 비율은 다른 숫자입니다. OpsLevel 자료에 따르면 Spotify 자체는 99% 사용률을 보고하지만 **Spotify 외 조직 평균은 약 10%**입니다.

격차의 원인은 OpsLevel과 Roadie 자료에서 일관되게 나옵니다. 플랫폼 팀이 Backstage 유지보수에 시간을 다 쓰느라 개발자가 실제로 원하는 기능을 못 만든다는 거죠. Backstage는 React/TypeScript 기반 플러그인 아키텍처라 셋업도 복잡하고, 메이저 업그레이드마다 플러그인이 깨지면서 마이그레이션 작업이 누적됩니다. Roadie의 분석은 이 패턴을 "DIY is dead"로 정리했습니다. 포털 자체를 만드는 일이 플랫폼 차별화 기능을 만드는 일을 잡아먹는다는 진단입니다.

이 격차가 의미하는 건 단순합니다. 도입 결정과 사용 결과는 다른 사건이고, 두 사건 사이에 18-24개월의 운영 부담이 있습니다.

2. TCO의 진짜 모습

Backstage는 Apache 2.0 라이선스로 라이선스 비용이 0입니다. 그런데 1차 출처에서 검증된 운영 비용은 다음과 같습니다.

OpsLevel 공식 자료: “3-15 FTE 엔지니어 minimum” 운영 인력 필요. Roadie 자료: 3-12명 전담 엔지니어 + 3년 누적 TCO $2M+. 시니어 플랫폼 엔지니어 연봉 $250K 기준으로 3-5명이면 연간 $750K-$1.25M 인건비입니다.

100명 엔지니어 조직 기준으로 Tasrie IT가 추정한 Backstage 3년 TCO는 연간 $375K-$750K입니다. 셋업 기간만 6-18개월. 메이저 업그레이드 한 번에 4명 FTE 팀이 6주씩 쓰는 사례가 보고됩니다.

같은 100명 조직에서 상용 대안의 가격 곡선을 보면 차이가 명확합니다. Roadie 매니지드 Backstage $22/개발자/월 = 연간 약 $26,400. Port $30+/개발자/월 = 약 $36,000+. Cortex $65/사용자/월 = 약 $78,000. OpsLevel은 30-45일 안에 셋업 완료.

100명 조직에서 Backstage 자체 운영 $375K-$750K vs 상용 대안 $26K-$78K. 약 5-10배 차이입니다. 입력 자료에 자주 보이는 "8-16배"는 다소 과장이지만, 정성적으로는 같은 방향이고 5-10배도 충분히 큰 격차입니다.

이 숫자를 보고 나면 Backstage 자체 운영을 권장할 수 있는 조건이 좁아집니다. Tasrie IT의 1차 출처 표현을 그대로 가져오면 **“500+ 엔지니어 + 5+ 명 전담 플랫폼 팀 + TypeScript/React 전문성 + 상용 대안이 못 만족시키는 커스텀 요구”**가 모두 충족될 때입니다. 이 조건을 충족하지 못하는 조직에서 Backstage 자체 운영 결정은 거의 항상 손해라는 게 1차 출처들의 일관된 결론입니다.

3. 한국에서 격차가 더 벌어지는 조건

여기까지가 글로벌 평균 분석입니다. 한국 시장에서는 격차가 더 벌어질 가능성이 높습니다. 네 가지 조건이 겹치거든요.

조건 1, 영어 기반 문서. Backstage 공식 문서, 플러그인 문서, 커뮤니티 자료가 모두 영어입니다. React/TypeScript 풀스택 자료까지 합치면 한국어 자료는 거의 없습니다. 한국 medium 블로그에 2024년부터 "국내 적용 사례 별로 없고 유지 관리 어렵다"는 회의론이 등장하고 있고, 이건 단순 인지도 문제가 아니라 운영 진입 장벽 문제입니다.

조건 2, React/TypeScript 전문 인력 부족. Roadie의 표현은 "TypeScript Tax"입니다. 대부분 DevOps 팀이 React/TypeScript 프론트엔드 전문성을 갖고 있지 않고, Backstage 커스터마이징은 이 둘 없이는 거의 불가능합니다. 한국 플랫폼 엔지니어링 영역에서 React/TypeScript + DevOps + Kubernetes를 동시에 갖춘 인력 풀은 글로벌 평균보다 좁습니다.

조건 3, 한국 SI/결재 시스템 통합 부재. 한국 대기업 환경에서는 사내 결재 시스템, 한국형 그룹웨어, 한국어 Slack/Jira 활용 패턴, 국내 보안 인증(K-ISMS, ISMS-P 등) 통합이 필수인데, Backstage 공식 플러그인 생태계에 이런 한국 특화 통합이 없습니다. 자체 플러그인 개발이 필요한데 이게 다시 운영 부담을 키웁니다.

조건 4, 한국 SI 업체의 default 제안 패턴. 한국 IT 매체와 컨설팅 회사가 Gartner 80% 예측을 같은 톤으로 인용하면서(Microsoft Learn 한국어, 에스코어/Samsung SDS 등) 플랫폼 엔지니어링 도입을 가속하는 중이고, 한국 SI 업체가 한국 대기업 PoC에서 Backstage를 default로 제안하는 패턴이 형성되고 있습니다. 이 패턴이 위험한 이유는 한 가지입니다. TCO 분석과 한국 시장 특수성 평가 없이 “글로벌 표준” 이유로 default를 결정하면 1년 후 “도입했지만 안 쓴다” 케이스가 양산되거든요.

이 네 조건이 겹치면 한국 조직의 Backstage 평균 사용률이 글로벌 평균 10%보다 더 낮을 가능성이 큽니다. 검증할 수 있는 한국 빅테크의 공식 사용률 데이터가 공개돼 있지 않아 추정이지만, 한국 medium 블로그의 회의론, 한국 SI 통합 부재, React/TypeScript 인력 풀의 좁음을 종합하면 합리적인 추정입니다.

4. 운영 레이어가 차별화

지난 IREN-Mirantis 글에서 GPU 자체가 commodity로 떨어지는 동안 운영 레이어가 새 마진 영역이 됐다고 짚었습니다. Backstage 사례도 같은 패턴입니다. Backstage 자체는 OSS이고 commodity로 떨어지는 중이고, 진짜 마진은 그 위 운영 레이어(Roadie, Port, Cortex, OpsLevel)에서 만들어지고 있습니다.

이게 한국 SI에게 직접 의미 있는 영역입니다. 자체 IDP를 처음부터 만드는 게 아니라, 글로벌 IDP 위에 한국 컨텍스트 운영 레이어(국내 보안 인증 통합, 한국 결재 시스템 연동, 한국어 문서, 한국 도구 플러그인)를 얹는 게 정렬 가능한 영역입니다.

세 가지 경로가 있습니다. 첫째, 자체 개발. 한국 대기업이 자체 IDP를 처음부터 만드는 길인데 시간과 인력이 큽니다. 둘째, 매니지드 Backstage 도입. Roadie 같은 글로벌 매니지드 서비스를 가져다 쓰는 길인데 한국 컨텍스트가 빠집니다. 셋째, 한국 SI 자체 운영 레이어. 글로벌 IDP(Backstage 또는 상용) 위에 한국 SI가 한국 컨텍스트 통합 레이어를 만들어 제공하는 길입니다.

세 경로 중 한국 SI에게 가장 정렬되는 건 셋째인데, 지금 한국 SI는 첫째(자체 개발)나 둘째(글로벌 매니지드/상용 default)에 머물러 있는 게 시장에서 보입니다. 그러니까 진짜 기회 영역이 비어있는 셈이지요.

5. 의사결정 분기점

지금 Backstage 도입을 검토 중인 조직이라면 다음 분기점을 봐야 합니다.

1차 출처가 권장하는 Backstage 자체 운영 조건: 500+ 엔지니어 + 5+ 명 전담 플랫폼 팀 + 깊은 TypeScript/React 전문성 + 상용 대안이 못 만족시키는 커스텀 요구. 이 네 조건이 모두 충족돼야 자체 운영이 합리적입니다.\
한국 시장에서 더 보수적으로 봐야 할 조건: 위 네 조건에 한국 컨텍스트 추가. 한국어 문서 자체 작성 능력 + 한국 결재/그룹웨어 통합 자체 개발 능력 + K-ISMS 인증 통합 능력. 이 세 추가 조건까지 충족되는 한국 조직은 1,000명 이상 규모 빅테크 정도입니다.
그 외 조직의 합리적 경로: 매니지드 Backstage(Roadie) 또는 상용 대안(Port, Cortex, OpsLevel) PoC. Roadie는 Backstage 호환성 유지하면서 운영 부담만 제거하는 모델이고, Port/Cortex/OpsLevel은 다른 아키텍처로 같은 IDP 기능을 제공합니다.
한국 SI 프리세일즈 입장에서 검토할 것: 한국 대기업 PoC에서 Backstage를 default로 제안하는 패턴 자체를 재검토. TCO 분석과 한국 시장 특수성 평가를 함께 제시하지 않으면 1년 후 고객 만족도가 낮아지고, 그게 다시 한국 SI의 플랫폼 엔지니어링 영역 신뢰도를 깎습니다.

6. 오늘의 체크리스트

Backstage 도입률 vs 실제 사용률 측정: 도입 결정만으로 평가하지 말고 주간 활성 개발자 비율을 별도로 측정. 회사 안 개발자 100명 중 매주 몇 명이 Backstage를 실제로 열고 작업하는지 확인.
3년 TCO 정확히 계산: 인건비(FTE × 연봉), 인프라 비용, 기회비용(같은 인력이 다른 일을 했을 때 가치) 모두 포함. 라이선스 무료라는 단일 항목으로 평가하면 안 됩니다.
한국 시장 특수성 평가: 한국어 문서 작성 부담, 한국 결재/그룹웨어 통합 부재, K-ISMS 같은 국내 인증 통합 비용을 별도 항목으로 평가. 글로벌 평균 TCO에 한국 가산을 더해야 정확합니다.
상용/매니지드 대안 PoC 병행: Backstage 자체 운영 결정 전에 Roadie, Port, Cortex, OpsLevel 중 하나 이상을 30-45일 PoC 진행. 같은 사용 사례에서 어느 도구가 한국 컨텍스트에 더 맞는지 직접 비교.
한국 SI 프리세일즈 패턴 검토: 한국 SI에서 일하시거나 SI 제안을 받으시는 분이라면, “글로벌 표준” 이유 단일로 default 제안되는 패턴을 검토. TCO 분석과 한국 시장 특수성 평가가 동반되지 않은 제안은 재논의가 필요합니다.

알고 보면 좋은 분석 포인트

이 글의 분석 포인트는 세 가지입니다.

도입과 사용을 한 숫자로 보면 안 된다는 점을 짚었습니다. Gartner 80% 예측은 플랫폼 팀 보유 비율이고, Backstage 평균 사용률 10%는 다른 사건입니다. 두 숫자를 분리해서 보지 않으면 의사결정이 왜곡됩니다. Spotify 99% vs 외부 조직 10%의 격차가 의미하는 건 OSS 자체가 아니라 운영 부담의 차이인 것이지요.
한국 시장에서 격차가 더 벌어지는 조건을 네 가지로 정리했습니다. 영어 기반 문서, React/TypeScript 인력 부족, 한국 SI/결재 시스템 통합 부재, 한국 SI default 제안 패턴. 이 네 조건이 겹치면 한국 조직의 Backstage 평균 사용률이 글로벌 평균보다 더 낮을 가능성이 큽니다. 비판 직접 톤으로 짚었지만, 한국 SI default 제안 패턴 재검토가 결국 한국 SI의 플랫폼 엔지니어링 신뢰도를 보호하는 길입니다.
시리즈 연속선에서 운영 레이어가 차별화 영역이라는 thesis가 IDP 사례에서도 같은 패턴으로 작동한다는 점을 짚었습니다. 지난 IREN-Mirantis 글에서 GPU commodity화와 운영 레이어 마진을 짚었다면, 이번 글은 OSS commodity화와 IDP 운영 레이어 마진의 같은 패턴입니다. 한국 SI에게 정렬 가능한 영역은 자체 개발이나 글로벌 매니지드 도입이 아니라 글로벌 IDP 위 한국 컨텍스트 운영 레이어를 만드는 셋째 경로입니다.