ABAP 프로그램이 느릴 때 손이 가는 진단 트랜잭션이 셋 있다 — **ST05, SAT, ST12**. 셋 다 "성능 분석"이라는 한 단어로 묶이지만 보는 곳이 다르다. 이걸 구분 못 하면 DB가 느린데 ABAP 코드만 들여다보거나, 반대로 루프가 문제인데 SQL만 째려보며 시간을 버린다. 정리하면: **ST05는 DB 접근(SQL)**, **SAT는 ABAP 코드 자체(CPU)**, **ST12는 둘을 한 번에** 본다. 보통 ST05로 DB 병목을 먼저 잡고(투자 대비 효과가 가장 크다), 그래도 안 잡히면 SAT로 코드를, 트랜잭션 하나를 통째로 진단하려면 ST12를 쓴다. 아래에서 각 도구의 화면 읽는 법과 표준 워크플로우를 정리한다. ## 왜 전환기에 더 중요해졌나 S/4HANA로 오면서 성능 진단의 무게가 커졌다. 핵심은 **코드 푸시다운(code push-down)** — 연산을 ABAP 서버로 끌어올리지 말고 CDS·AMDP·Open SQL로 HANA에 내리는 게 정석이 됐다. 그런데 ECC에서 잘 돌던 `SELECT ... INTO` 루프 코드가 컨버전 직후 HANA에서 오히려 느려지는 "post-conversion SQL" 문제가 흔하다. 이때 무엇이 느린지 정확히 짚으려면 결국 이 세 도구로 돌아온다. ## 세 도구 한눈에 | 도구 | 보는 것 | 언제 | |---|---|---| | **ST05** (SQL Trace) | SQL·RFC·Enqueue·Buffer 등 외부 접근 | DB 병목 의심 (제일 먼저) | | **SAT** (Runtime Analysis) | ABAP 코드 — 메서드별 CPU 시간 | 루프·내부테이블·CPU 병목 | | **ST12** (Single Transaction) | ST05 + SAT 통합 | 트랜잭션 1회 통째 진단 | ST05는 DB·RFC·lock 같은 **외부 접근**만 본다는 점을 기억하자. 내부테이블 정렬, 중첩 루프, 문자열 연산 같은 **순수 ABAP CPU 병목은 ST05에 안 보인다.** 그건 SAT/ST12의 영역이다. ## ST05 — SQL Trace 읽는 법 ST05는 SQL 외에 RFC·Enqueue(lock)·Buffer·HTTP 트레이스도 제공하는 Performance Trace 도구다. "필터로 활성화(Activate Trace with Filter)"로 특정 user·program·table만 좁혀 추적할 수 있다. 추적은 애플리케이션 서버 단위라, **추적 대상 user가 그동안 다른 작업을 하면 노이즈가 섞인다** — 진단할 액션 하나만 딱 돌리는 게 요령이다. 트레이스 리스트의 핵심 컬럼은 이렇다. | 컬럼 | 의미 | |---|---| | Duration (µs) | 실행 시간. 100ms(=100,000µs) 초과는 빨간색 | | Object Name | 접근한 테이블 | | Op. | 작업 유형(SELECT/INSERT…) | | Recs | 읽은 레코드 수 | | Statement | 실제 실행된 SQL | 여기서 가장 흔한 함정. **빨간색(>100ms)을 무조건 문제로 단정하면 안 된다.** 절대 시간이 아니라 **건수 대비**로 봐야 한다. 한 번에 1,000건을 읽어 200ms면 빨개도 양호하지만, 1건 읽는 데 50ms면 인덱스를 의심해야 한다. 단건 조회는 보통 1ms 안팎, 여러 건을 한 번에 읽는 array fetch면 건당 시간이 그보다 훨씬 짧아야 정상이다. ## ST05 실전 — 중복 SELECT와 실행계획 ST05의 핵심 기능은 둘이다. - **Summarize Trace by SQL Statement** (`SHIFT+F8`): 같은 SQL을 집계해 보여준다. 동일 쿼리가 수백 번 실행됐으면 **SELECT in LOOP(중첩 select)**가 범인일 확률이 높다. - **Explain SQL** (`F9`): 실행계획을 본다. Full Table Scan이 보이면 인덱스가 없는 것. 인덱스 유무는 비용을 1,000배까지 가른다(Index Unique Scan 2 vs Full Table Scan 3,850 같은 식). 여기에 `F2`(치환된 변수값), 소스 점프 버튼으로 "어느 코드가 이 SQL을 쐈나"까지 따라간다. 개선 방향은 정해져 있다 — `SELECT ... FOR ALL ENTRIES`나 JOIN으로 묶고, 인덱스를 맞추고, S/4HANA라면 아예 CDS·AMDP로 DB에 연산을 내린다. ## SAT — ABAP 코드의 시간 SAT(ABAP Runtime Analysis)는 옛 `SE30`의 공식 후속이다(NetWeaver 7.0 EhP2 도입). SE30 트레이스 파일도 SAT에서 그대로 열린다. SE30은 트레이스가 앱서버 로컬에 잠깐 있다 사라졌지만, SAT는 DB에 저장돼 다른 앱서버 트레이스도 조회되고 내부테이블 실제 이름까지 보여준다. 측정은 변형(Variant) 기반이다(DEFAULT 제공). 평가 도구 중 핵심은 **Hit List**로, 호출별 **Gross µs**와 **Net µs**를 보여준다. 이 둘의 구분이 SAT의 전부라 해도 된다. - **Net time**: 그 메서드 *자체*가 쓴 시간(하위 호출 제외) - **Gross time**: 그 메서드 + 그것이 호출한 하위 전부 **Net가 크면 그 코드 자체가 진범**이고, **Gross만 크면 그 함수는 죄가 없고 하위 호출이 병목**이다. 이걸 헷갈리면 엉뚱한 코드를 고친다. Call Hierarchy(실행 순서 트리), Profile(컴포넌트별 분포)로 더 파고든다. ## ST12 — 둘을 한 번에 ST12(Single Transaction Analysis)는 ST05(SQL)와 SAT(ABAP)를 **단일 화면으로 통합**한 도구다. "어느 코드가 → 어떤 SQL을" 호출했는지를 한눈에 본다. 대화형·리포트·배치잡은 물론 다른 user 세션도 추적된다. 사용 흐름은 추적 시작 → 다른 세션에서 액션 실행 → ST12로 돌아와 **End traces & collect** → Full screen 분석이다. 단, **ST12는 SAP 기본에 없다.** ST-A/PI 애드온으로 제공되니, 운영에서 갑자기 쓰려는데 트랜잭션 자체가 없어 당황하는 경우가 흔하다. 설치·버전은 **SAP Note 69455**, 사용 절차는 **KBA 2436955**를 참고한다. ## 표준 워크플로우 사실 동적 트레이스(ST05/SAT)를 켜기 전에, **정적 분석(Code Inspector·ATC)으로 'LOOP 안 SELECT' 같은 뻔한 안티패턴부터 걸러내는** 게 효율적이다. 그다음 순서는 외워두면 대부분 커버된다. 1. **ST05 먼저** — DB가 느린지부터. 투자 대비 효과가 가장 크다. 2. **안 잡히면 SAT** — DB는 빠른데 전체가 느리면 ABAP 코드(루프·CPU)다. 3. **통째 진단은 ST12** — 트랜잭션 하나를 ABAP+SQL 같이 보고 싶을 때. 그리고 **무엇을 켰든 끝나면 반드시 Deactivate.** 트레이스 활성 자체가 시스템 부하다. 운영에서 켜둔 채 방치하지 말 것. ## S/4HANA·CDS 관점 S/4HANA에선 ST05의 쓰임이 하나 더 늘었다. CDS·Open SQL이 **실제로 생성한 SQL을 검증**하는 용도다. CDS 뷰를 여러 겹 쌓으면(예: 7개 레이어가 400줄짜리 SQL을 만드는 식) 옵티마이저가 못 따라가 느려질 수 있다. ST05로 생성 SQL을 보고, 복잡한 CDS는 **HANA PlanViz**로 필터가 DB까지 내려갔는지(push-down) 확인한다. 한국 전환 현장에서 가장 흔한 시나리오 둘. ① 컨버전 직후 기존 리포트가 HANA에서 느려지면 ST05로 생성 SQL·인덱스 사용을 본다. ② 레거시 SELECT-in-LOOP를 코드 푸시다운으로 리팩터링할 때 before/after를 ST05·SAT로 정량 비교한다. 그리고 운영에서 ST12를 쓰려면 ST-A/PI가 깔려 있어야 하니, 국내 운영팀이 미설치인 경우가 많아 **Basis팀에 사전 설치(Note 69455)를 요청**해 두는 게 좋다. 입문자라면 딱 한 줄만 기억하자 — **"ST05 먼저, 안 잡히면 SAT/ST12."** 화면이 전부 영문이니 컬럼명(Duration·Recs·Statement, Gross·Net)은 그대로 익혀두면 실무에 바로 쓴다. 리팩터링에 쓸 신문법은 [ABAP 7.40/7.50 신문법](/education/abap-740-750-new-syntax), DB로 연산을 내리는 CDS는 [ABAP CDS View 입문](/education/abap-cds-view-intro)에서 다룬다. ## 출처 - SAP Community — *ST12 Trace: Step by step instruction*, *Next Generation ABAP Runtime Analysis (SAT)*: [community.sap.com](https://community.sap.com/t5/application-development-and-automation-blog-posts/st12-trace-step-by-step-instruction-on-how-to-use-it-for-analysis/ba-p/13240660) - SAP KBA 2436955 — *How to collect and analyze traces using ST12*: [support.sap.com](https://userapps.support.sap.com/sap/support/knowledge/en/2436955) - SAP Note 69455 — *ST-A/PI (ST12 등 서비스 툴)* - SAP Community — *ABAP Performance Tuning in S/4HANA: The ST05 Playbook*, *How to analyze query performance for ABAP CDS Views* 심화 참고: *Complete ABAP*, *ABAP Development for SAP HANA* (SAP PRESS)