IT 인프라의 패러다임이 클라우드 네이티브(Cloud Native)로 전환되면서, 많은 기업의 의사결정자와 엔지니어들이 고민에 빠지곤 합니다.

“우리의 새로운 애플리케이션 환경을 위해 어떤 인프라를 선택해야 하는가?”라는 근본적인 질문이죠. 과거의 방식대로라면, 우리는 더 높은 성능과 안정성을 보장하는 고가의 서버와 스토리지를 먼저 고려했을 것입니다. 하지만 클라우드 네이티브의 세계에서는 그 생각이 더 이상 최적이 아닐 수 있습니다.

클라우드 네이티브 환경에서는 전통적인 데이터센터 방식인 HCI (하이퍼 컨버지드 인프라)나 고가의 스토리지 장비, 거대한 VM 기반 인프라가 오히려 어울리지 않는 경우가 많습니다. HCI는 서버와 스토리지를 묶어 소프트웨어적으로 통합한 플랫폼으로, 주로 대형 가상머신(VM)을 안정적으로 구동하기 위해 설계된 구조입니다. 이러한 전통 인프라에서는 각 물리 서버에 고가의 스토리지 네트워크(Fibre Channel SAN 등)와 강력한 하드웨어 안정성이 요구됩니다.

이유는 개별 장비의 장애를 하드웨어 수준에서 막고, 만약 장애가 나더라도 라이브 마이그레이션이나 이중화된 스토리지로 서비스 중단 없이 대응하기 위함입니다. 겉보기에는 아주 견고한 구조이지만, 아이러니하게도 클라우드 네이티브 철학에는 맞지 않는 부분이 있습니다.

이 글에서는 MSA(Microservices Architecture), 쿠버네티스(Kubernetes)로 대표되는 클라우드 네이티브 환경에서는 왜 저렴한 범용(Commodity) x86 서버가 오히려 가장 현명하고 효율적인 선택인지 그 이유를 깊이 있게 설명해 드리고자 합니다.

전통적인 IT 환경, 특히 가상화(Virtualization)가 중심이던 시대에는 인프라 자체의 안정성이 무엇보다 중요했습니다. 서버 한 대가 다운되면 그 위에서 동작하던 수많은 가상머신(VM)과 서비스들이 동시에 멈춰버리는 대재앙이 발생할 수 있었기 때문입니다.

이러한 문제를 해결하기 위해 등장한 것이 바로 고가용성(High Availability, HA) 솔루션입니다. 값비싼 공유 스토리지(SAN/NAS)를 이용해 VM 이미지를 중앙에서 관리하고, 한 서버에 장애가 발생하면 다른 서버에서 즉시 VM을 재시작하는 VMware HA나 Hyper-V Failover Cluster 같은 기술이 대표적입니다. HCI(Hyper-Converged Infrastructure)는 여기서 한 걸음 더 나아가 컴퓨팅, 스토리지, 네트워킹을 하나의 어플라이언스로 통합하여 고가용성을 더욱 편리하게 제공하는 솔루션입니다.

클라우드 네이티브 애플리케이션은 인프라가 본질적으로 신뢰할 수 없다(unreliable)는 것을 전제합니다. 즉, 서버나 VM은 언제든지 예고 없이 사라질 수 있는 소모품으로 간주합니다. 대신, 애플리케이션 혹은 플랫폼 레벨에서 스스로 장애를 감지하고 복구하는 ‘회복탄력성(Resilience)’을 내재하고 있습니다.

쿠버네티스를 예로 들어보겠습니다. 쿠버네티스는 여러 개의 노드(서버)를 하나의 거대한 리소스 풀로 관리합니다. 특정 노드에 장애가 발생하면, 쿠버네티스 컨트롤 플레인은 이를 즉시 감지하고 해당 노드에서 실행되던 파드(Pod, 컨테이너의 실행 단위)들을 건강한 다른 노드로 자동으로 옮겨 재시작합니다. 서비스는 중단 없이 계속 제공되죠.

여기에 HCI나 고가의 HA 솔루션을 도입하는 것은 ‘회복탄력성을 위한 중복 투자’과 같습니다.

이미 쿠버네티스가 플랫폼 레벨에서 완벽하게 처리해주는 장애 복구 기능을, 값비싼 비용을 치르며 인프라 레벨에서 또다시 구현하는 셈입니다. 이는 마치 최고급 방탄조끼를 입은 군인에게 다시 한번 값비싼 방탄 방패를 들려주는 것과 같은 비효율입니다. 클라우드 네이티브의 핵심 가치인 ‘비용 효율성’과 ‘민첩성’을 크게 저해하는 선택이 될 수밖에 없습니다.

클라우드 네이티브의 사상적 뿌리는 구글과 같은 하이퍼스케일러(Hyperscaler) 기업들의 고민에서 시작되었습니다. 구글은 전 세계 사용자에게 끊김 없는 서비스를 제공하기 위해 수백만 대의 서버를 운영해야 했습니다. 이 모든 서버를 고가의 고성능 장비로 채우는 것은 천문학적인 비용 문제에 부딪힐 수밖에 없었습니다.

그래서 구글은 발상을 전환했습니다. 비싸고 완벽한 소수의 서버 대신, 저렴하고 평범한 x86 서버 수만, 수십만 대를 엮어 하나의 거대한 컴퓨터처럼 사용하는 ‘스케일 아웃(Scale-out)’ 방식을 택한 것입니다.

물론 이 방식에는 전제 조건이 따릅니다. 개별 서버는 언제든 고장 날 수 있다는 사실을 받아들여야 합니다. 구글은 이 문제를 하드웨어가 아닌 소프트웨어로 해결했습니다. 수많은 서버의 장애를 자동으로 감지하고 작업을 다른 곳으로 이전시키는 내부 플랫폼 ‘보그(Borg)’를 개발했고, 이 보그의 설계 사상과 경험이 녹아들어 탄생한 것이 바로 오늘날 클라우드 네이티브의 표준이 된 ‘쿠버네티스’입니다.

이 모델이 최적인 이유는 다음과 같습니다.

• 비용 효율적 확장 (Cost-Effective Scalability): 서비스의 규모가 커져 더 많은 컴퓨팅 파워가 필요할 때, 값비싼 고성능 서버 한 대를 추가(Scale-up)하는 것보다 저렴한 범용 서버 여러 대를 추가(Scale-out)하는 것이 훨씬 경제적입니다.
• 장애 영향 최소화 (Blast Radius Reduction): 고성능 서버 한 대가 다운되면 그 파급 효과는 매우 큽니다. 하지만 수천 대의 저렴한 서버 중 한두 대가 고장 나는 것은 전체 시스템에 거의 영향을 주지 않습니다. 쿠버네티스와 같은 오케스트레이션 툴이 알아서 처리해주기 때문입니다.
• 동질성 및 표준화 (Homogeneity & Standardization): 모든 서버를 비슷한 사양의 범용 장비로 구성하면, 인프라 관리가 단순해지고 교체 및 유지보수가 용이해집니다. 특정 벤더에 종속될 위험도 줄어듭니다.

결론적으로, 컨테이너 기술은 애플리케이션을 하드웨어로부터 완벽하게 추상화하고, 쿠버네티스는 이 컨테이너들을 저렴한 서버들의 바다 위에서 자유롭게 헤엄치게 만들어주는 역할을 합니다. 이 조합이야말로 구글이 증명해 낸 가장 효율적이고 강력한 현대적 인프라 운영 방식입니다.

핵심은 확장성과 비용, 그리고 실패 허용성에 있습니다. 저렴한 서버 10대를 묶으면 비싼 서버 1대보다 종합 성능이나 용량 면에서 더 유리할 수 있습니다. 필요하면 11대, 12대로 수평 확장하면 되고, 반대로 부하가 줄면 일부 서버를 쉬게 할 수도 있습니다. 이러한 스케일 아웃(scale-out) 방식은 클라우드 네이티브의 기본으로, 작은 서버들을 필요한 만큼 덧붙이는 식으로 성능과 용량을 키워갑니다.

반면 전통적인 스케일 업(scale-up) 방식에서는 이미 큰 한 대의 서버를 더 업그레이드할 방법이 한계가 있거나 비용이 급증합니다. 게다가 서버 한 대에 모든 걸 의존하면 그 장비에 장애가 날 경우 영향이 치명적이지만, 작은 서버 여러 대로 구성하면 한 두 대 문제 발생해도 전체 서비스에는 큰 지장이 없습니다. 구글의 사례처럼 고장 날 것을 전제로 값싼 부품을 사용하고, 대신 소프트웨어가 이를 최대한 최적화하고 대비하는 구조가 대형 인터넷 서비스에 잘 맞았던 것입니다.

정리하면, 저렴한 x86 서버 + 컨테이너 + 오케스트레이션 소프트웨어 조합은 비용 효율성과 확장성, 안정성을 모두 잡아주기 때문에 클라우드 네이티브에 최적이라고 볼 수 있습니다. 값싼 서버들을 “작은 부품”으로 삼아 레고처럼 크게 조립해나가는 셈인데, 한 조각이 망가지면 그 조각만 바꾸면 되고 전체 구조는 끄떡없는 탄력적인 시스템이 되는 것입니다. 이러한 철학은 구글뿐 아니라 페이스북, 아마존 등의 빅테크는 물론이고, 이제는 일반 기업과 공공기관에도 점차 도입되어 경제적인 클라우드 네이티브 인프라를 구축하는 방향으로 나아가고 있습니다.

전통적인 엔터프라이즈 IT 환경에서는 인프라 장비 자체에 높은 요구사항을 부여하곤 합니다. 예를 들어 서버는 반드시 이중 전원, 이중 네트워크, RAID 디스크로 무장하고, 스토리지는 고성능 SAN으로 꾸미며, 네트워크 스위치도 막대한 트래픽을 처리할 수 있는 장비로 갖추는 식입니다. 당연히 이런 사양을 추구하면 비용이 크게 들고 인프라 구성이 복잡해집니다. 그런데 클라우드 네이티브 환경에서는 이러한 요구사항이 비교적 낮습니다. 다시 말해, 값싸고 평범한 인프라로도 충분히 운영이 가능합니다. 그 이유는 클라우드 네이티브의 아키텍처적인 특성 때문입니다.

클라우드 네이티브 시스템은 언제든지 부분적인 장애가 발생할 것을 가정하고 디자인됩니다. 따라서 인프라 각 구성 요소가 100% 완벽하지 않아도, 시스템 전체적으로는 이를 우회하거나 보완해서 사용자에게 끊김 없는 서비스를 제공할 수 있습니다. 예를 들어 어떤 서버의 네트워크가 일시적으로 느려지거나 장애가 발생하면 쿠버네티스 오케스트레이터가 해당 서버에서 동작하던 컨테이너들을 다른 정상 노드로 자동 이동시킵니다. 또, 특정 컨테이너가 오류로 중단되면 이를 감지하여 새로운 컨테이너 인스턴스를 띄워 자동 복구합니다. 이러한 메커니즘이 있으니, 일반적인 이더넷 네트워크나 표준 스토리지로도 충분히 서비스를 운용할 수 있습니다. 반드시 최고급 네트워크 장비나 초고속 스토리지 채널이 아니어도 된다는 것입니다. 실제로 퍼블릭 클라우드 사업자들이 제공하는 인스턴스들을 보면, 개별 VM은 평범한 x86 서버 상에서 동작하며 네트워크도 특수 장비 없이 이더넷과 소프트웨어 정의 네트워크로 구성돼 있습니다. 그 대신 **가용 영역(Availability Zone)**을 다중화하거나 여러 인스턴스를 묶어 하나의 서비스를 구성하도록 권장하여, 한두 개 요소의 장애를 흡수하게 합니다. 즉, 저가형 인프라라도 여러 개를 조합하면 고가 장비 한 대를 쓰는 것과 맞먹는 안정성을 얻을 수 있게 설계하는 것입니다. 이는 소프트웨어 레벨에서의 신뢰성 확보 전략으로, 클라우드 네이티브 환경의 핵심 원리 중 하나입니다.

불필요한 기능이나 사양을 줄일 수 있기 때문입니다.

클라우드 네이티브 애플리케이션은 불필요한 상태(state)를 가지지 않는 방향으로 설계되는 경우가 많습니다. 상태를 내부에 두지 않는 스테이트리스(stateless) 서비스는 각 요청을 독립적으로 처리하고 데이터를 외부 저장소(예: DB나 객체 스토리지)에 보관하므로, 개별 애플리케이션 인스턴스에 고성능 저장장치나 특별한 파일 시스템이 요구되지 않습니다. 컨테이너의 로컬 스토리지는 휘발성으로 쓰고, 영속적인 데이터는 외부 관리형 DB나 분산 스토리지에 맡기는 식입니다. 따라서 컨테이너가 올라가는 호스트 서버 입장에서는 고가의 스토리지 어레이가 굳이 필요 없습니다. 로컬 디스크나 직결 SSD로도 충분하며, 중요 데이터는 이미 여러 곳에 복제되어 안전하게 보관되고 있습니다. 이렇듯 애플리케이션이 인프라에 기대는 바가 적기 때문에, 인프라 자체는 낮은 사양이어도 무방합니다. 예를 들어, 앞서 인용한 클라우드 전문가의 말대로 현대적인 클라우드 네이티브 앱은 직접 파일시스템에 의존하지 않고 DB와 객체 저장소(S3 등)를 사용하도록 개발하는 것이 권장되며, 특수한 스토리지 하드웨어 없이도 로컬 디스크+소프트웨어 복제로 충분하다고 합니다. 복잡한 NAS나 SAN, 전용 스토리지 장비를 도입하지 않아도 되는 것이지요. 그만큼 인프라 구성이 단순해지고 비용이 절감됩니다.

수평 확장에 최적화된 부하 분산 구조입니다.

클라우드 네이티브 환경에서는 요청을 여러 인스턴스에 고르게 분배하는 스케일 아웃 아키텍처를 사용합니다. 이때 개별 서버나 네트워크 링크 하나에 전체 부하가 집중되지 않도록 설계합니다. 예를 들어 1Gbps짜리 네트워크 인터페이스카드(NIC)를 가진 서버 여러 대가 있다면, 로드밸런서를 통해 트래픽을 분산시켜 각 서버가 그 중 일부만 처리하게 합니다. 그러면 한 서버당 필요한 네트워크 대역폭은 1/N로 줄어들어 고가의 100Gbps NIC가 없어도 됩니다. 스토리지도 마찬가지로, 여러 노드에 데이터와 I/O를 분산하면 개별 디스크의 초고속 성능이 없어도 총합으로는 높은 처리량을 달성할 수 있습니다. 이러한 분산 부하 덕분에 인프라 개별 구성품의 스펙은 높지 않아도 되는 것입니다. 오히려 너무 높은 스펙의 부품은 비용만 증가시키고 효율이 떨어질 수 있습니다. 클라우드 네이티브는 작은 자원들을 모아서 큰 성능을 얻는 구조이기 때문에, “충분히 좋은” 수준의 저렴한 인프라가 최상의 선택이 됩니다.

마지막으로 비용과 운영상의 이점을 들 수 있습니다. 저사양 인프라를 용인한다는 것은 곧 예산 절감으로 이어집니다. 공공기관처럼 제한된 예산 내에서 최대 성과를 내야 하는 환경에서는, 굳이 꼭 필요하지 않은 인프라 사양에 예산을 낭비하지 않는 것이 중요합니다. 클라우드 네이티브 환경은 앞서 설명한 이유들로 불필요한 인프라 투자 없이도 목표 성능과 안정성을 달성하도록 고안되었습니다. 또한 복잡한 전용장비를 줄이고 표준화된 저비용 인프라로 통일하면 운영 관리가 단순해집니다. 특별한 스킬을 요하는 장비보다 범용 기술 리소스를 활용할 수 있고, 예비 부품이나 교체도 수월합니다. 예컨대 과거에는 특정 벤더의 스토리지 장비 장애 시 전담 기술지원이 필요했다면, 이제는 범용 x86 서버 하나 교체하면 끝날 일입니다. 그만큼 운영 인력의 부담도 줄어들고 DevOps의 자동화 관리가 쉬워집니다.

여기서 말하는 ‘저렴하다’는 것이 무조건 성능이 낮고 품질이 조악한 서버를 의미하는 것은 아닙니다. ‘고가의 특수 기능이나 이중화 부품을 배제한, 합리적인 가격의 표준 서버’를 의미합니다.

클라우드 네이티브에 적합한 서버란 표준화된 범용 x86 아키텍처를 따르는 서버로서, 개당 가격이 합리적이고 필요 시 여러 대를 손쉽게 추가할 수 있는 기계들을 말합니다. 일반적으로 시중에 나오는 1U 또는 2U 랙마운트 서버, 예를 들어듀얼 소켓 CPU에 수십 코어, 수십~수백 GB 메모리, 그리고 수 테라바이트의 일반 SSD/HDD 저장장치를 갖춘 모델들이 이에 해당합니다. 중요한 것은 특별히 비싼 전문 장비가 아닌 범용 서버라는 점입니다.

이런 서버들은 벤더 종속 없이 표준 부품으로 구성되며, 고장 시 동일하거나 유사한 사양의 다른 서버로 손쉽게 대체할 수 있어야 합니다.

한 대 한 대가 너무 중요해서 교체가 어렵다면 클라우드 네이티브의 “가벼운 구성요소” 철학과 어긋나기 때문입니다. 따라서 화이트박스(White-box) 서버라 불리는 자체 조립식 서버나, Dell/HP/레노버 같은 범용 x86 서버 제조사의 보편적인 모델들이 많이 활용됩니다.

클라우드 네이티브 환경에 적합한 서버의 기준은 다음과 같이 정리할 수 있습니다.

• CPU: 클럭 스피드보다는 코어(Core) 수가 더 중요합니다. 수많은 마이크로서비스(파드)들이 동시에 실행되므로, 많은 수의 작업을 병렬로 처리할 수 있는 다중 코어 프로세서가 유리합니다. 최고급 모델보다는 가성비 좋은 모델을 여러 대 사용하는 것이 효율적입니다.
• 메모리(RAM): 가능한 한 많이 확보하는 것이 좋습니다. 수백, 수천 개의 컨테이너가 메모리를 나눠 사용하기 때문에 메모리는 다다익선입니다. 표준적인 ECC RAM이면 충분합니다.
• 스토리지: 고가의 외장 SAN/NAS 스토리지는 필요 없습니다. 오히려 빠른 I/O가 필요한 경우, 서버 내부에 장착하는 로컬 NVMe SSD가 훨씬 효과적입니다. 영구적인 데이터 저장이 필요하다면, Ceph, GlusterFS, Rook와 같은 분산 스토리지 솔루션(SDS, Software-Defined Storage)을 쿠버네티스 클러스터 위에서 함께 운영하는 방식을 택합니다. 이 역시 값비싼 스토리지 하드웨어가 아닌, 범용 서버의 디스크들을 묶어 소프트웨어적으로 구현합니다.
• 네트워크: 10GbE 또는 25GbE 수준의 표준 이더넷이면 대부분의 워크로드에 충분합니다. Calico, Cilium과 같은 CNI(Container Network Interface) 플러그인이 소프트웨어 레벨에서 복잡한 컨테이너 간 통신을 처리해주기 때문에, 고가의 특수 네트워크 장비는 필요하지 않습니다.
• 기타: 이중화된 파워 서플라이(Redundant PSU)나 RAID 컨트롤러 같은 부품도 필수는 아닙니다. 노드 하나의 장애는 클러스터 전체의 안정성에 영향을 미치지 않기 때문입니다. 이러한 부품을 제외하면 서버 비용을 더욱 절감할 수 있습니다.
  핵심은 ‘개별 컴포넌트의 완벽함’이 아닌, ‘전체 시스템의 회복탄력성’에 투자하는 것입니다.

핵심은 ‘개별 컴포넌트의 완벽함’이 아닌, ‘전체 시스템의 회복탄력성’에 투자하는 것입니다.

클라우드 네이티브 환경에서는 인프라 자체에 높은 사양을 요구하지 않아도 되는 구조적인 이유가 있습니다. 시스템이 저렴한 구성 요소들의 조합으로도 높은 신뢰성과 성능을 낼 수 있도록 설계되었기 때문입니다. 이는 벤더 종속성을 탈피하여 궁극적으로는 제한된 예산으로 최대의 효과를 누리려는 공공기관이나 기업에게 매우 매력적인 접근법입니다. 클라우드 네이티브를 도입하면 “값싼 인프라=부실한 서비스”가 아니라 “똑똑한 소프트웨어=튼튼한 서비스”의 공식을 구현할 수 있으며, 결과적으로 인프라에 대한 과도한 투자 없이도 안정적이고 유연한 IT 서비스를 제공할 수 있게 됩니다. 이는 현대 IT 환경에서 빠르게 입증되고 있는 사실이며, 앞으로도 클라우드 네이티브 트렌드는“더 적은 것으로 더 많은 것을 이루는”효율적인 인프라 방향으로 계속 발전할 것입니다.

• Kubernetes (쿠버네티스) 도입을 가로막는 오해와 장벽 12가지
• 불변의 인프라스트럭처(Immutable Infrastructure) 란 무엇인가?
• [자료 다운로드] 불변의 인프라스트럭처란? | 클라우드 시대의 새로운 운영 패러다임