SAP

CCMT 없이 S/4HANA 이관하면 큰일 나는 이유 #shorts #SAP #S4HANA

S/4HANA 이관에서 커스텀 코드가 가장 큰 위험인 이유

S/4HANA 전환 프로젝트에서 예산 초과와 일정 지연의 가장 흔한 원인은 표준 기능이 아니라 수십 년간 쌓인 커스텀 ABAP 코드입니다. ECC 시절 작성된 Z 프로그램은 S/4HANA에서 사라진 테이블(KONV, VBUK 등)을 직접 조회하거나, 40자로 확장된 자재번호(MATNR)를 18자 고정으로 가정하는 등 눈에 보이지 않는 비호환 지점을 품고 있습니다. 이 글에서는 Custom Code Migration Tool(이하 CCMT, Fiori 앱 명칭은 Custom Code Migration)을 활용해 비호환 코드를 자동 분석하고 수정 우선순위를 정하는 전 과정을 다룹니다.

이 글을 끝까지 읽으면 다음을 할 수 있게 됩니다.

  • CCMT의 동작 원리(ATC 원격 분석 + Simplification Database) 이해
  • 실제 스캔 실행과 결과(Finding) 해석
  • 비호환 패턴별 코드 수정 전략 수립
  • 비즈니스 임팩트 × 기술 복잡도 기반 우선순위 매트릭스 작성
  • 이관 전 커스텀 코드 정리(스코핑) 체크리스트 실행

이 글을 읽기 전에 알아두면 좋은 것

ABAP 개발 경험(Open SQL, 함수 모듈, 데이터 딕셔너리)과 ATC(ABAP Test Cockpit) 기본 사용법을 알고 있다는 전제로 설명합니다. S/4HANA Simplification Item 개념(예: 가격 조건 테이블 KONV → PRCD_ELEMENTS 통합)을 한 번이라도 접해봤다면 이해가 훨씬 빠릅니다. RFC 연결 구성 등 Basis 기초 지식도 일부 필요합니다.

환경 구성과 준비물 — 어떤 시스템에서 무엇을 돌리는가

CCMT 분석은 중앙 체크 시스템대상(ECC) 시스템을 원격으로 검사하는 구조입니다. 일반적으로 다음 조합이 권장됩니다.

  • 중앙 체크 시스템: SAP BTP ABAP Environment(Steampunk) 또는 SAP S/4HANA 2021 이상 온프레미스 — Fiori 앱 Custom Code Migration 실행 주체
  • 분석 대상 시스템: SAP ECC 6.0(NetWeaver 7.0 이상) — SAP Note 2436688 기반 원격 스텁(remote stub) 사전 적용 필요
  • 연결: 대상 시스템으로의 RFC Destination(온프레미스 중앙 시스템) 또는 Cloud Connector 경유(BTP ABAP Environment)
  • Simplification Database: SAP Note 2241080 절차에 따라 최신 콘텐츠를 중앙 시스템에 주기적으로 업데이트
  • 사용 데이터(선택이지만 강력 권장): 대상 시스템에서 SUSG(집계된 사용 데이터) 또는 SCMON을 최소 3~12개월 수집

참고로 과거에는 Solution Manager 7.2의 CDMC/커스텀 코드 분석을 쓰는 사례가 많았지만, 최근에는 Fiori 기반 Custom Code Migration 앱이 표준적인 접근으로 자리잡았습니다. SolMan 기반 사용 통계(UPL)를 이미 수집 중이라면 그 데이터를 스코핑 근거로 재활용할 수 있습니다.

핵심 개념 — CCMT는 어떻게 비호환 코드를 찾아내는가

CCMT를 비유하자면 이사 전 짐 정리 컨설턴트입니다. 새 집(S/4HANA)에 들어가지 않는 가구(비호환 코드)를 목록화하고, 지난 1년간 한 번도 쓰지 않은 짐(미사용 코드)은 버리라고 제안하며, 남길 짐에는 수리 견적(수정 난이도)을 붙여줍니다. 내부 동작은 세 축으로 구성됩니다.

  1. ATC 원격 분석(Remote Code Analysis): 중앙 시스템의 ATC가 RFC로 대상 시스템의 커스텀 코드를 읽어와 검사합니다. 대상 ECC를 업그레이드하지 않고도 최신 체크 로직을 적용할 수 있다는 점이 핵심입니다. 체크 변형(check variant)은 S4HANA_READINESS 계열을 사용합니다.
  2. Simplification Database: S/4HANA에서 변경·삭제·대체된 오브젝트 목록(Simplification Item)을 담은 데이터베이스입니다. ATC는 커스텀 코드가 참조하는 표준 오브젝트를 이 DB와 대조해 "이 테이블은 S/4HANA에서 사라졌다", "이 FM은 대체되었다" 같은 Finding을 생성하고, 관련 SAP Note 번호를 함께 제시합니다.
  3. 스코핑(Scoping)과 사용 분석: SUSG/SCMON 사용 데이터를 결합하면 "실제로 실행되는 코드"만 분석 범위에 넣을 수 있습니다. 일반적으로 커스텀 코드의 30~60%는 미사용 상태로 보고되는데, 이 코드는 수정 대상이 아니라 삭제 후보가 됩니다. 고치지 않아도 되는 코드를 걸러내는 것이 CCMT 활용의 절반입니다.

Finding에는 우선순위(1~3), 관련 Simplification Item, 참조 Note, 그리고 상당수 패턴에 대해 Quick Fix(ADT 자동 수정) 가능 여부가 표시됩니다. 즉 CCMT는 "무엇이 문제인가"뿐 아니라 "얼마나 기계적으로 고칠 수 있는가"까지 알려주는 도구입니다.

실전 예제 — 스캔 실행부터 코드 수정까지 3단계

1단계: 분석 프로젝트 생성과 첫 스캔

Custom Code Migration 앱에서 프로젝트를 만들고 대상 시스템 Destination을 지정하면, 분석 범위(커스텀 패키지)가 자동 수집되고 ATC 실행이 예약됩니다. 결과 화면에서는 Finding이 Simplification Item별로 그룹핑됩니다. 예를 들어 판매 문서 상태를 다루는 아래와 같은 레거시 코드는 즉시 검출됩니다.

" ECC 시절 코드: VBUK(판매문서 헤더 상태)를 직접 조회" S/4HANA에서는 VBUK/VBUP가 VBAK/VBAP의 상태 필드로 통합됨SELECT SINGLE gbstk FROM vbuk  INTO @DATA(lv_overall_status)  WHERE vbeln = @lv_sales_order." CCMT Finding: Simplification Item "SD Document Status" 매칭" 권장 수정: VBAK에서 직접 조회SELECT SINGLE gbstk FROM vbak  INTO @lv_overall_status  WHERE vbeln = @lv_sales_order.

이런 단순 테이블 치환 유형은 Quick Fix 대상으로 분류되어, ADT(Eclipse)에서 일괄 적용이 가능합니다.

2단계: 실무 시나리오 — 사라진 테이블(KONV) 대응과 에러 처리

가격 조건 테이블 KONV는 S/4HANA에서 PRCD_ELEMENTS로 대체되었습니다. 단순 치환처럼 보이지만 키 구조가 다르기 때문에(클라이언트 필드 추가 등) 호환 뷰에 의존하지 말고 명시적으로 재작성하는 편이 안전합니다. 예외 처리와 애플리케이션 로그를 포함한 수정 예시는 다음과 같습니다.

CLASS zcl_price_reader DEFINITION PUBLIC FINAL CREATE PUBLIC.  PUBLIC SECTION.    METHODS get_discount_amount      IMPORTING iv_pricing_doc      TYPE knumv      RETURNING VALUE(rv_amount)    TYPE prcd_elements-kwert      RAISING   zcx_pricing_not_found.ENDCLASS.CLASS zcl_price_reader IMPLEMENTATION.  METHOD get_discount_amount.    " KONV → PRCD_ELEMENTS: 필요한 필드만 명시적으로 조회    SELECT SINGLE kwert      FROM prcd_elements      WHERE knumv = @iv_pricing_doc        AND kschl = 'ZDIS'          " 커스텀 할인 조건        AND kinak = @space          " 비활성 조건 제외      INTO @rv_amount.    IF sy-subrc <> 0.      " 애플리케이션 로그 기록 후 예외 전파      DATA(lo_log) = cl_bali_log=>create_with_header(        header = cl_bali_header_setter=>create(                   object    = 'ZPRICING'                   subobject = 'MIGRATION' ) ).      lo_log->add_item( cl_bali_message_setter=>create(        severity   = if_bali_constants=>c_severity_error        id         = 'ZPRC'        number     = '001'        variable_1 = CONV #( iv_pricing_doc ) ) ).      RAISE EXCEPTION TYPE zcx_pricing_not_found        EXPORTING pricing_doc = iv_pricing_doc.    ENDIF.  ENDMETHOD.ENDCLASS.

포인트는 세 가지입니다. 조회 실패를 조용히 넘기지 않고 예외로 전파할 것, 로그를 남겨 이관 후 회귀 검증 시 추적 가능하게 할 것, 그리고 SELECT * 대신 필요한 필드만 명시할 것.

3단계: 프로덕션 품질 — 암묵적 정렬 제거와 테스트 격리

HANA로 DB가 바뀌면 결과 정렬 순서를 더 이상 암묵적으로 기대할 수 없습니다. S4HANA_READINESS 변형은 이런 "기능적 DB 의존" 패턴도 검출합니다. 아래는 정렬을 명시하고, 테스트 더블로 단위 테스트를 격리한 예시입니다.

" 수정 전(위험): BINARY SEARCH가 DB 정렬 순서에 암묵적으로 의존" 수정 후: ORDER BY PRIMARY KEY 명시SELECT vbeln, posnr, matnr, kwmeng  FROM vbap  WHERE vbeln IN @lt_order_range  ORDER BY PRIMARY KEY  INTO TABLE @DATA(lt_items).READ TABLE lt_items INTO DATA(ls_item)  WITH KEY vbeln = lv_order posnr = lv_item BINARY SEARCH.
" 단위 테스트: 실제 DB 없이 검증 (Open SQL Test Double Framework)CLASS ltc_price_reader DEFINITION FINAL FOR TESTING  DURATION SHORT RISK LEVEL HARMLESS.  PRIVATE SECTION.    CLASS-DATA go_environment TYPE REF TO if_osql_test_environment.    METHODS discount_found FOR TESTING RAISING cx_static_check.ENDCLASS.CLASS ltc_price_reader IMPLEMENTATION.  METHOD discount_found.    go_environment = cl_osql_test_environment=>create(                       VALUE #( ( 'PRCD_ELEMENTS' ) ) ).    DATA lt_prices TYPE STANDARD TABLE OF prcd_elements.    lt_prices = VALUE #( ( knumv = '0000012345'                           kschl = 'ZDIS'                           kwert = '150.00' ) ).    go_environment->insert_test_data( lt_prices ).    DATA(lv_amount) = NEW zcl_price_reader(                        )->get_discount_amount( '0000012345' ).    cl_abap_unit_assert=>assert_equals(      act = lv_amount      exp = '150.00' ).    go_environment->destroy( ).  ENDMETHOD.ENDCLASS.

수정한 코드에 이런 테스트를 붙여두면 이관 리허설(Mock Cutover)마다 회귀 검증을 자동화할 수 있어, 수정 작업 자체가 새 결함을 만드는 위험을 줄입니다. 보안 관점에서는 원격 분석용 RFC 사용자에게 분석에 필요한 최소 권한만 부여하는 것이 권장됩니다.

비호환 패턴별 수정 전략 요약

패턴대표 사례전략
사라진 테이블KONV, VBUK/VBUP, ANEK/ANEP후속 테이블(PRCD_ELEMENTS, VBAK 상태 필드, ACDOCA)로 재작성. 호환 뷰 의존은 임시 조치로만
필드 길이 확장MATNR 18→40자, 금액 필드 확장하드코딩된 CHAR18 선언·오프셋 연산 제거, 딕셔너리 타입 참조로 전환
Deprecated FM구형 BAPI, 내부용 FM 직접 호출후속 API(릴리스된 CDS 뷰/클래스)로 매핑, 관련 Note 지침 확인
암묵적 정렬 의존ORDER BY 없는 SELECT + BINARY SEARCHORDER BY 명시 또는 SORT 추가
SELECT *넓은 테이블 전체 필드 조회필드 리스트 명시 — HANA 컬럼 스토어 특성상 성능 차이가 큼

우선순위 매트릭스 — 무엇부터 고칠 것인가

Finding 수천 건을 순서 없이 고치면 프로젝트가 표류합니다. 비즈니스 임팩트(사용 빈도·업무 중요도)기술 복잡도(수정 난이도) 두 축으로 분류하는 방식이 일반적입니다.

  • A(고임팩트 × 저복잡도): 사용 빈도 높은 프로그램의 Quick Fix 대상 — 즉시 일괄 처리
  • B(고임팩트 × 고복잡도): 핵심 업무 프로그램의 구조적 재작성(KONV류) — 전담 개발자 배정, 이관 전 완료 필수
  • C(저임팩트 × 저복잡도): 사용 빈도 낮은 코드의 단순 수정 — 여유 리소스로 처리
  • D(저임팩트 × 고복잡도): 미사용에 가까운 복잡 코드 — 수정 대신 폐기(decommission) 검토

임팩트 판단 근거가 바로 SUSG/SCMON 사용 데이터입니다. 사용 데이터 없이 우선순위를 정하는 것은 감으로 짐을 싸는 것과 같습니다. CCMT의 스코핑 화면에서 사용 데이터를 업로드하면 오브젝트 단위로 실행 횟수가 표시되어 이 분류를 반쯤 자동화할 수 있습니다.

흔한 실수와 트러블슈팅

Q1. 원격 ATC 실행 시 대상 시스템에서 오류가 나거나 Finding이 비어 있습니다.

대상 ECC에 SAP Note 2436688 기반 원격 스텁이 적용되지 않았거나 버전이 낮은 경우가 대부분입니다. 스텁 관련 Note를 최신으로 반영하고 RFC 사용자 권한을 확인하세요. Simplification Database 콘텐츠가 오래된 경우에도 검출 누락이 발생하므로 분석 직전 업데이트가 권장됩니다.

Q2. Finding이 수만 건인데 전부 고쳐야 하나요?

아닙니다. 가장 흔한 실수가 "전건 수정" 접근입니다. 먼저 사용 데이터로 스코핑해 미사용 코드를 제외하면 일반적으로 대상이 절반 이하로 줄어듭니다. 남은 것 중 우선순위 1(이관 전 필수 수정)과 2~3(이관 후 점진 개선 가능)을 구분해 계획하세요.

Q3. Quick Fix를 일괄 적용했는데 런타임 오류가 생겼습니다.

Quick Fix는 구문 호환성을 맞춰줄 뿐 의미적 동등성까지 확인해 주지는 않습니다. 특히 데이터 모델 변경(KONV → PRCD_ELEMENTS)이 얽힌 수정은 반드시 단위 테스트와 통합 테스트로 검증해야 합니다.

Q4. 사용 데이터 수집 기간이 짧으면 어떤 문제가 있나요?

월말 결산, 연말 처리처럼 주기적으로만 실행되는 프로그램이 "미사용"으로 오분류됩니다. 최소 3개월, 가능하면 결산 주기를 포함한 12개월 수집이 권장됩니다. CCMT 없이 이관한 프로젝트의 전형적 실패 패턴 — 컷오버 후 첫 월말 결산에서 삭제된 Z 프로그램이 덤프를 내고, 임시 복구에 수 주를 쓰는 사고 — 가 바로 여기서 나옵니다.

이후 학습 방향과 연계 주제

CCMT로 비호환 코드를 정리했다면, 다음은 Clean Core 관점의 재설계입니다. 수정 대상 코드 중 확장 성격이 강한 것은 ABAP Cloud 개발 모델(RAP, 릴리스된 API)로 옮기는 것을 검토할 수 있습니다. ATC의 ABAP_CLOUD_READINESS 변형으로 클라우드 적합성을 추가 측정하고, SAP Readiness Check로 커스텀 코드 외 영역(Simplification Item, 애드온, 사이징)까지 종합 평가하는 흐름으로 확장해 보세요. Custom Code Lifecycle Management(CCLM)를 도입하면 이관 이후에도 미사용 코드가 다시 쌓이는 것을 막을 수 있습니다.

더 읽어볼 자료

댓글 0

아직 댓글이 없습니다.