제 커리어 대부분은 SAP와 함께해 왔으며, 현재 우리는 SAP 시스템을 호스팅하는 방식에 있어 매우 큰 변화를 목격하고 있습니다. ‘매우 높은 보안 수준’이 요구되는 일부 산업을 제외하면, 대부분의 기업이 클라우드로 전환하고 있습니다. 많은 경우, 이는 수십 년간 유지해 온 레거시 SAP 시스템을 정리하고 클라우드 기반 S/4HANA로 새롭게 시작하려는 전환점으로 인식되고 있습니다.
최근 저는 이러한 흐름이 SAP에만 국한된 것이 아니라는 점을 깨달았고, 나름의 가설도 세웠습니다. 1990년대 후반부터 2000년대 중반까지는 전례 없는 IT 혁신의 시기였으며, Y2K 문제를 시작으로 인터넷의 대중화, 공급망에서의 EDI 활용 확대 등이 이어졌습니다. 기업들은 IT 시스템에 막대한 투자를 해야 했고, 이후 지금까지 그 시스템에서 최대한의 가치를 끌어내며 사용해 왔습니다.
약 20년치 데이터를 그대로 클라우드로 가져가는 것은 단순히 비용 증가 문제를 넘어, 기업 구조를 경직시키거나 프로젝트에 대규모 ETL 부담을 추가하게 됩니다. 그 결과, 다양한 형태의 레거시 시스템이 여전히 많이 남아 있는 상황입니다.
변화의 흐름 속에서
제 커리어 대부분은 SAP와 함께해 왔으며, 현재 우리는 SAP 시스템을 호스팅하는 방식에 있어 매우 큰 변화를 목격하고 있습니다. ‘매우 높은 보안 수준’이 요구되는 일부 산업을 제외하면, 대부분의 기업이 클라우드로 전환하고 있습니다. 많은 경우, 이는 수십 년간 유지해 온 레거시 SAP 시스템을 정리하고 클라우드 기반 S/4HANA로 새롭게 시작하려는 전환점으로 인식되고 있습니다.
최근 저는 이러한 흐름이 SAP에만 국한된 것이 아니라는 점을 깨달았고, 나름의 가설도 세웠습니다. 1990년대 후반부터 2000년대 중반까지는 전례 없는 IT 혁신의 시기였으며, Y2K 문제를 시작으로 인터넷의 대중화, 공급망에서의 EDI 활용 확대 등이 이어졌습니다. 기업들은 IT 시스템에 막대한 투자를 해야 했고, 이후 지금까지 그 시스템에서 최대한의 가치를 끌어내며 사용해 왔습니다.
약 20년치 데이터를 그대로 클라우드로 가져가는 것은 단순히 비용 증가 문제를 넘어, 기업 구조를 경직시키거나 프로젝트에 대규모 ETL 부담을 추가하게 됩니다. 그 결과, 다양한 형태의 레거시 시스템이 여전히 많이 남아 있는 상황입니다.
제가 여러분께 전달할 수 있는 경험과 가치
저는 SAP와 함께 20년을 일해왔고, 그중 15년 이상을 SAP 데이터 관리 분야에서 활동해 왔습니다. 최근 2년 동안 수행한 디커미셔닝 프로젝트 수는 이전 18년을 모두 합친 것보다 많습니다.
이 블로그에서는 SAP 디커미셔닝을 위한 체크리스트를 소개하고, 각 항목에 대한 배경을 설명합니다.
이 글은 특정 솔루션에 종속되지 않고, 스스로 디커미셔닝을 진행하려는 분들을 위한 일반적인 가이드입니다. (이 글을 여러분의 상사가 읽지 않기를 바랍니다.)
또한 후속 블로그에서는 각 항목에 대해 EPI-USE Labs가 어떻게 이를 단순화하거나 완전히 제거할 수 있는지 설명할 예정입니다.
본격적인 팁
Tip 1: 메시지를 명확히 준비하고, 지속적으로 반복하여 전달하기
- 아카이브 시스템은 SAP UI화면대로 보이지 않는다.
- 현재 SAP에서 하던 모든 작업이 아카이브에서 동작 및 수행되지는 않는다.
- 원하는 대로 다 할 수 없기에 반드시 타협이 필요하다.
이 프로젝트에서는 다양한 사람들과 협업하게 됩니다. 기술을 지원하는 IT 컨설턴트부터 내부 IT 팀, 그리고 다양한 비즈니스 사용자들까지 포함됩니다. 이들 중 일부는 IT에 익숙할 수도 있지만, 그렇지 않은 경우도 많습니다. 그리고 대부분은 새로운 시스템 도입 과정에서 이미 많은 업무 부담을 안고 있을 것입니다. 특히 사용하던 SAP를 떠나는 경우라면 더욱 그렇습니다. 저는 이혼을 해본 적도 없고, 심각한 마약 중독을 끊어본 적도 없지만, 조직 차원의 고통과 스트레스, 눈물이라는 측면에서 본다면 사용하던 SAP 더이상 안쓰고 떠나는 일은 그 어떤 것보다도 힘든 과정일 것이라고 생각합니다. 그렇기 때문에 기대치 관리가 중요합니다.
새로운 시스템은 여러 가지 이유로 SAP 시스템처럼 보일 수 없습니다. 그리고 사실 그렇게 만들 필요도 없습니다. 사용자들은 현재 SAP GUI에 익숙해져 있지만, 새로운 시스템에서는 SAP GUI를 사용하지 않게 됩니다. 설령 새로운 시스템이 S/4HANA라고 하더라도, 사용자는 Fiori를 사용하게 될 것입니다.
또한 테스트와 검증을 진행할 때 ‘A가 B와 동일한가’를 확인하는 방식으로 접근해서는 안 된다는 점을 지속적으로 강조해야 합니다. 이 시스템은 SAP를 대체하는 것이 아니라, 단순히 ‘조회 전용 SAP 시스템’을 계속 운영하지 않아도 되도록 하기 위한 것입니다. 이 시스템은 도입 직후부터 사용 빈도가 줄어들 것이며, 며칠 혹은 몇 주 동안 전혀 사용되지 않을 수도 있습니다. 그러나 규제 준수 목적에서는 필요할 수 있습니다. 데이터가 존재한다는 사실 자체가 중요하며, 그것이 어떻게 표시되는지, 검색과 조회가 얼마나 쉬운지, 응답 속도가 얼마나 빠른지는 상대적으로 덜 중요합니다. 거의 사용되지 않는 전제로 도입하기 때문에 솔루션의 뛰어남이나 사용성에 과도하게 집착할 필요가 없습니다. 처음에는 욕심이 느껴질 수 있지만, 시간이 지나면 결국 사용자와 함께 타협해야 하는 상황이 오게 됩니다.
Tip 2: 재해 복구(Disaster Recovery) 옵션 검토 시 실제 활용 유스케이스 고려하기
- 아카이빙 시스템을 위해서 ‘시점 복구(Point-in-time recovery)’나 고가용성은 필요 없다.
디커미셔닝 시스템을 구축하는 담당자는 해당 시스템의 사용 목적을 충분히 이해하지 못하고, 일반적인 백업 및 재해복구(Disaster Recovery) 옵션을 기본으로 적용하려 할 수 있습니다. 이러한 옵션은 일반적으로 장애 발생 시 영향과 비용에 따라 다양한 수준으로 제공됩니다. ‘시점 복구(point in time recovery)’는 백업 데이터를 복원한 뒤, 로그를 재적용하여 특정 시점까지 복구하는 기능입니다.
하지만 디커미셔닝된 데이터의 장점은 변경되지 않는다는 것입니다. 사용자 레이아웃 설정과 같이 변경될 수 있는 요소를 고려한 뒤, 그에 맞는 백업 전략을 수립하면 됩니다. 실제로 사용 1년이 지나면, 일주일 간격으로 수행된 백업 데이터가 동일할 가능성이 매우 높습니다. 또한 시스템 복구 시간도 일반 IT 시스템 수준으로 빠를 필요는 없습니다. 한 시간 정도의 다운타임은 충분히 감내 가능할 것입니다.
요약하자면, 이 시스템은 일반적인 IT 시스템 기준에서 보면 매우 낮은 중요도의 사용 사례에 해당합니다. 따라서 필요 이상으로 고급 백업이나 DR 옵션에 비용을 지불하지 않도록 주의해야 합니다.
Tip 3: 워크숍을 통해 Usecase 목록을 체계적으로 수집하기
- 시스템 내 데이터가 아니라 Usecase 에 집중하십시오
- 현업 담당자와 논의를 시작할 때, 현재 SAP에서 수행되는 모든 작업이 디커미셔닝 이후에도 필요하지는 않다는 점을 명확히 해야 합니다.
Level 1 (쉬움) - 수천 개의 레고 블록 속에서 2x2 블록 찾기
Level 2 (보통) - 건초더미에서 바늘 찾기
↓
Level 9 (매우 어려움) - SAP 시스템에서 필요한 모든 데이터 식별하기
현대 SAP 시스템에는 70,000개 이상의 클라이언트별 테이블이 존재합니다. 이 중 많은 테이블은 기본 데이터만 포함하고 있으며, 귀사의 비즈니스나 산업과 전혀 관련 없는 데이터일 수도 있습니다.
실제로 필요한 데이터가 담긴 테이블은 약 3,000~5,000개 수준일 것입니다. 따라서 먼저 사용 사례를 정의하고, 그 사용 사례를 지원하는 데이터를 찾아야 합니다. 특정 트랜잭션이 어떤 테이블을 사용하는지 확인하기 위해 ST05 트레이스를 활용할 수 있으며, F1 기술 도움말도 사용할 수 있습니다. 다만 구조(Structure)와 투명 테이블(Transparent Table)을 구분하는 데 주의해야 합니다. 워크숍을 통해 사용 사례를 정의하고 문서화한 후 승인받으십시오. 참가자들에게 SAP 종료 후 1개월, 1년, 3년이 지난 시점에도 어떤 요청이 발생할지를 고민하게 해야 합니다. 또한 그것이 현재 수행 중인 작업인지, 아니면 향후에도 반드시 필요한 작업인지 계속해서 질문해야 합니다.
Tip 4: 연계된 시스템까지 함께 고려하기
- 해당 시스템들도 함께 디커미셔닝됩니까?
- 데이터 중복이 있습니까? 어떤 시스템에서 데이터를 가져와야 합니까?
대부분의 SAP 운영 기업에서 SAP는 재무 데이터를 포함한 주요 시스템이며 IT 환경의 중심입니다. 다양한 시스템이 SAP와 인터페이스를 통해 연결되어 외부와의 통신 역할을 합니다. CRM, SRM과 같은 다른 SAP 솔루션도 ERP와 연동되어 있을 수 있습니다. 워크숍 전에 이러한 주변 시스템 목록을 준비해야 합니다. SAP를 대체하는 프로젝트에서는 이미 어떤 시스템이 함께 종료될지 정의되어 있어야 합니다. 대체 시스템 설계에 포함된 시스템이 기존 SAP와 연결된 상태에서 생성된 과거 데이터를 계속 보유하는지도 확인해야 합니다. 해당 데이터가 유지된다면 목록에서 제외할 수 있습니다. 남아 있는 시스템에 대해서는 워크숍을 통해 해당 데이터가 실제로 필요한지 검토해야 합니다. 해당 데이터가 SAP ERP에 이미 저장되어 있는지, 혹은 최종 결과 데이터가 SAP에 존재하는지도 확인해야 합니다. 예를 들어, SRM에서 ERP로 전송된 구매 오더 중 처리되지 않은 데이터는 향후 필요하지 않을 가능성이 높습니다. 동일한 데이터가 여러 시스템에 존재한다면, 조회가 더 쉬운 시스템을 선택하는 것이 좋습니다.
Tip 5: 정형 데이터와 비정형 데이터를 모두 고려하기
- 문서는 데이터베이스에 저장되어 있지 않을 수도 있으며, 별도의 저장소에 존재할 수도 있습니다.
- 저장되지 않은 문서가 새로운 시스템에서 생성될 수 있습니까?
- 별도 저장소에 있는 경우, 다른 시스템에서 생성된 것입니까? 해당 시스템도 디커미셔닝됩니까?
디커미셔닝에는 구조화 데이터와 비구조화 데이터가 모두 포함된다는 점을 이해시키는 것이 중요합니다:
- 구조화 데이터는 테이블 데이터이며,;
- 비구조화 데이터는 PDF, Word 문서 등으로, 파트너 제공이나 규제 준수를 위해 필요할 수 있습니다. 또한 비즈니스 사용자가 특정 질문에 답변하기 위해 필요할 수도 있습니다. 급여 명세서, 송장 PDF, 특정 재무 보고서 등이 그 예입니다.
디커미셔닝 시스템에는 SAP의 로직이 포함되지 않으므로, 테이블 데이터를 조합하여 결과를 생성하는 기능은 사전에 실행해야 할 수 있습니다. 이는 Z/Y 리포트를 포함할 수 있습니다.
비정형 데이터가 SAP에 저장된 경우 SAP Office 또는 Content Server에 존재할 수 있습니다. 하지만 이를 확인하기 전에, 해당 문서의 출처와 목적지를 먼저 확인하는 것이 좋습니다. 중간 시스템에서 이미 문서가 저장되어 있을 수도 있으며, 그 시스템의 향후 계획과 사용자 접근성을 고려해야 합니다. SAP에서 추출하는 것보다 해당 시스템에서 가져오는 것이 더 쉬울 수도 있습니다.
SAP에서 문서를 가져와야 한다면 프로그램 방식으로 할지, RPA를 사용할지 결정해야 합니다. Content Server에 있다면 SAP를 거치지 않고 직접 가져오는 것이 더 쉬울 수도 있습니다.
Tip 6: 텍스트 데이터 관리 고려하기
- 구조화 데이터에는 많은 식별자가 포함되어 있습니다: 01 = Mrs, 02 = Miss 등. 이것이 필요합니까?
- 자재, 구매 오더, 판매 오더 등에서는 텍스트 입력이 가능하며, 이는 클러스터 테이블에 저장되어 직접 조회할 수 없습니다.
구조화된 데이터는 SAP에서 시스템 내 사용에 가장 효율적인 방식으로 저장되어 있으며, 이를 시스템에서 분리해 활용 가능한 형태로 만드는 데에는 최적의 형식이 아닙니다. 고려해야 할 대표적인 예로는 구성(Configuration)에 포함된 설명(Description) 값이 있습니다. 관계형 데이터베이스 관리 시스템은 A 테이블의 특정 필드가 B 테이블에 존재하는 값들 중 하나만 가질 수 있도록 강제하며, 해당 값의 의미에 대한 설명은 A 테이블에 여러 번 저장되는 것이 아니라 B 테이블에 한 번만 저장됩니다.
이에 대한 예로는 Mrs, Miss, Mr와 같은 호칭이나 오더 유형(order types) 등이 있습니다. 어떤 경우에는 사용자가 기술 코드의 의미를 직관적으로 알고 있을 수 있지만, 몇 년 동안 해당 SAP 데이터를 보지 않았다면 3년 후에도 그 의미를 기억할 수 있을까요? 아마도 그렇지 않을 것입니다.
따라서 워크숍에서는 설명 값을 함께 표시하기 위해 어떤 관련 구성 테이블들을 함께 저장해야 하는지를 결정하는 것이 중요합니다. 이후에는 선택한 아카이브 시스템이 이를 단순한 방식으로 저장할 수 있는지도 확인해야 합니다. 또한 SAP에서 지원하는 모든 언어 버전을 정말로 필요로 하는지, 아니면 특정 언어만 필요한지도 함께 고려해야 합니다.
텍스트는 메모장(Notepad)에서 보면 매우 단순한 것처럼 보입니다. 하지만 단순한 문자열 뒤에는 복잡한 구조가 숨어 있습니다. 특히 텍스트는 용량을 줄이기 위해 압축 대상으로 활용되기 쉬운 특성이 있기 때문에 항상 직접적으로 조회 가능한 형태로 존재하지는 않습니다. SAP에는 STXH와 STXL이라는 두 개의 테이블이 있으며, 이들은 매우 다양한 유형의 데이터와 연결되어 있습니다. 트랜잭션 TAANA를 사용하면 각 텍스트 유형별 레코드 수를 확인할 수 있는데, 대부분의 시스템에서는 그 수가 수백만 건에 달합니다. 실제 텍스트는 STXL에 클러스터 형태로 압축 저장되어 있기 때문에, 이를 조회하려면 SAP 함수 모듈을 사용해야 합니다.
워크숍에서는 실제로 사용되는 항목이 무엇인지 파악하고, 그 목록을 ‘필요한 것(원하는 것이 아닌 반드시 필요한 것)’으로 축소하는 것을 권장합니다. 그 이유는 SAP가 이러한 테이블들에 대한 개발자들의 연결 방식에 대해 엄격하게 통제하지 않았기 때문입니다. 일반적으로는 Vendor 번호나 PO 번호와 같은 키로 직접 연결되지만, 일부 특이한 경우도 존재합니다. 예를 들어 특정 생산 오더 텍스트의 경우, 키에 생산 오더 번호가 포함되어 있지만 그 앞에 사용 중인 클라이언트 번호가 붙어 있는 형태입니다. 이는 불필요한 구성인데, 생산 오더와 텍스트 테이블 모두 이미 클라이언트 단위로 구분되기 때문입니다. 개인적인 추측이지만, 이건 해당 개발자의 첫 번째이자 마지막 SAP 프로젝트였거나, 나중에 너무 부끄러워서 끝까지 밝히지 못한 사례일 수도 있습니다. 요점은 이렇습니다. STXH/STXL 테이블의 모든 데이터를 디클러스터링하려고 시도하는 것은 권장하지 않습니다. 왜냐하면 일부 데이터는 실제 비즈니스 데이터와 연결조차 할 수 없을 가능성이 있기 때문입니다.
Tip 7: 변경 이력 데이터 검토하기
- 또한 어떤 영역에서는 데이터 자체뿐 아니라 변경 이력까지 필요한지 여부도 확인해야 합니다.
SAP는 많은 영역에서 주요 시스템 기록(source of record) 역할을 하기 때문에, 데이터가 변경될 때마다 그 이력을 함께 저장합니다. 하지만 대부분의 경우, 디커미셔닝된 시스템에서는 이러한 변경 이력이 필요하지 않습니다. 다만 예외적으로 인사(HR) 데이터나 특정 산업에서의 레시피, 자재, 배치(Batch)와 같은 영역에서는 변경 이력이 요구될 수 있습니다. 앞서 텍스트 데이터와 마찬가지로, 모든 변경 이력을 가져가려고 하기보다는 실제로 필요한 영역을 식별하는 것이 중요합니다. 이후에는 프로그램 방식으로 추출할지, 화면 자동화(RPA)를 사용할지 판단해야 합니다. 대부분의 변경 이력은 또 다른 클러스터 테이블(CDHDR, CDPOS)에 저장되어 있으며, HR의 경우에는 PCL4 클러스터를 확인해야 합니다.
Tip 8: 보관할 데이터에 대한 청사진(계획/전략)를 수립하고 승인 받기
- 또한 어떤 데이터가 누락되었을 경우 어떻게 대응할 것인지에 대한 프로세스를 설계 단계(Blueprint)에 포함해야 합니다. 이는 각 영역에서 데이터를 얼마나 가져갈지 결정하는 데 중요한 기준이 될 수 있습니다.
- 이 작업은 프로젝트 초기에 반드시 수행해야 합니다. 전체 프로젝트에 큰 영향을 미치기 때문입니다.
문서화는 모든 프로젝트에서 중요하지만, 특히 이 프로젝트에서는 참여 인력들의 집중도가 낮을 수 있고, 더 시급한 업무로 돌아가기 위해 빠르게 합의를 보려는 경향이 있을 수 있습니다.
따라서 어떤 데이터를 어떻게 디커미셔닝할 것인지에 대한 블루프린트를 작성하고, 각 업무 영역에서 해당 내용을 검토 및 승인(sign-off)하도록 해야 합니다.
Tip 9: 테스트 전략 수립 및 수행하기
- 테스트 수준은 시스템을 다시 복구하는 데 드는 비용에 비례해야 합니다.
앞서 언급했듯이, 이 프로젝트는 대부분의 사람들에게 최우선 과제가 아닐 가능성이 높습니다(아마 프로젝트 매니저를 제외하고는). 따라서 비즈니스 사용자에게 테스트나 검증을 요청할 때 이 점을 고려해야 합니다. 여러 개의 Usecase 가 준비되었을 때 한 번에 검증을 요청하는 것이, 작은 요청을 여러 번 하는 것보다 효과적입니다.
테스트 수준을 결정할 때 고려해야 할 핵심 질문은 다음과 같습니다:
- 일반적인 질문: 만약 데이터가 누락되었을 경우, 시스템 접근을 다시 복구하는 것이 얼마나 어려운가?
- 유스케이스별 질문: 데이터가 없을 경우 어떤 영향이 있으며, 그 영향은 누구에게 미치는가?
사업 분할(divestiture)과 같이 SAP 시스템 접근이 완전히 차단되는 경우라면, 테스트와 검증은 매우 중요하며, 승인 결과가 법적 효력을 가질 수도 있습니다. 반면, 데이터를 다시 가져올 수 있지만 비용이나 노력이 필요한 경우라면 테스트 수준도 그에 맞게 조정해야 합니다.
또한 해당 결과에 비즈니스 영역과 데이터 유형에 따른 중요도를 반영해야 합니다. 예를 들어, 대부분 국가에서는 회계 문서를 최소 7년간 보관해야 하며, 이를 준수하지 않을 경우 극단적인 경우에는 기업 임원에게 법적 책임이 따를 수도 있습니다. 물론 프로젝트 범위 설정 과정에서의 실수로 인해 이러한 상황이 발생하는 것은 매우 드문 경우일 것입니다.
Tip 10: 향후 다른 시스템 디커미셔닝까지 고려하기
- 내부적으로 다른 시스템 디커미셔닝에도 활용할 수 있도록 솔루션을 홍보하는 것도 중요합니다.
- 어떤 솔루션을 사용하든, 더 많은 시스템을 함께 포함할수록 투자 대비 효과(ROI)는 더 좋아집니다.
- 향후 다른 시스템도 포함될 가능성을 고려하여 권한 관리, 저장 공간, 컴퓨팅 자원 등을 설계해야 합니다.
현재 SAP 시스템 변경과 직접 관련이 없는 다른 사업 부문이 있을 수도 있습니다. 이들의 IT 담당자와 업무 담당자에게 프로젝트 내용을 간단히 설명하는 것만으로도 향후 확장에 도움이 될 수 있습니다.
SAP 데이터를 어디로 옮기든, 여러 시스템이 하나의 디커미셔닝 플랫폼을 공유할수록 비용 효율성이 높아집니다. 따라서, 사용 중인 기술 솔루션이 향후 다른 시스템을 수용할 때 어떤 제약이 있는지 확인해야 합니다. 라이선스 제한이 있는지, 현재보다 더 많은 자원 확보가 필요한지 등을 미리 검토하는 것이 좋습니다.
Tip 11: 디커미셔닝 시스템을 단계적으로 도입하기
- SAP 접근을 차단하고, 이후 접근 요청을 추적해야 합니다.
가능하다면, 새로운 시스템의 안정화 단계(하이퍼케어 기간) 동안에는 기존 SAP 시스템을 계속 사용할 수 있도록 계획하고, 필요하다면 그 이후에도 일정 기간 유지하는 것이 좋습니다. 사용자들은 이미 처리해야 할 일이 많기 때문에, SAP 데이터에서 무언가를 확인해야 할 경우에는 SAP에서 직접 확인하도록 하는 것이 바람직합니다. 이후에는 SAP 접근을 차단하고, 새로운 디커미셔닝 시스템을 사용하도록 유도해야 합니다.
주의: 사용자들이 SAP 시스템을 계속 붙잡고 놓지 않도록 해야 합니다(디스플레이 전용 시스템의 숨겨진 비용에 대한 블로그를 참고하십시오). 이는 12번 항목과도 연결됩니다. 각 단계의 기간은 SAP를 백업에서 복구하는 것이 얼마나 현실적이며 비용이 얼마나 드는지에 따라 달라집니다.
Tip 12: 누락 데이터 아카이빙을 위한 실행 계획 사전 준비하기
- SAP 라이선스를 반드시 확인하십시오. 유지 보수가 종료된 이후에도 시스템을 조회 전용으로 유지할 수 있는지 확인해야 합니다.
SAP와의 라이선스 계약 조건에 따라, 기존 시스템을 원하는 기간 동안 디스플레이 전용으로 유지할 수 있는 경우도 있습니다. 유지 보수를 재계약하면서 새로운 계약을 체결했더라도, 현업 사용자가 접근하지 못하는 상황에서도 기술 계정으로는 여전히 기존 SAP 시스템에 접근할 수 있는 경우가 있습니다.
프로젝트 과정에서 누락된 데이터를 SAP에서 다시 추출해야 하는 상황을 대비해, 이른바 ‘비상 접근(Please smash the glass to access)’ 계획을 문서화해야 합니다. 이 계획에는 필요한 데이터를 신속하게 접근할 수 있는 방법과 함께, 추가 데이터 추출을 위해 프로젝트를 재가동할 수 있도록 필요한 인력과 절차가 포함되어야 합니다. (가능하다면 한 번으로 끝나기를 기대하지만) 추가 데이터 추출을 위한 ‘한 번의 앙코르’가 가능하도록 준비해야 합니다.
결국 어느 시점에서는 백업을 수행하고 시스템을 완전히 종료하게 될 것입니다. 정확히 언제 그 시점이 되어야 하는지는, 시스템을 다시 복구하는 데 드는 비용에 따라 결정됩니다. 이러한 모든 사항은 사전에 계획에 포함되어야 합니다.
Tip 13: 감사 대응을 철저히 준비하기
- 내부 및 외부 감사자와의 워크숍을 포함하십시오.
이 항목은 앞서 설명한 내용과는 순서가 조금 어긋나 있습니다. 이전 항목들이 프로젝트 종료 시점을 기준으로 시간 순서대로 설명되었기 때문입니다. 매년 감사는 진행되며, 디커미셔닝된 데이터 역시 감사 대상에 포함될 가능성이 높습니다. 또한, 특정 연도의 감사를 수행한 사람이나 회사가 다음 해에도 동일할 것이라는 보장은 없기 때문에, 이 부분은 반드시 고려해야 합니다.
내부 및 외부 감사자와 워크숍을 진행하여 프로젝트의 목적을 설명하고, 향후 몇 년 동안 어떤 데이터와 정보가 필요한지 확인해야 합니다. 이를 청사진에 반영하고, 감사자의 승인을 받아야 합니다. 이상적으로는 승인하는 사람이 최초 감사를 수행할 조직에 속해 있기를 기대할 수 있습니다. 이후 2년 차에 추가적인 보고서를 요구하는 경우라도, 첫 번째 감사가 원활하게 진행되었다면 보다 수월하게 협의할 수 있습니다. 또한, 정형 데이터와 비정형 데이터의 차이를 명확히 설명하고, 테이블 데이터는 존재하지만 ABAP 로직은 포함되지 않는다는 점을 분명히 해야 합니다. 감사자가 필요로 하는 보고서를 파악하고, 이를 RPA 또는 프로그램 방식으로 생성할 수 있도록 준비해야 합니다.
Tip 14: 13번에서 끝내지 말 것 (마무리까지 고려하기)
농담처럼 들릴 수도 있지만(사실은 중요한 내용입니다), ‘리포팅’과 같은 잘못된 요구 사항에도 주의해야 합니다. “외부 분석 도구에서 데이터를 읽어올 수 있는 API가 있나요?”라는 질문은 자주 나오지만, 실제로 비용을 지불할 의사가 있는 요구 사항인 경우는 거의 없습니다. 시간이 지날수록 해당 데이터는 리포팅 관점에서의 활용도가 점점 낮아집니다. 물론 특정 프로젝트에서는 이러한 요구 사항이 실제로 필요할 수도 있지만, 대부분의 경우 이는 이상적인 요구 사항에 불과하며, 프로젝트 비용을 검토할 때 가장 먼저 제외되는 항목입니다. 불필요한 시간 낭비를 줄이기 위해, 해당 요구 사항이 과거의 정적인 데이터에 대해 정말로 필요한 것인지 반드시 검증해야 합니다.
이 내용이 도움이 되셨다면, 이 과정을 어떻게 더 간단하게 만들 수 있는지 설명한 후속 블로그도 확인해 보시기 바랍니다.