클라우드 아키텍처의 이해와 서비스 장애 대응 전략 (IaaS vs PaaS)

IaaS와 PaaS의 차이를 이해하고, AWS 및 Cloudflare 등 최근 대형 장애 사례를 통해 회복 탄력성(Resilience) 있는 클라우드 아키텍처 설계를 고찰합니다.

Posted Dec 7, 2025 Updated Mar 29, 2026

By Park Joona

14 min read

클라우드 아키텍처의 이해와 서비스 장애 대응 전략 (IaaS vs PaaS)

클라우드 아키텍처가 뭔데?

클라우드 아키텍처 (Cloud Architecture)란?

클라우드 아키텍처는 클라우드 환경에서 IT 시스템을 구축하기 위한 기술적인 설계도를 의미한다.

쉽게 말해, 서버, 스토리지(저장소), 데이터베이스, 네트워크 등 다양한 클라우드 구성 요소들을 어떻게 배치하고 연결해야 사용자가 원하는 서비스를 안전하고 효율적으로 제공할 수 있을지 구조를 잡는 것이다.

클라우드 아키텍처의 구성 요소

요소	설명	예시
컴퓨팅 (Compute)	프로그램을 실행하는 서버	AWS EC2, 가상 머신
스토리지 (Storage)	파일이나 데이터를 저장하는 공간	AWS S3
데이터베이스 (Database)	정형화된 데이터를 관리하는 곳	AWS RDS, MySQL
네트워크 (Network)	모든 요소가 서로 통신할 수 있게 해주는 길	VPC, 로드 밸런서
보안 (Security)	외부 침입을 막고 권한을 관리하는 문과 열쇠	방화벽, IAM

서버 운영을 전제로 설계하는 것인가?

전통적인 방식, IaaS

전통적인 방식은 서버 운영을 전제로 하는 설계인 IaaS (Infrastructure as a Service, 서비스형 인프라)이다. 서버, 스토리지, 네트워크와 같은 IT 인프라를 인터넷을 통해 가상화된 형태로 제공하는 클라우드 컴퓨팅 서비스 모델이다. 클라우드에서 가상 머신을 빌려서 그 안에 OS도 깔고, 웹 서버도 설치하고, 보안 설정도 내가 직접해야 한다. 쉽게 말해, 빈 컴퓨터를 빌려서 사용하는 것이다.

그렇기 때문에 내가 쓴 만큼만 비용을 지불하면 되고, 물리적 하드웨어 (서버, 스토리지, 네트워크)는 서비스 제공업체가 관리하므로 사용자는 운영 체제, 데이터, 애플리케이션을 직접 구상하기만 하면 된다. 그렇기 떄문에 복잡하고 특수한 설정이 필요하거나, 직접 통제가 필요한 경우 서버 운영을 전제로 하는 아키텍처 설계를 고려해볼 수 있다.

요즘 트렌드, PaaS

최근에는 서버 운영을 안 하는 것 (serverless)을 목표로 설계하기도 한다. PaaS (Platform as a Service, 서비스형 플랫폼)은 개발자가 인프라 걱정 없이 애플리케이션을 개발하고 실행하는 데 필요한 완벽한 클라우드 환경을 제공하는 서비스이다. 서버가 아예 없는 것은 아니지만, 서버 관리를 클라우드 회사 (AWS, Google 등)가 대신 해주는 방식이다.

사용자가 직접 서버, 스토리지, 네트워크 같은 하드웨어 인프라를 관리할 필요가 없기 때문에 개발 생산성을 높일 수 있다. 빠르게 개발해서 서비스 출시가는 게 중요한 경우, 서버 관리에 시간을 쏟지 않아도 되는 서버리스형 아키텍처를 선택할 수 있다.

아키텍처가 왜 중요하지?

아키텍처의 목표

단순히 ‘작동만 하게’ 만드는 게 아니라, 다음 4가지 목표를 가지고 설계를 해야 한다.

확장성 (Scalability): 사용자가 갑자기 100명에서 100만 명으로 늘어났을 때, 서버가 터지지 않고 자동으로 늘어나서 버틸 수 있는가?
가용성 (Availability): 데이터센터에 화재가 나거나 서버 하나가 고장 나도, 서비스가 중단되지 않고 계속 돌아갈 수 있는가?
보안 (Security): 해커의 공격으로부터 고객의 데이터를 안전하게 지킬 수 있는가?
비용 최적화 (Cost Optimization): 불필요하게 낭비되는 자원은 없는가? 사용한 만큼만 낼 수 있는가?

특히 ‘가용성’과 ‘보안’이 가장 중요하고 어려운 과제라고 생각한다.

AWS와 Azure, Cloudflare 장애

cloudflare 장애로 인한 500 Internal Server Error

2025년 12월 5일 한국시간 오후 5시 50분경, 약 20분 간 클라우드플레어 (Cloudflare)를 사용하는 서비스가 먹통이 되는 이슈가 있었다. 나 역시 Notion 페이지 저장에 실패하고 ‘500 Internal Server Error’가 뜨는 불편을 겪었다. 클라우드플레어는 전 세계 인터넷 트래픽의 약 20%를 처리하는 미국의 웹 인프라 및 보안 기업으로 웹사이트와 사용자 사이에서 인터넷 교통경찰이자 철벽 방패 역할을 수행한다. 지난 11월 18일에도 클라우드플레어의 시스템에 문제가 생겨 오픈AI의 챗GPT, X(옛 트위터), 스포티파이, 페이스북, 아마존 사이트 등에서 접속 장애가 발생한 바 있다.

악성 봇을 차단하는 시스템의 설정 파일(Config File) 하나가 너무 커지면서 메모리 오류를 일으킨 것이 원인이었다. 문제는 이 잘못된 설정 파일이 전 세계 모든 서버에 동시에 배포되었다는 점이다. 이로 인해 전 세계 인터넷 트래픽의 약 20%가 영향을 받았다.

뿐만 아니라, 지난 10월 20일에는 AWS (Amazon Web Service)가 약 2시간 35분 동안 장애를 겪었고, 모든 서비스가 정상 운영되기까지는 약 15시간이 걸렸다. 세계 최대 클라우드 컴퓨팅 업체인 만큼, 그 피해도 상당했다. 쉽길 프로젝트 역시 AWS 서버를 사용하고 있어서 접속이 안되었다고 한다.

AWS의 핵심 데이터베이스 서비스인 DynamoDB의 내부 DNS 관리 시스템에서 발생한 작은 오류(경합 조건)가 원인이었다. 사용자가 앱이나 링크를 클릭하면 기기는 해당 서비스로의 연결을 요청한다. DNS는 이 요청을 안내하는 지도 같은 역할을 한다. 그런데 AWS가 그 방향 감각을 잃은 셈이다.

세계 2위 클라우드 서비스인 마이크로소프트 (MS)의 애저 (Azure) 역시 장애로 인한 피해를 막지는 못했다. 현지 시각 10월 29일, 서비스 장애로 인해 이 서버를 이용하는 알래스카항공, 스타벅스, 코스트코 등 다수의 기업이 체크인이나 결제 처리에 불편을 겪었다. 원인은 시스템 설정값 변경으로 인한 문제로 추측한다.

클라우드 서비스에의 과의존

앞서 살펴보았 듯이, 약 한 달 사이에 클라우드 서비스의 대표 세 회사 모두가 서비스 장애를 경험했다.

구성요소 하나만 장애가 있어도 관련된 서비스가 모두 마비되다 보니, 아키텍처 설계도 중요하지만 클라우드에 너무 의존하는 것도 경계해야 할 것 같다고 느꼈다.

특히 AWS의 장애 사례를 통해 두 가지 의존성에 대해 생각해볼 수 있다.

단일 실패 지점 (SPOF): DNS 시스템 하나가 고장 났는데, 그 여파로 전혀 다른 서비스들까지 줄줄이 멈췄다. 이는 시스템 간의 의존성(Dependency)이 너무 강하게 묶여 있었기 때문이다.
리전 (Region) 의존성: 많은 기업이 “미국 동부 리전” 한 곳에만 서버를 두고 있었다. 아키텍처 설계 시 “멀티 리전(Multi-Region)” 전략(서버를 여러 지역에 분산)을 쓰지 않은 서비스들은 속수무책으로 당했다.

과의존을 경계하자

클라우드 아키텍처 설계 시, 서비스 장애가 발생할 경우를 대비한 보수적인 설계가 필요하다.

결국 클라우드 아키텍처는 “최악의 상황에서 어떻게 살아남을 것인가”에 대한 전략을 짜는 것!

구분	초보 아키텍처	고수 아키텍처 (Resilient Architecture)
장애 대응	“안 고장 나게 만들어야지.”	“고장 날 것을 전제로 설계하자.” (Fail-safe)
서버 배치	“관리하기 편하게 한 곳에 몰아넣자.”	“한 곳이 터져도 딴 곳은 살게 흩어놓자.” (Multi-AZ/Region)
배포 방식	“업데이트는 한 방에 시원하게!”	“조금씩 간 보면서 천천히 배포하자.” (Canary/Blue-Green)
연결 구조	“기능끼리 직접 단단하게 연결.”	“기능끼리 느슨하게 연결하여 영향도 최소화.” (Decoupling)