AX Case 07 · 내부통제자문팀 · Risk LoS 첫 사례
SoD(직무분리) 위반 전수 스크리닝 — (주)한빛유통 사례
실무자 한 명(SoD 룰셋 설계 리드)의 업무 하나 — ERP 사용자 권한의 직무분리(SoD) 위반 전수 스크리닝 — 를 AI로 실험한 기록입니다. 감사팀의 저널엔트리 테스트(사례 3호)에 이어Risk LoS(내부통제자문)를 처음 관통한 사례이자, 정형 데이터 전수 스크리닝 패턴이 감사 밖 도메인에서도 재현되는지 검증합니다. 이번 사례의 핵심도 성공이 아니라 한계 — 권한 매트릭스 룰이 놓친 차명 사용 2건을 그대로 공개합니다.
0건
가상 권한 매트릭스
0건
전표 실행 이력
0건
위반 후보(보유 수준)
0건
미탐(rule-blind)
1 · Task
업무 정의 — 판단은 인간, 실행은 AI
`docs/firm-map/slots/risk-advisory.md` risk-task-01 카드의 분담을 그대로 따릅니다.
인간이 할 것
- SoD 룰셋(권한 조합 정의) 확정(매니저 risk-manager-1)
- 위반 건 실질 판단(보상통제 여부 검토)
- 개선권고 승인(파트너 risk-partner-1 검토)
AI가 할 것
- 가상 권한 매트릭스·전표 데이터 전수 스크리닝(2단)
- 위반 후보 추출·리스크 스코어링
- 자문 보고서 스타일 요약 초안 생성
- 룰셋 구조적 한계 자체 기록(미탐 위험 고지)
전환 지점
- 인간: SoD 룰셋(권한 조합 정의) 확정 → AI: 가상 권한·전표 데이터 전수 스크리닝·위반 후보·리스크 스코어 산출
- AI: 위반 후보·스코어링 결과 제시 → 인간: 위반 건 실질 판단(보상통제 여부)·개선권고 승인(파트너 검토)
2 · Input
입력 — 완전 가상 시나리오
본 시나리오는 완전 가상입니다 — 실존 기업·인물과 무관합니다(등장 인명 전부 합성).가상 중견 유통사 (주)한빛유통(ERP 사용, 회계·구매·판매·물류 모듈 통합운영)의 회계·구매·판매 모듈 사용자 권한을 대상으로, 내부통제 자문의 일환으로 권한 매트릭스와 최근 3개월 전표 실행 이력을 대사하는 SoD 위반 전수 스크리닝을 의뢰받았습니다.
모집단 명세
- 소스: `scripts/generate_access.py`(seed 고정 20260712b, 표준 라이브러리만 사용)로 생성한 가상 권한·전표 데이터.
- 사용자 180명(8개 부서, 직급 5단계) — 그중 2명은 퇴사자(계정 비활성화 처리 누락).
- 권한(트랜잭션 코드) 43개, 권한 매트릭스 672행.
- 전표 실행 이력 7,875건(2026-04-13~2026-07-12, 최근 90일, 타임스탬프·IP·금액 포함).
SoD 룰셋 10종
`scripts/screen_sod.py` 구현과 1:1 대응. 룰 10종 전부가 정확히 1건씩 히트했습니다.
| 룰 | 이름 | 충돌 코드 | 보유 위반 |
|---|---|---|---|
| R01 | 공급업체 마스터 등록↔대금 지급 실행 | VM_CREATE ↔ PAY_EXEC | 1건 |
| R02 | 전표 입력↔전표 승인 | JE_ENTER ↔ JE_APPROVE | 1건 |
| R03 | 구매 발주↔입고 처리 | PO_CREATE ↔ GR_POST | 1건 |
| R04 | 판매 주문↔여신 한도 변경 | SO_CREATE ↔ CREDIT_LIMIT_CHANGE | 1건 |
| R05 | 급여 마스터↔급여 지급 | PAYROLL_MASTER ↔ PAYROLL_EXEC | 1건 |
| R06 | 재고 조정↔재고 실사 확정 | INV_ADJUST ↔ INV_COUNT_CONFIRM | 1건 |
| R07 | 사용자 권한 부여↔권한 승인(ITGC) | USER_ROLE_GRANT ↔ USER_ROLE_APPROVE | 1건 |
| R08 | 은행계좌 마스터↔지급 실행 | BANK_MASTER ↔ PAY_EXEC | 1건 |
| R09 | 매출채권 감액↔수금 처리 | AR_WRITEOFF ↔ CASH_RECEIPT | 1건 |
| R10 | 결산 전표↔결산 승인 | FS_CLOSE_ENTRY ↔ FS_CLOSE_APPROVE | 1건 |
3 · AI Execution
AI 실행 — 2단 전수 스크리닝
AI는 모집단 전체(표본 추출 아님)를 2단으로 스크리닝했습니다. 1단(보유 수준) — 동일 user_id가 충돌 코드 A·B를 모두 보유하는가(access.csv 조인). 2단(실행 수준) — 보유 위반 후보 중 최근 3개월 전표 실행 이력에서 A·B가 모두 실제 실행됐는가(txlog.csv 대사, 고위험 신호). 리스크 스코어는 보유 기본점수(3) + 실행 수준 확인 가산(+5) + 실행 금액 5천만원당 +1로 계산해 위험도를 차등화했습니다.
3.1 위반 후보 목록(리스크 스코어순, 10건 전부)
| 순위 | user_id | 부서/직급 | 룰 | 실행 수준 | 실행 금액(원) | 스코어 |
|---|---|---|---|---|---|---|
| 1 | U162 | 회계팀/과장 | R02 전표 입력↔전표 승인 | Y | 52,570,000 | 9 |
| 2 | U163 | 물류팀/대리 | R03 구매 발주↔입고 처리 | Y | 71,890,000 | 9 |
| 3 | U164 | 판매팀/과장 | R04 판매 주문↔여신 한도 변경 | Y | 67,410,000 | 9 |
| 4 | U161 | 구매팀/과장 | R01 공급업체 마스터 등록↔대금 지급 | Y | 49,640,000 | 8 |
| 5 | U165 | 인사팀/과장 | R05 급여 마스터↔급여 지급 | Y | 25,250,000 | 8 |
| 6~10 | U166~U170 | 물류·IT·자금·회계 | R06~R10 각 1건 | N(보유만/편측) | 0 | 3 |
상위 5건(스코어 8~9)은 실행 수준까지 확인된 고위험군, 나머지 5건(스코어 3)은 보유만 또는 편측 실행 — 실행 증거는 없지만 권한 과다 부여 자체가 통제 미비입니다. 전체 상세는 `docs/cases/2026-07-12-risk-sod-screening/screening-log.md`(레포 내부)에서 발췌.
실험 중 자가 교정 — 정상 population 잡음 보정
초기 구현에서 8개 부서 권한 템플릿을 무작위 샘플링한 결과, 충돌 코드 쌍(예: 회계팀의 JE_ENTER/JE_APPROVE)이 같은 부서 템플릿 안에 함께 존재해 우연히 동시 배정되는 "우연한 보유 위반"이 34건 발생했습니다(심은 10건 대비 3.4배 잡음). AI가 이를 스스로 발견해 "정상 사용자는 SoD 룰셋 충돌 쌍을 동시에 보유하지 않도록" 보정 로직을 추가하고 재실행한 뒤, 보유 위반이 정확히 심은 10건으로 수렴함을 확인했습니다 — 실제 ERP 권한 부여 프로세스에서도 "부서 표준 역할(role template) 자체에 충돌 조합이 포함돼 있는 것"이 흔한 실패 유형이라는 점을 이 시행착오가 방증합니다. 위 통계는 보정 반영 후 결과입니다.
4 · Rule-blind Disclosure
미탐 — 룰은 정의된 위험만 본다
심은 위반 12건 중 10건은 표준 룰셋(권한 매트릭스)에 걸리도록, 2건은 의도적으로 룰셋을 통과하도록 설계해 심었습니다. 결과는 설계대로 — 위반 후보 목록에 두 건 모두 나타나지 않았습니다(`grep -i "U171\|U172\|U173\|U174" violations.csv` → 0건).
B01·B02 — 차명 사용(퇴사자 계정 대리 실행)
B01: 실제 담당자(구매팀 사원)가 VM_CREATE만 보유하고, 퇴사자 계정(자금팀, 권한 회수 누락)이 PAY_EXEC를 잔존 보유합니다. 담당자가 VM_CREATE를 실행한 17~41분 뒤, 퇴사자 계정이 동일 IP에서 PAY_EXEC를 실행했습니다(2회 반복 패턴). B02도 동일 구조 — IT팀 사원이 USER_ROLE_GRANT만 보유하고, 퇴사자 계정이 USER_ROLE_APPROVE를 잔존 보유해, 권한 부여 12분 뒤 동일 IP에서 승인이 실행됐습니다(본인이 부여한 권한을 본인이, 퇴사자 계정을 빌려 승인한 정황).
두 건 모두 충돌 코드 A·B를 각각 서로 다른 두 계정에 분산 보유시켜, 동일 user_id 기준으로 동작하는 권한 매트릭스 룰이 원천적으로 인식할 수 없도록 설계했습니다. 형식상 권한은 정상적으로 분리돼 있지만, 신원(동일 IP·근접 시간대)을 교차 확인해야만 드러나는 구조적 한계입니다.
이 미탐은 감점 사유가 아니라 경계 증거입니다. "AI 전수 스크리닝은 룰이 정의된 위험만 본다 → 룰셋 설계·갱신과 실질 판단은 인간의 일"이라는 전제(판단은 인간, 실행은 AI)를 데이터로 실증합니다.사례 3호(감사 JE 전수 테스트, 거래상대방 갭)에 이은 두 번째 실증 — 룰셋 도메인은 다르지만("전표 필드 검사"↔"신원 교차 검사"), "정의된 신호 밖은 못 본다"는 같은 패턴이 축적되고 있습니다.
룰셋 갱신 제안(승인 필요, 실험 범위 밖)
- 퇴사자(비활성 상태) 계정의 실행 이력 존재 자체를 즉시 플래깅하는 룰(R11 후보) 추가.
- 동일 IP·근접 시간대(예: 60분 이내)에 서로 다른 두 user_id가 충돌 코드 A·B를 각각 실행하는 신원 교차 룰(R12 후보) 추가.
- 퇴사 처리 시점과 계정 비활성화 시점의 갭(deprovisioning lag)을 별도 ITGC 결함 지표로 분리 보고.
룰 확장 자체는 인간(매니저 risk-manager-1) 승인 후 다음 반복에서 수행 — 이번 실험은 권한 매트릭스 룰셋 설계·초기 버전 검증까지가 범위입니다.
5 · Output
산출물 — 자문 보고서 스타일 요약 초안
AI 산출물은 모집단 요약 → 절차 → 결과 요약 → 위반 후보 목록·후속절차 제안(스코어순) → 미탐 위험 고지 순서의 조서 구조를 따릅니다. 위반 건 최종 판단(보상통제 여부)과 개선권고 승인 란은 전부 비어 있습니다.
조서 승인 — 인간 검토 대기
| 단계 | 담당 | 상태 |
|---|---|---|
| 1차 판단(위반 건 보상통제 검토) | risk-manager-1 | 인간 검토 대기 |
| 2차 검토(개선권고 초안 확정) | risk-director-1 | 인간 검토 대기 |
| 최종 승인 | risk-partner-1 | 인간 검토 대기 |
승인 체인·서명은 실제 서명을 시뮬레이션하지 않습니다 — 본 실험 범위 밖. 특히 B01/B02 미탐 사실은 조서 §5(미탐 위험 고지)에 명시적으로 남깁니다.
6 · Verdict
판정 — AX 가능, 재현성 게이트로 확인
이 사례는 지식엔진 소비가 없는 정형 데이터 업무입니다 — 생성 스크립트+seed 고정 독립 재실행이 게이트를 대체합니다(사례 3호와 동일 방식, Risk LoS에서의 첫 적용).
| 게이트 검사 | 결과 |
|---|---|
| 재현성 — generate_access.py(seed 20260712b)+screen_sod.py 독립 재실행 | 완전 일치 — 사용자 180·권한 672·이력 7,875·위반 후보 10건 |
| 심은 위반 회수 — exception-spec.md 정답지 대조 | 보유 수준 10/10(룰 10종 각 1건), 실행 수준 고위험 5/5 분별(스코어 8~9 vs 보유만 3) |
| rule-blind 검증 — 차명 사용 2건(퇴사자 계정 대리 실행) | 설계대로 0/2 미탐(독립 grep 0건) — 단일 user_id 검사의 구조적 한계로 정직 기록 |
| 2단 스크리닝 구조 | 보유(matrix join)→실행(이력 교차) 분리로 위험도 차등화 성립 |
| 의사결정 대행 금지 | 준수 — 실질 판단·보상통제 평가·승인 란 "인간 검토 대기" 공란 |
| 실험 중 자가 교정 | 정상 population 우연 충돌 34건 잡음 → 보정 후 심은 10건으로 수렴(로그에 투명 기록) |
판정 근거
AI 측은 ai_side 계약("권한·전표 전수 스크리닝 + 위반 후보·리스크 스코어")을 완주했습니다 — 보유/실행 2단 스크리닝이 심은 위반을 전량 회수하면서 위험도(실행>보유)를 정확히 차등화했고, 전 과정이 스크립트+seed로 결정적으로 재현됩니다. 감사(JE)에 이어 Risk 도메인에서도 정형 데이터 패턴이 동일하게 성립 — "AI 전수 스크리닝 + 예외만 인간" 서사의 두 번째 실증입니다.
rule-blind 미탐 2건(차명 사용)은 판정 감점 사유가 아니라 경계 증거입니다 — 권한이 형식상 분리돼 있어도 퇴사자 계정 대리 실행은 user_id 기반 룰로 구조적으로 못 잡습니다(동일 IP·근접 시간대라는 행위 패턴 분석 영역). 룰셋 확장 제안(퇴사자 계정 활동 룰·세션 패턴 룰)과 실질 판단은 human_side로 이관했습니다 — 사례 3호의 거래상대방 갭과 함께 "룰은 정의된 위험만 본다" 패턴의 축적입니다.
잔여 한계 (기록)
- 룰셋 10종은 대표 충돌 조합 — 실무 적용 시 회사별 ERP 트랜잭션 체계 매핑이 human_side.
- 보상통제(compensating control) 존재 여부 평가는 문서·인터뷰 영역으로 AX 범위 외.
- 가상 데이터는 단일 회사·단일 시점 — 업종·규모별 일반화는 사례 확장 시 재검증.
Risk LoS 개척으로 주요 LoS 5개 전부에 사례를 확보했습니다. 정형 데이터 패턴이 감사 밖 도메인(내부통제)에서도 재사용됨을 확인 — 패턴 라이브러리(엔진 소비 계열 + 정형 데이터 계열)가 법인 전체 업무 지도로 확장 가능함을 시사합니다.
본 사례의 시나리오·기업·권한 및 전표 데이터·등장 인명은 모두 합성이며 실존 기업·인물과 무관합니다. 데이터는 `scripts/generate_access.py`(seed 고정)로 생성되어 재현 가능합니다. 본 페이지는 내부통제 자문이 아니며, 실제 SoD 진단은 자격 있는 전문가의 판단을 따라야 합니다.