개인기로 그린 구성도는 그 사람이 나가면 끝난다. 2026년 기준 도구 9종 비교, 16:9 슬라이드 영역 배분과 글자 크기 하한, 범례·메타데이터 표준, /architecture 파일 구조와 ADR, 그리고 100점 평가표로 3부의 완성본을 실제 채점한다.
Part 4까지 왔다면 한 사람이 좋은 구성도를 그릴 수는 있게 됐다. 그런데 그건 아직 개인기다.
개인기로 그린 구성도의 문제는 명확하다. 그 사람이 프로젝트에서 빠지면 아무도 그 그림을 고칠 수 없다. 원본 파일이 어디 있는지 모르고, 왜 그렇게 그렸는지 모르고, 최신 버전이 어느 것인지 모른다. 다음 제안서에서는 그 그림을 PowerPoint에서 복사해 붙여 넣고 이름만 바꾼다. 그리고 3년쯤 지나면 아무도 손대지 못하는 그림이 회사 자산으로 남는다.
마지막 5부는 그걸 막는 이야기다.
| 도구 | 가장 적합한 용도 | 장점 | 주의점 |
|---|---|---|---|
| PowerPoint | 제안서 최종본 | 고객이 직접 수정하기 쉽고 AWS 공식 툴킷 제공 | 복잡한 구조의 원본 관리가 어렵다 |
| diagrams.net · draw.io | 제안서 구성도 원본 | 무료, 협업 편리, AWS 라이브러리, SVG 내보내기 | 수작업 정렬 품질을 사람이 관리해야 한다 |
| Figma | 시각적 완성도가 필요한 제안서 | 컴포넌트·스타일 관리, 협업 | 기술적 구조를 검증하는 기능은 없다 |
| Lucidchart | 협업형 다이어그램 | 템플릿과 협업 기능 | 유료 기능 의존 |
| AWS Infrastructure Composer | CloudFormation · SAM 구현 검증 | 시각 편집과 IaC 템플릿 동기화, PNG 내보내기 | 영업·사업 설명용 그림에는 지나치게 구현 중심 |
| PlantUML AWS Icons | 코드로 관리하는 기술 문서 | Git diff, 재현성, C4-PlantUML 연계 | 비개발자가 직접 수정하기 어렵다 |
| Structurizr | C4 기반 아키텍처 문서 | 하나의 모델로 여러 관점 생성 | 초기 모델링 학습이 필요하다 |
| Python Diagrams | 자동 생성형 기술 문서 | Python 코드와 버전관리 | 복잡한 레이아웃 미세 조정에 한계. 인프라를 프로비저닝하지는 않는다 |
| Cloudcraft | 기존 AWS 환경 시각화 | 계정·리소스·의존관계·비용 문맥 시각화 | 제안서용 메시지는 별도로 재구성해야 한다 |
2026년에 확인해둘 변동 사항이 몇 가지 있다.
도구 하나로 전부 해결하려는 시도는 대개 실패한다. 단계별로 나누는 편이 낫다.
가장 현실적인 표준은 한 문장으로 이렇게 정리된다.
원본은 diagrams.net, 납품본은 SVG를 삽입한 PowerPoint, 구현 검증은 IaC, 장기 기술문서는 Diagram as Code로 관리한다.
SVG 삽입을 강조하는 이유가 있다. PNG로 붙여 넣으면 확대할 때 글씨가 뭉개지고, 오탈자 하나를 고치려 해도 원본을 다시 찾아야 한다. SVG는 벡터라 축소·확대에 강하고, 급할 때는 PowerPoint 안에서 그룹 해제해 텍스트만 고칠 수도 있다.
좌→우 또는 위→아래 중 하나를 선택하고, 한 그림 안에서 섞지 않는다.
섞이는 순간 읽는 사람은 "이 화살표는 흐름인가 계층인가"를 매번 판단해야 한다. 그 판단 비용이 60초를 잡아먹는다.
영역을 미리 정해두면 그림마다 매번 레이아웃을 고민할 필요가 없어진다. 그리고 여러 장을 나란히 놓았을 때 같은 세트로 보인다. 6장 세트가 제각각으로 생기면 세트가 아니라 그냥 그림 여섯 장이다.
| 좋지 않은 제목 | 나은 제목 | 더 좋은 제목 |
|---|---|---|
| AWS 인프라 구성도 | 멀티 AZ 기반 의정지원 AI 서비스 목표 인프라 구성도 | 장애 격리와 프라이빗 데이터 처리를 적용한 의정지원 AI 목표 인프라 |
왼쪽 제목은 파일 이름이지 제목이 아니다. 오른쪽 제목은 그림을 보기 전에 이미 하나의 주장을 전달한다. 그리고 그 주장이 그림으로 뒷받침되는지를 독자가 검증하게 만든다. 검증하게 만드는 그림이 좋은 그림이다.
제목 아래에 한 문장을 넣는다. 그림을 보지 않아도 이해되는 문장이어야 한다.
외부 공개 채널과 내부 업무시스템을 분리하고, 모든 업무·데이터 처리 계층을 프라이빗 네트워크에서 다중 가용영역으로 운영합니다.
이 문장이 있으면 그림을 못 읽은 사람도 최소한 무엇을 주장하는지는 안다. 그리고 이 문장을 쓸 수 없다면, 그건 그림에 주장이 없다는 뜻이다.
색상은 장식이 아니라 의미를 가져야 한다. 그리고 두 가지 규칙이 따라붙는다.
첫째, 색상만으로 구분하지 않는다. 반드시 글자나 선 모양을 함께 쓴다. 제안서는 흑백으로 인쇄되는 경우가 흔하고, 평가위원 중 색각 이상이 있는 사람도 있다. 색으로만 구분한 그림은 그 순간 정보를 전부 잃는다.
둘째, 빨강은 장애가 아니라 보안 경계나 주의사항에 제한적으로 쓴다. 빨간색은 시선을 강하게 끌기 때문에, 남용하면 정작 강조해야 할 것이 묻힌다.
1부에서 예고했던 열 가지 실패 유형 중 마지막 둘이 여기 있다.
아직 도입하지 않을 서비스를 현재 확정된 것처럼 보이게 하는 경우다. 악의가 있어서가 아니라, 그리다 보니 구분을 안 한 것이다. 그런데 이건 계약 분쟁의 씨앗이 된다.
범례로 명확히 구분한다.
제안서마다 복사되면서 어느 그림이 최신인지 알 수 없게 되는 경우다. 이건 시간이 지날수록 악화되는 유일한 실패 유형이다.
그림 우측 하단에 메타데이터 블록을 넣는다.
Status가 특히 중요하다. Proposed(제안 중), Approved(승인됨), As-Built(구축 완료 기준), Deprecated(폐기) 중 무엇인지가 표시돼 있으면, 몇 년 뒤에 그 그림을 발견한 사람이 그걸 믿어도 되는지 판단할 수 있다.
PowerPoint 안에서만 그림을 관리하지 않는다. 원본을 별도로 관리하고, 제안서에는 내보낸 SVG를 삽입한다.
파일명에 번호를 붙인 이유는 6장 세트의 순서가 파일 이름에서 드러나게 하기 위해서다. 이렇게 해두면 신규 투입 인원이 디렉터리만 열어봐도 이 사업에 어떤 관점의 그림이 있는지 안다.
구성도는 결과만 보여준다. 왜 그렇게 됐는지는 그림에 담기지 않는다. 그걸 담는 것이 ADR(Architecture Decision Record)이다.
최소한 다음 일곱 가지를 기록한다.
| 항목 | ADR-001 예시 (컴퓨트 플랫폼) |
|---|---|
| 결정 사항 | 업무 서비스와 수집 워커를 ECS Fargate로 운영한다 |
| 결정 배경 | 회의록 OCR·정규화가 건당 15분을 넘길 수 있고, 운영을 MSP가 담당한다 |
| 고려한 대안 | AWS Lambda, Amazon EKS, EC2 Auto Scaling |
| 채택한 이유 | Lambda는 실행 시간 제약, EKS는 운영 복잡성. Fargate는 노드 관리 없이 장시간 작업 가능 |
| 장점 | 노드 패치 부담 없음, 작업 단위 확장, MSP 인수인계 용이 |
| 단점과 위험 | 단가가 EC2보다 높다. 대량 배치 시 비용 재검토 필요 |
| 재검토 조건 | 월 컴퓨트 비용이 예산의 40%를 넘거나, GPU 추론이 사업 범위에 들어올 때 |
EKS를 사용한다로 끝나는 문서는 ADR이 아니다. 이렇게 써야 한다.
다수의 독립 서비스, GPU 워크로드, 배포 표준화, 향후 온프레미스 연계를 고려해 EKS를 채택한다. 단, 초기 운영 복잡성이 높으므로 관리 인력과 GitOps 기반 운영 체계를 사업 범위에 포함한다.
재검토 조건을 적는 습관이 특히 중요하다. 모든 아키텍처 결정은 특정 시점의 제약 아래 내려진 것이고, 제약이 바뀌면 결정도 바뀌어야 한다. 언제 다시 볼지를 적어두지 않으면, 3년 전 조건에서 내린 결정이 근거 없이 계속 유지된다.
신입 교육과 내부 리뷰에는 점수표가 효과적이다. "좀 더 명확하게 그려보세요"보다 "흐름과 의존성 15점 중 9점입니다"가 훨씬 행동으로 이어진다.
| 평가 항목 | 배점 | 확인 질문 |
|---|---|---|
| 목적과 독자 | 15 | 이 그림이 답하는 질문이 한 문장으로 정의되어 있는가 |
| 범위와 경계 | 15 | 외부 · AWS · 계정 · 리전 · VPC · AZ 경계가 필요한 만큼 구분되었는가 |
| 흐름과 의존성 | 15 | 요청 · 데이터 · 이벤트의 방향과 의미가 명확한가 |
| 기술적 정확성 | 20 | AWS 서비스의 위치와 연결 방식이 실제 동작과 맞는가 |
| 보안 · 가용성 · 운영 | 20 | 인증, 암호화, 모니터링, 백업, 장애조치가 보이는가 |
| 가독성과 일관성 | 10 | 축소해도 읽히며 정렬 · 아이콘 · 화살표 규칙이 일관적인가 |
| 전제와 버전 | 5 | 가정, 제외 범위, 버전, 작성일이 있는가 |
| 항목 | 점수 | 근거 |
|---|---|---|
| 목적과 독자 | 14 / 15 | 상단 한 줄 메시지가 있고 독자가 정의됨. 다만 그림 안에 "어떤 결정을 받기 위한 그림인지"는 없다 |
| 범위와 경계 | 15 / 15 | Account → Region → VPC → AZ → Subnet, 리전 서비스와 온프레미스까지 구분 |
| 흐름과 의존성 | 12 / 15 | 번호 ①~⑦로 순서는 보이지만, 화살표 자체에 붙은 의미 레이블이 적다 |
| 기술적 정확성 | 20 / 20 | DB Subnet Group, Gateway · Interface Endpoint, 리전 서비스 위치 모두 정확 |
| 보안 · 가용성 · 운영 | 17 / 20 | 5계층 보안과 RTO · RPO는 있으나 백업 저장소의 위치가 그림에 없다 |
| 가독성과 일관성 | 9 / 10 | 일관적이나 리전 서비스 열의 여백이 다소 크다 |
| 전제와 버전 | 5 / 5 | Status · v0.9 · 작성일 · 원본 파일명 표기 |
| 합계 | 92 / 100 | 제안서 제출 가능. 다만 아래 세 가지를 보완하면 더 좋다 |
남은 8점을 채우려면 이렇게 한다. ① 화살표에 검색 질의, 원문 조회, 응답 생성 같은 의미 레이블을 붙인다. ② 백업 저장소와 교차리전 복사 경로를 그림에 표시한다. ③ 상단 메시지에 "목표 아키텍처 승인 요청"이라는 목적을 한 조각 더 넣는다.
여기서 중요한 건 92점이라는 숫자가 아니다. 어디를 고쳐야 하는지가 세 개의 구체적인 행동으로 나왔다는 것이다. 점수표의 목적은 등급을 매기는 게 아니라 다음 수정 항목을 만들어내는 것이다.
점수표를 통과했어도 마지막에 한 번 더 한다. 1부에서 소개한 그 테스트다.
두 개 이상 답하지 못한다면 그림을 단순화하거나 관점을 나눈다. 점수가 아무리 높아도 이건 예외 없이 적용한다.
| 시간 | 교육 내용 | 실습 결과물 |
|---|---|---|
| 15분 | 좋은 구성도와 아이콘 수프 비교, 60초 테스트 시연 | 문제점 5개 찾기 |
| 20분 | Architecture Brief 작성 | 요구사항 · 독자 · 목적 정의 |
| 20분 | 기술 중립적 컨텍스트 구성도 | 사용자 · 외부 시스템 · 범위 |
| 30분 | AWS 서비스 매핑과 경계 배치 | 목표 AWS 구성도 |
| 20분 | 보안 · 운영 · DR 추가 | 비기능 요구사항 반영 |
| 10분 | 동료 평가 | 100점 평가표 |
| 5분 | 아이콘 · 문구 제거 | 최종 간소화본 |
AWS 공식 레퍼런스 중 하나를 골라 다음 순서로 실습한다.
4번과 5번이 이 과제의 핵심이다. 단순 모작에서 끝내면 아무것도 배우지 않는다. 요구사항에 따라 무엇을 삭제하고 무엇을 바꿨는지, 그리고 무엇을 검토했지만 안 골랐는지를 설명하게 해야 비로소 설계가 된다.
그리고 이 열 가지를 하나로 줄이면 이 문장이 된다.
좋은 인프라 구성도는 시스템을 가장 자세하게 그린 그림이 아니라, 고객이 가장 빠르게 이해하고 검토하며 의사결정할 수 있게 만든 그림이다.
다섯 편에 걸쳐 하나의 가상 사업을 따라왔다. K광역시의회 의정지원 AI 플랫폼. 처음에는 AWS 서비스 24개와 화살표 47개가 빽빽한 그림이었고, 60초 테스트 7문항 중 하나도 답하지 못했다.
마지막에 남은 그림은 서비스 11개다. 그리고 일곱 문항에 전부 답한다.
그 사이에 우리가 한 일은 정보를 더한 것이 아니라 질문을 먼저 정한 것이었다. 어떤 질문에 답할지 정하고(1·2부), 그 질문에 답하는 순서대로 그리고(3부), 기술적으로 맞는지 검증하고(4부), 다음 사람이 이어받을 수 있게 표준으로 만들었다(5부).
신입에게 가르칠 때 가장 마지막에 하는 말은 늘 같다.
당신이 AWS 서비스를 몇 개 아는지는 고객의 관심사가 아니다. 고객의 관심사는 자기 문제가 풀리는가다.
RELATED
