UI5 모드
BTP

Joule로 ABAP 리뷰, 실수 3가지 #shorts #SAP #Joule

수정: 2026년 8월 19일 👁 0 · ♥ 0
▶ YouTube에서 보기

개요: Joule로 ABAP 코드 리뷰를 자동화한다는 것

코드 리뷰는 ABAP 팀의 품질을 지키는 마지막 관문이지만, 리뷰어의 시간과 컨디션에 따라 품질 편차가 큰 작업이기도 합니다. SAP의 생성형 AI 코파일럿인 Joule은 ABAP Development Tools(ADT) 안에서 코드 설명, 개선 제안, 단위 테스트 생성 등을 지원하며, 이를 리뷰 프로세스에 얹으면 "사람은 설계 리뷰, AI는 패턴 리뷰"라는 분업이 가능해집니다. 이 글에서는 창작 시나리오인 재고이동전표 처리 클래스를 소재로, Joule 기반 리뷰 자동화를 단계별로 살펴봅니다.

  • Joule for Developers가 ADT 안에서 동작하는 원리 이해
  • 기본 리뷰 요청 → 실무 리뷰 프롬프트 → ATC 연계 리뷰 파이프라인 구성
  • 실무 도입 시 흔한 실수 3가지와 회피 전략 습득

시작 전에 갖추면 좋은 배경

ABAP OO(클래스, 인터페이스)와 최신 ABAP 문법(인라인 선언, 문자열 템플릿)에 익숙하고, ADT(Eclipse)를 일상적으로 사용해 본 경험이 있으면 충분합니다. ATC(ABAP Test Cockpit)로 정적 검사를 돌려본 경험이 있다면 5단계 파이프라인 구성이 훨씬 수월합니다. ABAP Cloud 개발 모델의 기본 개념(released API, Tier 구분)을 알고 있으면 Joule의 제안을 평가할 때 도움이 됩니다.

환경 구성과 준비물

Joule의 ABAP 개발 지원은 클라우드 계열 환경에서 제공되는 것이 일반적입니다. 이 글은 다음 조합을 기준으로 합니다.

  • SAP BTP ABAP Environment(또는 SAP S/4HANA Cloud Public Edition의 ABAP 환경) — 비교적 최신 릴리스 권장
  • ABAP Development Tools for Eclipse 최신 버전 — Joule 통합 기능이 지속적으로 갱신되므로 업데이트 유지가 권장됩니다
  • Joule 활성화 — 관리자가 해당 ABAP 환경에서 AI 기능 사용을 설정하고, 라이선스(AI 소비 단위 포함)가 준비되어야 합니다
  • Git 기반 형상 관리(gCTS 또는 abapGit) — 리뷰 결과를 PR 코멘트로 남기는 운영을 위해 권장

온프레미스 클래식 환경에서는 동일한 기능 범위가 보장되지 않으므로, 도입 전 자사 릴리스에서 지원 범위를 확인하는 절차가 필요합니다.

동작 원리 한눈에 보기: Joule은 리뷰어가 아니라 "패턴 감별사"

Joule을 시니어 리뷰어로 착각하면 도입이 실패합니다. 정확한 비유는 공항 보안 검색대입니다. 검색대는 위험물의 "패턴"을 빠르고 일관되게 잡아내지만, 승객의 여행 목적이 타당한지는 판단하지 않습니다. Joule도 마찬가지로 SELECT 루프, 예외 삼킴, 하드코딩 같은 패턴 수준의 문제를 잘 찾아내지만, "이 정산 로직이 회계팀 요구사항에 맞는가" 같은 도메인 판단은 하지 못합니다.

기술적으로 Joule은 ADT에서 선택한 코드와 개발자의 자연어 프롬프트를 컨텍스트로 묶어 SAP가 운영하는 생성형 AI 백엔드에 전달하고, ABAP에 특화된 응답(설명, 개선안, 테스트 코드)을 돌려줍니다. 흐름을 도식화하면 다음과 같습니다.

# Joule 기반 리뷰 흐름 (개념도)
developer:
  - ADT에서 클래스/메서드 선택
  - 리뷰 프롬프트 입력 ("성능 관점에서 검토해줘")
joule:
  - 코드 + 프롬프트 → AI 백엔드 전달
  - 패턴 분석 결과 반환 (설명 / 개선안 / 테스트 초안)
team_process:
  - ATC 결과와 교차 확인
  - 사람 리뷰어가 도메인 판단 후 머지

핵심은 마지막 단계입니다. Joule의 출력은 제안이며, 확정은 언제나 사람과 ATC 같은 결정적(deterministic) 도구가 담당하는 구조가 일반적으로 권장됩니다. ATC가 "규칙 기반 벌금 딱지"라면 Joule은 "맥락을 읽는 코치"로, 둘은 대체재가 아니라 보완재입니다.

실전 예제: 재고이동전표 클래스 리뷰 3단계

창작 시나리오로 물류팀의 재고이동전표 전기 클래스 ZCL_WMX_TRANSFER_POSTING을 준비했습니다. 창고 간 이동 요청(ZWMX_TRF_REQ 테이블)을 읽어 전표를 생성하는 로직입니다.

1단계 — 기본: 문제 코드에 리뷰 요청하기

아래는 신입 개발자가 작성했다고 가정한, 전형적인 문제를 품은 코드입니다.

CLASS zcl_wmx_transfer_posting DEFINITION PUBLIC FINAL CREATE PUBLIC.
  PUBLIC SECTION.
    METHODS post_transfers
      IMPORTING iv_plant TYPE zwmx_plant_id
      RETURNING VALUE(rv_count) TYPE i.
ENDCLASS.

CLASS zcl_wmx_transfer_posting IMPLEMENTATION.
  METHOD post_transfers.
    SELECT * FROM zwmx_trf_req
      WHERE plant = @iv_plant AND status = 'N'
      INTO TABLE @DATA(lt_req).

    LOOP AT lt_req INTO DATA(ls_req).
      " 요청 건별로 자재 정보 재조회 (루프 내 SELECT!)
      SELECT SINGLE unit FROM zwmx_material
        WHERE matnr = @ls_req-matnr INTO @DATA(lv_unit).
      TRY.
          " 전표 생성 후 카운트
          rv_count = rv_count + 1.
        CATCH cx_root.  " 예외를 조용히 삼킴
      ENDTRY.
    ENDLOOP.
  ENDMETHOD.
ENDCLASS.

ADT에서 이 메서드를 선택한 뒤 Joule 패널에 이렇게 요청합니다.

"post_transfers 메서드를 성능과 예외 처리 관점에서 리뷰하고, 문제점을 심각도 순으로 나열해줘."

일반적으로 Joule은 (1) 루프 내 SELECT SINGLE로 인한 N+1 조회, (2) cx_root를 잡고 무시하는 예외 삼킴, (3) 상태값 'N' 하드코딩을 지적하고, FOR ALL ENTRIES 대신 조인이나 내부 테이블 선조회를 제안하는 응답을 돌려줍니다.

2단계 — 실무: 팀 리뷰 규칙을 프롬프트에 녹이기

실무에서는 팀마다 리뷰 기준이 다릅니다. 이를 재사용 가능한 리뷰 프롬프트 템플릿으로 표준화하는 것이 핵심 활용 팁입니다.

" 팀 리뷰 프롬프트 템플릿 (위키/저장소에 보관)
" 1) 성능: 루프 내 DB 접근, SELECT *, 불필요한 정렬 여부
" 2) 예외: cx_root 캐치 금지, 로깅 없는 CATCH 금지
" 3) 로깅: 실패 건은 zif_wmx_app_log 인터페이스로 기록했는가
" 4) ABAP Cloud: released API만 사용했는가

Joule의 제안을 반영해 개선한 코드는 다음과 같습니다.

METHOD post_transfers.
  SELECT r~req_id, r~matnr, m~unit
    FROM zwmx_trf_req AS r
    INNER JOIN zwmx_material AS m ON m~matnr = r~matnr
    WHERE r~plant = @iv_plant
      AND r~status = @zif_wmx_const=>c_status-new
    INTO TABLE @DATA(lt_req).

  LOOP AT lt_req INTO DATA(ls_req).
    TRY.
        mo_doc_builder->create( ls_req ).
        rv_count += 1.
      CATCH zcx_wmx_posting_error INTO DATA(lx_err).
        mo_log->add_error( iv_req_id = ls_req-req_id
                           ix_error  = lx_err ).
    ENDTRY.
  ENDLOOP.
ENDMETHOD.

조인으로 N+1 문제를 제거했고, 상수 인터페이스로 하드코딩을 없앴으며, 도메인 예외만 잡아 애플리케이션 로그에 남깁니다. 이 "Joule 지적 → 수정 → 재검토 요청" 루프를 커밋 전에 한 번 돌리는 것만으로 리뷰어의 반복 코멘트가 크게 줄어듭니다.

3단계 — 프로덕션: 테스트 생성과 ATC 게이트 결합

프로덕션 수준에서는 Joule에게 단위 테스트 초안 생성을 맡기고, 최종 게이트는 ATC로 잠급니다. Joule에 "post_transfers에 대한 ABAP Unit 테스트를 생성해줘. DB 의존성은 테스트 더블로 격리해줘"라고 요청하면 다음과 유사한 골격을 얻을 수 있습니다.

CLASS ltc_transfer_posting DEFINITION FINAL FOR TESTING
  DURATION SHORT RISK LEVEL HARMLESS.
  PRIVATE SECTION.
    DATA mo_cut TYPE REF TO zcl_wmx_transfer_posting.
    DATA mo_env TYPE REF TO if_osql_test_environment.
    METHODS setup.
    METHODS count_only_new_requests FOR TESTING.
ENDCLASS.

CLASS ltc_transfer_posting IMPLEMENTATION.
  METHOD setup.
    mo_env = cl_osql_test_environment=>create(
               i_dependency_list = VALUE #( ( 'ZWMX_TRF_REQ' )
                                            ( 'ZWMX_MATERIAL' ) ) ).
    mo_env->insert_test_data( VALUE zwmx_trf_req_tab(
      ( req_id = '1001' plant = 'P100' status = 'N' matnr = 'MAT01' )
      ( req_id = '1002' plant = 'P100' status = 'D' matnr = 'MAT02' ) ) ).
    mo_cut = NEW #( ).
  ENDMETHOD.

  METHOD count_only_new_requests.
    cl_abap_unit_assert=>assert_equals(
      act = mo_cut->post_transfers( 'P100' )
      exp = 1 ).  " 'N' 상태 1건만 처리
  ENDMETHOD.
ENDCLASS.

생성된 테스트는 반드시 사람이 검증 후 커밋합니다. 여기에 전송 릴리스 시점의 ATC 필수 실행(성능·보안 체크 변형 포함)을 걸어두면 "Joule 사전 리뷰 → 사람 리뷰 → ATC 게이트"라는 3중 방어선이 완성됩니다. 보안 관점에서는 사내 민감 데이터(실운영 고객 데이터가 포함된 코드 주석 등)를 프롬프트에 붙여넣지 않는 가이드도 함께 배포하는 것이 권장됩니다.

도입 시 흔한 실수와 트러블슈팅 FAQ

angle의 핵심인 실무 실수를 짚어봅니다. 현장에서 가장 자주 보이는 패턴은 세 가지입니다.

  • 실수 1: Joule 출력을 무검증 머지. 생성형 AI는 존재하지 않는 API나 구버전 문법을 제안할 수 있습니다. 특히 ABAP Cloud 환경에서 released되지 않은 오브젝트를 제안하는 경우가 있으므로, 문법 체크와 ATC를 통과하기 전에는 "초안"으로만 취급해야 합니다.
  • 실수 2: 컨텍스트 없는 뭉텅이 요청. 클래스 전체 2,000줄을 던지고 "리뷰해줘"라고 하면 피상적인 답이 옵니다. 메서드 단위로 쪼개고, 목적("이 메서드는 야간 배치에서 10만 건 처리")을 프롬프트에 명시할수록 품질이 올라갑니다.
  • 실수 3: ATC를 Joule로 대체하려는 시도. AI 응답은 비결정적이라 같은 코드에 다른 답이 나올 수 있습니다. 규정 준수·릴리스 차단 판정은 ATC에, 맥락 해석과 개선 제안은 Joule에 맡기는 역할 분리가 일반적으로 권장됩니다.

FAQ 1. Joule 패널이 ADT에 보이지 않아요. ADT 버전이 오래됐거나 대상 ABAP 환경에서 AI 기능이 활성화되지 않은 경우가 대부분입니다. Eclipse 업데이트 후 관리자에게 Joule 설정과 라이선스 할당 여부를 확인하세요.

FAQ 2. 응답이 영어로만 나옵니다. 프롬프트를 한국어로 작성하고 "한국어로 답해줘"를 덧붙이면 대체로 해결됩니다. 다만 기술 용어는 영어 원문을 유지하는 편이 팀 내 의사소통에 유리합니다.

FAQ 3. 리뷰 제안이 매번 달라져서 기준을 못 잡겠어요. 정상 동작입니다. 팀 표준 프롬프트 템플릿을 고정하고, 최종 판정 기준은 ATC 체크 변형에 두면 편차 문제를 프로세스로 흡수할 수 있습니다.

여기서 더 나아가기

리뷰 자동화가 자리 잡았다면 다음 주제로 확장해 보세요. (1) Joule의 코드 생성 기능으로 RAP 비헤이비어 구현 골격을 만들고 리뷰 루프에 태우는 방법, (2) gCTS 기반 브랜치 전략과 결합해 PR 단위로 사전 리뷰 체크리스트를 운용하는 방법, (3) SAP Build Code에서 Joule을 활용한 풀스택(CAP + Fiori) 개발 지원, (4) ATC 커스텀 체크를 만들어 팀 고유 규칙을 결정적 게이트로 승격하는 방법이 자연스러운 다음 여정입니다.

댓글 0

아직 댓글이 없습니다.