PFCG Single vs Derived — 어떤 역할을 써야? #shorts #SAP #PFCG

📖 이 글에서 다루는 것

SAP 권한 설계의 중심에는 PFCG(Profile Generator) 트랜잭션이 있습니다. 같은 PFCG 안에서도 Single Role, Composite Role, Derived Role은 내부 동작과 적용 시점이 완전히 다르며, 이 선택을 잘못하면 권한 운영 비용이 몇 배로 늘어납니다. 이 글은 세 가지 역할 유형의 생성 원리와 실무 선택 기준을 전국 판매 조직 시나리오로 비교합니다.

세 역할 유형의 Profile 생성 방식 차이를 설명할 수 있다
SU24 기본값이 역할 메뉴와 어떻게 연동되는지 이해한다
지역별 권한 분리에 Derived Role 패턴을 적용할 수 있다
AUTHORITY-CHECK로 역할이 실제 코드에서 검증되는 지점을 확인한다

📚 미리 알아두면 좋은 배경

SAP GUI 기본 조작(SU01, SE38 실행 수준)과 Authorization Object가 필드·값의 묶음이라는 개념을 알고 있으면 충분합니다. ABAP 예제가 포함되지만 문법보다 권한 체크 흐름을 읽는 것이 목적이므로 초급 ABAP 지식이면 따라올 수 있습니다.

🔧 환경 / 버전 / 준비물

이 글의 예제는 SAP S/4HANA 2023(온프레미스) 및 SAP NetWeaver AS ABAP 7.50 이상을 기준으로 합니다. PFCG의 3가지 역할 유형 동작은 ECC 6.0부터 S/4HANA까지 일반적으로 동일하게 유지됩니다.

트랜잭션 접근 권한: PFCG, SU01, SU24, SUIM, PFUD
권한 객체 S_USER_AGR(역할 관리), S_USER_PRO(프로필), S_USER_AUT(권한) 부여 필요
개발/품질 시스템에서 실습 후 CTS(Transport)로 운영 이관하는 방식을 권장
테스트용 판매 조직 데이터: VKORG 1000(서울), 2000(부산) 가정

💡 핵심 개념 — 3가지 역할의 내부 동작

PFCG 역할을 아파트 출입 시스템에 비유하면 이해가 빠릅니다. Single Role은 "카드키 한 장"입니다. 어떤 문(트랜잭션)을 열 수 있고, 몇 층(조직 레벨)까지 갈 수 있는지가 카드 한 장에 인코딩됩니다. PFCG에서 Single Role의 메뉴에 트랜잭션을 추가하면, SU24에 저장된 해당 트랜잭션의 기본 권한 객체 제안값이 Authorization 탭으로 자동으로 끌려 들어오고, Generate 버튼을 누르는 순간 실제 런타임이 참조하는 Authorization Profile이 생성됩니다. 유저 버퍼에 로드되는 것은 역할이 아니라 이 프로필이라는 점이 핵심입니다.

Composite Role은 "카드키 묶음 지갑"입니다. 자체 권한 데이터도, 자체 프로필도 없습니다. 여러 Single Role을 담는 컨테이너일 뿐이며, 유저에게 할당하면 내부의 Single Role들이 풀어져서 각각의 프로필이 유저 버퍼에 들어갑니다. Composite Role의 Authorization 탭이 비활성화되어 있는 이유가 바로 이것입니다. 매핑 정보는 AGR_AGRS 테이블에 저장됩니다.

Derived Role은 "같은 설계도로 찍어낸 지점별 카드키"입니다. 마스터(Imparting) 역할로부터 메뉴와 권한 값을 통째로 상속받되, 조직 레벨(Organizational Level)로 정의된 필드 값만 파생 역할별로 다르게 유지합니다. 마스터에서 "Generate derived roles"를 실행하면 조직 레벨을 제외한 모든 권한 값이 파생 역할로 밀어넣어집니다(push-down). 관계는 AGR_DEFINE 테이블의 PARENT_AGR 필드로 추적할 수 있습니다.

선택 기준을 한 줄씩 정리하면 이렇습니다.

Single: 직무(Job Function) 단위 권한의 기본 빌딩 블록. 모든 설계의 출발점
Composite: 직책(Position) 단위로 여러 직무를 묶어 할당을 단순화할 때
Derived: 동일 직무를 조직 단위(판매조직, 플랜트, 회사코드)별로 값만 바꿔 복제해야 할 때 — 마스터 1회 수정으로 전 지역 반영이 필요하면 사실상 필수

💻 실전 예제 3단계 — 전국 판매 조직 권한 분리

1단계: Single Role과 AUTHORITY-CHECK 기본 흐름

서울 영업팀용 Single Role Z_SD_ORDER_DISPLAY를 만들고 메뉴에 VA03을 추가하면, SU24 기본값에 따라 V_VBAK_VKO(판매조직별 판매문서 권한) 객체가 제안됩니다. 조직 레벨 VKORG에 1000을 입력하고 Generate하면 프로필이 생성됩니다. 커스텀 리포트에서 이 권한이 검증되는 지점은 다음과 같습니다.

REPORT zsd_order_list.

PARAMETERS: p_vkorg TYPE vkorg OBLIGATORY.

START-OF-SELECTION.
  " 유저 버퍼의 프로필에 대해 판매조직 권한을 검증
  AUTHORITY-CHECK OBJECT 'V_VBAK_VKO'
    ID 'VKORG' FIELD p_vkorg
    ID 'ACTVT' FIELD '03'.   " 03 = 조회

  IF sy-subrc <> 0.
    MESSAGE '해당 판매조직에 대한 조회 권한이 없습니다.' TYPE 'E'.
  ENDIF.

  SELECT vbeln, erdat, netwr
    FROM vbak
    WHERE vkorg = @p_vkorg
    INTO TABLE @DATA(lt_orders).

AUTHORITY-CHECK는 역할 이름을 보지 않습니다. 오직 프로필에 담긴 객체·필드·값만 평가한다는 점이 세 역할 유형을 이해하는 열쇠입니다.

2단계: Derived Role로 지역 확장 + 실패 로깅

부산(2000), 대구(3000) 지점이 추가되면 Single Role을 복사하는 대신 마스터 Z_SD_ORDER_MASTER를 만들고, 파생 역할 Z_SD_ORDER_1000, Z_SD_ORDER_2000의 Description 탭에서 마스터를 지정합니다. 각 파생 역할에서는 조직 레벨 VKORG 값만 지역별로 입력합니다. 이후 트랜잭션이 추가되면 마스터에서만 수정하고 "Generate derived roles"로 일괄 반영합니다. 코드 측면에서는 권한 실패를 감사 추적할 수 있도록 로깅을 붙입니다.

DATA(lv_actvt) = COND activ_auth( WHEN p_change = abap_true
                                  THEN '02' ELSE '03' ).

AUTHORITY-CHECK OBJECT 'V_VBAK_VKO'
  ID 'VKORG' FIELD p_vkorg
  ID 'ACTVT' FIELD lv_actvt.

CASE sy-subrc.
  WHEN 0.
    " 통과 — 정상 진행
  WHEN 4.
    " 값 불일치: 다른 판매조직의 파생 역할만 보유한 경우
    zcl_sd_auth_log=>write( iv_object = 'V_VBAK_VKO'
                            iv_vkorg  = p_vkorg
                            iv_reason = 'VALUE_MISMATCH' ).
    MESSAGE e001(zsd) WITH p_vkorg.  " SLG1 연계 후 사용자 안내
  WHEN 12.
    " 객체 자체가 유저 버퍼에 없음: 역할 미할당 또는 프로필 미생성
    zcl_sd_auth_log=>write( iv_object = 'V_VBAK_VKO'
                            iv_vkorg  = p_vkorg
                            iv_reason = 'NO_AUTH_IN_BUFFER' ).
    MESSAGE e002(zsd).
ENDCASE.

sy-subrc 4(값 불일치)와 12(객체 부재)를 구분해 로깅하면, 운영에서 "파생 역할 미할당"과 "프로필 미생성(빨간 신호등)"을 빠르게 구분할 수 있습니다. SU53과 함께 보면 원인 분석 시간이 크게 줄어듭니다.

3단계: 프로덕션 — Composite 조합, 검증 쿼리, 운영 체크

서울 지점장처럼 "주문 조회 + 여신 관리 + 리포트"를 함께 받는 직책에는 Composite Role Z_POS_BRANCH_MGR_1000을 만들어 파생 Single Role들을 묶습니다. 운영 이관 전에는 역할 구조를 테이블로 직접 검증하는 습관을 권장합니다.

-- Composite에 묶인 Single Role 확인
SELECT agr_name, child_agr
  FROM agr_agrs
 WHERE agr_name = 'Z_POS_BRANCH_MGR_1000';

-- 마스터-파생 관계 확인
SELECT agr_name, parent_agr
  FROM agr_define
 WHERE parent_agr = 'Z_SD_ORDER_MASTER';

-- 파생 역할별 실제 권한 값 검증 (VKORG가 지역별로 다른지)
SELECT agr_name, object, field, low, high
  FROM agr_1251
 WHERE object = 'V_VBAK_VKO'
   AND agr_name LIKE 'Z_SD_ORDER_%';

보안·성능 관점의 운영 체크리스트는 다음과 같습니다.

유저 할당 변경 후 PFUD(User Master Comparison)를 배치로 스케줄링해 프로필 동기화 누락 방지 — 미실행 시 역할은 있는데 권한이 없는 상태가 발생
업그레이드 시 SU25로 SU24 기본값을 갱신한 뒤 영향받는 역할을 재생성 — 이 단계를 건너뛰면 신규 권한 객체가 프로필에 반영되지 않음
SUIM으로 "특정 트랜잭션 실행 가능 유저" 역추적 및 STAUTHTRACE로 실제 체크되는 객체를 사전 확인
파생 역할 이름에 조직 값을 접미어로 넣는 네이밍(_1000)으로 감사 대응 용이성 확보

⚠️ 흔한 실수 / 트러블슈팅

Q1. Composite Role에 권한을 직접 넣으려는데 탭이 비활성입니다. 정상 동작입니다. Composite는 컨테이너일 뿐 자체 프로필이 없습니다. 권한 수정은 반드시 내부 Single Role에서 해야 하며, Composite에 메뉴를 커스터마이징해도 권한에는 영향이 없습니다.
Q2. Derived Role에서 개별 수정한 권한 값이 사라졌습니다. 마스터에서 "Generate derived roles"를 실행하면 조직 레벨이 아닌 모든 값이 마스터 기준으로 덮어써집니다. 파생 역할에 수동으로 넣은 비조직 필드 값은 상속 시 유실되므로, 지역별로 달라야 하는 값이 조직 레벨이 아니라면 그 필드는 Derived 패턴에 맞지 않는다는 신호입니다. 별도 Single Role로 분리하는 편이 안전합니다.
Q3. 역할을 할당했는데 sy-subrc 12가 계속 발생합니다. 세 가지를 순서대로 확인하세요. (1) 역할의 신호등이 초록인지(프로필 Generate 여부), (2) SU01 Roles 탭의 유효기간, (3) PFUD 비교 실행 여부. 특히 운송(Transport) 직후에는 대상 시스템에서 프로필 재생성과 유저 비교가 일반적으로 다시 필요합니다.
Q4. Composite와 Derived 중 무엇으로 지역 분리를 해야 하나요? 지역마다 "같은 직무, 다른 조직 값"이면 Derived가 정답입니다. Composite로 지역별 Single Role을 묶어 흉내 내면 트랜잭션 추가 시 지역 수만큼 반복 수정이 필요해 유지보수가 무너집니다. Composite는 어디까지나 "서로 다른 직무의 묶음"에만 사용하세요.

🚀 이어서 보면 좋은 주제

역할 설계를 익혔다면 SU24 제안값 커스터마이징으로 커스텀 트랜잭션의 권한 기본값을 표준화하는 작업이 자연스러운 다음 순서입니다. 이후 SUIM 기반 SoD(직무 분리) 점검, STAUTHTRACE를 활용한 최소 권한 도출, S/4HANA 환경이라면 Fiori 카탈로그/스페이스 권한(S_SERVICE, IWSG/IWSV)과 PFCG 역할의 연결까지 확장해 보시길 권장합니다. BTP 쪽 권한 모델(Role Collection)과의 개념 비교도 흥미로운 주제입니다.

📚 더 읽어볼 자료

SAP Help Portal — Role Administration (PFCG)
SAP Help Portal — AS ABAP Authorization Concept
SAP Help Portal — Editing Default Values (SU24)
SAP Community — Security 토픽 (역할 설계 실무 토론)
SAP Support Portal — Security 개요 및 관련 Note 검색
SAP Help Portal — S/4HANA 온프레미스 보안 가이드 (버전별 확인 권장)

댓글 0