한번만 실수해도 끝? IT개발자의 고뇌~

복잡한 IT 서비스! 늘어만 가는 업무량, 어깨를 누르는 무한 책임감 ~~~

IT 업계에 종사하는 개발자, 운영자의 하소연이다. 하루가 멀다하고 나오는 새로운 서비스들은 경쟁적으로 좀 더 화려하고 복잡한 기능들을 요구한다. 이에 따라 서버, 네트워크, Storage, 보안 시스템 등의 복잡도는 계속해서 증가된다. 프로그램 코드의 길이가 길어지니 그 안에 어떤 실수나 불안정성 요인이 있는지 아무도 모른다. 그러다가 문제가 발생되면 온통 개발자나 운영자의 탓으로만 돌린다. 개인의 책임을 묻는다. 과연 이것이 맞는 것일까 ? 

 

한번 실수는 병가지상사라는 말이 있다. 정말로 ?

전쟁을 할 때 한 번의 실수는 있을 수 있기에 용서해 준다는 말이다. 그리고 우리는 일상 생활의 대화 중에 이 속담을 자주 인용한다. 마치 실수에 무척 관대한 사람처럼 말이다. 그런데 현실에서 이런 관대함이 질 지켜지고 있을까 ? 그렇지 않은 것같다.

 

IT 시스템이나 서비스, 보안 침해 사고가 발생하면 사람들은 그 원인을 찾아 나선다. 그러다가 그것이 어떤 개발자나 운영자의 탓으로 귀결되면 모두가 합심하여 그를 공격한다. 천하의 죄인인것처럼 ! 어떤 사정이 있는건지, 불가피했던 것이었는지는 중요치 않다. 다만 결과가 중요할 뿐이다.

 

 

지우고 싶은 실수, Source: motivatingwords.net

 

휴먼 에러(Human error)는 실수인가, 인간적인 면모일까?

사람이 기계가 아닌 이상 실수를 하게 된다. 디지털이 아닌 아날로그 두뇌를 갖는 인간의 특성상 이런 잠재적인 실수 가능성은 상존한다. 따라서 사람에 의해 장애가 발생되면 휴먼 에러라는 말을 쓰곤 한다. 사람이기에 본원적으로 가질 수 밖에 없는 단점인 것이다.

 

실제 사례를 보자. 최근에 발생한 넷플릭스(Netflix) 장애 건이다(출처).

 

Netflix는 미국의 유명한 온라인 VOD 사업자이다. 이 회사는 아마존(Amazon)사에 전체 서비스의 운용을 위탁하고 있다. 그런데 많은 사람들이 찾는 크리스마스를 전후로 넷플릭스는 대규모 장애 사태를 겪었다. 아마존의 개발자가 실수로 넷플릭스 서버 운용에 중요한 화일을 삭제했기 때문이다.  

 

12월 24일 오후 12:24분 아마존의 개발자가 넷플릭스 서비스와 연관된 부하 분산 시스템(Load Balancer)의 중요한 설정 정보를 삭제 했다. 개발자는 자신이 한 행동이 어떤 결과를 초래하는지 전혀 몰랐다. 이후 넷플릭스 서비스는 장애를 겪었다.

아마존의 운영팀은 즉각 원인 파악에 나섰고, 부하 분산시스템의 API에 에러가 있는지 조사했다. 그러나 넷플릭스 외 다수의 서비스들이 정상적으로 동작하고 있어 API 에러는 아니었다.

 

시간이 경과되고 있었기에 운영자들은 시스템을 Restart 했다. 그러나 문제가 해결되지 않았다. Load Balancer가 동작하기 위해 필요한 설정 정보가 여전히 없었기 때문이었다. 그래서 운영자들은 단계적으로 설정을 다시 시작했다. 모든 작업은 장애가 발생된지 거의 10시간만에 완료 되었다. 넷플릭스는 크리스마스 황금 시즌 동안 서비스가 불통되어 큰 피해를 입었다.

 

나중에 분석 결과, 한 개발자가 실수로 설정 정보를 지운 사실이 발견 되었다..    

 

위 사례를 보면서 어떤 생각이 들까? 실수를 한 개발자의 현재 샹황이 궁금하다. 쉽게 예상이 되는 부분은 개발자가 해고되고 회사로부터 손해 배상 소송에 직면해 있을 수도 있다. 한번 실수로 치부하기에는 너무나 큰 사고를 쳤기 때문일까?

 

실수할 수 밖에 없는 인간이라는 걸 인정하면서, 실수가 허용되지 않는 현실이다.

 

 

Source: datinglish.com

 

 

사람이 아닌 시스템, 구조화의 문제

위 사고는 아마존에 있는 개발자 1명의 실수는 아니다. 어느 곳이나 운용체계는 단계별 감시, 감독 체계를 갖는다. 실수를 할 수있기 때문이다. 따라서 아마존의 대형 장애는 외면적으로 작업자 1명의 실수이겠지만 이는 개인의 실수가 아닌 아마존 운용 구조 자체에 문제가 발생된 것으로 보아야 한다. 따라서 아마존이 개발자 1명에게만 책임을 물어 해고 한다면 이건 아마존이 또 하나의 치명적인 실수를 하는 것이다.   

 

Check, Help 체계를 갖추어야 한다.

복잡한 IT 시스템의 개발 및 운용 구조에서 중요한 것은 상호 Check, Help 시스템을 갖추는 것이다. 서로간의 전문 영역이 다르고, 상황에 대한 유기적 대처를 하기 위해서는 개발자/운용자 상호 간에 자신의 작업 내용을 공개하고 서로 점검 및 지원해 주는 체계를 갖추는 것이 중요하다. 2명이 동시에 실수를 할 가능성이 1명일 때 대비 무척 낮기 때문이다.  

 

너그러움과 관용으로 고단한 IT 개발자/운영자를 격려하자.

중대한 실수를 저지른 사람을 무조건 옹호하자고 하는 건 아니다. 실수를 했다면 거기에 맞는 책임을 지는 것은 당연하다. 그러나 실수가 시스템이나 구조 자체의 결함 또는 그동안 한번도 발생하지 않았던 미지의 불가항력적인 사유에 의해 발생했다면 너그러이 용서를 해 주는 것이 좋다. 마치 인민 재판처럼 모두가 손가락질만 한다면 IT 업계의 유능한 인재가 될 수도 있는 사람이 영원히 재기 불가능하게 될 수도 있다. 

 

격려할 것인가, 좌절하게 만들 것인가?, source: whoareyouloard.wordpress.org

 

전지 전능한 전문성을 요구하는 현대의 IT 시스템은 개발자/운용자에게 스트레스를 주고 그들의 어깨를 짓누른다. 우리가 편히 쓰는 이러한 시스템이나 서비스들은 그들의 피땀어린 노력의 결과이다. 그들의 노고에 감사의 마음을 갖자. 그리고 그들이 실수를 하더라도 고의적이거나 태만 등에 의한 것이 아닐 때는 용서하는 미덕을 보여주자. 그것이 IT 산업의 발전과 생태계를 확장시키는 지름길일 것이다.