가상의 Z 프로그램이 국가 테이블 T005를 직접 읽고 있다고 해 봅시다. 클린 코어 이야기가 나오면 '이 표준 객체는 릴리스된 API인가'라는 질문이 따라옵니다. 이 글을 읽고 나면 릴리스된 API가 무엇으로 정해지는지, 표준 객체의 상태를 ADT와 SAP 공개 목록에서 어떻게 확인하는지, 릴리스되지 않은 객체에 기대면 업그레이드 때 왜 부담인지 구분해 어디부터 고칠지 고를 수 있습니다.
예시 프로그램 ZDEMO_API_STATE는 지어낸 것이고, 코드는 실제 시스템에서 실행하지 않았습니다. 표준 객체의 상태 값은 SAP가 GitHub에 공개한 Cloudification Repository 파일을 2026-10-21에 내려받아 확인했습니다. 개념은 ABAP 키워드 문서 7.58판, ADT 화면은 ABAP Platform 2025 FPS02의 ADT 안내서, 클린 코어 등급은 SAP Learning 과정을 기준으로 했고, 목록과 화면은 릴리스에 따라 바뀝니다.
릴리스된 API는 계약과 공개 범위, 두 분류로 정해진다
ABAP은 클래식 ABAP과 ABAP Cloud라는 두 주요 개발 방식을 지원합니다. 클래식 ABAP의 언어 버전인 Standard ABAP은 패키지 개념 말고는 저장소 객체 접근을 막지 않습니다. ABAP Cloud의 언어 버전인 ABAP for Cloud Development로 만든 객체는 같은 소프트웨어 컴포넌트 안처럼 허용된 몇 가지 경우를 빼면, 그 언어 버전용으로 릴리스된 API만 쓸 수 있습니다.
릴리스된 API는 ABAP Cloud에서 접근하도록 릴리스된 저장소 객체, 또는 그 일부이고, 두 분류가 함께 붙어야 합니다. 하나는 릴리스 계약으로, 바뀔 때 지킬 일관성과 호환성의 선을 정합니다. 일부 언어 버전의 저장소 객체가 릴리스된 API에 접근할 때 관련되는 계약은 C1(시스템 안에서 사용)뿐입니다. 다른 하나는 공개 범위(visibility)로, ABAP for Cloud Development나 ABAP for Key Users 같은 제한된 언어 버전에서 그 객체가 보이게 합니다.
C1 계약은 이미 공개된 파라미터·요소·CDS 연관 같은 구성 요소를 호환되지 않게 바꾸지 못하게 하고, 선택적 구성 요소는 나중에 더할 수 있게 둡니다. C1 객체는 릴리스 뒤에 지우면 안 되고, 대신 폐기 예정(deprecated)이 될 수 있습니다. 다만 완전한 하위 호환까지 약속하지는 않으므로, 쓰는 쪽도 허용된 변경에 견디게 짜야 업그레이드 뒤의 오류를 피할 수 있습니다.
SAP 노트
릴리스된 API는 두 분류가 함께 붙은 객체
ABAP 키워드 문서 7.58 · ADT 안내서 기준
릴리스 계약
C1- 바뀔 때 지킬 호환성의 선을 정한다
- C0 확장 · C1 시스템 안에서 사용 · C2 원격 API 등
- 일부 언어 버전의 API 접근에는 C1뿐
공개 범위(visibility)
Use in Cloud Development- 어느 제한 언어 버전에서 보일지 정한다
- ABAP for Cloud Development
- 또는 ABAP for Key Users
릴리스된 API
API State: Released- 둘이 함께 있어야 ABAP Cloud에서 쓴다
- C1 객체는 지우면 안 되고 폐기 예정이 될 수 있다
- 완전한 하위 호환까지 약속하지는 않는다
클래식 ABAP의 Standard ABAP은 패키지 개념 말고는 저장소 객체 접근을 막지 않습니다.
표준 객체 하나의 상태를 확인하는 자리
시스템 안에서는 개발 객체의 Properties 뷰에서 API State 탭을 보면 릴리스 상태가 나오고, 이 탭은 API로 릴리스될 수 있는 종류의 객체에만 있습니다. Released는 그 계약이 정한 목적으로 쓸 수 있는 공개 API입니다. Deprecated는 아직 공개 API지만 더는 쓰지 말고 후속 객체로 바꾸라는 뜻입니다. Deprecated로 12개월 이상 지난 객체는 최종 상태인 Decommissioned가 될 수 있고, 그러면 생산 용도로 쓸 수 없습니다.
여러 객체는 ADT Project Explorer에서 새 ABAP Repository Tree를 만들고 Released Objects나 Deprecated Objects 필터를 고릅니다. 속성 필터에 api:USE_IN_CLOUD_DEVELOPMENT를 넣으면 C1 계약, Use in Cloud Development 공개 범위로 릴리스된 객체가 나옵니다. 프로그램 ABAP_DOCU_RELEASED_APIS는 현재 시스템에서 릴리스 계약이 붙은 저장소 객체 목록을 보여 줍니다.
시스템 밖에는 SAP가 GitHub 저장소 SAP/abap-atc-cr-cv-s4hc에 공개한 Cloudification Repository가 있습니다. 릴리스된 API와 함께 릴리스되지 않은 객체도 JSON 파일에 담고, 후속 객체가 정해져 있으면 그것도 적습니다. SAP Cloud ERP Private이나 온프레미스는 이름에 PCE가 들어간 파일을 쓸 수 있는데, PCE 최신 파일은 SAP Cloud ERP Private 최신 판에만 맞으므로 자기 릴리스용 파일을 README에서 확인합니다.
SAP 노트
표준 객체 하나의 상태를 보는 세 자리
ADT 2025 FPS02 · ABAP 7.58 · SAP 공개 목록
ADT의 API State 탭
Properties > API State- Properties 뷰에서 객체 하나의 상태
- Released: 계약이 정한 목적으로 쓴다
- Deprecated: 후속 객체로 바꾼다
- Deprecated로 12개월 이상이면 Decommissioned가 될 수 있다
시스템 안의 목록
api:USE_IN_CLOUD_DEVELOPMENT- ADT Repository Tree의 Released Objects
- 속성 필터 api:로 계약·공개 범위를 고른다
- 프로그램 ABAP_DOCU_RELEASED_APIS
SAP가 공개한 목록
T005 -> I_COUNTRY- GitHub의 Cloudification Repository
- 릴리스 안 된 객체도, 정해졌으면 후속 객체도 싣는다
- Cloud ERP Private·온프레미스는 PCE 파일을 쓸 수 있다
- PCE 최신 파일은 Cloud ERP Private 최신 판 기준
상태 값은 2026-10-21에 받은 파일 기준입니다. 자기 시스템의 릴리스에서 다시 확인하세요.
2026-10-21에 받은 PCE 최신 파일(objectReleaseInfo_PCELatest.json)에서 T005 항목은 state가 notToBeReleased이고, successors에 CDS 엔터티 I_COUNTRY가 적혀 있습니다. I_COUNTRY의 state는 released입니다. SAP Learning의 SAP S/4HANA Cloud 과정은 ABAP Cloud 개발에서 T005를 읽으면 I_COUNTRY를 쓰라는 문법 오류가 난다고 예를 듭니다. 반면 Standard ABAP 프로그램에서는 같은 SELECT가 막히지 않으므로, 상태를 따로 찾아봐야 합니다.
릴리스되지 않은 객체에 기대면 업그레이드 때 무엇이 남나
ABAP Cloud에서 릴리스된 API의 변경은 앞에서 본 릴리스 계약이 엄격히 다룹니다. 릴리스되지 않은 객체에는 이런 약속이 없습니다. SAP Learning의 클린 코어 과정은 릴리스되지도, 클래식 API로 지정되지도 않은 SAP 내부 객체를 공지 없이, 호환성 보장 없이 바뀔 수 있는 대상으로 봅니다. 그런 객체에 기대는 Z 코드는 업그레이드 전에 그 객체가 바뀌었는지 살펴볼 일이 생깁니다. 같은 과정은 클래식 확장 기법을 쓰면 업그레이드 프로젝트가 필요 이상으로 번거로워질 수 있다고도 봅니다.
모든 미릴리스 객체가 같은 위험은 아닙니다. 같은 과정은 SAP S/4HANA Cloud Private Edition과 온프레미스의 확장을 네 등급으로 나눕니다. A는 릴리스된 API와 확장 지점만 쓰고, 시스템 안의 확장이라면 키 유저·개발자 확장 도구와 그에 맞는 ABAP 언어 버전으로 만듭니다. B는 공식 안정성 계약은 없지만 SAP가 클래식 API로 지정한 객체와 릴리스된 API만 쓰며, CL_GUI_ALV_GRID를 쓰는 ALV, 제한·미지원 객체를 참조하지 않는 Standard ABAP 커스텀 객체가 예입니다. C는 그 밖의 내부 객체를 쓰며, 외부 사용으로 인정되지 않은 SAP 테이블을 읽기만 하는 경우가 예입니다. C의 위험을 다루도록 SAP 객체 변경 기록(changelog)이 도입되었고, 그 기능에 호환되지 않는 변경을 찾는 자동 ATC 점검이 있습니다. D는 수정(modification), 암시적 확장, SAP 테이블에 대한 지원되지 않는 쓰기처럼 권장하지 않는 것을 씁니다. 한 확장의 등급은 그 안의 가장 낮은 등급으로 정해집니다.
같은 저장소의 클래식 API 분류 파일(objectClassifications_SAP.json)에는 classicAPI와 noAPI 상태가 있고, noAPI는 D 등급 객체를 가리킵니다. 2026-10-21 파일 기준으로 CL_GUI_ALV_GRID는 classicAPI입니다. T005는 릴리스되지 않았고 이 파일에도 없으므로, 등급 정의를 그대로 대면 T005를 직접 읽는 ZDEMO_API_STATE는 C가 됩니다. T005를 I_COUNTRY로 바꿔도 Standard ABAP 프로그램이므로 A가 아니라, 같은 정의로는 B입니다.
SAP 노트
클린 코어 등급 A~D
SAP S/4HANA Cloud Private Edition·온프레미스 확장
A · 릴리스된 API
ABAP for Cloud Development- 릴리스된 API와 확장 지점만 쓴다
- 안정성 계약이 있다
- 시스템 안에서는 맞는 언어 버전으로 만든다
B · 클래식 API
CL_GUI_ALV_GRID- SAP가 클래식 API로 지정한 객체
- 공식 안정성 계약은 없다
- 제한·미지원 객체를 안 쓰는 Standard ABAP 객체도
C · 내부 객체
SELECT * FROM t005- 릴리스도 클래식 API 지정도 아니다
- 공지 없이 바뀔 수 있다
- 예: 예시의 T005 직접 읽기
D · 권장하지 않음
state: noAPI- 수정·암시적 확장
- SAP 테이블에 지원되지 않는 쓰기
- noAPI로 표시된 객체
SAP Learning 클린 코어 과정 기준. 한 확장의 등급은 그 안의 가장 낮은 등급으로 정합니다.
프로그램이 많으면 ATC 점검으로 본다
Cloudification Repository의 JSON 파일은 ATC 점검 'Usage of Released APIs (Cloudification Repository)'의 내용으로 쓰입니다. 이 점검으로 ECC와 S/4HANA의 모든 릴리스에서 기존 커스텀 코드의 릴리스·미릴리스 API 사용을 분석할 수 있습니다. 검사 변형에서 이 점검을 켜고 속성에 파일 주소를 넣습니다. SAP Cloud ERP Private용으로는 Clean Core 아래의 Usage of APIs 점검에 PCE 파일을 넣습니다. 필요한 SAP Note 번호와 SSL 설정은 README에 있습니다.
ATC 검사 변형 ABAP_CLOUD_DEVELOPMENT_DEFAULT에 들어 있는 API_USAGE 점검도 폐기 예정 객체를 쓰는 곳을 찾지만, ABAP for Cloud Development와 ABAP for Key Users 객체만 보고합니다. Standard ABAP으로 쓴 기존 Z 프로그램에는 앞의 점검이 맞는 쪽입니다.
오늘 할 일은 하나입니다. 자주 고치는 Z 프로그램 하나를 골라, 그 안에서 직접 읽거나 부르는 SAP 표준 객체 이름을 적어 보세요. 그리고 PCE 파일에서 객체 이름으로 각 객체의 state와 successors를 찾아 옆에 적고, 파일에 없는 객체는 클래식 API 분류 파일에서 한 번 더 찾습니다. 후속 객체가 적힌 줄이 다음에 고칠 곳의 첫 후보입니다.
이 기록에 대화를 더해 주세요.
궁금한 점, 다른 접근, 직접 해 본 결과를 나눠 주세요.
로그인 상태 확인 중…
댓글을 불러오는 중…