S3 버킷은 서브넷 안에 없다. Lambda는 고객 VPC에서 실행되지 않는다. 그림이 읽히는 것과 맞는 것은 다른 문제다. 배치 오류 다섯 가지를 바로잡고, AWS 공식 레퍼런스와 한국 사례에서 복사할 것이 아니라 배울 것을 가려낸다.
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 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
