AWS 인프라 구성도 실무 가이드 (Part 2): 한 장 말고 여섯 장 — 제안서 구성도 세트 설계

Part 1에서는 K광역시의회 의정지원 AI 플랫폼 사업을 아이콘 수프로 그린 그림이 60초 테스트 7문항 중 하나도 답하지 못하는 것을 확인했다. 그리고 그 실패가 네 가지 유형으로 나타나지만 원인은 하나 — 툴을 너무 일찍 열었다 — 로 수렴한다는 것까지 봤다.

2부는 그 진단에 대한 첫 번째 처방이다. 그런데 이 처방은 대부분의 사람이 처음에 거부한다.

한 장으로는 안 된다.

---

"한 장에 다 넣어주세요"라는 요구

제안서를 준비해본 사람이라면 이런 상황이 익숙할 것이다.

"인프라 구성도는 한 장으로 정리해주세요. 슬라이드가 부족해서요."

그리고 이 요구는 대체로 합리적으로 들린다. 페이지 제한은 실제로 존재하고, 평가위원의 시간도 유한하다. 그림이 여러 장이면 산만해 보일 것 같다는 걱정도 근거가 없지 않다.

하지만 여기에는 잘못된 전제가 하나 숨어 있다. "정보를 한 장에 모으면 이해도 한 번에 된다"는 전제다. 실제로는 정반대다. 서로 다른 종류의 정보를 한 장에 모으면 각각의 정보가 서로를 가린다.

1부의 아이콘 수프를 다시 떠올려보자. 그 그림에는 이런 것들이 동시에 들어 있었다.

• 누가 이 시스템을 쓰는가 (사용자, 온프레미스 회의록 DB)
• 시스템이 무엇으로 만들어지는가 (Amazon ECS, Amazon Aurora)
• 무엇으로 보호하고 관측하는가 (AWS KMS, AWS CloudTrail)

세 가지는 서로 다른 종류의 질문이다. 그런데 그림에서는 전부 같은 크기, 같은 색의 사각형으로 그려져 있었다. 읽는 사람이 "이건 사람이고, 이건 컴퓨트고, 이건 횡단 관심사구나"를 스스로 분류해야 한다. 60초 안에 그걸 해내라는 건 무리한 요구다.

정보를 한 장에 모으는 것이 실패하는 이유는 욕심 때문이 아니다. 한 그림 안에 서로 다른 추상화 수준을 섞었기 때문이다. 이걸 정확한 언어로 설명해주는 도구가 있다.

---

C4 모델 — 그림의 확대 수준을 정하는 방법

C4 모델은 소프트웨어 아키텍처를 네 단계의 줌 레벨로 나눠 설명하자는 제안이다. 지도에 비유하면 세계지도 → 국가지도 → 도시지도 → 건물 도면에 해당한다.

여기에 두 가지 관점이 추가로 붙는다. Dynamic(동적) 다이어그램은 요청이 처리되는 순서를 보여주고, Deployment(배포) 다이어그램은 컨테이너 인스턴스를 실제 서버·노드·클라우드 환경에 매핑한다. 배포 다이어그램이 바로 우리가 "AWS 인프라 구성도"라고 부르는 그것이다.

C4를 알고 나면 1부의 아이콘 수프가 왜 실패했는지가 훨씬 정확하게 설명된다. 그 그림은 System Context와 Container와 Deployment와 횡단 관심사를 한 장에 섞어놓은 것이었다. 각각은 유용한 그림이지만, 겹치면 넷 다 못 읽는다.

C4를 제안서 산출물로 옮기면 이렇게 대응한다.

여기서 한 가지 오해를 미리 정리해두자. C4를 도입한다는 것이 "C4 표기법 그대로 그려야 한다"는 뜻은 아니다. 제안서 구성도에 C4 공식 표기법을 그대로 쓰는 경우는 드물다. 우리가 C4에서 가져오는 것은 표기법이 아니라 줌 레벨의 개념이다. "지금 그리는 이 그림은 어느 수준인가"를 스스로에게 묻게 만드는 것, 그것만으로 충분한 값어치를 한다.

---

제안서에 권장하는 6장 세트

C4로 줌 레벨을 정리하고, 여기에 제안 평가에서 반드시 요구되는 관점(보안·운영·DR, 구축·전환)을 더하면 여섯 장이 된다.

이 표에서 가장 중요한 열은 세 번째와 네 번째다. 각 장에는 답해야 하는 질문이 하나씩 배정되어 있고, 그 질문을 궁금해하는 사람이 정해져 있다.

이게 왜 중요한가. 제안 평가는 한 사람이 하지 않기 때문이다. 사업 담당자, 인프라 담당자, 보안 담당자, 회계 담당자가 각자의 관심사로 같은 문서를 본다. 한 장짜리 종합 구성도는 이 네 사람 모두에게 "내가 궁금한 것의 30%만 답해주는 그림"이 된다. 여섯 장으로 나누면 각자 자기 그림에서 100%를 얻는다.

정보량은 같은데 전달량이 다르다. 이것이 6장 세트의 유일한 논거다.

---

1장. 시스템 컨텍스트 구성도

가장 상위 그림이다. 그리고 신입이 가장 많이 건너뛰는 그림이기도 하다. "너무 당연한 내용 아닌가요?"라는 반응이 흔하다.

하지만 이 그림이 실제로 정하는 것은 사업의 범위다. 무엇을 만들고, 무엇을 만들지 않고, 무엇과 연결하는지. 계약 분쟁의 절반은 여기서 시작된다.

포함할 내용은 이 정도면 충분하다.

• 사용자 유형 (역할별로 나눈다. "사용자" 하나로 뭉치지 않는다)
• 관리자와 운영자
• 외부기관 또는 외부 서비스
• 온프레미스 시스템
• 구축 대상 시스템의 범위
• 주요 입력 · 출력 정보
• 사업 범위와 제외 범위

AWS 아이콘은 거의 필요하지 않다. 쓰더라도 AWS Cloud 정도만 표시한다. 이 장의 질문은 "누가 쓰고 무엇과 연결되는가"이지 "무엇으로 만드는가"가 아니기 때문이다.

이 그림에서 고객이 읽어야 하는 메시지는 하나다.

"이번 사업에서 우리가 구축하는 범위, 그리고 기존 시스템 및 외부기관과의 관계는 이렇습니다."

위 그림에서 오른쪽 아래 점선 박스를 눈여겨보길 바란다. 기존 의정관리시스템 고도화, 속기 시스템 교체·회선 증설이 "본 사업 제외 범위"로 명시돼 있다. 제안서에서 이걸 빠뜨리면, 착수 후에 "그건 당연히 포함인 줄 알았는데요"라는 대화를 하게 된다. 제외 범위를 그림에 적는 것은 방어가 아니라 성실함의 표시다.

---

2장. 목표 서비스 아키텍처

서비스를 기술 제품이 아니라 역할과 기능 계층으로 보여주는 그림이다. C4의 Container 레벨에 해당한다.

계층 구성은 대체로 이런 형태가 된다.

이 단계에서는 EKS, Lambda, Aurora 같은 AWS 서비스명을 써도 된다. 다만 반드시 역할명을 함께 표시한다.

이유는 단순하다. 평가위원이 전부 AWS 전문가는 아니기 때문이다. Amazon Neptune만 적힌 박스는 AWS를 아는 사람에게만 정보를 준다. 인물·조직·사건 관계 그래프 – Amazon Neptune은 모두에게 정보를 준다. 그리고 AWS를 아는 사람에게도 여전히 같은 정보를 준다. 한쪽만 손해 보는 선택은 하지 않는다.

덤으로, 역할명을 붙이려고 하면 스스로 검증이 된다. 역할명이 안 떠오르는 서비스가 있다면, 그건 아직 왜 넣는지 정하지 않았다는 뜻이다. 그런 서비스는 지운다.

---

3장 ~ 6장

나머지 네 장은 이후 편에서 실물과 함께 다룬다. 여기서는 각 장이 무엇을 답해야 하는지만 정리한다.

3장. AWS 배포 · 네트워크 구성도 — 논리적·물리적 경계를 보여준다. AWS Organization과 계정, 리전, VPC, 가용영역, 퍼블릭·프라이빗 서브넷, 인터넷 진입 경로, 외부 통신 경로, VPC Endpoint, VPN 또는 Direct Connect, 보안그룹, 관리·운영 접속 경로. 이 시리즈에서 기술적 오류가 가장 많이 나오는 그림이기도 하다. 4부에서 통째로 다룬다.

4장. 데이터 · 런타임 흐름도 — 구성요소의 위치보다 처리 순서가 중요한 그림이다. 번호를 붙이는 방식이 효과적이다. 그리고 이 사업처럼 AI 검색이 들어가는 경우, 오프라인 수집·인덱싱 경로와 온라인 질의·응답 경로를 반드시 분리해서 그려야 한다. 두 경로를 하나의 화살표로 이어 그리면 데이터 신선도 요구사항과 운영상 병목을 설명할 수 없다.

5장. 보안 · 운영 · 재해복구 구성도 — 제안서에서 가장 자주 누락되지만 평가 관점에서는 배점이 큰 그림이다. 인증, IAM 역할, 암호키와 비밀정보 관리, 웹 공격 방어, 감사 로그, 모니터링, 보안 이벤트 통합, 백업, 장애 감지, 복구 환경, 그리고 RTO와 RPO 숫자.

6장. 구축 · 전환 구성도 — 기존 시스템이 있는 사업이라면 목표 구성도만 제시해서는 부족하다. AS-IS에서 TO-BE까지의 단계, 병행운영 구간, 데이터 이관, 검증 기준, 롤백 방법, 단계별 책임 주체를 구분해서 표현한다.

---

arc42 — 무엇을 빠뜨렸는지 점검하기

C4가 "어느 수준으로 그릴지"를 정해준다면, arc42는 "무엇을 빠뜨리지 말아야 하는지"를 점검해준다. arc42는 아키텍처 문서에 담겨야 할 내용을 12개 항목으로 구조화한 템플릿이다.

신입 교육에서는 세 가지 도구의 역할을 이렇게 한 줄로 정리해서 알려준다.

C4로 그림의 줌 레벨을 정하고, arc42로 문서의 누락을 점검하며, AWS Well-Architected로 기술적 타당성을 검토한다.

세 도구는 경쟁 관계가 아니라 서로 다른 축을 담당한다. 하나만 알고 있으면 나머지 두 축에서 새는 것을 못 잡는다.

---

"6장은 과한데요?"

여기까지 읽고 나면 나오는 반응이 대체로 정해져 있다. 3개월짜리 소규모 사업에 구성도 여섯 장은 확실히 과하다. 맞는 지적이다.

6장 세트는 최대 세트가 아니라 완전 세트다. 사업 성격에 따라 덜어내는 것이 정상이다. 다만 덜어내는 데도 순서가 있다.

절대 생략하지 않는 것은 1장과 3장이다.

1장을 생략하면 사업 범위가 문서 어디에도 그림으로 남지 않는다. 3장을 생략하면 "이 팀이 실제로 AWS에 구축할 수 있는가"를 발주기관이 판단할 근거가 사라진다. 나머지는 사업 성격에 따라 조정 가능하지만, 이 둘은 거의 항상 필요하다.

그리고 하나 더. 슬라이드 매수가 정말 부족하다면, 6장을 억지로 한 장에 뭉치는 대신 3장으로 줄이는 편이 낫다. 뭉친 한 장은 0점이지만, 잘 고른 세 장은 세 개의 질문에 답한다.

---

정리

• 한 장짜리 종합 구성도가 실패하는 이유는 욕심이 아니라 줌 레벨이 섞였기 때문이다.
• C4 모델은 그 줌 레벨에 이름을 붙여준다: System Context / Container / Component / Code + Dynamic / Deployment.
• 제안서에는 6장 세트를 권장한다. 각 장은 하나의 질문과 하나의 주요 독자를 갖는다.
• 1장에는 AWS 아이콘이 거의 필요 없다. 대신 제외 범위를 반드시 적는다.
• 2장에서 서비스명을 쓸 때는 반드시 역할명을 함께 쓴다.
• arc42 12항목으로 누락을 점검한다.
• 사업 규모에 따라 덜어내되, 1장과 3장은 거의 항상 남긴다.

이제 무엇을 그릴지는 정해졌다. 남은 문제는 어떻게 그리는가다.

---

다음 편 예고

Part 3에서는 드디어 실제 작성으로 들어간다. 다만 여전히 draw.io를 열지는 않는다.

• 툴을 먼저 열면 왜 지는가 — 요구사항이 아니라 익숙한 서비스에 설계를 끼워 맞추게 되는 메커니즘
• Architecture Brief 16항목 양식, 그리고 K광역시의회 사업으로 실제로 채운 표
• 완성해야 할 한 문장: "이 그림은 누구에게, 무엇을 설명하고, 어떤 결정을 받기 위한 그림이다"
• 실제 작성 7단계 — 아이콘 없이 기능 블록 → Happy Path → AWS 서비스 매핑 → 경계 배치 → 화살표에 의미 붙이기 → 비기능 요구사항을 구조로 증명 → 마지막에 아이콘 감량
• 그리고 1부에서 예고한 "같은 사업, 같은 정보량, 다르게 그린 한 장"의 완성본

---

참고 자료

• C4 model — System Context / Container / Component / Code 및 Dynamic · Deployment 다이어그램
• arc42 — 아키텍처 문서 12항목 템플릿
• AWS Architecture Center — Reference Architecture Diagrams — 산업·기술별 레퍼런스 구성도
• AWS Well-Architected Framework — 6개 축 기반 아키텍처 검토
• Azure Well-Architected: Architecture design diagrams — 독자에 맞는 관점 선택과 일관된 표기