kubernetes 셀프서비스 backstage 도입여부 환경

 

개발자들이 yaml 안건드리고 배포할수 있는 환경을 만들고싶어서  

github으로 구현할지 backstage로 할지 고민을 하고 있습니다. 

다음과 같은 조건을고려해서 도입여부를결정하였습니다.    

 

1. Backstage가 필요 없는 경우

• 팀 규모가 작다
  • 개발자 10명 이하 + 서비스 20개 이하  
  • 온보딩은 문서(Markdown/Notion)로도 1일 이내에 충분히 가능.
• DevOps 병목이 크지 않다
  • 새 서비스 생길 때 DevOps 1명이 직접 Helm/CI/CD 넣어주는 게 몇 시간 안 걸린다.
  • 개발자 요청 건수가 적어서 반복 부담이 크지 않다.
• 서비스 표준화가 이미 잘 돼 있다
  • Template repo, reusable GitHub Actions, Helm 차트가 있어서 복붙으로도 80% 커버 가능.

👉 이런 상황이면 Backstage는 운영비용 > 효용이라 “라이트 셀프서비스”로 충분합니다.

---

2. Backstage가 필요한 신호

 

• 개발자 수: 30명 이상 (특히 팀이 여러 개로 나눠질 때)
• 서비스 수: 50개 이상 (Owner/알람/런북이 흩어져 혼란 발생)
• DevOps 병목: “새 서비스 시작/배포/DB 요청”을 DevOps가 직접 해줘야 해서 리드타임이 하루 이상 걸릴 때
• 문서 분산 문제: Notion, GitHub, Grafana, ArgoCD 등에서 정보가 흩어져 온보딩이 2~3일 이상 걸릴 때

 

아래와 같은 패턴이 보일 때 Backstage가 힘을 발휘합니다:

1. DevOps 병목
   • 새 서비스 만들 때마다 DevOps 요청 → 처리 대기 → 팀 전체 속도 저하.
   • “서비스 시작 리드타임”이 하루 이상 잡히는 경우.
2. 서비스 규모/팀 복잡성
   • 마이크로서비스가 30~50개 이상으로 늘어남.
   • 팀이 여러 개로 나뉘고, Owner/알람/런북 위치가 제각각 → “누가 뭘 책임지지?” 혼란 발생.
3. 표준화/셀프서비스 수요
   • “새 API 서비스 뼈대/DB/토픽/CI 파이프라인을 클릭 한 번으로 만들고 싶다”는 요구가 많아짐.
   • DevOps가 직접 개입하지 않고도 개발자가 배포/문서/대시보드를 셀프 서비스로 가져가야 하는 상황.
4. 문서/운영 정보 흩어짐
   • README, Notion, Wiki, Grafana, ArgoCD, GitHub Actions가 다 따로라 온보딩이 2~3일 이상 걸림.
   • 팀 내에서 “서비스 맵/카탈로그”를 따로 만들어야 할 정도.

---

3. Postgres 관련

네, Backstage는 메타데이터 저장 DB가 필요합니다.

• PoC → SQLite 가능 (컨테이너 재시작 시 데이터 유실 위험).
• 운영 → Postgres 권장 (RDS 같은 매니지드 사용 시 안정적).
• 저장되는 것: 카탈로그 엔티티, Scaffolder 실행 기록, RBAC 정책, 플러그인 메타데이터 등.

---

4. 정리 (판단 기준)

• 8명/20서비스: Markdown/Notion + 템플릿 레포 + GitHub Actions 재사용으로 충분.
• 30~50서비스 이상 / DevOps 1명으로 병목 심화 / 팀 다변화: Backstage 고려 시작.
• 셀프서비스화 요구(“원클릭으로 레포+CI+배포+문서”)가 강하면, 규모가 작아도 Backstage PoC 시도 가능.