클라우드 컴퓨팅에 대한 글, 기사는 계속 쏟아져 나오고 있습니다. 사용하는 용어도 참 다양하지요. 클라우드컴퓨팅, 유틸리티컴퓨팅, PaaS(Platform as a Service) 등의 용어가 주로 나오지요.
"마이크로소프트의 Gianpaolo의 블로그에서 가져왔습니다."
그런데 "클라우드 컴퓨팅"이 사용될 때 아키텍처 측면에서는 어떤 변화가 있을까요?
1. "직접 해라" vs "서비스로 쓰자"
- "직접 해라"의 경우는 컨트롤을 할 수 있지만, 반면에 규모의 경제 효과는 볼 수 없겠지요. 모든 비용을 혼자 지 불해야 합니다.
- "서비스로 쓰자"의 경우는 규모의 경제는 확실히 얻을 수 있지만, 직접 제어할 수는 없는 거죠
즉, "제어"와 "규모의 경제" 사이의 Trade Off이 있다는 거죠
2. "누가 구축할거냐"와 "누구의 장비에서 운영할 거냐"
- "누가 구축할거냐" (직접 개발하는 방식 vs 구입); 기능의 컨트롤에 영향을 미치는 거죠. 직접 구축한다면
기능을 넣고 빼는 것을 맘대로 할 수 있지만, 서비스 제공자로 부터 소프트웨어를 획득하는 거라면 제공자가
부여하는 것밖에 사용 못하겠지요.
- "누구의 장비에서 운영할 거냐"; SLA의 컨트롤에 영향을 미칩니다. "On Premise" 방식으로 직접 설치하고
운영한다면 SLA에 대한 모든 제어가 가능하겠지요. 물론 SLA에 대한 제어가 가능하다고해서 높은 SLA를
제공한다거나, 클라우드 방식보다 더 잘한다는 보장은 없지만요. ^^ 결국 SLA에 대한 조절은 가능하다는
것이고, 클라우드 방식을 사용한다면 SLA를 서비스 제공자가 주는대로 사용해야 겠지요. 
3. 가능성 맵 (map of possibilities)
위의 2가지 요소가 왜 중요할까요? 이 두가지의 요소를 통해 엔터프라이즈가 IT 자산을 사용할 수 있는 가능성 맵을 만들어볼 수 있기 때문이지요.
엔터프라이즈는 위의 2가지 요소에 비추어 "기능의 컨트롤", "SLA 컨트롤"을 규모의 경제를 활용하면서 얻기를 원하고 있다는 거죠. 맵 상의 하나의 선택이 다른 것보다 더 좋다는 것을 의미하는 것은 아니고 비즈니스 상황 및 규제 등에 따라 다르게 선택될 수 있는 것입니다.
아래의 그림을 통해 IT 자산의 몇 가지 유형을 볼 수 있습니다. 맨 왼쪽 위에 보면 '직접 설치된 패키지 소프트웨어'를 볼 수 있는데 직접 설치하고, SLA에 대한 모든 제어가 가능하지만 기능에 대해서는 제한적으로 선택이 가능하고, 규모의 경제를 통해 아쉬움을 달래는 것이죠. 소프트웨어 벤더의 경우 수백, 수천의 고객에게 패키지를 판매함을 통해 직접 고객이 개발하는 것보다 더 저렴한 금액으로 소프트웨어를 공급하게 됩니다. 맨 아래의 왼쪽 영역이 "직접 개발하고 직접 운영하는 소프트웨어" 영역 인데, 뱅킹 시스템을 예로 들어보지요. 제어권 및 기능을 모두 가지고 있지만 규모의 경제는 실현 못하죠. 개발 및 운영에 대한 모든 비용을 혼자 감당합니다 오른쪽 맨 위 영역이 바로 'SaaS' 입니다. 규모의 경제 효과가 높지만 기능 및 SLA에 대해서는 한계가 존재하는 거죠. 중간의 칼럼 (호스팅과 클라우드 컴퓨팅)은 직접 구축 및 운영에 비해 SLA 제어에 대해서는 제어권이 약화되지만 규모의 경제 효과는 증가되는 것을 볼 수 있죠. 
4. 가상의 시나리오
이 시나리오 에서는 몇 개의 IT 자산은 원하는 독자적인 시스템을 직접 구축 하고 몇 개는 시장에서 통용되는 되는 방식을 그대로 사용하는 것입니다. 다시 말하면, 차별화가 필요한 자산은 집중적인 투자를 하고 (의료 진단 소프트웨어 등), 아주 일반적인, 즉 차별화 되지 않는 자산 (CRM, 이메일 등)은 시장에서 구입하여 사용하는 것이죠. 게다가 IT 자산은 직접 운영하고 보유하여, IT 환경에 대한 SLA를 직접 통제하는 방식을 의미합니다. 
이런 형태의 그림이 아주 일반적이지요. 하지만 대부분의 CIO 분들은 이런 형태가 이상적이지만, 너무 많은 예산이 차별화 되지 않는 솔루션에 사용된다고 이야기 합니다.
결국 바라는 모습은 이런 겁니다. 
이메일과 CRM은 차별화 되기 쉽지 않고, 규모의 경제를 보장 받으면서 SLA와 기능에 대해 Trade Off하는 거죠. 직접 개발된 리거시 HR 시스템의 경우 기능면에서 규모의 경제를 보장 받는 형태로 전환되면서 SLA에 대한 보장 및 데이터 보안이 필요하다면 내부에서 운영되도록 할 수 있습니다. 의료 진단 소프트웨어의 경우는 차별화되어 경쟁력을 보유할 필요가 있으므로 기존 보다 2배 정도의 예산을 투자하여 뛰어나게 개발하는 겁니다. (다른 쪽에서 비용을 절감했기에 여기에 더 많은 예산을 쓸 수 있다는 거죠)
목적은 분명합니다. 컨트롤을 유지하면서 규모의 경제를 보장 받는 형태로 자산을 배치시키는 방향을 취하면 됩니다.
케즘을 넘어서 ... 
말이 쉽지 사실 직접 행동하는 건 쉽지 않죠.
Geoffrey A. Moore의 책에서 나온 말을 인용해보죠. 소프트웨어를 넘어서 클라우드로는 "케즘을 넘어서..."와 비슷합니다. 이 케즘은 아키텍트가 마스터해서 넘겨야 하는 거죠. 아키텍처가 당면한 도전과제는 다양합니다.
첫째, 아이덴티티
둘째, 관리
셋째, 데이터 입니다.
아이덴티티의 경우 크로스 바운더리상의 인증과 권한, 싱글 사인 온, 아이덴티티 라이프 사이클 등이며 관리는 방화벽을 넘어서 SLA 모니터링과 소프트웨어 액션 트리거링 (Halting, Pausing, Throttling) 할 것인지에 대한 것과 데이터의 소유권, 데이터의 이전 및 리포팅과 프라이버시 등입니다.
클라우드 컴퓨팅에 대해서 모든 답을 다 가지고 있는 사람은 없을 것입니다. 여러가지 방향으로 좋은 아키텍트 및 해결책을 찾으려고 노력하고 있다는 것이 적절한 표현일 것입니다. 앞으로는 위에 언급한 3가지 도전과제에 대해 좀 더 상세히 다루어 보려고 합니다. 그리고, 마이크로소프트가 공개한 S+S 어플리케이션 LitwareHR2에 대한 아키텍처 및 코드에 대한 부분을 다음 글에 다루어 보도록 하겠습니다.
"마이크로소프트 Gianpaolo의 블로그에서 가져왔습니다."
아키텍트2008. 7. 16. 11:39
