아직도 STANDARD만 써? #shorts #SAP #ABAP

ABAP 내부 테이블에서 STANDARD만 쓰는 개발자의 문제

ABAP 내부 테이블에서 STANDARD TABLE만 사용하는 개발자는 성능 최적화의 기회를 놓치고 있습니다. 소규모 데이터에서는 차이를 느끼기 어렵지만, 수만 건 이상 처리하는 배치 프로그램이나 업무 로직에서는 SORTED TABLE이나 HASHED TABLE로 변경하는 것만으로도 수배에서 수십 배의 성능 향상을 얻을 수 있습니다.

왜 STANDARD만 쓰는가 — 오해 해소

" 흔한 오해: SORTED/HASHED는 쓰기 어렵다
" 현실: 선언만 다를 뿐, 사용 방법은 거의 동일

" STANDARD (기존 코드)
DATA lt_orders TYPE STANDARD TABLE OF zbtp_order WITH DEFAULT KEY.

SELECT * FROM zbtp_order INTO TABLE @lt_orders.

READ TABLE lt_orders WITH KEY order_id = 'SO001' INTO DATA(ls_order).
" → 선형 탐색 O(n): 100만 건이면 최악 100만 번 비교

" SORTED로 변경 (선언만 다름)
DATA lt_orders TYPE SORTED TABLE OF zbtp_order WITH UNIQUE KEY order_id.

SELECT * FROM zbtp_order INTO TABLE @lt_orders.

READ TABLE lt_orders WITH TABLE KEY order_id = 'SO001' INTO DATA(ls_order).
" → 이진 탐색 O(log n): 100만 건이면 최대 20번 비교
" WITH TABLE KEY 사용 시 자동으로 이진 탐색

실전 비교: 매핑 테이블에서 STANDARD vs HASHED

" 시나리오: 고객 코드를 내부 코드로 변환 (1000번 반복)
" 매핑 테이블 1만 건

" STANDARD TABLE 방식
DATA lt_map TYPE STANDARD TABLE OF zbtp_cust_mapping WITH DEFAULT KEY.
SELECT * FROM zbtp_cust_mapping INTO TABLE @lt_map.

DATA lv_count TYPE i.
DO 1000 TIMES.
  READ TABLE lt_map WITH KEY ext_code = lv_input INTO DATA(ls_map).
  " 평균 5000번 비교 × 1000회 = 500만 번
ENDDO.
" 실행 시간: ~2.3초

" HASHED TABLE 방식
DATA lt_map TYPE HASHED TABLE OF zbtp_cust_mapping
            WITH UNIQUE KEY ext_code.
SELECT * FROM zbtp_cust_mapping INTO TABLE @lt_map.

DO 1000 TIMES.
  READ TABLE lt_map WITH TABLE KEY ext_code = lv_input INTO DATA(ls_map).
  " O(1) × 1000회 = 1000번 해시 계산
ENDDO.
" 실행 시간: ~0.04초 (약 57배 빠름)

LOOP 후 수정할 때: ASSIGNING vs INTO

" INTO 방식: 복사 + 수정 + MODIFY (3단계)
LOOP AT lt_orders INTO DATA(ls_order).
  IF ls_order-status = 'OPEN'.
    ls_order-processed = 'X'.
    MODIFY lt_orders FROM ls_order.  " 추가 MODIFY 필요
  ENDIF.
ENDLOOP.

" ASSIGNING 방식: 직접 수정 (1단계, 빠름)
LOOP AT lt_orders ASSIGNING FIELD-SYMBOL().
  IF -status = 'OPEN'.
    -processed = 'X'.  " 직접 수정 (복사본 없음)
    " MODIFY 불필요
  ENDIF.
ENDLOOP.
" 대용량에서 약 30-40% 빠름

이진 탐색 활용 (STANDARD TABLE에서도 성능 향상)

" STANDARD TABLE이지만 정렬 후 이진 탐색 가능
DATA lt_orders TYPE STANDARD TABLE OF zbtp_order WITH DEFAULT KEY.
SELECT * FROM zbtp_order ORDER BY order_id INTO TABLE @lt_orders.

" BINARY SEARCH 옵션 사용 (정렬되어 있어야 함)
READ TABLE lt_orders WITH KEY order_id = 'SO001' BINARY SEARCH
     INTO DATA(ls_order).
" O(log n)으로 처리됨
" 단, 항상 KEY 필드 순서로 정렬되어 있어야 안전

용도별 최적 선택 요약

• STANDARD: 순서 유지, 중복 허용, APPEND 자주 사용, 전체 LOOP만 필요
• SORTED: 범위 검색(AT, BETWEEN), 정렬 상태 유지, 중복 제어 필요
• HASHED: 단일 키 검색을 빈번히 사용, 최고 성능 필요, 중복 불허
• 매핑 테이블(코드-값): HASHED 항상 유리
• 정렬 출력이 필요한 리스트: SORTED (SORT 구문 불필요)

공식 문서

ABAP 내부 테이블 성능 가이드는 ABAP Keyword Documentation — Internal Tables Performance에서 확인하세요.