아키텍처 개념 → 직접 다이어그램 그리기 → AWS Well-Architected Framework 순서로 진행했다.
1. 아키텍처란 무엇인가
아키텍처는 시스템을 구성하는 컴포넌트와 그들 간의 관계, 배치, 흐름을 정의하는 설계도다. 서버, 데이터베이스, 스토리지, 네트워크, 보안 같은 구성요소가 서로 어떤 방식으로 연결되는지를 규정한다. IT 관점에서는 인프라 구조, 데이터 흐름, 트래픽 처리 방식 등 전체 시스템의 동작 방식을 설계하는 작업이다.
강의에서는 건축 설계도에 비유했다. 설계도 없이 지은 건물이 부실하듯, 아키텍처를 고려하지 않고 구축한 시스템은 유지보수 비용과 장애 위험이 커진다.
좋은 아키텍처의 6가지 요건
요소
설명
운영 우수성 (Operational Excellence)
모니터링 및 자동화 용이성
보안성 (Security)
데이터 보호 및 접근 제어
신뢰성 (Reliability)
장애가 발생해도 복구 가능
성능 효율성 (Performance Efficiency)
자원 낭비 없이 빠른 처리
비용 최적화 (Cost Optimization)
필요한 만큼만 자원 사용
지속 가능성 (Sustainability)
운영 시 환경적 영향 최소화
이 6가지는 뒤에서 다룰 Well-Architected Framework의 6대 원칙(Pillar)과 정확히 같다. 강의 초반에 "좋은 아키텍처 요건"으로 먼저 소개하고, 후반부에 프레임워크로 형식화하는 구성이다.
💡 느낀 점
6요건이 따로 노는 게 아니라 서로 트레이드오프 관계라는 점이 핵심이다. 비용 최적화를 극단으로 밀면 신뢰성(이중화)이 깎이고, 성능을 위해 리소스를 키우면 비용·지속가능성이 나빠진다. 실무 설계는 결국 이 6개 축 사이에서 우선순위를 잡는 일이다.
"장애가 발생해도 복구 가능"이 신뢰성의 정의인데, 장애를 막는 게 아니라 발생을 전제로 복구를 설계한다는 관점이 클라우드답다. 온프레미스에서 "장애 0"을 목표로 잡던 것과 출발점이 다르다.
AWS Cloud
└─ ap-northeast-2 / Availability Zone - a
└─ VPC 10.10.0.0/16
├─ Public subnet1 10.10.20.0/24
├─ Private subnet1 10.10.21.0/24
└─ Private subnet2 10.10.22.0/24
Internet gateway
2단계 — 구성요소 배치
users(외부) → IGW → Web Server(EC2) → App Server(EC2) → RDS, 그리고 정적 콘텐츠용 S3 bucket을 네트워크 위에 올린다.
3단계 — 요청 흐름을 화살표로 표현
정적 콘텐츠 요청(S3 경로)과 동적 콘텐츠 요청(EC2 → RDS 경로)을 화살표로 구분해서 그린다.
📸 [스크린샷: 3단계 — 정적/동적 요청 흐름 화살표까지 완성된 최종 다이어그램]
💡 실습 중 느낀 점
subnet을 그릴 때 Web 서버를 Public, App·RDS를 Private에 두는 이유가 그림으로 그려보니 바로 잡혔다. 외부에서 직접 닿아야 하는 건 웹 계층뿐이고, DB가 인터넷에서 직접 보이면 그 자체가 사고다. 글로 외울 땐 흐릿했는데 배치를 손으로 하니 명확해졌다.
정적 요청을 S3로, 동적 요청을 EC2→RDS로 분리하는 화살표를 그리면서, 이게 단순 도식이 아니라 비용·성능 설계라는 걸 알게 됐다. 정적 파일을 EC2가 직접 서빙하면 인스턴스 부하와 트래픽 비용이 커지므로 S3(나아가 CloudFront)로 빼는 게 정석이다.
CIDR(10.10.0.0/16 → /24 subnet)을 직접 적어보니 IP 대역 설계가 아키텍처의 일부라는 게 체감됐다. VPC를 /16으로 크게 잡고 subnet을 /24로 쪼개는 관례를 왜 쓰는지(향후 subnet 추가 여유) 그림에서 드러난다.
다이어그램은 결국 "어떤 리소스를 어디에 넣을지"를 먼저 합의하는 도구다. 코드 짜기 전에 이 그림 한 장이 있으면 IGW를 빠뜨리거나 RDS를 Public에 두는 실수를 설계 단계에서 거른다.
3. AWS Well-Architected Framework
Framework란
클라우드에서 안정적이고 효율적인 시스템을 설계하기 위한 기준 가이드라인이다. AWS가 수천 개 고객 아키텍처를 분석한 경험을 바탕으로 만들었고, 단순한 기술 체크리스트가 아니라 비즈니스 성공을 위한 설계 철학으로 제시된다.
6대 원칙 (Pillar)
각 원칙은 정의와 함께 "내 아키텍처가 이 질문에 답할 수 있는가"라는 핵심 질문 세트로 구성된다. 1번에서 본 6요건과 같은 축이되, 점검 질문이 붙어 진단 도구가 된다.
원칙
정의
대표 핵심 질문
운영 우수성
효율적 운영·모니터링·자동화·개선 반복을 설계
장애를 자동 감지·알림하는가? 수동 업무를 자동화했는가?
보안
권한 제한·암호화·감시 체계 + 책임 공유 모델 이해
데이터를 저장·전송 시 모두 암호화하는가? 보안 사고 대응 계획이 있는가?
신뢰성
장애·오류에도 빠르게 복구되고 정상 동작 지속 (고가용성·내결함성)
시스템 장애 시 자동 복구되는가? 리전/AZ 장애에 대응하는가?
성능 효율성
변화하는 요구에 맞춰 적절한 자원을 효율적으로 선택·사용
수요 증가 시 자동 확장되는가? 리소스가 과도/부족하지 않은가?
비용 최적화
필요한 리소스를 적정 크기로, 낭비 없이 사용 (사용량 기반 과금 통제)
불필요하게 쓰는 리소스는 없는가? 더 저렴한 옵션(Spot, Serverless)이 있는가?
지속 가능성
환경 영향 최소화, 에너지 효율 최적화
에너지 소비를 어떻게 줄일까? 탄소 발자국을 줄이는 선택을 하는가?
Well-Architected Tool
콘솔에서 무료로 제공되는 평가 도구다. 워크로드가 6대 원칙에 맞게 설계됐는지 질문 기반으로 점검하고, 자동 위험 분석과 모범 사례 개선 가이드를 내준다.
💡느낀 점
Tool이 결국 위 표의 "핵심 질문"을 그대로 묻는 구조다. 즉 6대 원칙 = 평가 항목이고, 원칙을 먼저 이해하면 Tool은 그걸 자동화한 체크리스트일 뿐이다. 개념과 도구가 1:1로 맞물린다.
신규 설계뿐 아니라 기존 운영 시스템 진단에도 쓴다는 점이 실무적으로 와닿았다. 이미 돌아가는 워크로드를 넣고 돌리면 "High Risk"로 빠진 항목이 개선 우선순위가 된다.
무료에 콘솔 내장이라 진입 장벽이 없다. 다만 질문에 정직하게 답해야 의미가 있다 — "암호화하고 있는가?"에 일단 Yes를 찍으면 리포트가 무용지물이 된다. 도구의 가치는 응답의 정확성에 종속된다.
학습 정리
아키텍처는 구성요소 간 관계·배치·흐름을 정의하는 설계도다. 없이 만든 시스템은 유지보수 비용과 장애 위험이 커진다.
"좋은 아키텍처 6요건"은 곧 Well-Architected Framework의 6대 Pillar(운영 우수성·보안·신뢰성·성능 효율성·비용 최적화·지속 가능성)다. 서로 트레이드오프 관계라 우선순위를 잡는 게 설계의 본질이다.
웹 아키텍처를 직접 그려보면 Public/Private subnet 배치, 정적(S3)·동적(EC2→RDS) 요청 분리 같은 설계 의도가 그림에서 드러난다.
VPC는 가상 네트워크, subnet은 퍼블릭/프라이빗 영역, IGW는 외부 연결, 보안 그룹은 인스턴스 단위 방화벽이다.
Well-Architected Tool은 6대 원칙을 질문 기반으로 자동 점검하는 무료 콘솔 도구다. 신규 설계 검증과 기존 시스템 진단에 모두 쓴다.
