SAP Clean Core 시대, 테스트가 더 중요해지는 이유
Clean Core 전환을 추진하는 기업에서 가장 자주 듣는 질문이 있습니다.
"커스텀 코드를 코어에서 빼면 SAP 표준만 남잖아요. SAP에서 표준은 다 테스트했을 텐데, 우리가 굳이 자동화까지 해서 테스트를 해야 합니까?"
합리적인 질문입니다. 실제로 Clean Core의 핵심 약속 중 하나가 "업그레이드가 쉬워진다, 테스트 부담이 줄어든다"입니다. 커스텀 코드가 코어에서 빠지면 업그레이드 시 충돌이 줄고, 그만큼 검증해야 할 범위도 줄어드는 건 사실입니다.
하지만 이 약속을 "테스트를 안 해도 된다"로 이해한다면, Clean Core 전환 후 첫 번째 정기 업그레이드에서 장애를 경험하게 될 것입니다.
이 글에서는 Clean Core가 테스트 환경을 실제로 어떻게 바꾸는지, 그리고 왜 테스트 자동화가 줄어드는 게 아니라 오히려 더 필요해지는지를 정리합니다.
1. Clean Core, 정확히 뭐가 달라지나
Clean Core에 대한 오해를 풀려면 먼저 뭐가 바뀌는지를 정확히 알아야 합니다
핵심 변화
기존 SAP 환경에서는 커스텀 코드가 코어 안에 직접 들어갔습니다. Z프로그램, Enhancement, 직접 테이블 수정 등이 표준 코드와 뒤섞여 있었습니다. 업그레이드를 할 때마다 이 커스텀 코드가 표준 변경과 충돌하고, 그 충돌을 해결하느라 프로젝트가 길어지고, 테스트 범위가 폭발적으로 늘어났습니다.
Clean Core는 이 구조를 근본적으로 바꿉니다.
코어는 표준 그대로 유지하고, 커스텀은 코어 밖으로 분리합니다. SAP Business Technology Platform(BTP) 위에 Side-by-side 확장을 만들거나, ABAP Cloud 모델로 On-stack 확장을 만듭니다.
핵심 원칙은 하나 — 코어를 건드리지 않는다.
이 원칙을 체계적으로 관리하기 위해 SAP는 확장을 4단계로 분류하는 레벨 체계(A~D)를 도입했습니다.
Level A: Released API만 사용, 완전 업그레이드 안전 — 모든 신규 개발의 타겟
Level B: Classic API(BAPI 등) 사용, 거버넌스 승인 하에 허용
Level C: SAP 내부 객체에 접근, 업그레이드 리스크 있음 — 개선 로드맵에 올려야 함
Level D: 직접 수정, Enhancement, 직접 테이블 접근 — 퇴출 대상
API 전략도 바뀝니다. 기존의 BAPI/RFC 직접 호출 대신, Released OData/SOAP API를 SAP Integration Suite를 통해 사용하는 것이 원칙입니다.
거버넌스도 사후 관리에서 사전 검증으로 바뀝니다. ABAP Test Cockpit(ATC)이 코드 수준에서 Clean Core 준수 여부를 자동 검사하고, 개발자는 새 코드를 작성하기 전에 "이 기능에 Released API가 있는가, 이 확장은 몇 레벨에 해당하는가"를 먼저 확인해야 합니다.
SAP가 Clean Core를 강조하는 이유
SAP가 Clean Core를 이렇게 강하게 밀고 도구까지 만들어서 제공하는 데는 비즈니스 모델 전환이라는 배경이 있습니다.
클라우드 환경에서는 모든 고객이 동일한 코드 베이스를 공유합니다. SAP가 정기적으로 혁신을 배포하려면 고객의 코어가 깨끗해야 합니다. 커스텀 코드가 잔뜩 들어간 코어에는 업그레이드를 밀어넣을 수 없습니다. Clean Core는 RISE with SAP의 전제 조건이고, SAP의 클라우드 전환 전략 전체의 기반입니다.
그래서 SAP는 Cloud ALM에 다음과 같은 Clean Core 전용 도구를 탑재했습니다.
RISE with SAP Methodology Dashboard: 시스템의 Clean Core 준수 현황을 한눈에 보여주고, 현재 S/4HANA 버전이 최신인지, 확장들이 다음 업그레이드에서 문제를 일으킬지 평가합니다
Custom Code Analytics: 커스텀 코드의 사용량, 성능 영향, 표준 준수 여부에 대한 상세 인사이트를 제공합니다
Extensibility Governance: 확장을 추적·관리하면서, 코어에 영향을 줄 수 있는 커스텀 코드를 식별하고 ABAP Cloud 또는 Side-by-side 모델을 따르는지 확인합니다
Release Assessment (RASD): 새 SAP 릴리즈가 고객 랜드스케이프에 미치는 영향을 사전에 파악합니다
여기까지가 Clean Core의 약속이고, 이 약속은 대부분 사실입니다.
문제는 이 약속에서 한 가지를 잘못 추론하는 데서 시작됩니다 — "커스텀이 줄면 테스트도 줄어든다."
2. "SAP에서 표준은 다 테스트 했을텐데?"
가장 흔한 오해이자, 가장 위험한 오해입니다.
SAP가 테스트하는 것
SAP은 릴리즈마다 표준 코어가 정상 작동하는지 검증합니다. 표준 트랜잭션이 동작하는지, 릴리즈 간 호환성이 유지되는지, 기본 설정 환경에서 프로세스가 끊기지 않는지 검증합니다.
이것은 사실이고, Clean Core로 전환하면 이 표준 검증의 혜택을 더 직접적으로 받게 됩니다. 코어에 커스텀이 없으니까요.
SAP가 테스트 하지 않는 것
하지만 SAP이 테스트하지 않는 영역이 있고, 이 영역은 Clean Core 전환 후에도 고객의 몫으로 남습니다.
첫째, 각 고객사의 비즈니스 프로세스 조합입니다.
표준만 사용하더라도 업종별 설정, 조직 구조, 가격 조건, 세금 규칙 조합은 회사마다 다릅니다. SAP는 VA01이 작동하는지는 테스트합니다. 하지만 각 고객사의 특수 할인 조건 + 다중 통화 결제 + 면세 거래 조합에서 VA01 → VL01N → VF01 → FI 전표까지 끊기지 않고 이어지는지는 테스트하지 않습니다. 이건 고객 환경에서만 검증할 수 있습니다.
둘째, BTP 위에 올린 확장이 업그레이드 후에도 작동하는지 입니다.
코어에서 빼서 BTP로 옮긴 커스텀 로직은 고객의 자산입니다. SAP가 테스트할 영역이 아닙니다. Cloud ALM 자체도 Manual & Automated Testing을 Clean Core의 Extensibility 영역 필수 요소로 포함하고 있고, "확장이나 커스터마이징이 코어에 예기치 않은 문제를 일으키지 않는지 철저히 테스트해야 한다"고 명시합니다.
셋째, 시스템 간 연계입니다.
SuccessFactors에서 생성된 인사 레코드가 코스트 센터에 반영되고, 출장 관리까지 영향을 미치는 흐름. Cloud ALM이 이런 크로스 시스템 프로세스의 가시성을 제공하지만, 가시성은 모니터링이지 검증이 아닙니다. 업그레이드 후 이 연계가 여전히 정상 작동하는지는 의도적으로 실행해봐야 알 수 있습니다.
핵심은 이렇습니다. SAP가 테스트하는 건 표준 코어가 정상 작동하는지이지, 각 고객사의 비즈니스 프로세스가 업그레이드 후에도 정상인지가 아닙니다. 표준만 써도 업종별 설정, 연계 구성, 데이터 조합은 회사마다 다르고, 이 차이가 장애의 원인이 됩니다.
3. 테스트가 줄어드는 게 아니라, 테스트 대상이 이동한다
Clean Core 전환 전후의 테스트 지형 변화를 구체적으로 보겠습니다.
줄어드는 테스트
솔직하게 말하면, 줄어드는 테스트 영역이 분명히 있습니다.
코어 안에 있던 Z프로그램과 Enhancement 관련 테스트가 줄어듭니다. 코드 자체가 제거되었거나 BTP로 이동했으니까요. 업그레이드 시 커스텀 코드 충돌 검증도 줄어듭니다. 코어에 커스텀이 없으면 충돌도 없습니다.
이 부분은 Clean Core의 약속이 실현되는 지점이고, 실제로 테스트 공수가 감소합니다.
새로 생기거나 오히려 늘어나는 테스트
문제는 줄어드는 테스트만 보면 전체 그림을 놓친다는 것입니다.
BTP 확장 검증이 새로 생깁니다.
코어에서 분리했다고 연결이 끊어진 건 아닙니다. BTP 확장은 Released API를 통해 여전히 코어와 연결됩니다. 코어가 업그레이드되면서 API 동작이 미세하게 달라지거나, API 버전이 올라가면 확장이 깨질 수 있습니다. 코어 안에 있었을 때는 "하나의 시스템 안에서 같이 테스트"하면 됐지만, BTP로 분리된 후에는 코어 업그레이드와 확장 검증을 별도로, 그러나 연계해서 수행해야 합니다.
정기 업그레이드 회귀 테스트 빈도가 늘어납니다.
Clean Core의 전제가 "최신 릴리즈를 빠르게 적용하는 것"입니다. S/4HANA Cloud Public Edition은 반기마다 메이저 업그레이드가 있고, 그 사이에도 feature update가 적용됩니다. Private Edition도 Feature Pack Stack이 반기 간격으로 제공됩니다. 기존에 업그레이드를 미루거나 건너뛸 수 있었다면, Clean Core 체제에서는 정기적으로 업그레이드를 적용하는 것이 권장됩니다.
한 번의 테스트 범위는 줄어들 수 있습니다. 하지만 테스트 횟수가 늘어납니다. 연간 1회 대규모 회귀 테스트를 하던 팀이, 반기마다 — 또는 그보다 자주 — 회귀 테스트를 돌려야 합니다.
연계 테스트 복잡도가 증가합니다.
Clean Core 아키텍처에서는 코어, BTP, Integration Suite, 써드파티 시스템이 분산된 구조로 연결됩니다. 코어에 모든 로직이 몰려 있던 기존 구조보다 연계 지점이 많아지고, 각 지점의 검증 필요성도 커집니다. E2E 프로세스를 단위 테스트가 아닌 전체 흐름으로 검증해야 하는 이유가 여기에 있습니다.
정리하면 이렇습니다. 집을 리모델링해서 방의 개수를 줄였다고 청소가 사라지지 않습니다. 방은 줄었지만 마당(BTP)이 생기고, 이웃집과 연결된 통로(연계)가 늘었습니다. 청소 대상이 바뀐 것이지, 청소 자체가 사라진 건 아닙니다.
4. Clean Core 시대의 테스트 자동화가 갖춰야 할 조건
테스트 대상이 이동했다면, 테스트 자동화의 요건도 달라져야 합니다.
정기 업그레이드를 현실적 일정 안에 끝내는 속도
Clean Core는 정기 업그레이드를 전제합니다. 반기마다, 또는 Feature Pack Stack이 나올 때마다 수백 건의 회귀 테스트를 현실적인 일정 안에 끝내야 합니다.
이전 글에서 다룬 회귀 테스트의 속도 병목이 여기서도 그대로 적용됩니다. UI 리플레이 방식으로는 한 건당 20~40분, 500건이면 며칠이 걸립니다. 정기 업그레이드 주기가 빨라진 환경에서 이 속도로는 일정을 맞출 수 없습니다.
백엔드 직접 전송 방식은 UI를 거치지 않고 SAP 백엔드에 직접 데이터를 전송하므로, 동일한 수백 건을 수시간 내에 처리할 수 있습니다. 정기 업그레이드가 반복되는 Clean Core 환경에서는 이 속도 차이가 "할 수 있는가, 없는가"를 결정합니다.
E2E 프로세스 검증
BTP 확장까지 포함한 전체 비즈니스 프로세스 흐름을 하나의 시나리오로 검증할 수 있어야 합니다. 모듈 단위 테스트만으로는 코어-BTP-Integration Suite 사이의 연계 장애를 잡을 수 없습니다.
주문 생성(코어) → 커스텀 승인 로직(BTP) → 출하(코어) → 외부 물류 연계(Integration Suite) → 청구(코어) — 이 전체 흐름이 하나의 테스트 시나리오로 실행되어야 합니다. 개별 단계가 각각 정상이어도, 흐름 전체가 끊기지 않는지는 E2E로 돌려봐야 압니다.
실데이터 기반 테스트
표준 프로세스라도 실제 운영 데이터 조합은 회사마다 다릅니다. 샘플 데이터로 테스트하면 SAP이 이미 테스트한 정상 케이스만 반복 확인하는 셈입니다.
진짜 검증은 운영 데이터의 예외 조합에서 나옵니다. 특수 할인 + 다중 통화 + 면세, 대량 반품 + 부분 취소 + 후속 청구 같은 현실의 데이터 패턴을 테스트 환경에 반영해야 "당신 회사의 프로세스"를 검증할 수 있습니다.
운영 DB에서 업무별로 실거래 데이터를 추출하고, 이를 테스트 시나리오에 바로 적용할 수 있는 구조가 있다면, 이 문제를 구조적으로 해결할 수 있습니다.
결론: Clean Core의 진짜 완성은 깨끗한 코어가 아니라 반복 가능한 검증 체계다
Clean Core는 올바른 방향입니다.
코어를 깨끗하게 유지하면 업그레이드가 쉬워지고, SAP의 혁신을 빠르게 받아들일 수 있습니다. SAP가 Cloud ALM에 전용 대시보드와 코드 분석 도구까지 만들어서 밀고 있는 이유가 있습니다. 커스텀 코드 충돌에서 해방되는 것만으로도 운영팀의 부담은 상당히 줄어듭니다.
하지만 Clean Core가 약속하는 건 "테스트가 사라진다"가 아니라 "테스트의 성격이 바뀐다"입니다.
코어 안 커스텀 코드 충돌 테스트는 줄어듭니다. 대신 BTP 확장 검증, 정기 회귀 테스트, 연계 테스트가 새로운 무게 중심이 됩니다. 그리고 이 테스트들은 정기 업그레이드 주기에 맞춰 반복되기 때문에, 수동으로는 지속할 수 없습니다.
같은 Clean Core, 다른 결과
같은 Clean Core 전환을 마친 두 기업을 비교해봅시다.
A사는 Clean Core 전환을 마치고 안심합니다. "커스텀을 다 빼서 이제 업그레이드가 편해졌다." 반기 업그레이드를 적용하면서 별도 회귀 테스트 없이 진행합니다. 첫 번째 업그레이드는 무사히 지나갑니다. 두 번째 업그레이드에서 BTP 확장이 호출하는 API의 응답 포맷이 미세하게 달라지면서, 커스텀 승인 프로세스가 조용히 멈춥니다. 운영팀은 한 주 뒤에야 이를 발견합니다 — 승인 대기 건이 쌓여 현업에서 문의가 들어온 뒤에야 이를 알아챕니다.
B사는 Clean Core 전환과 함께 회귀 테스트 자동화를 구축합니다. 반기 업그레이드마다 수백 건의 E2E 시나리오를 백엔드 직접 전송 방식으로 수시간 내에 돌립니다. 운영 데이터 기반으로 예외 조합까지 포함합니다. 두 번째 업그레이드 전 테스트에서 BTP 확장의 API 호환 문제를 사전에 발견하고, Go-live 전에 수정합니다.
차이는 Clean Core를 "했는가"가 아니라, 깨끗해진 코어 위에서 “반복 가능한 검증 체계를 갖췄는가” 입니다.
Clean Core의 진짜 완성은 코어를 깨끗하게 만드는 순간이 아닙니다. 깨끗해진 코어 위에서, 정기 업그레이드마다 BTP 확장과 비즈니스 프로세스 전체를 빠르게 검증할 수 있는 체계가 갖춰지는 순간입니다.