ABAP SQL 튜닝 ① - 왜 SQL이 병목이 되는가#

#들어가며 - Open SQL과 ABAP SQL

시작하기 전에 용어부터 정리합니다. 오랫동안 Open SQL이라 불리던 것이, 릴리스 7.53 무렵부터 공식 명칭이 ABAP SQL로 바뀌었습니다.

같은 것을 가리키는 다른 이름이라고 보면 됩니다. 이 시리즈에서는 ABAP SQL로 쓰되, 검색 편의를 위해 Open SQL도 병기하겠습니다.

#왜 SQL이 병목이 되는가

ABAP 프로그램이 느릴 때, 원인은 크게 둘 중 하나입니다.

경험적으로 후자가 압도적으로 많습니다. 이유는 구조에 있습니다.

ABAP 프로그램은 애플리케이션 서버에서 돌고, 데이터는 데이터베이스에 있습니다. 둘은 네트워크로 분리되어 있습니다. 내부 테이블을 한 번 더 도는 비용과, DB에 한 번 더 갔다 오는 비용은 차원이 다릅니다.

그래서 SQL 튜닝의 큰 방향은 늘 같습니다.

DB에 덜 가고, 갈 때는 꼭 필요한 만큼만 가져온다.

#5가지 황금률

SAP 성능 가이드에서 오래 쓰여온 원칙입니다. 이 시리즈의 뼈대이기도 합니다.

#	원칙	다루는 편
1	결과 집합을 줄여라 — 필요한 행만	②편
2	전송량을 줄여라 — 필요한 열만	③편
3	접근 횟수를 줄여라 — DB 왕복을 최소화	④편
4	검색 비용을 줄여라 — 인덱스를 타게	②편
5	DB 부하를 줄여라 — 버퍼·중복 조회 관리	④편

원칙 자체는 단순합니다. 문제는 실제 코드에서 이걸 어떻게 알아보고 어떻게 고치느냐이고, 나머지 편들이 그 이야기입니다.

#측정하지 않고 튜닝하지 마라

이 시리즈에서 가장 강조하고 싶은 원칙입니다.

흔한 실패 사례가 있습니다. 복잡해 보이는 JOIN 쿼리를 며칠 걸려 최적화했는데 전체 시간이 그대로인 경우입니다. 재보니 그 쿼리는 전체의 3%였고, 루프 안에서 10만 번 돌던 단순 조회가 80% 였습니다.

#측정 도구

상황에 따라 쓰는 도구가 다릅니다.

도구	보는 것	언제
ST05	내 세션이 실행한 SQL 전체 내역	재현 가능한 특정 프로그램
SAT	ABAP 코드별 소요 시간	어디가 느린지 모를 때
ST04	DB 전체 부하	재현이 안 되는 문제, 누적 부하
SQLM	운영 중 실행된 SQL의 통계 수집	전체 시스템에서 문제 SQL 찾기
SWLT	SQLM 결과 + 정적 검사 결합	튜닝 대상 우선순위 정하기
ATC	소스 정적 검사	코드 리뷰·이관 전 사전 차단

#개발자가 실제로 쓰는 순서

#S/4HANA에서 달라진 것

이 시리즈는 S/4HANA(HANA DB) 를 기준으로 씁니다. 전통적인 디스크 기반 DB와 전제가 다른 부분이 있어서, 예전 튜닝 상식이 그대로 통하지 않는 지점이 생깁니다.

• 컬럼 스토어 — 열 단위로 저장하므로 SELECT * 의 손해가 더 커집니다. (③편)
• 인덱스 전략이 다르다 — 예전처럼 보조 인덱스를 많이 만드는 접근이 항상 정답은 아닙니다. (②편)
• Code-to-Data — 계산을 ABAP이 아니라 DB에서 하도록 옮기는 방향입니다. (⑦편)

#시리즈 로드맵

편	주제
① (이 글)	왜 SQL이 병목이 되는가 · 측정 도구
②	결과 집합을 줄여라 — WHERE절과 인덱스
③	전송량을 줄여라 — SELECT * 와 필드 리스트
④	접근 횟수를 줄여라 — 루프 안의 SELECT, FOR ALL ENTRIES
⑤	대량 조회 ① 속도 — OFFSET vs 키셋 페이징
⑥	대량 조회 ② 메모리 — PACKAGE SIZE와 커서
⑦	S/4HANA Code-to-Data — CDS·AMDP

#정리

• 성능 문제의 대부분은 DB 접근에 있습니다.
• 큰 방향은 하나입니다. 덜 가고, 덜 가져온다.
• 무엇보다 측정이 먼저입니다. 감으로 고치면 시간만 씁니다.
• 실행 시간뿐 아니라 실행 횟수를 보세요.

다음 편에서는 첫 번째 황금률, 결과 집합 줄이기부터 시작합니다.