S/4HANA는 수많은 SAP 객체를 단순화하거나 제거했다(simplification). 그래서 ECC를 전환하면 두 가지가 동시에 터진다. 하나는 그 객체들을 참조하던 **내 Z 코드가 깨지는 것**, 또 하나는 내가 SAP 표준을 **고쳤다면(modification) 그 수정을 다시 맞춰야 하는 것**이다. 이 둘은 자주 뭉뚱그려지는데, 사실 **도구도 시점도 다른 별개의 작업**이다. 한국은 인하우스 개발(CBO) 비중이 유독 높아서, 이 커스텀 코드 적응이 전환 공수의 가장 큰 덩어리 중 하나다. 순서대로 풀어보자. ## 먼저, 두 가지를 구분하자 | 구분 | ① 커스텀 코드 호환성 | ② 수정 조정(Modification) | |---|---|---| | 대상 | 내가 만든 `Z*`/`Y*` 코드 | 내가 손댄 **SAP 표준 객체** | | 문제 | 단순화/제거된 SAP 객체를 참조 | 업그레이드가 표준을 덮어씀 | | 도구 | **ATC** + Simplification DB | **SPDD / SPAU / SPAU_ENH** | | 시점 | 전환 전, 개발 시스템에서 미리 | 전환 중·직후 (SUM이 띄움) | 표준을 한 번도 수정 안 했다면 ②(SPDD/SPAU)는 거의 비어 있고 ①(ATC)만 신경 쓰면 된다. 반대로 표준을 많이 고쳐 쓴 오래된 시스템은 ②도 만만치 않다. ## SI-Check — 무엇이 영향받는지부터 가장 먼저, **Simplification Item Check**로 이 시스템에 어떤 단순화 항목(simplification item)이 걸리는지 확인한다. 리포트 `/SDF/RC_START_CHECK`로 돌리며, 각 항목은 "무엇이 바뀌었고 어떻게 대응하라"는 전용 SAP Note로 연결된다. 여기서 나오는 정합성 오류(consistency error)는 **다운타임 전에** 정리해야 한다. SUM(전환 툴)이 전환 막판에 SI-Check를 다시 한 번 강제로 돌리는데, 그때 막혀서 멈추면 가장 비싼 시간에 손이 묶인다. 미리 깨끗하게 통과시켜 두는 게 핵심이다. ## ATC — 내 코드가 어디서 깨지나 커스텀 코드 호환성은 **ATC(ABAP Test Cockpit)**로 점검한다. 순서는 이렇다. 1. **Simplification Database를 임포트**한다(중앙 점검 시스템으로). 이 DB가 "어떤 SAP 객체가 바뀌었고 어떤 Note를 봐야 하는지"를 담고 있다. 2. **S/4HANA 전용 체크 변형**으로 ATC를 돌린다. - `S4HANA_READINESS_REMOTE` — Simplification DB 전체 항목 점검 - `S4HANA_READINESS_2023` 등 — 타겟 릴리스에 해당하는 항목만 3. 보통은 아직 ECC인 **개발 시스템에서 원격(remote) ATC**로 돌려, 전환 전에 깨질 곳을 미리 찾아 고친다. ATC 결과의 각 finding은 연결된 SAP Note에 적응 방법이 나와 있다. 수천 건이 나오는 게 보통이라, 우선순위(에러 vs 경고)와 실제 사용 여부로 추려서 잡는 게 현실적이다. 한국 프로젝트에서 특히 대량으로 걸리는 두 가지가 있다. 하나는 **자재번호(`MATNR`)가 18자리에서 40자리로 확장**된 것 — 자릿수를 가정하고 짠 코드가 줄줄이 깨진다. 또 하나는 `MB1A`·`MB01` 같은 **옛 재고이동 트랜잭션의 폐지** — 이걸 BDC로 호출하던 코드는 `BAPI_GOODSMVT_CREATE` 같은 BAPI로 바꿔야 한다. 한국 CBO는 BDC와 ALV 리포트 비중이 높아 이 두 패턴이 유독 많이 잡힌다. ## SPDD — 딕셔너리 수정 조정 (데이터 손실 주의) 여기서부터는 수정 조정이다. **SPDD**는 ABAP 딕셔너리 객체(도메인·데이터 엘리먼트·테이블·구조·기술설정)에 가한 수정을 새 표준과 맞추는 작업이다. - **시점**: 전환 *중*, 섀도우 인스턴스(shadow instance)에서 SUM이 띄운다. - **왜 최우선인가**: SPDD를 건너뛰면 **데이터 손실**로 이어질 수 있다. 테이블/필드 구조가 안 맞으면 데이터가 잘려나가기 때문. 그래서 SPDD는 미루면 안 되는 1순위다. ## SPAU / SPAU_ENH — 리포지토리·인핸스먼트 조정 **SPAU**는 리포지토리 객체(프로그램·화면·함수모듈·클래스 등)에 가한 수정을, **SPAU_ENH**는 인핸스먼트(enhancement)를 조정한다. - **시점**: 업그레이드가 끝난 *뒤*, 일반 클라이언트에서. - SPDD와 달리 안 해도 **데이터 손실은 없지만**, 안 하면 해당 기능이 표준으로 덮여 동작이 바뀌거나 깨진다. - 조정 결과는 새 워크벤치 요청(`SE01`)에 저장한다. 요즘은 표준을 직접 수정(modification)하기보다 인핸스먼트/BAdI로 푸는 게 정석이라, 실제로는 SPAU보다 `SPAU_ENH` 쪽이 더 자주 등장한다. ## 순서 한눈에 1. **전환 전 (개발 시스템)** — SI-Check로 영향 파악 + ATC(`S4HANA_READINESS_*`)로 커스텀 코드 미리 수정 2. **전환 중 (SUM)** — `SPDD`로 딕셔너리 수정 조정 (데이터 손실 방지, 최우선) 3. **전환 후** — `SPAU` / `SPAU_ENH`로 리포지토리·인핸스먼트 조정 가장 효과 큰 한 수는 따로 있다 — **고치기 전에 버리는 것**이다. ## 고치기 전에 버리기 — SCMON / SUSG ATC가 잡아낼 대상 자체를 줄이면 전체 공수가 직접 깎인다. 그래서 점검 전에 **안 쓰는 커스텀 코드를 걷어내는 게** 첫 수다. 단 "안 쓴다"를 감으로 판단하면 안 되고, 실제 사용 데이터로 봐야 한다. - **`SCMON`(ABAP Call Monitor)**: 운영 시스템에서 어떤 커스텀 객체가 실제로 호출되는지 일정 기간 수집한다. - **`SUSG`**: `SCMON`이 모은 데이터를 집계해 "이 기간에 한 번도 안 불린 객체" 목록을 뽑는다. 보통 1년 이상 — 연말 결산처럼 주기적으로만 도는 코드까지 한 바퀴 돌도록 — 모은 뒤, 한 번도 안 쓰인 Z 프로그램·리포트를 폐기 후보로 올린다. 이 사용 데이터를 ATC 결과와 겹쳐 보면 "쓰지도 않는데 깨지는 코드를 굳이 고치는" 낭비를 막을 수 있다. ## ADT 마이그레이션 앱과 퀵픽스 손으로만 다 고치는 건 아니다. **ADT(Eclipse)의 커스텀 코드 마이그레이션 도구**가 ATC finding을 한곳에 모아 보여주고, 단순한 패턴은 **퀵픽스(quick fix)로 반자동 수정**까지 해준다. 구문 교체 수준은 자동으로 처리되고, 비즈니스 로직이 얽힌 건 사람이 판단하도록 표시된다. 물론 수천 건을 전부 자동으로 풀어주진 않는다. 자동 처리되는 것과 사람이 봐야 하는 것을 분리해, 후자에 시간을 집중하는 게 현실적인 운영이다. ## 적응의 끝은 Clean Core 방향 하나만 더. 깨진 걸 그때그때 땜질하는 데서 끝내지 말고, **다시는 표준을 직접 수정하지 않는** 쪽으로 정리하는 게 좋다. 이른바 **Clean Core**다 — 표준은 건드리지 않고, SAP가 공개한 released API와 정식 확장 포인트(BAdI·인핸스먼트, ABAP Cloud의 확장 모델)로만 커스터마이징을 푼다. 그래야 다음 업그레이드 때 SPDD/SPAU 지옥을 반복하지 않는다. 이번 전환은 코드를 S/4HANA에서 돌아가게 만드는 작업일 뿐 아니라, **앞으로의 유지보수 비용을 정하는** 작업이기도 하다. ## 자주 묻는 질문 **ATC는 어디서 돌리나요?** 보통 아직 ECC인 개발 시스템에서 원격(remote) ATC로 돌립니다. Simplification DB를 임포트한 중앙 점검 시스템에 대상 시스템을 연결해 점검합니다. **SPDD와 SPAU 중 뭐가 더 급한가요?** SPDD입니다. 딕셔너리(테이블/필드) 조정을 건너뛰면 데이터 손실로 이어질 수 있어 최우선입니다. SPAU는 데이터 손실은 없지만 기능이 깨질 수 있습니다. **커스텀이 수천 개인데 다 고쳐야 하나요?** 아니요. 먼저 `SCMON`/`SUSG`로 안 쓰는 코드를 폐기해 대상을 줄이고, 남은 것도 에러/경고 우선순위로 추려서 잡습니다. ABAP 신문법이 헷갈린다면 [ABAP 7.40/7.50 신문법](/education/abap-740-750-new-syntax)을, 전환 전체 그림은 [SAP ECC 지원종료 정리](/education/sap-ecc-eos-2027-2030)와 [BP·CVI 전환](/education/bp-cvi-conversion)을 함께 보면 좋다. ## 출처 - SAP 공식 — *Custom Code Migration Guide for SAP S/4HANA*: [help.sap.com](https://help.sap.com/doc/9dcbc5e47ba54a5cbb509afaa49dd5a1/2025.000/en-US/CustomCodeMigration_EndToEnd.pdf) - SAP 공식 — *Conversion Guide for SAP S/4HANA* (SPDD/SPAU 단계): [help.sap.com](https://help.sap.com/doc/2b87656c4eee4284a5eb8976c0fe88fc/2023/en-US/CONV_OP2023.pdf) - SAP Community — *Custom code adaptation for SAP S/4HANA – FAQ*, *S/4HANA Custom Code Impact Analysis Using ATC* 심화 참고: *SAP S/4HANA Conversion*, *Complete ABAP* (SAP PRESS)