SPDD는 데이터 사전(DDIC) 구조를 복구하는 단계, SPAU는 프로그램·로직을 복구하는 단계로, S/4HANA 전환에서는 두 작업의 순서와 전략이 일정과 품질을 좌우합니다. 특히 Simplification Item SPAU는 유지·폐기·재구현을 결정하는 비즈니스 의사결정 단계입니다.
SPDD SPAU 차이: 구조적으로 보면 답이 보입니다
한 문장으로 말씀드리면, SPDD와 SPAU는 ‘객체 종류’보다 ‘복구 전략’의 차이입니다. SPDD는 DDIC, 즉 데이터 사전 객체를 다룹니다. 테이블, 구조, 데이터 엘리먼트, 도메인처럼 데이터 구조 자체에 손댄 Modification를 복구하는 단계죠. 예를 들어 과거 ECC에서 BSEG에 직접 필드를 붙였거나 TRM 관련 테이블을 표준 구조에 맞지 않게 확장했다면, 이건 단순 화면 수정이 아니라 데이터 무결성에 영향을 주는 문제입니다. 그래서 SPDD가 먼저 나옵니다. 데이터 구조가 흔들리면 그 위에서 도는 프로그램은 아무리 잘 병합해도 의미가 없거든요.
부가 설명: 실제 프로젝트에서 SPDD를 늦게 처리하면 활성화 오류, 변환 실패, 후속 테스트 지연이 연쇄적으로 발생합니다. “먼저 구조, 그다음 로직”이 기본 원칙입니다.
SPDD vs SPAU 차이, 그리고 Modification vs Enhancement 비교
SPAU는 프로그램, 함수모듈, 클래스, 화면, 메뉴 같은 Repository 객체를 다룹니다. 쉽게 말해 비즈니스 로직 쪽입니다. FI에서 RFFO* 지급런 로직이나 RFITEMAP 관련 변경, TRM의 Deal 처리용 표준 함수 수정 같은 것이 여기에 들어갑니다. SPDD와 달리 비교·병합·Reset 같은 선택지가 조금 더 유연합니다. 하지만 유연하다고 해서 가볍게 보면 안 됩니다. 여기서 잘못 살린 코드는 테스트에서만 통과하고 운영에서 덤프를 일으키는 경우가 많습니다.
| 구분 | SPDD | SPAU | Enhancement |
|---|---|---|---|
| 대상 | DDIC 객체 | 프로그램/로직 | Exit, BAdI, Enhancement Spot |
| 성격 | 데이터 구조 복구 | 표준 로직 복구 | 표준 확장 |
| 우선순위 | 매우 높음 | 높음 | 별도 영향 분석 필요 |
| 위험 | 데이터 무결성 | 기능 오동작/덤프 | 구현 위치 오류 시 영향 |
| 권장 방향 | 최소화 | 선별 유지 | 적극 활용 |
표를 보시면 감이 오실 겁니다. Modification은 SAP 표준 소스를 직접 바꾸는 방식이고, Enhancement는 표준을 건드리지 않고 확장 포인트를 활용하는 방식입니다. S/4HANA에서는 Clean Core 관점 때문에 후자가 훨씬 중요해졌습니다.
S/4HANA 변경사항을 확인해보면 과거 ECC에서 유지되던 일부 표준 수정 로직은 S/4HANA Simplification 영향으로 단순 병합이 아니라 폐기 또는 재설계 대상이 됩니다.
Simplification Item SPAU가 왜 중요할까요
여기서 많은 분이 놓치는 게 Simplification Item SPAU입니다. 예전엔 “수정 비교해서 맞추면 끝”이라는 접근이 가능했지만, S/4HANA에서는 그 코드가 아예 존재 가치가 있는지 다시 봐야 합니다. 대표적으로 Classic Cash Management에서 One Exposure로 넘어가는 구간이 그렇습니다. 당시에도 “일단 기존 코드 살리고 나중에 정리하자”는 말이 많았지만 실제로는 그 선택이 가장 비쌌습니다. 나중에 두 번 테스트하고, 운영 중 장애도 두 번 맞거든요.
부가 설명: SPAU는 이제 기술 병합 작업이 아니라 비즈니스 구조 재검토 단계입니다. 살리는 결정만큼 버리는 결정이 중요합니다.
SUM SPDD SPAU 흐름: IMG가 아니라 업그레이드 생명주기입니다
이 부분은 꼭 짚고 넘어가야 합니다. SPDD/SPAU는 IMG 설정이 아닙니다. Software Update Manager, 즉 SUM 프로세스의 일부입니다. 그래서 SPRO 경로가 없습니다. 이걸 커스터마이징처럼 접근하면 준비 순서가 완전히 어긋납니다. 관련 트랜잭션은 SPDD, SPAU, SPAU_ENH이고, 사전 분석에는 ATC, SE14, 덤프 확인용 ST22를 주로 봅니다. SAP 버전에 따라 동작이 다를 수 있으니 SAP Help Portal 확인을 권장합니다.
부가 설명: SPDD/SPAU는 전환 도중 갑자기 등장하는 것이 아니라, 사전 준비 품질을 검증하는 관문입니다. 미리 목록을 뽑아보면 일정 예측이 훨씬 정확해집니다.
- PREPARE — S/4HANA 전환 사전 준비 단계
- EXECUTE — 시스템 전환 실행
- SPDD — Dictionary 오브젝트 충돌 조정
- SPAU — Repository 오브젝트 수정 조정
- SPAU_ENH — Enhancement 오브젝트 수정 조정
- ATC 및 테스트 — ABAP Test Cockpit 검증 및 회귀 테스트
즉, SUM에서 SPDD는 구조 안정화, SPAU는 로직 조정, SPAU_ENH는 확장 영향 확인 단계로 보시면 됩니다.
SPDD, SPAU, SPAU_ENH 처리 비교
| 단계 | 주요 트랜잭션 | 무엇을 보나 | 핵심 액션 |
|---|---|---|---|
| SPDD | SPDD | DDIC 변경 충돌 | Adjust, Reset, 수동 병합 |
| SPAU | SPAU | 프로그램/함수/화면 수정 | Reset to Original, Adjust, Redo |
| SPAU_ENH | SPAU_ENH | BAdI/Enhancement 영향 | 재활성화, 재구현 검토 |
| 사전 점검 | ATC | Custom Code Adaptation | S/4 variant 분석 |
| 후속 조치 | SE14/ST22 | 활성화/덤프 | 구조 재활성화, 오류 분석 |
실무적으로는 RC_S4_PRE_TRANSITION_CHECKS와 ATC의 S/4 체크 variant를 먼저 돌려서 Custom Code Adaptation 범위를 잡는 게 좋습니다. 현장에서 자주 마주치는 상황은, SPAU 객체 수는 많은데 실제로 유지할 가치가 있는 건 절반 이하인 경우입니다.
부가 설명: 수량이 많다고 다 중요한 건 아닙니다. “객체 개수”보다 “프로세스 영향도”로 우선순위를 다시 매겨야 합니다.
Modification vs Enhancement 관점의 실무 팁: 여기서 성패가 갈립니다
제가 항상 말씀드리는 원칙은 간단합니다. SPDD는 무조건 선처리, SPAU는 전략적 처리입니다. 그리고 SPAU는 기술 작업이 아니라 비즈니스 의사결정입니다. FI 쪽에서는 RGGBS000 기반 Substitution Exit, 지급런과 DME 파일 생성에 연결된 RFFO* 수정, 오픈아이템 리포트류 변경을 먼저 봐야 합니다. TRM은 Deal Processing, Flow Builder, Valuation 영향 로직을 우선 확인하시고요. Cash Management는 One Exposure 전환 여부와 기존 사용자 수정이 충돌하는지 꼭 체크해야 합니다.
| 판단 기준 | 유지 | 폐기 | Enhancement 전환 |
|---|---|---|---|
| S/4 표준 대체 가능성 | 낮음 | 높음 | 중간 |
| 비즈니스 중요도 | 매우 높음 | 낮음 | 높음 |
| 테스트 비용 | 감수 가능 | 줄여야 함 | 초기 높지만 장기 유리 |
| 유지보수성 | 낮음 | 높음 | 가장 좋음 |
실제 프로젝트에서 이런 케이스가 있었는데요. SPAU 객체가 3,000건 넘게 나왔지만, 비즈니스 오너와 같이 하나씩 의미를 따져보니 약 40%는 과감히 폐기했습니다. 결과적으로 테스트 범위가 줄고 전환 품질은 오히려 좋아졌습니다. 반대로 지급 프로그램 수정은 “예전부터 잘 돌았으니 유지하자”로 갔다가 Go-live 직전 Payment Medium dump가 발생한 적도 있었습니다. 겉으로는 지급런이 완료됐는데 DME 파일에서 포맷 불일치가 난 거죠. 그때 느낀 건, 오래 살아남은 코드가 꼭 좋은 코드는 아니라는 점입니다.
다시 이야기 드려보면, 살릴 코드보다 버릴 코드를 먼저 찾는 접근이 S/4 전환에서는 훨씬 효과적입니다. Clean Core는 미학이 아니라 유지보수 비용 절감 전략입니다.
SPDD 오류, SPAU 오류, Simplification ATC Error 해결
자주 터지는 이슈는 패턴이 있습니다. 로그를 순서대로 보면 대부분 원인이 잡힙니다. SUM 로그, SPDD/SPAU 로그, ST22, 그다음 ATC 결과와 SAP Notes 검색 순으로 보시면 됩니다.
| 오류/증상 | 발생 원인 | 확인 포인트 | 해결 방법 |
|---|---|---|---|
| Dictionary object inconsistent | SPDD 미완료, DDIC 활성화 실패 | SPDD, SE14 | SPDD 완료 후 SE14 Activate |
| Modification adjustment incomplete | SPAU 객체 일부 미조정 | SPAU 상태 | 모든 대상 Green 처리 |
| ATC Simplification Error | S/4에서 obsolete API 사용 | ATC 결과 | 대체 API 적용, BAdI 재구현 |
| Payment Medium Dump | RFFO* 부분 조정 |
ST22, 지급런 테스트 | 관련 프로그램 전체 재검토 |
| TRM Deal 오류 | Exit/BAdI 미반영 | SPAU_ENH, 기능 테스트 | Enhancement 재활성화/재설계 |
특히 Dictionary object inconsistent는 구조 문제라서 우회가 거의 안 됩니다. 먼저 SPDD에서 Fully Adjust하거나 불필요한 수정이면 Reset하고, 그 뒤 SE14로 활성화해야 합니다. Modification adjustment incomplete는 SPAU에서 애매하게 남겨둔 객체가 원인인 경우가 많고요. ATC Simplification 에러는 “기술적으로는 컴파일되는데 S/4 철학에는 안 맞는 코드”를 잡아내는 역할을 합니다. 그래서 단순 syntax 수정으로 끝내면 다시 문제를 만납니다.
부가 설명: 오류 해결의 핵심은 증상보다 객체의 성격을 먼저 구분하는 것입니다. 구조 오류인지, 로직 오류인지, S/4 비호환인지 분류가 되면 대응 속도가 빨라집니다.
SPDD SPAU 차이 정리: 결국 전략입니다
핵심만 3줄로 정리해보겠습니다.
– SPDD SPAU 차이는 데이터 구조 복구와 로직 복구의 차이입니다.
– Modification를 많이 쌓아둘수록 S/4HANA Conversion 리스크와 테스트 비용이 커집니다.
– Simplification Item SPAU는 단순 병합이 아니라 유지·폐기·재구현을 결정하는 단계입니다.
여러분 시스템에서 아직 SPAU/SPDD object count를 확인하지 않으셨다면 지금 바로 그 작업부터 시작해보세요. 그리고 ATC S/4 variant를 먼저 돌려보시길 권합니다. 다음에 읽으면 좋은 글로는 ATC Custom Code Adaptation 실전 가이드, FI Payment Program 구조 분석을 추천드립니다. 비슷한 이슈를 겪으셨다면 댓글로 공유해주세요. 현장에서 자주 쓰는 판단 기준도 함께 나눠보겠습니다.
참고 출처
- SAP Help Portal – S/4HANA Conversion & SUM
https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE - SAP Simplification Item Catalog
https://help.sap.com/docs/SAP_S4HANA_SIMPLIFICATION_ITEM_LIST - SAP Readiness Check
https://help.sap.com/docs/SAP_READINESS_CHECK - SAP Best Practices
https://rapid.sap.com