이 글에서 다루는 내용
SAP를 처음 시작한 개발자가 가장 먼저 부딪히는 벽은 ABAP 문법이 아니라 수백 개의 트랜잭션 코드입니다. SE11과 SE16은 뭐가 다른지, 덤프가 나면 ST22를 봐야 하는지 SM21을 봐야 하는지, 테이블 데이터는 SM30으로 고치는 게 맞는지 — 실무 채팅방에서 매일 올라오는 질문들이죠. 이 글은 초보 개발자가 자주 헷갈리는 트랜잭션 코드 쌍을 Q&A 형식으로 정리한 실전 예제 모음입니다. 읽고 나면 아래 항목을 스스로 판단할 수 있게 됩니다.
- SE11 / SE16 / SE16N — 구조 정의와 데이터 조회의 경계 구분
- SE38 / SE37 / SE80 — 개발 오브젝트 유형별 진입점 선택
- SM30 / SM31 / SE54 — 테이블 유지보수 다이얼로그의 올바른 사용
- ST22 / SM21 / SM13 — 장애 상황에서 어디부터 열어야 하는지
- SPRO / SPDD / SPAU — 커스터마이징과 업그레이드 조정 도구 구분
미리 알고 있으면 좋은 배경
SAP GUI에 로그인해서 명령 필드(화면 좌측 상단 입력창)에 트랜잭션 코드를 입력해 본 경험이 있다면 충분합니다. ABAP 문법 지식은 필수는 아니지만, 리포트·펑션 모듈·테이블이라는 오브젝트 유형이 서로 다르다는 점 정도만 알고 있으면 이해가 훨씬 빠릅니다. 명령 필드에서 /n은 현재 세션에서 트랜잭션 전환, /o는 새 세션 열기라는 것도 함께 기억해 두세요.
실습 환경과 준비 사항
이 글의 내용은 SAP S/4HANA 2023 (온프레미스)와 SAP ECC 6.0 EHP8 기준으로 작성했습니다. 여기서 다루는 트랜잭션 코드는 대부분 NetWeaver 시절부터 이어져 온 표준이라 두 버전에서 동작이 거의 동일합니다. 다만 SAP BTP의 ABAP Environment(Steampunk)에서는 SAP GUI 트랜잭션 자체를 쓸 수 없고 ADT(Eclipse) 기반으로만 개발하므로, 이 글은 온프레미스/Private Cloud 환경을 전제로 합니다. 준비물은 다음과 같습니다.
- SAP GUI for Windows 8.00 이상 (또는 SAP GUI for Java)
- 개발 서버 접속 계정과 개발자 키(온프레미스의 경우)
S_TCODE권한 오브젝트에 해당 트랜잭션이 허용된 롤 — 권한이 없으면 트랜잭션 실행 자체가 차단됩니다
트랜잭션 코드 네이밍의 숨은 규칙
트랜잭션 코드가 헷갈리는 근본 원인은 이름이 기능을 설명하지 않기 때문입니다. 하지만 접두어에는 일정한 규칙이 있어서, 이것만 알아도 절반은 해결됩니다.
| 접두어 | 영역 | 대표 예 |
|---|---|---|
SE* | 개발 워크벤치 (Workbench Editor 계열) | SE11, SE38, SE80 |
SM* | 시스템 관리 (System Management) | SM30, SM21, SM50 |
ST* | 모니터링·트레이스 (System Trace) | ST22, ST05, ST12 |
SU* | 사용자·권한 (System User) | SU01, SU53, SU21 |
SP* | 커스터마이징·업그레이드·스풀 | SPRO, SPAU, SP01 |
비유하자면 SE 계열은 공장의 설계실, SM 계열은 공장 관리사무소, ST 계열은 CCTV 관제실입니다. "무언가를 만들거나 고친다"면 SE, "시스템을 운영·설정한다"면 SM, "무슨 일이 있었는지 조사한다"면 ST부터 떠올리는 습관을 들이면, 처음 보는 코드도 대략의 용도를 추측할 수 있습니다. 또 하나 중요한 원칙 — 커스텀 트랜잭션은 반드시 Z 또는 Y로 시작합니다. 표준 네임스페이스와 충돌을 피하기 위한 일반적인 규칙입니다.
실무 Q&A — 자주 헷갈리는 트랜잭션 코드 짝 정리
Q1. SE11, SE16, SE16N — 다 테이블 보는 거 아닌가요?
가장 많이 받는 질문입니다. 셋의 역할은 명확히 다릅니다.
- SE11 (ABAP Dictionary): 테이블의 구조를 정의·수정하는 곳입니다. 필드, 데이터 엘리먼트, 도메인, 외래키를 다룹니다. 데이터가 아니라 "설계도"를 보는 트랜잭션입니다.
- SE16 (Data Browser): 테이블에 들어 있는 데이터를 조회합니다. 클래식 화면이라 다소 투박합니다.
- SE16N (General Table Display): SE16의 ALV 기반 개선판입니다. 필터·정렬·레이아웃 저장이 편해서 실무에서는 사실상 SE16N을 표준처럼 씁니다.
예를 들어 주문 이력을 남기는 커스텀 테이블 ZTB_ORDER_LOG를 만들었다면 — 필드를 추가할 때는 SE11, 어제 쌓인 로그를 확인할 때는 SE16N입니다. 참고로 S/4HANA에서는 SE16H라는 HANA 최적화 버전도 있어서 집계(GROUP BY) 조회까지 화면에서 바로 할 수 있습니다.
Q2. 리포트는 SE38, 펑션은 SE37이라는데 SE80은 왜 있나요?
SE38은 실행 가능한 프로그램(리포트) 전용, SE37은 펑션 모듈 전용 편집기입니다. SE80(Object Navigator)은 이 둘을 포함해 클래스·패키지·화면·인클루드까지 모든 개발 오브젝트를 트리 구조로 탐색하는 통합 진입점입니다. 예를 들어 재고 동기화 리포트 ZR_STOCK_SYNC가 펑션 Z_FM_STOCK_RECALC를 호출하는 구조라면, 리포트 하나만 고칠 때는 SE38로 충분하지만 패키지 전체 구조를 보며 작업할 때는 SE80이 효율적입니다. 아래처럼 SE37의 단독 테스트 기능(F8)으로 펑션만 따로 실행해 볼 수 있다는 점이 SE37의 큰 장점입니다.
" ZR_STOCK_SYNC 내부에서의 호출 예시
CALL FUNCTION 'Z_FM_STOCK_RECALC'
EXPORTING
iv_plant = p_werks
iv_matnr = p_matnr
IMPORTING
ev_qty = lv_qty
EXCEPTIONS
not_found = 1
lock_error = 2
OTHERS = 3.
IF sy-subrc <> 0.
MESSAGE ID sy-msgid TYPE 'E' NUMBER sy-msgno
WITH sy-msgv1 sy-msgv2 sy-msgv3 sy-msgv4.
ENDIF.
SE37에서 이 펑션을 테스트 실행하면 리포트를 전부 돌리지 않고도 lock_error 예외 분기를 검증할 수 있습니다. 참고로 최근에는 클래스 기반 개발이 일반적이라 SE24(Class Builder)와 ADT(Eclipse)를 함께 알아두는 것이 좋습니다.
Q3. SM30이랑 SM31은 뭐가 다르죠? 데이터 수정은 여기서 하면 되나요?
SM30과 SM31은 사실상 같은 기능(Table Maintenance)으로 수렴했습니다. SM31은 과거 버전의 잔재이고, 현재는 SM30을 쓰면 됩니다. 진짜 중요한 구분은 따로 있습니다.
- SM30: 유지보수 다이얼로그(Table Maintenance Generator)가 생성되어 있는 테이블/뷰만 편집 가능. 검증 로직·이벤트가 적용된 안전한 편집 창구입니다.
- SE54: 그 유지보수 다이얼로그 자체를 생성·설정하는 트랜잭션입니다.
- SE16N + &SAP_EDIT: 다이얼로그 없이 데이터를 직접 수정하는 우회로인데, 감사 로그에 남고 대부분의 운영 환경에서 차단되어 있습니다. 운영 데이터 직접 수정은 권장되지 않습니다.
실무 순서는 이렇습니다 — 설정 테이블 ZTB_FEE_RATE를 만들었다면 ① SE11에서 테이블 정의 시 Delivery Class를 C(커스터마이징)로 지정, ② SE54(또는 SE11 → Utilities → Table Maintenance Generator)에서 다이얼로그 생성, ③ 이후 현업/운영자는 SM30으로만 값을 관리하게 안내합니다.
Q4. 프로그램이 죽었어요. ST22를 봐야 하나요, SM21을 봐야 하나요?
증상에 따라 갈립니다.
| 상황 | 트랜잭션 | 보는 것 |
|---|---|---|
| ABAP 런타임 에러(덤프) 발생 | ST22 | 덤프 상세, 소스 위치, 변수 값 |
| 원인 불명의 시스템 이상 징후 | SM21 | 시스템 로그 (DB 오류, 락, 커널 메시지) |
| 업데이트가 반영 안 됨 | SM13 | 업데이트 레코드 실패 내역 |
| 프로그램이 멈춰 있음(행) | SM50 / SM66 | 워크 프로세스 상태 |
순서로 기억하세요 — 덤프 메시지를 봤다면 무조건 ST22 먼저. 덤프도 없이 이상하다면 SM21 → SM50 순으로 넓혀갑니다. ST22에서는 "How to correct the error" 섹션과 소스 코드 발췌 부분만 봐도 원인의 80%는 잡힙니다.
Q5. SPRO, SPDD, SPAU — 이름이 비슷해서 늘 헷갈립니다.
이름만 비슷할 뿐 쓰는 시점이 완전히 다릅니다. SPRO는 평상시 기능 컨설턴트가 IMG(커스터마이징 트리)에서 시스템 설정을 하는 곳입니다. SPDD와 SPAU는 업그레이드/서포트 팩 적용 중에만 등장하는 조정 도구로, SPDD는 딕셔너리 오브젝트(테이블·구조)의 수정 충돌을, SPAU는 리포트·펑션 등 레포지토리 오브젝트의 충돌을 조정합니다. 초보 개발자가 SPDD/SPAU를 직접 열 일은 거의 없지만, "업그레이드 때 내 수정사항이 날아갈 수 있다"는 개념은 알고 있어야 표준 프로그램 수정(Modification)을 함부로 하지 않게 됩니다.
Q6. 권한 오류가 나면 SU01을 보나요?
아닙니다. 먼저 SU53입니다. 권한 오류 직후 SU53을 실행하면 "방금 실패한 권한 체크"가 어떤 권한 오브젝트·값 때문인지 그대로 보여줍니다. 그 결과를 캡처해서 권한 담당자에게 전달하는 것이 표준 절차입니다. SU01은 사용자 마스터를 관리하는 관리자용 트랜잭션이라 개발자가 직접 만질 일은 드뭅니다.
자주 나오는 질문과 실수 대처법
Q. SE16N에서 테이블이 "존재하지 않음"이라고 나옵니다.
테이블이 아니라 CDS 뷰이거나, 아직 활성화(Activate)되지 않았을 가능성이 큽니다. SE11에서 오브젝트 상태가 Active인지 먼저 확인하세요. S/4HANA에서는 예전 테이블이 CDS 호환 뷰로 대체된 경우도 많습니다.
Q. SM30에서 "유지보수 다이얼로그가 없다"는 오류가 납니다.
SE54에서 Table Maintenance Generator를 생성하지 않은 테이블입니다. 생성 시 기능 그룹 이름(예: ZFG_FEE_MAINT)과 권한 그룹을 지정해야 하며, 이후 테이블 필드를 바꾸면 다이얼로그도 재생성해야 한다는 점을 자주 놓칩니다.
Q. 트랜잭션을 입력했는데 아무 반응이 없습니다.
이미 다른 트랜잭션 안에 있는 상태에서는 코드만 입력하면 무시됩니다. /nSE38처럼 /n을 붙여 전환하세요. 그래도 안 되면 S_TCODE 권한 누락이니 SU53으로 확인 후 권한 요청이 필요합니다.
Q. SE38에서 표준 프로그램을 수정하려니 Access Key를 요구합니다.
표준 오브젝트 수정(Modification)은 SSCR 키가 필요하며, 업그레이드 시 SPAU 조정 대상이 됩니다. 가능하면 BAdI·Enhancement Point 같은 확장 기법을 먼저 검토하는 것이 일반적으로 권장됩니다.
이어서 살펴보면 좋은 주제
트랜잭션 코드 구분이 익숙해졌다면 다음 주제로 넓혀 보세요. ① ADT(Eclipse) 기반 개발 — S/4HANA에서는 CDS·RAP 개발이 GUI가 아닌 Eclipse에서 이뤄집니다. ② SE93으로 커스텀 트랜잭션 만들기 — 직접 만든 리포트를 ZOL01 같은 코드로 등록하는 과정. ③ ST05 SQL 트레이스와 SAT 런타임 분석 — 성능 문제를 조사하는 모니터링 계열 심화. ④ 전송 관리(SE09/SE10, STMS) — 개발한 오브젝트가 운영까지 이동하는 경로 이해.
댓글 0
아직 댓글이 없습니다.