SAP 데이터 마이그레이션이 실패하는 이유와 해결 방법

SAP 데이터 마이그레이션이 실패하는 이유는 무엇보다 하나입니다. 계획이 추출 결과가 보여 주는 것이 아니라, 비즈니스가 자기 데이터가 어떻다고 생각하는지를 바탕으로 짜여 있기 때문입니다. 이 가이드는 S/4HANA 프로젝트를 이끄는 프로젝트 디렉터, 데이터 리드, 재무 책임자를 위한 글입니다. 마이그레이션이 무너지는 이유, 컷오버 실패 대부분의 배후에 있는 다섯 가지 실수, 그대로 가져다 쓸 수 있는 모의 로드 계획, 2026년에 어떤 SAP 도구가 어떤 작업에 맞는지를 다룹니다. 이번 주에 한 가지만 하신다면, 고객, 공급업체, 자재 마스터를 전체 추출해서 레코드 수를 직접 세어 보십시오.

한 제조 기업이 SAP 구축에 18개월과 $4.5M을 들였습니다. 가동일이 되었습니다. 모두 긴장했지만 기대에 차 있었습니다. 그런데 데이터 마이그레이션이 실패했습니다.

제대로 돌아가는 것이 없었습니다. 고객 데이터가 빠져 있었습니다. 재고 수치가 틀렸습니다. 회계팀은 장부를 마감하지 못했습니다. CEO는 격노했습니다.

소프트웨어의 문제도 구축 팀의 문제도 아니었습니다. 실패는 비즈니스가 자기 데이터가 어떻다고 생각했던 것과 실제 모습 사이의 간극에 있었습니다.

SAP의 데이터 모델은 단순한 평면 파일 로드가 아닙니다. 레코드는 서로 의존합니다. 자재 마스터에는 일반 레코드(MARA), 플랜트 데이터(MARC), 평가 데이터(MBEW)가 있고, MRP 영역을 쓰는 경우 MRP 영역 데이터(MDMA)가 있습니다. 헤더만 로드하고 의존하는 뷰를 로드하지 않으면 자재는 존재하지만 트랜잭션에서 사용할 수 없습니다.

S/4HANA에는 자체 규칙이 더해집니다. 고객과 공급업체는 비즈니스 파트너입니다. 레거시 고객은 고객 롤을 가진 비즈니스 파트너가 되고, 공급업체는 공급업체 롤을 가진 비즈니스 파트너가 됩니다. 신용 한도, 은행 정보, 세금 번호는 그 비즈니스 파트너에 붙습니다. 레거시 시스템이 빈칸이 있어도 눈감아 주던 레코드는 여기서 검증에 실패합니다.

그리고 물량이 있습니다. 대부분의 기업은 자신이 가진 데이터 양에 충격을 받습니다. 한 고객은 자재 레코드가 약 50,000건이라고 생각했습니다. 모든 변형과 플랜트별 레코드를 세어 보니 500,000건에 가까웠습니다. 첫 번째 숫자에 맞춘 계획은 두 번째 숫자 앞에서 살아남지 못합니다.

현업의 추정전체 추출

범위 내 자재 레코드500,000+450,000 · +900%

현업의 추정50,000

전체 추출500,000

• 모든 변형과 플랜트별 레코드를 센 값
• 추정치에 맞춘 계획은 이 숫자 앞에서 버티지 못함

그것은 데이터 마이그레이션 문제가 아니었습니다. 데이터 마이그레이션 문제로 번진 범위 산정의 문제였습니다.

프로젝트 초기의 데이터 품질 진단은 보통 데이터를 검증하는 것이 아니라 데이터를 묘사하는 것입니다. 재무 이사는 공급업체 마스터가 잘 관리되고 있다고 말합니다. 창고 관리자는 자재가 대체로 깨끗하다고 말합니다. 그것들은 인상일 뿐입니다.

첫 번째 추출이 진실을 알려 줍니다. 몇 년 전에 정리했어야 하는데 하지 않은 공급업체. 오래전에 단종되었는데 비활성화하지 않은 자재. 국가 코드가 제각각인 고객 주소. 전자 이체로 대금을 지급하는 공급업체인데 은행 정보가 없는 경우.

이 중 어느 것도 기술적 수정이 아니라 비즈니스의 결정이 필요합니다. 중복된 두 공급업체 중 어느 쪽이 맞는지는 매입채무 부서만 말할 수 있습니다. 어떤 단종 자재를 차단하고 어떤 것을 남겨 둘지는 구매 부서만 말할 수 있습니다. 이런 결정은 시간이 걸리고, 데이터를 아는 사람이 필요합니다. 진단이 실제 추출에 기반하지 않으면, 계획은 데이터와 마주치는 순간 무너질 가정 위에 세워진 것입니다. 제 무료 데이터 마이그레이션 추정 도구는 실제 건수를 확보한 뒤 공수를 가늠하는 데 도움이 됩니다.

1. 마이그레이션을 뒤늦은 기술 작업으로 취급하는 것

마이그레이션은 SAP Activate의 모든 단계에 있어야 합니다. Explore에서는 범위를 정의합니다. 오브젝트, 소스 시스템, 물량, 품질입니다. Realize에서는 템플릿을 만들고 모의 로드를 실행합니다. Deploy에서는 최종 리허설과 컷오버 로드를 실행합니다. Run에서는 운영 데이터로 첫 기간 마감을 대사합니다.

마이그레이션 작업을 Deploy에서 시작하는 프로젝트는 몇 달 늦게 시작하는 것입니다. Realize에서 해결했어야 할 품질 문제가 컷오버를 몇 주 앞둔 첫 모의 로드에서야 드러납니다. 제 SAP 일정 계획 가이드는 전체 계획에서 마이그레이션이 어디에 놓이는지 보여 줍니다.

2. 부족한 현업 참여

마이그레이션은 실행 면에서는 기술적이지만 의사결정 면에서는 비즈니스 활동입니다. IT는 중복 공급업체 목록을 만들어 낼 수 없습니다. 어떤 고객 계정을 활성 상태로 옮기고 어떤 계정을 이력으로 남길지는 재무의 결정입니다. 단종 자재 정리에는 구매, 창고, 제품 관리가 필요합니다.

마이그레이션을 기술 인력으로만 꾸리고 현업은 마지막에 서명만 하는 존재로 취급하는 프로젝트는, 로드는 되는 데이터를 만들어 냅니다. 비즈니스 관점에서는 틀린 데이터입니다.

3. 모의 로드를 너무 적게 계획하는 것

잘 운영되는 SAP 데이터 마이그레이션에는 컷오버 전에 최소 세 번의 모의 로드가 필요하며, 복잡한 프로젝트는 더 필요합니다. 한두 번만 계획하는 프로젝트는 깨끗한 데이터와 깨끗한 매핑을 전제로 계획하는 것입니다. 그런 경우는 드뭅니다. 사이클이 더 많다는 것은 마이그레이션에 문제가 있다는 신호가 아닙니다. 제대로 계획되었다는 신호입니다.

4. 시험 로드를 대사하지 않는 것

오류 없이 끝난 로드 작업은 검증이 아닙니다. 검증은 로드된 것과 기대한 것을 비교합니다. 레코드 수, 재무 합계, 미결 항목 잔액입니다. 그런 다음 프로세스 스모크 테스트로 데이터가 트랜잭션에서 동작하는지 확인합니다.

대사하지 않은 시험 로드도 시간을 잡아먹습니다. 그 로드가 낳은 격차는 다음 모의 로드에도 그대로 남아 있고, 다만 원인을 거슬러 추적하기가 더 어려워질 뿐입니다. 다음 로드를 시작하기 전에 매번 대사하십시오.

5. 리허설과 다른 컷오버 로드

컷오버 마이그레이션은 마지막 모의 로드를 그대로 반복해야 합니다. 같은 추출 스크립트, 변환 로직, 로드 순서, 점검, 타이밍입니다. 컷오버 시점의 모든 변경은 프로젝트에서 압박이 가장 큰 순간에 검증되지 않은 위험을 들이는 일입니다.

가장 덜 검증되는 부분은 대개 델타입니다. 마지막 모의 로드와 컷오버 사이에도 현업은 계속 공급업체를 추가하고, 주문을 바꾸고, 재고를 옮깁니다. 데이터 동결일을 정하고, 최종 모의 로드의 일부로 델타 로드를 리허설하십시오.

이 사이클 구조를 출발점으로 쓰십시오. 각 사이클에는 목표와 종료 기준이 있으며, 대사에 서명이 이루어지기 전에는 완료된 것이 아닙니다.

사이클	목표	종료 기준	담당
모의 로드 1	구조: 모든 오브젝트가 의존 순서대로 로드됨	오브젝트별로 매핑 격차와 형식 오류 기록	데이터 마이그레이션 리드
모의 로드 2	품질: 매핑 수정 사항 테스트, 데이터 이슈 노출	오브젝트별 오류율 감소, 정제 결정 기록	데이터 스튜어드
모의 로드 3	비즈니스 규칙: 예외와 엣지 케이스	스튜어드가 각 영역에서 대사된 샘플을 승인	데이터 스튜어드
모의 로드 4	실제 운영 규모에서의 물량과 타이밍	컷오버 윈도 안에 전체 로드 완료	컷오버 매니저
최종 리허설	델타와 동결을 포함한 컷오버 리허설	건수와 재무 합계가 대사되고 서명됨	재무 컨트롤러와 데이터 리드

이 계획 주변에서 차이를 만드는 것은 다섯 가지입니다.

1. Prepare 단계의 전체 추출. 샘플이 아니라 전부입니다. 완전성, 정확성, 일관성, 중복을 프로파일링한 다음, 결과로 정제 규모와 일정을 산정하십시오.
2. 오브젝트별 매핑. 각 오브젝트(비즈니스 파트너, 자재, 미결 구매 및 판매 오더, 미결 항목, 재고, 고정자산)에 대해 소스-타깃 필드, 변환 규칙, 검증 점검, 예외 규칙을 문서화하십시오.
3. 지정된 데이터 스튜어드. 재무는 고객과 공급업체의 재무 데이터를 책임집니다. 구매는 자재 마스터를, 창고는 재고를 책임집니다. 각 스튜어드는 사이클이 끝날 때마다 자기 영역에 서명합니다.
4. 사전에 정의한 대사 기준. 첫 모의 로드 전에 어떤 건수와 합계가 로드가 맞다는 증거인지 합의해 두어, 컷오버 때 아무도 그것을 두고 다투지 않게 하십시오.
5. 문서화된 컷오버 순서. 동결, 추출, 변환, 로드, 검증, 현업 승인, Go/No-Go. 최종 리허설과 같은 순서입니다.

신규 S/4HANA 구축에서는 SAP S/4HANA Migration Cockpit이 SAP가 권장하는 초기 로드 도구입니다. S/4HANA 2020부터는 Fiori 앱 Migrate Your Data로 실행됩니다. 트랜잭션 LTMC는 deprecated 상태이며 기존 LTMC 프로젝트는 조회만 가능합니다. 이 앱은 두 가지 방식을 제공합니다. 스테이징 테이블을 사용한 데이터 마이그레이션(파일 또는 자체 도구로 채움)과 SAP 소스 시스템에서의 직접 데이터 마이그레이션입니다. 온프레미스와 프라이빗 클라우드 팀은 마이그레이션 오브젝트 모델러인 트랜잭션 LTMOM으로 표준 오브젝트를 조정하거나 자체 오브젝트를 만듭니다. 이 코크핏은 초기 로드를 위한 것이며, 반복되는 인터페이스나 대량 변경용이 아닙니다.

SAP Data Services는 SAP의 ETL 플랫폼입니다. 대용량, 복잡한 변환 로직, 여러 소스 시스템이 있거나, 프로젝트 이후에도 쓸 수 있는 재사용 가능한 데이터 품질 프레임워크를 원할 때 사용하십시오.

서드파티 ETL 도구(Informatica, Talend, Microsoft SSIS 등)는 조직이 이미 보유하고 있고 이를 다룰 역량이 있을 때 적합합니다.

SAP Datasphere는 이제 SAP Business Data Cloud의 일부이며, 마이그레이션 도구가 아닙니다. 그 자리는 Go-Live 이후의 분석 계층입니다. 이력을 레거시 시스템에 남겨 두고 그에 대한 리포팅이 여전히 필요할 때 의미가 있습니다.

대부분의 표준 구축에서는 Migration Cockpit이 대다수 오브젝트를 처리합니다. 대용량, 크게 커스터마이징된 레거시 시스템, 특이한 소스 구조에서는 보통 Data Services나 ETL 도구를 함께 써야 합니다. ECC에서의 전환은 다른 작업이며, 제 ECC에서 S/4HANA로의 마이그레이션 가이드에서 다룹니다.

SAP 데이터 마이그레이션이란 무엇입니까?

SAP 데이터 마이그레이션은 구축 또는 전환의 일환으로 레거시 시스템에서 데이터를 추출하고, SAP의 구조와 규칙에 맞게 변환한 뒤, SAP에 로드하는 일입니다. 대표적인 오브젝트는 비즈니스 파트너(고객과 공급업체), 플랜트 데이터가 있는 자재, 미결 구매 및 판매 오더, 재고 잔액, 재무 미결 항목, 고정자산입니다. 레거시 시스템이 대개 강제하지 않던 의존 관계와 검증 규칙을 SAP가 강제하기 때문에 어렵습니다.

SAP 데이터 마이그레이션의 주요 접근 방식은 무엇입니까?

신규 구축(그린필드)은 선별한 마스터 데이터와 미결 항목을 새 S/4HANA 시스템에 로드하고, 이력은 레거시 시스템이나 아카이브에 남깁니다. 시스템 전환(브라운필드)은 기존 ECC 시스템과 그 이력을 그 자리에서 전환합니다. 선택적 데이터 전환은 그 사이에 있으며, 선택한 회사 코드, 오브젝트, 기간 단위를 옮깁니다. 올바른 선택은 데이터 품질, 이력 요구사항, 기존 프로세스를 얼마나 유지하고 싶은지에 달려 있습니다.

SAP Migration Cockpit이란 무엇이며 언제 사용해야 합니까?

SAP S/4HANA Migration Cockpit은 모든 에디션에서 S/4HANA로의 초기 데이터 로드에 SAP가 권장하는 도구입니다. S/4HANA 2020부터는 Fiori 앱 Migrate Your Data로 실행되며, 트랜잭션 LTMC는 deprecated 상태입니다. 사전 정의된 마이그레이션 오브젝트를 제공하고, 전기(posting) 전에 데이터를 검증하며, 필드 단위로 오류를 보고합니다. 표준 오브젝트와 보통 수준의 물량에 사용하십시오. 물량, 변환 로직, 소스 구조가 템플릿이 처리하는 범위를 넘어서면 SAP Data Services나 다른 ETL 도구를 추가하십시오.

SAP 데이터 마이그레이션은 모의 로드를 몇 번 계획해야 합니까?

최소 세 번이며, 마지막은 컷오버 전체 리허설이어야 합니다. 복잡한 프로젝트는 더 필요합니다. 일반적인 계획에서 첫 번째는 구조적 매핑 격차를 찾아냅니다. 두 번째는 수정 사항을 테스트하고 데이터 품질 문제를 드러냅니다. 세 번째는 비즈니스 규칙과 엣지 케이스를 다룹니다. 마지막 실행은 컷오버를 그대로 반복하며, 그 대사 결과가 Go-Live 당일의 기준선이 됩니다.

고객과 공급업체는 SAP S/4HANA로 어떻게 마이그레이션합니까?

비즈니스 파트너로 합니다. S/4HANA에서는 고객과 공급업체 마스터 데이터를 비즈니스 파트너를 통해 관리하며, 고객 롤과 공급업체 롤이 붙습니다. 신규 구축에서는 Migration Cockpit이 비즈니스 파트너 오브젝트로 이를 로드합니다. ECC에서의 전환에서는 전환 자체보다 먼저 고객-공급업체 통합을 설정하고 실행해야 합니다.

SAP 데이터 마이그레이션이 컷오버에서 실패하는 원인은 무엇입니까?

컷오버 실패 대부분은 다섯 가지 패턴에서 나옵니다. 너무 적은 모의 로드. 끝에서 끝까지 한 번도 테스트하지 않은 컷오버 순서. 마지막 모의 로드 이후 레거시에서 생긴 변경과 검증되지 않은 델타 로드. 해소되지 않은 대사 격차. 표본 확인에 근거한 현업 승인. "처음 1,000건은 괜찮아 보였다"는 검증이 아닙니다. Go-Live에는 대사된 건수와 합계가 필요합니다.