감사를 좋아하는 사람은 없다. 최상의 결과가 나온다 할지라도, 감사는 값진 시간을 요구한다. 문제가 발생한다면 DDoS 공격보다 빠르게 IT 리더의 한 주를 망칠 수 있다. 더 나아가 부정적인 IT 감사 결과는 CIO의 관리 역량과 '미래'를 부정적으로 물들일 수 있다..
그러나 걱정할 필요 없다. 이렇게 되지 않도록 만들면 되기 때문이다. 내부, 외부 감사팀이 IT인프라, 정책, 운영을 샅샅이 뒤질 때 ‘만사형통’이 되도록 만들 수 있다. 그러기 위해서는 감사를 준비하고, 더 나아가 성과에 대한 증거를 제시해야 한다.
가장 먼저 할 일이 있다. IT 감사에 있어 정말 많이 저지르는 실수를 피하는 것이다. 아래 주의사항을 경계하면, IT 감사가 ‘재앙’이 되는 것을 피할 수 있다.
-> 기술 자산에 대한 지식이 감사자보다 부족하다
-> 감사인의 요구를 들어 주기 위해 수동 프로세스를 이용한다
-> 소프트웨어 벤더의 감사에 도전할 수 있는 역량이 없다
-> 감사 결과에 따른 후속 행동이 늦다
-> 감사자와 사전에 관계를 구축하지 않는다
-> 직원들을 준비시키지 않는다
-> 감사 관여 및 협력 프로세스가 없다
-> 감사자를 ‘적’으로 대한다
-> 직원들의 발목을 잡는 복잡한 정책과 절차가 있다
-> 수 많은 예외는 스스로를 망치는 지름길
기술 자산에 대한 지식이 감사자보다 부족하다
부정적인 IT 감사 결과를 피하는 최고의 방법은 자신의 기술 환경을 속속들이 아는 것이다. IT리더 본인이 모든 자산을 알아야 한다고 기대하기란 어렵다. 그러니 프로세스와 기술, 사람에 의지해야 한다.
컨설팅 회사인 KPMG의 CIO 자문 담당 펠릭스 아코스타 매니저는 “캐나다의 많은 조직들은 아직도 보유한 모든 기술 자산을 파악하는 데 애를 먹고 있다. 분류되지않은 서버 등 오래 된 장치와 장비가 특히 큰 어려움을 주고 있다”라고 말했다.
IT재고 정보의 품질이 큰 도전 과제인 기업들도 많다. 아코스타는 “여러 장소의 메모와 스프레드시트로 기술 자산을 확인 및 관리하는 조직도 있다. 이런 형태의 추적 프로세스는 통상 수동으로 업데이트를 해야 한다. 감사 직전에 이런 추적 문서들을 서둘러 업데이트하는 경우가 많다”라고 말했다.
그는 “IT 리더가 기술 자산을 제대로 파악하지 못 하면, 감사에서 문제에 직면할 확률이 높다”라고 강조했다. 자신의 자산을 모르는 상태에서 유지 관리를 하고, 이런 유지 관리를 기록으로 남길 수 있을까? 시장에는 하드웨어와 소프트웨어 자산 관리를 도와주는 소프트웨어 제품들이 많다. 그러나 이런 시스템이 포괄적이지 않은 경우도 있다. 예를 들어, 감사자에게 클라우드 자산을 추적하지 않는다고 말하는 사태는 없어야 한다.
감사인의 요구를 들어 주기 위해 수동 프로세스를 이용한다
준수해야 할 요구 사항과 데드라인을 맞추고 충족하기 위해 서버, 도구, 기타 기술 자산을 구성하는 것은 어려운 일이다. 여기에 도움을 주는 자동화 도구를 사용하지 않으면, 아마 실패할 수도 있다.
이와 관련, 오픈소스 통합업체인 셰도우-소프트(Shadow-Soft)의 존 레이 시니어 컨설턴트는 감사 및 테스트 프레임워크를 추천했다.
레이는 “셰프 인스펙(Chef Inspec)을 사용, 감사자가 쉽게 읽을 수 있는 보고서를 생성하고 있다. 원하는 결과를 얻기 위해 맞춤화가 조금 필요하지만, 효과가 좋다”라고 말했다.
그는 이어 “준수 요구사항을 충족하기 위해 스프레드시트를 사용하거나 수동으로 추적하는 대신, 인스펙 같은 자동화 도구를 사용하는 것이 훨씬 도움이 된다”라고 강조했다.
벌금과 추가 지출을 피하려면, 쉽게 자산과 환경을 추적하는 능력을 갖추는 것이 아주 중요하다. 이는 소프트웨어 벤더 감사 시, CIO들이 직면하는 중요한 도전 과제 중 하나다.
소프트웨어 벤더의 감사에 도전할 수 있는 역량이 없다
일부 기술 리더들은 점차 중요해지고 있는 소프트웨어 벤더 감사에서 직면하는 어려움이 커지고 있는 실정이다. 벤더가 감사에서 라이선싱 준수 여부를 물을 때 싸울 준비가 되어 있는 것이 가장 좋다.
캐나다 CIO 협회(CIO Association)의 게리 데이븐포트 CIO 멘토 겸 이사는 “내 경험으로는 소프트웨어 감사가 가장 힘들다. 소프트웨어 벤더들은 규칙을 흔히 바꾼다. 변경된 부분을 파악해 따라가기 힘들다”라고 말했다. 데이븐포트는 캐나다의 주요 소매업체인 허드슨 베이 컴퓨니(Hudson Bay Company)의 CIO로 일했었다.
소프트웨어 벤더 감사가 더 많은 비용으로 이어진 경우도 많다. IBM의 패스포트 어드밴티지(Passport Advantage) 변경을 예로 들 수 있다. 레지스터는 “메시지가 분명하다. 감사에서 초과 사용이 된 시기를 정확히 입증하지 못하면 2년 유지 관리 요금 전액을 지불해야 한다. 이는 라이센스 비용의 40%에 달한다”라고 보도했다.
소프트웨어 감사와 관련해 첨단 기술 기업들이 강경한 자세를 취하고 있다. 이런 식으로 추가 요금을 추구하는 회사는 IBM 뿐만이 아니다. 오라클과 마이크로소프트, 기타 대형 소프트웨어 회사의 벤더 감사를 전문적으로 돕는 컨설턴트와 변호사들이 있다.
감사 결과에 따른 후속 행동이 늦다
감사에 실패해, 해당 사항을 조치해야 하는 최악의 상황이 발생할 수도 있다. 이 경우, 빨리 대응하는 것이 가장 좋다. 힐튼(Hilton)의 마이클 레이딩거 CTO는 “감사자는 대응책을 묻고, 후속 조치를 요구할 것이다”라고 말했다.
관리자가 책임을 등한시 했을 때, 감사자가 이로 인해 초래된 문제를 발견하고 침묵하는 경우는 드물다. 경영진 또한 감사 결과를 보고 받는다. 즉 늦은 대응 또한 경영진에 보고된다. IT 감사 실패가 아주 길고 큰 실패로 이어지지 않도록 만전을 기해야 한다.
감사인과 사전에 관계를 구축하지 않는다
감사자를 프로젝트 이해 당사자로 포함시키는 방법은 나중에 문제를 피할 가장 좋은 방법 중 하나이다.
데이븐포트는 “IT 감사자를 기술 프로젝트에 포함시키면 모든 사람들이 편해진다. 중요한 시스템이 구현된 다음 감사자가 제안을 할 경우, 이를 적용하기란 훨씬 더 어렵다”라고 말했다.
그는 “주요 프로젝트에 감사자를 참여시켜 시간과 돈을 절약할 수 있다. 또 감사 조직과 좋은 업무 관계를 구축할 수 있는 최고의 방법 중 하나다”라고 강조했다.
감사자와의 관계가 ‘거래 관계’, ‘필요에 따른 관계’일 필요는 없다. 지속적으로 관계를 발전시키면 신뢰 구축과 커뮤니케이션 문제 최소화에 도움이 된다.
직원들을 준비시키지 않는다
준비와 가이드가 없는 상태에서 감사에 임하면 직원들이 불안해진다. 데이븐포트는 “내부 감사는 기업의 성과 달성에 중요한 역할을 한다. 나는 직원들에게 감사자는 해야 할 일이 있고, 우리는 그들이 할 일을 하도록 지원해야 한다고 설명한다”라고 말했다.
여기에 경험 많은 직원들로 하여금 신입 직원들에게 감사 요구사항을 알려주도록 할 수도 있다. 그러나 이런 비공식적 지원이 불충분할 수도 있다. 회사의 감사 부서와 지속적인 관계를 구축해야 한다.
감사 관여 및 협력 프로세스가 없다
직원들이 감사자와 관여하는 방법을 모르거나 두려워하면, 감사가 순조롭지 않을 가능성이 커진다. 몇몇 직원에게 감사 관리 책임을 맡겨 이를 개선할 수 있다.
레이딩거는 “힐튼이 기업 공개(상장)를 했을 때, 감사가 크게 늘었었다. 그런데 기술직 직원 가운데 상당수는 감사 질문을 다루는 방법을 몰랐었다. 이에 기술과 감사 모두에 경험이 있는 두 사람을 데려와, IT 감사 관리 책임을 맡겼다. 이들은 원활한 감사가 되도록 크게 기여했다”라고 설명했다.
감사인을 ‘적’으로 대한다
소속 부서를 대상으로 한 감사가 예정되어 있다는 소식을 반기는 사람은 거의 없다. 외부 전문가가 부서 운영, 서류를 평가하고, 직원들을 면접하는 것을 좋아할 사람은 없다. 그러나 감사자를 적으로 간주하는 것은 문제를 악화시킬 뿐이다.
레이딩거는 “나는 감사자를 또 다른 비즈니스 이해 당사자로 본다. 정기적으로 감사자와 만나는 것이 아주 중요하다. 감사자는 잘 알려진 기준과 베스트 프랙티스를 가지고 우리 프로세스를 평가한다. 이는 프로세스 검증에 도움을 준다. 애자일 조직으로 변모하기 위해, 감사로 프로세스와 접근법을 평가했다. IT는 우리가 성공적으로 변화하도록 도움을 줬다”라고 말했다.
직원들이 이런 ‘기대 사항’을 충족하도록 준비시키면, 성공적인 감사 결과를 얻는 데 도움이 된다. 그리고 감사자를 ‘적’이 아닌 ‘파트너로 볼 때만 가능한 일이다. 조직이 비즈니스 변혁을 추진하고 있다면, 감사는 객관적으로 성과를 평가, 이런 목표를 달성할 수 있도록 도움을 준다. 또 감사자가 목표 달성에 더 많은 리소스가 필요하다고 판단할 경우, 더 많은 리소스를 획득할 수 있다.
직원들의 발목을 잡는 복잡한 정책과 절차가 있다
기업이 일정 규모로 성장하면, 정책과 절차가 성장을 관리하는 데 없어서는 안될 요소가 된다. 하지만 직원들이 갖가지 정책을 계속 준수하느라 고통받고 있을 수 있다.
레이딩거는 “우리 회사는 몇 년 전, 정책을 단순화 시키는 프로젝트를 런칭했다. 우리는 정책의 수를 줄이고, 쉽게 이해할 수 있도록 만드는 목표를 세웠다”라고 말했다. 정책 준수 부담을 줄이면, 감사에서 더 쉽게 성과를 달성할 수 있다.
조직 정책과 절차를 단순화 시키는 것은 쉬운 일이 아니다. 정책 준수, 회계, 감사, HR 등 여러 부서의 주제 전문가가 필요할 수도 있다. 대안으로 기술 분야 정책 단순화를 지원할 수 있다. 비즈니스 절차와 정책을 개발하는 방법, 정기적으로 조정하는 방법에 대한 더 자세한 정보는 샘 카펜터의 <Work the System: The Simple Mechanics of Making More and Working Less(시스템 정비: 더 적게 일해 더 큰 성과를 일궈내는 단순한 기법)>을 참고할 것을 추천한다.
수 많은 예외는 스스로를 망치는 지름길
대부분의 기업 정책에는 예외를 허용하는 프로세스가 있다. 기업 정책에서의 예외는 감사자에게 도전 과제이다. 소프트웨어 패칭을 예로 들어보자.
레이는 “최근 한 고객은 감사자로부터 소프트웨어 패칭 방법에 대한 질문을 받았다. 문서화 된 프로세스가 존재했지만, 일부 세부 사항이 구체적이지 않았다. 이것이 문제가 됐다. 즉시 보안 패치를 적용하면 애플리케이션이 망가질 수 있기 때문이다. 감사자는 예외 처리에 있어, 더 상세한 프로세스를 원했다”라고 말했다.
보안 패치 적용을 미루면 보안 위험이 상승한다. 따라서 예외가 요구된다면 해당 이유를 문서화 해야 한다.
결론
기술 리더는 몇 가지 원칙에 입각해 감사 성과를 높일 수 있다. 첫째, 감사자가 전체 조직에 가져오는 가치를 인정한다. 둘째, 미흡한 부분을 없애고 질문에 대답하는 것 등 감사 활동을 관리하는 내부 프로세스를 개발한다. 마지막으로, 감사자 및 감사 조직과 지속적인 비즈니스 관계를 발전시킨다.
힐튼의 레이딩거는 “무엇보다도 나는 감사자를 우리 업무에서 해결해야 할 문제에 대한 시각을 갖고 있는 또 다른 이해 당사자로 간주한다”라고 강조했다. dl-ciokorea@foundryco.com
