거버넌스(Governance)라는 용어는 국가 운영과 비즈니스 분야에서 출발해서 최근 IT분야에도 많이 등장하는 용어다. 우리 말로는 지배구조라는 말로 번역되어 사용되고 있는 것으로 볼 때, 거버넌스는 조직의 의도(Intention)나 기대치(Expectation)을 달성하기 위해 내부를 얼마나 잘 ‘장악’하는가의 능력으로 해석할 수 있겠다.
IT분야에 거버넌스를 적용한다면, 사용자가 원하는 IT 제공(delivery)의 기대치를 달성하기 위해, IT조직이 내부의 ‘인력’, ‘프로세스’ 및 ‘구성 요소’(CI-Configuration items 또는 components)를 운영하는 능력이라고 볼 수 있다.
여기서 구성 요소는 IT를 생산해내는 인프라인 서버, 네트워크, 및 소프트웨어 등을 가리킨다.
‘인력’과 ‘프로세스’의 문제로 인해 발생하는 IT 지배구조의 어려움도 있겠지만, 국내 IT조직을 관찰한 결과, IT 운영의 기본이 되는 ‘구성 요소’를 지배하지 못해서 발생하는 문제점들이 더 많다는 사실을 알게 되었다.
다소 무형에 가까운(intangible) ‘인력과 프로세스 통제’의 어려움을 호소하는 IT조직들을 볼 때마다, 좀 더 통제가 쉬운 ‘유형(tangible)의 구성 요소’들은 제대로 관리하고 있을까 하는 의심이 드는 것은 이 때문이다. 이번 컬럼에서는 IT조직을 지배하는 데 필수적인 구성 요소들을 제대로 장악하고 있지 못하는 IT조직들에 대해 이야기 해보겠다.
■ 구성요소의 ‘정보’란 무엇인가?
구성요소를 인간사회에 빗대어 본다면, IT세상에 존재하는 ‘사람’과 같다. 사람은 인간사회에 태어나서 성숙해지고, 사회에 기여하는 나름의 ‘용도’를 가지고(살짝 찔리는 분들이 있을까?)있으며 용도가 다 하는 경우 ‘은퇴’하고 ‘폐기’된다.
구성요소도 IT조직에 들어옴으로써 탄생되고, 성숙과정에서 확장되거나 축소, 또는 변화가 일어나고, IT에 기여하는 ‘용도’가 있으며 용도가 다하는 경우 ‘은퇴’하고 ‘폐기’된다.
구성요소는 사람과 마찬가지로 부모(parents CI), 자식(child CI) 및 동료(related CI)와의 관계(relationship)도 가지고 있다. ‘ERP어플리케이션 서버’를 구성요소의 예를 든다면 부모는 ‘ERP어플리케이션’이 되겠고, 자식은 ERP서버에 딸려있는 ‘백업장치’이며 동료는 ‘ERP 데이터베이스 서버’나 연결관계가 있는 ‘인사 서버’로 볼 수 있다.
또 구성요소는 사람의 이력서 격인 ‘변경 이력’(change history)을 가지고 있으며 사회에 문제를 일으킨 사람이 가지게 되는 ‘전과 경력’에 해당하는 ‘장애 이력’(incident history)를 가지고 있다. 구성요소의 ‘정보’란 위와 같은 구성요소의 라이프사이클 정보, 관계 정보와 이력 정보들을 가리킨다.
IT에서는 위와 같은 구성요소의 정보들을 총칭해서 구성데이터베이스(CMDB, Configuration management Database)*라고 부른다. 구성 데이터베이스의 목적은 결국 IT환경 내에서 구성요소들이 문제를 일으키지 않고 잘 살아갈 수 있도록 보장하기 위해서, IT환경을 지배하는 IT조직에게 구성요소들의 상세 정보를 제공하는 것이라고 볼 수 있다.
■ 부실한 구성데이터베이스로 유발하는 피해들
부실한 구성데이터베이스는 IT조직과 사용자들에게 피해를 입힌다. 당연한 이야기가 되겠지만 가장 대표적인 피해는 IT를 사용하지 못하게 만드는 ‘장애’들이다.
구성데이터베이스의 부실이 원인이 되어 발생한 장애의 사례들은 아래와 같다.
-인사 서버에 대한 패치작업을 수행 했는데 다음날 ERP어플리케이션에 로그인 되지 않는 장애가 발생하는 경우
-업무시간 중에 발생한 재무 서버의 장애를 해결하기 위해 재무서버에 대한 리부팅을 긴급하게 시도했는데 엉뚱하게도 영업 어플리케이션이 작동하지 않는 추가적인 장애가 발생하는 경우
-사용자 정보 데이터베이스의 특정 테이블을 지웠는데 여러 어플리케이션의 장애가 동시에 발생하는 경우
위의 장애 사례들은 구성데이터베이스 중 특히 ‘관계’ 정보와 ‘변경/장애 이력’ 정보를 IT조직이 잘 몰라서 발생한 것이라고 이해하면 된다. 구성 데이터베이스의 부실로 인해 발생하는 또 다른 피해는, 장애의 신속한 대응을 불가능하게 한다는 점이다. 장애가 발생한 경우, IT장애대응팀이 장애 해결을 위한 초동 단계에서 긴급하게 수행해야 하는 일이 있다.
장애와 관련 있는 ‘구성요소들’을 확인하고, 확인된 구성요소들의 구성데이터베이스를 조회하여 ‘변경/장애이력’ 정보를 우선적으로 확인하는 일이다. 장애의 ‘전과’가 있는 구성요소들이 다시 장애를 유발하는 경우가 많다는 사실과 구성요소의 확장, 축소 및 용도 변경의 결과로 장애가 발생할 가능성이 높다는 것을 IT장애대응팀은 경험적으로 잘 알고 있다.
부실한 구성데이터베이스를 가진 IT조직은 장애의 초동 단계에서 확인할 수 있는 정보가 없거나 부족하기 때문에 장애에 대한 대응이 그만큼 늦을 수 밖에 없다.
■ 자산관리시스템이 구성요소 정보다?
간혹 구성데이터베이스가 있는가라는 질문에 ‘자산관리시스템’을 내미는 IT조직들을 만나게 된다.
자산관리시스템은 IT조직의 재무적인 관점에서 IT자산을 관리하기 위한 용도이지, 구성요소의 이력정보와 관계의 정보를 담고 있는 구성데이터베이스는 아니다.
즉, 자산관리시스템이 제공하는 정보는 구성데이터베이스의 참조정보는 될 수 있겠지만 그것만으로 구성데이터베이스의 용도를 달성하기는 불가능하다.
전형적인 자산관리시스템을 구성데이터베이스로 ‘오용’하고 있는 IT조직들은 구성요소의 이력 및 관계 정보가 없는 ‘절름발이’ 구성데이터베이스를 가지고 있다고 볼 수 있다.
■ 숨겨져 있거나 조각난 구성데이터베이스를 가진 IT조직
전통적인 IT조직은 구성요소 정보를 IT담당자 개인이 소유해 왔다. 구성요소가 탄생하는 시점, 예를 든다면 IT프로젝트의 ‘중간 과정’이나 ‘종료 시점’에, 해당 프로젝트의 담당자가 구성요소의 관계와 이력정보를 시스템 구성도의 형태로 보유하고 있는 것이다.
구성데이터베이스의 개념이 정착되지 않은 IT조직들은 이처럼 프로젝트 담당자의 PC에 숨겨져 있거나 흩어져 있는 구성요소의 정보로 인해 고통을 받아왔다. 프로젝트 담당자가 오랜 시간 그 조직에 근무한다는 보장도 없으며, 또 프로젝트 담당자의 업무가 바뀌는 과정에서 그나마 가지고 있던 구성요소 정보가 날라가 버리기 때문이다.
프로젝트가 많고 인력 변동이 심하며, 체계적인 업무 인수 인계 문화가 없는 IT조직일수록 이와 같은 문제는 더 심각하다. (구성데이터베이스 유지를 포기한 IT조직도 본 적이 있다!)
설령 구성요소 정보를 IT담당자가 유지하고 있다 하더라도, ‘독점’적인 방법으로 소유하고 있다면, 최신의 구성요소 정보를 잘 유지하고 있는지는 IT담당자 개인의 부지런함에 의존할 수 밖에 없으며, 해당 정보를 필요로 하는 다른 IT담당자에게 ‘적시’에 전달될 가능성이 매우 낮다.
■ 힘들지만 어차피 해야 할일
구성데이터베이스 없이도 지금까지 잘 살아왔다는 IT조직의 무용담은 지금도 가끔 듣고 있다. 하지 않으려는 변명은 수 천 가지가 넘는 법이다. IT내부의 구성요소 조차 지배하지 못하면서, 사용자들에게 IT 수준이나 IT대가의 정당성을 꺼내는 것은 전문가 집단인 IT조직에게는 다소 수치스러운 면이 있다.
경제도 어렵고 구조조정의 화살이 어디를 향하고 있을 지 모르는 이 어려운 시기에, IT조직이 까다롭고 많은 노력이 필요한 구성데이터베이스 구현을 결심하기란 쉽지 않다. 하지만 IT내부의 완벽한 지배구조를 정착하고 IT전문가 조직의 위상을 달성하기 위해서는 튼실한 구성 데이터베이스가 기반이 된다는 점을 IT조직들은 명심할 필요가 있다.
*본 칼럼 내용은 본지 편집방향과 다를 수 있습니다.
