| 디지털 트랜스포메이션의 전환을 비즈니스 핵심 전략으로 삼고 경쟁력을 강화하기 위해, 이를 뒷받침 하는 핵심 기술인 소프트웨어에 대한 관심이 그 어느 때보다도 큰 시기이다. 사용자가 비즈니스에 참여하는 기회가 늘어나고, 이에 민첩하게 대응하기 위해서는 애플리케이션의 확장성과 가용성의 향상, 워크로드의 최적화, 개발부터 제품화에 이르는 애플리케이션 라이프사이클 자동화를 지원하는 클라우드 도입을 통해 실현 가능하다. 본 고에서는 이러한 이점을 극대화하기 위한 클라우드 네이티브(Cloud-Native)의 개념과, 핵심 기술을 소개하고, 여기에 Cloud Native로의 전환을 고려하는 기업을 위한 전략을 제시하고자 한다. |
I. 서론
기업이 디지털 트랜스포메이션을 통해 내·외부 환경 변화에 좀 더 민첩하게 대응하고, 사용자의 비즈니스 니즈를 상시 만족하며, 여기에 비즈니스 연속성과 신뢰성을 최대한 확보하기 위해서는 SW 응용프로그램이나 플랫폼을 구현하고 운영하기 위한 주요 IT 요소 즉, 개발방법론, 아키텍처, 조직과 프로세스, 인프라, 구현과 개발 언어 등에 있어 많은 변화가 필요하다.
이처럼 급변하는 비즈니스 환경에서 성공하기 위해, 기업들은 애플리케이션의 아키텍처, 구축 및 배포 방식, 여기에 개발 문화까지 새롭게 바꿔야 한다는 도전에 직면하게 되었고, 이러한 부분은 애플리케이션의 확장성과 가용성의 향상, 워크로드의 최적화, 개발부터 운영에 이르는 애플리케이션 라이프사이클 관리 자동화를 지원하는 클라우드 도입을 통해 실현 가능함을 인식하게 되었다. 이러한 클라우드의 이점을 극대화하기 위해서는 새로운 형태의 애플리케이션 개발 접근법이 필요하게 되었는데, ‘클라우드 네이티브(Cloud-Native)’ 개발이 바로 이에 해당되며, 애플리케이션을 신속하게 구축하고 업데이트하면서 비즈니스 민첩성을 확보하고, 품질을 지속적으로 개선하는 방식이다. 본 리포트에서는 클라우드 네이티브의 개념을 정의, 특징 중심으로 서술하고, 세부 핵심 기술, 클라우드 네이티브로의 전환을 고려하는 기업을 위한 전략을 제시하고자 한다.
II. 클라우드 네이티브의 정의와 특징
클라우드 네이티브는 클라우드 기술이 지닌 가치와 이점을 최대한 활용한 현대적 애플리케이션을 구축, 배포 및 관리하는 소프트웨어 접근 방식이라고 정의할 수 있다. 클라우드 네이티브 기술은 애플리케이션 개발 및 운영 조직이 퍼블릭, 프라이빗, 그리고 하이브리드 클라우드와 같은 현대적이고 동적인 환경에서 확장 가능한 애플리케이션을 개발하고 실행할 수 있게 해주는 것에 집중한다. 이러한 방식은 애플리케이션의 유연성, 관리 편의성, 가시성을 갖춘 느슨하게 결합된 시스템을 가능하게 한다. 여기에, 견고한 자동화 기능을 함께 사용하면, 엔지니어는 영향이 큰 변경을 최소한의 노력으로 자주, 예측 가능하게 수행할 수 있다. 2015년 처음 클라우드 네이티브라는 용어를 사용한 리눅스는 CNCF(Cloud Native Computing Foundation) 재단을 만들어 클라우드 네이티브로 전환할 수 있는 오픈소스 기술들을 추진하고 관리하기 위해 550개가 넘는 여러 클라우드 공급자와 기업들이 참여하고 있는데, CNCF에서는 클라우드 네이티브에 대해 아래와 같이 정의 하고 있다.
[표 1] CNCF에서 정의한 클라우드 네이티브의 정의
| 구분 | 정의 |
| 인프라 관점 | 퍼블릭, 프라이빗, 하이브리드 클라우드 환경에서 유연하고 확장성 있는 애플리케이션을 만들고 운영하기 위한 기술 |
| S/W 아키텍처 관점 | 컨테이너, 서비스 메시, 마이크로서비스, 불변의 인프라스트럭처, 그리고 선언적 API등을 이용한 접근 방식을통해 느슨하게 결합된 시스템 및 SW 아키텍처 구조를 지향하는 방법 |
| 개발 및 운영조직, 프로세스 관점 | 전통적인 모놀리틱 기반 개발/배포/운영 방식에서 탈피하고, DevOps에 기반한 개발/운영 조직 및 프로세스 내재화를 통해 SW의 Agility를 지향하는 방법론 또는 체계 |
| 서비스 운영 관점 | 클라우드 플랫폼이 제공하는 장애 회복성, 관리 편의성, 가시성, 견고한 자동화 기술을 활용하여 영향력이 크고 예측 가능한 변경을 상시 가능하게 하는 기술 또는 방법 |
클라우드 네이티브의 가장 큰 특징으로는, 애플리케이션이 구축, 배포, 관리되는 방식을 혁신하는 전용 기술, 도구, 개발 및 운영 프로세스와 더불어 새로운 수준의 소프트웨어 추상화를 수반하는 부분이라고 할 수 있는데, 클라우드 네이티브 애플리케이션의 주요 특징을 그림 1과 같이 나타낼 수 있다. 우리가 흔히 알고 있는 전통적인 개발 방식을 지향하는 모놀리식 애플리케이션(monolithic application)은 단독으로 배포 가능한 프로그램에 모든 기능을 포함하고, 간단하게 접근할 수 있는 용이함은 있으나, 단독으로 배포 가능한 프로그램에 모든 기능을 포함함으로써, 복잡성이 증대되고, 기능 간 강하게 결합된 아키텍처로 인해 하나의 기능 개선 반영 시, 전체 서비스에 영향을 미치는 등 유지 및 관리가 더욱 어려워질 수 있다. 이로 인해, 새로운 기능을 추가하거나 변경하려면 해당 기능을 검증하는 것 외에도 결합된 다른 기능까지 검증해야 하므로 시간이 많이 소요될 수 있어, 타임 투 마켓을 지향하는 비즈니스 민첩성 대응에 어려움을 겪을 수 있다. 여기에, 동일한 코드베이스(codebase)에서 작업하는 개발자가 많아질수록, 변경 사항의 충돌 가능성과 개발자 간의 대인 커뮤니케이션의 필요성이 증가되는 부분도 간과 할 수 없으며, 인프라 측면에서도 대체적으로 전통적인 Legacy 기반의 온 프레미스 구조 및 하드웨어에 의존하기 때문에, 운영 시스템의 노후화에 따른 신규 시스템으로 교체를 지속적으로 수행하거나, 운영체제 및 미들웨어의 재구성, H/W자원을 지속적으로 검토하고 증설해야 하므로 자본투자 역시 계속 증가할 수밖에 없다.
이에 비해 클라우드 네이티브를 지향하는 애플리케이션 환경은 클라우드 인프라와 IaC(Infra as a Code)기반으로 애플리케이션 구동 환경의 구성이 빠르게 이루어지므로, 애플리케이션을 더 빠르게 개발하고 배포하는데 필요한 리소스와 환경을 개발자에게 빠른 시간 내에 제공함으로써, 기존에 개발 환경 준비를 위해 필요한 인프라 구성으로 인한 대기시간을 획기적으로 줄일 수 있다.
SW 아키텍처 측면으로는 느슨한 연결 구조를 지향하는 마이크로 서비스 아키텍처 구성 및 컨테이너 기술을 도입, 활용함으로써, 조직은 애플리케이션 개발을 가속화하고, 운영 중단 없이 애플리케이션을 업그레이드하고, 효율적으로 애플리케이션을 확장하고, 언제든지 다양한 환경 간에 이식이 용이한 구조를 지향함으로써 비즈니스 민첩성과 경쟁 우위를 향상시킬 수 있다.
조직 측면에서는, 전통적인 개발 방법론에 근거하여, 개발과 운영이 분리된 구조에 의해 신속한 비즈니스의 변화에 대응하기 어려운 구조에서 탈피하여, 데브옵스(DevOps) 원칙에 기반한 개발, 품질 보증, 보안, IT운영팀 및 서비스 제공에 관련된 팀들이 협업을 통해 지속적인 배포와 통합(CI/CD)에 기반한 개발/운영 프로세스를 지향함으로써, 지속적으로 변화하는 비즈니스 요구에 민첩하게 대응 가능한 역량을 확보하고 대응할 수 있다.
운영 측면에서는, 필요시 자동화, 셀프서비스, 텔레메트리, 수평 및 수직 확장이 가능해 비즈니스를 효율적으로 운영할 수 있어 빠르게 변화하는 시장 조건에 신속하게 대응할 수 있다.
따라서, 상시 변화하는 비즈니스의 민첩한 대응력과 인프라 자원관리의 효율성, 유연한 워크로드 및 SW 아키텍처, 안정적인 운영 자동화를 지향하는 클라우드 네이티브의 핵심 기술 요소를 파악하고 관련 역량을 확보하는 것이 앱 현대화를 통한 비즈니스 민첩성 대응에 필수적인 요소라고 할 수 있다.
[그림 1] 클라우드 네이티브의 주요 특징
[표 2] 전통적인 애플리케이션과 클라우드 네이티브 애플리케이션의 비교
| 구분 | 전통적인 애플리케이션 | 클라우드 네이티브 애플리케이션 |
| 지향 | 서비스의 안정 | Time-To-Market, Agility, 민첩한 대응 |
| 개발 방법 | Waterfall | Agile |
| 조직 구성 | 개발팀, 운영팀, QA, 보안팀 등 분리 | DevOps 또는 DevSecOps |
| 서비스 제공 주기 | 장기 | 단기, 필요시마다 |
| 애플리케이션 구조 | 모놀리틱 | 마이크로 서비스 |
| 서비스 연계 구조 | 강 결합 | 서비스 간 독립성이 최대한 보장되는 느슨한 결합 |
| 인프라 제공 형태 | 온 프레미스 기반(물리서버 또는 가상화 서버) | 클라우드 기반(가상화 서버, 컨테이너 등) |
| 워크로드 유연성 확보 | 낮음 | 높음 |
| 확장성 | 수동 확장/제한적 | 자동 확장 |
| 코드 체계 | 일원화된 코드체계 | Polyglot |
| 서비스의 교체/수정 | 어려움(하나의 모듈 변경 시, 전체 영향) | 모듈 간 느슨한 연결/격리된 환경 제공으로 용이함 |
| 데이터베이스 | 단일화 된 통합 데이터베이스 활용 | 서비스 별 독립적인 데이터베이스 활용 |
| 코드 빌드/배포 | 수작업 의존 | CD/CI 도구 활용 |
| OS 의존성 | OS 종속성 높음 | 컨테이너 구조 지향으로 OS 종속성 제거 |
| 유지보수성 | 상대적으로 낮음 | 높음 |
| 기술 수용성 | 낮음(예 : Only Java) | 높음(예 : 컨테이너 기술을 통해 Java, Python분리 가능) |
| 적합한 서비스 | – 규모가 작은 서비스 – 비즈니스 성장 가능성이 낮고 복잡한 구조가 불필요한 서비스 | – 비즈니스 성장 속도가 빠른 서비스 – 대규모 비즈니스 도메인 내 기능 또는 서비스가 명확하게 구분 가능한 경우 – 가용성 및 유연한 확장이 상시 요구되는 서비스 |
III. 클라우드 네이티브의 핵심 기술
앞서 설명한 바와 같이, 다양한 클라우드 네이티브 기술은 조직이 퍼블릭, 프라이빗, 그리고 하이브리드 클라우드와 같은 현대적이고 동적인 환경에서 확장 가능한 애플리케이션을 개발하고 실행 할 수 있게 해준다. 컨테이너, 서비스 메쉬, 마이크로서비스, 서버리스(Serverless) 인프라, 그리고 선언형(Declarative) API 등이 이를 지원하는 핵심 기술로 볼 수 있는데, 여기서는 클라우드 네이티브를 설명할 때 주로 언급되고 있는 5가지 핵심 기술인 컨테이너, 마이크로서비스 아키텍처(MSA), DevOps, CI/CD, 서버리스 컴퓨팅을 상세하게 소개하고자 한다.
가. 컨테이너(Container) 기술
컨테이너는 애플리케이션의 실행에 필요한 라이브러리, 구성 파일 등을 패키지로 묶어서 마치 이미지와 같은 형태로 격리된 환경에서 구동할 수 있도록 배포하는 기술을 의미한다.
컨테이너는 내부에 별도의 OS가 없고 Host OS의 커널을 공유하는 별도의 프로세스 형태로 동작하기 때문에 경량성과 높은 이식성을 장점으로 갖고 있다. 기존의 가상 머신(VM)환경이 Host OS 또는 하이퍼바이저(Hypervisor)에 종속되는 것과 다르게 컨테이너는 Host OS의 환경 변수와 상관없이 애플리케이션을 구동할 수 있게 되는 것이다. 여기에 추가적인 장점 중 하나인 가볍고 사이즈가 작은 형태로 애플리케이션의 구동 환경의 배포가 가능한 부분은 애플리케이션의 복제와 배포 시간의 리드타임의 축소, 복잡성 감소를 지향하게 된다.
[그림 2] 클라우드 네이티브의 가상머신과 컨테이너의 구성
컨테이너 기반의 가상화 소프트웨어로 주로 Docker, LXC, Lunix vServer, FreeBSD Jail, Solaris Zones 등이 있는데, 그 중 최근 가상화 및 클라우드 컴퓨팅 영역에서 가장 널리 활용되고 있는 것이 바로 도커(Docker)이다. 도커는 리눅스의 응용프로그램들을 소프트웨어 컨테이너 안에 배치시키는 일을 자동화하는 오픈소스 프로젝트로 리눅스 컨테이너(LXC) 기술 기반으로 구현 되어 있으며, 데이터와 코드의 분산된 관리, 프로그램 스택의 간결 명료함, 손쉽고 빠른 워크로드의 배포 등 이식성, 유연성을 향상시킬 수 있다. 또한 컨테이너 이미지 생성 기능을 통해 특정 컨테이너에서 실행될 소프트웨어와 구동을 위해 컨테이너 실행에 필요한 파일, 설정값 등의 구동 사양을 미리 정의해 놓을 수 있어, 개발자는 애플리케이션의 이미지를 만들고, 구동 환경에 구애 받지 않은 채 원격으로 배포하여 실행하는 것이 가능하다.
여기에, 컨테이너 이미지 용량 관리를 효율적으로 하기 위해 레이어라는 개념을 사용하여, 이미지는 여러 개의 읽기 전용(Read only) 레이어로 구성하고, 파일이 추가되거나 수정되면 기존 레이어는 변하지 않고 그 위에 새로운 레이어가 생성되는 구조를 가짐으로써, 원본 이미지에 대한 중복을 없애고 수정된 값만을 관리하여 시스템이 경량화 될 수 있다. 즉, 파일이 수정될 때마다 매번 새로운 버전 전체를 설치할 필요 없이 추가된 새로운 레이어만 다운받으면 되는 형태로 구현이 가능하다.
[그림 3] 도커 아키텍처(출처 : Docker)
[그림 4] 도커 이미지의 Layer의 개념(출처 : Docker)
나. 마이크로서비스아키텍처 (Micro Service Architecture)
MSA(Micro Service Architecture)는 하나의 애플리케이션을 여러 서비스로 작게 나누고 서비스들끼리 통신하는 형태의 아키텍처로 구축하는 것을 의미한다. 기존의 모놀리틱 구조와 비교 시, 모놀리틱은 전체 애플리케이션이 하나의 통합 형태로 구성되어 있고 안의 구성 모듈들이 강결합 형태로 연결되어 있기 때문에, 한 부분을 수정할 시 전체 애플리케이션을 재배포해야 한다는 단점이 있다. 이는 하나의 서비스 모듈에 장애가 발생 시, 전체 서비스에 영향을 미친다는 의미와도 일맥상통한다.
반면, MSA 아키텍처는 서비스 별로 독립적인 개발, 배포, 확장이 가능하고, 느슨한 모듈간 결합구조를 지향함으로써, 하나의 서비스에서 발생한 장애가 전체시스템 장애로 연결되지 않으며 유지보수 또한 용이하다. 예를 들어 MSA 아키텍처에 기반한 온라인 쇼핑몰 시스템의 경우, 사용자 인증과 관련된 서비스 모듈을 독립적으로 구성함으로써, 다른 모듈에 영향 없이 빠르게 개선하여 배포가 가능하다. 다만 모놀리틱 구성과 비교하여 복잡하고, API와 메세지 드리븐(Message Driven) 형태를 지향하는 구조로 되어 있어 속도가 느리다는 단점 등은 보완해야 할 사항이다.
[그림 5] 모놀리틱 아키텍처와 마이크로 서비스 아키텍처 구조 비교
다. DevOps(데브옵스)
DevOps는 Development(개발)과 Operation(운영)의 합성어로, 애플리케이션과 서비스를 급변하는 비즈니스 요구에 맞춰 빠른 속도로 제공할 수 있도록 조직의 역량을 향상시키는 조직 문화이자 철학, 방식 및 도구의 조합으로 정의된다. 이전의 전통적인 개발 조직이 지향했던 폭포수형 개발(Waterfall) 방법론의 경우, 서비스의 안정, 개발 프로세스의 엄격한 통제 및 안정적인 운영에 초점이 맞추어져, 소프트웨어 개발팀과 IT 운영 팀은 분리될 수밖에 없는 구조로 인한 정보 silo의 심화, 협업의 어려움에 의해 민첩한 비즈니스의 요구의 대응이 어려웠다.
이러한 전통적인 개발 방법론의 한계를 인식하게 되자, 애플리케이션 개발 및 운영 조직은 이러한 경계를 허물고, 개발팀과 운영팀 사이의 협력과 커뮤니케이션을 강화해야 한다는 공감대가 생성되기 시작하였으며, 이에 DevOps라는 개발 및 운영 철학이 대두되었다.
[그림 6] DevOps의 개념도(출처 : Atlassian 홈페이지)
DevOps는 소프트웨어 개발부터 배포, 운영, 모니터링까지의 전체 생명주기를 관리하며, 개발과 운영 간의 협업을 강화하여 릴리즈 주기를 단축하고 문제를 신속히 해결할 수 있도록 지원한다. 이를 통해 조직은 고객에게 더 빠르고 안정적인 제품 및 서비스를 제공할 수 있게 된다.
DevOps의 핵심 가치로는 고객 만족과 지속적인 서비스의 개선을 통한 가치의 제공이라고 할 수 있으며, 개발과 운영의 조화로운 협업을 통해 비즈니스 성과를 추진하고 지속적인 프로세스 개선을 주도한다. 또한 DevOps는 자동화, 표준화, 모니터링 등의 원칙을 적용하여 개발과 운영의 효율성을 높이고 신속한 제품 개선을 가능하게 한다.
또한 DevOps는 애플리케이션 개발 팀(Dev)과 해당 IT 운영 팀(Ops) 팀 간의 원활하고 지속적인 커뮤니케이션, 협업, 통합, 가시성 및 투명성을 장려한다. 각 팀간의 경계는 과감하게 허물고, 커뮤니케이션과 협업을 강화하며, 이러한 활동들은 초기 소프트웨어 계획부터 코딩, 구축, 테스트 및 릴리즈 단계와 구축, 운영 및 지속적인 모니터링에 이르는 DevOps 라이프사이클의 모든 단계에 걸쳐 계속 이루어진다. 이는 추가 개선, 개발, 테스트 및 구축에 대한 지속적인 고객 피드백 루프를 추진하는 원동력이 된다.
DevOps의 방법론으로는 스크럼(Scrum), 칸반(Kanban), 애자일(Agile) 등이 있으며, 이러한 방법론은 개발과 운영의 협업과 효율성을 향상시키는 데 도움을 줄 수 있으며, 각 단계별 여러 툴체인(Toolchain)의 활용을 통해 자동화, 협업 및 개발-운영 팀 간의 지속적 통합을 위한 DevOps 프로세스를 손쉽게 준수할 수 있도록 도와준다.
[그림 6] DevOps의 Toolchain(출처 : https://kkhipp.tistory.com/m/188?category=794639)
라. CI/CD(Continuous Integration and Continuous Delivery)
CI/CD는 애플리케이션의 지속적 통합과 지속적 배포를 의미하며, 애플리케이션 개발 단계를 자동화하여 애플리케이션을 더욱 짧은 주기로 고객에게 제공하는 방법을 의미한다.
CI, 즉 지속적 통합작업은 개발자를 위한 자동화 프로세스로 개별 개발자가 작업한 코드가 자동으로 빌드 및 테스트 되도록 하는 체계 또는 그러한 시스템이라고 할 수 있다. 소프트웨어는 그 규모가 커질수록 여러 개발자에 의해 구성된 팀에 의해 개발되는 경우가 많으므로, 각자가 작업한 코드를 결과물로 통합하는 작업을 지속적으로 해주어야 한다. 이때 코드를 합치기 전에 문제가 없는지 정확하게 확인하지 않으면, 실제 서비스로 배포되고 나서 문제가 발생할 수 있는데, 소프트웨어의 규모가 커질수록 수시로 이러한 통합 작업을 해야 하는 ‘통합 지옥(Integration Hell)’의 굴레에 빠질 수밖에 없다. 더군다나 규모가 큰 소프트웨어라면 더욱 어려운 작업이 될 수밖에 없다.
이러한 문제를 해결하기 위해 테스트, 병합, 공통 저장소에 변경 사항. 체크인 작업 워크플로우를 자동화하면 팀이 더욱 신속히 깔끔한 코드를 제공할 수 있다. 또한, 소요시간이 긴 중대한 업데이트가 아닌 사소한 변경 사항을 단기간에 통합하도록 함으로써 개발 파이프라인의 효율성을 향상시킬 수 있다.
CD는 배포, 코딩 결과를 최종 사용자에게 넘겨주어 실행 가능하도록 하는 단계를 자동화하는 것을 말하며, 코드를 배포용 파일로 빌드 하고 그 결과물을 서버에 전송한 다음 커맨드로 실행까지 지원하는 프로세스이다. 이러한 통합 및 테스트 단계부터 배포까지의 애플리케이션의 라이프 사이클 전체에 걸쳐 지속적인 자동화 과정을 지원하는 대표적인 도구로는 젠킨스, AWS의 Code Pipeline 등이 있다
마. 서버리스 컴퓨팅(Serverless Computing)
서버리스 컴퓨팅은 사용량에 따라 백엔드 서비스를 제공하는 방법을 의미한다. 서버리스 아키텍처에 기반한 클라우드 서비스를 이용하여 개발하는 경우, 사용자는 기본 인프라를 걱정하지 않고 코드를 작성하고 배포할 수 있으며, 서비스 규모가 자동으로 결정되기 때문에 고정 대역폭이나 서버 개수를 유지하거나 그에 대한 비용을 고려할 필요가 없고 오직 개발에만 집중할 수 있는 환경을 제공한다.
서버리스 개념은 애플리케이션 관점에서 BaaS(Backend as a Service)와 FaaS(Function as a Service)로 나누어 볼 수 있는데, BaaS는 단일 웹페이지나 모바일 앱 기반의 서비스에서 필요한 서버 기능들을 사용하기 위해 이용하는 Third Party 애플리케이션이나 클라우드 서비스를 말하며, 애플리케이션 개발 시 요구되는 복잡한 백앤드(Back-End) 기능들을 사용자(개발자)가 직접 개발하지 않고 클라우드 공급자가 제공하는 서비스를 이용해 쉽고 안정적으로 구현하게 지원한다. 반면에 FaaS는 사용자가 쓸 기능을 함수 단위로 나누어 구현하고 이를 서비스하는 형태로써, Event-Driven 지향형 아키텍처를 구현하는데 적합하며, 사용자가 원하는 기능을 함수 형태로 미리 작성해놓고 특정 이벤트(HTTP Request, API 호출, 특정 조건 등)가 발생하는 경우에 한해 실행된다. 대표적인 서비스로는 AWS의 Lambda, 마이크로소프트의 Azure Functions, 구글의 Google Cloud Functions 등이 있다.
[그림 7] 대표적 FaaS 서비스인 AWS Lambda를 활용한 예시 (출처 : dataonair.or.kr)
IV. 클라우드 네이티브로의 전환 전략
이렇게 클라우드 네이티브로의 전환이 가져다 주는 많은 이점이 부각되고 있어, 다양한 기업 및 공공기관에서 클라우드 네이티브로의 전환을 고려하고 있다. 클라우드 네이티브로의 전환은 중장기적 안목을 가지고 수행해야 하는 과제이며, 중요한 사항은 이러한 도전 과정에서 따라오는 많은 변화에 대해 해당 조직이 얼마나 잘 준비하고 대응하는가에 달려 있다.
이런 측면에서 기업의 업무 혹은 애플리케이션의 대부분을 한꺼번에 클라우드 네이티브 형태로 전환하는 사례는 찾아보기 드물다. 대부분의 기업이라면, 아마도 리스크가 상대적으로 적은 사내 시스템부터 우선적으로 테스트 또는 파일럿 형태로 전환한 뒤, 관련된 노하우와 기술 역량의 축적을 거쳐 비즈니스의 핵심 업무로 확대하는 방식으로 접근하는 것이 일반적인 경우일 것이다. 이와 같은 접근방식은 안정성 측면에서 최적의 선택이 될 수는 있으나, 클라우드가 지향하는 본연의 효과, 즉 시스템 탄력성과 확장성 나아가 비즈니스의 변화 대응의 민첩성이라는 목적을 달성하기 위해서는 바람직하지 않은 선택이 될 수 있다. 따라서, 클라우드 네이티브로의 전환을 위해 아래와 같은 접근 방법을 통해 전략을 수립해야 한다.
가. 비즈니스 도메인 및 워크로드의 명확한 현황 분석
- 비즈니스 업무 도메인의 성격 및 워크 플로우
- 비즈니스 업무 서비스의 구성(물리적, 논리적 단위)
- 비즈니스 업무 서비스의 기능 단위(독립적 기능, 공동 기능 구분)
나. 비즈니스 워크로드가 수행되는 운영자원의 인벤토리 데이터 확보 및 속성 파악
- 클라우드 환경 적용에 적합성을 평가하기 위한 기술적인 장애요소나 난이도를 파악하기 위한 기초자료로 활용하기 위한 요소들의 파악
[표 4] 클라우드 네이티브 전환 대상 워크로드의 인벤토리 수집 대상
| 구분 | 대상 요소 |
| 애플리케이션 속성 | 개발 유형(자체/패키지), 구축년도, 고객정보 처리 유무, 프레임 워크, DBMS, 솔루션, 형상 변경 건수 등 |
| 인프라 속성 | OS 버전, 고가용성 구성 여부, 평균 자원 사용률, 미들웨어 종류, 인터페이스 건수 등 |
다. 클라우드 네이티브 전환 적합성 평가를 위한 기준 수립
- 워크로드별 클라우드 전환 필요성과 난이도 수준의 평가를 통해서 클라우드 네이티브로의 전환 적합성을 판단
[그림 8] 클라우드 적합성 평가 기준에 근거한 평가 결과 매트릭스 (출처 : 2e.co.kr)
V. 시사점
최근 비즈니스의 트랜드는 고객의 요구에 빠르게 대응하고 시장의 변화에 민첩하게 대응하는 것이다. 이에 따라 기존의 전통적인 S/W의 개발방법론 및 방식의 변화와 이를 지원하는 인프라 환경의 유연성도 함께 요구되고 있다. 이를 위해 클라우드 네이티브 지향 애플리케이션을 구현하고 관리하는 것이 그 좋은 대안이 될 수 있으며, 이를 위해서는 아래 2가지 사항은 필수적으로 고려해야 할 것이다.
첫째로, 비즈니스 도메인의 명확한 분석을 통해, 해당 비즈니스에 대한 변화와 민첩성의 요구 수준 분석을 위한 진단 항목 등을 설정, 진단한 뒤 클라우드 네이티브 지향의 타당성 여부를 확인해야 한다. 비즈니스를 지원하는 모든 업무시스템이 모두 클라우드네이티브를 반드시 지향할 필요는 없다. 예를 들어 비즈니스의 변화가 거의 없고, 제한적인 사용자, 기능 변화가 많이 요구되지 않는 업무 시스템일 경우 이러한 대응을 위해 굳이 클라우드 네이티브를 지향할 필요가 없다. 이를 위해서는 SW개발 영역의 전문가 외에 비즈니스 도메인에 대한 전문 지식을 가지고 명확한 요구사항과 비즈니스 방향 전략을 제시할 수 있는 조직과의 협업은 필수이다.
두번째로 DevOps 지향형 조직의 구성이다. 클라우드 네이티브의 경우 기존의 전통적인 SW개발 방법론이 아닌 DevOps를 지향하므로 조직의 개발 및 관리 체계도 이에 맞추어야 한다. 즉, 모두가 공감하며, 동의할 수 있고 DevOps를 활용하여 달성하고 싶은 공통 목표를 지향하는 전략을 공유해야 한다는 것을 반드시 인지하여야 한다. 프로세스 전략, 커뮤니케이션 및 협업 방법의 구체화, 지속적인 개발, 통합 및 테스트를 위한 방법론을 체계화 하는 것이 반드시 필요하다. 이를 위해 개발, 테스트 및 배포 전반에서 협업할 수 있는 공통 툴을 선택하는 것이 무엇보다도 중요하며, 이 툴을 잘못 선택 시, 오히려 팀 내부의 협업체계를 방해할 수 있기 때문에 신중해야 한다. 공통의 목표는 “개발-운영에 해당하는 모든 과정을 자동화”하는 것을 인지하고, 이러한 자동화 과정을 실시간으로 공유하고 확인하며, 이슈가 발생했을때는 빠르게 확인할 수 있는 체계를 갖출 수 있는 도구를 선택할 수 있도록 검토해야 한다. 여기에 체계적인 SRE(Site Reliability Engineering)를 통해 서비스의 안정성과 가용성을 유지하면서 변화를 최대한 수용할 수 있는 지표를 선정하고 추적, 관리 함으로써 지속적인 효율성을 지향한다면 클라우드 네이티브의 장점을 한결 더 극대화 할 수 있을 것이다.
[참고문헌]
[1] 클라우드로 혁신하라 (판카드 아로라, 현동식 옮김, 정보문화사)
[2] 클라우드 전환 기준 및 고려사항 – 투이 컨설팅 리포트
[3] 가비아 라이브러리 – 클라우드 네이티브 정의부터 사례까지
[2] Is Your Company Ready for Cloud, Pamela K, Isom, Pearson
[3] Cloud Adoption Methodology, IBM