인프라의 재구성, 보이지 않는 혁명
안녕하세요.
오늘은 클라우드를 이루는 인프라에 대해서 쉽게 설명해 볼까 합니다.
클라우드를 이루는 뼈대에 해당하는 구조이고, 이를 통해 클라우드 혁명이 가능했습니다.
이것이 결국 우리가 현재 사용하는 AI의 집이기도 합니다.
"서버 한 대 구매하는 데 3천만 원, 설치에 2주, 3년 뒤에는 고철."
2010년대 초반, 많은 스타트업이 이 악순환에 갇혀 있었습니다.
사용자가 갑자기 몰리면 서비스는 다운되고, 그렇다고 미리 비싼 서버를 사두자니 대부분의 시간 동안 텅 비어 있었죠.
지난 화에서 살펴본 7가지 연장은 바로 이 문제를 해결하기 위해 등장했습니다. 이제 그 연장을 들고 본격적으로 집의 뼈대를 세울 차례입니다.
클라우드의 가장 기본이 되는 인프라(서버, 스토리지, 네트워크)를 설계하는 과정이죠.
여기서 가장 중요한 원칙 하나. 클라우드 세상에서는 '어떤 자재를 어떻게 사용하느냐'가 곧 '매달 내야 하는 관리비'로 직결됩니다.
클라우드 혁명의 심장에는 가상화(Virtualization)라는 기술이 있습니다.
가상화란 무엇인가?
가상화를 이해하려면 먼저 과거를 돌아봐야 합니다.
2000년대 초반까지만 해도 서버 한 대에는 운영체제(OS) 하나만 설치할 수 있었습니다.
웹서버용 서버 1대, 데이터베이스용 서버 1대, 이메일 서버용 서버 1대... 이런 식이었죠.
문제는 대부분의 서버가 실제로는 전체 성능의 10~20%만 사용하고 있었다는 점입니다.
나머지 80~90%는 그냥 놀고 있었던 셈이죠.
가상화는 이 문제를 해결했습니다.
하나의 물리 서버 위에 '하이퍼바이저(Hypervisor)'라는 소프트웨어 계층을 깔면, 그 위에 여러 개의 독립된 가상 서버(VM, Virtual Machine)를 만들 수 있게 된 것입니다.
각 가상 서버는 마치 진짜 서버처럼 완전히 독립적으로 작동하며, 서로 다른 OS와 애플리케이션을 실행할 수 있습니다.
예를 들어볼까요? 64코어 CPU와 512GB 메모리를 가진 고성능 물리 서버 1대가 있다면, 이를 가상화하여 8코어/64GB 가상 서버 8대로 나눠 쓸 수 있습니다.
마치 큰 건물을 통째로 빌리는 대신, 필요한 층만 골라 임대하는 것과 같죠.
가상화가 가져온 세 가지 혁명
첫째, 자원 활용률의 극대화입니다. 놀고 있던 80%의 성능을 여러 고객이 나눠 쓸 수 있게 되었습니다.
클라우드 제공자는 같은 하드웨어로 더 많은 고객에게 서비스할 수 있고, 고객은 필요한 만큼만 빌려 쓸 수 있게 되었죠.
둘째, 빠른 프로비저닝입니다.
과거에는 서버를 주문하면 도착까지 2주, 설치와 설정에 며칠이 더 걸렸습니다.
하지만 가상 서버는? 클릭 몇 번이면 30초 만에 생성됩니다. 소프트웨어로 복사하는 것이니까요.
셋째 그리고 가장 중요한 확장성(Scalability)입니다.
확장성: 클라우드의 진짜 힘
확장성이란 수요가 늘어날 때 시스템 용량을 빠르게 늘리고, 수요가 줄면 다시 줄일 수 있는 능력을 말합니다. 이것이 왜 중요할까요?
유명 연예인이 당신 회사의 제품을 SNS에 올렸습니다. 평소 1분에 100명 정도 방문하던 웹사이트에 갑자기 1분에 10,000명이 몰려듭니다. 과거 온프레미스 환경이었다면? 서버가 다운되고 기회를 놓쳤을 겁니다.
하지만 클라우드라면 몇 분 안에 서버를 10배로 늘려 대응할 수 있습니다. 그리고 트래픽이 진정되면 다시 원래대로 줄여 비용을 절감하죠.
이 확장성은 두 가지 기술의 조합으로 가능해집니다.
가상화 + 로드 밸런싱 = 무한 확장
가상화만으로는 부족합니다. 가상 서버 10대가 있어도, 사용자의 요청을 어떻게 나눠줄지 모르면 소용없으니까요.
여기서 로드 밸런서(Load Balancer)가 등장합니다. 로드 밸런서는 일종의 '교통 정리원'입니다.
사용자의 요청이 들어오면 여러 서버 중 가장 여유 있는 곳으로 자동으로 배분합니다. 한 서버가 바쁘면 다른 서버로, 어떤 서버에 문제가 생기면 자동으로 제외하고 정상 서버에만 요청을 보내죠.
이 조합이 강력한 이유는 이렇습니다:
가상화 덕분에 서버를 30초 만에 추가하거나 삭제할 수 있고, 로드 밸런서 덕분에 추가된 서버로 트래픽을 자동으로 분산할 수 있습니다
결과적으로 클라우드는 수요에 따라 자동으로 늘었다 줄었다 하는 '탄력성(Elasticity)'을 갖게 됩니다.
AWS의 Auto Scaling, Azure의 VM Scale Sets, GCP의 Managed Instance Groups가 바로 이런 자동 확장을 구현한 서비스입니다.
한 이커머스 회사는 평소에 서버 10대를 운영하다가, 블랙프라이데이 같은 대목에는 자동으로 100대까지 늘어나도록 설정했습니다. 이벤트가 끝나면 다시 10대로 자동 축소되고요. 만약 100대를 항상 유지했다면 연간 수억 원의 낭비가 발생했을 겁니다.
이것이 바로 '사용한 만큼만 지불한다(Pay-as-you-go)'는 클라우드 비즈니스 모델의 핵심입니다.
가상화가 없었다면, 로드 밸런싱이 없었다면, 이런 유연성은 불가능했을 것입니다.
클라우드에서 '서버'는 컴퓨트(Compute)라는 용어로도 불립니다. 이는 가상화 기술로 제공되는 가상의 컴퓨터, 즉 인스턴스(Instance)를 의미하죠.
집을 지을 때 거실, 서재, 작업실을 용도에 맞게 설계하듯, 우리 서비스의 목적에 맞는 인스턴스를 선택해야 합니다.
범용 인스턴스: 거실
대부분의 일상적인 작업에 무난하게 사용할 수 있는 공간입니다. 웹사이트 운영처럼 특별히 한쪽으로 치우치지 않은 작업에 적합하죠.
AWS의 m5나 t3 시리즈, Azure의 D-series, GCP의 E2-standard 인스턴스가 여기에 해당합니다.
컴퓨팅 최적화 인스턴스: 작업실
복잡한 계산을 빠르게 처리해야 하는 공간입니다. 과학 기술 시뮬레이션이나 고성능 게임 서버처럼 '두뇌 회전'이 빨라야 하는 작업에 쓰입니다.
AWS의 c5, Azure의 F-series, GCP의 C2-standard 인스턴스 등이 이 역할을 합니다.
메모리 최적화 인스턴스: 서재
대용량 데이터를 메모리에 올려놓고 빠르게 읽고 써야 하는 공간입니다. 실시간 데이터 분석이나 고성능 데이터베이스처럼 '기억 용량'이 커야 하는 작업에 특화되어 있죠.
AWS의 r5나 x1, Azure의 E-series, GCP의 M2, M3 인스턴스가 대표적입니다.
실제로 한 이커머스 회사는 일반 웹서버에 메모리 최적화 인스턴스를 사용하다가 범용 인스턴스로 교체하여 월 300만 원의 비용을 절감했습니다. 용도에 맞는 선택이 얼마나 중요한지 보여주는 사례죠.
클라우드 스토리지는 데이터의 가치와 사용 빈도에 따라 비용을 최적화하는 정교한 시스템입니다.
마치 집 안에서도 자주 쓰는 물건은 손 닿는 곳에, 계절용품은 다락방에 보관하듯 말이죠.
오브젝트 스토리지: 외부 창고
사진이나 동영상, 문서 백업처럼 당장 쓰지는 않지만 안전하게 보관해야 할 데이터를 위한 공간입니다. 거의 무한대로 확장 가능한 '임대 창고'와 같습니다. AWS의 S3, Azure의 Blob Storage, GCP의 Cloud Storage가 대표적입니다.
블록 스토리지: 책상 옆 서랍
서버에 직접 연결해서 쓰는 매우 빠른 전용 저장 공간입니다. 운영체제(OS)나 데이터베이스처럼 속도가 생명인 데이터를 보관하는 곳이죠. AWS의 EBS, Azure의 Disk Storage, GCP의 Persistent Disk가 여기에 해당합니다.
파일 스토리지: 공용 수납장
여러 서버가 동시에 접속해서 파일을 공유해야 할 때 사용합니다. 여러 사람이 함께 문서를 편집할 때 유용합니다. AWS의 EFS, Azure의 Files, GCP의 Filestore 등이 있습니다.
스토리지 티어링: 데이터의 '온도' 관리
클라우드는 여기서 한 걸음 더 나아갑니다. 데이터의 사용 빈도, 즉 '온도'에 따라 공간을 세분화하는 것이죠. - 핫(Hot) 티어: 매일 사용하는 뜨거운 데이터를 보관합니다. 비싸지만 가장 빠릅니다. (S3 Standard, Azure Hot Blob 등)
- 쿨(Cool) 티어: 가끔 사용하는 미지근한 데이터를 보관합니다. 조금 느리지만 저렴합니다. (S3 Standard-IA, Azure Cool Blob 등)
- 아카이브(Archive) 티어: 법적 보관 의무 등으로 거의 사용하지 않는 차가운 데이터를 보관합니다. 매우 느리지만 가장 저렴합니다. (S3 Glacier, Azure Archive Blob 등)
한 금융사는 3년 이상 된 거래 데이터를 핫 티어에서 아카이브 티어로 옮겨 연간 스토리지 비용을 70% 절감했습니다. 1GB당 월 2.3센트에서 0.1센트로 떨어진 것이죠.
네트워크는 이 모든 자원을 연결하고 세상과 소통하게 하는 '혈관'입니다. 아무리 좋은 방과 수납공간이 있어도 복도와 현관이 없으면 쓸모가 없죠.
VPC: 우리만의 독립 공간
모든 설계의 출발점은 VPC(가상 사설 클라우드, Virtual Private Cloud)입니다. 퍼블릭 클라우드 안에 우리 회사만 사용할 수 있도록 논리적으로 격리된 '독립 공간'을 만드는 것이죠. AWS에서는 VPC, Azure에서는 VNet, GCP에서는 VPC Network라고 부릅니다.
회사와 클라우드를 연결하는 두 가지 길
우리 회사 사무실과 이 독립 공간을 연결하는 방식은 크게 두 가지입니다.
- VPN: 인터넷 기반의 '암호화된 일반 도로'입니다. (AWS Site-to-Site VPN, Azure VPN Gateway 등)
- 전용선: 물리적으로 분리된 '회사 전용 고속도로'입니다. (AWS Direct Connect, Azure ExpressRoute, GCP Interconnect 등)
일반적으로 VPN은 월 5만~10만 원 수준이지만, 전용선은 월 100만 원 이상입니다. 대신 속도와 안정성, 그리고 보안성은 비교할 수 없을 정도로 우수하죠.
전용선은 인터넷을 거치지 않고 직접 연결되기 때문에 데이터 유출 위험이 현저히 낮습니다. 금융권이나 의료, 대용량 민감 데이터를 다루는 회사들이 높은 비용에도 전용선을 선택하는 이유입니다.
리전과 가용 영역: 재해에 대비한 설계
모든 인프라는 물리적인 데이터센터가 위치한 리전(Region, 도시)과 그 안에서 독립적으로 운영되는 가용 영역(AZ, Availability Zone, 데이터센터 건물) 개념 위에서 설계됩니다.
예를 들어, 서울 리전 안에는 보통 3~4개의 가용 영역이 있습니다.
각 가용 영역은 서로 다른 전력망과 네트워크를 사용하죠. 한 건물에 지진이나 정전이 발생해도, 다른 건물의 서버가 즉시 작업을 이어받아 서비스가 중단되지 않습니다.
2022년 SK C&C 판교 데이터센터 화재 사고를 기억하시나요? 이 데이터센터에 입주해 있던 네이버, 카카오 등 여러 고객사의 서비스가 동시에 마비되었습니다. 단일 데이터센터에 모든 것을 집중했다가 큰 피해를 입은 사례죠. 클라우드의 멀티 AZ 구성은 바로 이런 재해를 대비한 설계입니다.
지금까지 우리는 클라우드라는 집을 짓는 데 필요한 벽돌, 기둥, 배관, 즉 서버, 스토리지, 네트워크 각각의 특징과 실제 이름들을 깊이 있게 살펴보았습니다.
그렇다면 이 재료들을 어떻게 조합해야 비로소 '웹사이트'나 '데이터 분석 플랫폼'과 같은 쓸모 있는 공간이 만들어질까요?
다음 화에서는 이 구성 요소들이 통합되어 어떤 가치 있는 서비스를 만들어내는지, 그 실전 조합법에 대해 이야기해 보겠습니다.