| 전 세계는 서비스의 신속성, 안정성, 비용 효율성을 높이기 위해 자체 구축 시스템에서 클라우드 기반의 시스템으로 전환하고 있다. 국/내외 유수의 기업들은 클라우드 네이티브 방식을 채택하여 디지털 혁신을 추진 중이며, 정부도 이러한 추세에 발맞춰 클라우드 네이티브 적용을 핵심 과제로 설정했다. 관련 기관 및 부처에서는 2024년부터 신규 시스템 구축 시 클라우드 네이티브를 우선적으로 고려하도록 하고 있으며, 2026년부터는 클라우드 전환 물량의 상당 부분을 클라우드 네이티브 환경로 전환 할 계획이다. 클라우드 네이티브는 인프라뿐만 아니라 애플리케이션과 아키텍처를 클라우드 기반으로 전환하는 것을 의미하며, 컨테이너, 마이크로서비스, 데브옵스(DevOps), CI/CD 등의 다양한 기술 요소를 포함한다. 이러한 기술들을 기반으로 클라우드 환경에서 애플리케이션의 배포와 관리를 용이하게 하고, 다양한 환경에서의 상호 운용성과 이식성을 제공하여 장애로부터 독립적인 환경을 구성하는 기반이 된다. 이를 추진하기 위해서는 시스템의 확장성과 회복력을 향상시키는 기준인 클라우드 네이티브 아키텍처를 정의해야 하며 적용 시에는 단계적으로 접근해야 할 필요가 있다. 그랬을때, 클라우드 네이티브 기술의 도입은 단순히 도구를 도입하는 것 이상의 의미가 있으며, 각 조직의 상황에 맞춰 최적의 솔루션을 선택되고, 전체적인 개발 및 운영 방식의 변화를 수반할 수 있게 된다. |
Ⅰ. IT 기술 동향과 정부 정책의 변화
전 세계는 서비스의 신속성, 안정성, 비용 효율성 등을 제고하기 위해 시스템을 자체 구축 전략에서 클라우드(Cloud) 기반 구축으로 패러다임을 전환 중이며, 국내/외 유수의 기업들은 클라우드의 효과를 극대화 할 수 있도록 클라우드 네이티브 방식을 기반으로 디지털 혁신을 추진 중이다.
정부도 이러한 추세에 빠르게 대응하기 위해 2023년 4월 디지털플랫폼정부 실현계획을 통해 ‘클라우드 네이티브(Cloud Native) 적용’을 디지털 플랫폼 정부의 핵심 과제로 발표한 바 있다.
[그림 1] 연도별 운영 및 신규 시스템 구축 전략 변화
그 결과로 관련 기관 및 부처에서는 2024년부터 신규 시스템을 구축하거나 기존 시스템을 고도화할 때, 불가피한 사유가 없는 한 민간 클라우드와 클라우드 네이티브 우선 적용을 검토해야 하며, 2026년부터는 신규 클라우드 전환물량의 70% 이상(기존시스템은 50% 이상)을 클라우드 네이티브 방식으로 전환할 예정이다.
[표 1] 클라우드 네이티브/SaaS 전환률(계획)
| 구분 | 2024년 | 2025년 | 2026년 이후 | |
| 현행 시스템 | 클라우드 네이티브 적용률 | 11% | 30% | 50% |
| SaaS 적용률 | 10% | 25% | 35% | |
| 신규시스템 | 클라우드 네이티브 적용률 | 13% | 30% | 70% |
| SaaS 적용률 | 10% | 30% | 40% | |
현재는 하나의 대형시스템을 구축하는 방식이지만 앞으로는 디지털 플랫폼 정부 혁신인프라 위에서 작은 서비스의 묶음으로 시스템을 구축하는 클라우드 네이티브 방식을 적용하여, 그동안 반복적으로 발생했던 대형 정부시스템의 접속장애가 대폭 개선될 전망이다.
본 고에서는 이러한 클라우드 네이티브를 기반으로 개발된 애플리케이션들을 배포하기 위한 컨테이너(Container), 마이크로서비스(Microservice)와 같은 공통 기술 요소들과 클라우드 네이티브 기술의 대표적인 특징인 데브옵스(DevOps), CI/CD(지속 통합/배포), 마이크로서비스 아키텍처(Micro Service Architecture, MSA) 등에 대하여 설명한다.
Ⅱ. 클라우드 네이티브의 이해
가. 클라우드 네이티브의 정의
클라우드 네이티브는 인프라뿐만 아니라 애플리케이션, 아키텍처까지 모든 것을 클라우드 기반으로 전환하는 것으로 공공 클라우드 전환과 어플리케이션 현대화의 새로운 지향점이다.
여러 기관 및 기업에서는 다양한 관점으로 클라우드 네이티브를 정의하는데,‘클라우드 환경의 장점을 극대화 한 어플리케이션 개발 방법론’ 이라는 맥락은 같이 하고 있다.
[표 2] 클라우드 네이티브의 정의
| 구분 | 내용 |
|---|---|
| 한국정보통신기술협회(TTA) | – 클라우드 컴퓨팅을 활용하여 “퍼블릭, 프라이빗 및 하이브리드 클라우드와 같은 현대적이고 동적인 환경에서 확장 가능한 애플리케이션 을 구축하고 실행” 하는 소프트웨어 개발 방식 |
| 아마존 웹 서비스(AWS) | – 클라우드 컴퓨팅 환경에서 애플리케이션을 구축, 배포 및 관리하는 소프트웨어 접근 방식 |
| IBM | – 마이크로서비스라고 불리는 개별적이고 재사용 가능한 구성 요소로 구성되며, 이는 어떤 클라우드 환경에도 통합될 수 있도록 설계 및 구현하는 방식 |
| 클라우드 네이티브 컴퓨팅 재단(CNCF) | – 조직이 공공, 사적 및 하이브리드 클라우드에서 확장 가능한 애플리케이션을 구축하고 실행할 수 있도록 지원하는 기술 집합 – 컨테이너화 가능한 오픈소스 소프트웨어 스택을 사용하는 것 |
나. 클라우드 상호운영성과 이식성 구현을 위한 주요 기술요소
클라우드 네이티브 기반으로 시스템을 구성함으로써 서로 다른 인프라에서도 서비스를 쉽게 배포하여 운영할 수 있고(상호 운용성, Interoperability) 필요에 따라 인프라 간 이동이 가능한 애플리케이션을 개발(이식성, Portability)할 수 있게 되며, 이에 대한 장점은 다음과 같다.
◾첫 번째, 클라우드 서비스 제공자에게는 클라우드 서비스 간 상호운용성 표준 기술 도입을 통해 개발 비용, 시간 등의 자원 절감을 통해 기업 경쟁력을 높이고, 글로벌 표준을 준용함으로써 해외 진출을 통한 수출 경쟁력 또한 제고할 수 있다.
◾두 번째, 클라우드 서비스 이용자에게는 시스템다운, 데이터 소실 등의 상황에 대비할 수 있게 해주어 이용자를 보호하고, 애플리케이션 및 데이터의 쉽고 효율적인 이동을 통해 이용자 편익을 제고할 수 있다.
[표 3] 클라우드 네이티브의 기술요소
| 구분 | 내용 |
|---|---|
| 컨테이너(Container) | – 기존 클라우드 환경에서 많이 활용되는 가상 머신(Virtual Machine, VM)처럼 애플리케이션과 관련된 라이브러리나 종속되는 항목들을 패키지로 묶어 서비스 구동을 위한 가상 환경 – 가장 많이 활용 되는 오픈소스인 도커(Docker)는 컨테이너 정보를 Dockerfile로 관리하고 이 코드를 기반으로 컨테이너 이미지의 복제 및 애플리케이션 배포가 이루어지기 때문에 애플리케이션을 쉽게 다시 빌드 및 배포 가능 |
| 마이크로 서비스 아키텍처 (MSA, Micro Service Architecture) | – 엔터프라이즈 시스템을 중심으로 고안된 SOA(Service Oriented Architecture) 사상에 근간을 두고, 대용량 웹서비스 개발에 맞는 구조로 사상이 경량화되고 대규모 개발팀의 조직 구조에 맞도록 변형된 아키텍처 – 경량화되고 독립적인 여러 개의 서비스를 조합하여 애플리케이션을 구현하는 방식으로 서비스마다 자체 데이터베이스를 가지고 동작할 수 있기 때문에 개발부터 빌드 배포까지 효율적으로 수행할 수 있으며, 독립적인 서비스의 형태로 존재하기 때문에 이식성 측면에서 높은 효과를 보임 • 분리된 프로세스: 개별 마이크로서비스는 별도의 프로세스에 의해 실행되어, 서비스간의 의존성을 작게 할 수 있음 • API 통신: 마이크로서비스 구축을 위해 서로 다른 프로그래밍 언어를 이용하여 개발될 수 있으며, 각 마이크로서비스 간의 통신은 API를 통해 이뤄 짐 • 독립적인 배포: 각 서비스마다 별도의 개발 및 유지 관리 계획을 세울 수 있으며, 서비스의 규모를 작게 하여 프로그램의 복잡성을 줄여 개발 유지 보수에 필요한 비용을 절감할 수 있음 |
| Agile한 개발 방식 | – 사용자의 요구사항을 이해, 신속하게 반영하기 위해 기획,설계과정에 많은 시간과 노력을 기울이지 않고 빠르게 프로토타입을 개발하여 사용자의 피드백과 방향성을 확인하고 지속적인 개선 과정을 짧은 주기로 반복하는 개발방법론 • 과도한 기획 지양 • 핵심 기능에 집중 빠른 출시 목표 • 고객가치가 높은 기능 우선순위로 반복적인 개선 |
| CI/CD | – 애플리케이션 개발 단계를 자동화하여 애플리케이션 변경 사항을 보다 짧은 주기로 적용하기 위해 사용하는 방법 • 지속적인 통합(Continuous Integration, CI) : 개발한 소스코드를 반복적으로 통합하고 빌드를 자동화 하는 것 • 지속적인 서비스 제공(Continuous Delivery, CD) : 개발자들이 애플리케이션에 적용한 변경 사항이 버그 테스트를 거쳐 레포지토리(예: GitHub 또는 컨테이너 레지스트리)에 자동으로 업로드 되는 것 • 지속적인 배포(Continuous Deployment, CD) : 개발자의 변경 사항을 레포지토리에서 고객이 사용 가능한 프로덕션 환경까지 자동으로 릴리스 하는 것 |
| 데브옵스(Devops) | – 개발(Development)과 운영(Operations)을 결합한 용어로, 소프트웨어 개발부터 배포, 운영, 모니터링까지의 전체 생명주기를 통합하여 더 빠르고 안정적으로 고품질의 제품 및 서비스를 제공하는 문화, 방식 – CI/CD 환경을 통합하여 개발 환경 뿐 아니라 운영환경 까지 어플리케이션의 변경사항 배포하는 환경을 자동화 함 |
| 쿠버네티스 (Kubernetes, K8S) | – 클라우드 환경의 컨테이너 기반 인프라를 추상화하여 하위에 어떤 클라우드가 있는지 종류에 상관없이 쿠버네티스 상에 애플리케이션을 배포하고 관리가 가능한 오픈소스 소프트웨어 – 도커 등의 컨테이너 런타임을 통해 컨테이너를 다루는 도구이며, 여러 서버(노드)에 컨테이너를 분산해서 배치하거나, 문제가 생긴 컨테이너를 교체하거나, 컨테이너가 사용할 비밀번호나 환경 설정을 관리 함 |
이러한 장점을 가능하게 하는 것은 컨테이너, 마이크로 서비스 아키텍처 등의 기술요소를 기반으로 클라우드 네이티브 환경을 구성하기 때문이다.
프라이빗, 퍼블릭 및 하이브리드 클라우드 환경 전체에 지속적인 개발과 자동화된 관리 환경이 필요하며, 리소스의 셀프 서비스 및 온디맨드 프로비저닝은 물론 개발환경 부터 운영환경에 이르는 애플리케이션 라이프사이클을 자동화하여 서비스를 관리 할 수 있게 한다.
Ⅲ. 클라우드 네이티브 어플리케이션과 클라우드 네이티브 아키텍처
클라우드 네이티브 애플리케이션은 기존 및 새로운 소프트웨어 개발 패턴의 조합이라 고 볼 수 있다.
기존 패턴을 소프트웨어 자동화(인프라 및 시스템), API 통합 및 서비스 지향의 아키텍처라고 한다면, 클라우드 네이티브 패턴은 마이크로 서비스 아키텍처, 컨테이너화 된 서비스, 분산 관리 및 오케스트레이션으로 요약할 수 있다.
가. 클라우드 네이티브 어플리케이션
일반적으로 하나의 클라우드 네이티브 애플리케이션은 컨테이너 기반의 다수의 마이크로서비스로 구성되며, 이 서비스들은 고유한 프로그래밍 언어, 데이터베이스 및 별도의 스토리지를 가질 수 있다.
이러한 특징을 기반으로 개발된 애플리케이션을 클라우드 네이티브 애플리케이션(Cloud Native Application)이라 하며, 특징과 구축 시 고려사항은 다음과 같다.
[표 4] 클라우드 네이티브 어플리케이션의 특징과 고려사항
| 구분 | 내용 |
|---|---|
| 클라우드 네이티브 어플리케이션의 특징 | ◾ 서비스 및 API 기반의 개발을 보다 민첩하게 처리 ◾ 구현된 결과물을 지속적이고 자동으로 배포할 수 있는 시스템 구축 ◾ 개발 및 운영팀과의 효율적인 커뮤니케이션 ◾ 보다 발전된 모듈식 아키텍처의 구성 ◾ 사용자의 요구에 따른 수평적 확장 가능 ◾ ‘개발 → 테스트 → 프로덕션’과 같은 여러 형태의 운영 및 테스트 환경 지원 ◾ 모든 인프라에서 DevOps의 협업 시스템을 통해 애플리케이션 이식성 제공 |
| 클라우드 네이티브 어플리케이션 구축 시 고려사항 | ◾ 애플리케이션 설계: 구축하려는 서비스들의 사용자 요구사항에 대한 경계와 마이크로 서비스로의 전환 설계 ◾ API 설계: 표준화된 방법을 통한 내부 및 외부 리소스에 대한 액세스 방식에 대한 설계 ◾ 운영 관리: 애플리케이션 관리를 위한 로그 및 모니터링 정보에 대한 관리 ◾ DevOps :개발에서부터 운영까지의 애플리케이션 라이프 사이클에 대한 자동화 빌드와 배포 ◾ 테스트: 품질 보증을 위한 테스트 |
마이크로서비스 아키텍처를 이용하여 애플리케이션을 구축할 경우에 고려해야 할 가장 중요한 점은 사용자의 요구사항에 따른 기능을 어떻게 분할하고 어떤 마이크로서비스 에 할당하느냐에 대한 것이다.
사용자의 요구사항에 따른 각 기능을 너무 세밀하게 분할하면 시스템의 오버헤드가 커지고, 반대로 마이크로 서비스를 너무 크게 분할하면 마이크로서비스의 장점을 충분히 사용할 수 없게 되며, 각 서비스에 대해 감시/모니터링 해야 할 대상이 늘어남에 따라 애플리케이션 운영에 대한 복잡성이 늘어나게 된다. 따라서 초기 단계부터 리소스와 개발 및 관리능력 등을 고려한 설계가 중요하다.
나. 클라우드 네이티브 아키텍처 개요
클라우드 네이티브 기술을 이용하여 구현되는 애플리케이션 및 서비스를 위한 설계나 계획을 클라우드 네이티브 아키텍처라 하며, 클라우드 네이티브 기술들을 이용해 서비스 하고자 하는 애플리케이션에 대해 적은 리소스의 사용, 회복성, 관리능력 및 느슨하게 연결된 모듈 등의 효과를 제공할 수 있을 뿐만 아니라, 자동화된 인프라의 구성으로 시스템의 변경 및 개선 사항을 최소한의 노력으로 배포할 수 있게 한다.
[그림 1] 클라우드 네이티브 아키텍쳐
클라우드 네이티브 아키텍처를 구성하는 각각의 기술 스택들은 애플리케이션을 보다 빠르게 개발하고, 관리하기 쉽도록 모니터링 기술을 지원하며, 클라우드 상에 배포되는 시간을 단축하여, 더 자주 배포하는 것을 목표로 한다.
[표 5] 클라우드 네이티브 참조 아키텍쳐 설명
| 구분 | 내용 |
|---|---|
| Application Definition/Development) | – 구축과정에서 백엔드(Backend) 서비스를 기반으로 지원되는 다양한 서비스들 – 컨테이너 네이티브 애플리케이션을 구현하는데 필요한 메타데이터, 설정, 도구, 컨테이너 이미지 관리 도구 등 |
| Orchestration & Management | – 컨테이너 배포, 로깅, 모니터링 뿐만 아니라, Service Discovery 등의 작업을 처리 – 컨테이너 오케스트레이션(Kubernetes, Docker Swarm 등) 도구를 활용한 컨테이너 배포, Logging & Monitoring, Service Discovery 등 |
| Runtime | – 컨테이너 실행 표준과 컨테이너 네트워킹, 그리고 볼륨에 의한 컨테이너 데이터 저장을 위한 스토리지에 대한 부분 – 컨테이너 실행 표준(OCI), 컨테이너 네트워킹(Container Networking Interface Project), Storage(Volume Driver) 등 |
| Provisioning | – IT 인프라를 설정하는 프로세스로서 사용자의 요구에 맞게 시스템 자원 할당, 배치, 배포하는 등의 리소스에 대한 액세스 관리와, 서비스 실행부터 배포에 이르는 전 단계에 걸쳐 처리하는 일련의 프로세스 – 컨테이너 환경을 고려한 DevOps의 배포 도구와 프로비저닝 등 |
| Observability and Analysis | – 모니터링, 로깅 및 추적을 위한 솔루션 – CNCF 프로젝트에서 Prometheus(모니터링), Fluentd(로깅) 및 Jaeger(추적) 제공 – ELK(Elastic Search, Logstash, Kibana) 기반의 로그 수집 활용 |
| Infrastructure | – Bare Metal, Public Cloud 환경에서의 호환성을 유지 |
위 표에서 설명한 클라우드 네이티브 참조 아키텍처에서는 제일 먼저 비즈니스 도메인에 맞는 실행 환경과 애플리케이션을 설계 및 개발한 다음, 컨테이너 가상화 기술에 의해 배포하고 관리 도구를 사용해 애플리케이션의 상태와 개선 사항을 주기적으로 확인하도록 한다.
CNCF에서는 클라우드 네이티브 아키텍처가 다음과 같은 속성을 갖도록 구성되어야 한다고 정의 하였다.
◾ 애플리케이션 또는 프로세스는 컨테이너 가상화 기술에 의해 분리된 단위로 실행
◾ 애플리케이션을 구성하는 프로세스는 리소스 사용을 개선하고 유지보수 비용을 줄이기 위해 중앙 오케스트레이션 프로세스에 의해 동적으로 관리
◾ 애플리케이션 또는 서비스(마이크로서비스)는 명시적으로 기술된 종속적인 각 항목들과 느슨하게 결합
Ⅳ. 단계별 클라우드 네이티브 전환 전략
클라우드 네이티브 전환을 위해서는 컨테이너 플랫폼 기반의 클라우드 환경을 실제 운영이 가능한 Pilot 형태로 구축하여 검증하고, 이를 통해 내부 기술 검증 (운영 /개발 교육 및 기술 워크샾, 전문 기업의 Application 최적화 및 전환 가이드 등) 과정을 거쳐서 단계적으로 추진해야 한다.
[그림 1] 단계별 글라우드 네이티브 전환 전략
클라우드 네이티브 애플리케이션 구현을 위한 과정은 기업이나 조직에 따라 다르며, 애자일 개발 방식이나 IT 자동화를 지원하는 툴을 도입한다고 해서 클라우드 네이티브화 되고, 서비스 접근 방식의 속도가 빨라지는 것이 아니다. 따라서 필요한 클라우드 네이티브의 기술과 특징을 살펴보고, 기업에 맞는 최선의 선택을 해야 한다.
[참고 문헌]
[1] 행안부, “클라우드 네이티브 중심, 공공 부문 정보자원 클라우드 전환 계획’, 2023
[2] Redhat, 클라우드 네이티브 기반 Open Hybrid Cloud 전환 전략, 2023
[3] TTA, 클라우드 네이티브 애플리케이션 개발 가이드라인, 2023
[4] NIA, 클라우드네이티브 추진 시 고려사항, 2021
[5] 아마존 웹 사이트(https://aws.amazon.com)
[6] Cloud Native Computing Foundation(https://www.cncf.io/)