솔루션 홈
내부통제

SAP 직무분리(SoD) 상충 점검 — 마스터 변경과 지급 실행 권한이 한 사람에게 몰려있지 않은가

권한은 나눠줬는데, 실제로 겸직하고 있는 사람은 없는지 활동 이력으로 확인합니다

직무분리(Segregation of Duties)는 한 사람이 서로 견제해야 할 두 업무를 동시에 맡지 않도록 하는 가장 기본적인 내부통제 원칙입니다. 문제는 권한 부여 시점에는 분리돼 있던 역할이 조직 개편이나 겸직, 임시 대행 과정에서 슬그머니 한 사람에게 몰리는 경우입니다. 전표를 입력한 사람이 같은 전표를 승인하거나, 거래처 계좌를 바꾼 사람이 그 거래처로 지급까지 실행하는 식입니다. 권한 부여 내역만 봐서는 이런 겸직이 실제로 발생했는지 알 수 없고, 활동 이력을 직접 대조해야 드러납니다.

표준 원장·마스터 변경이력 구조를 그대로 이어받아, 회계연도·기간별로 사용자가 수행한 기능을 집계하고 이를 상충 규칙(겸직하면 위험한 기능 조합)과 대사해 상충 후보를 가려내는 화면을 OpenUI5로 확장했습니다. 판정 결과는 항상 "확인 필요"로 표시해 담당자가 직접 경위를 확인하도록 안내합니다. 실제 구동 화면 3종을 함께 공개합니다.

SAP 표준 기능을 그대로 이어받은 부분

  • 변경이력 — 마스터 변경 사용자·일시는 표준 변경문서 구조(CDHDR/CDPOS)를 그대로 활용
  • 전표 원천 — 입력·승인 사용자는 표준 전표 헤더 구조를 그대로 사용
  • 표준 화면 — 전표 개별 항목 조회(FBL3N) · 변경문서 조회(FB04)
항목내용
업무 영역재무회계(FI) · 내부통제
관련 대상 영역- (내부통제 · 직무분리)
Namespacezui5.sodcheck
셸 구조조회조건 영역(우측 조회) + 상충 결과 목록, 상세 Dialog
화면 수조회 화면 1개 + 상세 다이얼로그
SAP 표준 T-code- (연관 화면은 §7 참고)
성격조회·집계·대사형 — 통제 이슈 해당 여부의 최종 확인은 회사·감사인 몫
UI 테마sap_horizon 단일 적용

실제 화면 3종 둘러보기

회계연도·기간·위험등급·사용자ID를 넣고 조회하면 상충 후보 목록이 뜹니다 → 행을 클릭하면 그 사용자·규칙의 근거 활동이 다이얼로그로 열립니다.

아래는 실제로 앱을 실행해 기능을 눌러 가며 캡처한 화면입니다. 이미지를 클릭하면 원본 크기로 확대됩니다.

Main.view.xml
직무분리 상충 점검 메인화면 — 조회조건과 상충 결과 목록
상충 결과 목록 — 조회조건 영역 오른쪽 끝에 조회·초기화 버튼이 있고, 위험등급은 색상으로 구분됩니다. 점검상태는 기본적으로 "확인 필요"로 표시됩니다.
조회 결과 — 필터·정렬
사용자ID 조건으로 조회하고 합계건수로 정렬한 화면
사용자ID 조건 조회 — 사용자ID에 특정 문자열을 포함하는 건만 걸러 합계건수 내림차순으로 정렬한 결과입니다.
상세 다이얼로그
행 클릭 시 뜨는 활동 상세 다이얼로그
활동 상세 — 행을 클릭하면 그 사용자·규칙 조합의 근거가 된 두 기능의 활동 건수를 다이얼로그로 확인합니다.

조작 방법

  1. 회계연도 · 기간 · 위험등급 · 사용자ID를 지정합니다.
  2. 사용자ID 입력 필드에서 Enter 키를 누르거나 조회조건 영역 오른쪽 끝의 조회 버튼을 누르면 재조회됩니다. 초기화 버튼은 조건을 기본값으로 되돌립니다.
  3. 위험등급을 "전체"로 두면 위험등급 조건 없이 조회합니다.
  4. 결과 목록의 행을 클릭하면 상세 다이얼로그가 열립니다.

상충 판정 로직

같은 사용자가 같은 회계연도·기간에 상충 규칙의 두 기능(A, B)을 모두 수행한 이력이 있으면 상충 후보로 판정합니다.

판정 조건결과 상태사용자 조치
동일 사용자가 같은 기간에 규칙의 기능A·기능B를 모두 수행확인 필요활동 상세를 열어 두 기능의 수행 경위·승인 여부를 확인
사용자ID가 테스트 계정 명명 규칙에 해당예외(테스트 계정)정기 점검 대상에서 제외하되 목록에는 유지
기능A 또는 기능B 중 하나만 수행목록에 나타나지 않음해당 없음(상충 후보 아님)

이 화면이 대신 정하지 않는 것

같은 두 기능을 수행했다고 해서 곧바로 통제 위배로 단정하지 않습니다. 대행 승인이나 임시 겸직처럼 정당한 사유가 있을 수 있어, 통제 이슈 해당 여부에 대한 최종 판단은 회사와 감사인이 합니다. 이 화면은 그 판단이 필요한 후보를 골라내는 점검 도구입니다.

집계·대사 처리 단계

단계내용
1단계회계연도·기간·사용자·기능코드별 활동 건수를 집계
2단계상충 규칙에 정의된 기능A·기능B 조합과 동일 사용자·기간의 활동 유무를 대조
3단계두 기능 모두 활동이 있으면 활동건수A·활동건수B·합계건수를 산출
4단계합계건수 = 활동건수A + 활동건수B 가 항상 성립하는지 전수 검증
5단계테스트 계정은 점검상태를 "예외(테스트 계정)"로 별도 표시

조회조건

필드필수설명
회계연도필수4자리 연도
기간선택01~12, 비우면 전체 기간
위험등급선택전체/높음/중간/낮음(전체 선택 시 조건 미전달)
사용자ID선택부분 일치(포함), Enter 키로 바로 조회

결과 컬럼

컬럼설명
사용자ID · 사용자명상충 후보 사용자
규칙 · 기능A · 기능B매칭된 상충 규칙과 두 기능(표준 T-code 기준)
위험등급규칙의 위험도(높음/중간/낮음)
활동건수A · 활동건수B · 합계건수같은 기간 동안 각 기능을 수행한 건수와 합계
최근활동일 · 점검상태두 기능 중 더 최근 활동일, 확인 필요/예외(테스트 계정)

SAP 표준 기능 매핑

SAP 표준 T-code연관 기능
FB50전표입력
FBV0기표 승인(반출)
FK02공급업체 마스터 변경
FI12은행 마스터 변경
F110자동 지급 실행
FCH5 / FCH8수표 발행 / 취소·재발행
FS00계정과목 마스터 변경
MIRO매입송장 검증

통제 기준 정의표

관련 대상 영역요구사항대응 기능원천 데이터비고
-전표 입력과 승인 직무의 분리규칙 R01전표 헤더대상 영역: 내부통제
-지급 관련 마스터 변경과 지급 실행의 분리규칙 R02, R03거래처·은행 마스터 변경이력, 지급 실행이력대상 영역: 내부통제
-수표 발행과 취소·재발행 직무의 분리규칙 R04수표 발행·취소 이력대상 영역: 내부통제
-계정 마스터 변경과 그 계정 전표입력의 분리규칙 R05계정 마스터 변경이력, 전표 헤더대상 영역: 내부통제

도입 시 확인이 필요한 부분

상충 규칙의 구체적인 조합과 위험등급은 회사의 통제 매트릭스·권한 설계에 맞춰 확정해야 합니다.

참고 CDS 뷰

운영 서비스로 연결할 때를 가정해 새로 스케치한 집계 뷰 예시입니다(운영 반영 시 권한 체크를 추가해야 합니다).

@AbapCatalog.sqlViewName: 'ZCDSSODACT'
define view ZCDS_I_UserActivity
  as select from cdhdr
  left outer join bkpf
    on bkpf.usnam = cdhdr.username
{
  key cdhdr.username   as UserId,
  key cdhdr.objectclas as FunctionArea,
      cdhdr.gjahr       as Gjahr,
      cdhdr.tcode_cd    as Period,
      count(*)          as ActivityCount
}
// 상충 판정은 이 집계와 규칙 테이블을 사용자·기간 기준으로 대사해 산출

OpenUI5 구성

기능사용 컨트롤
화면 골격sap.m.Page + 조회조건 Panel + 상충 결과 목록
조회조건sap.m.ComboBox · sap.m.Input — 우측 끝에 조회 버튼, Enter 키로 즉시 재조회
상충 결과 목록sap.ui.table.Table(컬럼 10개 초과) — 행 클릭 시 상세 다이얼로그
상세sap.m.Dialog — 선택 행의 사용자·기간·기능 조건으로 활동 이력 재조회
공통 처리전역 오류 처리기(ErrorHandler)

서비스 경로는 manifest.jsondataSources 에 상대 경로로 선언한 OData 모델을 그대로 바인딩하며, 조회조건은 sap.ui.model.Filter 로 조립해 $filter 로만 전달합니다. 위험등급을 "전체"로 둘 때는 필터를 아예 생성하지 않습니다.

파일 구성

경로역할
index.htmlOpenUI5 부트스트랩 — sap_horizon
Component.js컴포넌트 초기화, 전역 오류 처리기 연결
manifest.json앱 디스크립터 — zui5.sodcheck · OData dataSources · ko 로케일
view/Main.view.xml조회조건 + 상충 결과 목록
view/DetailDialog.fragment.xml활동 상세 다이얼로그
controller/Main.controller.js조회·필터 조립·다이얼로그 로직
controller/BaseController.js공통 처리
model/ErrorHandler.js전역 오류 처리
model/formatter.js위험등급·점검상태 서식
i18n/i18n_ko.propertiesko 로케일 리소스

검증 환경 구성 상세는 이 글에서 다루지 않습니다. 운영 전환 시에는 화면과 판정 로직은 그대로 두고 데이터 계층만 실제 서비스 호출에 맞추면 됩니다.

검증 결과

화면 구성에 쓴 데이터는 합계건수 = 활동건수A + 활동건수B 관계가 항상 성립하도록 구성했습니다.

검증 항목결과
대사식 전수 검증(합계건수 = 활동건수A + 활동건수B)통과(불일치 0건)
표시 금지 검사 — 커스텀 프로그램ID·앱 식별자·출처 표현 검출0건
화면 렌더링 — 실브라우저에서 조회 → 필터 → 행 클릭 상세까지 실동작 후 캡처3/3
조회 버튼 위치 · sap_horizon 테마 적용 · Enter 키 조회확인
OData 계약 — 동사 경로 미사용, $filter·$orderby 로만 조회조건 전달확인

사용자·활동 건수는 모두 검증용으로 구성한 가상 데이터입니다.

자주 묻는 질문

이 화면은 어느 범위에 적용하나요?

재무회계 시스템에서 전표입력·승인, 거래처·은행·계정 마스터 변경, 지급 실행, 수표 발행·취소, 매입송장 검증 권한을 보유한 사용자를 대상으로 하며, 회계연도와 기간을 선택해 조회합니다.

점검상태가 "확인 필요"로 뜨면 무엇을 의미하나요?

같은 사용자가 같은 기간에 상충 규칙의 두 기능을 모두 수행한 이력이 있다는 신호입니다. 이 화면은 상충 후보를 골라내는 점검 도구이며, 통제 이슈 해당 여부에 대한 최종 판단은 회사와 감사인이 합니다.

화면의 수치는 실시간 SAP 데이터인가요?

실제 운영 화면은 OData 서비스를 통해 조회합니다. 이 글에 표시된 수치와 캡처는 검증용 샘플 데이터이며 실제 업무 데이터가 아닙니다.

상충 규칙은 어떻게 구성되나요?

서로 겸직하면 위험한 두 기능(예: 전표입력과 기표승인)을 한 쌍으로 정의하고 위험등급을 부여합니다. 회사의 통제 매트릭스 개정에 맞춰 규칙을 추가·변경할 수 있으며, 화면의 판정 로직 자체는 바뀌지 않습니다.

직무분리 상충, 결산 전에 활동 이력으로 먼저 확인해보세요

권한 부여 내역만으로는 드러나지 않는 겸직을 활동 이력 대사로 미리 확인해 두면, 통제 점검과 감사 대응이 한결 가벼워집니다. 현재 SAP 환경 기준으로 어떻게 적용되는지 함께 확인해 드립니다.

내부통제직무분리SoD권한 통제전표 통제OpenUI5