안녕하세요, 아는형입니다.
S/4HANA Conversion 프로젝트를 수행하다보면 반드시 한 번은 부딪히는 순간이 있습니다. BC가 SUM(Software Update Manager)을 수행하면서 처리해달라고 요청하는 화면이 있지요. 바로 SPDD. 처음 보시는 분들은 당황하실 수밖에 없습니다. “이거 어떻게 처리를 해야 하는거지?” 싶은 그 순간, 저도 똑같이 겪었습니다. 오늘은 이 SPDD가 정확히 무엇이고, 실제로 어떻게 처리해야 하는지 실무 기준으로 풀어보겠습니다.
SPDD란 무엇인가
SPDD는 한 줄로 정의하면 이렇습니다. SAP 표준 Dictionary Object에 고객이 직접 수정한 내역을, 새 버전(S/4HANA)에서도 유지할지 아니면 SAP 표준으로 되돌릴지 결정하는 단계입니다.
조금 풀어서 설명하면 이렇습니다. ECC를 쓰던 시절, 프로젝트를 하다 보면 SAP 표준 테이블이나 구조, 데이터요소 같은 것에 손을 대는 경우가 생깁니다. 그런데 S/4HANA로 넘어가는 시점에 SAP도 같은 Object를 자기들 나름대로 바꿔놨을 수 있습니다. 이때 “고객이 예전에 바꾼 부분”과 “SAP가 새로 바꾼 부분”이 서로 충돌하게 되는데, 이걸 시스템이 알아서 판단하지 못하니까 사람이 직접 보고 결정해줘야 하는 겁니다. 그게 SPDD입니다.
SPDD 대상이 되는 Object들
실무적으로 가장 자주 마주치는 건 SAP 표준 테이블/구조에 대한 Append, Include, 필드 속성 변경입니다. 그 외에 SPDD 대상이 되는 Object를 정리하면 아래와 같습니다.
| 구분 | 예시 | 설명 |
|---|---|---|
| Table | MARA, BSEG, BKPF 등 |
SAP 표준 테이블에 직접 필드 추가/속성 변경 |
| Structure | BAPI 구조, CI 구조, SAP 표준 Include 구조 | 구조 필드 변경 |
| Data Element | 데이터요소 길이, Domain 연결 등 | 필드 의미/길이/속성 변경 |
| Domain | 값 범위, 길이, 타입 등 | 기술적 속성 |
| Search Help | 표준 Search Help 수정 | F4 도움말 |
| Table Type/View 등 | Dictionary 관련 Object | DDIC |
SPDD는 Conversion 과정 중 어느 시점에 나오는가
S/4HANA Conversion은 보통 SUM으로 진행합니다. 전체 흐름을 단순화하면 다음 순서로 볼 수 있습니다.
사전 점검 → SUM 실행 → SPDD 단계 → Technical Conversion 계속 진행 → SPAU / SPAU_ENH → Post Conversion
이걸 각 단계별로 조금 더 뜯어보면 이렇습니다.
1) 사전 점검
- Maintenance Planner
- Readiness Check
- Simplification Item Check
- Custom Code Check
2) SUM 실행
- 준비 단계
- Shadow Instance 생성
- Repository/Dictionary Import
- XPRA, DDIC Activation 등
3) SPDD 단계
Dictionary Object를 조정하는 단계입니다. 여기서 반드시 처리를 완료해야 SUM이 다음 단계로 넘어갑니다. SUM이 멈춰서 기다리고 있는 게 바로 이 지점이라고 보시면 됩니다.
4) Technical Conversion 계속 진행
- System Switch
- Migration 작업
- S/4HANA 데이터 구조 전환
5) SPAU / SPAU_ENH
Program, Function, Class, Screen, Enhancement를 조정하는 단계입니다.
6) Post Conversion
- Finance Migration
- Custom Code 수정
- 기능 테스트
혹시 SUM이 멈춰서 진행이 안 될 때 당황하신 적 있으신가요? 십중팔구 SPDD나 SPAU에서 사람 손을 기다리고 있는 경우입니다. 이 두 개를 헷갈리면 처리 순서가 꼬이기 쉬운데, 다음 항목에서 차이를 정리해보겠습니다.
SPDD와 SPAU, 뭐가 다른가
처음 Conversion을 진행할 때 가장 헷갈리는 부분이 바로 이 둘의 차이입니다. 이름도 비슷하고 등장하는 타이밍도 가까워서 더 그렇습니다.
| 구분 | SPDD | SPAU |
|---|---|---|
| 대상 | ABAP Dictionary Object | Repository Object |
| 예시 | Table, Structure, Domain, Data Element | Program, Function Module, Class, Screen, Message, Include |
| 처리 시점 | SUM 중간, 비교적 앞 단계 | SUM 후반/Conversion 후 |
| 중요도 | 매우 높음 | 높음 |
| 미처리 시 영향 | Dictionary 변경 손실, 활성화 오류, 데이터 손실 가능 | 프로그램 로직 누락, 화면/기능 오류 |
| 대표 판단 | 필드/구조를 유지할지 SAP 표준으로 Reset할지 | 소스코드 수정분을 유지할지 SAP 표준으로 되돌릴지 |
결국 한 문장으로 정리하면, SPDD는 “데이터를 담는 그릇(Dictionary)”을 어떻게 할지 정하는 것이고, SPAU는 “그 그릇을 다루는 로직(Repository)”을 어떻게 할지 정하는 것입니다. SPAU_ENH나 Enhancement 관련 조정은 이 부분과 이어지는 주제라서, 이건 나중에 SPAU/SPAU_ENH 처리 실무에서 따로 다뤄보겠습니다.
실제 사례로 보는 SPDD 처리
이론은 이 정도면 됐고, 실제 사례를 하나 보겠습니다.
ECC 기존 상태는 이랬습니다. SAP 표준 Structure인 ABC_STRUCT에 고객이 ZFIELD1 필드를 추가해서 쓰고 있었습니다. 그런데 S/4HANA로 올라가면서 SAP가 같은 Structure를 건드려 놨습니다. 필드 구성이 바뀌고, 길이도 바뀌고, Include 구성도 달라졌습니다.
이 상황에서 시스템은 사람에게 이렇게 물어보는 셈입니다.
기존 고객이 추가한 ZFIELD1을 유지할까요, 아니면 SAP가 새로 제공한 표준 구조로 되돌릴까요?
이 판단을 내리는 작업이 바로 SPDD입니다.
처리 화면과 옵션
T-code SPDD로 들어가면 처리 대상 목록이 뜨고, 각 대상별로 선택할 수 있는 Available Action이 나옵니다.
처리 대상 확인
- Compare Version — 오류내역, 변경 내역 확인
- Use new SAP Version (Reset) — SAP가 새로 제공한 내용을 그대로 적용
- Modify again (Adjust) — 기존 고객 수정분을 유지(원복)
- Change Processor — 실무에서는 거의 사용하지 않음
실제로 저희 프로젝트에서 만난 케이스는 Domain이 BANKN에서 CHAR18로 Conversion되면서 변경이 발생한 건이었습니다. 이런 은행계좌 관련 필드는 대부분 암호화 처리가 걸려 있는 경우가 많은데, 저희 프로젝트에서 건드린 대상들도 전부 암호화 관련 건들이었습니다. 그래서 SAP 신규 표준으로 그냥 넘기지 않고, 기존 방식을 유지하는 쪽으로 결정했습니다.
처리 순서 정리
정리하면 실제 처리 순서는 다음과 같습니다.
SPDD진입 후 대상 목록 확인
- 대상 선택 후 Compare Version으로 변경 내역 확인
- 기존 방식을 유지해야 하는 경우, Available Actions에서 Modify Again (Adjust) 선택
- 선택 후 상태값이 변경된 것을 확인하고, 최종 확정을 위해 [Confirm Adjustment] 클릭
여기서 놓치기 쉬운 부분이 있는데요, Modify Again을 선택한 것만으로는 처리가 끝난 게 아닙니다. 반드시 Confirm Adjustment까지 눌러서 STATUS가 체크 표시로 바뀌어야 정상적으로 처리 완료된 것입니다. 이 확정 버튼을 안 누르고 넘어가면 SUM 진행 단계에서 다시 걸릴 수 있으니 주의하시기 바랍니다.
실제 사례를 보자
- 대상 선택 후 Compare Version으로 변경 내역 확인
- BU_BANKN이 오류로 잡혔었는데 이 예시의 경우 Domain이 BANKN에서 CHAR18로 Conversion 하면서 변경 진행하여 발생한 오류이다.
- 암호화 관련된 부분이 있어 해당 부분은 ECC로직을 그대로 유지하기로 결정
- Available Actions에서 Modify Again(Adjust) 선택
- 상태값이 변경되었고, 최종 확정을 위해 [Confirm Adjustment] 클릭
- 정상적 처리하면 STATUS가 체크로 변경되어야 최종 정상처리된 것임.
SPDD는 사실 한 번 원리를 이해하고 나면 그렇게 어려운 단계는 아닙니다. 다만 처음 마주치면 “이걸 Reset해야 하나 Adjust해야 하나” 하는 판단 자체가 낯설어서 시간을 많이 잡아먹습니다. 특히 저희처럼 은행 관련 필드에 암호화가 걸려있는 경우처럼, 판단 기준이 기술적인 것뿐 아니라 업무적인 맥락까지 봐야 하는 경우도 있으니, 무조건 SAP 표준을 따르기보다는 왜 그 필드를 건드렸었는지부터 다시 짚어보시길 권해드립니다. 다음에는 SPDD 다음 단계에서 만나게 되는 SPAU 처리 실무를 좀 더 자세히 풀어보겠습니다.