전산 장애를 최소화하는 방법

몇일 전 아이패드에서 전자 신문을 보다가 "전산장애" 에 관한 기사가 나왔다.
신문 기사의 은행에서뿐만 아니라 최근에 다른 증권사 장애도 본 적이 있고 개인적으로 크고 작은 경험이 있어 눈길이 가는 기사였다.

http://www.etnews.com/201201100046 

이러한 현상은 신상품 개발 및 새로운 규제적용으로 프로그램 수정이 빈번해지는 반면에 상시적으로 테스트가 이뤄지지 않기 때문이다. 대부분 은행 전산장애는 수정된 프로그램이 미치는 영향에 대해 사전 파악이 안 된 상태에서 구동해 발생했다. 농협 한 관계자는 “수정된 프로그램이 전면적인 장애를 일으킬 만큼 중요한 프로그램이 아니라고 판단해 수정 후 즉시 적용했다”고 답했다. 
   

문제는 여러가지가 있겠지만 크게 본다면 테스트 부족과 단순실수 두가지로 모아진다고 생각이 든다.

첫번째, 테스트 부족
현재의 은행, 증권, 보험은 업무의 연관/복잡화 되어있다.
따라서 하나의 소스가 여러 부서에서 사용하는 화면, 배치 그리고 실시간 처리 업무에서 호출될 수도 있고
조회하는 하나의 컬럼값이 하나의 업무로 인해 생성되는 값도 있겠지만 그렇지 않은 경우도 많다. 

 따라서 하나의 화면, 배치, 테이블, 컬럼 값들의 whole process 관점에서 연관 업무를 정리하고 제도개선이나 현업
요청건이 있을 때 BR(Business Relationship) 부서에서 대략적인 분석 후 개발 진행이 되어야 하지 않을까 한다.
또한 테스트도 그러한 기반하에 진행이 되어야 할 것이다.

ING Korea 에서 근무할 때 이러한 것으로 잠시 혼란과 힘들었던 점이 있었다.
하나의 테스트를 하기 위해서는 증권사 경우 오라클 등 데이터베이스 서버의 해당 테이블에 과거 값이나
운영 데이터를 넣어서 하는 경우가 빈번했었다.
그러한 경험을 가지고 접근하니 문화적 차이를 느낀 적이 있었지만
whole test 관점에서 본다면 ING Korea 에서 방법도 맞다.
해약 테스트를 하기 위해서 가입설계, 청약, 납입, 추가납, 그리고 몇년 돌려서 수익률 변하게 하고 그제야
해약 테스트 진행.

은행은 아직 경험이 없어 모르겠지만 증권은 개인적으로 이런 방식이 다소 생소할걸로 생각이 든다.
어쩌면 그것은 증권은 너무나 실시간 환경이라 "빨리 빨리" 라는 문화 때문이 아닐런지한다.

아니면, 해당 프로세스를 전반적으로 꿰차고 있을 수도 있고.
하지만 긴급 상황이 아니면 장애없는 운영을 위해서는 다소 불편하고 시간이 걸려도 whole test  가 필요할듯싶다.

두번째, 단순실수
이건 확실한 인재가 맞아 딱히 프로세스화하기 힘든 면이 있지만 경우에 따라서는 몇가지 유형별로 가능할 수 있다.
흔한 케이스는 사람이 운영하는 화면의 조작 실수, 반영 목록의 누락 등 흔히 접할 수 있는 것들이 많다.
팀원간의 cross check, 조작 컴퓨터의 권한이나 구동 프로그램의 제한과 조작 실수를 통계화나 팀원 리뷰를 통해서 발생 가능한 경우를 찾아 사전에 프로그램 수정으로 막을 수 있는 업무 환경이 되면 어떨까 한다.
무엇보다 중요한 건 이러한 노력은 티도 잘 나지 않고 신경쓰는 부분도 아닌다.
개인의 열정이 없으면 할 수 없는 일이므로 조직 차원에서 그런 노고를 한 직원을 보상해준다면 개인적으로 자부심도
느끼며 그러한 열정이 조직 모두에게 전파되지 않을까 하는 생각도 아울러 한다.

유지보수 인력이더라도 좀 더 대우받고 또 숨겨져있는 그들의 열정을 끄집어낼 수 있는 "꺼리" 를 찾고 생각한다면
일개 '과장' 직급으로선 오지랖 넓은 생각일까...