SAP Clean Core(클린 코어)란: 의미, 레벨 A~D, 거버넌스

SAP 클린 코어란 S/4HANA 시스템을 비즈니스가 허용하는 한 SAP 표준에 최대한 가깝게 유지하는 것입니다. 추가하는 모든 것은 SAP가 릴리스하고 안정성을 약속한 인터페이스를 통해 구축하므로, 업그레이드로 인해 깨지지 않습니다.

짧게 답하면, 클린 코어는 SAP를 어떻게 확장하고 통제할지에 관한 규율입니다. 커스텀 로직은 ABAP Cloud로 온스택에 두거나 SAP BTP로 사이드바이사이드에 두며, SAP는 모든 확장을 레벨 A(가장 깨끗함)부터 레벨 D(제거해야 할 수정)까지 등급으로 매깁니다. 그 대가는 더 빠른 업그레이드입니다. 저는 이 방식으로 업그레이드 기간을 40% 단축한 기업들을 보았습니다.

시스템이 SAP 표준 오브젝트에 대한 수정으로 가득하다면, 릴리스마다 회귀 테스트 프로젝트가 됩니다. 커스텀 로직이 릴리스된 인터페이스 뒤에 있다면, 업그레이드는 일상적인 유지보수가 됩니다.

저는 클린 코어 원칙을 적용해 업그레이드 기간을 40% 단축한 기업들을 보았습니다. 이들은 커스터마이징을 최소한으로 유지하고, 남긴 것은 철저히 통제하는 방식으로 이를 달성했습니다.

2024년 한 유럽 소비재 기업은 레거시 가격 결정 로직을 SAP BTP에서 코어 바깥에 구축한 모듈형 Fiori 앱으로 대체했습니다. 그 결과 해당 로직의 회귀 테스트가 완전히 사라졌습니다.

클린 코어 ERP에서도 커스터마이징은 가능합니다. 다만 SAP가 릴리스하고 안정적으로 유지하기로 약속한 인터페이스를 사용해야 합니다. SAP는 이를 위해 두 가지 방법을 제공합니다.

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

SAP는 자사의 접근 방식을 BTP 우선이라고 설명하며, 유스케이스별로 선택하도록 합니다. 제 경험으로는 코드가 어디서 실행되느냐보다 그 요구사항에 애초에 코드가 필요한지가 더 중요합니다.

더러운 코어는 ECC를 운영해 본 사람이라면 누구에게나 익숙한 모습입니다. 수정된 표준 프로그램, 직접 기록되는 Z 테이블, SAP 내부를 읽는 인터페이스, 아무도 문서화하지 않은 암시적 enhancement. 만들 당시에는 어느 것도 잘못이 아니었습니다. 다만 1~2년마다 업그레이드하는 시스템을 위해 만들어지지 않았을 뿐입니다.

이 주제는 제 YouTube 채널의 영상(영어)에서도 다룹니다.

SAP는 클린 코어를 5가지 지침 원칙으로 정리합니다. SAP가 각 원칙을 어떻게 규정하는지, 그리고 제가 가장 먼저 무엇을 보는지는 다음과 같습니다.

원칙	SAP가 의미하는 것	제가 가장 먼저 확인하는 것
프로세스	SAP 표준 프로세스에 최대한 가깝게 유지	“원래 이렇게 해 왔다”는 이유만으로 존재하는 프로세스 변형은 무엇인가
확장성	릴리스된 API를 통해 코어와 분리된 확장, 그리고 어떤 옵션을 쓸지에 대한 거버넌스	커스텀 코드가 얼마나 있고, 얼마나 사용되며, 어느 레벨에 있는가
데이터	확립된 거버넌스 모델 아래의 깨끗하고 규정을 준수하는 데이터	중복되거나 불완전한 마스터 데이터, 아무도 설명하지 못하는 커스텀 필드
통합	지원되는 기술로 구축한 표준화되고 안전한 연결	테이블을 직접 읽는 포인트 투 포인트 인터페이스
운영	나머지 네 가지를 유지하는 거버넌스, 사람, 프로세스, 도구	누가 확장을 승인하며, 무엇이 다음 수정을 막는가

대부분의 팀은 확장성에서 시작해 확장성에서 끝납니다. 측정하기가 가장 쉽기 때문입니다. 제 경험으로는 프로세스와 데이터가 더 큰 지연을 일으킵니다. 커스텀 코드는 대개 증상이고, 원인은 그 뒤에 있는 프로세스입니다.

2025년 8월 SAP는 기존의 3계층 확장성 모델을 클린 코어 레벨 개념으로 대체했습니다. 각 확장은 어떻게 구축되었는지, 코어와 얼마나 분리되어 있는지, 업그레이드를 얼마나 안전하게 견디는지에 따라 평가됩니다. 계층(tier)을 이야기하는 예전 SAP 자료를 읽고 있다면, 그것을 대체한 것이 바로 이 개념입니다.

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

사용하는 것레벨 A공개 릴리스된 안정적인 인터페이스만레벨 BSAP의 기존 API도 사용레벨 CSAP 내부 오브젝트레벨 D수정, SAP 테이블 쓰기, 암시적 enhancement

업그레이드 리스크레벨 A가장 낮음, 안정성 계약으로 보장레벨 B대체로 업그레이드에 안정적레벨 C업그레이드마다 점검 필요레벨 D가장 높음

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

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

레벨 A는 안정성 계약이 있는 공개 릴리스 인터페이스만 사용하며, SAP Build, ABAP Cloud 또는 BTP로 구축합니다. 레벨 B는 SAP의 기존 API까지 사용합니다. 레벨 C는 SAP 내부 오브젝트를 건드리며, SAP는 업그레이드 계획을 돕기 위해 이들에 대한 변경 로그를 제공할 계획입니다.

레벨 D는 수정, SAP 테이블 쓰기, 암시적 enhancement, 그리고 SAP가 권장하지 않는 기타 기법입니다. 이는 예전의 “클린한가, 아닌가” 논쟁보다 유용합니다. 오브젝트별로 목표를 정할 수 있기 때문입니다. 업그레이드 전에 레벨 D 오브젝트를 B나 C로 옮기는 것만으로도 리스크는 실제로 줄어듭니다.

ABAP Cloud는 SAP의 클라우드 대응 ABAP 개발 모델입니다. 개발자는 “ABAP for Cloud Development” 언어 버전을 사용하며, 릴리스된 오브젝트, 공개 API, 확장 포인트 위에서만 개발할 수 있습니다. SAP BTP ABAP 환경에서 시작되었고, 지금은 모든 S/4HANA 에디션에서 사용할 수 있습니다(SAP ABAP Cloud FAQ).

S/4HANA Cloud에는 세 가지 확장 경로가 있습니다. 키 유저 확장성은 SAP 코드를 건드리지 않고 필드, 로직, UI의 간단한 변경을 처리합니다. ABAP Cloud 기반 개발자 확장성은 긴밀하게 결합된 로직을 다루고, SAP BTP의 사이드바이사이드 확장은 분리된 상태로 남아야 하는 모든 것을 다룹니다.

선택의 폭은 에디션이 결정합니다.

	S/4HANA Cloud Public Edition	S/4HANA Cloud Private Edition 및 온프레미스
ABAP 개발	ABAP Cloud만 가능, 릴리스 2208부터 신규 고객에게 필수	2022년부터 ABAP Cloud 권장, 기존 ABAP도 계속 허용
SAP 코드 변경	불가능	가능하지만 레벨 D에 해당
키 유저 확장 및 BTP 사이드바이사이드 확장	사용 가능	사용 가능
클린 코어를 강제하는 주체	시스템	귀사의 거버넌스

Private Edition 고객에게 드리는 저의 원칙은, 새로 만드는 모든 것을 Public Edition인 것처럼 다루라는 것입니다. 기존 ABAP는 허용되지만, 오늘 추가하는 기존 방식의 오브젝트 하나하나가 다음 업그레이드 때 누군가 정당성을 설명해야 하는 결정이 됩니다.

클린 코어 결정은 비즈니스와 IT로 구성된 디자인 어소리티가 책임져야 합니다. IT만으로는 기술적으로 가능한 것이면 무엇이든 승인합니다. 비즈니스만으로는 예전 프로세스를 되돌려 달라고 요구합니다.

저라면 다음과 같이 구성하겠습니다.

1. 구성원을 지정합니다. 주요 영역별 비즈니스 프로세스 오너에 솔루션 아키텍트와 리드 개발자를 더합니다. 요구사항이 실제로 필요한지는 비즈니스 오너가 판단하고, 어떻게 구축할지는 IT가 판단합니다.
2. 구축을 시작하기 전에 우선순위에 합의합니다. 먼저 표준 프로세스, 다음은 키 유저 확장성, 그다음은 ABAP Cloud 또는 BTP 기반의 레벨 A입니다. 레벨 B나 C에는 서면 사유가, 레벨 D에는 철수 계획이 필요합니다.
3. 모든 확장 요청에 오너와 비즈니스 사유를 붙이게 합니다. 오너가 없으면 구축하지 않습니다. 결정과 수용한 레벨은 하나의 대장에 기록합니다.
4. 이관(transport) 앞에 기술적 관문을 둡니다. ABAP 테스트 콕핏의 클린 코어 점검을 정기적으로 실행하고, 새로운 레벨 D 코드가 운영 환경에 도달하기 전에 막습니다.
5. 업그레이드 전마다 대장을 검토합니다. 더 이상 아무도 쓰지 않는 것은 폐기하고, 이제 더 높은 레벨로 옮길 수 있는 것은 옮깁니다.

그 자리에서 던지는 질문은 예전에는 “왜 이것을 BTP에 둘 수 없는가?”였습니다. 지금이라면 저는 “왜 이것을 레벨 A로 만들 수 없는가?”라고 묻겠습니다. 만들 수 없다면, 다음 질문은 어떤 레벨을 왜 수용하느냐입니다.

제가 가장 많이 보는 클린 코어 실수는 SAP를 Oracle처럼 작동하게 만들려는 것입니다. 다른 시스템의 로직을 커스텀 코드로 다시 만들지 말고 SAP의 표준 프로세스를 채택하십시오. 아직 둘 사이에서 고민 중이라면 SAP vs Oracle에서 비교해 두었습니다.

클린 코어는 기술 문제이기 전에 변화 관리 문제입니다. 모든 커스텀 오브젝트는 누군가 요청했기 때문에 존재합니다. 그것을 없애려면 그 사람에게 표준 프로세스로 충분하다는 것을 설득해야 합니다.

그 대화는 새 프로세스에 관한 슬라이드가 아니라 실제로 작동하는 모습을 비즈니스가 볼 때 더 잘 풀립니다. 프로세스가 고유하다는 주장을 검증할 때도 더 잘 풀립니다. 실제로는 고유하지 않은 경우가 많기 때문입니다(아래 4단계와 5단계 참고).

도구만큼 역량도 중요합니다. ABAP Cloud나 BTP를 다뤄 보지 않은 ABAP 팀은 배우는 동안 프로그램을 늦추게 됩니다. 제가 함께 일한 한 제조 기업은 S/4HANA 프로젝트가 시작되기 전에 3개월간 사내 BTP 프로그램을 운영했고, 구축 단계에서 예상치 못한 문제가 줄어드는 것으로 그 효과를 거두었습니다.

클린 코어 준수란 5가지 원칙 전반에서 시스템의 얼마만큼이 SAP의 기준을 충족하는지를 말합니다. 숫자 없이는 관리할 수 없으며, SAP는 그 숫자를 얻을 수 있는 세 곳을 제공합니다.

1. ABAP 테스트 콕핏. 코드 수준 점검을 위한 SAP의 도구입니다. 어떤 커스텀 오브젝트가 릴리스되지 않은 오브젝트, 수정, 테이블 직접 액세스를 사용하는지 보여 줍니다.
2. SAP Readiness Check. 유지보수 계약에 포함되어 있으며, 결정하기 전에 S/4HANA 전환이 무엇에 영향을 주는지 보여 줍니다.
3. RISE with SAP Methodology 대시보드, 일명 클린 코어 대시보드. SAP Cloud ALM에서 실행됩니다. 시스템 뷰는 S/4HANA 버전을 확인하고, 데이터 수집 도구가 활성화되어 있는지 확인하며, 업그레이드에 앞서 확장을 검토합니다. 운영 뷰는 운영 KPI를 추적합니다.

제가 매달 디자인 어소리티 앞에 내놓을 숫자는 단순합니다. 각 레벨에 커스텀 오브젝트가 몇 개 있고, 레벨 D는 줄어들고 있는가? 미해결 예외는 몇 건이며, 각각 오너가 있는가?

다음 달에 귀사의 시스템을 평가해 달라고 요청받는다면, 저는 다음 순서를 따르겠습니다.

1. 무엇이 사용되는지 파악합니다. SAP Readiness Check를 실행하고 커스텀 코드의 사용 데이터를 수집합니다. 한 프로그램에서는 smartShift를 활용한 분석으로 18,000개의 커스텀 오브젝트가 3,200개로 줄었습니다. 나머지 대부분은 그저 사용되지 않고 있었기 때문입니다.
2. 남은 것을 레벨 A~D로 분류합니다. 코드에는 ABAP 테스트 콕핏을 사용합니다. RISE를 사용 중이라면 그다음부터는 클린 코어 대시보드가 추적합니다.
3. 오브젝트별로 결정합니다. 폐기하거나, 릴리스된 인터페이스로 옮기거나, BTP에서 다시 구축하거나, 사유를 문서화하고 유지합니다. 매일 실행되는 코드부터 시작하십시오. 한 지역 팀이 1년에 두 번 쓰는 보고서는 기다려도 됩니다.
4. 비즈니스를 같은 자리에 앉힙니다. 제가 함께 일한 한 재무 책임자는 45분간의 워크스루를 거친 뒤에야 새 Fiori 앱을 이해했습니다. 그 세션 덕분에 UAT에서 2주간 오갈 뻔한 논의를 줄였습니다.
5. “우리 프로세스는 다르다”에 이의를 제기합니다. 2023년 한 유럽 산업 기업의 영업팀 워크숍에서, “고유한” 프로세스의 80%는 불필요한 레거시 관리 업무로 드러났습니다. 우회 방식이 사라지자 표준 SAP가 고객 경험을 개선했습니다.
6. 데이터 작업을 일찍 시작합니다. 2024년에 제가 함께 일한 GCC 지역의 한 리테일 고객은 정리해야 할 커스텀 필드가 15,000개가 넘었습니다. 제 경험으로는 데이터 마이그레이션이 구축 공수의 30~40%를 차지하며, 그것이 예산의 어디에 반영되는지는 SAP 구축 비용 가이드에서 보여 드립니다.
7. Go-Live 전에 거버넌스를 정합니다. 앞서 설명한 디자인 어소리티를 세우고, 이를 새로운 확장의 유일한 경로로 만듭니다.

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

RISE with SAP에서 클린 코어는 필수인가요?

일괄적인 규칙은 아닙니다. Public Edition에서는 시스템이 강제하지만, Private Edition과 온프레미스에서는 여전히 코어를 수정할 수 있습니다.

그 경우 클린 코어는 거버넌스의 선택이며, SAP는 RISE methodology 대시보드로 이를 추적합니다. SI가 계약상 의무라고 말한다면, 해당 조항을 보여 달라고 요청하십시오.

ECC는 얼마나 더 쓸 수 있나요?

enhancement package 6~8의 SAP ERP 6.0은 메인스트림 유지보수가 2027년 12월 31일에 종료됩니다. 선택형 연장 유지보수는 추가 비용으로 2030년 12월 31일까지 이어집니다.

그 이후에는 SAP ERP, private edition, transition option이 2031년부터 2033년까지를 다룹니다. 이는 2030년 말 이전에 SAP HANA 기반 SAP ERP, private edition으로 이미 옮긴 대규모 시스템에만 적용됩니다.

2033년은 계획 기준일이 아니라 예외 경로로 보십시오. 경로 선택은 제 ECC에서 S/4HANA로의 마이그레이션 가이드에서 다룹니다.

클린 코어가 AI에 중요한가요?

그렇습니다. SAP 표준을 유지하면 AI와 Joule이 더 잘 작동하며, 크게 수정된 프로세스에서는 도입이 가장 어렵습니다.

SAP는 Joule을 포함한 AI 기능을 자사의 표준 프로세스와 데이터 모델 위에 구축합니다. Joule for developers는 릴리스된 API를 기반으로 ABAP Cloud 코드를 생성합니다. 클라우드, AI, 클린 코어가 어떻게 맞물리는지는 ERP 현대화 글에서 다룹니다.

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

S/4HANA나 RISE 계약에 서명하기 전에, 현재의 커스텀 코드를 레벨 A~D로 분류해 달라고 SI에 요청하십시오. 그것을 내놓지 못한다면, 그 견적에 대해 알 수 있는 것이 있습니다. 상담을 예약하시면 귀사의 상황을 함께 살펴보겠습니다.

SAP에서 클린 코어란 무엇인가요?

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

SAP 클린 코어의 5가지 원칙은 무엇인가요?

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

SAP 클린 코어 레벨 A, B, C, D란 무엇인가요?

2025년 8월부터 SAP는 확장을 4개 레벨로 분류합니다. 레벨 A는 공개 릴리스된 안정적인 인터페이스만 사용하고, 레벨 B는 기존 SAP API도 사용하며, 레벨 C는 SAP 내부 오브젝트에 접근합니다. 레벨 D는 수정, SAP 테이블 쓰기, 암시적 enhancement를 포함하며 업그레이드 리스크가 가장 높습니다.

RISE with SAP에서 클린 코어는 필수인가요?

일괄적인 규칙은 아닙니다. S/4HANA Cloud Public Edition은 ABAP Cloud와 릴리스된 인터페이스만 허용하므로 기술적으로 클린 코어를 강제합니다. Private Edition에서는 여전히 코어를 수정할 수 있으므로, 클린 코어는 SAP가 RISE with SAP Methodology 대시보드로 추적하는 거버넌스의 결정입니다.

ABAP Cloud란 무엇인가요?

ABAP Cloud는 SAP의 클라우드 대응 ABAP 개발 모델입니다. 릴리스된 오브젝트, 공개 API, 확장 포인트만 허용하므로 커스텀 코드가 업그레이드에도 안정적으로 유지됩니다. S/4HANA Cloud Public Edition에서는 릴리스 2208부터 신규 고객에게 필수이며, Private Edition과 온프레미스에서는 2022년부터 권장됩니다.

클린 코어는 어떻게 측정하나요?

코드 수준 점검에는 ABAP 테스트 콕핏을 사용하고, 커스텀 오브젝트를 레벨 A~D로 분류합니다. RISE 고객은 SAP Cloud ALM의 RISE with SAP Methodology 대시보드, 일명 클린 코어 대시보드에서 도입 현황을 추적할 수 있습니다. 저는 레벨별 오브젝트 수, 레벨 D의 추이, 오너가 지정된 미해결 예외의 수를 추적합니다.

SAP 클린 코어 거버넌스는 누가 책임져야 하나요?

클린 코어에 관한 모든 결정은 비즈니스와 IT로 구성된 디자인 어소리티가 책임져야 합니다. 요구사항이 실제로 필요한지는 비즈니스 프로세스 오너가 판단하고, 어떻게 어느 레벨로 구축할지는 IT가 판단합니다. 모든 예외는 오너와 함께 기록되고 업그레이드 전마다 검토됩니다.

SAP ECC 지원은 언제 종료되나요?

enhancement package 6~8의 SAP ERP 6.0은 메인스트림 유지보수가 2027년 12월 31일에 종료되며, 선택형 연장 유지보수는 추가 비용으로 2030년 12월 31일까지 받을 수 있습니다. SAP ERP, private edition, transition option은 2033년까지 이어지지만, 2030년 말 이전에 SAP HANA 기반 SAP ERP, private edition으로 옮긴 요건을 갖춘 대규모 시스템에만 해당합니다.