Backstage 엔티티의 정체성, kind 필드 완벽 이해하기 (Component부터 Resource까지)

안녕하세요! 오늘은 Backstage의 핵심 중의 핵심, 모든 메타데이터의 시작점이라고 할 수 있는 catalog-info.yaml 파일의 kind 필드에 대해 아주 깊이 있게 파헤쳐 보겠습니다. 🚀

Backstage를 설정하다 보면 가장 먼저 마주하게 되는 이 필드가 정확히 무엇을 의미하는지, 그리고 어떤 종류들이 있는지 알면 서비스 카탈로그를 설계하는 시야가 완전히 달라질 것입니다. 💡

---

🏗️ kind 필드란 무엇인가?

Backstage의 소프트웨어 카탈로그는 모든 자원을 '엔티티(Entity)'라는 단위로 관리합니다. 이때 kind 필드는 "이 엔티티가 어떤 유형의 사물인가?"를 정의하는 가장 기본적인 분류 체계입니다.

객체 지향 프로그래밍에 비유하자면, kind는 클래스(Class)와 같고, 우리가 작성하는 개별 YAML 파일은 그 클래스로부터 생성된 인스턴스(Instance)라고 이해하면 쉽습니다. 😊

---

🌟 주요 kind 유형 총정리

Backstage 표준 모델(Core Entities)에서 지원하는 대표적인 kind들을 상세히 살펴보겠습니다.

1. kind: Component (소프트웨어의 최소 단위) 🧩

가장 많이 사용되는 유형입니다. 코드 저장소에 있는 실제 서비스, 웹 앱, 라이브러리 등을 나타냅니다.

• 역할: 비즈니스 로직을 수행하는 실제 소프트웨어를 정의합니다.
• 예시: 마이크로서비스, 프론트엔드 리액트 앱, 공통 유틸리티 라이브러리.

2. kind: API (시스템 간의 대화 창구) 🔌

서비스가 외부에 노출하는 인터페이스를 정의합니다.

• 역할: REST, gRPC, GraphQL 명세를 관리하고 서비스 간의 계약을 명시합니다.
• 특징: Component가 이 API를 '제공(Provides)'하거나 '소비(Consumes)'하는 관계를 설정할 수 있습니다.

3. kind: System (연관된 자원들의 집합) 🏰

여러 컴포넌트와 API를 하나의 논리적인 단위로 묶어주는 역할을 합니다.

• 역할: "결제 시스템", "주문 관리 시스템"처럼 큰 단위의 비즈니스 기능을 나타냅니다.
• 도움: 복잡한 아키텍처를 추상화하여 한눈에 파악하게 해줍니다.

4. kind: Resource (인프라 및 외부 서비스) 💾

소프트웨어가 동작하기 위해 필요한 물리적/논리적 자원을 뜻합니다.

• 역할: 데이터베이스(PostgreSQL, Redis), S3 버킷, 클라우드 클러스터 등을 정의합니다.
• 관리: 어떤 서비스가 어떤 DB를 사용하는지 추적할 때 유용합니다.

---

👥 조직 구조를 정의하는 kind

Backstage는 소프트웨어뿐만 아니라, 그 소프트웨어를 만드는 사람도 관리합니다.

5. kind: Group & kind: User 👥

• User: 개별 개발자나 팀원을 나타냅니다.
• Group: 팀, 본부, 동호회 등 조직 단위를 나타냅니다.
• 연결: Component의 owner 필드에 특정 Group을 지정함으로써, "이 서비스는 어느 팀이 담당하는가?"를 명확히 합니다. 🎯

---

🛠️ catalog-info.yaml 예시로 보는 kind

실제 파일에서는 어떻게 쓰이는지 볼까요?

YAML

apiVersion: backstage.io/v1alpha1
kind: Component        # 바로 이 부분입니다!
metadata:
  name: order-service
  description: 주문을 처리하는 핵심 마이크로서비스
spec:
  type: service
  lifecycle: production
  owner: team-alpha    # Group 엔티티와 연결됨
  system: order-management-system

 

위 예시에서 kind: Component는 이 파일이 소프트웨어 구성 요소를 정의하고 있음을 선언합니다. 만약 이 파일이 API 명세였다면 kind: API로 바뀌었겠죠?

---

❓ kind를 정확히 설정하는 것이 왜 중요한가요?

1. UI 렌더링 방식 결정: Backstage는 kind에 따라 화면에 보여주는 플러그인과 탭을 다르게 구성합니다. (예: API는 Swagger 뷰어를 보여주고, Component는 CI/CD 현황을 보여줌)
2. 관계도(Graph) 형성: 엔티티 간의 연결 고리를 올바르게 형성하려면 각자의 역할을 정확히 정의해야 합니다.
3. 검색 및 필터링: 수천 개의 자원 중에서 필요한 것을 찾을 때 kind는 가장 강력한 필터가 됩니다. 🔍

---

🏁 결론: kind는 엔티티의 정체성입니다!

Backstage의 kind 필드는 단순한 문자열이 아니라, 해당 자원의 성격과 책임, 그리고 다른 자원과의 관계를 규정하는 정체성과 같습니다.

여러분의 인프라와 소프트웨어를 Backstage 모델에 맞게 잘 분류하는 것(Kind 설계)이 바로 훌륭한 개발자 포털을 만드는 첫걸음입니다. 🚀

---