2020.06.08

IDG 블로그 | 성공적인 클라우드 아키텍처로 가는 3단계

David Linthicum | InfoWorld
클라우드 아키텍트라면 클라우드 기술과 각 기술 조각을 어떻게 하나로 맞추는지를 알아야 한다. 또한 전통적인 프로세스도 이해할 필요가 있다.
 
ⓒ Getty Images Bank

클라우드 아키텍처가 다시 뜨거운 주제로 떠올랐다. 클라우드 아키텍트 구하기가 어려워지고 연봉은 올라가면서 많은 사람이 클라우드 아키텍처 관련 교육을 찾고 있다.

대부분 클라우드 아키텍트는 실제로 퍼블릭 클라우드 서비스 업체 한 곳에 관한 전문가에 불과하다. 다른 클라우드 서비스 업체를 알지 못하며, 이들이 함께 동작하는 방식도 알지 못한다. 아키텍트가 너무 근시안적으로 접근하며 맞든 안맞든 같은 기술만을 사용하는 바람에 클라우드 프로젝트가 실패하기도 한다.

필자는 20년 전에 사용하던 전통적인 아키텍처 프로세스로 돌아가는 것이 2020년의 클라우드 컴퓨팅에 더 잘 맞을 수도 있다는 것을 알게 됐다. 물론 이 프로세스는 오늘날 솔루션을 구축하는 방식과 우리가 사용하는 기술로 현대화해야 한다.

“장고 끝에 악수”는 항상 위험하다. 게다가 전통적인 순차적 아키텍처 프로세스(워퍼폴 방식)은 애자일 방법론의 세계와 공공연히 충돌한다.

클라우드 아키텍트는 다음 두 가지 극단을 조심해야 한다.

첫째는 클라우드 아키텍처 성공으로 가는 길을 반복할 수 있다는 생각이다. 애플리케이션 개발 모델은 애플리케이션 개발을 최적화하고 비즈니스 요구사항의 변화에 즉각적으로 대응하는 프로세스이다. 하지만 완전히 최적화된 아키텍처를 얻기 위해 수백만 달러를 불필요하게 허비할 계획이 아니라면, 똑같은 접근방법이 먹혀들지는 않는다. 엄청난 비용과 위험성을 지지 않고는 값비싼 기술이나 클라우드 서비스를 그런 식으로 도입할 수는 없다.

둘째, 클라우드 아키텍처를 기반 클라우드 기술을 선택하는 데 1년 이상이 걸리는 과정으로 생각한다면, 세상이 따라잡기 힘든 속도로 빠르게 바뀐다는 것을 알게 될 것이다. 이렇게 설계한 아키텍처를 프로덕션에 적용한다면, 구식 아키텍처를 배치하는 것이다.

그렇다면 성공적인 클라우드 아키텍처로 가는 가장 좋은 길은 무엇일까? 요즘의 베스트 프랙티스는 ‘빠른 설계’인데, 필자가 매일 연습하는 것이기도 하다. 그야말로 전통적인 방식과 새로운 방식의 만남이다.

우선은 마스터에 해당하는 전사적인 논리 아키텍처를 만들어 기존 엔터프라이즈 아키텍처와 관련해 클라우드 아키텍처란 무엇인지에 대한 기반 이해를 제공한다. 이때는 논리 아키텍처의 어떤 부분도 특정 기술에 배정하지 않는다. 논리 아키텍처는 앞으로 구축하고자 하는 비전으로, 매크로아키텍처(Macro Architecture, 고수준 아키텍처) 이다.

두 번째, 논리 매크로 아키텍처를 수많은 마이크로아키텍처로 분해한다. 글로벌 2000대 기업의 대부분에서 이는 부서, 기술 플랫폼, 데이터 스토리지, 보안 모델 등이다. 매크로아키텍처를 분해해 얻은 마이크로아키텍처는 빠른 설계 방법론을 사용해 해결할 수 있다.

마지막으로, 각 마이크로아키텍처에 각각의 빠른 설계 스프린트와 관련한 맞춤형 프로세스를 이용한다. 간단히 말해, 타임박싱(time-boxing) 방법론으로 각 마이크로 아키텍처를 위한 설계 주기를 몇 주 또는 며칠로 못박는 것이다. 이들 과정은 따로 분리해 연속적으로 또는 병렬적으로 진행할 수 있어야 한다.

과거의 접근과 현재 사용하는 방식을 얼마나 조합해야 할지는 흥미로운 일이다. 최고의 아키텍트라면 기술이나 프로세스, 방법론에 열린 마음을 잃지 않아야 한다. 아키텍트는 끊임없이 진화해야 한다. editor@itworld.co.kr


2020.06.08

IDG 블로그 | 성공적인 클라우드 아키텍처로 가는 3단계

David Linthicum | InfoWorld
클라우드 아키텍트라면 클라우드 기술과 각 기술 조각을 어떻게 하나로 맞추는지를 알아야 한다. 또한 전통적인 프로세스도 이해할 필요가 있다.
 
ⓒ Getty Images Bank

클라우드 아키텍처가 다시 뜨거운 주제로 떠올랐다. 클라우드 아키텍트 구하기가 어려워지고 연봉은 올라가면서 많은 사람이 클라우드 아키텍처 관련 교육을 찾고 있다.

대부분 클라우드 아키텍트는 실제로 퍼블릭 클라우드 서비스 업체 한 곳에 관한 전문가에 불과하다. 다른 클라우드 서비스 업체를 알지 못하며, 이들이 함께 동작하는 방식도 알지 못한다. 아키텍트가 너무 근시안적으로 접근하며 맞든 안맞든 같은 기술만을 사용하는 바람에 클라우드 프로젝트가 실패하기도 한다.

필자는 20년 전에 사용하던 전통적인 아키텍처 프로세스로 돌아가는 것이 2020년의 클라우드 컴퓨팅에 더 잘 맞을 수도 있다는 것을 알게 됐다. 물론 이 프로세스는 오늘날 솔루션을 구축하는 방식과 우리가 사용하는 기술로 현대화해야 한다.

“장고 끝에 악수”는 항상 위험하다. 게다가 전통적인 순차적 아키텍처 프로세스(워퍼폴 방식)은 애자일 방법론의 세계와 공공연히 충돌한다.

클라우드 아키텍트는 다음 두 가지 극단을 조심해야 한다.

첫째는 클라우드 아키텍처 성공으로 가는 길을 반복할 수 있다는 생각이다. 애플리케이션 개발 모델은 애플리케이션 개발을 최적화하고 비즈니스 요구사항의 변화에 즉각적으로 대응하는 프로세스이다. 하지만 완전히 최적화된 아키텍처를 얻기 위해 수백만 달러를 불필요하게 허비할 계획이 아니라면, 똑같은 접근방법이 먹혀들지는 않는다. 엄청난 비용과 위험성을 지지 않고는 값비싼 기술이나 클라우드 서비스를 그런 식으로 도입할 수는 없다.

둘째, 클라우드 아키텍처를 기반 클라우드 기술을 선택하는 데 1년 이상이 걸리는 과정으로 생각한다면, 세상이 따라잡기 힘든 속도로 빠르게 바뀐다는 것을 알게 될 것이다. 이렇게 설계한 아키텍처를 프로덕션에 적용한다면, 구식 아키텍처를 배치하는 것이다.

그렇다면 성공적인 클라우드 아키텍처로 가는 가장 좋은 길은 무엇일까? 요즘의 베스트 프랙티스는 ‘빠른 설계’인데, 필자가 매일 연습하는 것이기도 하다. 그야말로 전통적인 방식과 새로운 방식의 만남이다.

우선은 마스터에 해당하는 전사적인 논리 아키텍처를 만들어 기존 엔터프라이즈 아키텍처와 관련해 클라우드 아키텍처란 무엇인지에 대한 기반 이해를 제공한다. 이때는 논리 아키텍처의 어떤 부분도 특정 기술에 배정하지 않는다. 논리 아키텍처는 앞으로 구축하고자 하는 비전으로, 매크로아키텍처(Macro Architecture, 고수준 아키텍처) 이다.

두 번째, 논리 매크로 아키텍처를 수많은 마이크로아키텍처로 분해한다. 글로벌 2000대 기업의 대부분에서 이는 부서, 기술 플랫폼, 데이터 스토리지, 보안 모델 등이다. 매크로아키텍처를 분해해 얻은 마이크로아키텍처는 빠른 설계 방법론을 사용해 해결할 수 있다.

마지막으로, 각 마이크로아키텍처에 각각의 빠른 설계 스프린트와 관련한 맞춤형 프로세스를 이용한다. 간단히 말해, 타임박싱(time-boxing) 방법론으로 각 마이크로 아키텍처를 위한 설계 주기를 몇 주 또는 며칠로 못박는 것이다. 이들 과정은 따로 분리해 연속적으로 또는 병렬적으로 진행할 수 있어야 한다.

과거의 접근과 현재 사용하는 방식을 얼마나 조합해야 할지는 흥미로운 일이다. 최고의 아키텍트라면 기술이나 프로세스, 방법론에 열린 마음을 잃지 않아야 한다. 아키텍트는 끊임없이 진화해야 한다. editor@itworld.co.kr


X