메뉴 바로가기 검색 및 카테고리 바로가기 본문 바로가기

한빛출판네트워크

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

한빛미디어

번역서

절판

  • 저자 : 『닛케이 컴퓨터』 편집부
  • 번역 : 이영희
  • 출간 : 2012-07-28
  • 페이지 : 224 쪽
  • ISBN : 9788979149333
  • 물류코드 :1933
  • 초급 초중급 중급 중고급 고급
3.7점 (3명)
좋아요 : 19
바보는 경험에서 배우고, 현자는 역사에서 배운다!
일본 3위 은행, 미즈호은행의 대규모 장애에서 배우는 시스템 관리 방법

2002년과 2011년에 두 번의 시스템 장애를 일으킨 미즈호은행의 시스템 장애 사건을 낱낱이 파헤치고 이와 같은 일을 반복하지 않기 위해 시스템 관리 방법과 경영 방식을 풀어내는 책이다. 나날이 블랙박스화되는 시스템, 프로젝트의 노후화 및 비대화, 경영진의 판단 오류 등의 문제를 어떻게 해결할 수 있을까? 정보화 종합 잡지인 『닛케이 컴퓨터』에 지난 20년간 실린 "동작하지 않는 컴퓨터" 컬럼을 정리한 십계명은 기업에게 필요한 것이 무엇인지 알려주고, 시스템 관리의 중요성을 다시 한번 강조한다.

대상 독자
  • 대규모 시스템을 사용하는 기업의 경영진
  • 프로젝트 매니저
  • SI 개발자와 관리자
  • 전산 관리자
닛케이 컴퓨터 편집부 저자

닛케이 컴퓨터 편집부

1981년 창간 이래 ‘동작하지 않는 컴퓨터’라는 칼럼을 연재하고 있다. 주로 정보시스템 개발의 실패나 시스템 장애 사례를 발굴하여 게재한다. 잠깐 연재를 중단하기도 했지만 2001년 초부터 다시 연재하기 시작했는데, 우연하게도 2001년 1회에 실은 내용이 미즈호파이낸셜그룹의 장애에 관한 기사였다. 시스템 장애가 반복해서 일어나는 악순환을 ‘이번에야말로’ 끊기 위해 이 책을 출간했다.
이영희 역자

이영희

현재 노틸러스효성 주식회사 금융솔루션사업 본부의 부장으로 재직 중이며, 다년간 일본 히다찌 및 관련 계열사와의 SI프로젝트 및 패기지 개발에 주력하였다. 최근에는 효율적인 프로젝트 관리 및 품질 관리에 초점을 두고 국제 품질 인증 심사의 하나인 CMMI기반의 사내 품질경영시스템을 구축하고 있으며, 그와 관련 사내 제안 및 계약 프로세스의 표준화를 위해 활동하고 있다.

1. 지진 재해 직후 또다시 찾아온 대규모 시스템 장애 _Chapter 01 미즈호은행 시스템 장애 검증, 괴로운 10일_Chapter 02 꼬리에 꼬리를 무는 섣부른 30가지 대처 _Chapter 03 이대로라면 세 번째 장애가 일어난다 2. 합병 직후 "설마했던" 대규모 장애 발생_ Chapter 04 현장 일임이 악의 근원이다_ Chapter 05 무리한 시스템 통합 계획 수립_ Chapter 06 대혼란의 2002년 4월3. 장애는 어디에든 있다 _ Chapter 07 금융기관의 잇따른 대규모 장애 _ Chapter 08 인명 피해로 이어질 수 있었던 장애  4. 시스템 장애와 싸운다 _ Chapter 09 기간계시스템의 위기_ Chapter 10 경영진이 운명을 좌우한다 _ Chapter 11 성패를 좌우하는 계획 수립_ Chapter 12 지금이야말로 프로젝트 관리가 필요하다 _ Chapter 13 시스템 가동은 또 다른 시작이다 

시스템 장애는 왜 두번 일어났을까?

일본의 미즈호 은행이라는 곳에서 일어난 시스템 장애 이야기이다. 이 은행은 10년 전에도 큰 장애가 한 번 있었다고 하는데 두 번째 장애는 바로 2011년에 일어났다. 두번째 장애가 일어나게 된 과정은 조금 재밌다.
작년 일본의 대지진과 쓰나미 사건이 기억나는가? 재난 이후 많은 의연금 이체가 미즈호 은행으로 들어왔는데 거기서 거래 건수가 상한값을 넘어 가버린 것이 모든 장애의 시발점이 된다.
장애를 처리 하는 과정에서 어이 없는 실수로 더 큰 장애를 발생시키고, 또 다시 잘못된 판단으로 또 상황을 더 안좋게 만드는 모습을 찾아볼 수 있다.
나는 당시 쓰나미에만 들었고 이런 일도 있었는지는 전혀 몰랐었다. 만약 그런 상황이 있었다는 것을 알고 있었다면 기억을 더듬어 보며 조금 더 재미있게 이 책을 읽었을 수도 있겠다.

책의 초반부에는 어떻게 시스템에서 장애가 났는지, 경영진들이 판단을 내리는 모습들을 잘 그려주어서 독자들에게 상황을 확인시켜주고, 후반부에서는 다른 회사들의 장애들에 대해서 소개해주며 이런 장애들을 예방하기 위해 나아가야할 방향을 제시한다. .

은행 사람들의 IT이야기라서 그런지 금융쪽에서 일하지 않아본 내게 약간의 이질감은 있지만 책 자체는 상당히 쉽게 쓰여져 있고 술술 읽히는 편이다. 그냥 재미로 한 번 읽어보기 바란다. 예전에 자신들이 크게 장애를 냈던 상황들을 한번씩 떠올려 보면서.

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



필자는 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시스템이 조직의 운명을 좌우하는 경우라면 경영진의 결단이 필요하다. 당장에 시스템 교체까지 계획하지 않더라도 운영과 리스크에 대한 관리체계 구축과 지속적인 점검도 경영진의 의지에 달려있다.



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


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

☆★☆ 책에 대한 전반적 느낌 ★☆★

시스템 장애는 왜 두번 일어났을까? 라는 제목을 보고 개발자의 현장 체험을 모은 책이라는 생각을 했다.

하지만 이 책은 미즈호은행의 시스템 장애를 바탕으로 반복적으로 발생하는 시스템 장애의 원인과 해결을 제시하고 있는 칼럼형식의 책이다.


개발자를 위한 책은 아니라는 생각이 든다.



회사업무 흐름과 의사결정에서 시스템 장애에 어떻게 대응해야 하는지 경영진들이 어떻게 대처해야 하는지 제시하고 있다.


☆★☆ 장점 ★☆★

은행업무에 관심이 있다면 어느정도 은행업무의 흐름을 파악할 수 있다는 생각이 든다.

실제로 일어났던 일본의 미즈호은행을 바탕으로 사건의 발생부터 진행까지 신문보도자료와 발표자료 등 사건의 해결을 위해 노력했던 당시 상황을 바탕으로 기술하고 있어 시스템 장애에 어떻게 대응해 나갔는지 흐름을 알 수 있다.


☆★☆ 단점 ★☆★


객관적 사실을 바탕으로 하고 있지만 서술의 진행이 저자의 개인적 의견 중심이다.

기술적인 시스템 장애 해결을 위한 내용은 기대하지 많아야 한다. 주로 시스템 장애가 발생 했을 때 경영진이 어떻게 대응하는 것이 바람직한지를 제시하고 있다.
또한 예시로 들어있는 신문기사의 칼럼은 책을 읽을 때 흐름을 끊기게 하는 단점이 있다.



☆★☆ 기타 의견★☆★

개발자를 위한 책이 아니라 경영진을 위한 책이라고 생각한다.

책은 은행전산을 바탕으로 설명을 하지만 IT관련 산업의 경영과 관련된 일을 한다면 읽어보면 좋을 책이라고 생각한다.

대응 방안은 경영자를 위한 제시이지만 은행업무의 흐름 파악과 발생할 수 있는 다양한 에러에 대해서 참고할 수 있는 점에선 좋다.



가볍게 읽을 수 있는 책이라고 생각한다.

결제하기
• 문화비 소득공제 가능
• 배송료 : 2,000원배송료란?

배송료 안내

  • 20,000원 이상 구매시 도서 배송 무료
  • 브론즈, 실버, 골드회원이 주문하신 경우 무료배송

무료배송 상품을 포함하여 주문하신 경우에는 구매금액에 관계없이 무료로 배송해 드립니다.

닫기

리뷰쓰기

닫기
* 도서명 :
시스템 장애는 왜 두 번 일어났을까? 미즈호은행, 동일본 쓰나미 그 후 시스템 장애에서 얻은 교훈
* 제목 :
* 별점평가
* 내용 :

* 리뷰 작성시 유의사항

글이나 이미지/사진 저작권 등 다른 사람의 권리를 침해하거나 명예를 훼손하는 게시물은 이용약관 및 관련법률에 의해 제재를 받을 수 있습니다.

1. 특히 뉴스/언론사 기사를 전문 또는 부분적으로 '허락없이' 갖고 와서는 안됩니다 (출처를 밝히는 경우에도 안됨).
2. 저작권자의 허락을 받지 않은 콘텐츠의 무단 사용은 저작권자의 권리를 침해하는 행위로, 이에 대한 법적 책임을 지게 될 수 있습니다.

오탈자 등록

닫기
* 도서명 :
시스템 장애는 왜 두 번 일어났을까? 미즈호은행, 동일본 쓰나미 그 후 시스템 장애에서 얻은 교훈
* 구분 :
* 상품 버전
종이책 PDF ePub
* 페이지 :
* 위치정보 :
* 내용 :

도서 인증

닫기
도서명*
시스템 장애는 왜 두 번 일어났을까? 미즈호은행, 동일본 쓰나미 그 후 시스템 장애에서 얻은 교훈
구입처*
구입일*
부가기호*
부가기호 안내

* 온라인 또는 오프라인 서점에서 구입한 도서를 인증하면 마일리지 500점을 드립니다.

* 도서인증은 일 3권, 월 10권, 년 50권으로 제한되며 절판도서, eBook 등 일부 도서는 인증이 제한됩니다.

* 구입하지 않고, 허위로 도서 인증을 한 것으로 판단되면 웹사이트 이용이 제한될 수 있습니다.

닫기

해당 상품을 장바구니에 담았습니다.이미 장바구니에 추가된 상품입니다.
장바구니로 이동하시겠습니까?

자료실