SAP 클린 코어 전략: 의미와 적용 방법

클린 코어는 S/4HANA 업그레이드가 6주에 끝날지 6개월이 걸릴지를 좌우합니다. 시스템이 SAP 표준 오브젝트에 대한 수정으로 가득 차 있으면 릴리스마다 회귀 프로젝트가 됩니다. 커스텀 로직이 공개된 인터페이스 뒤에 있으면 업그레이드는 일상적인 유지보수가 됩니다.

저는 S/4HANA 프로젝트를 시작하기 전에 클린 코어 원칙을 적용해 업그레이드 기간을 40% 줄인 기업들을 보았습니다. 한 소비재 기업은 레거시 가격 로직을 코어 밖에서 만든 모듈형 Fiori 앱으로 대체했고, 그 뒤로 업그레이드가 그 로직을 깨뜨리지 않게 되었습니다.

2025년 4월에 이 글을 처음 쓴 뒤 많은 것이 바뀌었습니다. SAP는 이제 클린 코어를 다섯 가지 지침 원칙으로 설명하며, 2025년 8월부터는 모든 확장을 네 가지 레벨 중 하나로 분류합니다. ECC 기한도 더 분명해졌습니다. 이 버전은 그 변화를 반영했습니다.

클린 코어란 S/4HANA 시스템을 비즈니스가 허용하는 한 SAP 표준에 가깝게 유지하고, 추가로 필요한 것은 업그레이드에도 살아남는 방식으로 구축하는 것입니다.

커스터마이징은 여전히 할 수 있습니다. 다만 SAP가 공개했고 안정성을 약속한 인터페이스를 사용해야 합니다. SAP는 이를 위한 두 가지 방식을 제공합니다.

• 온스택, ABAP Cloud 기반. 확장이 S/4HANA 내부에서 실행되지만 공개된 API와 확장 포인트만 사용합니다.
• 사이드 바이 사이드, SAP BTP 기반. 확장이 별도의 애플리케이션으로 실행되며 API나 이벤트를 통해 S/4HANA와 통신합니다.

SAP의 공식 지침은 유스케이스별로 선택하되 BTP를 우선하라는 것입니다. 제 경험으로는 코드가 어디에서 실행되느냐보다, 그 요구사항에 애초에 코드가 필요한지가 더 중요합니다.

지저분한 코어는 ECC를 운영해 본 분이라면 낯익은 모습입니다. 수정된 표준 프로그램, 직접 쓰기가 이루어지는 Z 테이블, SAP 내부를 읽는 인터페이스, 아무도 문서화하지 않은 암묵적 인핸스먼트. 만들 당시에는 어느 것도 잘못이 아니었습니다. 다만 1년이나 2년마다 업그레이드되는 시스템을 염두에 두고 만든 것이 아니었을 뿐입니다.

SAP는 클린 코어를 다섯 가지 지침 원칙으로 정리합니다. 이 글의 이전 버전은 다른 제목들을 나열했습니다. 아래는 SAP가 실제로 사용하는 원칙이며, 각 원칙에서 제가 가장 먼저 보는 것을 함께 적었습니다.

원칙	SAP가 뜻하는 바	제가 먼저 확인하는 것
프로세스	가능한 한 SAP 표준 프로세스에 가깝게 유지	"늘 이렇게 해왔으니까"라는 이유만으로 존재하는 프로세스 변형이 무엇인지
확장성	공개된 API를 통해 코어와 분리된 확장, 어떤 옵션을 쓸지에 대한 거버넌스 포함	커스텀 코드가 얼마나 있고, 그중 얼마나 쓰이며, 어느 레벨에 있는지
데이터	정립된 거버넌스 모델 아래에서 관리되는 깨끗하고 컴플라이언스를 충족하는 데이터	중복되고 불완전한 마스터 데이터, 아무도 설명하지 못하는 커스텀 필드
통합	지원되는 기술을 기반으로 한 표준화되고 안전한 연결	테이블을 직접 읽는 점대점 인터페이스
운영	나머지 네 가지를 유지하는 거버넌스, 사람, 프로세스, 도구	누가 확장을 승인하는지, 다음 수정을 무엇이 막는지

대부분의 팀은 측정하기 가장 쉬운 확장성에서 시작해서 확장성에서 끝납니다. 제 경험상 지연은 프로세스와 데이터에서 더 많이 생깁니다. 커스텀 코드는 대개 증상입니다. 원인은 그 뒤에 있는 프로세스입니다.

2025년 8월 SAP는 기존의 3단계 확장성 모델을 클린 코어 레벨 개념으로 대체했습니다. 각 확장은 어떻게 만들어졌는지, 코어와 얼마나 분리되어 있는지, 얼마나 쉽게 업그레이드할 수 있는지를 기준으로 평가됩니다.

레벨	SAP의 설명	업그레이드에 미치는 의미
A	SAP Build로 확장. 공개되어 안정성이 보장된 인터페이스만 사용하며, ABAP Cloud 기반 온스택 또는 BTP 기반 사이드 바이 사이드	위험이 가장 낮습니다. SAP가 안정성 계약으로 이 인터페이스를 뒷받침합니다
B	SAP의 클래식 API와 기술도 사용	대체로 업그레이드에 안정적이지만 클라우드 개발 모델 밖에 있습니다
C	SAP 내부 오브젝트에 접근	부분적으로만 준수합니다. 업그레이드 때마다 확인이 필요하며, SAP는 내부 오브젝트에 대한 변경 로그를 계획하고 있습니다
D	권장하지 않음: 수정, SAP 테이블 쓰기, 암묵적 인핸스먼트, 명시적으로 비권장된 오브젝트	가장 먼저 걷어내야 할 기술 부채

예전의 "클린이냐 아니냐" 논쟁보다 훨씬 쓸모 있는 틀입니다. 오브젝트별로 목표를 정할 수 있기 때문입니다. 모든 것이 레벨 A에 도달할 필요는 없습니다. 업그레이드 전에 레벨 D 오브젝트를 B나 C로 옮기기만 해도 위험은 실질적으로 줄어듭니다.

레벨 A레벨 B레벨 C레벨 D

사용하는 것레벨 A공개되어 안정성이 보장된 인터페이스만레벨 BSAP의 클래식 API도 함께레벨 CSAP 내부 오브젝트레벨 D수정, SAP 테이블 쓰기, 암묵적 인핸스먼트

업그레이드 위험레벨 A가장 낮음, 안정성 계약으로 보증레벨 B대체로 업그레이드에 안정적레벨 C업그레이드 때마다 확인 필요레벨 D가장 높음

결정할 것레벨 A신규 개발의 기본값레벨 B수용하되 사유를 기록레벨 C사유를 두고 수용하고 업그레이드마다 재확인레벨 D가장 먼저 제거하거나 B 또는 C로 이동

출처: SAP 클린 코어 레벨 개념, SAP News, 2025년 8월

다음 달에 귀사의 시스템을 진단해 달라고 하신다면, 저는 이 순서를 따를 것입니다.

1. 무엇이 쓰이는지 파악합니다. 유지보수 계약에 포함된 SAP Readiness Check를 실행하고 커스텀 코드 사용 데이터를 수집합니다. 한 프로젝트에서는 smartShift로 분석한 결과 커스텀 오브젝트가 18,000개에서 3,200개로 줄었습니다. 나머지 대부분은 단순히 쓰이지 않던 것이었습니다.
2. 남은 것을 레벨 A부터 D까지 분류합니다. ABAP test cockpit은 코드 수준 점검을 위한 SAP의 도구입니다. RISE에서는 RISE with SAP Methodology 대시보드가 클린 코어 도입 현황을 보고합니다.
3. 오브젝트별로 결정합니다. 폐기하거나, 공개된 인터페이스로 옮기거나, BTP에서 다시 만들거나, 문서화된 사유와 함께 유지합니다. 매일 실행되는 코드부터 시작하십시오. 한 지역팀이 1년에 두 번 쓰는 리포트는 기다려도 됩니다.
4. 현업을 같은 자리에 앉힙니다. 제가 함께 일한 한 재무 책임자는 45분간 화면을 따라가 보고 나서야 새 Fiori 앱을 이해했습니다. 그 세션 하나로 UAT에서 오갈 2주치 공방이 사라졌습니다.
5. "우리 프로세스는 다르다"에 이의를 제기합니다. 한 영업팀 워크숍에서 "고유하다"던 프로세스는 80%가 불필요한 레거시 행정 업무였습니다. 우회 작업이 사라지자 표준 SAP가 고객 경험을 오히려 개선했습니다.
6. 데이터 작업을 일찍 시작합니다. 한 리테일 고객은 분류해야 할 커스텀 필드가 15,000개가 넘었습니다. 제 경험상 데이터 마이그레이션은 구축 공수의 30에서 40%를 차지하며, 대부분의 계획이 가장 과소평가하는 부분입니다. 그 이유는 SAP 데이터 마이그레이션이 실패하는 이유에서 다룹니다.
7. Go-Live 전에 거버넌스를 정합니다. 디자인 어소리티(Design Authority)가 모든 신규 확장을 검토해야 합니다. 예전에는 기본 질문이 "왜 이것이 BTP에 있을 수 없는가?"였습니다. 지금 저는 "왜 레벨 A가 될 수 없는가, 안 된다면 어느 레벨을 어떤 이유로 수용하는가?"라고 묻겠습니다.

도구만큼 역량도 중요합니다. ABAP Cloud나 BTP를 다뤄 본 적 없는 ABAP 팀은 배우는 동안 프로젝트를 늦춥니다. 제가 함께 일한 한 제조 기업은 S/4HANA 프로젝트를 시작하기 전에 3개월짜리 사내 BTP 프로그램을 운영했고, 구축 중에 놀랄 일이 줄어 그 효과를 봤습니다.

이 주제로 이야기를 나누면 거의 매번 세 가지 질문이 나옵니다.

RISE with SAP에서 클린 코어는 필수입니까? 일괄 규칙으로는 아닙니다. S/4HANA Cloud Public Edition에서는 공개된 인터페이스로만 확장할 수 있으므로 시스템이 이를 강제합니다. Private Edition과 온프레미스에서는 여전히 코어를 수정할 수 있습니다. 그곳에서 클린 코어는 거버넌스상의 선택이며, SAP는 RISE 방법론 대시보드로 이를 추적합니다. SI가 계약상 의무라고 말한다면 해당 조항을 보여 달라고 하십시오.

ECC는 얼마나 쓸 수 있습니까? 인핸스먼트 패키지 6에서 8까지의 SAP ERP 6.0은 주류 유지보수가 2027년 12월 31일에 종료됩니다. 선택형 연장 유지보수는 추가 비용으로 2030년 12월 31일까지 이어지며, SAP는 고객에게 2027년 3분기까지 주문해 달라고 요청합니다. 이전 인핸스먼트 패키지는 2025년 말에 주류 유지보수가 끝났습니다. 2030년 이후에는 SAP ERP, private edition, 전환 옵션이 2031년부터 2033년까지를 다룹니다. 2030년 말 이전에 SAP HANA 기반 SAP ERP, private edition으로 이미 옮긴 대규모 시스템에만 적용되며, SAP의 max success plan이 있어야 합니다. 2033년은 예외적 경로로 보고 계획 기준일로 삼지 마십시오. 경로 선택은 제 ECC에서 S/4HANA로의 마이그레이션 가이드에서 다룹니다.

클린 코어는 AI에도 중요합니까? SAP는 Joule을 포함한 AI 기능을 표준 프로세스와 데이터 모델 위에 구축합니다. 개발자용 Joule은 공개된 API를 대상으로 ABAP Cloud 코드를 생성합니다. 제 현재 생각은 단순합니다. 프로세스와 데이터가 표준에 가까울수록, 이런 기능이 쓸모 있어지기까지 필요한 조정이 줄어듭니다. 크게 수정된 프로세스는 AI 기능을 도입하기 가장 어려운 곳입니다.

클린 코어를 건너뛰는 팀이 그 일을 피하는 것은 아닙니다. 미룰 뿐이고, 그 일은 막힌 업그레이드, 끝없는 회귀 테스트, 아무도 이해하지 못하는 커스텀 코드로 되돌아옵니다.

S/4HANA 또는 RISE 계약에 서명하기 직전이라면, 범위에 합의하기 전에 SI에게 현재 커스텀 코드의 레벨 A부터 D 분류를 요청하십시오. 만들어 내지 못한다면, 그 자체가 견적에 대해 말해 주는 바가 있습니다. ECC에서 S/4HANA로의 마이그레이션 진단으로 마이그레이션 옵션을 점검해 보시거나, 통화를 예약해 귀사의 상황을 함께 살펴볼 수 있습니다.

SAP 클린 코어란 무엇입니까?

클린 코어란 S/4HANA를 SAP 표준에 가깝게 유지하고, SAP가 공개하고 안정성을 유지하겠다고 약속한 인터페이스를 통해서만 확장을 구축하는 것입니다. 확장은 ABAP Cloud 기반 온스택 또는 SAP BTP 기반 사이드 바이 사이드로 실행됩니다. 목표는 업그레이드가 커스텀 로직을 깨뜨리지 않도록 하는 것입니다.

SAP 클린 코어의 다섯 가지 차원은 무엇입니까?

SAP는 이를 클린 코어의 5대 지침 원칙이라고 부릅니다. 프로세스, 확장성, 데이터, 통합, 운영입니다. 프로세스는 표준에 가깝게 유지합니다. 확장은 공개된 API를 사용합니다. 데이터는 거버넌스 모델 아래에서 깨끗하게 관리합니다. 통합은 표준화되고 지원되는 기술을 사용합니다. 운영은 나머지 네 가지를 유지하는 거버넌스, 사람, 도구를 아우릅니다.

SAP 클린 코어 레벨 A, B, C, D는 무엇입니까?

2025년 8월부터 SAP는 확장을 네 가지 레벨로 분류합니다. 레벨 A는 공개되어 안정성이 보장된 인터페이스만 사용합니다. 레벨 B는 클래식 SAP API도 사용합니다. 레벨 C는 SAP 내부 오브젝트에 접근하며 업그레이드 때마다 확인이 필요합니다. 레벨 D는 수정, SAP 테이블 쓰기, 암묵적 인핸스먼트 등 권장되지 않는 기법을 포함하며 위험이 가장 높습니다.

RISE with SAP에서 클린 코어는 필수입니까?

일괄 규칙으로는 아닙니다. S/4HANA Cloud Public Edition은 공개된 인터페이스를 통한 확장만 허용하므로 클린 코어를 기술적으로 강제합니다. Private Edition에서는 여전히 코어를 수정할 수 있으므로 클린 코어는 거버넌스상의 결정입니다. SAP는 RISE with SAP Methodology 대시보드로 클린 코어 도입 현황을 보고합니다.

SAP ECC 지원은 언제 종료됩니까?

인핸스먼트 패키지 6에서 8까지의 SAP ERP 6.0은 주류 유지보수가 2027년 12월 31일에 종료되며, 추가 비용으로 선택하는 연장 유지보수는 2030년 12월 31일까지입니다. 이전 인핸스먼트 패키지는 2025년 말에 주류 유지보수가 끝났습니다. SAP ERP, private edition 전환 옵션은 2030년 말 이전에 SAP HANA 기반 SAP ERP, private edition으로 옮긴 적격 대규모 시스템에 한해 2033년까지 연장됩니다.

SAP 시스템의 클린 코어 준비도는 어떻게 진단합니까?

SAP Readiness Check와 커스텀 코드 사용 데이터로 시작하십시오. 여전히 쓰이는 것을 레벨 A부터 D까지 분류하되, 코드 수준 점검에는 ABAP test cockpit을 사용합니다. 그런 다음 오브젝트별로 폐기할지, 공개된 인터페이스로 옮길지, SAP BTP에서 다시 만들지, 문서화된 사유와 함께 유지할지 결정합니다. 프로세스와 데이터도 동시에 검토하십시오. 코드가 존재하는 이유는 대개 그 둘이 설명해 주기 때문입니다.

클린 코어 전략에서 SAP BTP의 역할은 무엇입니까?

SAP BTP는 사이드 바이 사이드 확장이 실행되는 곳입니다. BTP의 애플리케이션은 API와 이벤트를 통해 S/4HANA에 연결되므로 코어는 손대지 않은 채 유지됩니다. SAP는 BTP 우선 접근을 권장하며, 로직이 데이터나 트랜잭션 가까이에 있어야 할 때는 온스택 ABAP Cloud 확장을 사용합니다.