비교
MapleSpire와 Structurizr: 엔터프라이즈 거버넌스에 더 잘 맞는 것은?
Structurizr와 MapleSpire는 모두 C4 모델을 바탕으로 하며, 그림이 아닌 실제 모델을 다룹니다. 둘은 큰 조직에서 결정적인 질문에서 갈립니다. 공유 메타데이터가 어디에 있고, 누가 그것을 최신 상태로 유지할 수 있는가 하는 질문입니다.
Structurizr는 아키텍처가 코드이고 엔지니어링 팀이 Git에서 작성하고 리뷰할 때 빛을 발합니다. MapleSpire는 거버넌스가 적용된 저장소를 지향합니다. 조직 전체에 하나뿐인 태그·기술 카탈로그를 두고, 권한이 있는 사람이라면 누구나 시각적으로 편집할 수 있습니다.
두 가지 모델링 철학
Structurizr는 ‘모델을 코드로’ 다루는 도구입니다. 아키텍처를 텍스트 DSL로 작성해 Git에서 버전을 관리하고, 다이어그램을 렌더링하는 서버로 푸시합니다. 문서에서는 소프트웨어 시스템마다 하나의 workspace를 두고, 그 시스템을 만드는 팀이 소유하도록 권장합니다.
MapleSpire는 공유되는 시각적 모델입니다. 객체, 관계, 뷰가 데이터베이스에 저장되고, 여러 사람이 실시간으로 함께 편집하며, 오프라인에서도 계속 사용할 수 있습니다. 태그와 기술 카탈로그는 모든 파일에 복사되는 텍스트가 아니라 조직 수준의 엔터티입니다.
어느 쪽이 본질적으로 더 낫다고 할 수는 없습니다. 차이는 팀, 시스템, 기여자의 수가 늘어날 때 드러납니다.
메타데이터 지정: 태그, 기술, 버전, 그룹
| 메타데이터 | Structurizr | MapleSpire |
|---|---|---|
| 태그 | 요소별 자유 텍스트(tags "A,B"), 스타일은 태그 텍스트에 연결 | 태그와 태그 그룹을 조직에서 한 번 정의하고 ID로 참조 |
| 태그 이름 변경 또는 병합 | 모든 workspace에서 찾아 바꾸기 | 이름 변경, 색상 변경, 병합, 보관: 모든 랜드스케이프에 일괄 적용 |
| 기술 | 자유 텍스트(technology "Java") | 관리형 카탈로그: 별칭, 라이트·다크 아이콘, 문서 링크 |
| 기술 수명 주기 | 모델링되지 않음 | 활성, 지원 중단, 퇴출, 병합; 새 항목은 승인을 거침 |
| 사용 중인 버전 | 텍스트나 properties에 직접 추가 | 기술을 사용할 때마다 버전을 기록 |
| 그룹과 도메인 | DSL에서 선언하는 시각적 그룹 | 태그와 기술을 가질 수 있는 그룹, 계층형 도메인 |
| 사용자 정의 속성 | properties와 perspectives(자유로운 키-값 쌍) | 모델에 계획되어 있으나 아직 화면에서 편집 불가 |
Structurizr에서는 tags, technology, properties, perspectives 키워드로 요소를 설명합니다. 이는 요소마다 직접 입력하는 자유 문자열입니다. archetypes가 기본값을 제공하고 스타일은 태그에 연결되지만, 유효한 태그나 기술이 무엇인지 정의하는 중앙 레지스트리는 없습니다.
실제로는 ‘PostgreSQL’, ‘Postgres’, ‘postgresql 16’이 여러 workspace에 함께 존재할 수 있습니다. 태그 이름을 바꾸려면 관련된 모든 저장소에서 찾아 바꾸기를 해야 하고, 조직이 퇴출한 기술을 누군가 사용하는 것을 막을 방법도 없습니다.
MapleSpire에서 객체는 태그의 텍스트가 아니라, 조직에서 한 번만 정의된 태그에 대한 참조를 저장합니다. 기술은 별칭, 아이콘, 수명 주기를 갖춘 관리형 카탈로그에서 가져옵니다.
담당자는 어떻게 하나요?
소유권, 즉 어떤 팀이 그 요소를 책임지는지는 거버넌스 프로세스가 가장 먼저 요구하는 메타데이터인 경우가 많습니다. Structurizr에서는 owner 키 같은 자유 속성에 기록하며, 팀 디렉터리와는 연결되지 않습니다.
MapleSpire는 이미 접근 제어를 위해 팀을 관리하고 있으며, 모델에는 객체에 담당 팀을 지정하는 계획이 포함되어 있습니다. 다만 이 지정 기능은 아직 화면에서 제공되지 않습니다. 약속하기보다 솔직하게 말씀드리는 편을 택했습니다.
한 번 업데이트하면 모두에게
엔터프라이즈 뷰를 위해 Structurizr는 세 단계 방식을 제안합니다. 소프트웨어 시스템을 URL로 공유하는 DSL 카탈로그에 모으고, 각 팀의 workspace가 그 카탈로그를 확장하게 한 뒤, 전체 랜드스케이프를 생성하는 방식입니다. 이 랜드스케이프는 관리자가 모든 workspace를 가져와 생성기를 실행하고 결과를 푸시해 만듭니다. 사본이기 때문에 이후 변경 사항을 반영하려면 다시 생성해야 합니다.
MapleSpire에서는 태그와 기술이 조직의 데이터베이스에 있습니다. 관리 콘솔에서 바꾼 내용은 별도의 게시 단계 없이 모든 랜드스케이프에 즉시 반영됩니다. 하나의 랜드스케이프 안에서 각 객체는 한 번만 존재하고, 모든 다이어그램이 그것을 참조합니다.
정확성을 위해 두 가지를 덧붙입니다. MapleSpire에서도 상세 모델은 각 랜드스케이프 범위에 머물며, 조직 전체에서 공유되는 것은 카탈로그뿐입니다. 또한 기술을 사용할 때마다 기록 당시의 카탈로그 리비전이 보존되므로, 카탈로그를 바꿔도 이력이 조용히 다시 쓰이는 일은 없습니다.
접근 제어와 변경 리뷰
Structurizr server의 오픈 소스 코어에는 인증도 역할 기반 접근 제어도 없어 workspace가 공개됩니다. 역할, SAML, LDAP, 관리 API는 라이선스가 필요한 사전 빌드 바이너리에 포함됩니다. 이 도구의 큰 강점은 다른 데 있습니다. 모델이 코드이므로 모든 변경이 풀 리퀘스트, 리뷰, CI 자동 검증을 거칠 수 있습니다.
MapleSpire의 AGPL-3.0 코드에는 조직 역할, 랜드스케이프별 읽기·쓰기 권한을 가진 팀, Google 또는 Microsoft를 통한 OIDC 싱글 사인온, 관리 작업 감사 로그가 포함되어 있습니다. 변경은 초안에서 준비하고, 변경 목록을 검토한 뒤 충돌을 감지하는 병합으로 반영합니다.
현재의 한계: MapleSpire 초안에는 아직 병합 전 공식 승인 단계가 없습니다. 거버넌스에서 모든 변경에 대한 필수 리뷰를 요구한다면, 지금은 Structurizr의 풀 리퀘스트 흐름이 더 엄격합니다.
어느 쪽이 더 잘 확장될까?
| 기준 | Structurizr | MapleSpire |
|---|---|---|
| 팀 간 일관된 용어 | 규율과 리뷰에 달려 있음 | 단일 카탈로그로 강제 |
| 개발자가 아닌 기여자 | DSL과 Git을 배워야 함 | 시각적, 다중 사용자, 실시간 편집 |
| 최신 상태의 전체 그림 | 필요할 때 랜드스케이프 재생성 | 실시간 공유 카탈로그, 상세 모델은 랜드스케이프 단위 |
| 필수 변경 리뷰 | 풀 리퀘스트와 CI | 초안과 병합, 아직 공식 승인 없음 |
| 접근 제어와 SSO | 라이선스 바이너리 | 오픈 소스 코드에 포함 |
| 고가용성 | 선택한 스토리지와 라이선스에 따라 다름 | 동기화는 당분간 단일 인스턴스로 실행 |
조직 전체가 같은 언어(같은 태그, 기술, 버전)를 쓰게 하고, Git을 일상적으로 쓰지 않는 아키텍트, 제품 책임자, 팀까지 참여시키는 것이 과제라면 거버넌스 측면에서 MapleSpire가 더 잘 확장됩니다.
아키텍처를 이미 코드로 관리하고, 기여자가 개발자이며, 거버넌스가 풀 리퀘스트 리뷰로 이루어진다면 Structurizr는 여전히 훌륭한 선택입니다.
마이그레이션하거나 함께 쓰기
MapleSpire는 Structurizr DSL workspace를 가져와 그에 맞는 C4 다이어그램을 생성합니다. 또한 Structurizr DSL, Mermaid, JSON, CSV, SVG, PNG, Markdown으로 내보낼 수 있어, 기존 파일을 포기하지 않고도 기존 workspace로 MapleSpire를 시험해 볼 수 있습니다.
출처
Structurizr에 관한 내용은 2026년 10월 12일에 확인한 공식 문서를 근거로 합니다. 여기서 설명한 MapleSpire 기능은 공개된 코드에 있는 기능입니다.