왜 내부 테이블 타입이 면접 단골 문제인가
SAP ABAP에서 내부 테이블(Internal Table)은 가장 자주 사용하는 데이터 구조입니다. 세 가지 타입(STANDARD, SORTED, HASHED)의 차이를 모르면 대용량 데이터 처리 시 심각한 성능 문제가 발생합니다. 면접에서 이 질문이 나오면 단순히 차이를 말하는 것을 넘어, 언제 어떤 타입을 선택해야 하는지 설명할 수 있어야 합니다.
STANDARD TABLE: 순서 보장, 중복 허용
DATA: lt_orders TYPE STANDARD TABLE OF zbtp_order_item
WITH DEFAULT KEY,
ls_order TYPE zbtp_order_item.
" 순서대로 APPEND
APPEND VALUE #( order_id = 'SO001' item_no = 10 product = 'LAPTOP' qty = 2 )
TO lt_orders.
APPEND VALUE #( order_id = 'SO001' item_no = 20 product = 'MOUSE' qty = 5 )
TO lt_orders.
" 선형 검색 (READ TABLE ... WITH KEY)
READ TABLE lt_orders
WITH KEY order_id = 'SO001' item_no = 20
INTO DATA(ls_item).
" 100만 건에서 READ TABLE: O(n) — 느림
STANDARD TABLE은 인덱스나 해시가 없어 READ TABLE이 항상 선형 검색(O(n))입니다. 데이터가 많을수록 느려집니다. 순서가 중요하거나 중복 허용이 필요할 때, 혹은 전체 LOOP 처리만 할 때 적합합니다.
SORTED TABLE: 자동 정렬, 이진 탐색
DATA: lt_products TYPE SORTED TABLE OF zbtp_product
WITH UNIQUE KEY product_id.
" INSERT 시 자동 정렬 유지
INSERT VALUE #( product_id = 'P003' name = 'USB Hub' price = '15000' )
INTO TABLE lt_products.
INSERT VALUE #( product_id = 'P001' name = 'Keyboard' price = '45000' )
INTO TABLE lt_products.
" 결과는 P001, P003 순으로 정렬된 상태
" 이진 탐색: O(log n)
READ TABLE lt_products
WITH TABLE KEY product_id = 'P001'
INTO DATA(ls_prod).
" 100만 건에서 READ TABLE: O(log n) — 빠름SORTED TABLE은 INSERT 시 자동으로 KEY 순서로 정렬됩니다. READ TABLE WITH TABLE KEY가 이진 탐색으로 O(log n)입니다. 데이터를 정렬된 상태로 유지해야 하거나, 범위 검색(BETWEEN)이 필요할 때 적합합니다.
HASHED TABLE: 해시 기반, 최고 속도
DATA: lt_config TYPE HASHED TABLE OF zbtp_config
WITH UNIQUE KEY config_key.
" INSERT: 해시 계산 후 저장
INSERT VALUE #( config_key = 'MAX_RETRY' config_value = '3' )
INTO TABLE lt_config.
INSERT VALUE #( config_key = 'TIMEOUT_SEC' config_value = '30' )
INTO TABLE lt_config.
" 해시 검색: O(1) — 건수 무관하게 일정 시간
READ TABLE lt_config
WITH TABLE KEY config_key = 'MAX_RETRY'
INTO DATA(ls_cfg).
IF sy-subrc = 0.
DATA(lv_max_retry) = CONV i( ls_cfg-config_value ).
ENDIF.
HASHED TABLE은 READ TABLE이 O(1)로 가장 빠릅니다. 단, UNIQUE KEY만 가능하고, LOOP 순서가 보장되지 않으며, APPEND/INSERT INTO INDEX가 불가합니다. KEY로 빈번한 단일 검색이 필요한 경우(설정값 조회, 코드 매핑 테이블)에 최적입니다.
성능 비교: 실전 케이스
" 시나리오: 100만 건 재고 테이블에서 상품별 조회
" 케이스 A: STANDARD TABLE (잘못된 선택)
DATA lt_stock_std TYPE STANDARD TABLE OF zbtp_stock WITH DEFAULT KEY.
SELECT * FROM zbtp_stock INTO TABLE @lt_stock_std.
DO 1000 TIMES.
" 매번 O(n) 선형 검색 — 1000 * 1,000,000 = 10억 번 비교
READ TABLE lt_stock_std WITH KEY product_id = lv_pid INTO DATA(ls).
ENDDO.
" 케이스 B: HASHED TABLE (올바른 선택)
DATA lt_stock_hash TYPE HASHED TABLE OF zbtp_stock
WITH UNIQUE KEY product_id.
SELECT * FROM zbtp_stock INTO TABLE @lt_stock_hash.
DO 1000 TIMES.
" 매번 O(1) — 1000번만 실행
READ TABLE lt_stock_hash WITH TABLE KEY product_id = lv_pid INTO DATA(ls).
ENDDO.
LOOP에서 ASSIGNING을 쓰는 이유
" 대량 수정 시: LOOP ... ASSIGNING이 INTO보다 빠름
LOOP AT lt_orders ASSIGNING FIELD-SYMBOL(<ls_order>).
IF <ls_order>-qty > 100.
<ls_order>-discount_rate = '10.00'. " 직접 수정 (복사 없음)
ENDIF.
ENDLOOP.
" INTO는 행을 복사해서 수정 후 다시 저장해야 함 — 오버헤드 발생
LOOP AT lt_orders INTO DATA(ls_order).
IF ls_order-qty > 100.
ls_order-discount_rate = '10.00'.
MODIFY lt_orders FROM ls_order. " 추가 MODIFY 필요
ENDIF.
ENDLOOP.
면접 모범 답변 요약
- STANDARD: 순서 중요, LOOP만 사용, 중복 허용 필요 시
- SORTED: 정렬 상태 유지 + 범위 검색 필요 시, O(log n)
- HASHED: KEY로만 단일 검색, 중복 불허, O(1) 최고 성능
- 대용량 데이터에서 READ TABLE을 빈번히 하면 반드시 SORTED 또는 HASHED 선택
공식 문서
내부 테이블 타입 전체 설명은 ABAP Keyword Documentation — Internal Tables에서 확인하세요.
댓글 0
아직 댓글이 없습니다.