클라우드 아키텍처도 빠른 변화에 대비해야 한다

클라우드 아키텍처도 빠른 변화에 대비해야 한다

이 글은 IDG의 아티클을 전재하여 제공합니다.
[원문보기]: https://www.itworld.co.kr/news/


설립 5년차의 중견 바이오테크 회사가 있다고 가정해 보자. 편의를 위해 회사 이름은 미드코(MidCo)라고 정했다. 이 회사는 혈액 및 근육 샘플의 자동화된 테스트가 전문이다. 유망한 분야라 첫 5년 동안 사업은 성장했다. 하지만 스타트업 경쟁업체가 AI를 이용하는 좀 더 첨단화된 제품을 생산해 더 저렴한 가격에 판매하면서 미드코는 망해가고 있다.

미드코의 IT 부서는 더 최적화된 검사 기술을 더 나은 가격에 만들기 위해 연구개발과 마케팅에서 요구하는 변화를 따라가지 못한다. 게다가 일부 미드코의 특허 제품은 기존 클라우드 기반 시스템의 한계 때문에 생산 단계에 들어가지도 못했다. 미드코의 시스템은 몇몇 공급업체만 통합하고 다양한 서드파티 부품 업체를 이용하지 못하는데, 이 때문에 부품 공급 부족이나 공급업체 변경 등과 관련해 최적화된 공급망을 확보할 수 없다.

미드코가 망하는 이유는 나쁜 운이나 점점 치열해지는 시장 경쟁이 아니다. 초기에 클라우드 기반 솔루션을 만들면서 주요 시스템에 빠른 변화를 수용할 수 있는 역량을 통합하지 못했기 때문이다. 이런 제약은 회사가 성장하면서 점점 더 큰 문제가 되었는데, 시장이 누구도 예상하지 못한 속도로 빠르게 변했기 때문이다.

요즘은 미드코 같은 회사가 일반적이다. 이런 문제는 너무 많은 사일로 시스템을 통합하지 않은 채 운영하는 구식 기업에서나 있을 것이라고 생각하기 쉽다. 하지만 설립하지 10년 미만에다 클라우드 기반 시스템만을 사용해 온 곳도 많다. 이런 회사가 왜 망하는 것일까?

클라우드 컴퓨팅은 자동으로 최고의 민첩성과 최적화된 비용을 제공한다고 생각하는 사람이 많다. 하지만 현실은 전혀 그렇지 않다. 클라우드이건 아니건 빠른 변화에 적응할 수 있는 시스템을 구축해야만 한다. 많은 경우, 기존 클라우드 시스템에 관련 기능을 통합하는 것은 전통적인 시스템을 업그레이드하는 것만큼이나 어렵다. 그리고 이런 변화 기능 없이는 중견 기업은 파괴적인 경쟁자가 등장하면 바로 치명타를 맞는다. 일반 사용자에게 친숙한 공유 자동차나 공유 주택, 엔터테인먼트 시장만 봐도 알 수 있다.

오늘날 기업은 변화에 앞서 준비해야만 한다. 어떤 아키텍처라도 변화를 수용할 수 있어야 한다. 시스템이란 처음에는 최적화된 상태이겠지만, 시간이 지나도 계속 좋은 아키텍처이지는 않다. 지금 제대로 동작하는 시스템을 만드는 것만으로는 충분하지 않다. 내일과 모레의 빠른 변화도 수용할 수 있어야 한다.

변화를 수용하는 역량, 즉 민첩성은 새로운 특징은 아니다. SOA(Software Oriented Architecure)나 클라우드 컴퓨팅은 아키텍트가 최고의 민첩성을 제공하도록 독려한다. 아키텍처가 변화에 빠르게 대응할 수 있는 역량이 없는 것도 당연한 일이다. 설계도 위에 여러 시스템의 계층이 추가되면, 빠른 변화를 수용하는 것이 쉽지 않다. 그리고 이런 추가 계층은 계속 늘어날 것이다.

그렇다면 예상할 수 없는 변화에는 어떻게 대비해야 할까?

변화를 시스템에 들어가야 할 실질적인 기능으로 정의하고, 여기에 아키텍처의 우선순위를 부여할 수 있다. 처음에는 비용과 시간이 더 들어가는 추가 단계가 필요하지만, 장기적으로는 훨씬 이득이다. 이런 단계에는 다음과 같은 작업이 포함된다.

• 도메인 내에 휘발성 배치. 데이터이든 비즈니스 규칙이든 애플리케이션 동작 방식이든, 전체 시스템의 재개발과 테스트없이 즉각적인 환경구성 변경을 통합하는 역량을 제공한다. 이 역량은 퍼블릭 클라우드 내에서 더욱 강력한데, 광범위한 분산 시스템이 중앙화된 환경구성을 이용할 수 있기 때문이다.
• 서비스의 폭넓은 활용. 마이크로서비스부터 표준 서비스까지 개별 서비스로 분리된 것과 그렇지 않은 것을 나누어 아키텍처 전반에 걸쳐 재사용할 수 있도록 한다. 이들 서비스는 재배치나 테스트없이 변경할 수 있도록 한다.
• 추상화 사용. 추상화는 물리 데이터와 물리적인 처리에 필수적인 변경을 처리하는 핵심적인 툴이다. 쉽게 말해, 이 메커니즘은 휘발성을 도메인 내에 배치할 수 있도록 한다. 이런 구조와 시퀀스를 소프트웨어에서 변경해 물리 프로세스와 물리 데이터 스토리지를 변경하고, 백엔드 시스템은 변경하지 않는다.

이외에도 생각할 수 있는 기법은 많다. 하지만 이들 솔루션의 패턴을 이해하지 못하면 제때에 필요한 것을 구현하기 어렵다. 대부분 클라우드 아키텍트는 빠른 변경을 수용할 수 있는 설계에 우선순위를 두지 않는다. 어떻게 해야 하는지도 모르고 비용이나 시간을 이유로 추가 단계를 피하는 경우가 흔하다.

변화에 대한 준비에 착수하지 않으면, 수십억 달러짜리 기업이 어느 순간 사라질 수도 있다. 이런 실패의 원인을 추적해 보면, 경쟁력을 유지하기 위해 필요한 변화를 제대로 따라가지 못한 경우가 대부분이다. 민첩성은 있으면 좋은 역량이 아니라 생존을 위한 조건이다. 새로 회사를 설립하는 경우도, 기존 아키텍처를 고치는 경우도 마찬가지다. 휘발성을 도메인 내에 배치할 방법을 찾기 바란다. 서비스를 분해해 언제 어디서나 재사용할 수 있도록 하라. 추상화를 가장 잘 이용할 수 있도록 시스템을 정의하라.



IDG logo

▶   해당 콘텐츠는 저작권법에 의하여 보호받는 저작물로 기고자에게 저작권이 있습니다.
▶   해당 콘텐츠는 사전 동의 없이 2차 가공 및 영리적인 이용을 금하고 있습니다.


이 글이 좋으셨다면 구독&좋아요

여러분의 “구독”과 “좋아요”는
저자에게 큰 힘이 됩니다.

subscribe

David Linthicum
David Linthicum 클라우드 전문가

Deloitte Consulting

Deloitte Consulting의 Chief Cloud Strategy Officer