ATC 검사 없이 배포하면 큰일 — ABAP 코드 품질 자동화 #shorts #SAP #ABAP

개요와 이 글에서 다루는 범위

ABAP Test Cockpit(이하 ATC)은 ABAP 코드의 정적 분석과 품질 게이트(Quality Gate) 역할을 담당하는 SAP의 코드 검사 프레임워크입니다. 이 글에서는 ABAP Cloud(Steampunk, BTP ABAP Environment 및 S/4HANA Cloud Private/Public Edition) 환경에서 ATC를 ADT(ABAP Development Tools, Eclipse 기반)로 실행하고, Priority 1 결함을 해소한 뒤, GitHub Actions 기반 CI/CD 파이프라인에 ATC 결과를 통합하여 배포 전 자동 검증을 수행하는 흐름을 정리합니다.

이 글을 끝까지 따라가면 다음 항목을 직접 구성할 수 있습니다.

ADT에서 ATC Run/Run As 실행과 결과 해석
Check Variant(검사 변형)와 Priority(우선순위) 체계 이해
Exemption(예외) 요청 워크플로우 운영
abaplint 또는 abapGit 기반 CI/CD에 ATC 호출 연동
Priority 1 결함을 빌드 실패로 처리하는 게이트 설계

먼저 알고 있어야 할 배경 지식

이 글은 ABAP 객체(클래스, 인터페이스, CDS 뷰, RAP BO)를 ADT에서 작성해본 경험을 전제로 합니다. 또한 ABAP Cloud 개발 모델(Release Contract, Released API)과 abapGit을 이용한 소스 직렬화 개념을 알면 CI/CD 연동 부분의 이해가 빨라집니다. GitHub Actions에 대한 기본 워크플로 YAML 문법 지식도 마지막 단계에서 사용됩니다.

실습 환경과 준비물

다음 구성을 가정하고 코드와 설정을 작성했습니다. 사용 중인 시스템 버전에 따라 메뉴 위치나 Check ID가 다를 수 있으므로, 자사 환경의 Release Notes를 함께 확인하기를 권장합니다.

ABAP Cloud: SAP BTP ABAP Environment(Steampunk) 또는 S/4HANA Cloud Private Edition 2023 이상
IDE: ADT 3.40 이상이 설치된 Eclipse 2024-03 이상
Check Variant: ABAP_CLOUD_DEVELOPMENT_DEFAULT (ABAP Cloud 권장 변형)
abapGit Standalone 또는 Background 모드
GitHub Actions Runner: ubuntu-latest, abaplint CLI 활용
권한: S_DEVELOP, ATC Administration 권한(Exemption 승인 시)

ABAP Cloud 환경에서는 SE80/SE38 기반 Classic ATC와 달리, ADT의 ATC Result Browser와 Fiori Launchpad의 "Manage Checks" 앱을 함께 사용해야 운영 효율이 일반적으로 높습니다.

ATC 핵심 개념 정리

ATC는 ABAP 소스를 컴파일하기 전에 또는 활성화 시점에 정적 분석을 수행하는 검사 엔진입니다. 내부적으로는 Code Inspector(SCI)의 후속 프레임워크로, 다음 네 가지 축으로 동작을 이해하면 도움이 됩니다.

Check: 단일 룰. 예: "Released API만 사용", "SELECT ... INTO TABLE 시 ORDER BY 누락"
Check Variant: Check들의 집합. ABAP Cloud의 경우 ABAP_CLOUD_DEVELOPMENT_DEFAULT가 기본 권장 변형입니다.
Priority: 1(에러) / 2(경고) / 3(정보)로 분류됩니다. 일반적으로 Priority 1은 빌드 차단 사유로 사용합니다.
Exemption: 특정 결함에 대해 사유와 만료일을 기재하고 승인받는 예외 처리 절차입니다.

ABAP Cloud 모델에서 가장 자주 만나는 결함은 "Use of Released API only"입니다. Classic ABAP과 달리 Cloud 컨텍스트에서는 Release Contract가 부여되지 않은 객체(예: 일부 DDIC 테이블 직접 접근, 함수 모듈 직접 호출)는 사용이 차단되며, ATC가 이를 Priority 1로 감지합니다. 비유하자면 ATC는 코드 출고 직전의 "QA 검수원"이고, Released API 목록은 "안전 인증을 통과한 부품 목록"에 해당합니다. 인증되지 않은 부품을 끼우면 검수원이 조립 라인을 멈추는 것과 같습니다.

Check Variant는 ATC Configuration(Fiori 앱 "Configure ATC" 또는 트랜잭션 ATC)에서 시스템 단위 기본값으로 지정합니다. 프로젝트별로 다른 변형을 적용하고 싶다면 패키지 속성에 "ATC Check Variant"를 명시적으로 부여할 수 있습니다.

1단계 — ADT에서 기본 ATC 실행

가장 단순한 실행 흐름은 ADT의 Project Explorer에서 패키지 또는 클래스를 우클릭하고 "Run As" → "ABAP Test Cockpit"을 선택하는 것입니다. 다음은 검사 대상이 되는 단순 클래스 예시입니다. 의도적으로 Cloud에서 차단되는 패턴을 넣었습니다.

CLASS zcl_order_reporter DEFINITION
  PUBLIC
  FINAL
  CREATE PUBLIC.

  PUBLIC SECTION.
    METHODS print_open_orders.

ENDCLASS.

CLASS zcl_order_reporter IMPLEMENTATION.

  METHOD print_open_orders.
    DATA lt_orders TYPE TABLE OF vbak.   " Cloud에서 차단 대상

    SELECT vbeln, erdat, netwr
      FROM vbak
      INTO CORRESPONDING FIELDS OF TABLE @lt_orders
      WHERE auart = 'TA'.

    LOOP AT lt_orders ASSIGNING FIELD-SYMBOL(<ls_order>).
      WRITE: / <ls_order>-vbeln, <ls_order>-netwr.   " WRITE 사용도 Cloud에서 제한
    ENDLOOP.
  ENDMETHOD.

ENDCLASS.

이 클래스를 패키지에 활성화한 뒤 ADT에서 ATC를 실행하면 ATC Problems View에 결과가 표시됩니다. 일반적으로 다음과 같은 메시지를 확인할 수 있습니다.

"Use of VBAK in ABAP for Cloud Development not allowed" — Priority 1
"WRITE statement not allowed in ABAP for Cloud Development" — Priority 1

해결 방향은 Released CDS 뷰(예: I_SalesOrder)와 RAP Behavior 또는 IF_OO_ADT_CLASSRUN 기반 콘솔 출력으로 교체하는 것입니다.

2단계 — Priority 1 결함 해소와 로깅 적용

실무 시나리오에서는 결함 해소뿐 아니라 실행 추적과 예외 처리 로깅을 함께 설계합니다. 아래는 Released API만 사용하도록 재작성한 버전입니다.

CLASS zcl_order_reporter DEFINITION
  PUBLIC
  FINAL
  CREATE PUBLIC.

  PUBLIC SECTION.
    INTERFACES if_oo_adt_classrun.

  PRIVATE SECTION.
    METHODS read_open_orders
      RETURNING VALUE(rt_orders) TYPE STANDARD TABLE OF i_salesorder WITH EMPTY KEY
      RAISING   cx_abap_invalid_value.

ENDCLASS.

CLASS zcl_order_reporter IMPLEMENTATION.

  METHOD if_oo_adt_classrun~main.
    TRY.
        DATA(lt_orders) = read_open_orders( ).
        out->write( |Open orders fetched: { lines( lt_orders ) }| ).

        LOOP AT lt_orders ASSIGNING FIELD-SYMBOL(<ls_order>).
          out->write( |{ <ls_order>-salesorder } / { <ls_order>-totalnetamount }| ).
        ENDLOOP.

      CATCH cx_abap_invalid_value INTO DATA(lx_err).
        out->write( |[ERROR] { lx_err->get_text( ) }| ).
    ENDTRY.
  ENDMETHOD.

  METHOD read_open_orders.
    SELECT salesorder, salesorderdate, totalnetamount
      FROM i_salesorder
      WHERE salesordertype = 'TA'
      INTO TABLE @rt_orders
      UP TO 500 ROWS.
  ENDMETHOD.

ENDCLASS.

변경의 핵심은 세 가지입니다. 첫째, VBAK 직접 접근을 Released CDS 뷰 I_SalesOrder로 대체했습니다. 둘째, WRITE 대신 if_oo_adt_classrun의 out->write( )를 사용해 콘솔 로깅을 수행합니다. 셋째, TRY ... CATCH cx_abap_invalid_value로 예외 경로를 명시화했습니다. 다시 ATC를 돌리면 Priority 1 결함이 사라지고, 잔여 항목은 일반적으로 Priority 2(권고) 수준으로 남습니다.

특정 결함이 비즈니스적으로 회피 불가한 경우 ATC Problems View의 항목을 우클릭하여 "Request Exemption"을 선택합니다. Approver, 만료일, 사유를 입력하면 Fiori "Approve ATC Exemptions" 앱에서 승인자가 검토합니다. Exemption은 무기한이 아닌 만료일 기반 운영을 권장합니다.

3단계 — GitHub Actions CI/CD 연동

운영 환경에서는 개발자가 ATC를 까먹지 않도록 파이프라인에서 자동 실행해야 합니다. 일반적인 패턴은 두 가지입니다.

abapGit으로 GitHub에 직렬화된 소스를 abaplint(Open Source ABAP 린터)로 검사하는 사전(Pre-flight) 단계
SAP가 제공하는 piper(또는 자체 호출)를 통해 실제 ATC를 시스템에서 실행하고, 결과를 Checkstyle XML로 회수하는 단계

다음은 GitHub Actions에서 abaplint로 사전 검사를 수행하고, Priority 1에 해당하는 룰을 빌드 실패로 처리하는 워크플로 예시입니다.

name: abap-quality-gate

on:
  pull_request:
    branches: [ main ]
  push:
    branches: [ develop ]

jobs:
  static-checks:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout sources
        uses: actions/checkout@v4

      - name: Setup Node.js
        uses: actions/setup-node@v4
        with:
          node-version: '20'

      - name: Install abaplint
        run: npm install --global @abaplint/cli

      - name: Run abaplint with cloud profile
        run: abaplint --format checkstyle --outfile abaplint-report.xml
        continue-on-error: false

      - name: Upload report
        if: always()
        uses: actions/upload-artifact@v4
        with:
          name: abaplint-report
          path: abaplint-report.xml

리포지토리 루트에 abaplint.jsonc를 두고 ABAP Cloud 프로파일과 동일한 룰 셋을 흉내내도록 설정합니다. 핵심 발췌는 다음과 같습니다.

{
  "global": {
    "files": "/src/**/*.*",
    "skipGeneratedGatewayClasses": true
  },
  "syntax": {
    "version": "Cloud",
    "errorNamespace": "^(Z|Y)"
  },
  "rules": {
    "cloud_types": true,
    "avoid_use": {
      "define": true,
      "endselect": true,
      "kernelCall": true,
      "writeListState": true
    },
    "check_syntax": true,
    "unused_variables": true
  }
}

시스템 측 ATC를 실제로 호출하려면 ABAP Cloud 시스템의 ATC OData 서비스를 호출하는 별도 단계가 필요합니다. 일반적으로 SAP Project "Piper"의 abapEnvironmentRunATCCheck 스텝을 활용하며, 다음과 같은 형태로 호출합니다.

      - name: Run ATC on ABAP system
        uses: SAP/project-piper-action@v1
        with:
          command: abapEnvironmentRunATCCheck
          flags: >-
            --cfApiEndpoint=${{ secrets.CF_API }}
            --cfOrg=${{ secrets.CF_ORG }}
            --cfSpace=${{ secrets.CF_SPACE }}
            --cfServiceInstance=${{ secrets.ABAP_INSTANCE }}
            --atcConfig=atc-config.yml
        env:
          PIPER_username: ${{ secrets.SAP_USER }}
          PIPER_password: ${{ secrets.SAP_PASS }}

      - name: Fail on Priority 1
        run: |
          if grep -q 'severity="error"' ATCResults.xml; then
            echo "Priority 1 findings detected"; exit 1;
          fi

여기서 atc-config.yml은 대상 패키지, Check Variant(예: ABAP_CLOUD_DEVELOPMENT_DEFAULT), Configuration을 명시합니다. 인증 정보는 GitHub Secrets로만 주입하고, 서비스 키는 정기 회전하는 것을 권장합니다.

자주 만나는 실수와 트러블슈팅

운영 중 자주 보고되는 이슈를 FAQ 형태로 정리했습니다.

Q1. ATC를 돌렸는데 결과가 비어 있다.
A. Check Variant가 비어 있거나 비활성 Check만 포함된 변형일 가능성이 큽니다. 시스템 ATC Configuration에서 기본 변형을 확인하고, 패키지 속성의 ATC Check Variant 오버라이드 여부도 점검하세요. ABAP Cloud에서는 ABAP_CLOUD_DEVELOPMENT_DEFAULT를 권장합니다.
Q2. 동일 코드인데 로컬 ADT와 CI 결과가 다르다.
A. 로컬은 Local Inspection(빠른 단축 검사)을 수행하고, CI는 전체 변형을 적용하는 경우가 흔합니다. ADT에서 "Run As → ABAP Test Cockpit With..." 메뉴로 동일 변형을 선택해 재실행하여 비교하세요.
Q3. Released API가 아닌 객체를 꼭 써야 한다.
A. 우선 SAP API Hub 또는 Released Objects 카탈로그에서 대체재를 찾는 것이 일반적으로 유리합니다. 정 안 되면 Exemption을 요청하되, 만료일을 6~12개월 이내로 짧게 두고 대체 작업 티켓을 함께 등록하세요.
Q4. Priority 2까지 빌드 실패로 묶었더니 개발 속도가 너무 떨어진다.
A. 게이트는 단계적으로 강화하는 편이 권장됩니다. 초기에는 Priority 1만 차단, 다음 스프린트에서 Priority 2 신규 결함 차단(증가분 게이트), 마지막에 전체 차단 순서로 단계 적용하면 팀 저항이 줄어듭니다.

흔한 함정 한 가지는 abapGit으로 직렬화된 소스에 abaplint를 돌리는 것을 "ATC와 동일하다"고 오해하는 것입니다. abaplint는 정적 분석을 빠르게 수행하는 보조 도구이고, 시스템 컨텍스트(DB 객체, Release Contract, 권한 검사)를 동일하게 검증하지 못하므로 두 단계를 모두 두는 것이 일반적으로 안전합니다.

이후에 더 깊이 살펴볼 주제

이 글에서 다룬 흐름을 익혔다면 다음 주제로 확장해 볼 수 있습니다. 첫째, ATC와 함께 ABAP Unit을 CI에 통합하여 정적 분석과 단위 테스트 게이트를 동시에 운영하기. 둘째, Code Pal for ABAP 등 커뮤니티 Check를 사내 Check Variant에 합치기. 셋째, gCTS(Git-enabled CTS)와 ATC를 묶어 Transport 단계에서 자동 검증하기. 넷째, Fiori "Manage Software Components" 앱에서 Release 단계별 ATC 결과 추적을 자동화하기.

참고할 만한 문서와 자료

SAP Help Portal — ABAP Test Cockpit: help.sap.com/docs/ABAP_PLATFORM_NEW
SAP Help Portal — ATC in ABAP Cloud Development: help.sap.com/docs/btp ATC Checks
SAP Help Portal — Released APIs for ABAP Cloud: help.sap.com Released APIs
SAP Community — ATC Exemption Workflow Best Practices: community.sap.com ATC
Project Piper — abapEnvironmentRunATCCheck Step: project-piper.io
abaplint 공개 문서: rules.abaplint.org
SAP Help Portal — ABAP Development Tools User Guide: help.sap.com ADT Guide

댓글 0