SAP

SU53 아직도 모른다면? 권한 오류 30초 해결 #shorts #SAP #SU53

1. "You are not authorized" — 권한 오류가 터지는 순간

SAP S/4HANA(2022/2023 온프레미스 및 Private Cloud Edition 기준)를 쓰다 보면 누구나 한 번은 만나는 메시지가 있습니다. 화면 하단 상태 표시줄에 뜨는 You are not authorized to use transaction MM60 같은 빨간 문구입니다. 업무는 급한데 권한 담당자(Basis/Security 팀)는 자리에 없고, 메일로 "권한 주세요"라고만 보내면 담당자도 "정확히 어떤 권한이 없는데요?"라고 되묻는 핑퐁이 시작됩니다.

이 글에서 다루는 SU53은 이 핑퐁을 끊는 가장 빠른 도구입니다. 오류 발생 직후 SU53 한 번만 실행하면 "어떤 권한 오브젝트의, 어떤 필드에, 어떤 값이 없어서 실패했는지"가 30초 안에 화면에 나옵니다. 읽고 나면 아래를 할 수 있게 됩니다.

  • 권한 오류 발생 직후 SU53으로 실패한 Authorization Check를 즉시 조회
  • Object / Field / Value 3단 구조로 실패 원인을 해석
  • 권한 담당자에게 "정답이 담긴" 요청 메일을 한 번에 작성
  • SUIM·ST01(STAUTHTRACE)과의 역할 차이를 구분해 상황별 도구 선택

2. 시작 전에 알아두면 좋은 것들

어려운 배경지식은 필요 없습니다. SAP GUI 로그인과 트랜잭션 코드 실행(예: /nMM60)만 할 줄 알면 됩니다. 다만 아래 두 개념은 미리 감을 잡아두면 좋습니다.

  • 권한 오브젝트(Authorization Object): 권한 검사의 최소 단위. 예를 들어 S_TCODE는 "어떤 트랜잭션을 실행할 수 있는가"를 검사합니다.
  • 롤/프로파일(Role/Profile): 권한 오브젝트 값들을 묶어 사용자에게 배포하는 단위. PFCG로 관리합니다.

3. 환경과 준비물 — 어떤 시스템에서든 거의 동일

SU53은 R/3 시절부터 존재한 표준 트랜잭션으로, S/4HANA 1909 이후 버전에서도 동일하게 동작합니다. 이 글의 화면 기준은 다음과 같습니다.

  • 시스템: SAP S/4HANA 2022 이상 (온프레미스 / Private Cloud Edition) — Public Cloud Edition은 GUI 트랜잭션 대신 Fiori 앱 "Display Authorization Trace" 계열을 사용하므로 이 글의 범위 밖입니다.
  • 클라이언트: SAP GUI for Windows 7.70 이상 또는 SAP GUI for HTML(WebGUI)
  • 필요 권한: 본인의 SU53 조회는 별도 권한이 거의 필요 없습니다. 단, 다른 사용자의 SU53 데이터를 조회하려면 권한 오브젝트 S_USER_AUT 계열 권한이 일반적으로 요구됩니다.

한 가지 중요한 제약: S/4HANA(정확히는 NetWeaver 7.50 이후)의 SU53은 사용자·클라이언트별로 최근 실패 기록을 일정 기간(기본 최대 100건 수준) 버퍼에 보관하지만, 구버전에서는 "마지막 실패 1건"만 보여줬습니다. 따라서 오류가 난 직후, 다른 화면을 헤집기 전에 SU53을 실행하는 습관이 가장 안전합니다.

4. SU53의 동작 원리 — 커널이 남긴 '실패 영수증'

SU53을 이해하는 가장 쉬운 비유는 카드 결제 거절 영수증입니다. 편의점에서 카드가 거절되면 단말기가 "한도 초과인지, 카드 정지인지" 사유 코드를 찍어주듯이, SAP 커널은 ABAP 코드 안의 AUTHORITY-CHECK 구문이 실패할 때마다 그 내역을 사용자 세션 메모리에 기록합니다. SU53은 이 기록을 사람이 읽을 수 있는 형태로 꺼내 보여주는 조회 창구일 뿐입니다.

내부 흐름을 도식화하면 이렇습니다.

사용자 액션 (MM60 실행)
   │
   ▼
ABAP 프로그램의 AUTHORITY-CHECK 실행
   │
   ├─ sy-subrc = 0  → 통과, 화면 진행
   │
   └─ sy-subrc ≠ 0  → 실패
         │
         ├─ 커널이 실패 내역(Object/Field/Value)을 버퍼에 기록
         └─ 사용자에게 "권한 없음" 메시지 표시
                │
                ▼
        사용자가 /nSU53 실행 → 버퍼의 실패 기록 조회

실제 검사 코드는 대략 아래 형태입니다. 예를 들어 자재 리스트 조회 프로그램이 특정 플랜트 권한을 검사한다면 이런 식입니다.

" 예시: 커스텀 자재 조회 리포트의 플랜트 권한 검사
AUTHORITY-CHECK OBJECT 'M_MATE_WRK'
  ID 'ACTVT' FIELD '03'          " 03 = 조회(Display)
  ID 'WERKS' FIELD lv_plant.     " 예: 화성 플랜트 '2100'

IF sy-subrc <> 0.
  " 이 순간의 실패 내역이 SU53 버퍼에 남는다
  MESSAGE e027(zmm_report) WITH lv_plant.
ENDIF.

핵심은 세 가지입니다.

  • Object: 무엇을 검사했나 (M_MATE_WRK = 자재마스터의 플랜트 권한)
  • Field: 오브젝트 안의 어떤 항목인가 (ACTVT=활동, WERKS=플랜트)
  • Value: 프로그램이 요구한 값 vs 사용자가 가진 값 (요구: 03/2100, 보유: 없음)

SU53 화면은 이 세 층위를 트리로 보여주고, 아래쪽에는 사용자가 실제 보유한 관련 권한(프로파일 내 값)을 함께 표시합니다. 즉 "요구 값"과 "보유 값"의 차이(diff)를 눈으로 확인하는 도구입니다.

5. 실전 3단계 — 오류 발생부터 요청 메일까지

[1단계] 기본: 30초 진단 루틴

  1. 권한 오류 메시지를 확인합니다. (예: MM60 실행 → "You are not authorized...")
  2. 같은 세션에서 즉시 명령 필드에 /nSU53 입력 후 Enter. 새 모드(/o)로 열어도 되지만, 다른 트랜잭션을 먼저 실행하면 기록이 밀려날 수 있으니 곧바로 실행이 원칙입니다.
  3. 화면 상단의 가장 최근 항목(빨간 아이콘)이 방금 실패한 검사입니다. S/4HANA에서는 좌측에 시간순 목록이 나오므로 오류 발생 시각과 대조합니다.

MM60(자재 리스트) 접근이 막힌 경우 SU53 결과는 일반적으로 아래처럼 읽힙니다.

Authorization check failed  (2026-07-28 14:03:21)
──────────────────────────────────────────────
Object : S_TCODE   (Transaction Code Check at Transaction Start)
  Field: TCD       Value required: MM60

User's existing authorizations for S_TCODE:
  Profile: Z_MM_DISPLAY_ALL
    TCD = MM03, MMBE, MB52        ← MM60이 목록에 없음

해석: 사용자는 MM03·MMBE 등은 실행 가능하지만 S_TCODE의 TCD 값에 MM60이 없어서 진입 자체가 거절됐습니다. 여기까지가 30초입니다.

[2단계] 실무: 트랜잭션은 열리는데 데이터 단계에서 막히는 경우

더 흔하고 까다로운 케이스는 "트랜잭션은 들어가지는데 특정 플랜트/회사코드 데이터에서 막히는" 상황입니다. 예를 들어 MM60에서 플랜트 2100을 조회하다 오류가 났다면 SU53에는 이렇게 남습니다.

Authorization check failed
──────────────────────────────────────────────
Object : M_MATE_WRK  (Material Master: Plants)
  Field: ACTVT   Value required: 03
  Field: WERKS   Value required: 2100

User's existing authorizations for M_MATE_WRK:
  Profile: Z_MM_DISPLAY_ALL
    ACTVT = 03
    WERKS = 1100, 1200            ← 2100 없음

이때 권한 담당자에게 보내는 요청은 아래처럼 "정답을 포함해" 써야 왕복이 한 번으로 끝납니다.

[권한 요청] 사용자: JHKIM / 시스템: PRD-100
발생 트랜잭션: MM60 (자재 리스트, 플랜트 2100 조회 시)
SU53 결과:
  - Object: M_MATE_WRK
  - ACTVT = 03 (조회)
  - WERKS = 2100  ← 이 값이 기존 롤에 없음
요청: 담당 업무 확장(화성 플랜트)에 따라 WERKS 2100 조회 권한 추가 요청
근거: 2026-07-28자 조직개편 공지 (첨부)

실무 팁 두 가지를 덧붙입니다.

  • 스크린샷보다 텍스트: SU53 화면에서 해당 항목을 펼친 상태로 캡처하되, Object/Field/Value는 텍스트로도 병기하세요. 담당자가 PFCG에서 바로 검색할 수 있습니다.
  • 배치/백그라운드 오류: 백그라운드 잡의 권한 오류는 대화 세션이 없어 SU53으로 못 봅니다. 이 경우 잡 로그와 STAUTHTRACE(장기 권한 트레이스)를 사용하는 것이 일반적입니다.

[3단계] 운영 관점: 담당자가 SU53 결과를 검증·반영하는 흐름

권한 담당자 입장에서 SU53 결과를 그대로 믿고 값을 추가하는 것은 위험할 수 있습니다. 프로덕션에서 권장되는 검증 순서는 다음과 같습니다.

  1. SUIM 교차 확인: User → "Users by Complex Selection Criteria"로 해당 사용자가 실제 그 값을 보유했는지 재확인. SU53 버퍼가 오래된 세션 기록일 가능성을 배제합니다.
  2. STAUTHTRACE 재현: 사용자에게 동일 작업을 재현시키고 트레이스로 전체 검사 순서를 확보합니다. SU53은 실패 건 중심이라, 실패 직전에 통과한 검사들의 맥락이 빠질 수 있습니다.
  3. SU24 제안값 확인: 해당 트랜잭션의 기본 권한 제안(Default Values)을 확인해 롤 설계 표준에 맞게 반영합니다. 개별 값 땜질(수동 오브젝트 추가)보다 메뉴 기반 롤 재생성이 장기적으로 안전합니다.
  4. SoD(직무분리) 점검 후 이관: 예컨대 자재마스터 생성 권한(ACTVT 01)과 재고 이동 권한을 한 사람에게 몰아주면 감사 지적 대상이 될 수 있습니다. 검토 후 DEV→QAS→PRD 순으로 롤을 이관합니다.

6. Failed Check 읽기 요령 — 헷갈리기 쉬운 3가지 패턴

  • 패턴 A: S_TCODE 단독 실패 → 진입 자체가 막힌 것. 롤 메뉴에 트랜잭션 추가가 정석입니다.
  • 패턴 B: 업무 오브젝트 실패 (M_MATE_WRK 등) → 진입은 됐고 데이터 범위(플랜트, 회사코드 등)가 부족한 것. 기존 롤의 조직 레벨 값 확장을 검토합니다.
  • 패턴 C: 실패 기록이 최근 오류와 무관 → SU53 버퍼에는 사용자가 인지하지 못한 "무해한 실패"도 남습니다. 일부 프로그램은 권한을 검사해 실패하면 조용히 기능을 숨기고 정상 진행하기 때문입니다. 타임스탬프가 오류 발생 시각과 일치하는지 반드시 확인하세요. 이것이 SU53 오독의 가장 흔한 원인입니다.

7. SU53 vs 다른 도구 — 언제 무엇을 쓰나

도구용도쓰는 시점
SU53내 세션의 최근 실패한 권한 검사 조회오류 직후 30초 진단
STAUTHTRACE (ST01 후속)특정 사용자의 권한 검사 전체를 실시간 추적 (성공/실패 모두)SU53만으로 원인이 불명확할 때, 재현 가능한 경우
SUIM사용자/롤/오브젝트 보유 현황 리포트"이 사용자가 이 권한을 갖고 있나" 확인
SU24트랜잭션별 권한 제안값(Default Values) 유지보수롤 설계·수정 시 (담당자 영역)
PFCG롤 생성/수정/배포실제 권한 부여 작업

한 줄 요약: SU53은 진단, STAUTHTRACE는 정밀 검사, SUIM은 현황 조회, SU24/PFCG는 처방입니다. 최종 사용자 입장에서는 SU53까지가 본인 몫이고, 그 결과를 근거 자료로 넘기는 순간 역할이 끝납니다.

8. 자주 만나는 권한 오브젝트 Top 5

  • S_TCODE — 트랜잭션 실행 자체. 모든 권한 오류의 출발점.
  • M_MATE_WRK / M_MATE_STA — 자재마스터의 플랜트/뷰 단위 권한. MM 계열 오류 단골.
  • F_BKPF_BUK — 회계전표의 회사코드 권한. FI 조회·전기 오류의 대부분.
  • M_MSEG_WMB / M_MSEG_BWA — 자재문서의 플랜트/이동유형 권한. MIGO 오류 시 자주 등장.
  • S_DATASET / S_GUI — 서버 파일 접근·파일 다운로드 권한. 엑셀 다운로드가 안 될 때 의심 대상.

9. 자주 묻는 질문과 트러블슈팅

Q1. SU53을 실행했는데 "No authorization error found" 또는 엉뚱한 기록만 나옵니다.

오류 발생 세션과 다른 세션(다른 GUI 창, 다른 앱 서버)에서 실행했거나, 오류 이후 다른 작업을 해서 기록이 밀렸을 가능성이 큽니다. 오류를 재현한 뒤 같은 창에서 즉시 /nSU53을 실행하세요. 재현이 어려우면 STAUTHTRACE로 넘어가는 것이 일반적입니다.

Q2. SU53에 빨간 실패 기록이 있는데, 사실 업무는 정상 동작합니다. 권한을 요청해야 하나요?

아닙니다. 프로그램이 선택적으로 기능을 숨기기 위해 수행한 검사 실패일 수 있습니다(6장 패턴 C). 실제 화면 오류 메시지와 타임스탬프가 일치하는 항목만 요청 근거로 쓰세요. 불필요한 권한 추가는 감사 리스크만 키웁니다.

Q3. Fiori 앱에서 권한 오류가 났는데 SU53이 소용없어 보입니다.

Fiori는 프론트엔드(카탈로그·타일 권한)와 백엔드(OData 서비스·업무 권한)가 분리되어 있습니다. 백엔드 업무 권한 실패라면 해당 백엔드 시스템에서 본인 계정으로 SU53/STAUTHTRACE 확인이 가능하지만, 타일이 아예 안 보이는 문제는 카탈로그 할당 문제이므로 SU53 범위 밖입니다.

Q4. 다른 사용자의 SU53을 대신 봐줄 수 있나요?

SU53 초기 화면에서 사용자 ID를 지정해 조회할 수 있으나, S_USER_AUT 등의 관리 권한이 일반적으로 필요합니다. 권한 담당자·운영자 역할에 해당하는 기능입니다.

10. 이후에 살펴볼 주제

SU53으로 "읽는 법"을 익혔다면, 다음 순서로 확장하는 것을 권장합니다.

  • STAUTHTRACE 실전 활용 — 재현 가능한 오류의 전체 검사 흐름 추적
  • PFCG 롤 설계 기초 — 메뉴 기반 롤과 조직 레벨(Org Level) 개념
  • SU24 제안값 관리 — 커스텀 트랜잭션(Z-트코드)에 권한 검사를 심는 법
  • S/4HANA Fiori 권한 모델 — 카탈로그/스페이스와 백엔드 롤의 이중 구조

11. 더 깊이 볼 만한 문서

댓글 0

아직 댓글이 없습니다.