클라우드 네이티브
더 많은 작업
클라우드 네이티브(Cloud Native)는 애플리케이션을 처음부터 클라우드 환경에서 돌아가도록 작고 느슨하게 결합된 단위로 나누고, 컨테이너와 자동화된 배포 파이프라인으로 자주·안전하게 바꾸며, 수요에 따라 자동으로 늘리고 줄이는 설계·운영 방식이다.
클라우드 네이티브 컴퓨팅 재단(CNCF)은 클라우드 네이티브를 퍼블릭·프라이빗·하이브리드 클라우드에서 워크로드를 규모 있게, 프로그래밍 가능하고 반복 가능한 방식으로 개발·빌드·배포하게 하는 실천으로 정의한다. 그 특징은 느슨하게 결합된 시스템이 안전하고 복원력 있으며 관리·관찰 가능하게 상호운용하는 것이고, 대표 기술로 컨테이너, 서비스 메시, 멀티테넌시, 마이크로서비스, 불변 인프라, 서버리스, 선언적 API를 든다. 강한 자동화와 결합하면 큰 변경도 자주, 예측 가능하게 할 수 있다고 본다.[1]
기존 시스템을 그대로 가상서버로 옮기는 리프트 앤 시프트는 클라우드에 올린(cloud-hosted) 것일 뿐이다. 클라우드 네이티브는 애플리케이션 구조부터 클라우드의 탄력성과 자동화를 쓰도록 다시 설계한다. 국내 공공부문 연구는 핵심 구성요소로 컨테이너, 마이크로서비스 아키텍처, 지속적 통합·제공(CI/CD), 데브옵스를 들고, 이를 받치는 개발 방식으로 애자일을 덧붙인다.[2]
| 구성요소 | 역할 |
|---|---|
| 컨테이너 | 애플리케이션과 종속성을 하나로 묶어 어느 환경에서나 같게 실행되게 한다. 플랫폼이 바뀌어도 옮기기 쉽다(이식성) |
| 마이크로서비스 아키텍처 | 기능을 작고 독립적인 서비스로 나누고 API로 통신한다. 서비스별로 따로 배포·확장하고, 한 서비스의 장애가 전체로 번지지 않게 격리한다 |
| CI/CD 파이프라인 | 코딩-빌드-테스트-배포를 자동화해 사람 개입을 줄이고 자주 배포한다(지속적 통합과 지속적 배포) |
| 데브옵스 | 개발과 운영이 한 팀처럼 일해 배포·운영을 빠르게 반복한다 |
| 오케스트레이션·자동 확장 | 쿠버네티스 같은 플랫폼이 컨테이너를 배치하고, 부하에 따라 늘리고 줄이며, 죽은 인스턴스를 다시 띄운다 |
| 관찰 가능성 | 로그·지표·추적으로 접속 지연이나 장애 원인을 빨리 찾는다 |
클라우드 네이티브로 만들 만한 시스템은 이용량 변동이 커서 탄력적 확장이 필요하거나, 접속 지연·서비스 장애를 빨리 해결해야 하거나, 기능 변경과 배포가 잦거나, 여러 클라우드·플랫폼으로 옮길 수 있어야 하는 시스템이다. 반대로 하나의 큰 애플리케이션이 대규모 단일 DB를 공유하는 구조는 모놀리틱 아키텍처의 특징이다. 이런 구조는 일부만 바꿔도 전체를 다시 배포해야 하고 일부 기능만 따로 확장할 수 없어서, 클라우드 네이티브의 지향점과 반대이다. 마이크로서비스는 서비스마다 자기 데이터를 갖는 것을 원칙으로 한다(서비스별 데이터베이스 패턴).
| 구분 | 클라우드 이전(리프트 앤 시프트) | 클라우드 네이티브 |
|---|---|---|
| 구조 | 기존 모놀리식 구조 유지 | 마이크로서비스로 분해 |
| 배포 | 수작업·대규모 일괄 배포 | CI/CD 파이프라인 자동 배포 |
| 확장 | 서버 증설 위주 | 서비스 단위 자동 확장 |
| 장애 대응 | 전체 영향 | 서비스 격리, 자동 복구 |
| 데이터 | 대규모 공유 DB | 서비스별 DB |
- ↑ 「CNCF Cloud Native Definition v1.1」, Cloud Native Computing Foundation, https://github.com/cncf/toc/blob/main/DEFINITION.md, 확인일: 2026-11-04.
- ↑ 이재혁·김상현, 「Cloud-Native의 확산: 정성적·정량적 연구기법을 이용한 공공부문의 클라우드 활성화 방안」, 『한국빅데이터학회지』 제8권 제2호(2023), https://doi.org/10.36498/kbigdt.2023.8.2.55, 확인일: 2026-11-04.