Structurizr Cloud, 9월 30일 종료: 모델부터 먼저 빼내세요

Structurizr의 클라우드 서비스가 수명을 다합니다. 그들의 end-of-life 페이지에는 "Structurizr cloud service (no replacement)"가 Lite, CLI, 온프레미스 설치본과 나란히 올라 있고, 이들 모두 새로 통합된 툴링으로 대체됩니다. 그들의 종료 공지에 따르면 워크스페이스는 2026년 7월 1일부로 읽기 전용이 되었고, 남아 있던 월간 구독도 같은 날 중단되었으며, 서비스는 2026년 9월 30일에 종료됩니다. 이 공지는 Patreon 안에 있으니, 날짜를 기준으로 계획을 세우기 전에 직접 확인해 보세요.

읽기 전용이 된 것 자체는 비상 상황이 아닙니다. 비상 상황은 읽기 전용이 가리고 있는 쪽입니다. 워크스페이스를 빼내는 데 쓸 도구들이, 바로 그 닫히는 서비스의 일부라는 점입니다. 워크스페이스 에디터의 DSL 탭, 대시보드의 내보내기 링크, 웹 API. 이 전부가 클라우드 서비스입니다. 10월 1일에는 클릭할 탭이 없습니다.

그러니 첫 번째 결정은 어떤 도구로 옮길지가 아닙니다. 파일 하나를 내 디스크에 내려받는 것입니다. 그건 워크스페이스마다 복사해서 붙여넣는 작업일 뿐이고, 아무것도 약속하지 않습니다. 목적지를 고르는 일은 그 둘 중 어느 쪽도 아닙니다.

모델을 빼내세요

이 부분을 먼저 하세요. 아래에 있는 어떤 내용을 읽기도 전에요.

당신의 워크스페이스는 읽기 전용이지, 보이지 않게 된 것이 아닙니다. Structurizr의 클라우드 서비스 FAQ는 읽기 전용 워크스페이스에 대해 이렇게 말합니다. "You can still view the workspace content (via the UI and web API) but no changes can be made" — 워크스페이스 내용은 (UI와 웹 API를 통해) 계속 볼 수 있지만 어떤 변경도 할 수 없습니다. 아래 내용은 전부 오늘은 동작합니다.

DSL로 작성하고 CLI로 push해 왔다면, 이미 끝났을 수도 있습니다. 당신의 workspace.dsl은 Git에 있습니다. 열어서 최신인지 확인하세요. 딱 하나 확인할 것이 있습니다. 브라우저 다이어그램 에디터에서 손으로 조정한 레이아웃은 클라우드 사본에 있지, 당신의 DSL에는 없습니다. 그게 중요하다면 2단계의 JSON 내보내기도 함께 챙기세요.

브라우저에서, 또는 Workspace API를 통해 작성했다면, 당신의 모델은 Structurizr의 데이터베이스 안에만 존재합니다. 다음 순서대로 하세요.

  1. DSL. Structurizr가 기존 사용자에게 하는 조언은 DSL로 변환하라는 것입니다. 그들의 워크스페이스 에디터 도움말 페이지에서: "A DSL representation of your workspace (excluding documentation) can be found on the DSL tab" — 워크스페이스의 DSL 표현(문서 제외)은 DSL 탭에서 찾을 수 있습니다. 워크스페이스 에디터 자체는 2022년 2월에 중단되었지만, https://structurizr.com/workspace/XXXXX/workspace-editor 형태의 URL로는 여전히 접근할 수 있습니다. XXXXX는 당신의 워크스페이스 ID입니다. 열어서 DSL 탭을 클릭하고, 전부 복사해서 workspace.dsl로 저장하세요.

    그들 문장의 괄호를 눈여겨보세요. DSL 표현에는 문서가 포함되지 않습니다. !docs와 !adrs를 리포지토리의 Markdown 파일로 향하게 하는 대신 워크스페이스 안에 문서나 ADR을 써 두었다면, DSL 탭은 그것을 돌려주지 않습니다.

  2. JSON. Structurizr의 마이그레이션 안내는 페이지 상단의 "export your workspaces" 링크로 안내합니다. 이 링크가 workspace.json을 만들어 줍니다. 이미 DSL이 있어도 함께 받아 두세요. Structurizr 자신의 playground와 local이 모두 받아들이는 형식이고, local은 workspace.dsl과 workspace.json을 그 순서로 찾습니다.

  3. 이 두 파일이 놓치는 모든 것. 워크스페이스 안에 쓴 문서, 업로드한 이미지, 상태 이력이 딸린 결정 기록. UI가 아직 살아 있는 동안 UI에서 워크스페이스를 열고, 중요한 것을 Markdown으로 복사해 두세요.

  4. 두 파일 모두 리포지토리에 commit하세요. 노트북 폴더가 아닙니다. 리포지토리, 그것도 그 파일들이 설명하는 코드 옆, 다음 사람이 찾아낼 자리여야 합니다.

워크스페이스마다 반복하세요. 열두 개가 있다면, 나중에 다시 오겠다고 스스로에게 약속하지 말고 한자리에서 끝내세요.

한 가지 확인하지 못한 것이 있습니다. 9월 30일에 워크스페이스 데이터가 삭제되는 것인지, 단지 접근할 수 없게 되는 것인지에 대해 Structurizr가 공개한 내용을 저는 어디에서도 찾지 못했습니다. 10월에 돌려달라고 요청할 수 있다고 단정하지 마세요. 그렇다고 요청할 수 없다고 단정하지도 마세요. 파일을 확보하세요.

어디에 둘 것인가

정직한 선택지 네 가지입니다. 각각 어울리는 팀이 다르고, 그중 셋은 archyl이 아닙니다.

선택지 1: Structurizr 자신의 툴링

어떤 벤더 블로그가 말해 주는 것보다 훨씬 많은 팀에게 이것이 정답이며, 가장 먼저 비용을 따져 봐야 할 선택지입니다.

Structurizr가 사라지는 게 아닙니다. 사라지는 건 클라우드 서비스입니다. 그들의 EOL 페이지는 옛 제품을 새 제품에 대응시킵니다. Lite는 local로, CLI는 pull / push / export로, 온프레미스 설치본은 server로 대체됩니다. 오늘 Lite나 CLI를 쓰고 있다면 당신 앞에도 마이그레이션이 있습니다. 다만 훨씬 작은 규모일 뿐입니다.

  • **local**은 문서에서 이렇게 설명됩니다. "the free and open source local command provides a way to view diagrams and modify their layout" — 무료이며 오픈소스인 local 명령은 다이어그램을 보고 레이아웃을 수정하는 방법을 제공합니다. 당신의 머신에서 localhost에 바인딩되어 돌아갑니다. 그들의 퀵스타트는 명령 두 개입니다. docker pull structurizr/structurizr, 그다음 docker run -it --rm -p 8080:8080 -v PATH:/usr/local/structurizr structurizr/structurizr local. workspace.dsl이 들어 있는 디렉터리를 가리키게 하고, http://localhost:8080을 열고, 파일을 편집하고, 브라우저를 새로 고치면 됩니다.
  • playground는 가끔 쓰는 경우에 대한 그들의 제안입니다. workspace.dsl이나 workspace.json을 업로드하고, 다이어그램을 보고, 탭을 닫으면 됩니다.
  • **server**는 클라우드 서비스가 당신을 위해 하던 일, 즉 워크스페이스를 더 넓은 청중에게 공개하는 일을 대체하는 것입니다. 소스에서 직접 빌드하면 무료인 오픈 코어가 있고, 파일 시스템 스토리지와 Lucene 검색을 갖췄으며 인증은 없습니다. 미리 빌드된 바이너리는 여기에 SAML, 역할 기반 접근 제어, 비공개 공유 토큰, S3 및 Azure Blob 스토리지, Elasticsearch, 관리자 API를 더하고 라이선스가 필요합니다. 고유 사용자 120명은 월 £300, 2150명은 £600, 51~100명은 £900이며 연 단위로 청구됩니다. 그들이 말하는 고유 사용자에는 iframe이나 삽입된 이미지를 통한 경우까지 포함해 다이어그램을 보는 모든 사람이 들어가며, 편집자만 세는 것이 아닙니다.

어울리는 팀: 모델이 이미 Git 안의 DSL이고, 읽는 사람이 엔지니어이며, 클라우드 서비스의 주된 용도가 렌더링이었던 팀. DSL을 지금 그대로 유지하고, 우리 자신의 임포터가 버리는 deployment 뷰와 dynamic 뷰도 그대로 유지하며, 그 툴링은 C4 모델을 만든 바로 그 사람이 씁니다. 그게 당신이라면, 여기서 읽기를 멈추고 Docker 명령을 실행하러 가세요.

어울리지 않는 팀: 당신이 서버를 운영하지 않으면서도 비엔지니어 백 명이 다이어그램을 둘러봐야 하는 팀, 그리고 열람자 스무 명에 월 £300이 편집자 단위 SaaS 가격보다 나쁘게 읽히는 팀. 그리고 하나 더, 이 글의 나머지 전부가 기대고 있는 논지가 있습니다. 셀프 호스팅은 당신의 모델을 보존할 뿐, 유지해 주지는 않습니다. 클라우드에서 낡아 가던 워크스페이스는 local에서도 똑같이 낡아 갑니다. 코드가 바뀌었다고 DSL을 다시 돌리는 사람은 없습니다.

선택지 2: DSL을 리포지토리에 두고, 도구 비용은 그만 내기

가장 과소평가된 선택지이자 가장 저렴한 선택지입니다.

workspace.dsl을 Git에 두고, 다른 모든 것과 마찬가지로 풀 리퀘스트에서 리뷰하고, 누군가 정말로 그림이 필요할 때 그때그때 렌더링합니다. local이 컨테이너 안에서 렌더링해 줍니다. playground도 마찬가지입니다. Structurizr 문법에서 아예 벗어나고 싶다면, LikeC4는 MIT 라이선스이고 리포지토리 안의 .c4 파일로 작성하며 Vite 플러그인, React 컴포넌트, 웹 컴포넌트를 통해 배포되므로, 이미 운영 중인 문서 사이트에 다이어그램을 끼워 넣을 수 있습니다.

어울리는 팀: 다이어그램의 독자가 DSL을 읽을 수 있는 몇 안 되는 엔지니어들이고, "이걸 대체 얼마나 자주 열어 보나?"라는 질문에 대한 정직한 답이 "온보딩 때와 장애 때"인 팀. 쓰고 있던 것 중 잃는 것은 없고, 반복 비용은 0이 됩니다.

어울리지 않는 팀: 리포지토리를 clone하지 않을 사람들이 다이어그램을 읽는 모든 경우. 그리고 그건, 당신이 클라우드 서비스에 돈을 내고 있었다면, 바로 그 돈을 내던 이유일지도 모릅니다.

선택지 3: 다른 호스팅형 C4 도구

클라우드 서비스가 당신에게 실제로 일을 해 주고 있었다면, 다른 호스팅형 도구로 대체하는 것은 합리적인 선택입니다. 그리고 한 곳만 보지 말고 여러 곳을 봐야 합니다.

IcePanel이 가장 비슷한 대체재입니다. 비주얼 우선의 C4 도구로, 호스팅 서비스가 있고 무료 등급은 편집자 5명, 열람자 무제한, 모델 오브젝트 최대 100개까지이며, 유료 플랜은 연 단위 청구 기준 편집자 1인당 월 $40부터 시작합니다. 그들 자신의 Structurizr 비교 글에는 "model objects can be imported from Structurizr, Backstage, and a REST API" — 모델 오브젝트는 Structurizr, Backstage, REST API에서 가져올 수 있다고 적혀 있습니다. 제가 접근할 수 있었던 페이지들에서는 어떤 파일 형식을 받는지 문서화된 것을 찾지 못했습니다. 그러니 결정하기 전에, 위 섹션에서 빼낸 바로 그 파일을 업로드해서 무엇이 살아남는지 확인하세요. 이 조언은 이 글에 나오는 모든 도구에 적용됩니다. 우리 것도 포함해서요.

어울리는 팀: 드래그 앤 드롭 에디터를 원하고, 열람자가 엔지니어가 아닌 팀.

어울리지 않는 팀: 모델이 텍스트였기 때문에 Structurizr로 옮겨 온 팀. 클라우드 종료에서 벗어나려고 architecture-as-code를 포기하는 것은 이상한 거래이고, 변경 사항을 diff로 보고 싶어지는 첫 순간에 그것을 실감하게 됩니다.

선택지 4: archyl

우리는 Structurizr DSL 임포터를 만들었습니다. 그러니 이건 제가 가장 잘 아는 선택지이자, 당신이 가장 회의적으로 읽어야 할 선택지입니다.

workspace.json이 아니라 workspace.dsl을 가져오세요. archyl은 Structurizr DSL 텍스트를 파싱합니다. 워크스페이스 JSON 경로는 없습니다. 내보내기 링크에서 JSON만 받았다면, 시도하기 전에 아래 섹션을 보세요.

프로젝트를 열고, 임포트 모달에서 Structurizr DSL을 고르고, .dsl 파일을 업로드하거나 붙여넣으세요. 넘어오는 것: 최상위의 person과 softwareSystem, 중첩된 container와 component, 이름과 설명, 컨테이너와 컴포넌트 그리고 관계에 붙은 기술 문자열, 쉼표로 구분된 태그, 어느 깊이에 있든 group:<name> 태그로 평탄화되는 group 블록, 그리고 요소 본문 안을 포함해 파일 어디에 선언되어 있든 관계 전부. 컨테이너와 관계의 타입은 당신의 기술 문자열과 레이블 문자열에서 추론됩니다. 외부 시스템은 External System 또는 External 태그로 골라냅니다. 임포터는 Simon Brown 본인의 Big Bank 샘플 워크스페이스로 테스트되어 있습니다.

넘어오지 않는 것, 이쪽이 더 중요합니다.

  • 모든 레이아웃과 스타일. views, configuration, styles 블록은 건너뜁니다. 대신 archyl이 다이어그램을 자동 배치합니다. 수동 레이아웃은 Structurizr가 내세워 파는 것 중 하나이니, 이건 당신의 예전 도구가 가장 잘하던 바로 그 부분이고, 당신은 그것을 포기하는 셈입니다.
  • !docs와 !adrs. 지시어는 건너뜁니다. archyl에 ADR과 문서 기능이 있긴 하지만, Structurizr 임포터가 그것을 채워 주지는 않습니다.
  • !include. 여러 파일로 나뉜 워크스페이스는 임포트 전에 하나로 합쳐야 합니다. 그렇지 않으면 include된 내용은 그냥 없습니다.
  • deployment 환경, deployment node, infrastructure node. 임포트되지 않습니다.

임포터는 그 대부분을 임포트 결과 화면에 경고 목록으로, 소스 파일 자신의 용어 그대로 되돌려 줍니다.

line 42: 'views' block is not supported and was skipped
line 7: directive '!docs' is not supported and was skipped

여기에 두 가지 단서를 답니다. 믿을 수 있는 목록이 우리를 치켜세우는 목록보다 더 값어치가 있기 때문입니다. 첫째, deployment 환경과 노드는 건너뜁니다. archyl이 다루는 것은 정적 구조이지 배포 토폴로지가 아니기 때문입니다. 파서가 경고 목록에 줄 번호와 함께 이름을 남기므로, deploymentEnvironment "Live" 블록은 나중에 알게 되는 것이 아니라 읽을 수 있는 한 줄로 도착합니다. 둘째, 경고는 파서가 거부한 것을 알려 줄 뿐, 나머지 임포트가 완벽했다고 알려 주지는 않습니다. 임포트가 끝난 뒤 모델을 직접 읽어 보세요.

local을 돌리는 대신 여기에 돈을 낼 유일한 근거: archyl은 모델을 리포지토리와 다시 대조해 그 간극에 점수를 매깁니다. 그래서 코드와 어긋나기 시작한 모델은 조용히 틀린 것이 되는 대신, 어긋났다고 스스로 말합니다. 그게 드리프트 스코어이고, 결정론적이며, AI 호출 없이 동작합니다. 클라우드가 읽기 전용이 되던 날 당신의 Structurizr 워크스페이스가 정확하고 최신이었다면, 이건 필요 없고 저도 팔려고 하지 않겠습니다. 열여덟 달째 낡아 있었다면, 애초에 문제는 도구가 아니었고, 그것을 다른 곳으로 옮긴다고 해결되지도 않습니다.

우리에게 불리하게 따져야 할 두 가지. 무료 Developer 플랜은 프로젝트당 모델 오브젝트를 100개로 제한하므로, 시스템 쉰 개와 그 컨테이너들이 있는 워크스페이스는 들어가지 않습니다. 그리고 archyl은 클라우드 우선이고 셀프 호스팅은 Custom 등급에서만 가능합니다. 날짜가 실린 바로 그 공지에서 Structurizr가 클라우드 서비스를 닫는 이유로 든 것은, 엔지니어링 팀들이 아키텍처 다이어그램을 클라우드에 올리기를 꺼려 왔고 사용량이 꾸준히 줄어들었다는 점이었습니다. 그게 당신의 보안 팀 이야기라면, 선택지 1이 우리보다 잘 맞습니다. 그리고 그 사실을 구매 절차 안에서 2주 걸려 발견하는 일은 없어야 합니다.

가진 게 JSON 파일뿐이라면

대시보드의 내보내기 링크는 workspace.json을 주고, 대부분의 사람이 결국 손에 쥐게 될 파일도 이것입니다. 어디에서 통하는가:

  • Structurizr local과 playground는 이 파일을 그대로 읽습니다. 변환할 것이 없습니다.
  • archyl은 읽지 않습니다. 대신 DSL 탭에서 DSL을 받아 오세요. 그것도 9월 30일 전에요. 워크스페이스가 Workspace API로 작성되어 DSL 탭이 쓸 만한 것을 주지 못한다면 대안이 두 가지 있습니다. 리포지토리를 연결해서 AI 디스커버리가 코드에서 모델을 제안하게 하거나, 코딩 에이전트를 그 JSON에 붙여서 MCP 서버를 통해 모델을 쓰게 하는 것입니다. 후자의 방법은 여기에 정리해 두었습니다.
  • 그 밖의 어디든: 마이그레이션한 뒤가 아니라, 하기 전에 물어보세요.

한 문단으로 정리하는 선택

모델이 이미 Git 안의 DSL이고 읽는 사람이 엔지니어라면, local을 돌리고 아낀 돈은 다른 데 쓰세요. 공유 가능하고 접근이 통제되는 인스턴스가 필요하고 라이선스 비용을 감당할 수 있다면, server가 클라우드 서비스가 해 주던 일에 가장 가깝습니다. 비주얼 에디터와 비기술직 열람자가 필요하다면 IcePanel을 보세요. 방금 내보낸 워크스페이스가 이미 낡아 있었고, 그것이 낡은 이유가 손으로 갱신하는 일이 누군가의 네 번째 우선순위였기 때문이라면, 교체해야 할 것은 도구가 아닙니다. 그리고 그게 바로 archyl이 하는 주장입니다.

무엇을 고르든: 파일부터 먼저 빼내세요. 탭은 서비스와 함께 사라집니다.

작동 방식에 대해 더 보려면 Structurizr, LikeC4, IcePanel 프로젝트 임포트하기, Structurizr 마이그레이션 페이지, 2026년 C4 도구 비교를 참고하세요. 모델 자체가 처음이라면 C4 모델과 아키텍처 드리프트부터 시작하세요.