SAP Z코드, 꼭 나쁘기만 할까요?
CBO 개발, 그 유혹과 책임 사이
Z로 시작하는 그 코드, 대체 뭐길래?
SAP를 쓰다 보면 꼭 듣게 되는 말, "이건 Z로 개발해야 돼요.”
여기서 말하는 Z코드는 SAP의 표준 기능으로는 해결 안 되는 업무를 위해 만든 맞춤형 프로그램을 뜻해요.
정식 명칭은 CBO(Customer Bolt-On),
이름처럼 기존 시스템에 ‘추가로 달아 붙이는 기능’이죠.
SAP 세계에선 모든 사용자 정의 프로그램은 ‘Z’나 ‘Y’로 시작하게 되어 있는데요,
이건 마치 ‘이건 우리 회사가 만든 거예요!’라고 딱지 붙여놓는 것과 같아요.
그래서 CBO는 흔히 Z-프로그램이라고 불리죠.
맞춤 기능의 유혹, 그리고 그림자
SAP 표준 기능은 모든 기업에 맞춰진 기성복 같은 존재입니다.
그런데 우리 회사만의 독특한 사정이 있을 땐 이 기성복에 안주머니 하나쯤은 달아야겠죠?
그게 바로 CBO의 역할이에요.
필요한 리포트 추가, 입력값 제한, 자동 채움 같은 기능을 개발하면
현업은 훨씬 편리하게 일할 수 있게 됩니다.
하지만 문제가 하나 있어요.
이렇게 만든 Z-코드가 쌓이고 복잡해질수록
시스템은 무거워지고, 유지보수는 어려워지고,
결국엔 누가 만들었는지조차 모르는 블랙박스가 돼버릴 수 있다는 거죠.
편의 vs 통제, 우리는 어디에 설 것인가
현업은 Z-코드가 편해요. 회사 규칙에 맞춰 잘 가공돼 있으니까요.
반면 표준 T-코드는 범용적이지만 사용법이 복잡하고 통제가 어렵죠.
모든 걸 Z로 해결하면 회사마다 제멋대로 쓰는 시스템이 될 수 있고,
모든 걸 표준만 쓰자니 현실 업무가 안 돌아가는 상황이 생기기도 해요.
그래서 중요한 건, 양쪽의 균형을 잘 잡는 거예요.
Z코드를 만들 땐 꼭 자문해봐야 하죠.
“정말 이 기능, CBO로만 가능할까?”
“표준 기능으론 진짜 안 되는 걸까?”
“향후 유지보수는 어떻게 할 건가?”
이 글의 전문은 Rabbit Logs에서 확인하실 수 있어요.
** SAP CBO 프로그램, 애증의 Z코드 완벽 해부! (feat. 현업 딜레마) **
