시스템 장애는 왜 두 번 일어났을까? - 미즈호은행, 동일본 쓰나미 그 후 시스템 장애에서 얻은 교훈

시스템 장애는 왜 두 번 일어났을까? - 미즈호은행, 동일본 쓰나미 그 후 시스템 장애에서 얻은 교훈
[닛케이 컴퓨터] 편집부 지음, 이영희 옮김 / 한빛미디어 / 2012년 7월

시스템 장애는 왜 두 번 일어났을까?- 미즈호은행,  동일본 쓰나미 그 후 시스템 장애에서 얻은 교훈 



필자는 IT 분야에서 16년간 일한 나름 전문가라고 할 수 있다. 그래서 IT의 문제들을 이야기하는 기사 등에 매우 관심이 많다. 한빛미디어는 IT분야 전문서적을 출간하는데 종종 메뉴얼 중심에서 벗어나 정보경영이나 인문학적 관점에서 씌어진 책들을 소개한다.  이번에 출간된 이 책도 이런 책 중에 하나이다. 필자가 가장 관심을 가지는 종류의 서적이다.


미즈호은행의 장애에 대한 기사들을 정리하여 출간한 이 책은 사실 IT분야에서 일하는 사람들 보다 IT 분야를 활용하는 다른 분야에 사람들이 읽어봐야 할 책이다. 특히 IT가 중심이 되어있는 기업이나 조직의 우두머리이면서IT에 대해 섣부르게 알고 있는 경영자들이 꼭 읽었으면 하는 책이다. 하지만 현실적으로는 이런 부류들은 이런 책을 접할 기회도 적고 실상 읽어도 이해를 못할 수도 있지만…

IT는 흔히 방법론에 대해 이야기가 많이 된다. 어떻게 구현할 것인가? 어떤 하드웨어나 소프트에어를 쓸 것 인가 하는 이야기는 이 글에서 이야기하고자 하는 것과는 거리가 있다. 미즈호은행에서 발생한 문제들은 근본적으로 기술적인 문제보다는 IT에 대한 인식부족이 근본 원인이었다. 미즈호은행 뿐 아니라 거의 대부분의 IT 프로젝트에서 기술적인 부분에 대해서만 고민을 하다 정작 중요한 부분이 정책, 전략 등의 방향성을 못 잡는 경우가 많다. 목적지 없이 출발한 배는 바다 위에서 표류하게 된다. 아주 단순하게 생각해보면 표류하지 않으려면 미즈호은행이 했던 실수들을 따라 하지 않으면 되는 것이다.

이것은 현재가 지구 규모에서 인류가 처한 위험 중에 하나이다.

필자는 먼저 IT에 대한 잘못된 선입견부터 이야기할까 한다. 새 기술에 대해 이야기, 하드웨어, 소프트웨어에 대해 이야기를 하는 사람들은 많지만 그러나 정작 대부분의 사람들은 IT를 어렵게 느낀다.  현재 대다수의 사람들이 IT 없이는 세속의 삶을 살 수 없기 때문에 IT를 잘 모르거나 어려워하면서 자연스럽게 그것을 이용하는 상황은 아이러니한 상황이라고 할 수 있다. 그러나 IT가 추구하는 목적을 생각해 볼 때 이런 현상은 자연스러운 것이다. 잘 구현된 IT는 사용자가 그것을 인지하지 못 할 정도로 자연스러워야 한다.  사용자들은 잘 이용하기만 하면 되는 것이지 그것에 대해 알아야 할 이유도 막연한 두려움을 가질 필요는 없다. IT에 대해 잘아야 하는 사람들은 정보시스템을 기획하고 설계하고 구현하며 유지하는 이들이면 족하다.

IT관련 일을 하는 이들이 IT에 대해 잘 알고 인지하고 있어야 한다는 것은 별다를 것 없는 당연한 이야기라서 이 말을 하면서도 스스로 좀 이상하다는 느낌이 든다. 하지만 IT를 만들어가는 사람들이 이것을 잘 모른다고 하면 어떨까? 당연히 IT시스템 즉 정보시스템의 구동에 문제가 생길 가능성이 커진다. 현재 우리가 사용하는 대부분의 문명(크게는 교통시스템, 방송 그리고 작게는 신용카드 같은 것 들까지…)이 대부분 IT시스템에 기반을 두고 있기 때문에 이런 모든 것들을 제작하고 운영하는 사람들 중에 자신들이 관리하는 시스템에 대해 잘 모르는 이가 있다면 이건 걱정스러운 상황일 것이다.

몰라도 할 수 있는 IT 프로젝트?

몰라도 할 수 있는 IT 프로젝트가 있을까? 잘 모르면서 어떤 일을 한다는 것은 일단 문제가 있다. 하지만 현실에는 잘 알지 못해도 어떤 일에 참여하거나 진행을 승인하는 경우가 많고 IT 프로젝트도 예외는 아니다. 특히 실무자가 아닌 경우에는 그런 상황이 충분히 가능한 일이다.

 

모든 일이 그렇듯이 잘 모르면 일을 그르칠 가능성이 매우 높다. 요즘 IT 프로젝트는 그 규모나 파급효과가 크다. 특히 국가기간 산업(전력, 교통, 통신)등과 금융 쪽에서 운용하는 IT 시스템은 그 규모나 파급효과의 규모가 국가 차원에 이르기 때문에 일을 그르친다는 것의 위험성은 엄청나다. 더 큰 문제는 요즘에는 그 규모가 어찌 되었던 간에 그들 조직밖에 대해 서비스를 하는 시스템의 경우는 거의가 인터넷을 통해 불특정 다수의 일반인들에게 24시간 365일 노출이 되어 있기 때문에  문제가 발생하면 불특정 다수가 그것을 인지할 수 있다. 거기다가 그들은 무엇인가를 발견하면 퍼트리는 경향이 있다. 작은 실수가 일파만파 커져서 조직전체에게 책임을 묻은 규모로 확대될 가능성이 충분하다.

요즘의 IT 시스템은 조직. 기업의 위상이 걸린 문제이기 때문에 개발자 또는 개발조직의 책임과 문제로 대충 덮어버릴 수 없게 된다. 작은 문제가 반드시 전체의 문제가 되지는 않지만 대응방법에 따라 단순한 오탈자 문제 하나로도 전국민이 아는 문제로 확산될 수 있다.

경영자나 임원들이 나 몰라라 하면서 개발조직에 책임을 전가할 수준의 문제가 아니라는 것이다. 특히나 기술적인 문제가 아닌 경영전략, 부서간의 이견에 의해 발생된 사건이라면 실무자들이 아무리 머리 터지게 싸워봐야 결론이 나지 않는다. 이런 문제에서 조직의 목표를 설명하고 올바른 방향으로 모두가 나아가도록 조율하거나 명령하는 것이 경영진의 책임이다. 

경영자가 회의 자리를 빛내기만 하고 회사 통장의 잔고만 확인하는 시대는 이지 지나갔다.

‘지금은 20세기가 아니라 21세기이다.’

필자도 최근 몇 년간 몇 건의 홈페이지 개발 프로젝트의 사업관리나 PM으로 참여했는데 이 경우는 고객사의 의뢰를 받아서 작업을 하기 때문에 위의 주장에 따르면 고객 사가 자신들의 만들고자 하는 홈페이지에 대해 최종적인 책임이 있다 하겠다. 그런데 많은 경우 외주개발사에 일임하고 심지어 자신들이 정리해야 하는 요구사항도 외주업체에서 만들어 주길 원한다. 그 들의 요구내용을 한 문장으로 만들어 보면 ‘당신들이 전문가들이니까 대충 이야기해도 잘 알아듣고 다른 유사 사이트의 경우와 잘 조합하여 최고의 홈페이지를 만들어 달라~’ 이런 식이다. 물론 홈페이지를 외주 주고 나면 고객사 담당자는 그냥 외주업체가 만들어 놓은 것을 검토하는 일만 하면 되니까 남는 시간에 다른 일 하라고 하는데 이 역시도 몰이해와 책임감 결여에서 온다고 본다.

외주 업체가 잘 수행해서 적기와 원하는 결과물을 얻으면 좋지만 이런 분위기에서라면 100이면 100, 제때에 제대로 완수하지 못한다. 결국에 가서는 자신들이 운영할 홈페이지에 대한 책임감으로 외주 업체와 함께 고생을 해야 한다.

내부의 문제를 외부로 전가시킨다고 그 문제가 해결되지 않는다. 문제에 관여된 사람의 수가 늘어 더 복잡해진다.

다시 본론으로 돌아가서 IT시스템이 조직의 중요한 경영, 유지수단이라면 최고경영자도 반드시 이에 대한 적절한 수준의 이해를 가지고 자신에게 정확한 조언을 할 전문직 임원을 보유해야 한다. 반드시 조직의 경영층이 책임을 질 각오로 수행하지 않은 IT 프로젝트는 프로젝트 관리의 엄격한 기준에서 보면 모두 실패할 것이다.

시스템의 오류는 개발자의 능력이나 인간적인 실수에 의한 것인가?

현업에서 만나는 개발자들 중에는 특이한 성격이나 습관을 가진 사람들이 많다. 화면 가득 코드와 대화를 하다 보니 그렇게 되었을 수도 있다. 또 프로그램 개발자들의 업무 특성상 한일에 몰두하는 사람이 적임자이기도 하기 때문일 것이다. 실무에서 개발자들과 프로젝트를 운영하다 보면 개발작업의 일정은 늘 미지수이고 예상일정보다 늘 초과된다. 또 어제 수정한 부분이 다른 작업 중에 알 수 없는 오류를 낸다. 개발자의 수행 능력은 개인별 편차가 있긴 하지만 개발작업이라는 것 자체의 경우의 수를 파악하고 각 경우의 수를 조합하여 논리적인 모듈을 만든 것이라 복잡한 입력과 절차를 가진 업무에 대한 작업에서는 그 경우수가 수백에서 수천 개에 이른다.또 이 책에서 주장하듯이 대형 금융 시스템의 프로그램 코드는 1억행 정도 되는데 이런 규모의 코드는 사람의 능력으로는 100% 완벽하게 파악하는 것은 애초에 불가능한 것이다. 다만 일정한 단위로 모듈화한 후 각 모듈과 모듈간의 관계로 구분 처리하여 한 번에 처리한 규모를 줄여서 개발이나 관리 시 오류 가능성을 줄이는 것이다.

게다가 우리나라나 일본처럼 아직 권위주의 시대의 영향이 남아있는 사회에서는 프로젝트의 계획 자체가 상사나 좀더 권력을 가진 조직에서 정해서 실제 구현하는 조직에게 통보되는 식이라 사실상 대부분의 프로젝트가 촉박한 시간에 실무자들에게 전달이 된다.

이런 상황에서는 업무파악, 프로세서 설계, 모듈과 라이브러리화, 형상관리, 개발자간의 크로스 체크, 통합테스트, 스트레스 테스트는 고사하고 단순히 코딩을 하기에는 벅찬 상황이 된다. 이런 상황에서 완벽한 프로젝트 수행이 가능하지 않다는 것은 당연하다. 보통 이런 구조적인 문제들을 실무자의 체력(?)과 정신력(?) 막아내는 것이 우리의 현실이다. 

프로젝트의 방향을 정확히 잡아주고 엉뚱한 방향으로 가지 않도록 지속적으로 관리만 해줘도 위험성은 대폭 사라진다.

현실과 미래 

90년대 우리나라도 10년전 일본이 그랬던 것처럼 경제적 풍요 속에 대규모 IT 프로젝트들이 진행되었다. 또IT강국으로 만든다는 정부의 정책에도 힘을 얹어서 다양한 규모의 IT업체들이 할거(?)했다. 많은 젊은이들이 컴퓨터 프로그램이나 컴퓨터 디자인을 배우기 위해 학원등록 창구에 줄을 섰다. 

2012년 지금, 90년대에 그렇게 IT분야에 말을 들였던 기업과 젊은이들의 반수 이상은 이 분야에서 사라졌다.업계에서는 함께 일할 만한 인력을 찾기 어렵다. 일단 이 분야는 대기업 일반 사무직에 비해 월급이 매우 낮고 일은 고되다 못해 죽을 것 같고. 관련 회사들도 불안정하다는 인식으로 일을 가르쳐 볼만한 신입인력이 없다.

경제의 거품이 꺼져 버려 길고 긴 길을 갈 것이다. 대 기업들도 쉽게 대규모 프로젝트를 기획하지 않는다. 시스템은 노후화되고 기본 구조파악과 개선 없이 주먹구구식으로 붙인 기능들은 언젠가 전체 시스템에 영향을 줄 것이다. 더 무서운 것은 구축 이후 변경된 것들에 대한 체계적인 문서화도 없고 담당자들도 수시로 변경이 되고 있어 어느 누구도 시스템을 전반적으로 아는 사람이 없다는 것이다. 그냥 잘 돌아가길 바랄 뿐이라고 해야 하나?

소위 ‘시스템의 블랙박스화’ 문제이다. 5, 10년 단위로 시스템을 교체해야 한다. 그러나 앞으로 경영상의 위험 문제로 시스템 노후화는 늘어갈 것이다. 그러나 앞에서 언급했듯이 IT시스템이 조직의 운명을 좌우하는 경우라면 경영진의 결단이 필요하다. 당장에 시스템 교체까지 계획하지 않더라도 운영과 리스크에 대한 관리체계 구축과 지속적인 점검도 경영진의 의지에 달려있다.

소 잃고 외양간 고쳐봐야 외양간 고친 수고만 아깝지 않을까?

뭐라고? 소는 다시 사면 된다고?