2018.07.19

IT 전문가들이 두려워하는 '시궁창' 프로젝트 상황 6가지

Dan Tynan | CIO

잘해야 본전이고 자칫하면 나락으로 떨어질 수 있는 IT 프로젝트들이 있다. 구형 시스템 패치, 클라우드로의 이메일 전환, ERP 업그레이드와 같은 것들이 대표적이다.

대부분의 IT전문가들이 두려워하는 프로젝트들이 있다. 지식이나 평판에 도움되지 않으면서도 힘들기만 한, 그러나 필수적인 작업들이 그렇다. 가령 패치 관리는 화려하지 않지만 실패하면 조직이 엄청난 보안 유출을 겪게 된다. 클라우드로의 이메일 마이그레이션 프로젝트는 매력적이지 않은 경우가 많지만 2018년에 이메일 서버를 내부에 둘 이유도 없다. ERP(Enterprise Resource Planning) 이행과 업그레이드는 흔히 발생하는 IT프로젝트 실패 사례지만 그렇다고 ERP시스템을 방치할 수도 없다.

기술 자체이 지옥 같은 IT프로젝트의 기저 원인인 경우는 거의 없다. 비 현실적인 기대치, 적절한 범위 설정 실패, 문화적 충돌, 미루기, 상부의 적절한 지원 부재 때문에 기술 계획이 혼란이 빠지는 경우가 더 많다. 회피하고 싶지만 회피할 수 없는 IT 프로젝트 사례와 가능한 해법을 정리했다.



1. 마지막 순간의 엄청난 패치
패치는 거의 모든 IT전문가가 싫어하는 필수적이며 따분한 일이다. 그러나 미루다보면 에퀴팩스(Equifax)에서와 같은 사태가 발생할 수 있다.

IT서비스 제공 기업 알바카 네트웍스(Alvaka Networks)의 CEO 올리 토르다슨은 "수 개월 또는 수 년 동안 패치가 이루어지지 않은 대형 프로젝트를 넘겨 받고 한다. 때로는 수 백 개의 생산 서버와 개발 및 시험 서버일 수 있다. 무엇인가 잘못되면 한 브랜드의 거대한 인터넷 존재감이 사라질 수 있다는 사실을 알기 때문에 스트레스가 심하다. 이 때문에 내부 직원들이 때로는 패치를 미루다가 어느 날 갑자기 경영진이 상황을 살펴보고 상황이 너무 심각하다는 사실을 깨닫게 된다"라고 말했다.

몇 년 전 알바카는 도시 경찰 부서의 대규모 윈도우 패치 프로젝트를 수행하고 있었다. 일반 직원의 데스크톱에는 모든 것이 잘 진행됐다. 하지만 경찰서장, 지서장, 부서장의 PC가 모두 다운되었고 그들은 불만족스러워했다.

토르다슨은 "경찰서의 고위 간부들은 거리낌이 없다. 로그인하여 해야 할 일을 하지 못하기 때문에 우리에게 전화를 걸어 요청한다"라고 말했다.

그들은 약간 다른 기기와 함께 제 3자 앱을 사용하고 있었고 이것이 충돌을 일으켰던 것으로 밝혀졌다. 토르다슨의 팀은 패치를 롤백(Roll Back)하고 문제를 분리하여 30분 만에 해결할 수 있었다. 하지만 30분 동안 긴장과 스트레스가 최고조에 달했다.

최악의 패치 작업은 시스템을 수 년 동안 방치한 것이었다고 알바카의 CTO 우나 가다슨이 말했다.

"무엇인가를 패치했는데 서버 재부팅에 비정상적으로 오래 걸리거나 재부팅이 아예 되지 않는 경우에는 '이런 젠장'이라는 생각이 든다. 때로는 가상머신 복구 콘솔로 이동하여 서버를 살펴보아야 한다. 다른 환경에서는 패치를 하고 잘 되기를 바랄 수밖에 없다"라고 그는 말했다.

교훈 : 최악의 상황 시나리오를 피하기 위해서는 모든 단일 시스템을 고려하여 엄격하게 시험한 백업 계획을 수립하도록 더욱 노력하는 것이다.

가다슨은 "패치 작업을 할 때마다 일반 백업과 추가적인 스냅샷부터 사람들에게 알리고 서비스를 정지하는 것까지 모든 것을 고려한 백업 계획이 있어야 한다. 일부 시스템은 지나치게 까다로우며 오프라인 과정이 매우 구체적이다. 준비하고 가능한 모든 시나리오를 고려하는 것이 중요하다"라고 말했다.

2. 클라우드로의 대규모 이메일 마이그레이션
온프레미스 이메일 솔루션에서 클라우드로의 이동은 이론상으로 쉬워 보인다. 하지만 결코 그렇지 않다고 의료 IT 보안 컨설팅 기업 시큐어HIM(SecureHIM)의 CEO 마이크 마이클이 말했다.

우선 사용자가 축적한 것이 있다. 수 년 전에 삭제했어야 하는 수 기가바이트의 메시지가 있기 때문에 데이터의 용량 자체가 벅차다. 로터스 노츠(Lotus Notes) 등의 레거시(Legacy) 시스템에서 이동하는 경우 엄청난 데이터 변환이 필요하다. 이런 메시지에 포함된 정보 중 일부는 매우 민감하며 통제를 받기 때문에 HIPAA, GDPR, SOX, 기타 규정을 준수해야 한다.

마이클 자신도 클라우드 마이그레이션에 1년 이상이 소요되고 많은 수작업이 요구됐던 업무를 경험한 적 있다고 전했다.

그는 "이메일은 매우 보편적이기 때문에 어떤 식으로든 마이그레이션이 실패하면 IT가 즉시 칼침을 맞게 된다. 슬랙과 기타 팀 채팅 앱의 시대에도 이메일 마이그레이션은 IT가 두려워하는 프로젝트 중 하나다”라고 말했다.

교훈 : 다른 지옥 같은 IT프로젝트와 마찬가지로 미리 숙제를 하는 것이 중요하다. 시스템 또는 장치 요건을 완전히 터득하도록 하고 개념 증명과 시범 운영을 위한 고급 사용자 핵심 그룹을 운영하여 대부분의 문제를 미리 해결하는 방안을 강구한다. 마이클은 "IT가 가서 보고 '괜찮아 보이는데.'라고 말해서 될 일이 아니다. 정말로 사용자 요건과 그들이 무엇을 허용할지를 알아야 한다"라고 말했다.

3. 태어날 때부터 고아인 준수성 의무
IT프로젝트에는 두 가지가 있다. 경영진의 강력한 지원을 받는 것과 그렇지 않은 것이다. 가장 지옥 같은 종류는 아마도 직원이 준수성을 위해 각종 분쟁에 휘말리고 있는데, 상부의 지원이 거의 없는 것이다.

한 IT서비스 기업의 이사 쉘든 C.(가명)는 "경영진이 의무화했지만 제대로 지원하지 않는 규제 지향적인 프로젝트가 최악이다"라고 말했다. (그는 이전 동료들이 알아보지 못하도록 익명을 요구했다.)

약 1년 전까지만 하더라도 쉘든은 웨스트 코스트(West Coast)에 소재한 한 대형 금융기관의 기술VP였다. 그가 이 기업에 합류했을 때는 이미 규제기관의 표적이 되어 있었다. 부적절한 재난 복구 계획 때문이었다. 활동적인 주주들은 해당 기관이 이를 해결하도록 몰아붙였고 경영진이 프로젝트를 지원하기는 했지만 부서장들은 우선순위가 제각각이었다. DR이 최우선순위로 인정받지 못했다.

결국 현업 부서장들은 제대로 참여하지 않았다. 그들은 시스템 대체 작동과 복구 우선순위를 위한 부서 요건을 제출하거나 업무에 필수적인 데이터와 앱을 식별하지 못했다. 그들은 예비 또는 사전 시험에 참여하지 않았다. 그들은 쉘든의 이메일을 무시했다.

IT부서가 요청했기 때문에 부서장들은 이를 무시하기 일쑤였고 프로젝트 후원자들은 쉘든에게 아무런 도움도 주지 않았다.

그는 "이런 상황이 있으니 제발 도와 달라고 임원진에 요청했다. 그러나 원활히 소통되지 못했으며 겉도는 대화가 오갈 뿐이었다. 각종 문제들이 인정받지도, 해결되지도 못한 채 프로젝트가 진행되어야 했다"라고 회고했다.

교훈 : 모든 과정을 문서화하는 것이 기본이다. 동시 ㅔ정보를 적절한 사람들에게 배포하여 프로젝트 지원자가 나중에 무시했다고 주장할 수 없도록 해야 한다.

그리고 그렇게 해도 효과가 없으면 손실을 막아야 한다. 쉘든의 경우 가능한 신속하게 새로운 자리로 이동하는 것이었다.

그는 "재미있는 점은 CIO가 DR프로젝트를 대성공이었다고 생각했다는 점이다. 나는 표창을 받았다. 하지만 실제로 감사측이 자세히 들여다보면 변명해야 할 일이 부지기수였다. 기업 문화가 문제의 원인이라면 떠날 때가 된 것이다"라고 말했다.

-> ‘회사를 떠나야 할 때’ 시만텍 조직개편의 교훈
-> '연봉? 상사? 발전성?' 유능한 직원들이 떠나는 이유

4. 육두문자 ERP
새로운 ERP시스템을 이행하는 것보다 더 큰 분노나 불만을 유발하는 단일 프로젝트는 없을 것이다.

2018.07.19

IT 전문가들이 두려워하는 '시궁창' 프로젝트 상황 6가지

Dan Tynan | CIO

잘해야 본전이고 자칫하면 나락으로 떨어질 수 있는 IT 프로젝트들이 있다. 구형 시스템 패치, 클라우드로의 이메일 전환, ERP 업그레이드와 같은 것들이 대표적이다.

대부분의 IT전문가들이 두려워하는 프로젝트들이 있다. 지식이나 평판에 도움되지 않으면서도 힘들기만 한, 그러나 필수적인 작업들이 그렇다. 가령 패치 관리는 화려하지 않지만 실패하면 조직이 엄청난 보안 유출을 겪게 된다. 클라우드로의 이메일 마이그레이션 프로젝트는 매력적이지 않은 경우가 많지만 2018년에 이메일 서버를 내부에 둘 이유도 없다. ERP(Enterprise Resource Planning) 이행과 업그레이드는 흔히 발생하는 IT프로젝트 실패 사례지만 그렇다고 ERP시스템을 방치할 수도 없다.

기술 자체이 지옥 같은 IT프로젝트의 기저 원인인 경우는 거의 없다. 비 현실적인 기대치, 적절한 범위 설정 실패, 문화적 충돌, 미루기, 상부의 적절한 지원 부재 때문에 기술 계획이 혼란이 빠지는 경우가 더 많다. 회피하고 싶지만 회피할 수 없는 IT 프로젝트 사례와 가능한 해법을 정리했다.



1. 마지막 순간의 엄청난 패치
패치는 거의 모든 IT전문가가 싫어하는 필수적이며 따분한 일이다. 그러나 미루다보면 에퀴팩스(Equifax)에서와 같은 사태가 발생할 수 있다.

IT서비스 제공 기업 알바카 네트웍스(Alvaka Networks)의 CEO 올리 토르다슨은 "수 개월 또는 수 년 동안 패치가 이루어지지 않은 대형 프로젝트를 넘겨 받고 한다. 때로는 수 백 개의 생산 서버와 개발 및 시험 서버일 수 있다. 무엇인가 잘못되면 한 브랜드의 거대한 인터넷 존재감이 사라질 수 있다는 사실을 알기 때문에 스트레스가 심하다. 이 때문에 내부 직원들이 때로는 패치를 미루다가 어느 날 갑자기 경영진이 상황을 살펴보고 상황이 너무 심각하다는 사실을 깨닫게 된다"라고 말했다.

몇 년 전 알바카는 도시 경찰 부서의 대규모 윈도우 패치 프로젝트를 수행하고 있었다. 일반 직원의 데스크톱에는 모든 것이 잘 진행됐다. 하지만 경찰서장, 지서장, 부서장의 PC가 모두 다운되었고 그들은 불만족스러워했다.

토르다슨은 "경찰서의 고위 간부들은 거리낌이 없다. 로그인하여 해야 할 일을 하지 못하기 때문에 우리에게 전화를 걸어 요청한다"라고 말했다.

그들은 약간 다른 기기와 함께 제 3자 앱을 사용하고 있었고 이것이 충돌을 일으켰던 것으로 밝혀졌다. 토르다슨의 팀은 패치를 롤백(Roll Back)하고 문제를 분리하여 30분 만에 해결할 수 있었다. 하지만 30분 동안 긴장과 스트레스가 최고조에 달했다.

최악의 패치 작업은 시스템을 수 년 동안 방치한 것이었다고 알바카의 CTO 우나 가다슨이 말했다.

"무엇인가를 패치했는데 서버 재부팅에 비정상적으로 오래 걸리거나 재부팅이 아예 되지 않는 경우에는 '이런 젠장'이라는 생각이 든다. 때로는 가상머신 복구 콘솔로 이동하여 서버를 살펴보아야 한다. 다른 환경에서는 패치를 하고 잘 되기를 바랄 수밖에 없다"라고 그는 말했다.

교훈 : 최악의 상황 시나리오를 피하기 위해서는 모든 단일 시스템을 고려하여 엄격하게 시험한 백업 계획을 수립하도록 더욱 노력하는 것이다.

가다슨은 "패치 작업을 할 때마다 일반 백업과 추가적인 스냅샷부터 사람들에게 알리고 서비스를 정지하는 것까지 모든 것을 고려한 백업 계획이 있어야 한다. 일부 시스템은 지나치게 까다로우며 오프라인 과정이 매우 구체적이다. 준비하고 가능한 모든 시나리오를 고려하는 것이 중요하다"라고 말했다.

2. 클라우드로의 대규모 이메일 마이그레이션
온프레미스 이메일 솔루션에서 클라우드로의 이동은 이론상으로 쉬워 보인다. 하지만 결코 그렇지 않다고 의료 IT 보안 컨설팅 기업 시큐어HIM(SecureHIM)의 CEO 마이크 마이클이 말했다.

우선 사용자가 축적한 것이 있다. 수 년 전에 삭제했어야 하는 수 기가바이트의 메시지가 있기 때문에 데이터의 용량 자체가 벅차다. 로터스 노츠(Lotus Notes) 등의 레거시(Legacy) 시스템에서 이동하는 경우 엄청난 데이터 변환이 필요하다. 이런 메시지에 포함된 정보 중 일부는 매우 민감하며 통제를 받기 때문에 HIPAA, GDPR, SOX, 기타 규정을 준수해야 한다.

마이클 자신도 클라우드 마이그레이션에 1년 이상이 소요되고 많은 수작업이 요구됐던 업무를 경험한 적 있다고 전했다.

그는 "이메일은 매우 보편적이기 때문에 어떤 식으로든 마이그레이션이 실패하면 IT가 즉시 칼침을 맞게 된다. 슬랙과 기타 팀 채팅 앱의 시대에도 이메일 마이그레이션은 IT가 두려워하는 프로젝트 중 하나다”라고 말했다.

교훈 : 다른 지옥 같은 IT프로젝트와 마찬가지로 미리 숙제를 하는 것이 중요하다. 시스템 또는 장치 요건을 완전히 터득하도록 하고 개념 증명과 시범 운영을 위한 고급 사용자 핵심 그룹을 운영하여 대부분의 문제를 미리 해결하는 방안을 강구한다. 마이클은 "IT가 가서 보고 '괜찮아 보이는데.'라고 말해서 될 일이 아니다. 정말로 사용자 요건과 그들이 무엇을 허용할지를 알아야 한다"라고 말했다.

3. 태어날 때부터 고아인 준수성 의무
IT프로젝트에는 두 가지가 있다. 경영진의 강력한 지원을 받는 것과 그렇지 않은 것이다. 가장 지옥 같은 종류는 아마도 직원이 준수성을 위해 각종 분쟁에 휘말리고 있는데, 상부의 지원이 거의 없는 것이다.

한 IT서비스 기업의 이사 쉘든 C.(가명)는 "경영진이 의무화했지만 제대로 지원하지 않는 규제 지향적인 프로젝트가 최악이다"라고 말했다. (그는 이전 동료들이 알아보지 못하도록 익명을 요구했다.)

약 1년 전까지만 하더라도 쉘든은 웨스트 코스트(West Coast)에 소재한 한 대형 금융기관의 기술VP였다. 그가 이 기업에 합류했을 때는 이미 규제기관의 표적이 되어 있었다. 부적절한 재난 복구 계획 때문이었다. 활동적인 주주들은 해당 기관이 이를 해결하도록 몰아붙였고 경영진이 프로젝트를 지원하기는 했지만 부서장들은 우선순위가 제각각이었다. DR이 최우선순위로 인정받지 못했다.

결국 현업 부서장들은 제대로 참여하지 않았다. 그들은 시스템 대체 작동과 복구 우선순위를 위한 부서 요건을 제출하거나 업무에 필수적인 데이터와 앱을 식별하지 못했다. 그들은 예비 또는 사전 시험에 참여하지 않았다. 그들은 쉘든의 이메일을 무시했다.

IT부서가 요청했기 때문에 부서장들은 이를 무시하기 일쑤였고 프로젝트 후원자들은 쉘든에게 아무런 도움도 주지 않았다.

그는 "이런 상황이 있으니 제발 도와 달라고 임원진에 요청했다. 그러나 원활히 소통되지 못했으며 겉도는 대화가 오갈 뿐이었다. 각종 문제들이 인정받지도, 해결되지도 못한 채 프로젝트가 진행되어야 했다"라고 회고했다.

교훈 : 모든 과정을 문서화하는 것이 기본이다. 동시 ㅔ정보를 적절한 사람들에게 배포하여 프로젝트 지원자가 나중에 무시했다고 주장할 수 없도록 해야 한다.

그리고 그렇게 해도 효과가 없으면 손실을 막아야 한다. 쉘든의 경우 가능한 신속하게 새로운 자리로 이동하는 것이었다.

그는 "재미있는 점은 CIO가 DR프로젝트를 대성공이었다고 생각했다는 점이다. 나는 표창을 받았다. 하지만 실제로 감사측이 자세히 들여다보면 변명해야 할 일이 부지기수였다. 기업 문화가 문제의 원인이라면 떠날 때가 된 것이다"라고 말했다.

-> ‘회사를 떠나야 할 때’ 시만텍 조직개편의 교훈
-> '연봉? 상사? 발전성?' 유능한 직원들이 떠나는 이유

4. 육두문자 ERP
새로운 ERP시스템을 이행하는 것보다 더 큰 분노나 불만을 유발하는 단일 프로젝트는 없을 것이다.

X