칼럼 | 지금 바로 손대야 할까? IT 현대화 성공을 위한 5단계 가이드

IT 포트폴리오 현대화의 필요성을 주장하는 것은 자동차의 엔진오일을 교체해야 한다는 말과 크게 다르지 않다. 하지 않으면 언젠가 엔진이 망가지기 때문이다.

하지만 이를 지금 바로 실행할 때의 투자 대비 효과(ROI)는 어떨까? 이는 일종의 확률 싸움이다. 현대화를 미루면 언젠가 문제가 발생할 것이라는 통계적 가능성은 높아진다. 하지만 그 시점이 언제가 될지는 불확실하다.

CIO 자리에 얼마나 오래 머물 계획인지에 따라, 지금부터 설명하는 내용을 고민하지 않아도 될 수 있다. 골치 아픈 일을 다음 사람에게 미루며 시간을 벌 수도 있다.

1단계: 보유 자산을 문서화하라

IT 현대화의 출발점은 현재 보유한 자원을 정확히 아는 것이다. 이상적으로는 체계적으로 정비되고 관리되는 CMDB(구성관리 데이터베이스) 안에 모든 정보가 보관돼 있어야 한다. 하지만 수년간 이 정보를 요청해 온 경험에 따르면, 신뢰할 수 있고 최신 상태로 유지되는 CMDB는 마치 신비생물학자(cryptobiologist)가 ‘네스호 괴물’을 찾는 일처럼 발견하기 어려웠다.

이른바 IT 신비생물학자 대열에 합류하지 않으려면, 가장 먼저 해야 할 일은 IT가 관리하는 애플리케이션 목록과 그에 연결된 기술 스택을 정리하는 것이다. 여기에는 각 애플리케이션이 지원하는 비즈니스 아키텍처, 그리고 의존하는 저장소, 통합 시스템, 플랫폼, 인프라, 물리적 설비 등이 포함된다.

2단계: IT 자산의 향후 조치를 결정하라

‘디스포지셔닝(dispositioning)’이란 앞서 문서화한 각 자산의 향후 조치를 결정하는 작업을 의미한다. 먼저 기능이나 성능에 심각한 결함이 있는 애플리케이션부터 살펴볼 필요가 있다. 해당 시스템이 비즈니스에 충분한 가치를 제공하지 못하고 있다는 의미이기 때문이다.

선택할 수 있는 조치는 8가지다.

• 확장: 해당 자산이 제공하는 가치를 높이기 위해 추가로 투자한다.
• 유지: 자산을 계속 유지하되, 작동에 필요한 최소한의 유지보수를 수행한다.
• 업데이트: 상용 애플리케이션의 경우, 벤더가 권장하는 최신 버전과 차이가 없도록 업데이트한다.
• 교체: 기능이 동일하거나 더 우수한 상용 솔루션으로 전환한다. 필요에 따라 맞춤형 개발을 선택할 수도 있지만, 대부분의 IT 조직에서는 ‘가능하면 구매하고 꼭 필요할 때만 개발하라’는 원칙이 기본 설계 기준으로 자리 잡고 있다.
• 현대화: 애플리케이션을 현대 아키텍처 및 엔지니어링 표준과 관행에 맞도록 리팩토링한다.
• 리플랫폼: 더 비용 효율적인 환경으로 재구성한다. 예를 들어, 코볼(COBOL) 애플리케이션은 그대로 유지하되, 기존의 Z/OS 대신 RHEL 10처럼 더 선호되는 플랫폼에서 실행되도록 재컴파일할 수 있다. 단, 리플랫폼에는 한계가 있다. 많은 IT 조직이 ‘리프트 앤 시프트’ 방식으로 애플리케이션을 새로운 플랫폼으로 이전했지만, 이 과정이 실제 현대화와는 거리가 멀다는 사실을 깨달았다.
• 통합: 비슷한 기능을 수행하는 여러 애플리케이션이 존재하는 경우, 하나를 표준 시스템으로 지정하고 나머지를 통합한다.
• 폐기: 더 이상 필요하지 않은 애플리케이션은 데이터를 보관한 뒤 시스템에서 제거한다. 단, 누군가 사용하고 있는 것은 아닌지 반드시 확인해야 한다.

3단계: 상호 의존성과 파급 효과에 주의하라

하나의 애플리케이션에 대한 조치만으로는 충분하지 않은 경우가 대부분이다. 조치가 다른 애플리케이션이나 기술 스택, 특히 해당 애플리케이션이 의존하는 플랫폼까지 연쇄적으로 영향을 미칠 가능성이 높기 때문이다.

특히 비즈니스와 직접 연결된 애플리케이션을 변경하면 다른 앱에도 영향을 주는 것은 물론, 하나 이상의 통합 시스템이 깨질 가능성도 매우 높다. 여기서 중요한 다음 단계로 넘어가 보자.

4단계: 통합 시스템을 관리하라

통합 시스템은 애플리케이션 포트폴리오 내에서도 특별한 영역이다. 대부분 맞춤형 코드로 구현돼 있으며, 구조가 취약하고 불안정한 경우가 많고, 일단 문제가 발생하면 복구되더라도 정상 작동 여부를 검증하기 어렵다.

특히 통합 시스템은 시스템마다 같은 용어를 다르게 정의하는 경우가 많아 문제가 생기기 쉽다. 예를 들어 어떤 CRM 솔루션은 고객을 ‘개인’으로 간주하고, 또 다른 시스템은 가구, 기업, 또는 고객사의 주요 담당자로 정의한다. 이런 시스템 간의 데이터베이스를 동기화하는 일은 결코 간단하지 않다.

여기에 비즈니스 전략이 B2C 소매 중심에서 B2B 도매 모델로 전환되기라도 하면, 통합 구조 전반을 다시 설계해야 하는 상황에 직면하게 된다.

5단계: 전체 스택을 들어내더라도 실행에 옮겨라

필자가 지난 달 쓴 글과 더불어 지금까지 설명한 내용은 어디까지나 복잡한 IT 포트폴리오를 ‘현대적인 수준’으로 유지하기 위한 기본 틀일 뿐이다. 이 프레임워크만으로 시스템이 자동으로 개선되지는 않는다.

현대화가 필요한 모든 시스템을 개선하려면, 적절한 역량을 갖춘 인재를 충분히 확보하는 것부터가 쉽지 않은 과제다. 문제는 여기서 끝나지 않는다. IT 포트폴리오가 일정 수준 이상으로 노후화되면, 기존 시스템을 고치는 것보다 아예 전면 재구축하는 쪽이 더 나아 보이는 순간이 온다.

기술이 충분히 발전해 기존 IT 운영 환경 전체를 거주형 AI가 자동으로 역설계할 수 있게 된다면, 운이 좋은 CIO는 그 혜택을 누릴 수도 있다.

그렇지 않다면, 전체 포트폴리오를 ERP, CRM 등과 같은 대규모 통합 애플리케이션 제품 몇 개로 교체하는 것이 개별 시스템을 하나하나 고치는 방식보다 더 현실적이고 경제적인 선택이 될 수 있다. 이 경우 대부분의 애플리케이션은 앞서 언급한 조치 중 ‘통합’ 대상으로 분류될 가능성이 높다.

이는 겉보기에 좋은 계획처럼 들리지는 않을 수 있다. 하지만 2012년 영화 ‘아르고’에서 토니 멘데즈가 말했듯, 그게 ‘가장 덜 나쁜 계획’일 수 있다.
dl-ciokorea@foundryco.com