'else' 공백: 컴포지트 리스크가 보안 룰 사이에 숨는 방식

개요

통제 담당자에게 리스크가 어디 있냐고 물으면 룰 위반을 가리킬 것입니다. 차단된 거래, 플래그된 로그인, 격리된 파일입니다. 하지만 성숙한 룰 기반 환경에서 위반은 오히려 건강한 부분입니다. 룰이 작동하고 있다는 증거이기 때문입니다. 진짜 위험은 더 조용한 곳에 있습니다. 어떤 룰에도 매칭되지 않은 모든 이벤트가 소리 없이 '허용' 또는 기껏해야 '로그'로 처리되는 else 분기입니다. 이 글에서는 그 else 공백의 세 가지 형태를 정리하고, 룰을 한 줄도 다시 쓰지 않고 이를 메우는 방법을 보여줍니다.

배경: 공백은 우연이 아니라 구조입니다

if-else 엔진은 설계 시점에 열거된 것만 판정할 수 있습니다. 정의되지 않은 모든 것은 판정을 완전히 우회합니다. 이것은 룰의 버그가 아니라 룰을 정의하는 속성입니다. 기업이 수년에 걸쳐 룰을 축적하면 커버된 영역은 촘촘해지지만, '점검할 생각조차 하지 못한 것'의 경계는 결코 사라지지 않습니다. 정교한 리스크는 바로 그 경계로 이동합니다. 감시되지 않을 것이 보장된 유일한 지점이기 때문입니다.

형태 1: 커버리지 공백 — 해당하는 룰 자체가 없다

관리자가 휴가 중이라 ERP 승인 권한이 대리위임된 상황을 생각해 보십시오. 직무분리(SoD) 매트릭스에 '위임'이라는 개념이 없다면, 위임된 승인은 관대하게 평가되는 것이 아니라 아예 평가되지 않습니다. 매트릭스는 표현할 수 없는 것을 플래그할 수 없습니다. 모든 통제 환경에는 이런 케이스가 있습니다. 룰의 어휘에 단어 자체가 없는 실제 비즈니스 행위들입니다.

형태 2: 컴포지트 리스크 — 룰은 전부 통과, 조합은 위험

어떤 서버가 패치는 완료됐고, 접근 권한도 올바르게 설정됐으며, 90일 넘게 아무도 로그인하지 않았습니다. 각 점검은 모두 그린입니다. 그런데 합쳐 보면 방치된 자산입니다. 눈에 띄지 않을 만큼은 관리되고, 오용을 아무도 눈치채지 못할 만큼은 사용되지 않는 상태입니다. 컴포지트 리스크는 구조적으로 보이지 않습니다. 개별 룰 하나하나는 정확히 제 역할을 하고 있기 때문입니다. 평범해 보이는 행위는 여러 시그널에 걸쳐 맥락이 적용될 때 비로소 리스크가 되는데, 단일 룰 평가는 결코 맥락을 적용하지 않습니다.

형태 3: 맥락 의존 케이스 — 조건이 언어로만 존재한다

이 매크로의 의도는 무엇입니까? 세션을 넘나드는 이 이동 패턴은 비정상입니까? 운영자들이 매일 답하고 있는 실제 보안 질문들이지만, 그중 어느 것도 숫자 임계값으로 컴파일되지 않습니다. 룰엔진에는 '의도'를 표현할 문법이 없으므로, 이 질문들은 애초에 엔진에 들어가지도 못합니다.

"룰을 더 쓰면 되지 않나"가 통하지 않는 이유

반사적인 대답은 룰을 더 작성하는 것입니다. 하지만 세 가지 구조적 이유로 실패합니다.

커버리지 공백은 사후에 발견됩니다 — 그래서 룰은 언제나 현실보다 늦습니다.
컴포지트 리스크는 룰의 조합에 대한 룰을 요구합니다 — 조합 공간은 조합적으로 폭발하여 어떤 팀도 열거할 수 없습니다.
맥락 의존 조건은 임계값으로 표현할 수 없습니다 — 조건 자체가 숫자가 아니라 언어입니다.

룰을 늘리면 커버된 영역이 더 촘촘해질 뿐, else 분기는 줄어들지 않습니다.

세 가지 형태 한눈에 비교

형태	예시	룰이 놓치는 이유
커버리지 공백	SoD 매트릭스에 없는 위임 승인	개념에 해당하는 룰이 없음
컴포지트 리스크	패치 OK + 권한 OK + 90일 미접속	각 룰은 통과, 조합은 미판정
맥락 의존	매크로 의도, 세션 간 이상 이동	조건이 임계값이 아닌 언어

룰을 건드리지 않고 공백 메우기

건전한 설계는 결정론적 룰을 각자의 차선에 두고, else 분기만 맥락 판정에 위임합니다. 허용 후 로그로 기본 처리하는 대신, 분기는 전체 맥락과 함께 결정을 요청합니다.

# 결정론적 룰은 변경 없이 빠르게 실행됩니다.
verdict = rule_engine.evaluate(event)
if verdict is None:  # else 공백: 매칭된 룰이 없음
    # 이 케이스만 주변 맥락과 함께 위임합니다.
    verdict = crux.evaluate(
        event=event,
        context=gather_context(event),  # 관련 시그널, 이력, 엔티티
    )
route(verdict)  # 반환된 판정을 결정론적으로 처리

모든 판정은 확신도(confidence) 점수와 서면 근거(rationale)와 함께 반환되므로, 모호함은 조용한 기본값이 아니라 감사 가능한 결정으로 끝납니다.

{
  "verdict": "risk",
  "confidence": 0.88,
  "mode": "AGENT",
  "signals": ["patch_ok", "perms_ok", "idle_92d"],
  "rationale": "컴포지트 방치 자산 패턴: 개별적으로는 준수하는 시그널이 조합되어 방치 리스크를 형성합니다."
}

우리 조직의 공백을 매핑하는 실무 지침

먼저 룰엔진 하나를 계측하여 else 분기에 도달하는 빈도를 측정하십시오. 그 수치가 감시되지 않는 표면입니다. 그런 다음 해당 이벤트 표본을 위 세 가지 형태로 분류하십시오. 대부분의 조직은 세 형태가 모두 존재함을 발견합니다. 가치가 가장 높은 분기를 판정 레이어로 먼저 보내고, 확신도가 낮은 판정은 인간 개입(HITL) 검토 큐로 보내 모호함을 기본값이 아니라 사람이 해소하도록 하십시오.

SeekersLab 스택에서의 위치

탐지 도구는 이 패턴의 일부를 이미 구현하고 있습니다. Seekurity SIEM은 여러 소스에 걸쳐 시그널을 상관 분석하고, Seekurity SOAR는 애매한 알림을 검토로 라우팅합니다. 판정 레이어는 그 동일한 아이디어를 ERP, 네트워크, 자산, 물리보안, 파일 검역 등 모든 도메인 룰엔진의 else 분기로 일반화하며, KYRA AI Guardrail은 LLM 상호작용 자체를 거버넌스합니다. Crux는 이를 간편한 확장으로 구현합니다. 이미 운영 중인 else 분기에 API 호출 한 줄을 추가하는 것이 전부입니다.

결론

당신을 가장 해칠 가능성이 높은 이벤트는 어떤 룰도 평가하지 않는 이벤트입니다. 핵심을 정리하면 다음과 같습니다.

위반은 건강한 부분입니다 — 리스크는 룰이 결코 보지 않는 곳에 숨습니다.
else 공백은 세 가지 형태를 가집니다 — 커버리지 공백, 컴포지트 리스크, 맥락 의존 케이스.
룰을 늘리면 커버리지는 촘촘해지지만 공백은 줄지 않습니다 — 경계는 구조적입니다.
맥락 판정이 공백을 메웁니다 — 확신도 점수와, 불확실한 소수에 대한 사람 검토와 함께.

다음 단계: 엔진 하나의 else 분기 비율을 측정하고, 표본을 세 형태로 분류한 뒤, 가치가 가장 높은 분기에 판정 레이어를 파일럿으로 적용하십시오. Crux가 룰엔진 사각지대를 커버하는 방식 보기 또는 전문가 상담 신청.