Clean ABAP ③ 내부 테이블 잘 쓰는 법: 키, 읽기, 루프

3줄 요약

• STANDARD·SORTED·HASHED는 데이터 양과 조회·변경 방식에 맞춰 선택해요.

• 정렬이나 조회에 필요한 키를 직접 지정해요. 키가 필요 없는 표준 테이블에는 EMPTY KEY를 써요.

• 행의 존재 여부, 한 행의 값, 조건에 맞는 여러 행 중 무엇이 필요한지에 따라 조회 문장을 골라요.

어떤 상황에서 쓰나요

내부 테이블을 선언할 때 종류와 키를 어떻게 정했는지에 따라 조회 방식과 성능이 달라져요. 이번 글에서는 Clean ABAP이 제안하는 선택 기준을 살펴보고, 존재 여부 확인·한 행 조회·반복 처리에 맞는 문장을 구분해 봐요.

행이 있는지만 알면 되는지, 한 행의 값이 필요한지, 여러 행을 처리할지부터 구분해 보세요. 같은 내부 테이블도 목적에 따라 아래처럼 다른 방식으로 읽습니다.

핵심 내용

테이블 종류 고르기 (가이드 스스로 "대략적인 지침"이라고 말해요)

• HASHED: 큰 테이블, 한 번에 채움, 거의 수정 안 함, 키로 자주 읽음. 데이터를 변경할 때는 해시 관리 비용도 발생하므로 자주 바뀌는 테이블에는 맞지 않아요. 데이터가 많고 키로 조회하는 작업이 잦을 때 조회 성능의 이점을 얻기 쉬워요.

• SORTED: 큰 테이블, 항상 정렬돼 있어야 함, 조금씩 채우거나 수정함, 전체 키나 부분 키로 자주 읽음. 새 행을 넣을 때는 정렬 위치를 찾고 인덱스를 유지하는 비용도 고려해야 해요.

• STANDARD: 작은 테이블, 순서가 상관없거나 넣은 순서대로 처리해야 하는 배열, 인덱스 접근과 SORT+BINARY SEARCH 접근이 둘 다 필요한 경우.

DEFAULT KEY를 피해요. 선언할 때 습관적으로 붙이기 쉽지만, 의도하지 않은 필드가 키로 선택될 수 있어요. 구조체 행의 표준 키에는 문자형·바이트형 필드가 포함되고 숫자형 필드는 제외되므로, 정렬이나 중복 제거 결과가 예상과 달라질 수 있어요. 특히 필드 목록 없는 SORT, DELETE ADJACENT DUPLICATES는 기본 키를 따라가므로, READ TABLE ... BINARY SEARCH와 함께 쓰면 예상 밖의 결과가 나올 수 있다고 해요.

DATA itab2 TYPE STANDARD TABLE OF row_type WITH NON-UNIQUE KEY comp1 comp2.
DATA itab1 TYPE STANDARD TABLE OF row_type WITH EMPTY KEY.

주의: EMPTY KEY 테이블을 필드 지정 없이 SORT 하면 아무것도 정렬되지 않아요. 키가 비어 있음을 정적으로 알 수 있으면 문법 경고가 나와요.

INSERT INTO TABLE을 우선해요. 모든 테이블 종류와 키 종류에 쓸 수 있어서, 나중에 성능 때문에 테이블 종류를 바꿔도 이 문장은 고칠 필요가 없어요. APPEND TO는 STANDARD 테이블을 배열처럼 쓰며 "맨 끝에 붙인다"는 점을 강조하고 싶을 때만 써요.

읽기는 의도가 보이게 써요.

IF line_exists( my_table[ key = 'A' ] ).                       " 있는지만 볼 때
READ TABLE my_table REFERENCE INTO DATA(line) WITH KEY key = 'A'.  " 한 건 읽을 때
LOOP AT my_table REFERENCE INTO DATA(line) WHERE key = 'A'.    " 조건에 맞는 모두

READ TABLE ... TRANSPORTING NO FIELDS와 sy-subrc 검사, 또는 LOOP AT 안에서 EXIT 하는 방식은 같은 동작을 더 긴 코드로 표현해요. LOOP 안의 IF로 거르는 것도 WHERE로 바꾸는 게 의도가 분명해요.

불필요한 이중 읽기를 피해요. 행이 있을 거라고 기대하는 경우라면 먼저 line_exists로 존재 여부를 확인한 뒤 다시 읽지 말고, 한 번 읽고 예외로 처리해요.

TRY.
    DATA(row) = my_table[ key = input ].
  CATCH cx_sy_itab_line_not_found.
    RAISE EXCEPTION NEW /clean/my_data_not_found( ).
ENDTRY.

원문은 이것이 성능뿐 아니라 "정상 흐름과 오류 처리를 한 곳에 섞지 말라"는 일반 규칙의 한 경우라고 설명해요(이 연재의 여덟 번째 회에서 다뤄요).

주의할 점

• 테이블 종류 선택은 가이드도 말하듯 대략적인 기준이에요. 데이터 크기와 접근 패턴을 실제로 측정해 보고 정하세요. 자세한 기준은 ABAP 언어 도움말의 "테이블 종류 선택" 항목에 있어요.

• [ ] 테이블 식, VALUE #( ... OPTIONAL ), REFERENCE INTO DATA(...), RAISE EXCEPTION NEW는 7.40 이상(일부는 그보다 높은 릴리스)에서만 돼요. ECC 에서는 쓰기 전에 문법 검사를 해 보세요. (7.40 기준은 원문에 적힌 것이 아니라 일반적으로 알려진 정보예요.)

• 원문은 2019년에 처음 공개되어 2025년 3월에 마지막으로 고쳐진 문서예요(제가 읽은 판은 2026년 10월 기준). 이 글은 읽고 정리한 것이고 예제를 직접 실행해 보지는 않았어요.

원문 주소: https://github.com/SAP/styleguides/blob/main/clean-abap/CleanABAP.md#tables