빈 캔버스는 거짓말입니다. 당신의 아키텍처는 이미 Structurizr 파일, Terraform 모듈, Mermaid 다이어그램, README 파일에 적혀 있으니까요. AI 에이전트를 Archyl의 MCP 서버에 연결하면, 박스 하나 다시 그리지 않고 그 전부를 살아 있는 C4 모델로 바꿀 수 있습니다.

MCP로 코드, Terraform, 다이어그램을 C4 모델로 변환하기

아키텍처 문서화에서 가장 어려운 건 박스를 그리는 일이 아닙니다. 도구를 여는 그 순간, 아키텍처는 이미 존재한다는 것이죠 — 서로 대화하지 않는 다섯 군데에 흩어진 채로요.

누군가 8개월 동안 관리해 온 Structurizr DSL 파일. 십여 개의 README 속 Mermaid 다이어그램. 어떤 다이어그램보다 실제 인프라를 잘 설명하는 Terraform 모듈. 예전에 쓰던 도구에서 내보낸 PlantUML. 그리고 절대 거짓말하지 않는 유일한 소스, 코드베이스 그 자체.

토요일에는 MCP 서버 두 개와 프롬프트 하나로 Confluence 스페이스를 Archyl로 마이그레이션하는 방법을 보여드렸습니다. 오늘은 같은 트릭으로 더 큰 보상을 노립니다: 아키텍처 자체를 가져오는 겁니다.

두 가지 경로, 소스마다 골라 쓰세요

먼저 내장 경로들입니다. 리포지토리가 Archyl에 연결되어 있다면, AI Discovery가 코드를 분석해 시스템, 컨테이너, 컴포넌트, 관계까지 완전한 C4 모델을 제안하고, 당신은 검토하고 승인하면 됩니다. 그리고 다른 C4 도구에서 넘어오는 경우라면, Structurizr DSL, LikeC4, IcePanel 내보내기에는 이미 원클릭 임포터가 있습니다. 둘 중 하나가 맞아떨어지면 거기서 시작하세요.

MCP 경로는 그 나머지 전부를 위한 것입니다: Discovery가 볼 수 없는 소스들. 다이어그램-애즈-코드 파일, 인프라 정의, 누군가의 위키에 있는 아키텍처 페이지, 프라이빗 서버의 리포지토리. Archyl의 MCP 서버는 C4 모델의 전체 쓰기 표면을 노출합니다 — create_system, create_container, create_component, create_relationship, set_element_technologies, create_adr — 그래서 소스를 읽을 수 있는 에이전트라면 무엇이든 모델을 쓸 수 있습니다.

설정은 토요일과 똑같은 한 줄입니다:

claude mcp add --transport http archyl https://api.archyl.com/mcp \
  --header "X-API-Key: your_api_key"

레시피 1 — Structurizr, Mermaid, PlantUML

다이어그램-애즈-코드는 가장 쉬운 승리입니다. 의미가 이미 명시적으로 적혀 있으니까요. 표준적인 workspace.dsl이라면 위의 원클릭 임포터가 더 빠릅니다 — 에이전트가 제 몫을 하는 건 Mermaid와 PlantUML(임포터가 없습니다), 임포터가 파싱하지 못하는 DSL 변형, 또는 이미 모델이 있는 프로젝트에 선택적으로 병합하고 싶을 때입니다. Claude Code에서 리포지토리를 열고:

이 리포지토리 루트의 workspace.dsl을 읽어줘. 내 Archyl 프로젝트
"Aurora Commerce"에 모델을 재현해줘:

- softwareSystem → create_system (외부 시스템은 external_system으로
  표시)
- container → 올바른 시스템 아래에 create_container, technology
  필드는 유지
- 모든 관계 → 설명과 함께 create_relationship
- DSL에 없는 건 아무것도 지어내지 마. 매핑하지 못한 게 있으면
  목록으로 알려줘.

끝나면 list_systems와 list_containers로 모델을 다시 읽어서
요약을 보여줘. 빠진 게 없는지 확인할 수 있게.

마지막의 읽기 확인 단계는 계속 가져갈 만한 습관입니다: 에이전트가 잘 됐겠거니 하고 넘어가는 대신, 라이브 모델을 상대로 자신의 가져오기를 직접 검증하는 것이죠.

레시피 2 — Terraform

인프라 코드는 다이어그램이 잊어버린 것들을 알고 있습니다. 에이전트를 Terraform으로 향하게 하고, 딱 맞는 고도에서 작업하게 하세요:

이 리포지토리의 infra/를 읽어줘. 배포 수준의 아키텍처를 Archyl에
모델링해줘: 매니지드 서비스(RDS, SQS, S3, CloudFront...)는
컨테이너나 외부 시스템으로 만들되, 실제 서비스당 하나씩 —
리소스당 하나가 아니라. 관계는 IAM 정책, 시큐리티 그룹, 환경
변수에서 찾아 연결해줘. 나중에 가져온 레이어만 필터링할 수
있도록, 만드는 것 전부에 "terraform" 태그를 붙여줘.

"리소스당 하나가 아니라"라는 한 줄이 진짜 일을 합니다. 순진한 임포터는 Terraform 리소스 400개를 박스 400개로 만듭니다. 에이전트는 DB 인스턴스와 그 서브넷 그룹, 파라미터 그룹이 _Orders Database_라는 하나의 컨테이너라는 것을 이해합니다.

레시피 3 — 코드베이스 그 자체

DSL도 없고, 다이어그램도 없고, 리포지토리가 Archyl에 연결되어 있지도 않다면? 에이전트는 이미 당신의 코드 안에 앉아 있습니다. 모델을 바텀업으로 제안해 달라고 하세요 — 배포 매니페스트에서 서비스를, 패키지 구조에서 컴포넌트를, 에이전트가 찾아낸 HTTP 클라이언트와 큐 프로듀서에서 관계를. AI Discovery의 일을 손으로 하는 셈이고, Discovery가 소스에 닿을 수 없을 때의 올바른 대안입니다.

레시피 4 — 위키에 갇힌 다이어그램

토요일 포스트의 MCP 서버 두 개를 결합하세요: 에이전트가 Atlassian MCP 서버로 아키텍처 페이지를 읽고, 거기 설명된 시스템과 플로우를 추출해 Archyl에 씁니다. 이벤트 파이프라인을 설명하던 위키 페이지가 실제로 탐색 가능한 모델이 되고 — 그 페이지 자체도 연결된 문서로 함께 들어옵니다.

가져오기는 지루한 부분입니다 — 진짜 핵심은 이겁니다

가져온 다음 날, 그게 바로 이 일을 한 이유입니다. 모델이 MCP를 통해 들어왔기 때문에, MCP를 통해 계속 닿을 수 있습니다:

에이전트들이 코딩하면서 모델을 조회합니다 — "어떤 컨테이너가 결제 데이터베이스와 통신하지?"가 도구 호출 한 번 거리입니다.
새 서비스는 그것을 만든 바로 그 에이전트가 모델에 추가합니다. 모델은 썩어 가는 대신 현실을 따라갑니다.
드리프트 점수와 컨포먼스 규칙이 실제 시스템과 일치하는 모델 위에서 돌아갑니다.

마무리로 솔직한 규칙 하나: 에이전트는 제안하고, 당신이 리뷰합니다. 시스템을 하나씩 가져오고, 요약을 읽고, 어울리지 않는 것은 쳐내세요 — 여느 코드 리뷰와 똑같은 규율입니다. 결국 손에 쥐는 모델은 먹인 소스만큼만 좋고, 다섯 소스 중 어느 것이 진실을 말하고 있었는지 아는 사람은 당신뿐입니다.

당신의 아키텍처는 이미 존재합니다. 다시 그리지 말고, 가져오세요. 전체 도구 목록은 MCP 서버 문서에 있습니다.

MCP로 코드, Terraform, 다이어그램을 C4 모델로 변환하기 - Archyl Blog