abapGit 모르면 큰일 — Git Push까지 3단계 #shorts #SAP #ABAP

abapGit이 왜 ABAP 개발자의 필수 도구가 되었는가

ABAP 개발자라면 한 번쯤 이런 경험이 있을 것이다. 트랜스포트 요청(TR)을 잘못 릴리즈해서 코드가 뒤엉키고, 누가 언제 어떤 변경을 했는지 추적할 수 없어 밤을 새운 기억 말이다. abapGit은 이런 고통을 해결하기 위해 오픈소스 커뮤니티가 만든 도구로, ABAP 오브젝트(클래스, 함수그룹, DDIC, CDS 뷰 등)를 Git 저장소로 관리할 수 있게 해준다. 이 글을 마치면 다음 항목을 실제로 수행할 수 있다.

abapGit을 SE38에서 리포트 형태로 설치
GitHub 저장소를 온라인 리포지토리로 연결
Pull / Stage / Push 3단계 실전 워크플로우 실행
협업을 위한 브랜치 전략 이해
SSL/인증서/네임스페이스 관련 트러블슈팅 대응

abapGit은 SAP 표준 제품이 아닌 커뮤니티 오픈소스 도구이며, 프로덕션 시스템 적용 전 반드시 조직의 보안 정책을 확인하는 것이 권장된다.

이 글을 이해하기 위해 필요한 배경

이 글은 beginner 수준으로 설계되었지만, 몇 가지 기초 개념을 알고 있으면 훨씬 수월하다. SE80 또는 ADT(ABAP Development Tools)에서 클래스나 리포트를 생성해 본 경험, Git의 기본 명령(clone, commit, push, pull)에 대한 개념적 이해, 그리고 GitHub 계정 생성 경험이 있으면 좋다. SAP GUI만 사용해도 대부분의 작업이 가능하므로 Eclipse 기반 ADT가 없어도 진행할 수 있다. 다만 CDS View나 Behavior Definition 같은 최신 오브젝트를 다루려면 ADT + abapGit 플러그인 조합이 권장된다.

사전 준비 환경과 버전 확인

abapGit은 폭넓은 ABAP 버전을 지원하지만, 안정적인 사용을 위해서는 다음 조건을 권장한다.

NetWeaver 최소 버전: SAP NetWeaver 7.02 SP16 이상 (7.31 이상 강력 권장)
SAP BTP ABAP Environment / Steampunk: abapGit 대신 gCTS 또는 abap-file-system 기반 워크플로우 검토 필요
S/4HANA: 2020 이상에서 정상 동작 확인
권한: DEVELOPER 롤, S_TRANSPRT, S_DEVELOP 오브젝트 권한
네트워크: SAP 시스템에서 github.com으로의 HTTPS(443) 아웃바운드 통신 허용
SSL 인증서: STRUST에 GitHub 루트/중간 인증서 등록 필요 (DigiCert 계열)

온프레미스 환경이라면 SAPRouter나 프록시 설정을 SICF/SM59에서 미리 점검해야 한다. 개발/QA 시스템에서 먼저 검증 후 확장하는 것이 일반적이다.

abapGit의 동작 원리 이해

abapGit을 제대로 사용하려면 그것이 무엇을 하는 도구인지 개념적으로 이해해야 한다. 일반적인 Git 클라이언트는 파일시스템 위의 텍스트 파일을 관리하지만, ABAP 오브젝트는 데이터베이스 테이블(TADIR, REPOSRC, DD02L 등)에 저장된다. abapGit은 이 데이터베이스 오브젝트를 XML + ABAP 소스 텍스트 조합으로 직렬화(Serialization)하여 Git이 이해할 수 있는 형태로 변환한다.

비유하자면 abapGit은 "번역가"에 가깝다. ABAP 데이터베이스라는 창고에 보관된 부품(오브젝트)을 꺼내 Git이라는 세계의 언어(파일)로 번역해 GitHub에 저장하고, 반대로 GitHub에 있는 파일을 다시 ABAP 오브젝트로 재조립해 창고에 넣는다.

핵심 개념 다이어그램(텍스트):

[SAP System]              [abapGit]                [Git Remote]
 ZCL_ORDER  ─ Serialize ─> zcl_order.clas.abap ─> GitHub
 ZIF_ORDER  ─ Serialize ─> zcl_order.clas.xml
 Z_DDIC     ─ Serialize ─> z_ddic.tabl.xml     <─ Pull ─ 커밋 이력

abapGit이 관리하는 단위는 Package(개발클래스)이다. 하나의 Z-Package = 하나의 GitHub Repository 매핑이 기본 규칙이며, 이 원칙을 지키면 트랜스포트와 Git 커밋의 일관성을 유지하기 쉽다.

한 가지 중요한 제약은 abapGit이 Transport Request와 별개로 동작한다는 점이다. Push는 Git에 반영하지만 시스템 간 이전(DEV→QA→PRD)에는 여전히 TR이 필요하다. 즉, abapGit은 형상관리와 협업을 담당하고 TMS는 릴리즈 이전을 담당하는 이중 트랙 구조로 운영한다.

1단계: abapGit 설치와 저장소 연결 기본 예제

가장 먼저 abapGit standalone 버전을 설치한다. SE38에서 리포트 하나만 있으면 되는 매우 가벼운 방식이다.

브라우저에서 https://github.com/abapGit/build/blob/main/zabapgit_standalone.prog.abap 접속
Raw 파일 내용 전체 복사 (약 40만 라인 이상 단일 리포트)
SE38에서 ZABAPGIT_STANDALONE 리포트 생성
복사한 소스 붙여넣기 후 활성화(Ctrl+F3)
F8로 실행

실행하면 SAP GUI HTML 컨트롤로 abapGit의 메인 화면이 열린다. 첫 번째 실습으로 SalesOrder 관리 패키지를 만들고 GitHub 저장소에 연결해보자.

" SE80에서 로컬 패키지 생성 예시
" Package Name : $Z_SALES_ORDER_MGMT   (로컬 패키지 - 트랜스포트 없음)
" Description  : Sales Order Management Demo
" Software Comp: HOME

" 간단한 데모 클래스 하나 생성
CLASS zcl_so_calculator DEFINITION
  PUBLIC FINAL CREATE PUBLIC.
  PUBLIC SECTION.
    METHODS calculate_total
      IMPORTING iv_unit_price TYPE p DECIMALS 2
                iv_quantity   TYPE i
      RETURNING VALUE(rv_total) TYPE p.
ENDCLASS.

CLASS zcl_so_calculator IMPLEMENTATION.
  METHOD calculate_total.
    rv_total = iv_unit_price * iv_quantity.
  ENDMETHOD.
ENDCLASS.

이제 abapGit 메인 화면에서 "+ New Online" 클릭 후 다음 정보를 입력한다.

Git repository URL: https://github.com/myaccount/sales-order-mgmt.git
Package:           $Z_SALES_ORDER_MGMT
Branch:            main
Folder logic:      PREFIX   # 또는 FULL (권장: PREFIX)

Create Online Repo를 누르면 초기 Push 화면이 뜬다. GitHub Personal Access Token(PAT)을 사용자명은 GitHub ID, 비밀번호는 PAT로 입력하면 인증이 완료되고 코드가 원격 저장소로 전송된다.

2단계: 실무 시나리오 — Pull, Stage, Commit 워크플로우

실제 협업 상황을 가정해보자. 동료가 GitHub에 새로운 유틸리티 클래스를 추가했고, 나는 그것을 로컬로 가져와 수정한 뒤 다시 Push해야 한다.

Pull 실행: abapGit 메인에서 저장소 클릭 → 우측 상단 "Pull" → 트랜스포트 요청 선택 → 변경 대상 오브젝트 목록 확인 → OK. 로컬 패키지에는 새 클래스가 자동 생성된다.

수정 시나리오로, 판매주문 검증 로직을 확장해보자.

CLASS zcl_so_validator DEFINITION
  PUBLIC FINAL CREATE PUBLIC.
  PUBLIC SECTION.
    TYPES: BEGIN OF ty_validation_result,
             is_valid       TYPE abap_bool,
             error_message  TYPE string,
             error_code     TYPE string,
           END OF ty_validation_result.

    METHODS validate_order
      IMPORTING is_order        TYPE zso_order_header
      RETURNING VALUE(rs_result) TYPE ty_validation_result.

  PRIVATE SECTION.
    METHODS log_validation
      IMPORTING iv_order_id TYPE string
                iv_message  TYPE string.
ENDCLASS.

CLASS zcl_so_validator IMPLEMENTATION.
  METHOD validate_order.
    " 실무 검증: 금액 0 초과, 고객 존재, 배송일 유효
    IF is_order-total_amount <= 0.
      rs_result-is_valid      = abap_false.
      rs_result-error_code    = 'SO001'.
      rs_result-error_message = |Invalid total amount: { is_order-total_amount }|.
      log_validation( iv_order_id = is_order-order_id
                      iv_message  = rs_result-error_message ).
      RETURN.
    ENDIF.

    IF is_order-customer_id IS INITIAL.
      rs_result-is_valid      = abap_false.
      rs_result-error_code    = 'SO002'.
      rs_result-error_message = 'Customer ID is mandatory'.
      RETURN.
    ENDIF.

    rs_result-is_valid = abap_true.
  ENDMETHOD.

  METHOD log_validation.
    " Application Log 기록
    DATA(lo_log) = cl_bali_log=>create_with_header(
      severity = if_bali_constants=>c_severity_error
      header   = cl_bali_header_setter=>create( object = 'ZSO' subobject = 'VALIDATE' ) ).
    " ... 로그 추가 로직 ...
  ENDMETHOD.
ENDCLASS.

수정 후 저장/활성화하고 abapGit 저장소 화면으로 돌아가면 "1 diff" 같은 표시가 나타난다. 여기서 Stage를 누르면 어떤 오브젝트를 커밋에 포함할지 선택하는 화면이 뜬다.

Staging 화면 예시:
  [x] zcl_so_validator.clas.abap        Local: modified
  [x] zcl_so_validator.clas.xml         Local: modified
  [ ] zcl_so_temp_debug.prog.abap       Local: new    <- 커밋 제외

Commit message:
  feat(validator): add order validation with Application Log

Author name : Hong Gildong
Author email: hong.gildong@company.com

Commit을 누르면 로컬에서 커밋 오브젝트가 생성되고, 이어서 GitHub Push까지 자동으로 진행된다. 이때 커밋 메시지는 Conventional Commits 스타일(feat/fix/docs/refactor)을 권장한다. 이후 팀원은 GitHub에서 Pull Request 리뷰를 수행하고, 리뷰 완료 후 merge된 내용을 다른 시스템에서 다시 Pull하여 반영한다.

3단계: 프로덕션 — 브랜치 전략, APACK, CI 연동

프로덕션에서는 단순한 Push만으로 부족하다. 여러 개발자가 협업하고 외부 의존성을 관리하려면 브랜치 전략과 패키지 매니페스트가 필요하다.

abapGit이 지원하는 APACK(ABAP Package Manager)는 다른 GitHub 저장소를 의존성으로 선언할 수 있게 해준다. 아래는 판매주문 프로젝트가 abap-openapi 라이브러리를 참조하는 예시다.

<?xml version="1.0" encoding="utf-8"?>
<asx:abap xmlns:asx="http://www.sap.com/abapxml" version="1.0">
 <asx:values>
  <DESCRIPTOR>
   <GROUP_ID>com.mycompany.sap</GROUP_ID>
   <ARTIFACT_ID>sales-order-mgmt</ARTIFACT_ID>
   <VERSION>1.2.0</VERSION>
   <REPOSITORY_TYPE>abapGit</REPOSITORY_TYPE>
   <GIT_URL>https://github.com/mycompany/sales-order-mgmt.git</GIT_URL>
   <DEPENDENCIES>
    <item>
     <GROUP_ID>org.abapopenapi</GROUP_ID>
     <ARTIFACT_ID>abap-openapi-client</ARTIFACT_ID>
     <GIT_URL>https://github.com/abap-openapi/abap-openapi.git</GIT_URL>
     <TARGET_PACKAGE>$OPENAPI_CLIENT</TARGET_PACKAGE>
    </item>
   </DEPENDENCIES>
  </DESCRIPTOR>
 </asx:values>
</asx:abap>

이 매니페스트를 ZIF_APACK_MANIFEST를 구현한 클래스로 등록하면 abapGit이 자동으로 의존성 저장소를 인식하고 함께 Pull한다.

.abapgit.xml 설정 파일로 폴더 로직, 시작 패키지, 무시 파일을 지정한다.

<?xml version="1.0" encoding="utf-8"?>
<asx:abap xmlns:asx="http://www.sap.com/abapxml" version="1.0">
 <asx:values>
  <DATA>
   <MASTER_LANGUAGE>E</MASTER_LANGUAGE>
   <STARTING_FOLDER>/src/</STARTING_FOLDER>
   <FOLDER_LOGIC>PREFIX</FOLDER_LOGIC>
   <IGNORE>
    <item>/.gitignore</item>
    <item>/LICENSE</item>
    <item>/README.md</item>
    <item>/package.devc.xml</item>
   </IGNORE>
  </DATA>
 </asx:values>
</asx:abap>

브랜치 전략(GitHub Flow 기반):

main: PRD 반영 완료 코드 (Protected, PR + Review 필수)
develop: DEV 시스템 활성 브랜치
feature/SO-1234-add-validator: 기능 개발용 (Jira 티켓 연동)
hotfix/SO-9999-tax-calc-bug: 긴급 수정

abapGit UI에서 Switch Branch로 브랜치 전환 후 개발하고, PR 머지 후 main으로 재전환한다. 추가로 abaplint를 GitHub Actions에 연결하면 PR마다 정적 분석이 자동 실행된다.

name: abaplint
on: [push, pull_request]
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '20'
      - run: npm install -g @abaplint/cli
      - run: abaplint

흔한 실수와 트러블슈팅 FAQ

Q1. "SSL handshake failed" 오류가 발생합니다.
GitHub SSL 인증서가 STRUST에 등록되지 않은 경우다. 브라우저에서 github.com 인증서 체인(루트 + 중간)을 .cer로 내보내 STRUST의 SSL Client SSL Client (Anonymous) PSE에 임포트하고 ICM을 재시작한다. 이후 SM59에서 HTTP 커넥션 테스트로 검증할 수 있다.

Q2. Push 시 "Authentication failed" 오류가 납니다.
2021년 8월부터 GitHub는 비밀번호 인증을 폐지했다. 반드시 Personal Access Token(PAT) 또는 SSH Deploy Key를 사용해야 한다. GitHub Settings → Developer settings → Personal access tokens에서 repo 스코프로 발급받아 비밀번호 자리에 입력한다.

Q3. "Object type xxx not supported" 메시지가 뜹니다.
BOPF, RAP Behavior Definition, 일부 커스텀 오브젝트는 abapGit 버전에 따라 미지원일 수 있다. 표준 abapGit 대신 개발자 버전(zabapgit_standalone.prog.abap의 dev 브랜치)을 사용하거나, 해당 오브젝트를 별도 패키지로 분리해 관리 대상에서 제외한다.

기타 자주 겪는 함정으로는 패키지 계층 불일치(부모 패키지가 GitHub에 없는데 서브 패키지만 Pull 시도), 번역 텍스트 누락(MASTER_LANGUAGE와 시스템 로그온 언어 불일치), DDIC 활성화 오류(테이블/도메인 순서상 종속성 문제) 등이 있다. 활성화 오류는 대개 Pull 후 SE80에서 수동으로 마스 활성화(Ctrl+F3 반복)하면 해결된다.

실무에서 abapGit 활용 패턴과 다음 확장 방향

abapGit에 익숙해졌다면 다음 단계로 확장해보자. 첫째, gCTS(git-enabled Change and Transport System)는 SAP가 공식 제공하는 Git 통합 솔루션으로 트랜스포트와 Git을 이중 관리할 수 있다. 둘째, abaplint로 코딩 규칙을 자동 검증하고 CI 파이프라인에 통합한다. 셋째, ABAP Unit + GitHub Actions로 테스트 자동화까지 확장할 수 있다. 마지막으로 SAP BTP ABAP Environment(Steampunk)로 넘어가면 abapGit 대신 abap-file-system 방식이 표준이 되므로 함께 익혀두면 좋다.

현업에서 자주 쓰이는 abapGit 활용 패턴을 정리하면 다음과 같다.

오픈소스 라이브러리 배포: abap2xlsx, cl_demo_output 같은 공개 라이브러리를 abapGit으로 바로 설치
팀 간 코드 공유: 내부 GitHub Enterprise에 공통 유틸리티 저장소 구성 후 각 프로젝트에서 Pull
코드 리뷰: PR 기반 리뷰로 TR 릴리즈 전 품질 검증 단계 추가
백업/재해 복구: 개발 오브젝트를 Git에 주기적으로 Push해 ABAP 시스템 장애 시 복원

댓글 0