우리의 삶과 마찬가지로 IT에서도 가끔 나쁜 일이 생긴다. 중요한 비즈니스 운영에 다운타임이 발생하지 않도록 보장하기 위해 막대한 비용과 노동이 투입되지만, 어딘가엔 항상 빈틈이 존재한다. 어떤 부분이 확연히 드러나게 잘못되는 경우, 실제로 그 문제를 어떻게 해결하는지 보다는 문제가 발생한 때와 그 여파가 지속되는 동안 이를 어떻게 커뮤니케이션하는지가 훨씬 더 중요하다.
필자는 지난 몇 주 동안 이 사실이 얼마나 중요한지 새삼 깨달았다. 필자와 정기적으로 거래하는 한 서비스 공급업체가 그야말로 재앙적인 네트워크 장애라고밖에 설명할 길이 없는 사태에 직면했다. 쉽게 예측할 수 없는 종류의 장애였고 여러 계층으로 구성된 리던던시도 아무 소용이 없는 형태로 발생했다는 점 정도를 제외하고는 실제 문제의 본질이 무엇인지는 중요하지 않았다.
이러한 측면에서 필자는 자신의 네트워크가 예측 불가능한 방식으로 무너지는 것을 지켜볼 수밖에 없었던 기술 담당자에게 진정한 동정심을 느낀다. 누구나 IT 분야에서 오래 일하다 보면 실력이 얼마나 뛰어난지에 관계없이 언젠가는 그런 일을 겪게 된다.
필자는 장애 자체에 대해서는 이 공급업체에게 기꺼이 만회할 기회를 줄 의향이 있지만(이 장애가 비즈니스에 지장을 초래했다는 사실에도 불구하고) 장애에 대해 커뮤니케이션하는 방식에 있어서는 호의적으로 평가할 생각이 없다. 사실 필자 의견으로는 장애 커뮤니케이션에 관한 이 업체의 태만함은 장애 자체보다 그 회사에 대한 인식에 훨씬 더 나쁜 영향을 미친다.
모든 IT 종사자는 언제든, 무엇이든 잘못될 수 있다는 위험을 안고 있다. 사람들이 장애 발생에 있어서 우선시하는 점은 장애 중, 그리고 그 이후 명확하게 상황을 커뮤니케이션하는 능력이다. 필자는 커뮤니케이션이 제대로 이루어졌다는 이유로 막대한 규모의 장애를 용납한 조직들을 봤고, 반대로 아무런 업무 손실도 일으키지 않았지만 커뮤니케이션이 제대로 되지 않았다는 이유로 거의 해고될 뻔한 사람들도 봤다. 커뮤니케이션은 그만큼 중요하다.
필자는 이번에 경험한 사고보다 더 심각한 사고도 겪은 적이 있는데, 이렇게 장애 커뮤니케이션이 제대로 되지 않은 경우를 보면 다음과 같은 몇 가지 공통적인 특징이 있다.
1. 필자는 문제를 탐지하도록 구성해 둔 자체 모니터링 도구를 통해서만 문제를 인지했다. 공급업체의 누구도 연락해서 문제 발생을 알리지 않았다.
2. 문제의 원인에 대해 물었을 때 항상 근본 원인 분석을 수행하는 데 몇 시간이 걸릴 것이라는 대답이 돌아왔으며 다른 정보는 얻을 수 없었다.
3. 여러 차례의 요청에도 불구하고 그 근본 원인 분석 결과는 무려 4일 후에나 전달됐다. 그 사이 문제에 대해 어떤 연락도 없었다. 그 문제가 다시 발생할 가능성이 있는지 여부조차 알 수 없었다.
4. 마침내 근본 원인 분석 결과를 받았지만 자료는 뒤죽박죽이었고, 문제에 대한 세부적이고 충분한 정보가 담겨 있긴 했으나 철자와 문법적 오류가 난무하는 “전문가답지 않은” 문서였다.
자신이 근무할 때 장애가 발생할 경우 가장 먼저 해야 할 일은 그 상황의 이해관계자에게 이를 알리는 것이다. 이들이 아직 문제를 인지하고 있지 못한 상황이라도 마찬가지다. 물론 문제를 명확히 파악할 시간이 필요하고 제대로 알기 전에는 문제에 대한 성급한 결론을 내리려 시도해서는 안 된다. 그렇게 할 경우 나중에 상황이 더 나빠질 수 있기 때문이다. 그러나 문제를 알리는 데 너무 시간을 끄는 것은 금물이며 신속하게 문제를 알리도록 노력해야 한다. 기술적 지식이 없는 고객이라면 문제에 대처하고 있다는 사실을 아는 것만으로 걱정을 덜게 된다.
심리적 압박을 느끼는 장애에 직면한 상황에서 가장 하기 어려운 일 중 하나는 문제 해결을 위해 노력할 시간을 할애해 사람들에게 문제를 알리는 것이다. 필자도 어렵다는 것을 안다. 필자도 눈앞에서 기업 네트워크 전체가 다운되고 혼자서 정신 없이 문제를 해결하기 위해 애썼던 상황에 직면한 적이 있다. 문제 해결 작업을 중단하고, 생각의 고리를 끊고, 어떤 문제가 발생했으며 앞으로 어떻게 될 것인지 알리는 것(특히 기술적 지식이 없는 사람에게)은 정말 하고 싶지 않은 일이다.