[지디넷코리아]"법칙1. 프로젝트가 실패할 가능성은 해당 프로젝트의 중요성에 비례한다."

국내의 대표적인 인터넷서점 예스24가 최근 IT시스템 개편 과정에서 발생한 장애로 인하여 심각한 사업적 손상을 겪었다. 예스24는 지난달 시스템을 전면 재구축하는 과정에서 발생한 문제점으로 인해, 무려 5일이 넘도록 사이트 운영을 중단하였을 뿐만 아니라 배송 또한 완전히 중단함으로써 고객들의 커다란 항의를 받았다.

필자도 예스24의 시스템 재구축 직전에 물품을 주문하였다가 열흘 만에 일부 물품만 겨우 받을 수 있었다. 이번 사건을 통해 예스24는 직접적인 손실액만 10억 원 이상이 될 것으로 알려지고 있으며, 시장 및 고객의 신뢰도 하락에 따라 앞으로 겪게 될 간접적 손실 또한 막대할 것으로 추산된다. 현재 예스24는 인터파크와 치열한 경쟁 상태에 있는데, 이번 사태로 인해 인터파크는 커다란 반사 이익을 얻게 될 것으로 보인다.

IT를 이용하여 사업을 영위하는 많은 기업들이 IT 프로젝트의 복잡성 및 위험(Risk)을 간과하고 있다. IT 프로젝트에는 수많은 위험이 도사리고 있다. 신기술의 사용, 숙련되지 못한 팀원, 고객 요구사항의 불분명함, 일정의 촉박함, 빈약한 예산 등으로 인해 프로젝트의 성공이 위협받고 있는 것이다.

이번 예스24 신(新)시스템의 개발을 담당한 업체인 이네트의 작년 11월 공시에 따르면, 계약금액 2억원에 개발 기간 6개월로서 올해 4월 15일에 완료되는 것으로 되어 있다. 숙련된 개발자가 그리 많지 않은 마이크로소프트 닷넷(Microsoft .NET) 기반의 기술을 사용하는 리스크, 그리고 쇼핑몰과 백오피스 및 데이터베이스를 전면 개편하는 것에 대한 리스크를 고려할 때 꽤나 적은 비용 및 적은 개발 기간을 산정했다는 것을 알 수 있다.

프로젝트라는 것이 아무리 충분한 기획을 하더라도 예상치 못한 변수 및 실수가 있을 수 밖에는 없기 마련이지만, 누가 보아도 예상할 수 있는 위험을 고려하지 않거나 최소한의 안전 장치조차 마련하지 않는 것은 이해하기 힘든 일이다.

"법칙2. 업그레이드를 한 후 이전 버전을 삭제하자마자, 장애가 일어난다. 그리고 이전 버전은 다시 설치되지 않는다."

소프트웨어 개발 및 그 산출물의 복잡성을 간과해서는 안 된다. 이번 예스24 사태에 있어 가장 놀라운 점은, 그러한 대규모 시스템에 있어 철저한 기능/통합/성능 테스트 및 SQA(Software Quality Assurance, 소프트웨어 품질 보증)를 제대로 수행하지 않았다는 것이고, 또한 신시스템에 문제가 발생할 경우를 대비하여 이전 시스템으로 돌아갈 수 있는 준비를 제대로 갖추지 않았다는 것이다.

만일 그렇게 했다면, 장애가 발생했더라도 이전 시스템을 다시 가동함으로써 신시스템의 장애가 크게 문제되지 않았을 것이다. 하지만 그러한 대응책이 없었던 예스24는 무려 5일간 웹사이트 운영을 중단하게 되었고, 오프라인의 사업 기반이 없는 인터넷 기업으로서 웹사이트 운영의 중단은 사실상의 사업 중단으로 인식되었다. 물론 현재는 웹사이트가 거의 정상 가동되고 있는 상태이다. 장애 발생 후 외부 전문가를 투입하여 문제점을 해결한 결과이다(우리는 이러한 장애 발생 시 외부 전문가 투입되어야만 해결되는 경우를 많이 보아왔다).

우리가 이번 사태를 통하여 알 수 있는 것은 인터넷 기업이 IT를 활용하여 사업을 영위하고 있음에도 불구하고, IT에 대한 인식이 아직도 저급한 수준에 머물러 있다는 것이다. 우리 주변에 디지털 기술이 넘쳐나고는 있지만, 아직도 대형 IT시스템을 구축하는 것은 상당히 두렵고 어려운 일이다. 더군다나 최근과 같이 소프트웨어 업계가 침체되어있고 경험이 풍부하고 유능한 전문 인력이 부족한 상태에서는 더욱 그렇다.

예스24 수준의 시스템은 단순한 쇼핑몰이라기보다는 대규모 엔터프라이즈 시스템으로서, 전문적인 SI 업체가 담당하여야 하는 개발이라고 할 수 있다. 즉 대규모 분산 시스템 및 백오피스의 개발 경험, 철저한 소프트웨어 품질 관리 능력, IT 프로젝트 관리 및 위험 관리 능력이 요구되는 개발이다. 그러한 경험과 능력이 부족한 상태에서 거기다 익숙하지 않는 신기술을 적용했다면, 총체적으로 위험이 상승하는 것은 당연한 일이다.

필자는 이번 사태를 시스템 장애에 즉각적으로 대응하지 못하여 생긴 해프닝이기 보다는, 위에 지적한 본질적인 문제점들이 결합하여 발생한 사건으로 파악하고 있다. 그리고 이것은 어느 한 업체의 IT 시스템에 대한 안일한 인식에 따른 문제를 넘어서서 많은 기업들에 만연되어 있는 문제이므로, 앞으로 우리는 다른 기업에 대해서도 (경우는 다르지만 본질적으로는 동일한) 유사 사태를 신문에서 종종 접하게 될 것으로 본다.

IT를 활용하여 사업을 영위하는 모든 기업은, IT 시스템 및IT 프로젝트에 대한 존중심을 가져야 할 필요가 있다. 만일 IT 시스템을 단순히 사업을 영위하기 위한 도구로만 생각하여 그것에 대한 충분한 배려(care)를 하지 않고, IT 전문가를 확보하기 위한 충분한 교육과 투자를 하지 않고, IT 프로젝트의 위험성을 간과함으로써 자질과 능력을 갖춘 프로젝트 매니저를 선정하지 않고 또한 경영진과 의사소통할 수 있는 프로젝트 관리 시스템을 갖추지 못한다면, IT는 해당 기업에게 도구가 아닌 재앙이 될 것이기 때문이다. 필자의 말이 과하다고 느끼는 독자들이 있겠지만, 업계에는 그것을 증명하는 수많은 사례들이 있다. 이번 사태를 계기로 IT에 대한 한층 더 합리적인 인식이 확산되기를 기대해 본다.

여기에서 소개한 프로젝트의 법칙은 우리가 익히 알고 있는 머피의 법칙을 프로젝트에 응용한 것이다. 끝으로 필자가 프로젝트 관리와 관련된 강의 시 항상 빼놓지 않고 언급하는, 프로젝트의 법칙3을 소개하며 글을 마치도록 하겠다. 이러한 머피의 법칙이 왜 중요하냐고 묻는다면, 그것을 언제나 기억함으로써 프로젝트에 대해 안일하게 대처하는 무책임한 낙관을 상당 부분 막을 수 있기 때문이다. 모든 것은 인식의 문제이다.

"법칙3. 프로젝트에 있어 확실한 단 한 가지는, 어떤 일이 잘못된 가능성이 있다면 그것이 잘못되어 갈 것이라는 점이다." @