분석이 활동이 없는 IT조직들
최영석 BSI코리아 심사위원
[지디넷코리아] 살인의 추억 VS. CSI 과학수사대살인의 추억이라는 영화를 본 사람들은 영화에 등장하는 70 ~ 80년대 형사들의 모습들을 기억할 것이다. 과학 수사라는 건 찾아볼 수도 없고 형사 개인의 직감이나 경험에 의존하여 사건을 해결하느라 좌충우돌하는 우스꽝스런 과거 한국 경찰들의 자화상을 영화를 통해 그려내고 있다.
이에 반해 미국드라마의 열풍을 몰고 온 CSI 과학수사대에서의 경찰들은 과학 수사의 전형을 보여주고 있다. 증거를 찾고 기존의 데이터를 활용하여 분석함으로써 사건을 해결해나가는 모습은 비록 드라마이지만 감탄을 자아내게 한다. 물론 요즈음의 한국 경찰들은 다소 과학(?)적인 모습을 보이고 있어 그 당시와 비교하는 것은 무리가 있을 수 있다.
IT조직에서의 장애 해결 관행IT내에서도 많은 사건(Incident)들이 발생한다. 우리는 그런 사건들 중 IT사용을 불가능하게 만드는 사건들을 ‘장애’라는 이름으로 부른다.
IT에서 장애라는 사건이 발생하면 위에서 언급한 경찰들처럼 장애를 대응하기 위해 IT담당자들이 출동(!)을 하게 되고 우선 장애 상황을 벗어나기 위해 혼수상태에 빠진 IT시스템(i.e. 서버, 네트워크 장비 또는 어플리케이션)을 살리기 위한 여러 가지 시도를 하게 된다. 노력 끝에 IT가 정상상태로 돌아오게 되면 장애라는 사건은 공식적으로 종료된다. 문제는 장애가 발생하고 종료되기까지 IT조직이 과학수사와 같은 데이터에 근거한 분석 기법을 활용하여 해결하고 있는가라는 점이다.
장애를 해결하기까지 경황이 없다는 것을 감안한다면 IT의 정상화 이후에라도 장애라는 사건을 재조사하여 근본원인을 찾아내고 재발 방지를 위해 데이터로 재활용하고 있는지 생각해볼 일이다.
IT를 사용하거나 IT 외부에서 바라보는 사람들은 뭔지는 모르겠지만 IT조직이 과학적인 방법을 사용하여 장애를 대응하지 않을까 생각하겠지만 실상은 그렇지 않은 IT조직들이 많다는 것을 조심스럽게 알려야 하겠다.
분석 활동이 없는 국내 IT조직들국내 IT조직을 관찰해 본 경험에 의하면 국내에서 내로라하는 일부 IT전문기업을 제외하면 대부분의 IT조직이 분석에 근거하여 IT업무를 수행한다고 보기가 어렵다.
장애가 발생하여 IT사용이 불가능하게 되면 IT사용자측(i.e. IT사용자, IT를 관리하는 부서 및 IT에 직간접적으로 영향을 받는 외부 협력 조직)에서 워낙 불같이 일어나게 되고 관심을 가지게 되므로 IT조직은 장애 상황을 어쨌든 벗어나기 위해 안간힘을 쓰게 된다.
이 과정에서 IT조직은 여러 가지 방법을 사용하게 된다. 그런데 IT조직이 장애 발생 이후에 작성한 장애 기록들을 검토해 보면 장애 해결 과정에서 장애의 정황 파악이나 해결 방안을 찾아내기 위해 데이터 자료를 활용하거나 체계화된 분석 방법을 적용한 사례를 찾아보기가 어렵다.
장애 상황을 어쨌든 빨리 벗어나 IT사용자측의 비난을 모면하고자 하는 목적으로 IT조직은 장애 해결을 위해 임시방편(work-around*)을 사용하는 경우가 대부분이다. 대표적인 임시방편의 하나가 시스템 재가동 즉, ‘껐다 켜기’이다. 임시방편을 사용하여 장애를 해결하게 되면 대개 장애를 발생시킨 정황이나 증거가 깨끗하게 치워지게 된다.
교통사고에 비유한다면 교통사고의 정황과 원인 파악보다는 교통사고 현장을 빨리 정리해서 통행을 정상화시키는 데 집중하는 상황인 셈이다. 물론 교통사고 현장을 빨리 정리하는 것이나 임시방편을 사용해서 IT를 빨리 정상화시키는 것도 중요하겠지만 IT에 있어 이러한 상황은 결국 분석 활동을 구조적으로 불가능하게 만드는 악순환 체계를 제공한다.
분석 활동이 없는 IT조직들의 특징분석활동이 없는 IT조직들은 여러 가지 특징들을 보인다. 우선 IT 직원들의 일별 또는 월별업무 분포를 보면 분석 업무에 할당된 시간이 거의 없다. 대부분의 업무 시간이 수동적인(reactive) 업무를 하느라 소비하거나 실적이나 프로세스에 할당되지 않는 휘발성 IT 업무로 구성되어 있다.
업무실적을 담은 리포트에도 이러한 IT조직의 특징을 찾을 수 있다. 리포트의 대부분 내용이 신규 개발이나 도입 또는 설치 등에 관해서 언급하고 있어 분석 업무에 대해 관심이 없거나 가치를 부여하지 않는 것으로 여겨진다. 그 외에 분석 활동이 없는 IT조직들에서 다음과 같은 특징을 찾아 볼 수 있다.
-문서화나 기록을 경시한다.
-업무 노하우나 중요 자료들을 개인이 보유하고 있다.
-장애 기록이 부실하다.
-분석활동에 필요한 리소스 부족을 탓한다.
-외부 벤더에 의존한다.
IT조직의 체질을 바꾸기 위한 몇 가지 방법들첫째, 분석활동의 필요성을 IT조직내의 상위경영층에서 먼저 인정하고 IT직원들이 이를 받아들일 수 있도록 설득해야 한다. 분석 활동을 보장해주는 자원과 환경 조성은 이들 경영층의 몫이다.
분석활동이 중요하다고 하면서도 단기적이거나 눈에 당장 띄는 성과만을 요구하거나 장애 상황의 모면에만 관심을 가지는 IT조직내의 상위경영층이 있는 한 분석 활동이 IT조직 내에 정착되기는 요원하다.
둘째, 분석 활동을 IT조직내의 공식적인 프로세스로 인정하는 것이다. 지난 컬럼에서 언급한 것처럼 IT조직이 프로세스 중심으로 움직일 수 있도록 체계를 갖춘다고 한다면 그 프로세스 중에서 분석 활동을 보장하는 프로세스를 추가하여야 한다. 전통적인 장애 관리 활동(장애관리 프로세스라고 부르기는 부족하다.)을 고수해온 IT조직의 장애 보고서를 들여다보면 장애 보고서상에 장애의 ‘근본원인’이라는 항목이 있음에도 불구하고 작성된 장애리포트의 대부분이 공란이거나 ‘벤더에 의뢰 중’으로 기록되어 있다.
이를 해결하기 위해 ITIL과 ISO표준에서는 문제 관리 프로세스(Problem management process)의 도입을 제시하고 있다. 분석을 위한 프로세스를 공식적으로 도입하여 장애의 근본원인을 끝(!)까지 찾아내도록 보장할 수 있다.
◇IT에서의 분석도구들
셋째, 분석을 전담하는 팀 구성을 검토하는 것이다. IT조직 내에는 반복적인 업무를 선호하는 사람도 있고 깊게 파고 들어가서 분석하는 일을 좋아하는 사람도 있다. 경영의 입장에서 IT직원의 성향을 파악하고 이들 성향에 맞는 업무를 할당하는 것도 중요한 관리활동의 하나이다.
소규모 조직인 경우는 분석 활동에 관련된 업무와 수동적인(reactive) 업무를 IT직원이 동시에 수행할 수 밖에 없겠지만 어느 정도 규모가 되는 IT조직은 분석 활동을 전담해서 수행할 수 있는 인력으로 팀을 구성해서 분석활동에 전념하도록 하는 것도 시도해 볼만 하다.
이때 구성되는 팀은 꼭 물리적으로 보장되는 조직일 필요는 없다. IT업무의 요소 별 전문가들을 선정해 논리적인 팀의 일원으로 활동하게 하는 것도 잘 알려진 선진기업의 실행사례이다.
넷째, 사소한 것이라도 기록으로 남기는 기록 ‘중시’ 풍조를 만들어야 한다. 장애가 발생하여 대응하는 경우 해당 장애가 발생한 장비 담당자는 장애 해결을 위해 자신이 장비에 어떤 명령어를 사용했는지 어떤 로그를 조사했는지 언제 외부 벤더에 기술 의뢰를 했는지에 대해 기록해야 한다. 이것은 장애라는 사건의 전말을 이해하고 분석하는 데 결정적인 내용들이다.
하지만 대부분의 IT조직 내에서 장애 기록을 살펴보면 위와 같은 담당자의 상세 대응 내역은 고사하고 객관적인 사실 파악이 어려울 정도의 수준으로 작성되어 있는 경우가 많다. IT에 대한 변경* 작업도 마찬가지이다. 부실한 변경 작업 계획과 결과는 장애를 초래할 가능성이 많고 더군다나 장애가 발생해도 해당 작업자가 어떤 작업을 수행하다가 어떤 실수를 해서 장애가 발생했는지를 추적하기가 어렵다.
IT에 종사하는 사람들이 기술적인 능력에 비해 문서나 기록을 작성하는 실력(?)이 다소 떨어진다는 것은 IT 내 외부에서 묵시적으로 인정하는 사실이다. 그러나 문서화의 능력은 태어날 때부터 타고 나는 것이 아니라 습관이라는 점과 문서화를 잘 할 수 있도록 여러 가지의 사례나 템플리트의 개발을 병행한다면 효과를 볼 수 있다.
넷째, 스스로 해결하고자 하는 의지가 필요하다. IT를 구성하는 다양한 기술적인 요소들은 IT 직원이 스스로 개발한 것이 아니다. 예를 들면 서버나 네트워크 장비는 100% 외부의 벤더들에 의해 개발된 것들이다.
그러다 보니 장애가 발생하게 되면 장애를 조사하는 과정에서 외부 벤더들에게 지원을 요청하게 된다. 그러나 장애를 해결하는 주체는 IT조직 자신이어야 함에도 이를 전적으로 외부 벤더들에게 넘기는 태도를 보이는 IT조직들이 있다. 벤더들이 특정 고객만을 위해 지원하는 것에는 한계가 있을 수 밖에 없으며 해당 장애가 벤더의 제품 결함이라는 보장도 없기 때문에 대부분의 경우 벤더들은 IT조직의 운영상의 문제로 돌리거나 장기간 무 응답으로 대응하게 된다.
단 한번이라도 IT조직 스스로의 힘으로 장애를 분석하여 근본 문제점을 찾아내는 데 성공한 IT조직은 자신감과 더불어 분석능력의 일취월장을 경험하게 된다. 그 순간 IT조직은 벤더들보다 더 뛰어난 IT인력을 보유하게 되는 것이다.
