SAP 프로젝트에서 자주 듣는 말이 있다.
“표준 화면은 우리 업무와 안 맞으니 새로 하나 만들자.”
사용자 입장에서는 자연스러운 요구다. 기존 시스템에서 쓰던 화면과 SAP 표준 화면의 구조가 다르고, 필요한 값이 한 화면에 보이지 않으면 새 프로그램이 더 편해 보인다.
하지만 SAP에서 개발 하나를 추가한다는 것은 화면 하나를 만드는 일이 아니다. 앞으로의 업그레이드, 테스트, 권한, 인터페이스, 데이터 정합성, 장애분석까지 유지해야 할 하나의 제품을 추가하는 일에 가깝다.
그래서 개발 여부는 “표준이 불편한가?”보다 먼저 이 요구가 정말 SAP 표준 프로세스 밖에 있어야 하는가?로 판단해야 한다.
첫 번째 질문: 표준이 부족한가, 우리가 표준을 다르게 쓰고 있는가
현업 요구를 받으면 바로 개발명세서를 만들기 전에 차이를 세 종류로 나누는 것이 좋다.
| 차이 | 예 | 우선 대응 |
|---|---|---|
| 프로세스 차이 | 기존 승인순서와 SAP 표준 흐름이 다름 | Fit-to-Standard 검토 |
| 정보표시 차이 | 필요한 필드가 화면에 안 보임 | Adaptation/Extension 검토 |
| 실제 기능 Gap | 표준으로 표현할 수 없는 고유 업무 | Extension/Custom App 검토 |
이 세 가지를 섞으면 단순한 화면배치 문제를 거대한 CBO로 만들거나, 반대로 실제 business requirement를 표준에 억지로 끼워 맞추게 된다.
기존 시스템과 SAP 화면이 다른 것은 정상일 수 있다
Legacy ERP에서 사용자는 한 화면에서 다음을 동시에 입력했을 수 있다.
- 회계정보
- 관리정보
- 결재정보
- 별도 통계항목
- 사용자 메모
그 시스템이 그렇게 설계되었다고 해서 SAP에서도 반드시 같은 화면을 재현해야 하는 것은 아니다.
SAP에서는 Master Data, account assignment, workflow, document flow 등 서로 다른 객체와 프로세스가 역할을 나눌 수 있다.
따라서 “화면이 다르다”는 사실은 기능 Gap의 증거가 아니다.
개발 전에는 요구사항을 결과가 아니라 목적 문장으로 바꾼다
예를 들어 현업이 다음과 같이 요청했다고 하자.
“기존 시스템처럼 입력필드 12개가 있는 CBO 화면을 만들어 주세요.”
이것은 이미 해결책까지 포함된 요구다.
대신 다음처럼 바꾼다.
“구매비용 발생 시 어느 프로젝트와 경영책임단위에 귀속되는지 입력하고, 승인 후 재무전표와 관리보고에서 동일한 정보를 추적할 수 있어야 한다.”
이렇게 정의하면 해결방법은:
- 기존 표준 account assignment
- Custom Field
- Workflow
- Extension logic
- Side-by-side application
- 완전한 Custom Object
중에서 다시 선택할 수 있다.
확장 방식은 가장 가벼운 것부터 검토한다
SAP의 현재 extensibility 방향을 단순화하면 다음과 같은 계층으로 생각할 수 있다.
- Standard Configuration
- Key-user Extensibility
- Developer Extensibility / ABAP Cloud
- Side-by-side Extension
- 필요한 경우 Classic Custom Code
Edition과 release에 따라 사용할 수 있는 기능은 다르지만 중요한 설계원칙은 같다.
표준을 변경하는 강도가 높아질수록 장기 유지비와 upgrade coupling도 증가한다.
Custom Field 하나면 되는 일을 CBO로 만들 필요는 없다
업무에 추가 속성 하나가 필요할 뿐이라면 Custom Field 또는 지원되는 extension point만으로 해결할 수 있는 경우가 있다.
예를 들어 기존 business object에 “관리구분” 하나를 추가하고 해당 값을 UI와 report에 노출하면 충분한 업무를 위해 별도 테이블·화면·CRUD 프로그램을 만들 이유는 약하다.
반대로 독립적인 lifecycle과 여러 하위 데이터, 별도 상태변경 로직을 가진 business object가 실제로 필요하다면 CBO 또는 별도 application을 검토할 이유가 생긴다.
CBO의 기준은 화면이 아니라 독립된 Business Object인가다
다음 요구를 비교해보자.
A. Purchase Order에 내부 관리용 분류값 하나가 필요하다.
B. SAP 표준에 존재하지 않는 별도 신청 객체가 있고, 신청→검토→승인→완료라는 lifecycle과 자체 데이터가 필요하다.
A를 위해 독립 CBO를 만드는 것은 과도할 수 있다.
B는 실제 독립 business object가 존재하므로 별도 객체가 자연스러울 수 있다.
즉 판단기준은 화면 개수가 아니라 업무적으로 독립된 identity와 lifecycle이 필요한가다.
Side-by-side가 유리한 경우도 있다
확장기능이 SAP transaction과 깊게 결합될 필요가 없고 여러 backend 데이터를 모으거나 외부 사용자를 대상으로 한다면 SAP core 안에 모든 로직을 넣는 것보다 side-by-side architecture가 적합할 수 있다.
예를 들어:
- 여러 시스템의 데이터를 한 곳에서 조회
- 외부 파트너가 사용하는 application
- SAP upgrade lifecycle과 독립적으로 빠르게 변경해야 하는 기능
- 대규모 별도 computation이나 특수 UI
같은 요구다.
반대로 posting 순간 SAP 내부 validation과 강하게 결합된 로직이라면 on-stack extension이 더 자연스러울 수 있다.
Clean Core는 ‘개발하지 말라’는 뜻이 아니다
Clean Core를 “모든 Z개발을 금지한다”로 이해하면 현실적인 운영이 어렵다.
SAP의 현재 guidance도 private cloud와 on-premise 환경에서 기존 classic custom code가 존재하고 모든 요구를 한 번에 ABAP Cloud 모델로 전환하기 어려운 현실을 인정한다.
핵심은 개발 자체를 없애는 것이 아니라:
- released API와 extension point를 우선하고
- SAP internal object에 대한 강한 dependency를 줄이고
- upgrade impact를 측정 가능하게 만들고
- 새 extension은 가능하면 cloud-ready 방식으로 만드는 것
이다.
Custom Code의 진짜 비용은 개발비보다 변경비다
개발비 2천만원의 프로그램이 10년 동안 그대로 동작한다면 비용은 예측 가능하다.
문제는 매년:
- SAP upgrade regression test
- business rule 변경
- authorization 변경
- 관련 interface 변경
- 개발자 교체
- 장애분석
이 필요해질 때다.
따라서 Custom Development 경제성은 초기 개발비보다:
Initial Build + Upgrade/Test Cost + Change Cost + Support Cost + Failure Risk
로 봐야 한다.
표준을 쓰는 비용도 0은 아니다
반대 방향의 오류도 피해야 한다.
Fit-to-Standard라는 이유로 현업 생산성이 크게 떨어지거나 필요한 통제가 사라진다면 그것도 비용이다.
예를 들어 매월 200명이 표준 화면의 부족한 정보 때문에 30분씩 별도 Excel 작업을 해야 한다면 연간 노동시간이 상당하다.
따라서 개발을 하지 않는 선택 역시:
수작업시간 + 오류위험 + 통제손실 + 사용자교육비
를 포함해 평가해야 한다.
개발여부를 판단하는 실무 질문
| 질문 | Yes라면 |
|---|---|
| 표준 configuration으로 가능한가? | 표준 우선 |
| 기존 object에 field/logic 추가면 충분한가? | Key-user/Developer extension 검토 |
| 독립 lifecycle을 가진 객체가 필요한가? | CBO/Custom App 검토 |
| SAP core와 느슨하게 연결해도 되는가? | Side-by-side 검토 |
| SAP internal object를 직접 건드려야 하는가? | 장기 upgrade 비용을 다시 검토 |
결론
SAP 표준 화면이 기존 시스템과 다르다는 이유만으로 CBO가 필요한 것은 아니다.
좋은 설계는:
Business Purpose → Standard Fit → 최소 Extension → 독립 Object 필요성 → Lifecycle Cost
순서로 판단한다.
표준을 무조건 지키는 것도, 사용자가 원하는 화면을 모두 Custom으로 만드는 것도 정답은 아니다.
핵심은 필요한 business differentiation만 확장하고, 나머지는 SAP core와 가능한 느슨하게 결합하는 것이다.
그렇게 해야 오늘 사용하기 편한 시스템이 다음 upgrade에서 가장 비싼 legacy가 되는 일을 줄일 수 있다.