Cloud Native

클라우드는 자원을 빌리는 소비 모델이고, 클라우드 네이티브는 그 자원을 전제로 애플리케이션을 만드는 설계·운영 방식입니다.

CNCF 용어집은 클라우드 컴퓨팅을 “CPU·네트워크·디스크 같은 자원을 인터넷 너머에서 필요할 때 쓸 수 있게 제공하는 모델”로 정의합니다(출처: CNCF Cloud Native Glossary — Cloud Computing). 핵심은 소유가 아니라 임대입니다. 자본 지출(서버 구매)을 운영 지출(사용량 과금)로 바꾸고, 필요할 때 자원을 늘렸다 줄일 수 있는 조달 방식이 클라우드입니다.

반면 클라우드 네이티브 기술은 “퍼블릭·프라이빗·하이브리드 클라우드 같은 현대적이고 동적인 환경에서 확장 가능한 애플리케이션을 구축하고 운영하게 하는 기술”입니다(출처: CNCF Cloud Native Glossary — Cloud Native Tech). 컨테이너, 서비스 메시, 마이크로서비스, 불변 인프라, 선언적 API 가 대표 기술로 명시되어 있습니다.

두 정의를 나란히 놓으면 층위가 다르다는 점이 보입니다. 클라우드는 “어디서 실행하느냐”에 대한 답이고, 클라우드 네이티브는 “어떻게 만들고 운영하느냐”에 대한 답입니다. 그래서 온프레미스 데이터센터에 쿠버네티스 기반 프라이빗 클라우드를 구축해 운영하는 조직은 퍼블릭 클라우드 계약이 없어도 클라우드 네이티브일 수 있고, 반대로 퍼블릭 클라우드 요금을 매달 내면서도 클라우드 네이티브와는 거리가 먼 조직이 있을 수 있습니다.

Cloud Native Forum 은 이 구분을 한 걸음 더 밀고 갑니다. 클라우드는 “무엇(What)” 또는 “어디서(Where)”의 문제이고, 클라우드 네이티브는 “어떻게(How)”의 문제 — 애플리케이션을 개발하고 배포하고 운영하는 방법론이자 문화의 총체 — 라는 정리입니다(출처: 왜 진짜 전문가들은 ‘클라우드’보다 ‘클라우드 네이티브’를 말하는가). 같은 글은 현장에서 자주 보이는 등식 두 개를 오해로 지목합니다. 하나는 “특정 클라우드 사업자(CSP)의 관리형 서비스를 최대한 끌어다 쓰는 것이 클라우드 네이티브”라는 등식이고, 다른 하나는 기존 시스템을 VM 째로 옮겨 놓은 상태를 클라우드 네이티브라고 부르는 것입니다. 전자는 오히려 사업자 종속을 키우고, 후자는 클라우드 기반(cloud-based)일 뿐 클라우드 네이티브(cloud-native)는 아닙니다.

그림 1. 클라우드와 클라우드 네이티브의 층위 차이

클라우드로 가는 길은 하나가 아니라 rehost, replatform, refactor 로 이어지는 스펙트럼이며, 클라우드 네이티브는 그 끝에 있습니다.

업계에서 널리 쓰는 마이그레이션 전략 분류(6R)는 원래 Gartner 가 제시한 5R 분류를 AWS 가 확장한 것으로, 이전(rehost)·재배치(replatform)·재구매(repurchase)·재설계(refactor)·유지(retain)·폐기(retire)로 나뉩니다(출처: AWS Prescriptive Guidance — 6 R’s migration strategies). 이 가운데 실행 경로에 해당하는 세 가지를 보겠습니다.

• Rehost(리프트 앤 시프트) — 애플리케이션을 고치지 않고 VM 째로 클라우드에 옮깁니다. 이전 속도는 가장 빠르지만, 배포 주기·확장 방식·장애 대응은 온프레미스 시절 그대로입니다.
• Replatform — 코드 골격은 유지하되 운영 요소 일부를 교체합니다. 자체 운영 DB 를 관리형 데이터베이스로 바꾸거나, 애플리케이션을 컨테이너에 담아 관리형 쿠버네티스에 올리는 수준입니다.
• Refactor(재설계) — 애플리케이션을 마이크로서비스로 분해하고 CI/CD·자동 확장·관측성을 전제로 다시 만듭니다. 비용과 기간이 가장 크지만, 클라우드의 탄력성을 온전히 쓰는 단계는 여기서 시작됩니다.

여기서 rehost 를 “하이퍼바이저 갈아타기”로 좁혀 이해하면 함정에 빠집니다. VMware 에서 다른 VM 플랫폼으로 옮기는 작업은 브랜드를 교체하는 일이지 구조를 바꾸는 일이 아닙니다. VM 마다 게스트 OS 가 따로 붙는 구성은 그대로 남고, OS 별 보안 패치와 라이선스 관리 부담도 그대로 이어집니다. 이미지 포맷마저 VMDK·VHD·QCOW2 로 갈리기 때문에 플랫폼을 바꿨다는 이유로 이동성이 생기지도 않습니다(출처: VM 에서 다른 VM 으로 전환은 중복 투자일 뿐, 좋아지는 것은 없다). 게다가 애플리케이션이 모놀리식으로 남아 있으면 CI/CD·불변 인프라 같은 운영 자동화의 전제 자체가 성립하지 않습니다.

정리하면 “클라우드를 쓴다”는 말은 rehost 만 해도 참이 되지만, “클라우드 네이티브다”는 말은 refactor 방향으로 상당히 이동해야 참이 됩니다. 두 용어의 차이는 결국 이 스펙트럼 위에서 우리 시스템이 어디에 서 있느냐의 차이입니다.

그림 2. 마이그레이션 스펙트럼 — rehost에서 refactor까지

VM 위 모놀리식은 한 덩어리로 배포·확장되고, 컨테이너 위 마이크로서비스는 서비스 단위로 따로 배포·확장됩니다.

전통적 배포 방식에서 애플리케이션은 물리 서버나 VM 위에서 한 덩어리(모놀리식)로 동작했습니다. 쿠버네티스 공식 문서는 이 흐름을 전통 배포 시대 → 가상화 배포 시대 → 컨테이너 배포 시대로 정리하면서, 컨테이너가 VM 보다 가볍고 OS 를 공유하면서도 애플리케이션마다 파일시스템·CPU·메모리를 격리해 주는 실행 단위라고 설명합니다(출처: Kubernetes 공식 문서 — 개요, 한국어).

이 실행 단위의 차이가 아키텍처의 차이로 이어집니다. 모놀리식은 결제 기능 하나를 고쳐도 애플리케이션 전체를 다시 배포해야 하고, 트래픽이 몰리면 전체를 복제해 수직·수평 확장해야 합니다. 반면 컨테이너 기반 마이크로서비스는 결제 서비스만 배포하고 결제 서비스만 확장할 수 있습니다. 이렇게 컨테이너·MSA·CI/CD·DevOps 네 요소가 맞물려 돌아가는 구조는 컨테이너 기반 배포와 쿠버네티스 문서에서 이어 볼 수 있습니다.

그림 3. 모놀리식 VM 배포와 컨테이너·MSA 배포의 구조 비교

여기서 오해 하나를 짚고 가겠습니다. rehost 로 옮긴 VM 도 클라우드 콘솔에서 몇 분 만에 새로 만들 수 있으니 “우리도 탄력적”이라고 생각하기 쉽습니다. 하지만 애플리케이션이 한 덩어리인 이상 확장 단위도 한 덩어리입니다. 인프라는 탄력적인데 애플리케이션이 그 탄력을 받아 내지 못하는 상태 — 이것이 “클라우드에 있지만 클라우드 네이티브는 아닌” 상태의 전형입니다.

클라우드 네이티브 운영의 핵심은 사람이 서버를 고치는 대신, 시스템이 선언된 상태를 스스로 회복하는 자동화입니다.

VM 중심 운영에서는 장애가 나면 담당자가 접속해 프로세스를 재시작하고, 트래픽이 늘면 증설 품의를 올려 서버를 추가합니다. 확장은 대체로 더 큰 장비로 바꾸는 수직 확장(scale-up)이고, 배포는 정해진 시간에 수동 절차로 진행됩니다.

쿠버네티스 기반 운영은 방식이 다릅니다. 운영자는 “이 서비스는 항상 3개 인스턴스가 떠 있어야 한다”는 원하는 상태를 선언하고, 쿠버네티스가 현재 상태를 그 목표에 맞춥니다. 컨테이너가 죽으면 자동으로 다시 띄우는 자가 치유(self-healing), 부하에 따라 인스턴스 수를 조절하는 자동 확장이 오케스트레이션 계층에서 처리됩니다(출처: Kubernetes 공식 문서 — 개요, 한국어). 배포 역시 CI/CD 파이프라인이 담당해 빌드·테스트·릴리스가 자동으로 이어집니다.

그림 4. 선언적 상태 조정과 자가 치유 루프

운영 관점에서 두 세계의 차이를 한 줄로 줄이면 이렇습니다. 전자는 “장애가 나면 사람이 뛰는 체계”이고, 후자는 “장애가 나면 시스템이 먼저 복구하고 사람은 원인을 보는 체계”입니다. 같은 클라우드 위라도 운영 부담과 야간 대응 빈도가 갈리는 이유가 여기에 있습니다.

같은 클라우드 요금제라도 자원 활용 밀도가 다르면 청구서가 달라집니다. 차이를 만드는 것은 요금제가 아니라 아키텍처입니다.

rehost 방식은 온프레미스에서 잡던 여유 용량을 그대로 들고 갑니다. 최대 부하 기준으로 산정한 VM 을 24시간 켜 두면, 실제 사용률이 낮은 시간에도 같은 요금이 나갑니다. 온프레미스의 고정비가 클라우드의 고정비로 바뀌었을 뿐입니다.

여기에 청구서에서 잘 안 보이는 항목이 하나 더 붙습니다. VM 마다 게스트 OS 가 하나씩 필요하니, 같은 워크로드를 돌려도 OS 몫의 메모리·디스크·라이선스·패치 공수가 VM 수만큼 늘어납니다. Cloud Native Forum 은 이를 “OS 세금(OS Tax)”이라 부르면서, 정적 자원 할당, 명령형 수동 운영, 하이퍼바이저와 애플리케이션의 이중 관리, 할당했지만 쓰지 않는 유휴 자원을 VM 기반 IaaS 의 구조적 비효율로 함께 지목합니다(출처: 가상화 vs 클라우드 네이티브 인프라 아키텍처 완전 분석). 컨테이너는 호스트 커널을 공유하므로 이 중복 자체가 사라집니다.

컨테이너 기반으로 재설계한 시스템은 밀도를 높일 여지가 큽니다. 여러 서비스가 노드 풀을 공유하고, 자동 확장이 부하에 맞춰 인스턴스 수를 조절하며, 야간·주말처럼 트래픽이 빠지는 시간대에는 자원을 반납합니다. 필요할 때 쓰고 아닐 때 줄이는 과금 모델의 장점은 애플리케이션이 그렇게 늘고 줄 수 있을 때에만 실현됩니다(출처: CNCF Cloud Native Glossary — Cloud Computing).

물론 자동 확장 정책이 엉성하면 오히려 비용이 튀는 역효과도 있습니다. 요청·제한(request/limit) 값이 실제 사용량과 동떨어지면 노드가 과다 확보되고, 축소 정책이 없으면 늘어난 인스턴스가 그대로 남습니다. 컨테이너 환경에서는 비용을 서비스·팀 단위로 가시화한 뒤 자원 요청값을 실측에 맞춰 조정하는 FinOps 실천이 함께 가야 절감이 실현됩니다.

같은 클라우드 위라도 설계 방식에 따라 배포·확장·복구·비용의 작동 원리가 달라집니다. 아래 표는 그 차이를 운영 항목별로 대조한 것입니다.

표에서 눈여겨볼 지점은 왼쪽 열이 “틀린” 방식이 아니라는 점입니다. 왼쪽은 이전 속도와 변경 최소화가 강점이고, 오른쪽은 배포 민첩성과 탄력성이 강점입니다. 문제는 왼쪽 방식으로 옮겨 놓고 오른쪽의 효과(빠른 배포, 자동 복구, 비용 절감)를 기대할 때 생깁니다. 기대와 방식이 어긋나면 “클라우드로 갔는데 달라진 게 없다”는 평가로 이어지고, 이는 도구가 아니라 선택한 마이그레이션 경로의 결과입니다.

모든 시스템을 refactor 할 필요는 없습니다. 변경 빈도와 트래픽 변동성이 큰 시스템부터 단계적으로 옮기는 판단이 현실적입니다.

판단 기준을 세 가지로 제안합니다.

1. 변경 빈도 — 요구사항 변경과 배포가 잦은 시스템일수록 refactor 의 효과가 큽니다. 연 1~2회 바뀌는 안정적 시스템은 rehost 나 retain(유지)이 합리적일 수 있습니다.
2. 트래픽 변동성 — 피크와 평시의 격차가 큰 서비스는 자동 확장의 이득이 큽니다. 부하가 일정한 내부 시스템은 이득이 제한적입니다.
3. 장애 영향 범위 — 멈추면 사업 손실이 큰 서비스일수록 자가 치유와 무중단 배포의 가치가 큽니다.

이 기준으로 애플리케이션 포트폴리오를 평가하면, “전부 클라우드 네이티브로”가 아니라 “이 시스템은 refactor, 저 시스템은 replatform, 나머지는 유지”라는 현실적인 그림이 나옵니다. 실무에서는 한 시스템 안에서도 경로를 섞을 수 있습니다. 대외 서비스 프런트는 refactor 로 재설계하고, 뒤에 붙은 정산 배치는 replatform 으로 컨테이너에만 담고, 수년 내 폐기 예정인 모듈은 손대지 않는 식입니다. 퍼블릭 클라우드로 옮기는 것과 클라우드 네이티브로 바꾸는 것이 어떻게 다른지는 공공부문 클라우드 네이티브 전략 글에서 사례와 함께 볼 수 있습니다.

클라우드와 클라우드 네이티브는 경쟁 관계가 아니라 층위가 다른 개념입니다. 클라우드가 빌린 땅이라면 클라우드 네이티브는 그 땅의 특성에 맞게 지은 건물입니다. 우리 조직의 질문은 “클라우드냐 클라우드 네이티브냐”가 아니라, “어떤 시스템을 어느 단계까지 옮길 것인가”가 되어야 합니다. 그 답을 세우는 출발점으로 이 스펙트럼 지도를 활용하시기 바랍니다.

Q. 클라우드를 쓰면 자동으로 클라우드 네이티브가 되나요?

아닙니다. 클라우드는 자원을 빌리는 소비 방식이고, 클라우드 네이티브는 애플리케이션을 그 자원에 맞게 설계·운영하는 방식입니다. VM 을 그대로 옮긴 rehost 는 클라우드 사용이지만 클라우드 네이티브는 아닙니다.

Q. 리프트 앤 시프트(lift-and-shift)는 나쁜 선택인가요?

아닙니다. 데이터센터 계약 만료처럼 이전 속도가 최우선일 때는 합리적인 선택입니다. 다만 rehost 로 끝내면 배포 속도·확장성·비용 효율은 거의 개선되지 않으므로, 이후 replatform·refactor 로 이어 갈 대상을 정해 두는 편이 좋습니다.

Q. VMware 에서 다른 가상화 플랫폼으로 옮기면 클라우드 네이티브가 되나요?

아닙니다. 하이퍼바이저를 교체해도 VM 마다 게스트 OS 가 붙는 구조, OS 별 패치·라이선스 관리, 모놀리식 애플리케이션은 그대로 남습니다. 이미지 포맷이 플랫폼별로 갈리므로 이동성도 크게 나아지지 않습니다. 실행 단위를 컨테이너로 표준화하고 오케스트레이션 계층을 올려야 구조가 바뀝니다.

Q. 클라우드 사업자의 관리형 서비스를 많이 쓰면 클라우드 네이티브인가요?

관리형 서비스 사용량과 클라우드 네이티브 성숙도는 별개입니다. 특정 사업자 전용 서비스에 애플리케이션이 깊이 얽히면 오히려 이동성이 떨어집니다. 컨테이너·쿠버네티스·선언적 구성처럼 표준화된 계층 위에서 만들면 퍼블릭·프라이빗·온프레미스를 오갈 수 있습니다.

Q. 온프레미스에서도 클라우드 네이티브가 가능한가요?

가능합니다. CNCF 정의는 퍼블릭·프라이빗·하이브리드 클라우드를 모두 포함합니다. 자사 데이터센터에 쿠버네티스 기반 플랫폼을 구축하고 컨테이너·CI/CD·관측성을 갖추면 온프레미스에서도 클라우드 네이티브 방식으로 운영할 수 있습니다.

Q. refactor 는 어떤 시스템부터 시작해야 하나요?

변경이 잦고 트래픽 변동이 크며 장애 시 사업 영향이 큰 시스템이 우선순위입니다. 반대로 변화가 거의 없는 시스템은 rehost 나 유지가 나을 수 있습니다. 포트폴리오 전체를 한 기준으로 평가한 뒤 단계적으로 진행하시기 바랍니다.

Cloud Native Forum (cncf.co.kr)

• 클라우드 네이티브란? 개념·구성요소·도입 전략 가이드
• 왜 진짜 전문가들은 ‘클라우드’보다 ‘클라우드 네이티브’를 말하는가
• VM 에서 다른 VM 으로 전환은 중복 투자일 뿐, 좋아지는 것은 없다
• 가상화 vs 클라우드 네이티브 인프라 아키텍처 완전 분석(백서)
• 공공부문 클라우드 네이티브 전략 — 클라우드 네이티브 ≠ 퍼블릭 클라우드 전환
• 클라우드 네이티브란 무엇인가요?
• 쿠버네티스란 무엇인가 — 개념과 아키텍처
• 3.3 컨테이너 기반 배포와 쿠버네티스 — 클라우드 네이티브 시대로의 전환
• 제1부 클라우드 네이티브와 컨테이너 입문(eBook)
• 비싼 WAS의 시대는 끝났다 — 클라우드 네이티브 최적화 WAS로 전환할 때

MSAP.ai · OPENMARU

• 클라우드 네이티브 전환 진단 컨설팅
• 클라우드 네이티브 도입 효과와 공공·AI 인프라 사례(백서)
• 오픈소스 WAS 마이그레이션 도입 가이드

공식 문서·표준

• CNCF Cloud Native Definition v1.1
• CNCF 용어집 — 클라우드 네이티브 기술(한국어)
• CNCF 용어집 — 클라우드 컴퓨팅(한국어)
• Kubernetes 공식 문서 — 개요(한국어)
• AWS Prescriptive Guidance — 마이그레이션 전략(6R)
• The Twelve-Factor App(한국어)