Backstage 가져오기
Backstage 카탈로그를 Archyl로 가져오기

Backstage는 운영 중인 것을 나열합니다. Archyl은 같은 카탈로그를 탐색 가능한 C4 모델로 바꿉니다. System은 시스템이 되고, Component와 Resource는 컨테이너가 되며, 모든 API 엔티티는 spec을 그대로 보존한 계약이 되어 이를 제공하고 소비하는 서비스에 연결됩니다. Backstage는 그대로 씁니다. 소유권은 넘어오지 않으며, 얻는 것은 두 개의 C4 레벨입니다.

요금제 보기
catalog-info.yamlBackstage
1apiVersion: backstage.io/v1alpha1
2kind: Component
3metadata:
4  name: checkout-api
5spec:
6  type: service
7  system: storefront
8  owner: payments-squad
9  providesApis: [checkout]
10  dependsOn:
11    - resource:orders-db
Reading…
app.archyl.com
Aurora Commerce/Containers
Search the architecture…K
ALMDKS
AI
가져오는 항목

모든 것이 Archyl로 옮겨집니다

가져오는 동안 아키텍처 모델이 그대로 보존됩니다.

Systems

모든 System 엔티티가 설명과 태그를 유지한 채 C4 소프트웨어 시스템이 됩니다. 서로 다른 namespace에서 이름이 같은 System 두 개는 병합되지 않고 이름이 변경되며, 어느 것이 변경되었는지는 가져오기 결과가 알려줍니다.

Components

Component는 이를 소유한 System 아래의 컨테이너가 되며, 소유 관계는 spec.system 또는 partOf 관계에서 해석됩니다. spec.type도 매핑되어 service는 서비스로, website는 웹 앱으로, cronworkflow는 워커로, library는 라이브러리로 바뀝니다.

Resources

Resource도 컨테이너가 되며, 유형은 spec.type에서 결정됩니다. RDS 인스턴스와 Valkey 클러스터는 데이터베이스가 되고, Kafka 토픽과 SQS 큐는 메시지 큐가 되며, S3 버킷은 파일 스토리지가 됩니다.

API spec

API 엔티티는 Archyl의 API 계약이 됩니다. 인라인 spec.definition은 원문 그대로 유지되고, HTTP, gRPC, GraphQL 또는 async로 분류되며, 이를 제공하고 소비하는 컨테이너에 연결됩니다.

Relations

dependsOn, consumesApi, producesTo, consumesFrom, versionedIn은 유형이 지정된 관계가 됩니다. Backstage는 대부분의 relations를 양방향으로 내보내지만 가져오기는 그중 하나만 유지합니다. consumesApi 간선은 API를 거쳐 실제로 이를 제공하는 컨테이너까지 해석됩니다.

Namespace와 lifecycle

metadata.tags는 변경 없이 넘어오고, namespace, lifecycle, type도 접두사가 붙은 태그로 함께 따라옵니다. Backstage에서 다듬어 둔 분류가 아키텍처 모델에서도 그대로 남습니다.

단계별 안내

며칠이 아니라 몇 분 만에 마이그레이션

복잡한 도구도, 수작업 재입력도 필요 없습니다.

1

카탈로그 내보내기

Backstage의 catalog API를 호출하고 응답을 저장하세요. entities 엔드포인트는 알고 있는 모든 System, Component, Resource, API를 하나의 JSON 배열로 반환합니다.

2

Backstage 형식 선택

Archyl의 가져오기 대화 상자에서 "Backstage" 탭을 선택하세요. Backstage가 내보낸 entities 배열을 가공 없이 그대로 받습니다.

3

entities.json 업로드 또는 붙여넣기

파일을 업로드하거나 내용을 붙여넣은 뒤 검증하세요. 가져오기를 확정하기 전에 Archyl이 JSON의 오류를 알려줍니다.

4

가져온 뒤 경고를 확인하기

Archyl이 모델을 구성하고, 생성한 시스템, 컨테이너, API 계약, 관계의 개수와 이름을 변경해야 했던 모든 엔티티를 보고합니다. 소유자는 나중에 지정하세요. Backstage의 Group과 User는 가져오지 않습니다.

얻게 되는 것

옮긴 뒤 Archyl이 더해 주는 것

가져오기가 끝나면, 가져온 모델 위에서 이 기능들이 바로 작동합니다.

드리프트 감지

문서가 실제 코드베이스를 얼마나 정확하게 반영하는지 보여주는 0-100% 건강 점수를 받으세요. 드리프트가 누적되기 전에 감지합니다.

규정 준수 규칙

아키텍처 규칙을 정의하고 자동 검사를 실행하여 시스템이 정의된 가드레일 내에 있도록 보장합니다.

DORA 메트릭

배포 빈도, 리드 타임, 변경 실패율 및 복구 시간을 아키텍처 건강 상태와 함께 추적합니다.

MCP 서버 (191개 도구)

191개의 전문 MCP 도구를 통해 Claude, Cursor 또는 Windsurf에서 아키텍처 데이터를 조회할 수 있습니다.

아키텍처 결정 기록

ADR을 C4 요소에 직접 연결하여 모든 설계 결정에 추적 가능한 컨텍스트를 부여합니다.

API 계약

OpenAPI, AsyncAPI 또는 GraphQL 스키마를 컨테이너와 컴포넌트에 첨부합니다. 계약을 아키텍처와 함께 버전 관리합니다.

전환 전에 팀들이 묻는 질문

Backstage를 떠나야 하나요?

아니요, 대부분의 팀은 그러지 않는 편이 낫습니다. Backstage는 개발자 포털이고 Archyl은 아키텍처 모델입니다. 가져오기는 카탈로그 내보내기 파일을 읽을 뿐 Backstage 인스턴스에는 전혀 손대지 않으므로 둘 다 계속 운영할 수 있습니다. Archyl은 평면적인 카탈로그가 답할 수 없는 질문에 답합니다. 이 서비스들이 어떻게 맞물리는지, 무엇이 코드에서 드리프트했는지, 그중 하나가 바뀌면 어떤 계약이 깨지는지.

가져오면 C4 레벨은 몇 개가 생기나요?

두 개입니다. System은 C4 레벨 1에, Component와 Resource는 둘 다 컨테이너로 레벨 2에 놓입니다. Backstage에는 Component보다 아래의 엔티티 kind가 없으므로 레벨 3을 채울 재료가 없습니다. 컴포넌트와 코드 요소는 나중에 직접 추가하거나, Archyl의 AI 발견을 저장소에 연결해 제안된 내용을 승인하면 됩니다.

소유권도 이전되나요?

아니요. User와 Group 엔티티는 건너뛰고 ownedBy 관계도 매핑하지 않으므로 spec.owner는 Archyl의 소유자가 되지 않습니다. 미리 계획해 둘 만한 부분은 이것 하나입니다. Archyl의 소유권 맵을 사용한다면 가져오기 후에 소유자를 지정하세요.

OpenAPI와 gRPC spec은 어떻게 되나요?

인라인 spec.definition이 있는 API 엔티티는 그 spec을 원문 그대로 Archyl API 계약으로 유지하며, spec.type에 따라 HTTP, gRPC, GraphQL 또는 async로 분류되고, 이를 제공하고 소비하는 컨테이너에 연결됩니다. 인라인 정의가 없는 API 엔티티도 이름, 설명, 유형은 그대로 넘어오지만 본문은 없습니다.

가져오기가 건너뛰는 것은 무엇인가요?

User와 Group 엔티티, 그리고 이를 가리키는 ownedBy 관계입니다. Location과 Template 엔티티도 마찬가지입니다. metadata.annotations와 metadata.links 블록도 건너뛰므로 TechDocs 포인터는 넘어오지 않습니다. 매핑 대상이 아닌 relations는 무시됩니다. 중복되거나 이름이 변경된 엔티티에 대해서는 가져오기가 경고를 표시합니다. 위의 kind들은 경고 없이 버려지기 때문에 이 페이지에서 이름을 밝혀 둡니다.

카탈로그에 자동 발견된 Resource가 수천 개 있습니다. 전부 들어오나요?

네. 모든 Resource를 가져옵니다. 공들여 정리한 데이터를 조용히 버리는 편이 너무 많이 가져오는 것보다 나쁘기 때문입니다. 각 컨테이너는 Backstage의 spec.type에서 가져온 유형 태그를 유지하므로 잡음이 많은 범주도 계속 식별할 수 있고, 내보내기 전에 Backstage의 filter 쿼리 파라미터로 원본에서 범위를 좁힐 수도 있습니다.

카탈로그가 바뀌면 다시 가져올 수 있나요?

네. 다시 내보내고 다시 가져오면 됩니다. Archyl은 이름으로 대조해 찾은 것은 갱신하고 새로운 것은 생성하므로, 모델이 카탈로그에서 갈라지지 않고 계속 따라갑니다. CI에서 실행하고 싶다면 동일한 가져오기를 MCP 서버의 import_dsl 도구에서 backstage 형식으로 사용할 수 있습니다.

평생 무료 플랜

카탈로그를 아키텍처로 보기

한 번 내보내고 한 번 가져오면, 이미 정리해 둔 시스템, 서비스, resource, API spec이 드리프트 감지와 규정 준수 규칙, 그 위의 MCP 서버까지 갖춘 C4 모델이 됩니다. Backstage는 하던 일을 계속합니다.

  • 신용카드 불필요
  • 5분이면 설정 완료
  • 뷰어는 언제나 무료
데모 예약빠른 시작 가이드 읽기

Backstage 카탈로그를 Archyl로 가져오기: Backstage에서 C4로

Backstage Software Catalog를 탐색 가능한 C4 모델로 바꾸세요. System, Component, Resource와 인라인 API spec을 entities.json에서 가져옵니다. 소유권은 Backstage에 남습니다.

backstage

Backstage

Backstage 가져오기

Backstage 카탈로그를 Archyl로 가져오기

Backstage는 운영 중인 것을 나열합니다. Archyl은 같은 카탈로그를 탐색 가능한 C4 모델로 바꿉니다. System은 시스템이 되고, Component와 Resource는 컨테이너가 되며, 모든 API 엔티티는 spec을 그대로 보존한 계약이 되어 이를 제공하고 소비하는 서비스에 연결됩니다. Backstage는 그대로 씁니다. 소유권은 넘어오지 않으며, 얻는 것은 두 개의 C4 레벨입니다.

Backstage 카탈로그를 Archyl로 가져오기 | Backstage에서 C4로

Backstage Software Catalog를 탐색 가능한 C4 아키텍처 모델로 바꾸세요. System, Component, Resource와 인라인 API spec을 entities.json에서 가져옵니다. 소유권은 Backstage에 남습니다.

Backstage에서 C4, Backstage 카탈로그 가져오기, Backstage 카탈로그 내보내기, Backstage 아키텍처 다이어그램, Backstage software catalog C4 모델, Backstage 아키텍처 문서화

Systems

모든 System 엔티티가 설명과 태그를 유지한 채 C4 소프트웨어 시스템이 됩니다. 서로 다른 namespace에서 이름이 같은 System 두 개는 병합되지 않고 이름이 변경되며, 어느 것이 변경되었는지는 가져오기 결과가 알려줍니다.

Components

Component는 이를 소유한 System 아래의 컨테이너가 되며, 소유 관계는 spec.system 또는 partOf 관계에서 해석됩니다. spec.type도 매핑되어 service는 서비스로, website는 웹 앱으로, cronworkflow는 워커로, library는 라이브러리로 바뀝니다.

Database

Resources

Resource도 컨테이너가 되며, 유형은 spec.type에서 결정됩니다. RDS 인스턴스와 Valkey 클러스터는 데이터베이스가 되고, Kafka 토픽과 SQS 큐는 메시지 큐가 되며, S3 버킷은 파일 스토리지가 됩니다.

FileText

API spec

API 엔티티는 Archyl의 API 계약이 됩니다. 인라인 spec.definition은 원문 그대로 유지되고, HTTP, gRPC, GraphQL 또는 async로 분류되며, 이를 제공하고 소비하는 컨테이너에 연결됩니다.

ArrowLeftRight

Relations

dependsOn, consumesApi, producesTo, consumesFrom, versionedIn은 유형이 지정된 관계가 됩니다. Backstage는 대부분의 relations를 양방향으로 내보내지만 가져오기는 그중 하나만 유지합니다. consumesApi 간선은 API를 거쳐 실제로 이를 제공하는 컨테이너까지 해석됩니다.

Namespace와 lifecycle

metadata.tags는 변경 없이 넘어오고, namespace, lifecycle, type도 접두사가 붙은 태그로 함께 따라옵니다. Backstage에서 다듬어 둔 분류가 아키텍처 모델에서도 그대로 남습니다.

카탈로그 내보내기

Backstage의 catalog API를 호출하고 응답을 저장하세요. entities 엔드포인트는 알고 있는 모든 System, Component, Resource, API를 하나의 JSON 배열로 반환합니다.

FileCode

Backstage 형식 선택

Archyl의 가져오기 대화 상자에서 "Backstage" 탭을 선택하세요. Backstage가 내보낸 entities 배열을 가공 없이 그대로 받습니다.

entities.json 업로드 또는 붙여넣기

파일을 업로드하거나 내용을 붙여넣은 뒤 검증하세요. 가져오기를 확정하기 전에 Archyl이 JSON의 오류를 알려줍니다.

가져온 뒤 경고를 확인하기

Archyl이 모델을 구성하고, 생성한 시스템, 컨테이너, API 계약, 관계의 개수와 이름을 변경해야 했던 모든 엔티티를 보고합니다. 소유자는 나중에 지정하세요. Backstage의 Group과 User는 가져오지 않습니다.

CircleCheckBig

Activity

드리프트 감지

문서가 실제 코드베이스를 얼마나 정확하게 반영하는지 보여주는 0-100% 건강 점수를 받으세요. 드리프트가 누적되기 전에 감지합니다.

규정 준수 규칙

아키텍처 규칙을 정의하고 자동 검사를 실행하여 시스템이 정의된 가드레일 내에 있도록 보장합니다.

ChartColumn

DORA 메트릭