플러그인 소유권

원문 보기 위키 갱신 2026.10.07

이제 건강한 Backstage 인스턴스를 향해 잘 나아가고 있어요! 전체 회사에 출시되었고, 개발자들이 주는 피드백이 마음에 들고 있어요. 일부 개발자들은 심지어 직접 플러그인을 작성하는 데 관심을 표현하기 시작했어요.

출처: 문서

본문

이너소스

다른 팀의 내부 기여를 받아들이는 것은 개발자에게 맞춤화된 개발자 포털로 가는 길에 있다는 좋은 신호예요. 이것은 수많은 장점이 있는 잘 닦인 길이지만 단점도 몇 가지 있어요. Backstage 인스턴스가 커지고 오래될수록 그 개발자들을 찾기 어려워질 수 있고, 팀이 Backstage 업데이트에서 더 많은 마찰을 겪기 시작할 수도 있어요.

시작하기 전 준비 상태

이너소스는 진정으로 보람 있는 이니셔티브지만, 기반 작업이 이미 마련되어 있을 때 가장 잘 동작해요. 너무 일찍 뛰어들면 기여 팀과 Backstage를 소유한 팀 모두에게 불필요한 마찰을 만들 수 있어요.

기여를 초대하기 전에 다음을 마련해 두는 것이 좋아요:

새 플러그인의 일관된 시작점. 기본 상태에서 yarn new를 실행하면 동작하는 Backstage 플러그인이 스캐폴드되는데, 훌륭한 시작점이에요. 하지만 CLI는 여러분이 직접 정의하는 사용자 정의 템플릿도 지원해요. 사용자 정의 템플릿을 사용하면 회사의 모범 사례, 코딩 규칙, 공유 컴포넌트를 처음부터 내장할 수 있어서, 기여자가 직접 맞추지 않아도 모든 플러그인이 여러분의 기준을 이미 충족하는 기준선에서 시작할 수 있어요.
스타일 가이드. 플러그인이 따르는 코딩 규칙을 문서화해요. TypeScript 표준, 테스트 커버리지 기대치, 명명 규칙이 포함돼요.
UI/UX 지침. 기여자는 자신의 플러그인이 Backstage 안에서 어떻게 보이고 동작할지 알아야 해요. 디자인 시스템, 사용하는 컴포넌트 라이브러리, 로딩 상태와 오류 처리 같은 패턴을 공유하세요.

이런 리소스를 기여 팀이 시작하기 전에 공유하는 것이, 사후에 풀 리퀘스트에서 검토하는 것보다 훨씬 효과적이에요.

팀이 빌드를 시작하기 전에 대화를 나누기

팀이 플러그인을 만들고 싶다며 찾아오는 것은 훌륭한 신호예요. 그들이 구상하는 것을 이야기할 시간을 가져보세요. 이것은 검토 과정이 아니라, 무엇을 만들고 있는지 이해하고 성공을 위해 준비시켜 줄 수 있는지 확인하는 기회예요.

함께 탐구하면 좋은 몇 가지:

플러그인은 무엇을 하고, 어떤 문제를 해결하나요?
이것이 그 팀에만 특정한 것인가요, 아니면 조직 전반의 더 넓은 사용자에게 유용한가요?
시간이 지나면서 어떻게 유지보수할 계획인가요?

이런 대화는 올바른 시작 템플릿을 가리키고, 기존 플러그인과의 중복을 지적하며, 어디에 맞는지 생각할 수 있는 맥락을 주어요.

카탈로그에 플러그인 등록하기

팀이 플러그인을 만들었고 더 넓은 사용을 위해 준비되었다면, 소프트웨어 카탈로그에 등록해야 해요. 이렇게 하면 플러그인을 발견할 수 있고, 명확한 소유자가 생기며, 다른 팀이 알아야 할 의존성이 표면화돼요.

catalog-info.yaml을 완전히 작성하기

플러그인이 카탈로그에 등록될 때 기여 팀은 catalog-info.yaml이 완전한지 확인해야 해요. 최소한 자신들을 소유자로 나열하고, 백엔드 API, 외부 서비스 또는 다른 Backstage 플러그인에 대한 의존성을 문서화해야 해요. 이렇게 하면 다른 팀이 질문이나 피드백을 위한 명확한 연락처를 갖게 되고, 플러그인이 무엇에 의존하는지 정확히 파악할 수 있어요.

apiVersion: backstage.io/v1alpha1kind: Componentmetadata:  name: my-plugin  description: A short description of what this plugin does.spec:  type: plugin  lifecycle: production  owner: team-name  dependsOn:    - component:my-backend-api