Clean Core 전략과 CBO 관리가 왜 지금 중요한가

안녕하세요. 아는 형입니다.

“우리 회사는 업에 따른 특수한 기능이 많이 필요하여 표준 기능만으로는 안 돌아간다.” 오랫동안 SAP를 도입한 기업들 사이에서 이 말은 거의 국룰처럼 통했습니다. 그런데 2026년 지금, 같은 말이 전혀 다른 맥락에서 다시 소환되고 있습니다. 이번엔 자부심이 아니라 걸림돌로요.

“커스터마이징 = 경쟁력”이라는 믿음이 흔들리는 시점

그 결과가 뭐였는지는 이 바닥에 있는 분들은 다 아실 겁니다. 시스템 안에는 수만 줄의 Z-프로그램과 수십 개의 User-Exit, BAdI 구현체가 켜켜이 쌓였습니다. 한때는 이게 남들과 다른 프로세스, 즉 경쟁력이라고 여겨졌죠.

그런데 지금은 같은 구조가 전혀 다른 이유로 도마 위에 올랐습니다. AI가 그 위에서 작동하지 않는다는 것입니다. 왜 커스터마이징이 갑자기 골칫거리가 됐는지, 그리고 그 한복판에 있는 CBO(Custom Business Object, 커스텀 오브젝트)를 왜 지금 관리해야 하는지 한번 정리해봤습니다.

Clean Core란 무엇인가

Clean Core를 한 문장으로 요약하면 이렇습니다. “ERP 코어(핵심 시스템)는 최대한 표준 상태로 유지하고, 회사 고유의 기능은 코어 바깥에서 구현하자.”

과거 방식과 비교하면 이해가 빠릅니다.

구분	기존 방식	Clean Core 방식
커스텀 로직 위치	ECC/S4 코어 내부 (Z-프로그램, User-Exit)	SAP Business Technology Platform(BTP) 등 코어 외부
코어와 확장의 연결	소스코드 레벨로 직접 얽힘	API를 통한 느슨한 연결(Side-by-Side 확장)
업그레이드 시	영향도 분석 → 코드 수정 → 테스트, 수개월 소요	코어가 표준이므로 업그레이드 영향 최소화
판단 기준	이 요구사항을 커스터마이징으로 구현할 수 있는가	이 요구사항이 표준 기능으로 충분히 해결되는가

표만 보면 그냥 개발 방법론 하나 바뀐 것 같지만, 사실 핵심은 판단 기준 자체가 바뀐다는 것입니다. Clean Core를 실행하는 첫 단계로 흔히 언급되는 게 ‘Standard-First’ 접근법인데요. 새 요구사항이 들어올 때마다 “커스텀으로 어떻게 짤까”가 아니라 “표준 기능으로 될까”를 먼저 검토하는 겁니다. 재밌는 건, 과거엔 없었던 표준 기능이 최신 버전엔 이미 들어와 있는 경우가 생각보다 많다는 점입니다.

왜 지금 Clean Core가 트렌드의 중심에 섰나

Clean Core라는 개념 자체는 사실 새롭지 않습니다. 그런데 2026년 들어 이 논의가 갑자기 급부상한 데는 명확한 이유가 있습니다.

① AI가 “지저분한 코어” 위에서 작동하지 않는다

SAP의 AI 에이전트 Joule이나 Datasphere 같은 데이터 플랫폼을 도입하려는 기업이 늘고 있는데, 실제 프로젝트 현장에서는 반복적으로 같은 문제가 발생한다고 합니다. 데이터는 있는데, AI가 그 의미를 해석하지 못하는 겁니다.

생각해보면 당연합니다. 20년간 쌓인 커스텀 코드가 표준 비즈니스 오브젝트를 우회해서 동작하고 있다면, AI 입장에서는 데이터 구조 자체가 예측 불가능한 상태가 됩니다. 표준화되고 투명한 데이터 구조가 전제되어야 AI가 제 역할(수요 예측, 이상 탐지, 자동화된 프로세스 실행 등)을 할 수 있다는 게 업계의 공통된 진단입니다.

AI가 똑똑해서 알아서 파악해줄 거라 기대하시는 분들이 꽤 있는데, 순서가 반대입니다. 데이터 구조가 먼저 정리돼야 AI가 그 위에서 뭔가를 할 수 있습니다.

② 업그레이드 속도가 곧 경쟁력이 되는 시대

코어가 표준에 가까울수록 새 버전 업그레이드에 걸리는 시간과 비용이 줄어듭니다. 최신 기능, 보안 패치, 규제 대응 업데이트를 출시 즉시 받아쓸 수 있다는 뜻이기도 하고요. 반대로 코어가 지저분할수록, 업그레이드 한 번에 수개월씩 걸리는 영향도 분석과 테스트를 반복해야 합니다.

③ RISE with SAP·클라우드 전환과 맞물림

RISE with SAP 방법론 자체가 Clean Core를 전제로 설계되어 있습니다. 표준화와 최신 확장성을 기반으로 혁신을 추진한다는 게 공식 방향성이고, 커스터마이징을 최소화해 운영·보안 리스크를 줄이는 것을 핵심 가치로 내세우고 있습니다.

결국 지금 진행 중인 대부분의 S/4HANA 전환 프로젝트는, 어떻게 보면 “Clean Core를 어느 수준까지 실현할 것인가”의 문제이기도 합니다.

CBO(커스텀 오브젝트) 관리가 Clean Core의 핵심인 이유

Clean Core 논의를 실무로 끌고 내려오면, 결국 가장 먼저 부딪히는 게 “우리 시스템 안에 어떤 CBO가 있고, 그것들을 어떻게 처리할 것인가”입니다.

CBO는 기업이 표준 기능 대신 자체적으로 개발한 프로그램, 테이블, User-Exit, BAdI 구현체 등을 통칭합니다. Clean Core가 왜 CBO 관리와 사실상 같은 문제인지는 다음 이유 때문입니다.

① CBO는 코어와 가장 강하게 얽혀 있는 지점이다

표준 화면 커스터마이징이나 리포트 정도는 상대적으로 영향 범위가 좁습니다. 하지만 특정 테이블을 직접 조회하거나, 표준 BAPI를 우회해 데이터를 직접 쓰는 CBO는 코어의 데이터 모델 자체에 종속되어 있습니다. 코어가 바뀌면(예: S/4HANA 전환, 버전 업그레이드) 가장 먼저, 가장 크게 영향을 받는 게 바로 이 CBO들입니다.

② CBO는 “발견”부터가 어렵다

Clean Core를 실현하려면 먼저 우리 시스템에 CBO가 얼마나, 어디에 있는지 파악해야 하는데요. 수년간 여러 담당자를 거치며 쌓인 커스텀 개발은 문서화가 안 되어 있는 경우가 많습니다. 그래서 실무에서는 CBO 인벤토리 작성 자체가 Clean Core 프로젝트의 첫 관문이 됩니다.

③ 등급을 나눠 관리해야 한다

모든 CBO를 무조건 없앨 수는 없습니다. 그래서 업계에서는 흔히 확장 유형을 등급(예: 표준 API 기반 확장 ~ 코어 직접 수정)으로 나누고, 등급이 낮을수록(코어에 덜 침투적일수록) 우선순위를 낮추고, 등급이 높을수록(코어 데이터에 직접 개입할수록) 우선적으로 표준화하거나 BTP 같은 외부 플랫폼으로 이전하는 방식의 접근을 취합니다.

실제로는 어떤 모습으로 나타나는가 — TR 모듈의 예

여기까지는 다소 원론적인 이야기고, 이제 좀 더 현장 이야기를 해보겠습니다. Treasury 모듈 전환 과정에서 흔히 마주치는 사례입니다.

ECC 환경에서는 반제(청산) 페어 데이터를 조회하기 위해 특정 테이블을 직접 쿼리하는 자체 개발 프로그램을 흔히 볼 수 있습니다. 이런 방식은 ECC 안에서는 잘 동작합니다. 하지만 전형적인 “코어에 강하게 얽힌 CBO”이기도 하죠.

문제는 S/4HANA로 전환하면서 발생/이연 데이터의 정본 소스 자체가 바뀐다는 데 있습니다. 데이터가 새로운 구조로 통합되면서, 과거 테이블을 직접 조회하던 커스텀 프로그램은 더 이상 정상적으로 작동하지 않습니다. 표준 기능(TPM_MIGRATION 등)이 데이터 모델 전환을 처리해주더라도, 그 위에 얹혀 있던 CBO까지 자동으로 따라와 주지는 않는다는 게 핵심입니다.

이 부분은 예전에 다룬 TPM_MIGRATION 리포트 관련 포스팅에서 좀 더 구체적으로 짚었으니, 데이터 모델 전환 자체가 궁금하신 분은 참고하시면 좋을 것 같습니다.

이 사례가 보여주는 건 명확합니다. Clean Core는 먼 미래의 IT 전략이 아니라, 지금 진행 중인 전환 프로젝트에서 CBO를 어떻게 재설계하느냐의 문제로 이미 현실화되어 있다는 점입니다.

그래서 무엇을, 어떻게 해야 하는가

CBO 인벤토리부터 만든다 — 시스템 내 커스텀 프로그램·User-Exit·BAdI·직접 테이블 접근 로직을 목록화
의존 관계를 등급화한다 — 표준 API 기반인지, 코어 테이블에 직접 접근하는지 구분해 우선순위 설정
Standard-First로 재검토한다 — 각 CBO에 대해 “지금 버전의 표준 기능으로 대체 가능한가”를 먼저 확인
불가피한 확장은 코어 밖으로 — 꼭 필요한 커스텀 로직은 BTP 등 Side-by-Side 확장 방식으로 이전 검토
전환 프로젝트 일정에 반영한다 — CBO 재설계는 스코핑 단계부터 비즈니스 케이스에 포함시켜야 하며, 계약 이후에 뒤늦게 발견하면 일정과 비용 모두 흔들린다는 게 업계의 공통된 경고

마무리

Clean Core는 결국 “코어를 얼마나 깨끗하게 유지하느냐”의 문제고, 그 실행의 8할은 CBO를 어떻게 찾아내고, 등급을 매기고, 재설계하느냐에 달려 있습니다. 특히 데이터 모델 자체가 바뀌는 S/4HANA 전환 시점에는, CBO 재설계가 선택이 아니라 프로젝트 성패를 가르는 필수 작업이 됩니다.

참고: 본 글의 일반적인 Clean Core 개념 및 업계 동향은 SAP 공식 자료 및 컨설팅 업계 발행물을 참고했습니다. 자사 시스템에 대한 CBO 영향도는 반드시 개별 시스템 분석을 통해 확인하시기 바랍니다.