Claude에게 아키텍처 그림 맡길 수 있을까 2026 — mermaid·draw.io·diagram workflow가 진짜 실무에 먹히는 조건

Posted on by

이거 한 번쯤 다들 궁금해한다.

Claude한테 아키텍처 그림까지 시키면 되지 않나?

겉으로 보면 엄청 그럴듯하다. 요구사항도 읽고, 코드도 보고, 문서도 보고, 그림까지 뽑으면 생산성이 끝장날 것 같다.

근데 실무는 그렇게 단순하지 않다.

그림은 예쁘게 나오는데, 회의에서 바로 못 쓰거나, 리뷰에서 경계가 틀리거나, 나중에 코드와 어긋나는 순간이 온다.

그래서 이 글은 Claude가 그림을 그릴 수 있냐보다 어떤 조건에서 맡겨야 실무가 덜 깨지냐에 더 가깝다.

이 글이 필요한 사람

  • 시스템 구조를 자주 설명해야 하는 개발자
  • PR마다 다이어그램을 붙이고 싶은데 매번 시간이 아까운 사람
  • mermaid는 빠른데 stakeholder 공유용으로는 약하다고 느끼는 사람
  • draw.io는 좋은데 매번 손으로 다시 그리기 귀찮은 사람
  • Claude를 쓰긴 쓰는데, 그림은 어디까지 믿어도 되는지 감이 없는 사람

지금 결론

짧게 말하면 이렇다.

Claude에게 아키텍처 그림을 맡기는 건 충분히 가능하다.

다만 무조건 그림부터가 아니라 텍스트 스펙 -> 초안 다이어그램 -> 사람 검토 -> 외부 공유본 순서로 가야 한다.

실무에서 가장 안전한 조합은 대체로 이렇다.

용도 도구 이유
초안 생성 Claude + mermaid 빠르고 수정이 쉽다
팀 내부 리뷰 mermaid 또는 draw.io 차이를 빨리 잡아낸다
대외 공유 draw.io 또는 export된 이미지 비개발자도 보기 쉽다
자동화/재생성 Claude Code + 템플릿 반복 수정 비용을 줄인다

즉, Claude는 디자이너라기보다 초안 작성자에 가깝다.

그림의 정답을 자동으로 아는 게 아니라, 텍스트를 빨리 도식으로 바꾸는 역할에 더 강하다.

왜 이게 생각보다 어려운가

아키텍처 그림은 단순한 선 그림이 아니다.

그림 하나에 최소한 아래 정보가 같이 들어간다.

  • 시스템 경계
  • 데이터 흐름
  • 동기/비동기 구분
  • 신뢰 경계
  • 운영 주체
  • 장애 지점
  • 외부 의존성

문제는 Claude가 이걸 그림으로는 잘 보여줘도, 경계를 잘못 잡으면 그럴듯한 오답이 된다는 점이다.

예를 들면,

  • 로깅과 트래픽 경로를 섞는다
  • 내부 큐와 외부 API를 같은 레벨로 놓는다
  • 운영자만 보는 경로와 사용자 경로를 구분하지 않는다
  • 보안 경계를 점선으로 그어야 하는데 그냥 선으로 넘긴다

이런 건 그림이 예뻐도 망한 그림이다.

추천 워크플로

Claude에게 바로 그림 그려줘라고 던지는 대신 아래처럼 쪼개면 훨씬 낫다.

  1. 텍스트로 시스템 경계를 먼저 적는다
  2. mermaid로 1차 초안을 만든다
  3. draw.io로 stakeholder용 버전을 만든다
  4. 다이어그램이 코드와 어긋나는지 체크한다
  5. 변경되면 템플릿에서 다시 생성한다

이 흐름의 핵심은 그림이 아니라 재생성 가능성이다.

그림은 수동으로 예쁘게 그릴수록 나중에 업데이트가 귀찮아진다.

반대로 Claude가 텍스트 스펙에서 재생성하게 만들면, 변경 비용이 확 내려간다.

비교표

방식 장점 약점 언제 쓰나
손그림 빠른 사고 정리 재사용이 어렵다 브레인스토밍 초반
mermaid 텍스트 기반, 버전 관리 쉬움 복잡한 레이아웃이 약함 PR, 문서, 설계 초안
draw.io 보기 좋고 공유 쉽다 수동 수정이 많다 리뷰, 발표, 외부 공유
Claude 단독 생성 초안 속도가 빠르다 경계 오류가 섞일 수 있다 구조 초안 생성
Claude + 템플릿 반복 작업에 강하다 템플릿 설계가 필요하다 운영용 다이어그램

여기서 중요한 건 Claude가 무엇을 대체하느냐다.

손그림을 대체하면 초반 속도는 올라간다.

draw.io 수작업을 대체하면 유지보수 비용이 줄어든다.

하지만 구조 정의 자체를 대체하면 사고가 난다.

실전 운영에서 깨지는 지점

1. 요구사항이 느슨한데 그림부터 그릴 때

이 경우 Claude는 빈칸을 메우려 한다.

그게 때로는 장점인데, 아키텍처에서는 단점이 된다.

그림이 있어 보이게 나오지만, 실제로는 가정이 너무 많다.

2. 엔티티 이름이 매번 바뀔 때

용어가 흔들리면 다이어그램도 흔들린다.

API, Gateway, Router, Adapter를 계속 섞어 쓰면 결국 사람도 헷갈린다.

3. stakeholder마다 원하는 해상도가 다를 때

개발자는 내부 경로를 보고 싶고, PM은 사용자 흐름을 보고 싶고, 보안 담당자는 신뢰 경계를 보고 싶다.

그런데 한 장에 다 넣으면 아무도 만족하지 못한다.

4. 다이어그램이 문서와 분리될 때

이게 제일 흔하다.

문서는 바뀌는데 그림은 옛날 상태로 남는다.

Claude가 도식 생성까지 맡는 이유는 여기 있다.

문서와 그림을 같은 소스에서 다시 찍어내야 덜 벌어진다.

체크리스트

  • 시스템 경계를 먼저 한 문단으로 적었나
  • 사용자 흐름과 내부 흐름을 구분했나
  • 동기 호출과 비동기 호출을 구분했나
  • 외부 서비스는 별도 박스로 뺐나
  • 보안 경계나 권한 경로를 빠뜨리지 않았나
  • stakeholder용 버전과 개발자용 버전을 분리했나
  • 나중에 다시 생성할 수 있는 템플릿이 있나

실수 TOP

1. 그림이 예쁘면 다 된 줄 아는 것

예쁜 그림은 발표용이지, 항상 정답은 아니다.

2. 세부 시스템을 너무 많이 한 장에 우겨 넣는 것

한 장에 다 넣으면 읽는 사람 머리가 먼저 터진다.

3. mermaid만 믿고 끝내는 것

mermaid는 빠르지만, stakeholder가 보기엔 너무 개발자 친화적일 수 있다.

4. draw.io를 수동 정리본으로만 쓰는 것

나중에 다시 수정하려면 결국 사람이 다시 그린다.

5. Claude가 이해한 용어를 검수하지 않는 것

이름이 한 번 틀리면 그림 전체가 틀린다.

FAQ

Claude가 그린 아키텍처 그림을 그대로 써도 되나?

아니. 초안으로는 좋지만 그대로 외부 공유하면 경계 오류가 섞일 수 있다.

mermaid와 draw.io 중 뭐가 더 나은가?

둘 중 하나가 우월하다기보다 용도가 다르다.

mermaid는 빠른 초안, draw.io는 공유와 발표에 더 강하다.

다이어그램을 Claude에게 맡기면 시간이 진짜 줄어드나?

초안 시간은 확 줄어든다.

대신 검수 없이 내보내면 나중에 고치는 시간이 늘어난다.

가장 좋은 방식은?

텍스트 스펙을 Claude에 주고, mermaid로 초안을 뽑고, draw.io로 최종본을 만드는 방식이다.

다음에 읽을 글

Sources