비즈니스 애질리티(Agility) 실현을 위한 애플리케이션 현대화(Application Modernization)

최근 클라우드의 발전과 더불어 많은 기업들이 오래전부터 운영해오던 기존 시스템을 클라우드 환경으로 전환하는 노력들을 시도하고 있습니다. 컨테이너(Container) 기술의 발전은 애플리케이션을 새롭게 만들고 배포하는 일련의 절차를 과거보다 빠르게, 비전공인들도 쉽게 참여할 수 있게 하였습니다. 최근 활발히 진행되고 있는 컨테이너 기술을 활용한 애플리케이션 현대화 (Application Modernization) 사례에 대해 살펴보겠습니다.

클라우드 기술 백서 관련하여 궁금하신 사항은 이곳으로 문의주세요.

클라우드 전환에 필수적인 컨테이너 기술의 발전

최근 클라우드의 발전과 더불어 많은 기업들이 오래전부터 운영해오던 기존 시스템을 클라우드 환경으로 전환하는 노력들을 시도하고 있습니다. 일상을 되돌아보면 변화와 새로움이 늘 좋은 것은 아니었습니다. 하지만 새로운 변화에 적응하고 맞춰야 새로운 일상을 받아들일 수 있고 그렇게 조금씩 나아가야 앞으로의 변화에 잘 대응할 수 있을 것 같습니다. 컨테이너(Container) 기술의 발전은 애플리케이션을 새롭게 만들고 배포하는 일련의 절차를 과거보다 빠르게, 비전공인들도 쉽게 참여할 수 있게 하였습니다. 최근 활발히 진행되고 있는 컨테이너 기술을 활용한 애플리케이션 현대화(Application Modernization) 사례에 대해 살펴보겠습니다.

[여기서 잠깐!] 컨테이너(Container) 기술이란?

컨테이너 기술은 소프트웨어를 실행하는 데 사용되는 가상화 기술 중 하나입니다. 컨테이너는 하나 이상의 프로세스를 격리된 환경에서 실행할 수 있도록 하는 가벼운 가상화 단위입니다.

Cloud Native Computing Foundation (CNCF)

출처: http://www.opennaru.com/kubernetes/cloud-native-computing-foundation-cncf/

애플리케이션 현대화(Application Modernization)의 개념

최근 애플리케이션 현대화와 관련된 사업들이 활발히 진행되고 있습니다. 애플리케이션 현대화의 정의는 단순히 애플리케이션 구조 설계에 대한 현대화만을 의미하지 않습니다. 애플리케이션은 기업의 비즈니스를 담게 되는데, 이러한 비즈니스는 조직의 의사 결정 구조와 관련이 있습니다. 조직의 의사 결정 구조는 시스템의 모습을 결정하기 때문입니다.

"Any organization that designs a system will inevitably produce a design whose structure is a copy of the organization's communication structure" - 1967년 맬빈 콘웨이(Melvin Conway) 논문

[여기서 잠깐!] 애플리케이션 현대화(Application Modernization)이란?

애플리케이션 현대화는 기존의 레거시 시스템을 최신 기술과 아키텍처로 업데이트하거나, 새로운 애플리케이션을 현대적인 방식으로 개발하여 기존 비즈니스 프로세스를 최적화하는 것입니다.

애플리케이션 현대화는 기업이 변화하는 비즈니스 요구사항에 대응할 수 있도록 도와줍니다. 이를 위해 애플리케이션 현대화는 다음과 같은 접근 방식을 사용합니다.

1. 클라우드 네이티브 방식: 클라우드에서 실행할 수 있는 애플리케이션을 개발하는 방식으로, 클라우드의 유연성과 확장성을 활용할 수 있습니다.
2. DevOps 방식: 개발과 운영을 통합한 방식으로, 개발자와 운영팀이 함께 일하면서 애플리케이션을 지속적으로 개선하고 배포합니다.
3. 마이크로서비스 아키텍처: 애플리케이션을 작은 단위로 분할하여 개발하고 배포하는 방식으로, 유연하고 확장성이 높은 애플리케이션을 만들 수 있습니다.
4. 컨테이너 기술: 애플리케이션을 패키징하고 실행하는 기술로, 애플리케이션의 이식성과 확장성을 향상시킵니다.

이러한 접근 방식을 활용하여 애플리케이션을 현대화하면, 기업은 더욱 빠르고 유연하게 비즈니스 요구사항에 대응할 수 있으며, 높은 품질의 애플리케이션을 제공할 수 있습니다.

컨테이너 기술의 발전에 따른 애플리케이션 생성 및 배포 방식의 진화

애플리케이션의 구조에도 많은 변화가 생겼습니다. 컨테이너 기술의 발전은 애플리케이션을 만들고 배포하는 방식에 있어 많은 진화를 가져왔습니다. 독립적으로 동작하는 개별 애플리케이션만 잘 만든다면 확장하는 것은 그리 큰 문제는 되지 않을 것입니다. 국내외 많은 기업들은 이미 컨테이너 기술이 적용된 환경으로 변화해 왔습니다. 클라우드 네이티브(Cloud Native)한 인프라 환경으로 전환되었다는 뜻이며 AWS 같은 클라우드 플랫폼 위에 비즈니스 애플리케이션을 올려 서비스를 하고 있다는 것입니다.

[여기서 잠깐!] 클라우드 네이티브(Cloud Native)란?

클라우드 네이티브는 모든 시스템 및 애플리케이션의 설치와 구성이 클라우드 환경 기반으로 구성되는 것을 의미합니다.

클라우드 네이티브 애플리케이션을 구축하기 위해서는 다음과 같은 특징을 갖추어야 합니다.

- 컨테이너화(Containerization): 애플리케이션을 컨테이너로 패키징하여, 배포 및 관리를 용이하게 합니다.
- 마이크로서비스 아키텍처(Microservices Architecture): 애플리케이션을 작은 단위의 서비스로 분할하고, 각각의 서비스를 독립적으로 개발 및 배포합니다.
- 자동화(Automation): CI/CD, Provisioning, Configuration 등의 과정을 자동화하여 개발 및 운영 프로세스를 효율화합니다.
- 탄력성(Scalability): 클라우드의 확장성을 활용하여, 애플리케이션을 빠르게 확장하거나 축소할 수 있습니다.
- 서비스 메시(Service Mesh): 마이크로서비스 아키텍처에서 서비스 간 통신을 관리하는 기술입니다.

클라우드 네이티브 애플리케이션은 클라우드의 특성을 최대한 활용하여 개발되므로, 기존의 온프레미스 환경에서 구축된 애플리케이션보다 더욱 유연하고 확장성이 높은 애플리케이션을 구축할 수 있습니다. 이를 통해 개발자와 운영팀은 더욱 빠르게 애플리케이션을 개발하고 배포할 수 있으며, 기업은 더욱 높은 효율성과 경쟁력을 얻을 수 있습니다.

비즈니스 애플리케이션의 문제점

다만, 비즈니스 환경과 직결되는 애플리케이션이 클라우드 네이티브 한 구조로의 전환(소스코드 리팩토링(Refactoring))이 되지 못한, 여전히 전통적인, 모놀리스(Monolith) 구조를 가지고 있다는 것입니다. 따라서, 'Business Agility' 달성을 위한 클라우드 네이티브 시스템으로의 전환을 위해서는 반드시 애플리케이션 현대화가 수반되어야 합니다. 그럼 애플리케이션 현대화 전환을 위한 접근은 어떻게 해야 하는지 사례와 기술 측면에서 접근 전략을 공유하고자 합니다.

A항공사 애플리케이션 현대화(Application Modernization) 사례 분석

비즈니스 시스템의 유연함이 여객기에서 화물기로 성공적 전환을 가능하게 해

삼성SDS는 2021년 말부터 A항공사에 대한 애플리케이션 현대화를 위한 분석을 수행했습니다. 그 가운데 여러 사업적인 이해관계를 배제하고 기술적인 내용에 대해서 고민했던 내용을 공유하고자 합니다. A항공사는 코로나 기간 동안 유일하게 전 세계 항공사 중 흑자를 기록한 기업입니다. 그 중심에는 '물류수송' 여객기의 화물기 용도 전환이라는 아주 단순한 전략이 있었습니다. 그것을 가능하게 했던 것은 항공 관련 시스템 중 탑재 관리 시스템의 유연함이 빛을 발한 것 같습니다. A항공사 시스템은 150여 개 이상의 시스템이 연관되어 동작하고 그것은 국내외 여러 기관 및 기업들과 거미줄처럼 촘촘하게 연결되어 작동되고 있었습니다. 여객기에서 화물기로 빠르게 전환할 수 있었던 것은 비즈니스를 뒷받침하는 시스템이 있었기 때문입니다. 독자적으로 개발한 시스템이 빛을 발한 것이었습니다.

여전히 풀어야 할 복합적인 문제들

하지만 코로나 시기의 생존과 더불어 그 이후 달라진 세상에서 치열하게 경쟁해야 하는 항공업계는 여전히 풀어야 할 많은 숙제를 안고 있습니다. 조직에 뿌리 박혀 있는 문화를 바꾸고 노후화된 시스템의 개선작업, 더 나아가 시스템을 개발/운영하는 직원들의 기술 역량까지 향상시켜야 하는 다양한 문제들이 산재해 있습니다. 이러한 복합적인 문제 유형들은 다음 3가지 정도로 정리할 수 있습니다.

- 조직문화(비즈니스와 IT 조직 간 협력관계) 개선
- 노후화된 시스템 구조의 현대화
- 직원들의 디지털 역량 향상

이번 글에서는 '노후화된 시스템 구조의 현대화'라는 관점에서 내용을 설명하고자 합니다.

애플리케이션 현대화(Application Modernization) 전환 전략

리호스트(Re-host), 리플랫폼(Re-platform), 리팩터(Re-factor) 전략 정의

먼저 시스템의 현대화 범위를 한정 지어야 할 것입니다. 접근 방법으로는 ‘Re-host’, ‘Re-platform’, ‘Re-factor’ 전략을 고려할 수 있습니다. 앞서 언급했던 것처럼 이미 많은 기업들이 ‘Re-platform’ 전환을 하였습니다. 기존에 운영 중인 애플리케이션의 변화 없이 단순히 클라우드 환경으로 이전하는 것을 ‘Re-host’라고 합니다. 그리고 애플리케이션을 변경하지는 않으나 클라우드 인프라 위에 ‘컨테이너’로 애플리케이션을 전환해서 배포하는 전략을 ‘Re-platform’이라고 합니다. 마지막으로 애플리케이션을 재구조화하고 개선하는 작업을 한 후 ‘Re-platform’하는 전략을 ‘Re-factor’라고 합니다.
다음으로 애플리케이션 현대화 전환에 대한 구체적인 애플리케이션 현대화 수행전략이 필요합니다. 구체적인 애플리케이션 현대화 수행 전략은 3단계로 생각해 볼 수 있습니다.

애플리케이션 현대화(Application Modernization) 수행전략 3단계

1단계: 사전 위험 요인 파악 및 전략 수립

먼저 전환 대상 시스템들이 여러 개일 경우 이를 진단하여 우선 순위화를 합니다. 00여 개의 시스템 중 어떤 시스템을 먼저 애플리케이션 현대화를 수행할지, 어느 정도의 노력(인건비와 재료비)이 필요한지를 분석하여 사전에 위험 요인을 파악하고 이에 적합한 전략을 수립합니다.

2단계: 재구축 가능 여부 분리해 개별 전략 수립

두 번째로 시스템의 특성을 반영한 Re-use, Re-build(재구축) 대상을 분석하여 마이크로서비스로의 대상을 선별합니다. 00여 개의 시스템 중 Re-use 가능한 것과 가능하지 않은 시스템을 분리하여 개발 전략을 수립하게 됩니다. 화면(UI)과 DB 프로그램과 관련된 소스코드의 경우 대부분 Re-build이고, 백앤드 자바(java) 언어로 개발된 소스코드 중 Class, Method 및 특정 Module은 일부 Re-use 하게 됩니다. 마이크로서비스(Microservice) 개발이 가능한 시스템을 별도로 선별하고 MSA(Microservice Architecture) 구성 전략을 수립합니다 .

[여기서 잠깐!] 마이크로서비스 아키텍처(Microserivce Architecture)란?

클라우드에서 MSA(Microservice Architecture)는 애플리케이션을 작고 독립적인 단위로 나눈 서비스 기반 아키텍처를 의미합니다. 각각의 마이크로서비스는 하나의 특정 기능을 수행하며, 서로 다른 마이크로서비스와 협력하여 전체 애플리케이션을 구성합니다.

MSA의 핵심 아이디어는 모놀리식 아키텍처를 대체하여, 애플리케이션을 작은 단위의 서비스로 나누고, 각 서비스를 개별적으로 개발, 배포, 운영할 수 있도록 하는 것입니다. 이를 통해 개발자들은 작은 단위의 코드 변경 사항에 대해서만 관리하면 되기 때문에, 애플리케이션의 유지보수성과 개발 생산성을 향상시킬 수 있습니다.

또한, MSA는 애플리케이션의 가용성과 확장성을 높이는 데도 중요한 역할을 합니다. 각각의 마이크로서비스는 독립적으로 개발, 배포, 운영되므로, 서비스 단위로 확장이 가능합니다.

MSA는 클라우드 환경에서 더욱 중요한 역할을 합니다. 클라우드에서는 서비스를 쉽게 배포하고, 자원을 효율적으로 활용할 수 있는 환경이 제공되기 때문에, MSA 아키텍처가 적극적으로 활용되고 있습니다.

3단계: 서비스들을 조합해 새로운 비즈니스 서비스를 생성할 수 있는 플랫폼 완성

마지막으로 마이크로서비스를 등록·공유할 수 있고 이러한 서비스들을 조합해서 새로운 비즈니스 서비스를 생성할 수 있는 플랫폼을 완성합니다. API를 등록하고 공유할 수 있는 ‘API Hub’ 시스템을 구축하여 마이크로서비스를 상호 연결 및 조합하고 이를 통해 새로운 비즈니스 서비스를 만들 수 있도록 서비스 카탈로그(Service Catalog)를 구축하는 것입니다. 이러한 3단계 ‘애플리케이션 현대화 수행전략’을 실현하기 위한 기술 전략이 필요합니다.

Prioritization

정량적 지표와 정성적 지표의 우선순위가 높을수록 비즈니스 가치와 시스템 특성을 중요시합니다.

APAM (Application Portfolio Analysis Method)
정량적 지표
  • 장애 영향도
  • 등급
  • 인터페이스 수
  • 프로그램 수
정성적 지표
  • 예상 개발 기간
  • 비즈니스 중요도
언어별 시스템 수
  • Microsoft .NET 1개
  • 전자정부프레임워크(Spring) 5개
  • Struts 10개
  • C언어 배치 1개
  • SpringBoot 5개
  • PL/SQL 1개
  • Spring 약 10개
  • JSP 1개
  • JAVA 25개
  • HTML 3개
  • C언어 3개
  • C# 18개
  • ASP 22개
  • Android (java) 1개
  • .Net Framework 22개
Re–use, Re–build

기술 타입과 5년간 Re–factor 전환 방법을 확인할 수 있습니다.

Application Migration Strategy (Re‐factor)
    • Aglle Methodology
      • Development Framework
      • Executable Framework
    • Global Standard
    • Talent Transformation
  1. develop
    • Microservice
  2. register
    • Service Catalog
  3. compose
    • Composable Applications

애플리케이션 현대화 수행전략

애플리케이션 현대화(Application Modernization) 기술 전략

애플리케이션 현대화를 위한 기술전략에는 크게
1. 애플리케이션 현대화 수준 평가(AM Assessment), 2. 클라우드 네이티브 아키텍처(Cloud Native Architecture) 3. 컴포저블 어플리케이션(Composable Appliction) 4. SRE(Site Reliability Engineering)의 4가지 중요 고려 사항이 있는데요.
이 중 클라우드 네이티브 아키텍처와 컴포저블 어플리케이션에 대해 알아보겠습니다.

AM 전환
  • AM Assessment
    • 어플리케이션 Re‐use, Re‐build (Composable Application)
    • 아키텍처 표준 (Cloud Native Architecture)

      • 기술 가이드 (Composable Application)

      • 설치/운영 자동화 (SRC)

Cloud Native Architecture

클라우드 네이티브는 모든 시스템 및 애플리케이션의 설치와 구성이 클라우드 환경 기반으로 구성되는 것을 의미합니다. 업계에서 얘기하는 클라우드 네이티브는 ‘마이크로 서비스’, ‘컨테이너’, ‘데브옵스’를 뜻합니다. 즉 클라우드 환경에서 ‘컨테이너’, ‘마이크로서비스’, ‘데브옵스’ 환경이 구축되고 유기적으로 연결되어 동작하는 시스템 모양을 만들어야 한다는 것입니다.

1) 컨테이너

컨테이너 기술의 발전으로 업계에서는 사실상(De-factor) 표준처럼 사용하고 있습니다. 과거의 VM 환경을 컨테이너 환경으로 전환하는 사례가 많습니다. 물론 VM, 컨테이너 등 어느 한쪽의 기술만 사용하는 형태가 아닌 VM 위에 컨테이너 혹은 같이 혼용해서 사용하는 형태가 일반적입니다. 컨테이너 기술과 관련해서는 대표적인 클라우드 사업자인 아마존이 ‘AWS re:Invent 2017’에서 AWS Fargate를 발표했었습니다. AWS Fargate란 사용자가 컨테이너를 생성하고 직접 관리해야 하는 많은 번거로운 부분들을 AWS에서 관리해주는 완전한 형태의 매니지드 서비스입니다. 사용자는 애플리케이션 콘텐츠, 네트워킹, 스토리지 관리에만 집중하면 되고 프로비저닝, 패치 적용, 클러스터 용량 관리 또는 인프라 관리 등에 대해서는 신경을 쓰지 않아도 됩니다. 기업이 IT 환경 관리에 대한 노력을 줄이고 비즈니스에 집중할 수 있는 플랫폼을 제시하고 있습니다. 컨테이너는 비즈니스 애플리케이션을 포함하거나 그 자체가 비즈니스 애플리케이션입니다.

VM
  • Infrastructure
    • Host Operating System
      • Hypervisor
          • App 1
            • Bins/Libs
            • Guest OS
          • App 2
            • Bins/Libs
            • Guest OS
          • App 3
            • Bins/Libs
            • Guest OS
Container
  • Infrastructure
    • Operating System
      • Docker Engine
          • App 1
            • Bins/Libs
          • App 2
            • Bins/Libs
          • App 3
            • Bins/Libs

VM vs Container

EC2
  • Amazon ECS
    • Scheduling and Orchestration
      • Cluster Manager
      • Placement Engine
  • EC2 Instance
    • ECS Task
      • ECS agent
      • Docker agent
      • ECS AMI
AWS Fargate
  • Amazon ECS
    • Scheduling and Orchestration
      • Cluster Manager
      • Placement Engine
  • ECS Task

출처: http://www.opennaru.com/kubernetes/cloud-native-computing-foundation-cncf AWS Fargate

2) 마이크로서비스

대부분의 애플리케이션 현대화 전환 대상 애플리케이션은 모놀리스 구조입니다. 모놀리스 구조가 문제라고 하기보다는 모놀리스한 시스템은 구조상 많은 기능이 하나의 애플리케이션 안에 모두 포함되어 있습니다. 비즈니스 측면에서는 특정 기능에 대한 수정이 용이하지 않습니다. 수정이 용이하지 않은 것은 비즈니스 요건을 즉시 반영하기 부담스러운 구조라는 것입니다. 기술적인 측면에서는 컨테이너로 전환 시에 컨테이너 크기가 커서 기동하거나 정지하는데 다소 시간이 많이 소요된다는 단점이 있습니다. 이러한 문제에 대한 대안으로 마이크로서비스가 회자되고 있습니다. 마이크로서비스 개발의 핵심은 모놀리스 애플리케이션을 독립적으로 실행이 가능한 단위로 분할하는 것입니다. 하지만 십 수년간의 비즈니스가 포함되어 있는 애플리케이션을 한번에 재단하는 것은 분명 많은 장애 위험을 내포하게 됩니다. 비즈니스 측면에서 중요하다고 판단되는 업무에 대해서는 업무 담당자와 충분한 협의와 협업을 통해서 서비스를 분할해야 합니다. 분명한 것은 마이크로서비스 구조의 애플리케이션은 분명 'Business Agility'를 충족시키는데 기존의 모놀리스 애플리케이션에 비해 장점이 있습니다. 비즈니스 측면에서 애플리케이션 단위가 작아지고 서비스에 대한 기능 응집도를 높이고 결합도가 낮은 서비스를 구현함으로써 특정 부분에 대한 변경 및 배포 작업 부담이 줄어 비즈니스 변환에 상대적으로 빠른 대응이 가능하다는 것입니다. 앞서 얘기한 컨테이너 기술의 발전이 없었다면 예전의 'SOA(Service Oriented Architecture)'의 힘들었던 과정을 답습하고 있을지도 모릅니다. 다행인 것은 마이크로서비스를 실행할 수 있는 기술적 환경이 과거보다 분명히 좋아졌다는 것입니다 .

[여기서 잠깐!] 모놀리스 구조(Monolith)란?

모놀리스 구조는 전통적인 소프트웨어 개발 방식으로, 하나의 애플리케이션에 모든 기능을 포함하는 구조를 말합니다. 이러한 애플리케이션은 하나의 코드베이스로 구성되며, 데이터베이스나 라이브러리 등의 리소스를 공유합니다.

모놀리스 구조는 개발과 배포가 비교적 간단하며, 운영과 관리가 쉬워 생산성을 높일 수 있습니다. 또한, 전체 애플리케이션을 한 번에 수정하고 배포하므로 일관성을 유지하기 쉽습니다.

하지만 모놀리스 구조는 애플리케이션 규모가 커지면서 복잡성이 증가하는 단점이 있습니다. 한 번에 많은 코드를 수정하고 배포하기 때문에 작은 변경 사항도 전체 시스템에 영향을 미칠 수 있습니다. 또한, 스케일링이 쉽지 않으며, 모든 기능을 포함하는 단일 애플리케이션으로 인해 유연성과 확장성이 제한됩니다.

따라서 최근에는 모놀리스 구조 대신, 마이크로서비스 아키텍처와 같은 분산 시스템 구조가 주로 사용되고 있습니다.

API First Design
  • Backend 개발팀
    1. IMPL
    2. MOCK
    3. API
  • Frontend 개발팀
    • Android
      1. SDK
      2. API
    • iOS
      1. SDK
      2. API
    • Client
      1. SDK
      2. API

API First Design

Monolithic
This project has got so big, i'm not sure i'll be albe to deliver it!
Micro Service
it's so much better delivering this project in bite-sized sections

출처: https://happy-coding-day.tistory.com/94 모놀리스 vs 마이크로서비스

3) API First Design

마이크로서비스를 개발하다 보면 고민이 생깁니다. 일반적으로 기능을 개발하는 절차는 백앤드(Back-End) 프로그램을 개발해서 API를 생성하면 프론트앤드(Front-End) 개발자는 백앤드 API를 참조해서 화면(UI)을 개발하게 됩니다. 백앤드 프로그램은 자바와 같은 언어로 비즈니스 업무 로직을 구현한 기능이고 프론트앤드 프로그램은 화면(UI) 기능을 구현한 프로그램입니다. 앞서 설명한 과정 즉 백앤드 프로그램 개발 후 프론트앤드 프로그램을 개발하는 과정을 반복하며 프로젝트가 진행됩니다. 그런데 이러한 방식은 프론트앤드 개발자가 늘 백앤드 프로그램 개발이 끝나기를 기다렸다가 일을 해야 하는 번거로움이 생기게 됩니다. 개발 시점의 차이가 그 이유입니다. 백앤드 소스코드 중 일부 변경이 일어나면 프론트앤드 소스코드의 변경이 수반됩니다. 이는 여러모로 불편하고 번거로운 작업입니다. 이러한 번거로움을 어떻게 해결할 수 있을까? 하는 것의 답이 ‘API First Design’입니다. 백앤드 개발자가 API만 정의하면 결과를 보여줄 수 있는 Mock을 제작할 수 있습니다. 프론트앤드 개발자는 Mock을 이용해서 백앤드 프로그램의 API를 테스트할 수 있습니다. 백앤드 개발자는 API 형태의 Mock을 등록하여 프론트앤드 개발자와 의사소통을 진행하게 됩니다. 구글에서 만든 ‘Google apigee’ 같은 솔루션이 ‘API First Design’을 실현할 수 있는 대표적인 솔루션입니다.

4) 서비스 카탈로그

‘서비스 카탈로그’는 독립적으로 실행이 가능한 마이크로서비스가 등록되어 여러 비즈니스에서 활용 가능하도록 서비스들을 제공하는 일종의 ‘서비스 마켓플레이스’ 같은 개념입니다. 등록된 서비스를 서로 조합해서 새로운 서비스를 만들 수도 있습니다. 다소 이상적인 모습이긴 하지만 결국에는 이러한 목표를 가지고 애플리케이션을 개발하면 비즈니스나 기술적인 성숙도 측면에서 좋은 지향점일 수 있습니다. 예를 들어, 항공 관련 서비스 중 '탑승권 판매/발권 서비스', '면세품 판매 서비스', '기내식 서비스', '항공 결제 서비스' 등이 서비스 카탈로그에 각각 개별 서비스로 등록되어 있다면 이들 서비스가 필요한 조직 혹은 기업에서는 등록된 서비스를 사용하거나 혹은 서비스를 조합하여 '항공 여객 서비스'라는 새로운 서비스를 만들 수 있게 됩니다. 잘 만들어진 서비스를 조합하여 새로운 비즈니스 애플리케이션을 생성하는 개념은 최근 ‘가트너’에서 발표한 ‘Composable Applications’의 개념과 일맥상통합니다. 그럼 ‘Composable Applications'에 대해 조금 더 알아보겠습니다.

API Hub (Compose API)와 서비스 카탈로그(Create Biz Service)를 조합해서 새로운 서비스를 만들 수 있습니다.

서비스 카탈로그
Biz. Catalog의 Load Service, Gov. I/F Service, Custom Service 정보를 확인할 수 있습니다.
Load Service Gov. I/F Service Custom Service
여객 탑재 서비스 KCUS 연동 서비스 적하목록 서비스
화물 탑재 서비스 관세청 연동 서비스 보세창고 서비스
C.G 서비스 공항공사 연동 서비스 통관 상태 제공 서비스
Tech Catalog의 Middleware, DBMS, Cache/Queue 정보를 확인할 수 있습니다.
Middleware DBMS Cache/Queue
Tomcat MariaDB EHCache
Wildfly PostgreSQL Redis
Nginx MongoDB RabbitMQ

서비스 카탈로그

Gartner 2022 Strategic Technology Trend, Composable Applications

최근 ‘가트너’에서 2022년 12가지 전략 기술 트랜드를 발표했습니다. 물론 가트너가 발표한 전망대로 모두 실현되는 것은 아니지만 우리가 하는 업과 관련된 주제들은 살펴볼 가치가 있습니다. 주제들 중 하나인 클라우드 네이티브 플랫폼(Cloud Native Platform) 은 과거와는 비교도 안될 만큼 빠른 성장과 성숙도의 향상을 보이고 있습니다. 과거에 주로 'IaaS' 서비스 중심이었던 클라우드 서비스가 점차 'PaaS', 'SaaS'까지 영역을 확대하고 기술의 성숙도 상당히 높아졌습니다. 애플리케이션의 구조 또한 많은 변화가 있었고 현재 새롭게 진행되는 애플리케이션 구조를 마이크로서비스 형태로 구축하려는 기업이 많아졌습니다.

컴포저블 애플리케이션(Composable Applications)의 개념

‘가트너’가 발표한 컴포저블 애플리케이션(Composable Applications)은 이보다 한 발 더 앞서 나간 개념인 것 같습니다. 잘 만들어진 여러 개의 마이크로서비스를 필요에 따라 조합해서 새로운 비즈니스 애플리케이션을 만드는 'Composable Applications'에는 비즈니스에서 필요한 모든 기능을 담게 됩니다.

예를 들어 설명하자면 해외여행을 갈 때 탑승권을 구매하고 탑승 수속을 밟게 되고, 탑승 후에는 비행기에서 면세품을 구매하기도 하고 기내식을 먹기도 합니다. 항공사 입장에서는 이 모든 서비스가 승객들이 불만이 없게 제공해야 하는데, 시스템 관점에서 서비스로 생각해보면 '탑승권 판매/발권 서비스', '면세품 판매 서비스', '기내식 서비스', '항공 결제 서비스' 등의 개별 서비스로 분리할 수 있고 이들을 합쳐서 '항공 여객 서비스'로 제공할 수도 있습니다. 즉 '탑승권 판매/발권 서비스' 같은 독립적으로 동작이 가능한 작은 서비스를 조합해서 '항공 여객 서비스'라는 조합된 하나의 서비스로 만들 수 있다는 것입니다. 여기서 '탑승권 판매/발권 서비스' 같은 독립적으로 동작이 가능한 작은 서비스가 '마이크로서비스'이고 이를 결합하여 만든 '항공 여객 서비스'가 컴퍼저블 애플리케이션(Composable Applications)이 됩니다. 당연히 설명한 대로만 설계하고 구현한다면 정말 이상적인 애플리케이션이 탄생할 것이라는 것은 의심의 여지가 없습니다. 이러한 구조의 애플리케이션은 생각하는 것처럼 쉽게 설계하고 구현하기는 어려울 것입니다. 다만 이러한 컨셉을 목표로 하여 기획하고 설계하다 보면 보다 ‘Business Agility’ 실현을 위한 좋은 설계와 사례를 만들어 갈 수 있지 않을까 라는 생각이 듭니다.

Top Strategic Technology Trends for 2022
  • Data Fabric
  • Composable Applications
  • Distributed Enterprise
  • Cybersecurity Mesh
  • Decision Intelligence
  • Total Experience
  • Privacy–Enhancing Computation
  • Hyperautomation
  • Autonomic Systems
  • Cloud–Native Platforms
  • AI Egineering
  • Generative AI

출처: Gartner



Composable Business
Business Model
  • Value Propostion
  • Customer
  • Financials
  • Business Capanilities
Operating Model
  • Value Streams
  • Govemance
  • Resource
  • Business Capanilities
Digital Twin Composable Applications

PBC (Packaged Business Capabilities)의 디자인 원칙과 구성요소는 아래 4가지가 있습니다.

  • Orchestration
  • Discovery
  • Autonomy
  • Modularity

Packaged business capabilities are encapsulated software components that represent a well-defined business capability, recognizable as such by a business user and packaged for programmatic access.

맺음말: 조직의 구조, 문화, 기술까지 큰 변화를 수반하는 애플리케이션 현대화 (Application Modernization)

애플리케이션 현대화는 기업의 조직 구조, 문화, 기술까지 큰 변화를 수반하게 됩니다. 애플리케이션 현대화 전환을 통해 다양한 이해관계자들의 뷰(view) 를 만족시키지 못하고 비즈니스 측면에서의 효과도 없다면 이는 단순히 프로그램 언어를 바꾸거나 시스템만 이전하는 것과 다를 바가 없습니다. 단순한 노동이 됩니다.

현대화된 애플리케이션 구조에서 비즈니스 가치를 창출하지 못한다면 그 결과는 기업의 존망과도 직결된다는 절실함에서 나오는 철저한 고려가 필요할 것 같습니다.

기업의 생존에 꼭 필요한 애플리케이션 현대화를 위한,
삼성 클라우드 플랫폼 (Samsung Cloud Platform)에서 클라우드 컨테이너 상품을 만나보세요.

박성훈 프로 / 삼성SDS
MSA 컨설팅/설계/구축 업무를 담당하고 있고 주로 대내외 시스템 구축 프로젝트에 참여하고 있습니다. 이 외 T2 MSP 개요 강의, 아키텍트 데이, 기술사 멘토링 등의 활동을 하고 있습니다. 소소하지만 개인 홈페이지 hoony.com을 통해서 IT 경험을 공유하고 소통하고 합니다.
클라우드 기술 백서 관련하여 궁금하신 사항은 이곳으로 문의주세요.

좋아요
공유하기