SAP 테스트 전략 (1) ECC to S/4HANA Migration

SAP ECC에서 S/4HANA로의 전환은 단순한 시스템 업그레이드가 아닙니다. 많은 기업들이 충분한 테스트를 거쳤다고 생각하지만, 실제 Go-live 후 업무가 중단되는 사례가 반복됩니다. 왜 이런 일이 발생하는 걸까요?

이 글에서는 SAP Migration 프로젝트에서 자주 발생하는 문제와 그 원인, 그리고 효과적인 검증 전략을 소개합니다.

SAP Migration 시 자주 발생하는 문제들

SAP ECC에서 S/4HANA로 전환한 후 첫 업무일, 많은 기업들이 예상치 못한 문제에 직면합니다.

현장에서 실제로 일어나는 일:

• 영업팀: 판매오더(VA01) 생성 시 가격이 제대로 계산되지 않음

• 구매팀: 발주서(FB01) 작성 시 거래처 정보 불완전으로 진행 불가

• 재무팀: 월말 마감 시 자산/세금/원가 데이터 불일치로 결산 실패

이런 문제들은 단순한 버그가 아닙니다. 시스템 전환 과정에서 구조적으로 발생하는 이슈들입니다.

왜 이런 일이 발생할까?

Migration 실패의 가장 흔한 세 가지 원인이 있습니다.

1. BP(Business Partner) Role 전환 오류

거래처 역할 정보가 제대로 옮겨지지 않아 거래 처리가 불가능해집니다.

ECC에서는 단순하게 관리되던 거래처 정보가 S/4HANA에서는 더 세분화된 역할(Role)로 구분됩니다. 고객, 공급업체 등 기본 정보는 존재하지만 세부 역할이 누락되면 해당 거래처와의 모든 거래가 중단됩니다.

2. 조건 마스터(Condition Master) 불일치

가격 결정 규칙이 신규 시스템에 맞게 전환되지 않습니다.

할인율, 세금 계산, 운송비 적용 등 복잡한 가격 결정 로직이 S/4HANA 구조에 맞지 않으면 견적서나 청구서 금액이 틀어집니다.

3. 모듈 간 연결 단절

FI-SD-MM-PP 등 모듈 간 인터페이스가 깨져 전체 프로세스가 중단됩니다.

각 모듈은 개별적으로 정상 작동하지만, 모듈 간 데이터 전달 지점에서 오류가 발생하면 구매부터 지급까지, 판매부터 수금까지 이어지는 전체 업무 흐름이 멈춥니다.

ECC와 S/4HANA는 근본적인 구조가 다릅니다.

단순 데이터 전환만으로는 정상 작동을 보장할 수 없습니다.

• 데이터 저장: 테이블 기반 → CDS View 기반

• 비즈니스 로직: ABAP 프로그램 → Embedded Analytics

• 트랜잭션 처리 방식 변경

그렇다면 많은 기업들이 전환 전에 테스트를 수행하는데, 왜 이런 문제들을 미리 발견하지 못할까요?

기존 테스트 방식의 한계

대부분의 기업은 SAP Migration 전에 충분한 테스트를 수행했다고 생각합니다. 하지만 전환 후에도 문제가 발생하는 이유는 테스트 방식 자체에 근본적인 한계가 있기 때문입니다.

1. 샘플 데이터 중심의 테스트

전통적인 테스트 방식의 첫 번째 문제는 샘플 데이터 의존성입니다.

테스트 환경의 현실:

• 거래처 10개, 품목 20개 정도의 깨끗한 샘플 데이터 사용

• 정상적인 거래만 확인

• 예외 상황 미반영: 다중 통화, 특수 세금, 복잡한 가격 조건

실제 운영 환경:

• 수천 개의 거래처, 수만 개의 품목

• 수백 가지 조건 조합

• 복잡한 예외 케이스가 일상

샘플 데이터는 의도적으로 단순화되고 정제된 데이터입니다. 실제 비즈니스에서는 특별 할인이 적용되고, 여러 통화로 거래하고, 국가별로 다른 세금이 계산됩니다.

결과적으로, 샘플 테스트에서는 "정상" 케이스만 통과하고 실제 운영에서 발생하는 "예외" 케이스들은 전혀 검증되지 않습니다.

2. 반복되는 데이터 전환과 유지보수 부담

두 번째 문제는 SAP Migration 프로젝트의 특성에서 발생합니다.

전환 사이클:

• 1차 연습 전환 → 데이터 수정

• 2차 리허설 전환 → 데이터 수정

• 3차 최종 전환

각 전환마다 데이터가 조금씩 달라집니다. 거래처 코드가 바뀌고, 품목 번호가 재정의되고, 조직 구조가 조정됩니다.

문제점:

• 매번 데이터가 바뀔 때마다 테스트 스크립트 수정 필요

• 유지보수 비용 폭증

• 최종 전환 데이터와 테스트 데이터 불일치

이러한 문제점으로 인해, 시간이 갈수록 전환 품질 검증보다는 변경된 데이터에 맞춰 테스트 스크립트를 수정하는 데 더 많은 시간을 쏟게 됩니다.

3. 수작업 검증의 현실적 한계

아무리 체계적으로 테스트를 설계해도, 결국 사람이 직접 확인해야 한다면 한계가 명확합니다.

수작업 검증의 문제:

• 사람이 확인할 수 있는 범위: 전체의 20-30%에 불과

• 수천 개 트랜잭션 일일이 확인 불가능

• 깊은 밤/주말 작업으로 피로 누적 → 실수 증가

오류 발견 시점의 위험:

• Go-live 직전 발견: 프로젝트 일정 지연

• Go-live 이후 발견: 실제 업무 중단 → 비즈니스 연속성 위험

긴급 수정 작업에 투입되는 비용과 인력은 사전 검증 비용의 수십 배에 달합니다.

그렇다면 이런 문제들을 어떻게 해결할 수 있을까요? 효과적인 SAP Migration 테스트를 위한 네 가지 핵심 전략을 소개합니다.

효과적인 SAP Migration 테스트 전략

기존 테스트 방식의 한계를 극복하기 위해서는 근본적으로 다른 접근이 필요합니다. 여기서 소개하는 네 가지 전략은 실제 SAP Migration 프로젝트에서 검증된 방법들입니다.

전략 1: 운영 실데이터 자동 추출 기반 테스트

첫 번째 전략은 테스트 데이터 자체를 바꾸는 것입니다. 샘플 데이터가 아닌 실제 운영 데이터를 활용해야 합니다.

핵심 접근법:

• 최근 6개월~1년 트랜잭션 로그 자동 분석

• 실제 거래 패턴, 예외 케이스, 경계값 모두 포함

• 수작업 없이 자동 추출로 유지보수 부담 최소화

실제 운영 환경에서 발생한 거래들을 그대로 자동 추출하여 테스트에 활용합니다. 지난 1년간 실제로 처리된 판매오더, 구매오더, 청구서, 지급 내역을 모두 분석합니다.

그 안에는 특별 할인이 적용된 케이스, 다중 통화로 결제된 케이스, 복잡한 세금이 계산된 케이스가 모두 포함되어 있습니다.

자동 추출의 장점:

✅ 실제 업무 환경 그대로 반영

• 복잡한 조건 조합 자동 포함

• 예외 케이스 누락 없음

✅ 유지보수 효율성

• 데이터 변경 시 재추출만 하면 됨

• 스크립트 수정 불필요

✅ 성능 검증

• 실제 데이터 볼륨과 부하 반영

• 성능 병목 지점 사전 탐지

특히 '자동 추출'이라는 점이 중요합니다. 2차, 3차 전환 때마다 새로운 데이터를 재추출하여 테스트하면 됩니다. 이것만으로도 유지보수 부담을 크게 줄일 수 있습니다.

전략 2: 전환 오류 패턴 사전 내장

두 번째 전략은 과거의 경험을 체계화하는 것입니다.

자주 발생하는 오류:

• 세금 코드 매핑 오류: 국가별, 품목별 세금 규칙이 신규 시스템에 맞지 않음

• BP Role 누락: 고객/공급업체 역할 정보가 제대로 전환되지 않음

• 조건 마스터의 가격 결정 규칙 불일치: 할인, 할증, 운송비 계산 로직 오류

이런 오류들은 대부분의 SAP Migration 프로젝트에서 공통적으로 나타납니다.

사전 내장 접근법:

Step 1: 오류 패턴 데이터베이스 구축

• 과거 프로젝트 오류 이력 수집

• 세금, BP, 조건 마스터 영역별 분류

Step 2: 자동 스캔 체계

• 전환 직후 패턴 매칭 자동 실행

• 리스크 영역 즉시 식별

Step 3: 조기 대응

• 초기 단계 문제 발견 → 수정 비용 최소화

• 같은 실수 반복 방지

과거 프로젝트에서 발생한 오류들을 체계적으로 정리합니다. 전환된 데이터를 스캔하여 "이 세금 코드는 과거에 문제를 일으켰던 패턴입니다", "이 BP는 Role이 누락될 가능성이 높습니다" 라고 사전에 경고합니다.

전략 3: Cross-Module E2E 시퀀스 자동 생성·리플레이

세 번째 전략은 부분이 아닌 전체를 보는 것입니다.

실제 업무는 여러 모듈을 거쳐 흐릅니다. 구매팀, 재무팀 시스템을 개별 테스트했을 때는 정상이었지만, 실제로 구매에서 지급까지 전체 프로세스를 실행하면 중간에 데이터가 제대로 전달되지 않아 멈춥니다.

※ E2E 시나리오 예시

[구매 프로세스] 구매요청(MM) → 구매오더(MM) → 입고(MM) → 송장검증(FI) → 지급(FI)

[판매 프로세스] 판매오더(SD) → 출하(SD) → 청구(SD) → 수금(FI)

자동 생성·리플레이 프로세스

1단계: 자동 생성

• 운영 로그 분석으로 실제 비즈니스 프로세스 흐름 추출

• 수작업 시나리오 작성 불필요

2단계: 자동 리플레이

• 전환 후 시스템에서 시나리오 그대로 재실행

• 모듈 간 인터페이스 오류 즉시 탐지

3단계: 반복 검증

• 수정 후 동일 시나리오로 회귀 테스트

• 안정성 지속 확인

실제 운영 시스템의 로그를 분석하면, 어떤 트랜잭션들이 어떤 순서로 실행되는지 자동으로 파악할 수 있습니다. 이를 바탕으로 E2E 시나리오를 자동 생성하고, 전환 후 신규 시스템에서 그대로 재실행합니다.

SAP Migration 테스트 실행 단계

앞서 소개한 전략들을 실제 프로젝트에 적용하려면 체계적인 실행 계획이 필요합니다. Migration 테스트는 크게 세 단계로 나눌 수 있습니다.

Phase 1: 준비 (전환 2-3개월 전)

전환 작업 2-3개월 전부터 테스트 준비를 시작해야 합니다.

주요 활동:

• 운영 트랜잭션 로그 자동 추출 및 분석

• 대표 케이스 선정

• 개인정보 마스킹/합성 작업

• 전환 오류 패턴 사전 내장

• Cross-module E2E 시나리오 자동 생성

핵심 작업:

6개월에서 1년치의 트랜잭션 로그를 분석하여 대표적인 거래 패턴을 파악합니다. 운영 시스템에서 데이터를 추출할 때는 업무 시간대를 피하고, 시스템 부하를 최소화합니다.

대표 케이스를 선정할 때는 빈도와 중요도를 함께 고려합니다.

• 가장 자주 발생하는 거래 유형 (Top 케이스)

• 드물지만 critical한 거래 (희귀 케이스)

• 시스템 한계를 테스트하는 경계값 케이스

산출물:

• 테스트 데이터셋 (마스킹/합성 완료)

• 오류 패턴 데이터베이스

• E2E 시나리오 목록

Phase 2: 초기 검증 (전환 직후)

전환 작업이 완료되면 즉시 집중 검증을 시작합니다.

즉시 실행:

• 핵심 E2E 시나리오 자동 리플레이

• 거래 유형별 검증 (판매/구매/재무/자산)

• 오류 패턴 자동 스캔

• 세금·BP·조건 마스터 집중 검증

실행 타이밍:

보통 전환 작업이 토요일 밤에 끝나면, 일요일 새벽부터 자동 테스트를 시작합니다. 다음날 아침이면 전체 테스트 결과를 확인할 수 있습니다.

우선순위 설정:

• Critical 오류 즉시 대응 (업무 중단 위험)

• High 오류 당일 내 대응 (주요 기능 영향)

• Medium 오류 순차 처리 (일부 기능 영향)

Phase 3: 집중 안정화 (전환 후 1개월)

Go-live 후 첫 한 달은 시스템 안정화에 가장 중요한 시기입니다.

지속 모니터링:

• 일일/주간 자동 테스트 실행

• 신규 오류 즉시 대응

• 수정 후 자동 리플레이로 회귀 테스트

• 시스템 안정성 추세 분석

모니터링 주기:

• 1주차: 매일

• 2-3주차: 격일

• 4주차 이후: 주간

목표: Go-live 후 1개월 내 안정화 달성

통상적으로 전환 후 2-4주 정도면 대부분의 문제가 해결되고 시스템이 안정화됩니다.

SAP Migration 체크리스트

SAP Migration 프로젝트를 시작하기 전에 다음 체크리스트를 활용하여 준비 상태를 점검하세요.

데이터 준비

• 실제 운영 데이터 6개월~1년치 수집 완료

• 자동 추출 도구 또는 방법 준비

• 개인정보 마스킹 계획 수립 및 법무 검토 완료

• 예외 케이스 포함 여부 확인 (특별 할인, 다중 통화, 특수 세금 등)

• 데이터 볼륨 및 성능 테스트 계획 수립

테스트 설계

• 5-10개 핵심 E2E 시나리오 자동 생성 준비

• 전환 오류 패턴(세금·BP·조건 마스터) 사전 내장

• 모듈 간 인터페이스 검증 포인트 식별

• 자동 리플레이 체계 구축

• 테스트 환경 구성 완료 (개발/품질/운영 분리)

실행 체계

• 자동화 가능 영역 최대화 (목표: 80% 이상)

• 오류 대응 프로세스 정의 (담당자, 에스컬레이션 경로)

• 전환 후 모니터링 계획 수립 (일일/주간 리포트)

• 롤백 계획 수립 (Critical 오류 발생 시 대응)

• 의사소통 채널 구축 (Slack, Teams 등)

결론

SAP Migration은 기술 프로젝트인 동시에 비즈니스 연속성을 좌우하는 중요한 전환입니다.

성공적인 Migration을 위한 핵심 요소:

✅ 실제 데이터 기반 현실적 테스트

• 샘플이 아닌 운영 데이터로 예외 케이스까지 검증

✅ 오류 패턴 조기 탐지 체계

• 과거 경험을 체계화하여 반복 실수 방지

✅ 전체 프로세스 E2E 검증

• 부분이 아닌 전체 업무 흐름 확인

✅ 지속적인 모니터링과 빠른 대응

• Go-live 후 1개월간 집중 관리로 안정화

이 네 가지 요소를 갖춘 체계적인 검증 전략을 통해 리스크를 최소화하고, 안정적인 전환을 실현할 수 있습니다.

SAP Migration은 단순히 시스템을 바꾸는 것이 아니라, 더 나은 비즈니스 기반을 만드는 기회입니다. 철저한 준비와 검증으로 성공적인 전환을 이루시기 바랍니다.

다음 편 예고: SAP 테스트 전략 2편, S/4 → S/4 Upgrade (Private Cloud)에 대해 알아보겠습니다.