SAP CBO, 애증의 Z코드 완벽 해부

안녕하세요, Rabbit입니다! 🐰

현업에서 “이거 Z로 개발해야 해요”라는 말을 들어보신 적 있을 거예요. 오늘은 SAP 개발의 오래된 동반자, CBO(Z코드)를 다루겠습니다. SAP의 표준 기능만으로 우리 회사의 특수한 업무를 다 처리할 수 없을 때 구원자처럼 등장하는 게 CBO인데, 이 구원자가 가끔은 시스템을 무겁게 만드는 주범이 되기도 합니다.

오늘은 CBO의 정체부터 장단점, 그리고 현업의 현실적인 딜레마까지 정리하겠습니다.

3줄 요약

• CBO는 회사가 직접 추가한 프로그램으로, 이름이 Z나 Y로 시작해 ‘Z코드’라 불린다.
• 표준 기능에 손대지 않고 따로 만들어 안정적이지만, 쌓이면 관리가 어려워진다.
• 표준 T-CODE(통제는 어렵지만 강력함)와 Z코드(편하지만 늘면 부담) 사이엔 정답이 없다.

CBO, 그게 뭔가요

CBO는 ‘Customer Bolt-On’의 줄임말로, 쉽게 말해 ‘고객(회사)이 직접 추가한 프로그램’입니다. 잘 갖춰진 주방에 우리 매장만의 특별 도구를 하나 더 들이는 것과 비슷합니다.

실무에서는 CBO보다 Z코드라는 말을 훨씬 많이 씁니다. SAP에는 회사가 직접 만든 개발 객체는 이름을 Z나 Y로 시작해야 한다는 규칙이 있습니다. SAP가 제공하는 표준 프로그램과 회사가 만든 프로그램을 한눈에 구분하기 위한 장치입니다. 메뉴판에서 본사 표준 메뉴와 우리 매장만의 스페셜 메뉴를 표시로 구분해두는 것과 같습니다. “아, 이건 우리가 만든 거구나”라고 바로 알 수 있죠.

비유로 이해하기: 본사 레시피와 매장 특별 소스

레스토랑 비유로 풀어보면 더 쉽습니다. 본사가 내려준 표준 레시피가 있다고 해봅시다. 맛도 좋고 다 마음에 드는데, 딱 하나 우리 매장 단골손님이 원하는 매운맛 소스가 빠져 있습니다.

이때 선택은 두 가지입니다.

수정은 본사 레시피 자체를 뜯어고치는 겁니다. SAP의 표준 프로그램을 직접 수정하는 것과 같습니다. 위험하고, 나중에 본사가 레시피를 업데이트하면 충돌이 날 수 있습니다.

CBO 개발은 본사 레시피는 그대로 두고, 우리 매장만의 특별 소스를 따로 만들어 곁들이는 겁니다. 원래 메뉴를 해치지 않으면서 우리만의 특색을 더하는 거죠. 이게 CBO(Z코드)가 일하는 방식입니다.

빛과 그림자 — CBO의 장단점

CBO는 회사 업무 효율을 끌어올리는 효자가 되기도 하고, 시스템을 느리게 만드는 골칫거리가 되기도 합니다.

장점은 유연성입니다. 전 세계 수많은 회사가 쓰는 SAP 표준이 우리 회사의 업무 방식과 완벽히 맞기는 어렵습니다. “우리는 결재 단계가 5단계라 표준으론 부족해요” 같은 상황에 CBO는 단비 같은 존재입니다. 표준 프로그램을 직접 건드리지 않으니 시스템 안정성도 지켜지고, SAP가 업그레이드될 때 충돌 위험도 적습니다.

단점은 관리 부담입니다. CBO는 만들고 끝이 아닙니다. 법규나 업무가 바뀌면 계속 손봐야 합니다. 이런 CBO가 하나둘 쌓이면, 나중엔 누가 왜 만들었는지 아무도 모르는 ‘블랙박스’가 됩니다. 담당자가 퇴사하면 더 막막해지죠. 필요하다고 마구 만들다 보면 시스템이 점점 무거워지고 느려지는 것도 문제입니다.

현실의 딜레마 — 표준 T-CODE vs Z코드

이론은 그렇다 쳐도, 현장에선 늘 비슷한 고민이 따라옵니다. 현업에 표준 T-CODE를 가르쳐야 할지, Z코드 사용법만 알려줘도 될지 망설여지는 순간이 옵니다. 대부분의 업무는 Z코드로 충분히 처리되고, 회사 규칙이 잘 반영돼 있어 통제하기도 쉽습니다. 반면 표준 T-CODE는 강력하지만, 사람마다 다르게 쓰면 프로세스가 엉킬 수 있습니다.

Z코드는 친절한 매니저의 체크리스트와 같습니다. 우리 매장만의 규칙(특정 조건에서는 이 값을 못 넣게 막기, 필수 항목 자동 입력)이 이미 다 반영돼 있어, 직원은 순서대로 따라 입력만 하면 됩니다. 실수가 줄고 일이 편해집니다.

표준 T-CODE는 강력한 만능 조리도구와 같습니다. 기능은 많고 잘 쓰면 효율적이지만, 제대로 모르고 쓰면 다칠 수 있습니다. 회사의 세세한 규칙까지 막아주지 않아서, 잘못 입력할 가능성이 Z코드보다 큽니다.

정답은 없다, 균형이 있을 뿐

그렇다면 모두가 표준 T-CODE만 쓰는 게 정답일까요? 그렇지도 않습니다. 모두가 표준만 쓴다면, Z코드에 녹아 있던 회사의 중요한 업무 규칙이 무시될 수 있고, 이는 월말 결산이나 연말 보고에서 원인 모를 데이터 불일치로 돌아옵니다.

결국 “어느 쪽이 옳다”가 아니라, “양쪽의 장점을 살리면서 단점을 줄이는 방법”을 찾는 게 답입니다.

그림 1. 표준 T-CODE(만능 도구)와 Z코드(맞춤 비서)의 차이

두 방식의 성격과 강점, 약점을 표로 정리하면 차이가 더 또렷해집니다.

	표준 T-CODE	Z코드(CBO)
성격	만능 조리도구	친절한 체크리스트
강점	강력하고 범용적	회사 규칙이 이미 반영됨
약점	통제·관리가 어려움	쌓이면 블랙박스화
적합한 상황	표준 업무, 드문 작업	반복 업무, 회사 고유 규칙

표 1. 표준 T-CODE와 Z코드의 성격 비교

Rabbit의 한 끗

CBO(Z코드)는 회사에 꼭 맞는 기능을 주는 유용한 도구입니다. 다만 계획과 관리 원칙 없이 늘리면 시스템을 무겁게 만드는 양날의 검이기도 합니다.

CBO를 만들기 전엔 늘 이렇게 물어보면 좋습니다. “이거 정말 CBO로 만들어야 할까?”, “표준 기능이나 설정으로 대체할 수 없을까?”, “지금 만들면 나중에 우리가 이걸 잘 관리할 수 있을까?” 꼭 필요한 CBO는 만들되, 개발 표준과 문서화를 함께 갖추는 것, 그게 애증의 Z코드를 애정으로 채우는 방법입니다. 😎

더 읽어보기

• 실무자가 자주 쓰는 SAP PP T-CODE 모음
• SAP T-CODE 사용법: 입력부터 단축 명령어·즐겨찾기까지