인프라를 처음 인수인계받았을 때, 제일 먼저 찾게 되는 게 네트워크 구성도입니다. 그런데 막상 열어보면 현실과 전혀 다른 '화석 문서'가 기다리고 있는 경우가 태반이었습니다. 저도 그 상황을 여러 번 겪었고, 결국 직접 해결책을 찾아 나섰습니다.
Mermaid와 LLM 자동화로 구성도를 코드처럼 관리하기
팀에 새 사람이 들어올 때마다 반복되는 상황이 있었습니다. 레거시 Visio 파일을 열어두고 "이거 지금도 맞는 거야?"라는 물음이 공중에 떠도는 것입니다. 처음엔 단순히 업데이트를 안 한 사람의 문제라고 생각했는데, 직접 겪어보니 구조적인 문제였습니다. 실제 인프라는 스프린트마다 바뀌는데, 다이어그램을 별도로 유지하는 건 사실상 이중 관리입니다. 어느 순간부터 아무도 건드리지 않게 됩니다. 이건 담당자 개인의 나태함이 아니라, 유지보수 비용이 너무 높은 도구를 선택했기 때문에 벌어지는 구조적 실패입니다.
그래서 시도한 것이 Mermaid 기반의 텍스트 다이어그램입니다. Mermaid란 마크다운과 비슷한 문법으로 네트워크 토폴로지나 플로우차트를 기술하면, 이를 자동으로 시각화 이미지로 렌더링해주는 텍스트 기반 도구입니다. 핵심은 다이어그램이 텍스트 파일로 저장된다는 점입니다. 이렇게 되면 Git으로 버전 관리가 가능해지고, 인프라 코드 변경과 함께 PR(Pull Request)에 다이어그램 변경 사항을 함께 담을 수 있습니다.
여기서 한 단계 더 나아간 개념이 IaC(Infrastructure as Code)와 연결됩니다. IaC란 서버, 네트워크, 보안 그룹 같은 인프라 자원을 코드로 정의하고 관리하는 방식입니다. 저는 이 개념을 다이어그램에도 그대로 적용했습니다. Terraform 코드나 AWS 아키텍처 설정 파일을 LLM에 붙여넣고 "이걸 Mermaid 다이어그램으로 표현해줘"라고 요청하면, 실제 인프라 상태를 반영한 구성도 초안이 수초 안에 나옵니다. 직접 써봤는데, 노드 20개짜리 VPC 구성을 수작업으로 그렸을 때 30분 넘게 걸리던 것이 이 방식으로는 5분 이내에 끝났습니다.
실제로 이런 식으로 요청합니다. "우리 VPC에는 퍼블릭 서브넷과 프라이빗 서브넷이 있고, ALB는 퍼블릭 서브넷에, ECS 파드는 프라이빗 서브넷에, RDS는 별도 DB 서브넷에 있어. VPN을 통해 온프레미스와 연결되고, Direct Connect가 백업으로 구성돼 있어. Mermaid로 그려줘." 결과물은 GitLab 마크다운이나 Notion에 그대로 붙여넣으면 즉시 렌더링됩니다. 이 방식으로 인프라 변경 시마다 다이어그램도 함께 업데이트하는 습관이 팀 전체에 자리를 잡았습니다.
도구별 활용 상황을 정리하면 다음과 같습니다. Mermaid는 GitLab, GitHub, Notion 등에서 즉시 렌더링 가능하여 팀 내부 문서화에 적합합니다. PlantUML은 시퀀스 다이어그램, 컴포넌트 다이어그램 표현에 강하고 CI/CD 파이프라인 문서화에 유용합니다. Diagrams as Code는 Python 코드로 AWS, GCP 등 클라우드 아키텍처를 표현하는 개발자 친화적 도구입니다. draw.io나 Visio는 고객사 제출이나 감사 자료처럼 정교한 시각 표현이 필요할 때 병행해서 사용합니다.
자동화의 한계와 다이어그램 신뢰성 문제
자동화가 생산성을 높이는 건 분명합니다. 그런데 제 경험상 이건 좀 다릅니다. AI가 생성한 다이어그램을 검증 없이 공식 문서로 올리는 순간, 또 다른 '화석 문서'가 탄생합니다. 다만 이번엔 오래된 게 아니라 처음부터 틀린 문서입니다. 이게 오히려 더 위험합니다. 오래된 문서는 사람들이 "맞나 확인해야겠다"는 경계심을 가지지만, 방금 AI가 만든 것처럼 보이는 문서는 그대로 믿어버리는 경향이 있기 때문입니다.
LLM(Large Language Model), 즉 대규모 언어 모델은 주어진 텍스트 설명에서 명시되지 않은 부분을 스스로 추론하여 채웁니다. 네트워크 구성 설명에 보안 그룹 규칙이나 피어링 관계를 빠뜨리면, LLM은 그 공백을 임의의 가정으로 메웁니다. 직접 써봤는데, 멀티 리전 환경에서 리전 간 VPC 피어링(서로 다른 가상 네트워크 간 트래픽을 직접 라우팅하는 연결 방식) 관계를 빠뜨린 설명을 넣었더니, LLM이 자의적으로 연결선을 그려 넣어 실제 구성과 전혀 다른 다이어그램이 만들어진 적이 있습니다.
특히 멀티 계정, 멀티 리전 환경이나 보안 경계(Security Boundary)가 복잡하게 얽힌 구성에서는 이 문제가 두드러집니다. 보안 경계란 특정 자원에 대한 접근을 제어하는 논리적 구분선으로, IAM 정책이나 네트워크 ACL로 구현됩니다. 이 경계가 다이어그램에서 빠지거나 잘못 표현되면 컴플라이언스 감사에서 치명적인 오류로 이어질 수 있습니다. 제가 이 부분에서 신경을 곤두세우는 이유는, 감사 담당자는 다이어그램을 실제 구성의 증거로 받아들이기 때문입니다. 틀린 다이어그램은 단순한 문서 오류가 아니라 잘못된 보안 주장이 됩니다.
가트너는 '작업 특화 에이전트'가 내장된 애플리케이션 비중이 2025년 말 5% 미만에서 2026년 말에는 40%까지 급증할 것으로 전망했습니다(출처: Gartner). AI 에이전트 기반 자동화가 빠르게 확산되는 만큼, 자동 생성된 결과물의 품질 검증 체계도 함께 갖춰야 한다는 의미이기도 합니다.
SolarWinds의 NTM(Network Topology Mapper)처럼 실제 네트워크를 스캔하여 장치 변경을 자동 감지하고 토폴로지 맵을 갱신하는 솔루션도 있습니다(출처: SolarWinds). 이런 솔루션은 온프레미스 환경에 강점이 있고, 클라우드 네이티브 환경에서는 별도 연동 설정이 필요합니다. 제 환경은 AWS 중심이라 LLM 기반 방식이 더 현실적이었는데, 완전 자동 스캔 방식도 맹점은 있습니다. 스캔이 포착하는 건 현재의 물리적, 논리적 연결 상태이지, 그 연결의 의도와 이유는 아닙니다. 왜 이렇게 구성했는지에 대한 맥락은 사람이 직접 써야 합니다.
결국 자동 생성 도구를 어떤 용도로 쓰느냐가 핵심입니다. 팀 내부 소통용 다이어그램이라면 LLM으로 초안을 뽑고, 담당자가 한 번 눈으로 검토한 뒤 올립니다. 고객사 제출용이나 보안 감사 자료라면 draw.io로 정교하게 재작업하고 반드시 인간 검수를 거칩니다. 이 구분을 지키지 않으면 자동화가 오히려 리스크를 키울 수 있습니다. 자동화 도구가 아무리 좋아져도 다이어그램의 정확성에 대한 최종 책임은 담당자에게 있습니다. 이 원칙 하나만 잊지 않으면, AI 도구는 분명 강력한 조력자가 됩니다.
네트워크 구성도 자동화의 핵심은 '초안을 빠르게 만드는 것'과 '그 초안을 정확하게 검증하는 것', 이 두 단계를 함께 가져가는 데 있습니다. Mermaid와 LLM 조합은 전자를 획기적으로 단축시켜 줬습니다. 아직 수작업으로 구성도를 관리하고 계신다면, 우선 간단한 구성 하나를 Mermaid로 표현해 보는 것부터 시작해 보시길 권합니다. 처음엔 낯설지만, 한 번 익히면 다시 Visio로 돌아가기가 어려워집니다.
참고:
- SolarWinds – 네트워크 다이어그램 소프트웨어 NTM: https://www.solarwinds.com/ko/network-topology-mapper/use-cases/network-diagram
- ProcessOn – 네트워크 토폴로지 다이어그램 드로잉 튜토리얼: https://www.processon.io/ko/label/network-topology-diagram
- ProcessOn – 네트워크 토폴로지 다이어그램 필독 가이드: https://www.processon.io/ko/blog/network-topology-kr
- Laon People – Graphify와 AI 구조화의 핵심 (Gartner 2026 전망 포함): https://laonpeople.com/blog-category/insight/