리버스엔지니어링(Reverse engineering)은 제품이나 소프트웨어를 역추적하여 제품개발기술이나 소스 코드를 찾아내는 방법이다. 기업 내부 목적, 군사적 목적 또는 해킹의 목적으로 다양하게 사용되고 있다.
IT조직은 내부프로세스들을 통해 ‘IT’라는 제품을 사용자에게 제공하고 있다. 그런데 이런 제품에 결함이나 중단과 같은 부정적인 사고가 발생하게 되면, 사고의 원인을 찾아내기 위해서는 IT의 프로세스를 역추적할 수 밖에 없다.
하지만 IT조직이 구축하고 있는 프로세스들이, 이러한 역추적이 가능하도록 해주는 체계과 데이터를 제공하고 있지 않다면, 리버스엔지니어링에 ‘준하는’ 연구분석 활동을 통해서만 사고의 원인을 찾아낼 수가 있다.
이번 칼럼에서는 역추적을 어렵게 만드는 IT조직의 프로세스에 대해 이야기해보겠다.
■어플리케이션 결함에 대한 역추적
어플리케이션의 결함이 발생하는 경우를 예를 들어보자.
고객 정보를 조회하기 위해 특정 화면의 버튼을 클릭했으나, 오류 화면이 발생했다는 사용자의 신고가 접수되었다면, 일반적으로 어플리케이션 담당자나 고객정보를 조회할 수 있도록 우선적인 조치를 취하게 된다. 결함이나 서비스 중단등에 대해서 근본 원인 조사를 반드시 수행하는 IT조직의 경우는, 우선적인 조치 이후, 독립적인 사고 관리자가 분석에 나서게 된다.
사고 관리자는 우선 해당 사건의 원인을 찾게 된다. 사건을 둘러싼 용의자들, 즉 프로그램, 데이터베이스 및 서버들의 최근 활동들을 조사하면서 사건의 직접적인 발생 원인을 찾게 된다. 이러한 조사과정에서 들여다보게 되는 것들이 일반적으로 ‘변경 및 릴리즈프로세스’와 관련 ‘기록’들이다.
■공식적인 배포과정을 거치지 않은 결함
사건의 직접적인 원인이 ‘잘못된 로직을 사용하게 된 프로그램 문제’라고 하자. 그렇다면 사고 관리자는 해당 프로그램이 출시된 과정을 검증하게 된다. 그런데 놀랍게도 해당 프로그램은 공식적으로 배포과정을 거치지 않았다는 사실을 발견한다. 최근 프로그램 개발자들이 폭주하는 사용자들의 개발요청으로 공식 배포과정을 거치지 않고 배포한 프로그램 중의 하나인 것이다.
또, 사고 관리자는 공식 배포과정을 거치지 않고 개발자들이 어떻게 운영(Live) 환경의 프로그램 배포처에 접근할 수 있었는지에 대해 조사를 한다. 조사 결과, 개발자들 중의 일부는 운영환경에 접근할 수 있는 공용 계정과 패스워드를 알고 있다는 사실을 발견하게 된다. 이 계정은 일전에 개발자들과 서버운영자들이 공동 작업하면서 사용했던 것으로 확인되었다.
■공식적인 배포과정을 거친 결함
만약 프로그램의 출시된 과정을 검증한 결과, 공식적인 배포과정을 거친 것으로 확인된 경우는, 조금 다른 방법으로 조사가 전개된다. 공식적인 배포과정에서는 프로그램에 대한 테스트 과정을 거치도록 되어 있는데, 어떻게 이 프로그램이 이 과정에서 통과가 된 것인지를 확인하게 된다.
배포과정에서 작성된 테스트 결과를 검토한 결과, 테스트 항목에는 테스트 여부만 기록하게 되어 있을 뿐, 개별 화면별 또는 버튼별 기능을 테스트하고, 그 결과를 기록하도록 하는 수준까지는 요구하고 있지 않았다는 것을 발견하였다.
■결함에 대한 처방
사고관리자는 공식배포과정을 거치지 않은 경우와 공식배포과정을 거친 경우에 대해서는 재발 방지를 위한 서로 다른 처방을 내리게 된다.
공식배포과정을 거치지 않은 경우에 대해서는 개발자가 우회할 수 있는 경로를 차단하는 처방을 내리고, 공식배포과정을 거친 경우에 대해서는 테스트 항목을 상세한 수준으로 작성하여 검증가능하도록 하는 처방을 내리게 된다.
■역추적이 불가능한 IT조직
지금까지의 얘기는, 이상적인 IT조직의 역추적과정을 들여다 본 것이다.
현실의 IT조직은 어떨까?
다 그렇지는 않지만, 일부 IT조직들은 어플리케이션 결함이 발생하더라도 근본원인을 찾는 활동을 하지 않는다. 그냥 프로그램을 고쳐서 상황을 해결하면 사건은 종료된다.
또, 프로그램을 공식적으로 배포하는 과정 또는 프로세스를 가지고 있지 않거나, 있더라도 잘 지켜지지 않는다. 만약 위에서 언급한 사고관리자가 이런 IT조직에서 사건의 근본 원인을 추적하는 업무를 맡게 된다면, 초기단계에서 좌절할 수 밖에 없다.
개발자가 임의로 운영 환경에 접근하여 배포할 수 있으며, 배포하다가 실패하면, 이것 조차 마음대로 바꾸어버릴 수 있으며, 배포하기전에 테스트를 수행하지 않거나, 테스트를 수행하더라도, ‘예스/노’의 수준으로 테스트 기록을 유지하고 있는 IT조직에서는, 사고관리자가 사건을 역추적해서 근본원인을 찾기도 어렵고, 설령 찾는다고 하더라도, 사건의 재발을 방지하기 위한 대책은 공허하게 여겨지게 될 수 밖에 없다.
■역방향 검증이 가능한 IT프로세스
IT를 제공하기 위해서는 일반적으로 생산에 초점을 둔 ‘정방향’의 프로세스에 관심을 가질 수 밖에 없다. 하지만 IT의 결함이나 중단이 발생한 경우, 이에 대한 근본원인 분석과 재발방지를 위해서는 역방향으로 프로세스를 거슬러 갈 수 있도록 해야 한다.
역방향으로 추적하는 것이 어려운 IT프로세스는, 대체로 정방향의 프로세스가 긴밀하게 연결되어 있지 않거나, 데이터가 불충분하다고 보면 된다.
견고한 IT프로세스를 원하는 IT경영자가 있다면, 역방향으로의 추적가능성을 검증하는 과정에서, 정방향으로의 프로세스 탄력성을 높일 수 있으며, 프로세스를 운영하면서 남기게 되는 기록의 디테일을 결정할 수 있는 효과를 얻을 수 있다.
IT담당자들은 본인이 프로세스를 준수하게 되면 얻는 ‘이득’이 납기 준수나 성과 달성의 ‘이득’보다 낮다고 생각하는 경향이 있다. 또, 상세한 기록을 남기는 것이 어디에 소용될 것인지에 대해 납득하지 못하고 있는 경우가 많다.
IT프로세스를 준수하는 것과 적절한 기록을 남기는 것이 중요하고 꼭 필요하다는 것을, IT담당자들이 받아들 일 수있도록 하는 것도 IT경영자의 몫으로 생각한다.
수 년의 시간이 지나도, 별로 나아지지 않는 IT조직의 공통적인 특성은, 유독 생산이나 납기준수와 같은 한 방향의 활동에만 몰입한다는 점이다. 사용자 요구사항을 만족하는 것이 최우선이라는 나름의 이유를 내세우고 있지만, 사용자들은 이미 그들이 사용하고 있는 IT가 좋은 품질이 아니라는 것을 알고 있다.
이런 IT조직이 갑자기 비용에 대해 따지게 된다면, 사용자들은 어떤 생각을 하게 될까?
*본 칼럼 내용은 본지 편집방향과 다를 수 있습니다.
