Offcanvas
Some text as placeholder. In real life you can have the elements you have chosen. Like, text, images, lists, etc.
Offcanvas
1111Some text as placeholder. In real life you can have the elements you have chosen. Like, text, images, lists, etc.
클라우드

글로벌 칼럼 | ‘아웃사이드 인’ 방식으로 접근하는 클라우드 아키텍처

David Linthicum | InfoWorld 2022.04.18
22개월 동안 진행한 클라우드 아키텍처 프로젝트의 마지막 3주를 남겨놓고 있다. 수많은 클라우드 컴퓨팅 자원을 정의하는 환경 구성을 정의하고 설계했다. 데이터베이스와 AI 엔진, 애플리케이션 개발 플랫폼, 데브옵스 툴체인, 클라우드옵스 툴은 물론 보안과 거버넌스까지 설계했다.

그런데 오늘 몇몇 데이터베이스가 애플리케이션이 요구하는 대로 정보를 저장하지 않는다는 사실을 발견했다. 또 AI 엔진은 선택한 보안 솔루션에서는 동작하지 않으며, 클라우드옵스 툴은 예산보다 훨씬 비싸다. 왜 이런 일이 생긴 것일까? 순전히 아키텍트의 잘못일까?
 
ⓒ Getty Images Bank

때로는 클라우드 솔루션 설계 단계에서 이런 실수를 찾아내기도 한다. 새로 구축하는 시스템이거나 전통적인 플랫폼의 마이그레이션이든 관계없다. 안타깝게도 이런 유사한 문제는 클라우드 아키텍트가 오류를 최소화하기 위해 아무리 애를 써도 언제나 생긴다.

필자를 괴롭히는 것은 이런 실수가 구현 단계 이후까지도 발견되지 않는 경우가 많다는 점이다. 솔루션이 동작하기는 하겠지만, 기반에 깔린 문제는 여전히 비즈니스에 부정적인 영향을 미칠 것이다. 이런 솔루션은 갈수록 최적화 상태가 나빠지기 때문이다. 더 많은 운영 비용이 들고, 기업이 얻을 수 있는 이점은 더 줄어든다.

예를 들어, 사기 탐지 시스템을 지원할 AI 엔진을 잘못 골랐다고 생각해 보자. 이 시스템은 최적화된 AI 엔진을 이용했다면 잡아낼 수 있는 사기 행위의 1/3 정도밖에 잡아내지 못한다. 어쨌든 시스템은 사기를 탐지하고 있기 때문에 아무도 문제를 알아차리지 못한다. 하지만 뒤에서 매출 손실로 출혈이 계속되는 상태이다.

클라우드 컴퓨팅 솔루션을 점점 더 많이 사용하게 되면서 클라우드 아키텍트가 비즈니스에 악영향을 미칠 큰 실수를 저지르는 것도 자주 목격한다. 누구도 완벽할 수는 없다. 하지만 일부 아키텍트는 크건 작건 자신의 클라우드 솔루션에서 오류를 최소화하기 위한 모든 것을 한다. 이런 아키텍트가 하는 것은 무엇일까?

클라우드 솔루션을 구성하고 가장 최적화된 접근법을 고르는 데 있어서 실수를 100% 방지할 수 있는 확실한 길은 없다. 하지만 필자는 새 아키텍트와 일할 때는 먼저 클라우드 아키텍처에 인사이드 아웃(Inside out) 또는 아웃사이드 인(Outside in) 방식으로 접근할 수 있다는 것을 지적한다. 두 방법론은 서로 다른 이점이 있다.

인사이드 아웃 접근법은 스토리지, 컴퓨트, 데이터베이스, 네트워킹, 운영 등 가장 기본적인 개념과 기술 구성요소로부터 아키텍처를 생각한다. 그리고 더 상세한 요구사항을 정의하기 위해 외부로 확장한다. 데이터베이스 모델이나 성능 관리, 특정 플랫폼의 요구사항, 그리고 컨테이너와 컨테이너 오케스트레이션 같은 구현 기술을 정의한다.

다시 말해 인프라와 같은 기본 요소로 시작하고, 이후에 구체적인 솔루션 요구사항으로 확장한다. 총체적인 기술 결정과 환경 구성이 구체적인 비즈니스 요구사항을 어떻게 만족할 수 있을지 고민해야 한다. 이를 통해 비즈니스를 지원할 수 있는 구체적인 솔루션을 구축한다.

아웃사이드 인 접근법은 반대로 움직인다. 구체적인 비즈니스 요구사항으로 시작한다. 예를 들어, 특정 솔루션이나 애플리케이션에 맞는 비즈니스 사용례와 같은 것으로 시작한다. 그리고 안으로 들어가 인프라와 기타 기술 등 솔루션과 애플리케이션의 요구사항을 지원하기 위해 필요한 인프라와 기타 기술로 파고든다.

대부분 클라우드 아키텍트는 인사이드 아웃 접근법을 선택한다. 솔루션의 구체적인 목적을 제대로 파악하기 전에 인프라를 고르는 셈이다. 이들은 클라우드 서비스 업체나 데이터베이스 솔루션 업체와 협력 관계를 맺고 기타 인프라 관련 솔루션을 고르는데, 구체적인 비즈니스 솔루션의 요구사항을 만족할 것이라 가정할 뿐이다. 다시 말해, 좁은 범위의 솔루션을 선택하기 전에 넓은 범위의 솔루션을 고른 것이다.

이것이 바로 동작은 하지만 갈수록 최적화 상태가 나빠지는 솔루션을, 더 나쁘게는 앞서 설명한 여러 가지 놀라운 문제를 일으키는 솔루션이 만들어지는 방식이다. 이런 문제를 찾아내기 위해서는 상당한 시간의 작업이 필요하며, 보통은 즉석에서 기술 솔루션을 제거하고 대체할 수 있는 팀이 필요하다. 이런 팀은 필요한 데이터베이스 모델을 지원하는 데이터베이스를 추가해야 할 수 있는데, 이미 주요 데이터베이스 계약으로 라이선스 비용을 지불하고 있는 상태일 수도 있다. 아니면, AI와 동작할 수 있도록 보안 시스템을 교체해야 할지도 모른다. 불과 몇 년 전에 50만 달러나 들여 테스트하고 배치한 시스템일 수도 있다. 필자는 그간의 경험으로 많은 기업이 현재 이렇게 하고 있다는 것을 알고 있다.

기업은 먼저 기존의 가정을 기반으로 기반 기술을 선택하고, 이후에 기존 애플리케이션 포트폴리오가 필요로 하는 것을 살펴봐야 한다는 주장도 있다. 기업이 하드웨어와 소프트웨어를 구매하던 시절에는 더 비용 효과적인 방법이었을지 모르지만, 우리는 이제 클라우드 기반의 자원을 이용한다. 더는 그런 가정이 맞지 않는다.

이제 기업은 특정 애플리케이션과 솔루션의 요구사항을 이들 애플리케이션과 솔루션을 지원하고 완전히 최적화된 다수의 인프라 선택지 어디로도 옮길 수 있다. 각 애플리케이션에 최상인 데이터베이스나 보안, 거버넌스, 운영을 포함하는 독보적인 인프라를 구현할 수도 있다.

이런 환경의 이점은 구체적인 비즈니스 과제를 최적의 방법으로 해결하기 위해 선택하고 환경을 구성할 수 있는 지원 기술 인프라를 구축하는 것이다. 더는 과거의 기술 결정에 애플리케이션을 억지로 맞출 필요가 없다. 이 때문에 아웃사이드 인 접근법이 더 나은 클라우드 아키텍처 설계 방안이 된다. 클라우드의 강력함을 제대로 이용하는 방법이기 때문이다.
editor@itworld.co.kr
 Tags 아키텍처 아키텍트 아웃사이드인 인사이드아웃
IDG 설문조사

회사명 : 한국IDG | 제호: ITWorld | 주소 : 서울시 중구 세종대로 23, 4층 우)04512
| 등록번호 : 서울 아00743 등록일자 : 2009년 01월 19일

발행인 : 박형미 | 편집인 : 박재곤 | 청소년보호책임자 : 한정규
| 사업자 등록번호 : 214-87-22467 Tel : 02-558-6950

Copyright © 2022 International Data Group. All rights reserved.