이 블로그 시리즈에서는 데이터의 생애주기 종료, 그리고 경우에 따라서는 시스템의 종료 단계까지 살펴보고자 합니다. SAP® 시스템과 데이터를 보다 “품위 있고 안정적으로” 종료할 수 있도록, 제 경험과 지식을 공유하는 것이 목적입니다. 서버실 바닥에 피가 낭자하고 사람들이 눈물을 쏟는, 그런 참혹한 결말(IT 커리어에서 한 번쯤은 겪어봤을 법한… 최소한 피는 없었길 바랍니다) 대신 말이죠.
1. 사업 분할(매각) 2. 인수(기업 인수) 3. 통합 4. SAP 이탈 5. Greenfield SAP(신규 구축 방식)
먼저, 시스템이나 데이터를 종료해야 하는 필요성이 어떻게 발생하는지 살펴보겠습니다. 몇 가지 비즈니스 이벤트가 시스템을 ‘조회 전용(display only)’ 상태로 만들 수 있습니다. 예를 들어, 매각된 사업부에서 사용하던 시스템이 있을 수 있습니다. 해당 시스템 전체를 복제하여 인수자에게 넘겼지만, 재무 및 법적 요건에 따라 매도 기업은 거래 이후에도 일정 기간 동안 데이터를 보관해야 합니다.
또는 기업 인수(acquisition)의 경우도 있습니다. SAP 시스템이든 다른 온프레미스 ERP 시스템이든, 비즈니스 프로세스를 통합하는 과정에서 인수 기업의 기존 시스템에 맞춰 재구현하기로 결정했을 수 있습니다. 이때 미결(open) 항목만 이전되고, 컴플라이언스나 참고를 위해 필요한 과거 거래 데이터는 ‘동결된(mothballed)’ 기존 시스템에 남게 됩니다.
또 다른 사례는 SAP에서 다른 기술로 전환하는 경우입니다. 많은 기업이 SAP를 현대화하고 있지만, 일부는 산업 특화 솔루션으로 이동하기도 합니다. 또는 S/4HANA로 전환하면서 기존 SAP 시스템을 그대로 업그레이드하지 않고, 신규 구축 방식으로 전환하는 경우도 있습니다.
이 모든 사례는 결국 동일한 결과로 이어집니다. 즉, 소수의 사용자만 데이터를 조회하기 위한 목적으로 유지되는 SAP 시스템(또는 여러 시스템)이 남게 되는 것입니다.
처음에는 소수의 사용자만을 위해 전체 ERP 시스템을 유지하는 것이 비합리적으로 보일 수 있습니다. 하지만 컴플라이언스와 향후 조회를 위해 필요한 데이터를 추출하려고 하면, 매우 복잡하고 깊이 있는 데이터 구조라는 ‘판도라의 상자’를 열게 됩니다.
일반적인 SAP 시스템에는 30,000개 이상의 애플리케이션 데이터 테이블이 존재합니다. 하나의 단순한 트랜잭션 코드도 50~70개 이상의 테이블을 참조할 수 있으며, 이들 간의 관계는 항상 단순하지 않습니다. 예를 들어 Sales Order를 조회할 때, 고객 마스터의 배송 주소를 보는 것인지, 아니면 해당 주문에만 별도로 입력된 주소를 보는 것인지에 따라 데이터 출처가 달라질 수 있습니다.
또한, 하나의 Sales Order에는 여러 라인 아이템이 존재하며, 이는 서로 다른 테이블에 저장됩니다. 각 아이템은 Material Master와 연결될 수도 있고, 이는 또 다른 데이터 세트에 저장되어 있습니다. 더 나아가 Delivery, Contract, Billing Document 등 선행·후행 문서도 함께 확인해야 할 수 있습니다. 사용자가 단순히 CSV 파일을 열어 주문 번호를 찾고, 또 다른 CSV에서 아이템을 확인하는 방식으로는 데이터의 ‘의미’를 파악할 수 없습니다. 단순한 원시 데이터(raw data)가 아니라, 의미 있는 데이터 접근을 위해서는 훨씬 더 정교한 구조가 필요합니다.
문제는 여기서 끝나지 않습니다. SAP 데이터에는 다양한 커스터마이징 값이 포함되어 있습니다. 예를 들어, ‘Plant 3000’이라는 값만으로 충분한지, 아니면 해당 Plant의 실제 설명까지 필요한지 판단해야 합니다. 또한 ‘01, 02, 03’과 같은 코드 값이 무엇을 의미하는지도 필요할 수 있습니다. SAP의 커스터마이징 테이블은 약 50,000개에 달합니다. 이 중 어떤 테이블이 실제로 사용되는지, 어떤 것은 기본값인지 구분하는 것도 쉽지 않습니다.
이러한 이유로 많은 기업이 ‘SAP 데이터를 다운로드하자’는 시도를 하다가, 데이터 구조의 복잡성을 인지하고 중도에 포기하게 됩니다. 이는 조회용도만을 위한 시스템 유지 비용을 과소평가하는 경우가 많기 때문이기도 합니다.
시스템을 조회 전용으로 전환하는 첫 단계는 권한을 조회 전용으로 제한하는 것입니다. 인터페이스는 이미 운영 시스템으로 이전되어 있어야 하며, ALE, IDoc, 이메일 등 통신 기능도 점검하여 데이터가 외부로 전송되지 않도록 해야 합니다. 라이선스 측면에서는 SAP 유지 보수를 더 이상 유지하지 않아도 됩니다. 다만 운영체제 패치 등으로 인해 시스템을 재시작해야 할 경우가 있으므로, 최소한의 SAP Basis 역량은 필요합니다.
하드웨어나 클라우드 비용도 고려해야 합니다. 온프레미스 환경이라면 기존 서버로도 충분히 운영이 가능할 수 있습니다. 이 단계에서는 큰 문제가 없어 보입니다.
하지만 2~3년 후 상황은 완전히 달라질 수 있습니다.
SAP를 적극적으로 활용하던 핵심 사용자들은 모두 회사를 떠났습니다. 재무 부서 사용자들은 이제 비즈니스 운영을 위해 XXX 솔루션에 익숙해져 있으며, SAP GUI 트랜잭션 코드를 실행하거나 구식으로 보이는 화면(혹시 PONG 게임 기억하시나요?)을 해석하는 방법을 알지 못하거나, 배울 의지도 없습니다. 그리고 IT 부서 역시 데스크톱에 SAP GUI를 설치하는 방법조차 알지 못합니다.
IT 총괄 책임자는 ‘클라우드 전환 전면화(cloud-only)’ 전략을 추진하고 있으며, 부동산 매각으로 인해 서버실 자체를 더 이상 운영할 수 없는 상황입니다. 누군가는 이 시스템을 Azure/AWS/GCP로 이전해야 합니다. 그런데 해당 클라우드 플랫폼의 마이그레이션 및 운영 도구가 이 오래된 운영체제와 호환될 수 있을까요?
또는
데이터센터가 이제 완전히 가상화된 서버 환경으로 운영되고 있을 수도 있습니다. 기존 서버를 ‘있는 그대로(as is)’ 가상 머신으로 이전하는 데는 성공했지만, 이제 모든 가상 머신을 관리하는 솔루션이 업그레이드되면서 Windows 2012를 지원하지 않게 되었습니다. 결국 SAP 호스트 서버를 업그레이드해야 합니다. 그런데 사용 중인 데이터베이스 버전이 Windows 2012까지만 지원하므로, 데이터베이스도 함께 업그레이드해야 합니다. 그리고 새로운 운영체제와 데이터베이스 버전에 맞게 SAP 시스템도 패치해야 합니다. 그런데 SAP 패치 방법을 기억하는 사람이 있을까요? 이런, 유지 보수 계약을 중단했기 때문에 패치 파일을 다운로드할 수도 없는 상황입니다.
결국, 과거에는 가장 쉬운 선택이었던 방법이 몇 년 뒤에는 완전히 막힌 길이 되어버립니다.
눈치가 빠르신 분들(그리고 이 블로그를 여기까지 읽어주신 분들이라면 더욱 그렇겠죠)은, 글 초반에 제가 ‘시스템’과 ‘데이터’를 혼용해서 사용하다가 이후에는 시스템 선셋(sunsetting)에 초점을 맞췄다는 점을 알아차리셨을 것입니다. 이는 보다 일반적인 sunsetting 사례이기 때문이지만, 최근 데이터 프라이버시의 중요성이 높아지면서 시스템은 그대로 유지하더라도 데이터는 종료해야 하는 상황이 발생할 수 있습니다.
예를 들어, SAP 시스템의 HCM이 SuccessFactors Employee Central로 전환되는 경우를 생각해 볼 수 있습니다. 이때 과거 직원 데이터는 이후에 시스템에서 제거될까요? 5년 후 새로운 프로젝트를 위해 외부 업체가 샌드박스 환경에 접근하게 되었을 때, 그 직원 데이터가 반세기 가까운 시간 동안 아무 변화 없이 그대로 남아 있다는 사실을 누군가 인지하게 될까요? 제 생년월일과 주민등록번호(또는 사회보장번호)는 지난 5년 동안 변하지 않았습니다. 그 데이터는 비즈니스 프로세스가 SAP 시스템에서 이전되던 당시와 동일하게 지금도 여전히 중요한 정보입니다. 하지만 동시에 또 다른 문제가 발생합니다. 컴플라이언스 요건을 충족하기 위해서는 해당 직원들의 과거 급여 정보는 반드시 보관해야 합니다. 그렇다면 HR 부서에서는 이미 잊혀진 오래된 시스템에서 데이터를 제거하면서도, 필요한 소수의 사용자만이 안전하고 사용자 친화적인 환경에서 접근할 수 있도록 하려면, 그 데이터를 어디에 보관해야 할까요?
이와 같은 상황은 SAP Cloud for Customer로 고객 데이터가 이전되었지만, 디지털 코어로 전환되는 과정에서 온프레미스 SAP 시스템에 여전히 해당 데이터가 남아 있는 경우에도 동일하게 적용될 수 있습니다.