[칼럼]변경이 발생하지 않는 IT조직?

IT분야에서 변경(change)은 IT구성요소인 인프라나 어플리케이션의 크고 작은 변화를 의미한다. IT가 변화하는 것은 그 나름대로의 이득이 있어서이다.

자연세계의 진화론처럼 IT도 사용자와 기술의 주변 환경 요구에 따라 순방향으로 변화하게 되는 것이다. 그런데 일부 IT조직은 변경이 아예 발생하지 않거나 매우 적다고 주장하는 경우를 경험한 적이 있다. 도대체 어찌된 영문일까?

변경을 억누르는 과거의 아픈 기억

변경이 발생하지 않는 IT조직은 대체로 ‘변경 실패’로 인한 아픈 기억을 가지고 있는 경우가 대부분이다. 좋은 의도로 변경을 시도했다가 오히려 IT 중단이 발생하여 사용자측으로부터 호된 비난을 받게 되면 변경에 대해 두려움을 가질 수 밖에 없다.

문제는 두려움을 대하는 IT조직의 자세이다. 두려움을 정면으로 맞서서 변경을 더 잘 다루어보겠다는 결심보다는 변경 자체가 아예 발생하지 않도록 회피 전략을 선택하는 것이다. 이혼의 아픈 상처가 ‘이성에 대한 회피’로 결론 난 것이다.

엄격한 변경 프로세스의 도입

변경에 대한 회피전략을 선택한 IT조직은 엄격한 변경 프로세스를 우선적으로 도입하게 된다. 변경 프로세스의 과정에 모든 IT관리자가 승인을 하도록 하고 변경이 완료될 때까지 10여 단계 이상을 절차를 거치도록 설계한다.

변경을 제기한 IT담당자는 변경에 대한 필요성과 이 변경이 실패 없이 안전하게 진행될 수 있다는 것을 엄격한 변경 프로세스 과정에서 충분하게 납득시켜야만 변경을 성사시킬 수 있다. 대부분의 변경을 IT담당자가 제기한다는 점을 감안한다면 변경의 통과가 정말 어려울 수 밖에 없다.

게다가 일부 IT조직은 변경의 통과 성공률을 개인이나 팀의 평가지표에 반영하고 있어 변경을 제기하는 것 조차 꺼리게 만들고 있다.

비공식적인 변경의 득세

IT조직에서 근무해 본 경험이 있는 사람은 변경이 발생하지 않고는 IT운영이 불가능하다는 사실을 잘 알고 있다. 엄격한 변경 프로세스로 인해 변경이 발생하지 않는 IT조직에서는 결국 비공식적인 변경의 ‘지하 세계’가 존재할 수 밖에 없다.

담당자가 판단해서 공식적으로 탄로나지 않을 정도의 변경은 임의로 진행해버리게 되고, 해당 담당자의 직계 관리자는 타 팀의 관리자가 눈치채지 않는다는 조건에서는 이를 눈감아주게 된다. 이러한 풍조는 암암리에 모든 IT부서에 만연하게 되고, 결국 엄격한 변경 프로세스를 가진 IT조직에서는 공식적인 변경이 거의 없게 되는 것이다.

심각해져만 가는 부작용들

비공식적인 변경을 수행하다가 장애가 발생하게 되면 어떤 문제가 발생할까?

장애로 인해 IT중단이 발생하게 되므로 사용자측에서는 장애 원인을 밝혀달라는 요구를 하게 된다. 이 IT조직은 자신들이 구현해놓은 엄격한 변경프로세스를 사용자측에 수시로 자랑해오던 터라, 이번 장애의 원인이 ‘몰래 수행한 변경’으로 초래한 것이라는 것을 실토하는 순간 모든 것을 잃는다고 생각하게 된다. 이때 IT조직이 선택할 수 있는 결론은 자명하다.

원인 불명의 장애!

왜 수준이 낮은 IT조직에 원인 불명의 장애가 많은지를 이해할 수 있는 대목이다. 거짓이 거짓을 낳는 악순환과 함께 IT조직의 운영상에도 문제가 발생한다.

비공식적인 변경을 진행하는 담당자는 구태여 변경 기록을 남기지 않는다. 변경 기록은 변경 대상이 되는 ‘IT 구성요소’의 일생을 추적할 수 있는 중요한 이력 정보이다. 이력 정보가 없는 IT구성요소들의 증가는 IT 관리 체계를 ‘불구’로 만든다. IT를 둘러싼 수 많은 사건사고들을 해결하기 위해서는 IT구성요소의 이력 정보를 파악하는 것이 최우선인데, 이것이 불가능하다는 것은 IT 관리의 붕괴를 의미한다.

ISO 국제표준(ISO/IEC 20000 IT서비스 관리 체계)과 ITIL에서는 변경과 구성요소 관리를 IT관리 체계의 중심으로 규정하고 있다.

꽃보다 변경

변경은 IT분야에서 매우 민감하고 두렵고 또, 어려운 존재다. 하지만 사용자 개선요구나 편의성 증대, 발생한 장애나 잠재적인 장애의 해결 및 IT운영의 효율화 등과 같은 긍정적인 이득을 얻기 위해서는 변경이 반드시 필요하다.

따라서 IT조직은 모든 변경에 대해서 자신감을 가져야 한다. 변경으로 인해 장애가 발생하더라도, 변경을 더 잘 처리할 수 있는 교훈을 얻을 수 있는 기회로 활용하면 된다. 모든 크고 작은 변경을 공개적으로 평가하고 기록해나간다면 변경에 대한 자신감과 IT 운영 성숙도가 더욱 높아지게 된다.