SAP Go-live 전에 잡아야 할 것 vs Go-live 후에야 보이는 것

ECC에서 S/4HANA로의 Migration을 앞둔 의사 결정자를 위한 사전 검증과 사후 모니터링의 역할 분담. 그리고 그 경계선은 생각보다 유연합니다.

May 06, 2026

SAP Go-live 전에 잡아야 할 것 vs Go-live 후에야 보이는 것

Contents

1. Go-live 전에 잡을 수 있는 것 Migration의 직접 영향 비즈니스 로직 E2E 흐름 모듈 간 정합성 의도적으로 구성한 예외 케이스 2. 보통은 Go-live 후에야 보인다고 여겨지는 것 실 부하 패턴 엣지 케이스 / 특이 거래 외부 연계 시스템과 주고받는 실제 데이터 패턴 누적된 마스터·트랜잭션 데이터 분포 3. 이 경계는 움직인다 Real Data Extractor 연계 시스템과 주고받은 실제 데이터 기반 사전 검증 4. 그래도 남는 진짜 사후 영역 실 사용자의 예측 불가 행동 변화 시스템의 장기 성능 저하 Go-live 이후 외부 시스템 자체의 변경 5. 그래서 사전에 잡을 수 있는 것은 최대한 잡아둬야 한다

수개월의 ECC→S/4HANA Migration 끝에 드디어 Go-live.
안정화 단계가 시작되고 며칠은 별 문제 없이 지나갑니다. 시스템은 정상으로 보입니다. 그런데 영업팀에서 전화가 옵니다.

"주문이 안 만들어져요."

추적해보니 Migration 과정에서 어떤 마스터 데이터의 매핑이 미세하게 어긋나면서 다른 프로세스를 조용히 깨뜨린 것입니다. 운영 중 수정에 며칠, 영향 분석에 또 며칠. 안정화 기간이 길어집니다.

이때 진짜로 던져야 할 질문은 따로 있습니다.

이건 Go-live 전에 잡을 수 있었던 영역인가, 아니면 운영에 들어가야만 보이는 종류였나? 이 질문에 답하지 못하면 안정화 기간이 무한 연장되고, 이후 분기 업그레이드에서도 같은 패턴이 반복됩니다.

SAP가 Cloud ALM 체계 안에서 Operations 모니터링을 점점 강력하게 만들고 있는 시점이라, 이 질문은 더 첨예해졌습니다. "모니터링이 이렇게 좋아졌는데 사전 회귀 테스트는 어디까지 해야 하나?"

이 글은 ECC→S/4HANA Migration을 분기점으로 두고, 사전과 사후 검증 활동을 정리합니다. 무엇을 사전에 잡아야 하고, 무엇이 사후에서만 보이는지. 그리고 그 경계가 어떻게 움직이는지 살펴봅니다.

1. Go-live 전에 잡을 수 있는 것

ECC→S/4HANA Migration은 SAP 시스템에서 일어날 수 있는 가장 큰 변화입니다. 사전 검증, 즉 회귀 테스트와 같이 의도적으로 시나리오를 실행하는 활동으로 충분히 커버되는 영역이 있습니다.

Migration의 직접 영향

ECC와 S/4HANA의 차이는 명확하게 정의되어 있습니다.
테이블 구조 변경(BSEG, BSIK 통합), CDS View 도입, Fiori 앱 전환, OData 서비스 추가, 비즈니스 파트너 통합. 변경 사항은 SAP의 Simplification List와 Migration Cockpit 가이드에 모두 정리되어 있습니다. 이러한 변경이 기존 프로세스를 깨뜨리는지는 사전에 검증할 수 있습니다.

비즈니스 로직 E2E 흐름

Order-to-Cash, Procure-to-Pay 같은 핵심 프로세스가 Migration 후에도 끊김 없이 흐르는지를 확인하는 일입니다. 판매 오더 생성부터 회계 전표 생성까지 한 시나리오로 묶어 실행해보면 깨지는 지점이 그대로 드러납니다.

모듈 간 정합성

SD에서 생성된 데이터가 FI로 넘어가면서 매핑이 어긋나는 문제, MM과 WM 사이에서 데이터가 유실되는 문제 — 이런 cross-module 정합성 이슈는 모듈별 단위 테스트로는 잡히지 않지만, 모듈을 가로지르는 시나리오를 사전에 실행하면 잡힙니다. Migration에서 가장 자주 터지는 영역이기도 합니다.

의도적으로 구성한 예외 케이스

특정 조건 조합에서 Migration 이후 시스템이 어떻게 반응하는지를 사전에 의도적으로 검증하는 것입니다. 테스트 시나리오를 설계할 때 "이 조합은 깨질 수 있겠다"고 의식적으로 포함시킨 케이스들이 여기 해당합니다.

이 영역들에는 한 가지 공통점이 있습니다. Go-live 전에, 의도적으로 시나리오를 실행해서 확인할 수 있다는 것입니다. Cloud ALM 모니터링으로는 잡을 수 없는 영역입니다. 모니터링은 실제로 트랜잭션이 흘러야 작동하는 도구이기 때문에, 아직 일어나지 않은 변경의 결과는 관찰할 수 없습니다.

Migration Go-live를 중심으로 사전 검증과 사후 모니터링의 시점·방식 비교표

2. 보통은 Go-live 후에야 보인다고 여겨지는 것

반면, 전통적으로 운영에 들어가야만 보인다고 분류되어 온 영역이 있습니다.

실 부하 패턴

월말 마감 시 평소의 5배 트랜잭션이 몰리는 패턴, 분기말 결산 주에 특정 잡(Job)이 동시에 실행되는 패턴, 글로벌 자회사가 시간대 차이로 야간에 인터페이스 호출을 집중시키는 패턴. 이런 부하는 실제 운영이 시작되어야 자연스럽게 발생합니다. ECC에서는 이미 일어나고 있던 일이지만, 새 S/4HANA 환경에서도 그대로 작동할지는 다른 이야기입니다.

엣지 케이스 / 특이 거래

특별 할인 + 다중 통화 + 면세 조건이 동시에 적용된 거래, 부분 취소 후 재청구가 이어지는 거래, 수동 보정 항목이 들어간 마감 거래. 이런 조합을 사람이 미리 시나리오로 다 작성하기는 어렵습니다.

외부 연계 시스템과 주고받는 실제 데이터 패턴

SAP-MES, SAP-WMS, SAP-은행 EDI 같은 인터페이스에서 실제로 어떤 데이터가 어떤 빈도로, 어떤 예외 상황에서 오가는지. 이런 패턴은 실제 운영 트래픽이 흘러야 드러납니다.

누적된 마스터·트랜잭션 데이터 분포

수년간 ECC에서 쌓인 자재 코드 변형, 거래처 분류 체계의 미세한 차이, 조직 구조 개편 이력이 만든 데이터 분포 — 이런 누적 효과는 Migration 이후 새 환경에서 다르게 작동할 수 있습니다.

이 영역들은 흔히 "사후 모니터링으로만 잡을 수 있다"고 여겨져 왔습니다. Cloud ALM Operations가 이 영역을 점점 더 잘 관찰할 수 있도록 강화되고 있는 이유이기도 합니다.

여기까지 읽고 나면 자연스럽게 도출되는 결론이 있습니다. "그러니까 사전 검증과 사후 모니터링은 둘 다 필요하다." 맞는 말입니다. 다만 한 단계만 더 들어가 보겠습니다.

3. 이 경계는 움직인다

사후 영역으로 분류되는 4가지 중 일부는, 사실 ECC 운영 데이터를 S/4HANA 사전 검증 시나리오로 끌어오면 사전에 잡을 수 있습니다.

핵심은 단순합니다. ECC는 이미 수년간 운영되고 있고, 위 4가지 영역의 데이터가 ECC 운영 DB에 그대로 쌓여 있습니다. 부하 패턴, 실제 발생한 엣지 케이스, 외부 시스템과 주고받은 통신 기록, 누적된 마스터 데이터 분포 — 모두 ECC에 이미 있습니다. 이 데이터를 S/4HANA 사전 시나리오로 가져올 수 있다면, "Go-live 후에야 보인다"고 분류했던 영역의 상당 부분이 사전 검증 영역으로 넘어옵니다.

PerfecTwin은 정확히 이 영역에서 두 가지 메커니즘으로 작동합니다.

Real Data Extractor

ECC 운영 DB에 저장된 실제 거래 데이터를 직접 추출해서 S/4HANA 테스트 시나리오에 연결합니다. 샘플 데이터를 인위적으로 만들지 않고 ECC 운영 거래의 분포를 그대로 사전 시나리오에 반영합니다.

연계 시스템과 주고받은 실제 데이터 기반 사전 검증

ECC와 주변 시스템 사이에서 실제로 흐른 데이터 패턴을 사전 시나리오에 반영해서, 새 S/4HANA 환경에서 인터페이스 동작을 운영 전에 검증합니다.

이 두 메커니즘이 결합되면 다음과 같은 일들이 가능해집니다.

부하 패턴: ECC 운영 거래 로그에서 시간대별·요일별·월말 패턴을 추출해 S/4HANA 사전 부하 시나리오로 재구성
엣지 케이스: ECC에서 실제 발생한 특이 거래·예외 처리가 운영 데이터에 모두 기록되어 있으므로 S/4HANA 사전 시나리오에 자연 포함
외부 연계 통신: 실제 송수신 데이터 기반으로 인터페이스 동작을 새 환경에서 사전 시뮬레이션
데이터 분포: ECC 마스터·트랜잭션의 실제 분포를 S/4HANA 사전 시나리오에 그대로 반영

관련 포스팅: 사전 시나리오에 운영 데이터를 어떻게 가져오는지에 대한 더 자세한 논의 → 실데이터 기반 SAP Migration 테스트

사전 영역과 사후 영역의 경계는 고정되어 있지 않습니다. 어떤 도구를 쓰는가에 따라 움직일 수 있습니다.

4. 그래도 남는 진짜 사후 영역

물론 사후의 모든 것을 사전으로 끌어올 수는 없습니다. 진짜 사후에서만 가능한 영역이 분명히 있습니다.

실 사용자의 예측 불가 행동 변화

Go-live 이후 사용자들이 새 S/4HANA 화면에 어떻게 적응하는지, 어떤 화면에서 이탈하는지, 어떤 기능을 우회해서 쓰는지. 이건 사전 데이터로는 시뮬레이션할 수 없습니다. 하지만 이 데이터들이 꾸준히 쌓이고, 이를 다음 테스트에 활용할 수 있다면 예측 불가능한 행동 패턴이 줄어듭니다.

시스템의 장기 성능 저하

6개월, 1년이 지나면서 새 환경에서 인덱스가 비대해지고, 특정 테이블이 느려지고, 대시보드 응답 시간이 길어지는 현상. 시간이 지나야 드러납니다.

Go-live 이후 외부 시스템 자체의 변경

연계 시스템이 자체적으로 API를 변경하거나, 거래처가 EDI 포맷을 바꾸거나, 정부 시스템이 새 인증 방식을 도입하는 일. 우리 SAP 쪽 사전 검증으로는 잡을 수 없습니다.

이 영역들은 Cloud ALM 모니터링이 본격적으로 작동해야 하는 영역입니다. 사전 시뮬레이션의 한계 밖에 있습니다.

5. 그래서 사전에 잡을 수 있는 것은 최대한 잡아둬야 한다

여기까지 정리하면 그림이 명확해집니다. 사후 모니터링이 떠안아야 할 진짜 자기 일은 정해져 있습니다 — 사용자 행동, 장기 효과, 외부 변경.

문제는 사전에 잡을 수 있는 것까지 사후로 흘려보낼 때 발생합니다. 그러면 사후 모니터링은 자기 본업뿐 아니라 사전에서 누락된 Migration 영향까지 동시에 떠안아야 합니다. 운영팀은 영구 사후 수습(firefighting) 모드로 들어가고, 안정화 기간은 무한 연장됩니다.

반대로 사전 검증의 영역을 최대한 넓혀두면 사후 모니터링은 본업에 집중할 수 있습니다. 안정화 기간은 빠르게 정상 운영으로 전환되고, Migration 이후 분기 업그레이드 사이클에서도 같은 안정성이 유지됩니다. 한 번 구축한 사전 검증 자산이 분기마다 재실행되는 회귀 테스트 자산으로 그대로 살아납니다.

관련 포스팅: 사전 검증 자체의 속도와 커버리지를 어떻게 끌어올리는가 → 회귀 테스트 5가지 구조적 병목

Go-live는 끝이 아닙니다. 분기점입니다. 그리고 분기점의 위치는 도구가 결정합니다.

ECC→S/4HANA Migration은 SAP 운영 라이프사이클에서 가장 큰 분기점입니다. 이 분기점에서 사전 검증 영역을 어디까지 넓혀두느냐가 Go-live 직후 안정화 기간의 길이를 결정하고, 그 이후 매 분기 업그레이드의 안정성을 결정합니다. 이 원칙은 RISE Private Cloud의 정기 업그레이드, GROW의 반기 업그레이드 같은 후속 변경에도 동일하게 적용됩니다.

사전과 사후는 경쟁 관계가 아닙니다. 사전이 약하면 사후가 폭주하고, 사전이 깊으면 사후가 본질에 집중합니다.

PerfecTwin이 ECC→S/4HANA 사전 검증 영역을 어디까지 넓힐 수 있는지 직접 확인해보세요. → 직접 확인하기

Contents