자율 컴퓨팅

자율 컴퓨팅, “꿈인가 현실인가”

자체 예상· 최적화 능력 필수 …기반 요건 먼저 확인해야

5년 전 IBM의 폴 혼은 정보 기술에 대한 생각에 새로운 길을 열었다. 우리가 과연 진정한 진보를 이룬 것일까, 아니면 단순히 과대선전에 장단을 맞춰 흥분에 들떠 있을 뿐일까?

시스템이 더 이상 비즈니스 니즈를 지원하지 못하는 지점까지, 혹은 심지어 유지가 불가능한 지점까지 이르렀는가? 복잡한 SOA(Service Oriented Architecture)와 VoIP 같은 컨버지드 애플리케이션이 보편화되면서, IT는 맞춤식으로 제작된 비공식적인 스크립트를 이용해 점 대 점 기반에서 너무 많은 애플리케이션을 통합시킨 데 대한 대가를 치르고 있다. 그 결과 구조화되지 않은(unstructured) 절차상의 행동으로 인해 노동 비용이 부풀려지고 고객 관계를 향상시키는 데 전혀 도움이 되지 않는 유연성 없는 서비스 전송 인프라가 생겨났다.
자율 컴퓨팅에 대한 폴 혼의 위대한 비전은 어떻게 된 것일까? 간단히 말하자면 이 업계는 자율화의 목적에 대해 립 서비스를 계속하면서 거의 아무런 저항도 없이 전술적인 문제 해결에만 치중한 채, 자가 치료 시스템을 확보하는 데 필요한 힘든 작업은 미뤄오는 경우가 너무나 많았다.
태도를 바꿀 준비가 된 사람들에게는 일군의 소프트웨어 중소업체들과 함께 CA, HP 및 MS가 IBM에 합류해 실질적인 IT 과제를 해결하는 데 앞장서고 있다는 반가운 소식이 있다. 하지만 회사에서 자율 컴퓨팅이 먹히게 하기 위해서는 회사의 환경과 비즈니스 목표, 기술 필요조건, 그리고 기존의 프로세스 및 워크플로우를 제대로 이해해야 한다. 약간의 자체 지식만 갖추고 있으면 기업에서는 큰 절감 효과를 얻을 수 있다.
사실상 우리는 IT그룹이 화재 진압 상태에 머무르는 것을 비난만 할 수는 없다. 가속화되는 비즈니스 수요가 모든 규모의 조직에서 예산과 기술적 재량에 압박을 가하고 있기 때문이다.
늘어나는 복잡성은 새삼스러운 것은 아니지만 그 속도가 최근에는 부쩍 더해졌으며, 프로세스를 수동으로 만들고 이행하는 프로세스가 너무나 노동 집약적이고 비실용적인 경우도 많다. 즉 이것은 종종 자기 보존적인 차원이다. 그리고 시간도 우리 편이 아니다. 기간 비즈니스 서비스가 인프라에 의존하면서 고장과 다운타임에 대한 비즈니스 내구성을 떨어뜨리고 있기 때문이다.
이에 대응해 일부 기업에서는 IT 프로세스와 최적화된 서비스 관리로 시선을 돌리고 있는데, 이것은 ITIL(IT Infrastructure Library)에 대한 늘어나는 관심으로 입증되고 있다. ITIL 프레임워크를 사용해, 업체들은 반복적이고 에러 발생률이 높은 사건 관리 부문에서의 인간의 개입을 대폭적으로 줄일 수 있는 자동 프로세스를 개발하고 있다. 하지만 ITIL은 솔루션의 한 부분에 불과하다.

자율 시스템이란?
IT 업계에서는 자동 컴퓨팅을 결정짓는 핵심적인 구성요소들로 다음과 같은 다섯 가지를 받아들이고 있다.

1. 사용자 개입이 없이 필요를 충족시키기 위해 시스템에서 최상의 자원을 예상해야 한다. 시스템은 늘 변화하는 상황에 따라 서비스를 역동적으로 구성 및 재구성할 수 있어야 한다.

2. 시스템은 계속해서 스스로를 최적화해야 한다. 즉 시스템은 사용자 개입이 없이 성능을 향상시키고, 용량을 최적화하며, 고객의 경험을 개선해 줄 방법을 언제나 모색해야 한다.

3. 시스템은 자체 컴포넌트를 이해할 수 있게 해주는 일정 수준의 자가 인지 능력을 갖추고 있어야 한다. 이것은 현재 상태와 용량 및 이용량을 가늠하고, 필요한 경우 용량 확장을 위해 다른 자원으로 액세스하는 데 있어 결정적인 능력이다.

4. 시스템은 성능 감소, 고장 및 보안 위협(늘 있는 것이든 갑작스런 사고든)이 사용자에게 최소한의 영향을 미치도록 자가 치료 능력을 갖추고 있어야 한다. 시스템은 이러한 문제를 탐지하고(발생하기 이전에 하는 게 이상적이다) 예방 조치를 취해야 한다.

5. 시스템은 외부 환경과 상호 작동할 수 있어야 하며, 개방형 표준을 기반으로 해야 한다. 여기에는 주변 환경에 대한 이해 능력과, 그 환경과의 커뮤니케이션 방법에 대한 새로운 정책 및 규정 생성 능력이 포함된다.

실질적 방안
자율 컴퓨팅 프로젝트의 성공에 있어 핵심적인 것은 현실적으로 전달이 될 수 있는 것에 대한 기대치를 일찌감치 잡아 두는 일이다. 조직의 운영적 성숙도를 엄격히 조사해 보라. 자동화가 실현이 되기 위해서는 네트워크와 서버 자산에 대한 구성 정보를 수집하고, 비즈니스 영향력 평가를 위해 고객 정보에 액세스하고, 내부와 외부의 SLA(Service Level Agreement)에 대한 데이터를 제공할 수 있는 능력이 반드시 자리를 잡고 있어야 한다.
만약 <그림: 조직의 성숙도>에서 ‘혼란’ 단계나 ‘사후 대응’ 단계에 있다면 기본적인 모니터링 및 관리 기능을 이행하고, 사건, 변경 및 구성 관리를 처리하는 공식적인 프로세스를 만듦으로서 큰 수확을 거둘 수 있다. ‘사전 예비’ 단계나 ‘서비스 기반’ 단계에 도달하고자 하는 조직들에게는 아이컨클루드(IConclude)의 옵스포스(OpsForce), 오팰리스(Opalis)의 인티그레이션 서버(Integration Server), 그리고 리얼옵스(RealOps)의 AMP 등의 제품들이 다음과 같은 목표를 달성하는 데 도움을 줄 것이다.

>> 서비스에 영향을 주는 고장을 줄이고 MTTR을 단축시키기 위해 모니터링 애플리케이션고 서비스 데스크간의 비즈니스 및 운영 프로세스 자동화

>> 일관성 있는 운영적 워크플로우 기반을 포함해, 조직의 여러 부문들간에 확장이 되는 서비스 중심의 IT 전략 개발

>> 작동화된 워크플로우나 시각적 지침을 통해 에러 발생 확률이 높고 수동으로 반복해야 하는 작업 부하 경감

>> 네트워크와 애플리케이션 인프라 내에서 흔한 문제에 미리 규정된 해결 단계 적용
>> 프로비저닝, 주문 입력, 빌링 및 모니터링 등과 같은 기간 시스템에 표준화된 통합 지점을 제공하고, 이러한 시스템들간의 데이터 상호교환을 위한 자동 프로세스 개발

작업용 툴
자동 컴퓨팅에서 성과를 올리고자 하는 대부분의 업체들은 주로 ‘사후 대응’ 단계와 ‘사전 예비’ 단계 사이에 있는 규모가 큰 기술 의존적인 조직을 타깃으로 하고 있다. 이러한 기업들은 네트워크 및 애플리케이션 관리 툴에 막대한 투자를 하고 있지만, 사건, 구성 및 환경 변화를 관리하는 데 있어 그 운영팀에서는 여전히 수동 프로세스에 많은 의존을 하고 있다.
보다 중요한 것은 변화나 사건이 고객에게 어떤 영향을 미치는지, 그리고 기존의 서비스 레벨과 비즈니스 니즈를 기반으로 작업에 우선순위를 어떻게 정하는지를 결정하는 데 몇 분, 혹은 몇 시간이나 걸리는 일이 잦다는 것이다. 이런 조직들에게는 자동 컴퓨팅은 이행할 수 있는 현실이라기보다는 공상과학 영화에 더 가깝게 들릴 것이다.
하지만 반드시 그런 것은 아니다. IBM은 특히 문제 해결에 초점을 둔 오토나믹 컴퓨팅 툴키트(Autonomic Computing Toolkit)를 개발하고, 자사 전 제품 라인에 자율성을 통합시키고 있다.
CA와 HP 또한 이 시장 진입을 시도 중이다. HP의 어댑티브 엔터프라이즈(Adaptive Enterprise)는 웹 서비스 통합과 기업의 다른 웹 서비스와의 상호 작동을 강조하는 애플리케이션 인프라 배치에 초점을 두고 있다. CA의 경우 어떠한 애플리케이션 환경에서든 프로세스 스케줄링을 지원하고자 유니센터 엔터프라이즈 잡 매니지먼트(Unicenter Enterprise Job Management)를 이용해 교차 플랫폼 작업 관리 엔진과 에이전트를 가시화했다.
마이크로소프트의 마이크로소프트 다이내믹스(Microsoft Dynamics)라는 비즈니스 관리 애플리케이션은 시스템 데이터를 기반으로 보다 나은 의사결정을 내릴 수 있도록 비즈니스를 지원하는 것을 목표로 한다.
대형 아키텍처를 받아들일 준비가 제대로 되지 않은 회사들을 대상으로, 지난 2년간 보다 작은 소프트웨어 업체들이 운영 센터의 일일 과제들을 해결하는 일을 맡아 나서고 있다. 예를 들어 아이컨클루드, 오팰리스 및 리얼옵스 제품들은 폭넓은 애플리케이션 문제 해결을 제공하며, 네트워크 및 보안 관리 기능을 최적화해준다.
모든 주요 프레임워크에서 공통되는 개념은 끊김없이 통합된 IT 환경을 만듦으로써 데이터가 정보 사이들간에 수집이 될 수 있게 한다는 것이다. 보다 낮은 레벨의 애플리케이션 배후에 있는 아키텍처적인 개념도 마찬가지다. 이들은 문제 해결에 역점을 두기 때문에 보통 모니터링 소프트웨어와 인프라 사이에 위치하며, 모두가 시스템 모니터링 툴과 서비스 데스크 애플리케이션에의 기존 투자를 기반으로 구축이 된다. 그리고 이것이 바로 이들이 성숙도에서 ‘사후 대응’ 단계에 있는 조직에게 별 도움이 되지 않는 이유다.
IT에서 원하는 특정 워크플로우를 정하고 나면, 애플리케이션은 각 사건에 대한 프로시저를 실행한다. 그러면 IT는 자동화된 방식이나 시각적으로 안내되는 프로세스를 통해 경보가 발생된다. 프로시저에는 경보의 확인응답, 새로운 장애 티켓 제작, 미리 지정된 특정 장애관리 테스트 수행, 가능한 경우 복구 작업 수행, 그리고 마지막으로 티켓을 종료하고 경보를 소각하는 것이 포함된다.
적절히 이행될 경우 이러한 애플리케이션은 생산 지원 스태프 비용을 줄여주고, 에러율을 감소시키며, 프로세스 완료 시간을 개선해 준다. 보다 중요한 것은 이들이 조직을 비즈니스의 엔터프라이즈 레벨 뷰로 이동시킨다는 것이다. 예를 들어 온라인 임원진 게시판(online executive dashboard)은 핵심 프로세스 관점의 맥락에서 이행이 될 때 실시간 서비스 보증 정보에 대한 집중적이고 행동 가능한 뷰를 제공한다.
운영 관리 업계에서처럼 우리는 자율 컴퓨팅 시장에 승부수를 건 소프트웨어 대기업들이 혁신적인 중소기업을 흡수함에 따라 향후 몇 년간 엄청난 혁신과 통합을 보게 될 것 같다.
하지만 이러한 이동은 분명 그럴만한 가치가 있다. 자동화 이니셔티브를 주도하는 IT 임원들은 조직 내에서 변화의 주역이 될 것이다. 자율 컴퓨팅의 비전은 이미 충분하다. 이것이 제대로 실현만 된다면 복잡한 관리를 늘리리 않으면서 사람들이 코어 비즈니스에 집중할 수 있게 해줌으로써 IT그룹과 비즈니스에 엄청난 영향을 미치게 될 것이다.

잠자는 숲속의 미녀
겉으로 보기에는 그리 복잡해 보이지 않으면서도 IT 스태프에게 큰 영향을 미칠 수가 있는 자동화 기능들이 있다. 예를 들어 시스템 관리자가 매일 새벽 한 시에 일어나 백업을 원격으로 시작해야 하는 조직이 있었다. 이제 이 회사에서는 오팰리스 인티그레이션 서버를 이용해 이 작업을 자동화하고, 프로세스 중 잘못되는 것이 있으면 수정을 하고 있다.

달아나는 비용을 체포하라
유럽의 전자 물류 솔루션 사업자인 트랜스포레온(Transporeon)은 사용자 계정 추가, 백업 수행 및 HTML 유지보수 보고서 만들기와 같이 반복되는 내부의 IT 작업을 돕기 위해 아이컨클루드의 옵스포스를 이용해 십여 개의 프로세스 플로를 개발하고 있다. 옵스포스는 생산성을 향상시키고 총 유지보수 비용을 40% 이상 절감시켰다. 그 결과 이제 핵심 자원들은 보다 빠른 응답 시간을 끌어내고 고객 만족도를 향상시키고 있다.

소프트웨어 선택시 체크리스트

노동 집약적이기 마련인 프로세스를 자동화한다는 개념 자체는 전혀 잘못된 게 없지만, 기반 서비스 프로세스가 비효율적이거나 완전히 기능장애를 일으킬 경우에는 실질적으로 오랫동안 이점을 누리기가 힘들다.
성공적인 자동화 전략을 위해서는 인프라의 기술적 측면뿐만 아니라 변화, 구성, 사건, 릴리즈 및 문제 관리와 같은 서비스 전달에 포함되는 운영 프로세스까지 다뤄져야 한다. 조직에서는 자동화 기술과 보조를 맞춰 운영 프로세스와 워크플로우를 배치해야 한다. 그리고 이렇게 되기 위해서는 IT에서 비즈니스를 이끄는 것들과 필요조건을 제대로 이해하고 있어야 한다. 소프트웨어를 선택할 때는 다음 사항들을 확인해 보라.

>> 내 조직이 준비가 됐는가?
프로세스를 자동화하기 위해 필요한 기반 애플리케이션이 제대로 갖춰져 있는가? 아니면 예를 들어 성능이나 구성 관리에서 채워 넣어야 할 빈틈이 있는가? 교차 플랫폼 애플리케이션 통합과 문제 해결을 찾기 이전에 이 점을 만드시 확인해야 한다.

>> 내 프로세스를 개발 및 변경하는 데 소프트웨어가 어떤 종류의 인터페이스를 제공하는가?
직원이 프로세스를 만들거나 관리하기 위해 복잡한 언어를 배워야 하는 일은 피하고 싶을 것이다. 인터페이스가 간편한 워크플로우로 구축 및 변경을 지원하지 못한다면 관리가 괴로워진다.

>> 내 애플리케이션용으로 미리 구축된 접속은 어떤 게 있는가?
통신을 해야 하는 애플리케이션의 체크리스트를 만들고, 자동화 프레임워크에 사전 구축된 접속이 있는지 확인하라. 접속이 없다면 업체에서 이것을 당신을 위해 만들고 유지보수해주는지 알아 봐야 한다.

>> 자동화된 컴퓨팅 환경으로 접속해야 하는 모든 애플리케이션을 당신이 제어하는가?
조직들은 이것을 사일로에게 넘기는 경우가 종종 있다. 서비스 데스크 애플리케이션을 제어하는 그룹에서 당신이 이것을 자동화 소프트웨어와 연결하지 못하게 한다면 어떻게 하겠는가?

>> 자동화 소프트웨어의 확장성은 어떠한가?
업체측에서 제품이 양적으로나 프로세스적으로 확장될 수 있는 능력뿐만 아니라, 다중 애플리케이션에 접속할 수 있는 능력을 시연해 보였는가? 분산된 데이터 센터를 갖고 있다면 소프트웨어가 다중 센터와 분산된 애플리케이션을 어떻게 처리하는가?

>> 자동화 소프트웨어에 문제 해결용으로 사전 제작된 프로세스가 많이 포함돼 있는가?
이런 것들은 아주 멋진 출발점이 될 수 있지만, 당신의 특수한 비즈니스 규정과 정책에 맞추기 위해 이런 프로시저를 얼마나 맞춤화시켜야 하는지도 확인해야 한다. 업체측에서 프로세스 맞춤화를 위해 얼마나 많은 지원을 해줄 수 있는가?

>> 당신에게 있는 제품이나 툴을 이용해 얼마간의 자동화를 이룰 수 있는가?
오늘날의 많은 네트워크 관리 애플리케이션에는 예를 들어 접속이 미리 만들어진 워크플로우 엔진이 포함돼 있다. 새 툴에 투자를 하기보다 기존 제품들 가운데 하나를 확장시켜서 자체 워크플로우를 만들고 즉각적인 회수 효과를 기대할 수 있다.

결론적으로 말하자면, IT 관리자는 더 많은 혼란 속에 빠지지 않는다는 확신을 갖고 있어야 한다. 자동화 시스템의 목표는 덜 복잡하게 하자는 것이지, 직원이 새 툴과 프로그래밍 언어를 배워야 하고, 일상의 유지보수 작업에 또 하나의 단계를 추가함으로써 더 복잡하게 하자는 게 아니라는 사실을 명심하라.

데이터넷