[지디넷코리아]이른바 ‘복잡성 관리’는 기업 내 비용 절감의 핵심을 차지하고 있다. 여기에는 단순히 획득 비용 뿐 아니라 솔루션의 장기적 영향, 그리고 연계 비용에 대해 정직한 평가가 이뤄져야 한다.

시스템과 네트워크에서 복잡성 수준이 균형을 이루도록 해야 한다는 말은 구성이 복잡해짐에 따라 발생하는 비용을 관리해야 한다는 뜻이다. 보통 복잡성을 유발하는 요소가 무엇인지 찾아내는 과정에서 이익이 무엇인지도 알아낼 수 있다.

예를 들어 보자. 본인은 15년 전 IBM AS/400을 주 시스템으로 사용하고 있었기 때문에 토큰링(Token Ring) 환경을 이용하고 있었다. 이 때 소규모 광채널이 길거리를 통과해 공장까지 닿게 해야 하는 상황에 직면하게 됐다. 당시 토큰링을 사용해 이런 네트워크를 구성하려면 비용이 많이 들었기 때문에 결국 이더넷(10Base-T)를 추가해 토큰링 대신 사용하게 됐다.

이더넷을 도입함으로써 당장 몇 천 달러를 절약할 수 있었지만 기술직 직원들에게 타입 A/타입 1 STP(Shielded Twisted Pair) 토큰링 케이블 제작법뿐 아니라 이더넷 케이블의 선 배열하는 법, RJ-45 커넥터를 찍는 법 등을 가르쳐야 했다. 하지만 당시 IT 분야에서는 이더넷이 대세를 굳혀가고 있었으며 어쨌든 우리도 언젠가는 옮겨가야 했다.

바로 이런 과정이 소위 결정이라는 것이다. 우리는 매년 몇 백 개씩 이와 같은 결정을 해야 하며 결정을 내릴 때마다 환경은 복잡해진다. 구매 모델의 재고가 떨어져 다른 모델의 네트워크 스위치를 사야 하는 일은 비일비재하며 급하게 스위치를 새로 구매할 경우도 존재한다.

따라서 결정을 내릴 때마다 환경이 복잡해지더라도 비용은 절감된다는 측면을 정당화할 수 있는지 평가해야 하는 것이다.

균형에 따른 수요를 이해하라
시스템 아키텍트가 관리 작업을 더 이상 감당할 수 없다고 말하기 직전까지 시스템과 네트워크가 복잡한 상황으로 치닫는 것은 자연스런 현상이다. 이런 상황에 직면하면 비로소 푸시백(pushback)이 시작된다. 즉 복잡성에 대한 저항이 나타나기 시작한다는 의미다.

복잡성에 대한 불만은 종종 상당히 빨리 나타나기도 한다. 솔루션이 전보다 복잡해지면 조직의 관심이 아무리 커도 구축이 꺼려지는 것이 사실이다. 하지만 그 반대도 보통 사실이다. 뭔가가 너무 복잡해지면 환경을 관리하는 데 불필요한 일 또한 만들어지게 된다. 환경에 대해 적절한 복잡성 유지 요령을 터득하는 것 또한 비용을 줄이는 데 필수적이다.

복잡성, 무조건 기피해도 좋지 않다
복잡해지는 걸 피하려고만 하면 다른 가치있는 선택을 찾지 못하게 된다. 복잡성이 늘어날 가능성이 있다 해도 아직 만들어진 바 없는 네트워크나 아키텍처에 부딪혀보자. 문제를 항상 우아하게 해결하는 게 목표이긴 하지만 계획하는 바에서 흠 하나 찾을 수 없다면 그 또한 실현성이 없거나 아직 검증되지 않은 것일 것이다.

하지만 본인이 선호하며 세세히 파악하고 있는, 단순한 환경에 딱 맞춰 안주하려는 사람들이 있다. 노벨 제품만 갖고 일하는 회사는 MS 윈도우 서버를 쓸 수밖에 없다는 주장이 제기돼 어쩔 수 없이 사용해야만 하는 때가 오기 이전까지는 꿋꿋하게 버틴다.

어떤 회사는 그래픽 부서에서 매킨토시로 작업하도록 바꿀 수 있고, 이로 인해 문제 또한 줄일 수 있음에도 불구하고 전 부서에서 MS 윈도우만을 쓰도록 고집하기도 한다.

이런 사례는 너무 순수하게 단순함만을 고집하는 경우다. 최상의 솔루션에 기반을 둔 요소를 결정하는 대신, 나와 나 자신에게 익숙한 환경에서 최상의 솔루션이 무엇인지 묻고 그에 따라 결정하는 것이다. 우리가 잘 알고 있고 이해하고 있는 것만으로 한정을 두고 복잡성을 외면하는 것은 말 그대로 하나의 방안에 지나지 않는다.

복잡하게, 나만 알수 있도록 매우 복잡하게
반면 지금까지 얘기했던 것과는 완전히 반대로 환경이 얼마나 복잡해질지 개의치 않고 새로운 걸 시도하려는 관리자들도 있다. 그들이 갖고 있는 관점은, 관리자인 자신이 기술을 알고 이해하고 있다면 모든 사람들도 그래야만 한다는 것이다. 이들은 보통 자신들이 관리하는 환경에 서로 다른 하드웨어와 소프트웨어를 산재시켜 놓는다.

이들이 보유한 라우터와 스위치는 구매할 당시 모두 저렴했던 것들로만 이뤄져 있다. 그리고 이들은 사내용 웹서버와 같이 비교적 사소한 작업에 사용하는 서버 운영체제로 리눅스를 사용하기도 한다. 라우터, 스위치, 심지어 운영체제를 새로 추가하는 일이 다른 사람들에겐 복잡하더라도 자신에게는 그렇지 않다는 결론이 나면 이 관리자들은 결코 두려워하지 않는다.

이런 상황은 두가지로 표현할 수 있다. 하나는 자존심이 있다는 것이고 또 하나는 자신의 일자리를 보호하려는 행위라는 점이다. 자존심이란 “나는 이걸 할 수 있는 유일한 사람이다”라는 것이며 보호하는 행위란 “그들이 나를 어떻게 대신할 수 있겠어? 내가 이걸 어떻게 하는지 아무도 이해할 수 없잖아”라는 거다.

양쪽 모두 대규모 시스템에서는 매우 위험한 생각이다. “누구든지 할 수 있다”라는 표현을 쓸 수 있어야 더 적절한 것이다. 대형 시스템의 핵심은 지속가능성이며, 그렇게 하려면 시스템을 이해하는 사람이 최소한 한 명 이상이 있어야 한다.

적절한 대응은 교육과 지원 비용을 평가해보고 복잡해지는 게 합리적인지를 따져본 후 결정을 내리는 것이다. 평가가 이뤄져 복잡함을 받아들이겠다고 마음먹었다면 결정에 따르는 데 수반되는 위험과 비용을 완화시킬 필요가 있다.

복잡성 관리 비용 조정법
새로운 시스템 도입에 따른 교육비의 지출을 줄이려면 기존 시스템과 유사한 걸 찾는 게 가장 기초적인 방법이다. 동일 브랜드의 다른 모델을 의미할 수도 있고 대다수 시스템 사용자들에게 친숙한 브랜드의 모델을 의미할 수도 있다.

궁극적으로 우리의 목표는 서로 차이나는 부분을 줄이는 것이다. 예를 들어 평소에 넷기어 스위치와 라우터를 구매해왔다면 가능한 한 넷기어 스위치와 라우터를 추가하거나 다음에도 같은 브랜드 제품을 도입해야 한다. 만약 가능하지 않다면 일반 사용자 시장에 깊이 침투해 있는 링크시스 같은 솔루션을 찾아보는 것도 좋다. 대다수 IT 전문가들은 본 경험을 갖고 있을 것이다.

비용을 조정하는 다음 단계에서는 툴의 사용법과 이 환경에서 작업하게 될 것들을 미리 예상해 문서화하는 것이다. 컴포넌트의 역할을 확실히 정의한다면 사용법을 혼동하는 경우도 줄일 수 있을 것이다. 문서가 예쁠 필요는 없으며 분량이 많을 필요도 없다. 다만 지원과 문제 해결에 필요한 정보는 담고 있어야 하며 모든 솔루션의 기본 아키텍처 또한 문서화돼야 한다.

마지막으로 특히 어떤 환경이 연계될지 명확하지 않을 때 도움이 될 수 있도록 문서를 작성하면 지원 비용을 절약하는 데 큰 도움이 될 수 있다. 실속있는 문서에는 제품 이름, 버전, 펌웨어, 일련번호, 지원 계정 등이 들어있어야 한다. 문제가 발생한 경우 해결할 때까지 필요한 시간을 줄이는 데에도 문서는 필수적이다.

결론
복잡성 관리는 저비용의 핵심 요소다. 여기에는 획득 비용뿐 아니라 솔루션의 장기적 영향과 연계된 비용에 대해서도 엄밀하고 정직한 평가가 이뤄져야 한다. 확장에 대한 전략을 수립하라. @