S3 버킷은 서브넷 안에 없다. Lambda는 고객 VPC에서 실행되지 않는다. 그림이 읽히는 것과 맞는 것은 다른 문제다. 배치 오류 다섯 가지를 바로잡고, AWS 공식 레퍼런스 수십 장이 수렴하는 여섯 가지 레이아웃 패턴과 생성형 AI 수명주기 축까지 정리한다.
Part 3에서 완성한 구성도는 60초 테스트 7문항에 전부 답했다. 그런데 그건 읽히는가에 대한 답이지 맞는가에 대한 답이 아니다.
읽히지만 틀린 그림은 더 위험하다. 안 읽히는 그림은 아무도 믿지 않지만, 잘 읽히는 그림은 사람들이 그대로 믿기 때문이다. 그리고 그 그림이 상세설계의 출발점이 된다.
4부는 기술 검증이다. 그리고 남의 그림에서 무엇을 배울 것인가에 대한 이야기다.
흔한 오류는 두 가지 형태로 나타난다. 리전 바깥에 그리거나, 단일 퍼블릭 서브넷에 그리는 것이다.
올바른 표현은 DB Subnet Group과 두 개 이상 AZ의 데이터 서브넷에 배치하는 것이다. RDS의 DB Subnet Group은 일반적으로 둘 이상의 가용영역에 걸쳐 구성된다. 이건 선택이 아니라 Multi-AZ 배포의 전제다.
그림에 이걸 표현하면 부수 효과가 하나 있다. "고가용성을 제공합니다"라는 문장을 따로 쓸 필요가 없어진다. 그림이 이미 말하고 있기 때문이다.
이건 신입뿐 아니라 경력자도 자주 틀린다. Private App Subnet 박스 안에 Lambda 아이콘을 넣는 것이다.
Lambda의 실행 환경은 AWS가 관리하는 영역에 있다. 고객 VPC에 연결하도록 설정하면, 선택한 서브넷에 네트워크 인터페이스가 만들어지고 그 인터페이스를 통해 VPC 안의 리소스에 접근한다. 함수 자체가 고객 서브넷에서 도는 것이 아니다.
이 구분이 왜 중요한가. 그림이 틀리면 검토도 틀리기 때문이다. Lambda가 서브넷 안에 있다고 그려두면, 보안 담당자는 "그 서브넷의 NACL로 Lambda를 통제할 수 있겠군"이라고 판단한다. 그리고 상세설계에서 그게 아니라는 것을 알게 되면, 그때는 이미 네트워크 설계가 굳어 있다.
이게 가장 자주 나오는 오류다. S3 버킷을 프라이빗 서브넷 안에 그리는 것.
S3와 DynamoDB는 리전 서비스다. VPC 안에 존재하지 않는다. VPC 안에 있는 것은 그 서비스로 가는 경로다.
Amazon Bedrock도 마찬가지다. Bedrock은 리전 서비스이고, 프라이빗 연결은 VPC 안의 인터페이스 엔드포인트를 통해 이뤄진다. Bedrock 모델이 애플리케이션 서브넷 안에서 도는 것처럼 그리면 틀린 그림이다.
한 문장으로 정리하면 이렇다.
서비스의 위치와 엔드포인트의 위치는 다르다.
3부 완성본에서 리전 서비스 (VPC 밖) 열을 따로 만들고, VPC 안에는 VPC Endpoint 스트립만 둔 이유가 이것이다.
| 서비스 · 구성 | 흔한 오류 | 권장 표현 |
|---|---|---|
| Amazon RDS · Aurora | 리전 바깥 또는 단일 퍼블릭 서브넷에 표시 | DB Subnet Group과 두 개 이상 AZ의 데이터 서브넷에 표현 |
| AWS Lambda | Lambda 자체가 고객 서브넷에서 실행되는 것처럼 표시 | Lambda 서비스는 AWS 관리 영역에 두고 VPC 연결(ENI)을 표시 |
| Amazon S3 · DynamoDB | 버킷·테이블을 프라이빗 서브넷 안에 배치 | 리전 서비스로 VPC 밖에 두고 Gateway Endpoint를 VPC에 표시 |
| Interface VPC Endpoint | AWS 서비스를 통째로 서브넷 안에 넣음 | 선택된 서브넷 안에 Endpoint ENI를 표시 |
| Amazon Bedrock | Bedrock 모델을 애플리케이션 서브넷 내부에 표시 | 리전 서비스로 두고 PrivateLink Endpoint를 VPC 안에 표시 |
3부 6단계에서 이미 다룬 원칙이지만, 실제 그림으로 보면 차이가 분명하다.
왼쪽 그림에도 Multi-AZ 구성 (고가용성)이라는 글자가 분명히 있다. 제안서 본문에도 같은 문장이 있을 것이다. 그런데 그 그림에서 검증할 수 있는 것은 아무것도 없다.
오른쪽에는 이런 것들이 보인다.
ECS Fargate ×2)30초 / 실패 2회)CPU 60% 초과)그리고 마지막 한 줄이 중요하다. 복제본은 백업이 아니다. Replica는 하드웨어 장애와 AZ 장애를 막아주지만, 실수로 테이블을 지웠거나 데이터가 손상됐을 때는 복제본에도 똑같이 반영된다. 그래서 논리적 삭제와 손상에 대비한 독립 백업을 함께 표시해야 한다.
IAM, KMS, GuardDuty, CloudTrail, WAF 아이콘이 그림 여기저기 떠 있는데, 그것들이 무엇을 보호하는지 알 수 없는 경우다.
이 그림이 주는 인상은 정확히 하나다. "보안 체크리스트를 옮겨 적었다." 설계했다는 인상이 아니다.
역할 중심으로 묶으면 다르게 읽힌다.
| 역할 계층 | 서비스 | 답하는 질문 |
|---|---|---|
| Identity | IAM Identity Center · IAM | 누가 무엇에 접근하는가 |
| Data Protection | KMS · Secrets Manager | 저장·전송 데이터와 자격증명을 어떻게 보호하는가 |
| Detection | GuardDuty · Security Hub | 이상 행위와 위협을 어떻게 탐지하는가 |
| Audit | CloudTrail · AWS Config | 누가 언제 무엇을 했는가 |
| Protection | WAF · Shield | 공개 채널로 들어오는 공격을 어떻게 막는가 |
이렇게 묶으면 빠진 것도 눈에 띈다. K광역시의회 사업처럼 개인정보를 다루는 경우, Data Protection 행에 "저장 시 암호화 대상이 무엇인가"가 비어 있으면 그게 바로 보완할 지점이다.
"재해복구를 제공합니다"라고만 쓰고 목표 복구시간과 데이터 손실 허용 범위를 제시하지 않는 경우다.
AWS는 재해복구 전략을 일반적으로 네 단계로 설명한다.
| 전략 | 평상시 상태 | 비용 | 일반적 복구 특성 | 이 사업에 맞는가 |
|---|---|---|---|---|
| Backup and Restore | 백업만 유지 | 낮음 | 복구 시간이 가장 김 | RTO 4시간 달성이 불확실 |
| Pilot Light | 핵심 데이터·일부 기반 유지 | 중하 | 전체 환경 확장이 필요 | 예산 제약 하에서 현실적 후보 |
| Warm Standby | 축소된 전체 환경 유지 | 중상 | 비교적 빠른 전환 | RTO 여유는 크지만 예산 초과 |
| Multi-Site Active/Active | 여러 리전에서 동시 운영 | 높음 | 가장 빠른 복구 가능 | 단일 리전 예산이라 미채택 |
오른쪽 열을 눈여겨보길 바란다. 이 표가 제안서에서 의미를 갖는 순간은 네 개를 나열할 때가 아니라, 그중 하나를 고르고 나머지를 왜 안 골랐는지 적을 때다. 3부 Architecture Brief의 '대안' 칸이 여기서 쓰인다.
그리고 고른 전략은 그림에 숫자로 남긴다.
여기서부터가 4부의 후반부다.
AWS Architecture Center에는 산업·기술별 레퍼런스 구성도가 대량으로 있고, 상당수 문서에는 수정 가능한 PowerPoint 원본도 포함되어 있다. AWS는 공식 PPT 툴킷과 아이콘 패키지도 별도로 제공한다.
그래서 제안서를 쓸 때 가장 쉬운 유혹은 이것이다. 비슷한 레퍼런스를 찾아서 이름만 바꿔 넣는 것.
이게 실패하는 이유는 명확하다. 레퍼런스 아키텍처는 일반적인 요구사항을 전제로 만들어진 것이고, 당신의 사업에는 특수한 요구사항이 있기 때문이다. 그리고 제안 평가에서 배점을 받는 부분은 정확히 그 특수한 부분이다.
레퍼런스에서 배워야 하는 것은 서비스 조합이 아니라 표현 구조다. 즉 "저 사람들은 왜 저것을 저 위치에 그렸는가"다.
AWS 공식 레퍼런스들을 이 관점으로 훑어보면, 서로 다른 수십 장의 그림이 사실 여섯 개의 레이아웃 패턴으로 수렴한다.
이 그림은 AWS 공식 다이어그램을 옮겨 그린 것이 아니다. 그 다이어그램들이 쓰는 배치 패턴만 추상화한 것이고, 원문은 아래 표의 링크에서 직접 보는 편이 낫다. 그리고 그게 이 절의 요지이기도 하다 — 가져올 것은 그림이 아니라 축이다.
내 사업에 맞는 축을 고르는 것이 레퍼런스를 쓰는 법이다. K광역시의회 사업이라면 ⑤ 두 경로 분리형(수집과 질의를 4장에서 나눠 그린다)과 ④ 생애주기형(원문→정제→인덱스를 역할로 구분한다)이 필요하고, ⑥ 리전 비교형은 단일 리전 예산이라 필요 없다.
아래 문서들은 대부분 수정 가능한 PowerPoint 원본(ZIP)을 함께 제공한다. 다시 그려보는 실습(5부의 추천 과제)에 그대로 쓸 수 있다.
| 레퍼런스 | 레이아웃 패턴 | 원본 제공 | 발행 |
|---|---|---|---|
| AWS Security Reference Architecture | ① 계정 우선형 | 웹 문서 | 지속 갱신 |
| Generative AI for the AWS SRA | ① 계정 우선형 | 웹 문서 | 최신 |
| Moodle for High Availability | ② 좌→우 계층형 | PowerPoint | 2022 |
| Serverless Screenshot Processor | ③ 번호 이벤트형 | PowerPoint | 2022 |
| Modern Data Analytics | ④ 생애주기형 | PowerPoint | 2022 |
| Real-Time Streaming for RAG | ⑤ 두 경로 분리형 | PowerPoint | 2024 |
| Knowledge Graphs and GraphRAG | ⑤ 두 경로 분리형 | PowerPoint | 2024 |
| Multi-region API Gateway | ⑥ 리전 비교형 | PowerPoint | 2022 |
| Payment System Modernization | 하이브리드 신뢰경계형 | PowerPoint | 2023 |
| Amazon VPC Lattice | 관점 분할형 | 웹 문서 | 2023 |
발행 연도를 함께 적어둔 이유가 있다. 레퍼런스 구성도는 생각보다 오래된 것이 많다. 위 문서 중 상당수가 2022년 발행이다.
그런데 여기에 함정이 하나 더 있다. Modern Data Analytics 문서는 발행일이 2022년 5월인데, 본문에는 Amazon Managed Service for Apache Flink와 Amazon SageMaker AI가 등장한다. 둘 다 2022년에는 없던 이름이다. AWS는 발행일을 그대로 둔 채 본문만 갱신하기도 한다.
그래서 판단 기준은 이렇게 잡는 편이 안전하다. 레이아웃은 발행일과 무관하게 배워도 되지만, 서비스명과 구성은 반드시 현재 문서에서 다시 확인한다. 제안서에 존재하지 않는 서비스명이 적혀 있는 것만큼 신뢰를 빠르게 잃는 것이 없다.
앞의 패턴 그림은 추상화한 것이라, 진짜 레퍼런스가 어떻게 생겼는지는 원문을 봐야 감이 온다. 대표적인 네 장을 출처와 함께 싣는다.
② 좌→우 계층형 — Moodle for High Availability on AWS 출처: Amazon Web Services, Moodle for High Availability on AWS · 2021년 12월 22일 발행 · 2026년 7월 27일 확인 볼 것: 왼쪽 진입점에서 오른쪽 데이터까지 한 방향으로 흐르고, 가용영역 두 개가 위아래가 아니라 좌우로 나란히 놓여 있다. 그래서 "무엇이 중복인가"가 한눈에 읽힌다. 캐시·파일·DB의 복제 관계가 두 영역 사이 가운데에 글자로 적혀 있는 것도 눈여겨볼 만하다.
④ 생애주기형 — Modern Data Analytics Reference Architecture on AWS 출처: Amazon Web Services, Modern Data Analytics Reference Architecture on AWS · 2022년 5월 31일 발행 · 2026년 7월 27일 확인 볼 것: 열 이름이
data sources → data ingestion → scalable data lake → seamless data movement → purpose-built analytics and insights다. AWS 제품 카테고리가 아니라 데이터가 지나가는 단계로 열을 잡았다.AWS Lake Formation이 거버넌스 열에 따로 서 있는 것도 의도된 배치다.
⑤ 두 경로 분리형 — Exploring Real-Time Streaming for Retrieval Augmented Generation 출처: Amazon Web Services, Exploring Real-Time Streaming for RAG in Generative AI · 2024년 8월 발행 · 2026년 7월 27일 확인 볼 것: 왼쪽 절반이 데이터를 넣는 경로(변경 감지 → 스트리밍 → 처리 → 임베딩)이고, 오른쪽 위
Generative AI application으로 가는 선이 쓰는 경로다. 6번 벡터 저장소가 두 경로가 만나는 유일한 지점이라는 것이 이 그림의 핵심이다.
⑥ 리전 비교형 — Multi-region API Gateway with CloudFront 출처: Amazon Web Services, Multi-region API Gateway with CloudFront · 2022년 4월 19일 발행 · 2026년 7월 27일 확인 볼 것:
Region A와Region B박스가 똑같이 생겼고 위아래로 나란하다. 그리고 둘을 잇는 세로선에global database라고 적혀 있다. 리전 두 개를 그리는 것만으로는 부족하고, 무엇이 둘을 잇는가를 적어야 한다는 것을 보여준다.
저작권 안내 — 위 네 장은 Amazon Web Services가 AWS Architecture Center에 공개한 레퍼런스 아키텍처 다이어그램이며, 저작권은 AWS에 있습니다. 이 글에서는 표현 구조를 설명하기 위해 출처를 밝혀 인용했습니다. 각 원문 페이지에서 수정 가능한 PowerPoint 원본(ZIP)을 내려받을 수 있으니, 실제 작업에는 이 이미지 대신 원본을 받아 쓰기를 권합니다.
2025년 11월에 나온 Well-Architected Generative AI Lens는 이 시리즈에 특히 유용하다. 생성형 AI를 수명주기 여섯 단계로 나눠 보는데, 이걸 그대로 구성도의 축으로 쓸 수 있기 때문이다.
AI 사업 제안서에서 구성도를 Bedrock + OpenSearch + Lambda 같은 서비스 목록으로 그리면, 평가위원 입장에서 검토할 것이 없다. 반면 이 여섯 단계를 축으로 삼으면 각 단계가 그대로 검토 항목이 된다. "모델 선택 근거는?", "커스터마이징은 프롬프트인가 RAG인가 파인튜닝인가?", "품질 저하를 어떻게 감지하나?"
K광역시의회 사업으로 옮기면 3번(Customization)이 RAG + 근거 인용 강제, 6번(Continuous Improvement)이 답변 근거 적중률 모니터링에 해당한다. 이 둘이 비어 있는 AI 제안서가 대단히 많다.
| 레퍼런스 | 배울 표현 구조 |
|---|---|
| AWS Security Reference Architecture | 애플리케이션 서비스보다 계정 분리와 보안 책임 구조를 먼저 보여준다. Organizations 관리 계정, Security OU, Log Archive 계정, Security Tooling 계정, Network 계정, Workload 계정. 공공·금융 제안에서 특히 유효하다 |
| Control Tower · Landing Zone Accelerator | 업무시스템 구성도와 클라우드 기반환경 구성도를 분리한다. 대규모 제안에서는 단일 VPC 그림을 그리기 전에 조직·계정 구성도를 먼저 둔다 |
| Moodle 고가용성 아키텍처 | 사용자 진입점부터 데이터 계층까지 왼쪽에서 오른쪽으로 배치하고, AZ별로 중복 배치하며, 애플리케이션·캐시·파일·DB의 역할을 분리한다. CI/CD와 실행환경도 분리한다 |
| 서버리스 이미지 처리 파이프라인 | 복잡한 이벤트 기반 시스템은 서비스 위치보다 "어떤 사건이 어떤 처리를 유발하는가"를 번호로 설명한다 |
| EKS 애플리케이션 현대화 | 플랫폼 제어 영역 / 애플리케이션 워크로드 / 빌드·배포 / 하이브리드 연결을 한 덩어리로 그리지 않고 시각적으로 분리한다 |
| Amazon VPC Lattice | 한 장짜리 만능 구성도 대신 컴포넌트 구조·트래픽 흐름·중앙집중형·분산형을 개별 그림으로 나눈다. 네트워크 토폴로지와 실제 요청 흐름은 별도의 그림이다 |
| Modern Data Analytics | AWS 제품 카테고리가 아니라 데이터 생애주기로 구성한다. Source → Ingestion → Storage → Governance → Processing → Serving → Consumption |
| Real-Time RAG · GraphRAG | RAG 구성도는 오프라인 수집·인덱싱 경로와 온라인 질의·응답 경로를 반드시 분리한다. 원문 저장 / 정보 추출 / 엔티티·관계 정규화 / 그래프 구축 / 그래프 검색 / 벡터·키워드 검색 / LLM 응답 생성을 독립 단계로 표현한다 |
| Multi-Region API Gateway | 멀티리전은 리전 박스를 두 개 그리는 것으로 끝나지 않는다. Active·Standby 여부, 읽기·쓰기 위치, 복제 방향, DNS 라우팅, 장애 판단 주체, 전환 조건, 복구 리전의 평상시 용량까지 표시한다 |
| Payment System Modernization | 하이브리드는 온프레미스 ↔ AWS로 그리지 않는다. 인터넷 요청과 전용망 요청의 차이, 내부·외부 API 진입점, 신뢰 경계, 암호화 구간, 온프레미스에 남는 시스템, 클라우드로 가는 기능, 데이터 동기화 방향을 구분한다 |
K광역시의회 사업에 이 중 무엇이 필요한가를 골라보면 이렇게 된다. Real-Time RAG의 "두 경로 분리"(수집과 질의를 4장에서 나눠 그린다), Payment Modernization의 "신뢰 경계 구분"(내부망 의원과 인터넷 시민을 다르게 그린다), Modern Data Analytics의 "데이터 생애주기"(원문→정제→인덱스를 역할로 구분한다). 나머지는 이 사업에 필요 없다.
필요한 것만 골라 쓰는 것이 레퍼런스를 제대로 쓰는 법이다.
한국 기업 사례는 그대로 복사하기보다 문제와 설계 결정이 연결되는 방식을 참고하는 것이 좋다. 아래는 AWS 공식 기술 블로그에 공개된 사례들이다.
| 사례 | 핵심 구조 | 구성도 작성 시 배울 점 |
|---|---|---|
| 우아한형제들 데이터 플랫폼 | EKS, EMR on EKS, Airflow, Trino, Ranger, EKS Anywhere, 온프레미스 GPU | 데이터·AI 워크로드 종류와 플랫폼 공통 기능을 분리하고, 단계적 전환을 표시한다 |
| 롯데e커머스 EKS 전환 | 온프레미스 모놀리식 → EKS 기반 마이크로서비스 | "서버 증설 지연·대규모 이벤트 대응"이라는 문제와 자동확장·마이크로서비스라는 선택을 연결해 보여준다 |
| VMS Solutions 데이터 플랫폼 | S3 데이터레이크, ETL, Athena, KMS, IAM, GuardDuty, Config, OpenSearch | 보안 서비스 아이콘을 흩뿌리지 않고 보안·관측 계층으로 묶어 표현한다 |
| 라온엔터테인먼트 게임 플랫폼 | GameLift, DynamoDB, SQS, Lambda 및 분석 파이프라인 | 소규모 팀과 변동성 높은 트래픽에는 관리형 서비스 중심의 간결한 그림이 적합하다 |
| Config Intelligence | EKS, RabbitMQ, KEDA, Karpenter, Spot 인스턴스 | 중단되면 안 되는 메시징·제어 계층과 중단 가능한 작업 노드를 분리한다 |
| Midas EKS 전환 | ECS → EKS, GitOps, Argo CD, Helm | 목표 실행환경뿐 아니라 배포·운영 모델과 전환 경로를 함께 표현한다 |
| Dalpha Hybrid Nodes | AWS 관리 EKS 제어영역, 온프레미스 GPU 노드, VPN·TGW | 하이브리드 전체 구조와 BGP·라우팅 상세 구조를 별도 그림으로 분리한다 |
| KCC 멀티에이전트 플랫폼 | 채널, 오케스트레이션, 부서별 에이전트, 도구, 데이터 | AI 구성도를 채널·오케스트레이션·에이전트·도구·데이터 계층으로 나누고 호출 순서를 번호로 표시한다 |
여덟 사례가 공통으로 알려주는 것은 하나다.
아키텍처는 기술 목록이 아니라, 기존 문제를 해결하기 위해 선택된 설계 결정의 결과로 설명해야 한다.
이 원칙을 실제 작업으로 옮기면, 제안서 문구와 구성도를 이렇게 연결하게 된다.
| 고객 문제 | 설계 결정 | 구성도에 표현할 내용 |
|---|---|---|
| 정기회 기간 트래픽 5배 급증 | 관리형 로드밸런싱 · 자동확장 | 부하 진입점, 확장 대상, 확장 기준(CPU 60%) |
| 관보 API · 외부기관 장애 | 큐 · 재시도 · DLQ | 비동기 경로와 실패 메시지 보관 위치 |
| 민원인 개인정보 외부 노출 우려 | 프라이빗 서브넷 · VPC Endpoint | 인터넷을 경유하지 않는 경로 |
| 답변의 데이터 출처 추적 필요 | 원본 · 정제 · 메타데이터 분리 | Raw · Curated · Catalog 계층 |
| AI 답변의 신뢰성 부족 | 근거 검색 · 출처 반환 · 감사로그 | 검색 경로, 근거 저장소, 응답 로그 |
| 재해 시 4시간 내 복구 필요 | Pilot Light + 교차리전 백업 | 복제 방향, RTO · RPO, 전환 경로 |
이 표를 채울 수 있으면 제안서의 아키텍처 설명 절은 사실상 다 쓴 것이다. 왼쪽 열은 RFP에서 나오고, 가운데 열은 3부 Architecture Brief에서 나오고, 오른쪽 열이 그림이 된다.
그림은 읽히고, 기술적으로도 맞다. 마지막 질문은 이것이다. 이걸 어떻게 개인기가 아니라 조직의 역량으로 만들 것인가?
Part 5에서 시리즈를 마무리한다.
/architecture 파일 구조와 ADR 양식RELATED
