물류시스템 장애가 부른 대혼란

IT 의존도 높은 공급망관리…위기대응능력 키워야

“기업과 기업 간 전산망 통합은 쉽지 않은 일이다. 특히, EDI(전자문서교환, Electronic Data Interchange) 등 정보 결합은 더 큰 골칫거리다. 양사의 합병으로 아직 내부 결속을 다지지 못한 상태에서 통합물류의 IT역량은 곧바로 시너지를 기대하기는 힘들다. 사람처럼 술 한잔 함께 먹고 노래방에서 어깨동무하고 노래 불러서 동료애와 결속을 다질 수 있는 경우가 아니라는 뜻이다.”  <editor>

        출처: 구글

글. 물류논객 '후버'

작년 본지를 통해 블랙아웃으로 인해 물류정보시스템이 마비될 수도 있다는 것(통권 35호, “정전(停電)사태 위기, 물류도 예외는 아니다” 참조)을 언급한 바 있다. 

비록 블랙아웃으로 인한 것은 아니었지만, 얼마 전 CJ대한통운와 CJ GLS의 택배 통합에 따른 배송지연 사태는 물류정보시스템 마비가 가져올 수 있는 재앙을 단적으로 보여주었다.  양사 택배시스템 통합의 과정에서 코드 통합 미흡을 얘기하기도 하고, 사용자의 미숙을 얘기하기도 하지만, 결과적으로는 정보시스템 장애로 보여지고 말았다.

물류기업이 합병하면, 합병한 기업의 서로 독립된 시스템이 하나로 통합되어 나름의 시너지를 내기까지는 시간이 좀 걸린다. 사실 물류기업끼리 합병을 하는 목적 중에는, 그들이 서로 독립적으로 갖고 있던 IT 역량을 하나로 합쳐 고객들의 늘어나는 요구사항에 유연하게 대응하는 것도 있을 것이다. 

그러나 지금은 어느 누구도 대적 못할 것 같은 DHL 조차도 그렇게 되기까지는 시간이 걸렸다. 필자의 지인으로부터 들은 얘기를 빌리자면, DHL이 유럽의 어떤 국가에서 현지 3PL을 인수하고 현지에서 영업 활동을 하게 되었는데 우연치 않게 필자의 지인이 일하던 유럽의 해당 기업에 응찰을 하게 되었다고 한다. 

필자가 DHL이면 그래도 믿고 맡길 수 있지 않느냐고 했는데, 지인의 답변은 의외였다. 이곳에서는 독일 DHL을 생각하면 곤란하다고 말이다. 아직 시스템 통합이 완전히 되지 않아 독일 DHL처럼 모든 것을 완벽하게 갖추고 응찰하는 것이 아님을 필자에게 귀띔해 주었고, 결국 그 기업은 DHL의 응찰을 받아주지 않았다. 

실제 필자 역시 합병 직후의 어떤 3PL에게 EDI(전자문서교환, Electronic Data Interchange) 연결 시도했다가 화병 나는 줄 알았던 경험이 있다. 합병으로 아직 내부 결속을 다지지 못한 상태에서 합병 3PL의 IT역량은 곧바로 시너지를 내기는 힘들다는 얘기다. 사람처럼 술 한잔 함께 먹고 노래방에서 어깨동무하고 노래 불러서 동료애와 결속을 다질 수 있는 경우가 아니라는 뜻이다. 

시스템 장애라는 것은 일단 발생하면 시스템 담당자에게는 악몽이다. 시스템 담당자가 예측할 수 있으면 장애라고 말할 수도 없다. 정말 예측하지 않은 곳에서 장애는 발생한다. 예측할 수 없으니 악몽이다. 대량의 데이터를 병렬 처리하면 될 것을 순차 처리하다가 시스템이 과부하를 일으켜서 스스로 장렬하게 전사해도 시스템 장애고, 누군가의 요청에 의해 업데이트한 프로그램이 오작동을 일으켜 시스템이 무한 루프(프로그램이 무엇인가를 멈추지 않고 계속 반복 실행하는 상태를 의미하는 시스템 용어)를 돌아도 시스템 장애다. 

이런 상황은 그나마 시스템 담당자의 귀책이 있다고 말할 수나 있다. 요즘처럼 기업의 업무에 정보시스템을 광범위하게 사용하는 세태 속에서는 시스템 밖의 사람들은 늘 자신들이 일을 못한 것에 대하여 희생양을 찾으려고 노력하기 마련이며, 이때 그 희생양으로 제일 잘 걸려드는 것이 정보시스템이다. 

예를 들어 언론을 통해 드러난 CJ대한통운 택배 지연과 같이 미숙한 사용자가 대량의 데이터를 잘못 만들어서 오배송이 발생함으로써 업무가 멈춰버릴 정도라면, 시스템 자체의 문제가 아니었다고 해도 시스템 밖의 사람들에게는 시스템 장애다. 

시스템 밖의 사람들에게 시스템의 구조와 사용자의 작동법 미숙을 강조해 봤자 말짱 헛일이다. 사용자 변화관리를 제대로 못 한 책임만 돌아온다. 필자가 누군가에게서 들은 한 마디가 이러한 상황을 간단히 요약해 준다. 

“사용자가 시스템을 잘못 다루는 것도 시스템 Problem이다.”

모든 사고들이 다 마찬가지겠지만, 시스템 장애도 그 특성상 해결하는 사람은 극소수에 불과하다. 예를 들어 시스템을 잘못 만들었다면, 만든 사람만 날 새워 가며 다시 프로그램을 수정해서 바로잡으면 된다. 서버와 같은 하드웨어 장애라면, 서버 및 네트워크 전문가가 문제를 해결하면 된다. 사용자의 오작동에 의한 것이라면, 사용자의 오작동을 바로잡아 주면 된다.

그러나 문제는 해결하는 사람이 아닌 해결과 상관없는 사람들이다. 그들을 기다리고 있는 것은 이러한 상황을 전파해야 할 대상자 명단, 지금 시스템이 왜 이러냐는 사용자들의 빗발치는 문의 전화, 죄송하다는 말을 반복하다 못해 전화상으로 들려오는 육두문자를 참아 내느라 우울증 직전까지 간 정신 상태, 상황을 실시간으로 확인하고 대응방안을 마련해야 할 절박한 이들과, 이러한 상황을 맞아 내가 이렇게 열심히 일을 하고 있노라고 회사에 각인시켜 주려는 몇몇 영웅심 많은 이들 모두에게 해야 할 수많은 보고들, 그리고 고통분담 차원의 인정사정 없는 야근, 뭐 이런 것들이 그들을 기다린다. 

특히 시스템 장애를 회사 밖에 알려서 대중의 이해와 공감을 받아야 한다면 그런 것쯤은 감내할 수 있는데, 숨겨야 한다면, 이것도 쉽지 않다.

이렇게 시스템 장애의 해결이 매우 어렵게 된 데에는 공급망 관리의 역할이 컸다. 재고의 감축과, 외부 파트너와의 유기적 연결로 대표되는 공급망 관리의 시대를 맞아 요즘은 사소한 시스템 장애가 너무나 많은 다른 기업 활동에 영향을 준다. 

예를 들어 창고관리시스템이 멈추면 거래처로부터 받은 주문을 출하할 수 없게 되어 매출실기할 것은 자명한데, 그렇게 됨으로써 창고관리시스템에서 주는 출하정보를 받는 각종 대시보드(Dashboard)나 임원정보시스템, 경영정보시스템, 납기약속시스템, 심지어, 출하정보를 받아 다음주 플래닝(Planning)을 돌리는 공급망계획(Supply Chain Planning) 솔루션까지도 영향을 받게 된다.

Dashboard나 경영정보시스템을 관리하는 이들은 소명을 요구하고, 납기약속시스템을 관리하는 이들은 고객에게 납기약속을 못 해주는 것에 대한 대안을 요구하거나, 고객에게 사과 전화 돌리느라 바빠진다. Supply Chain Planning 솔루션 담당자들은 출하실적을 적게 받음으로써 차기 예상재고가 늘게 되므로 차기 물량 발주에 어려움을 겪을 상황에 대비해야 한다. 

공급망 관리의 궁극적인 목적은 재고를 줄이는 것이었던가. 요즘은 공급망 관리한다고 너도나도 물류센터 규모를 작게 가져가고 재고를 적게 가져가려고 노력하다 보니 시스템 장애가 발생하면 얼마 안 가 재고나 자재가 떨어져 버리거나, 재고가 물류센터에 꽉 찬 상태에서 더 이상 보관할 곳이 없어짐으로써 자연스럽게 공장이 멈춰 버릴 수도 있다. 시스템 장애가 발생했을 때 생산 시스템 자체가 멈춰 버리는 확률보다는, 오히려 생산과는 전혀 관계가 없는 시스템이 멈춰 버림으로써 간접적인 영향을 연쇄 반응으로 받다가 결과적으로 생산이 멈추는 확률이 더 높을 것으로 본다.

공급망 관리를 한다는 이유로 수많은 정보시스템 개선이 이루어져 왔으며, 앞으로도 많은 기업에서 그렇게 할 것이다. 그러나 과연 얼마나 많은 기업들이 그렇게 정보시스템을 구성함으로써 그들이 가진 공급망은 유사시 더욱 더 취약해질 수 있으며, 그 취약함을 무엇으로 극복해야 할지에 대해서는 제대로 생각해 보지 않는 것 같다. 하긴 정보시스템 개선을 하는 이들은, 그것을 순방향으로 이용함으로써 어떠한 이득이 있을 것인지에 대해서는 열심히 생각하지만, 정작 더욱 높아지는 정보시스템의 취약성에 대해서는 아무도 고민하지 않는다. 

결국 그 고민은 시스템 담당자가 해야 하는 것일까? 필자는 그렇게 생각하지 않는다. 정보시스템 개선으로 인해 더 많은 오류가 발생할 가능성이 있다면, 처음부터 시스템 담당자는 ‘노(No)’라고 말할 수 있어야 한다.