개요
기업 시스템에 AI를 붙이는 일은 으레 크고 위험한 프로젝트로 여겨집니다. 새 플랫폼을 들이고, 데이터를 옮기고, 몇 달을 매달리는 그런 일 말이죠. 하지만 꼭 그럴 필요는 없습니다. AI를 붙일 가장 쉬운 자리는, 이미 쓰는 시스템이 스스로 비워둔 곳 — 룰엔진이 판정을 포기하는 else 분기입니다. 이 글에서는 왜 그 지점이 AI를 들이기에 가장 자연스러운 자리인지, 거기서 AI가 맡게 되는 세 가지 케이스는 무엇인지, 그리고 연동이 실제로 얼마나 간단한지 보여드립니다.
else 분기가 깔끔한 접점인 이유
룰엔진은 이미 잘 정의된 대부분의 이벤트를 빠르고 정확하게 처리합니다. 표현하지 못하는 것만 else 분기로 흘러가는데, 지금은 대개 '허용하고 로그만 남기기', 즉 아무 일도 일어나지 않는 것으로 끝납니다. 이건 실패가 아니라 룰이 말할 수 있는 범위의 경계일 뿐입니다.
그런데 연동 관점에서는 오히려 선물입니다. else 분기는 기존 룰을 하나도 건드리지 않고 새 판단을 더할 수 있는, 코드 안의 명확한 한 지점이니까요. AI를 시스템 전체에 이식하는 게 아니라, 시스템이 이미 열어둔 그 한 자리에 붙이기만 하면 됩니다. 그래서 리스크도, 품도 적게 드는 방식입니다.
케이스 1: 커버리지 공백 — 룰 자체가 없다
관리자가 휴가를 간 사이 ERP 승인 권한이 대리위임된 상황을 떠올려 보세요. 직무분리(SoD) 매트릭스에 '위임'이라는 개념이 없으면, 위임된 승인은 관대하게 평가되는 게 아니라 아예 평가되지 않습니다. 이런 건 미리 룰로 적어둘 수 없지만, 맥락을 보면 사람은 몇 초 만에 판단합니다. 바로 AI가 잘하는 종류의 일이고, 정확히 룰이 손대지 못한 채 남겨두는 부분입니다.
케이스 2: 컴포지트 리스크 — 룰은 다 통과, 조합이 문제
어떤 서버가 패치도 다 됐고, 권한도 제대로 설정됐고, 90일 넘게 아무도 로그인하지 않았습니다. 점검마다 전부 초록불인데, 합쳐 놓고 보면 방치된 자산입니다. 컴포지트 리스크가 단일 룰 평가에 안 보이는 건, 룰 하나하나가 제 일을 하고 있기 때문입니다. 위험은 여러 시그널을 가로질러 맥락을 볼 때 비로소 드러나죠. 그 맥락을 보는 일은 AI에겐 쉽고, 따로 도는 룰 하나에겐 불가능합니다.
케이스 3: 맥락 의존 케이스 — 조건이 말로만 존재한다
이 매크로의 의도는 무엇일까요? 세션을 넘나드는 이 이동은 비정상일까요? 운영자가 매일 답하는 진짜 질문들이지만, 어느 것도 숫자 임계값으로는 옮겨지지 않습니다. 룰엔진에는 '의도'를 담을 문법이 없어서, 이 질문은 아예 엔진에 들어가지도 못합니다. 반대로 주변 맥락과 함께 모델에 건네면, 답할 수 있는 질문이 됩니다.
"룰을 더 짜면 되지 않나"가 답이 아닌 이유
반사적으로 나오는 대답은 룰을 더 작성하는 겁니다. 하지만 else 분기는 줄지 않습니다. 세 가지 구조적인 이유 때문입니다.
- 커버리지 공백은 사후에야 발견됩니다 — 그래서 룰은 늘 현실보다 한발 늦습니다.
- 컴포지트 리스크는 룰의 조합에 대한 룰을 요구합니다 — 조합의 수가 폭발적으로 늘어, 어떤 팀도 다 적을 수 없습니다.
- 맥락 의존 조건은 임계값이 될 수 없습니다 — 조건 자체가 숫자가 아니라 언어이기 때문입니다.
룰을 늘리면 커버되는 영역이 촘촘해질 뿐입니다. 반면 else 분기에 AI를 한 번 붙이면 세 유형을 같은 자리에서 한꺼번에 커버합니다. 일이 늘어나는 게 아니라 오히려 줄어드는 이유죠.
세 가지 케이스 한눈에
| 케이스 | 예시 | 왜 룰이 아니라 AI인가 |
|---|---|---|
| 커버리지 공백 | SoD 매트릭스에 없는 위임 승인 | 미리 룰로 적어둘 수가 없음 |
| 컴포지트 리스크 | 패치 OK + 권한 OK + 90일 미접속 | 여러 시그널의 맥락에서만 보임 |
| 맥락 의존 | 매크로 의도, 세션 간 이상 이동 | 조건이 임계값이 아니라 언어 |
실제로 얼마나 간단한가
접점이 이미 있으니, 연동은 정말 작은 일입니다. 룰엔진이 판정을 흘려보내는 그 지점에서, '허용하고 로그만' 대신 판정을 한 번 요청하면 됩니다.
# 기존 결정론적 룰은 그대로, 빠르게 실행됩니다.
verdict = rule_engine.evaluate(event)
if verdict is None: # else 분기: 걸린 룰이 없음
# 바로 이 자리에 AI를 더합니다 — 주변 맥락을 함께 넘깁니다.
verdict = crux.evaluate(event, context=gather_context(event))
route(verdict) # 돌아온 판정을 결정론적으로 그대로 처리돌아오는 판정은 알 수 없는 점수 하나가 아니라, 확신도와 근거까지 담긴 구조화된 결정입니다. 그래서 기존 파이프라인이 결과를 그대로 처리할 수 있고, 확신도가 낮은 건 조용히 넘어가는 대신 사람 검토 큐로 올라갑니다.
{
"verdict": "risk",
"confidence": 0.88,
"mode": "AGENT",
"signals": ["patch_ok", "perms_ok", "idle_92d"],
"rationale": "개별로는 준수하는 시그널이 합쳐지며 방치 자산 리스크를 형성함."
}SI 프로젝트처럼 도입합니다
한 번에 한 접점씩 붙이기 때문에, 이 방식은 플랫폼 마이그레이션이 아니라 SI(시스템 통합) 프로젝트처럼 진행됩니다. else 분기가 가장 많이 걸리는, 가치 높은 도메인을 하나 골라 그곳에 판정 API를 연결하고, 소수 케이스로 검증한 뒤, ERP·운영·재무처럼 도메인 단위로 넓혀 갑니다. Crux가 바로 그 레이어입니다. 이미 돌아가고 있는 시스템의 else 분기에 붙는 AI 판정 레이어죠.
결론
AI 도입이 꼭 재구축일 필요는 없습니다. 핵심을 정리하면 이렇습니다.
- 가장 쉬운 진입점은 이미 있습니다 — 룰이 스스로 비워둔 else 분기입니다.
- 세 가지 케이스가 정확히 AI의 몫입니다 — 커버리지 공백, 컴포지트 리스크, 맥락 의존.
- 시스템 전체 개조가 아니라 접점 하나입니다 — 호출 한 줄, 룰은 그대로.
- 작게 시작해 넓히면 됩니다 — 도메인 하나로 파일럿을 돌리고, 데이터를 근거로 확장합니다.
다음 단계: 가치가 높은 룰엔진을 하나 골라, 지금 else 분기에 얼마나 자주 도달하는지 재보고, 그 한 접점에만 판정을 파일럿으로 붙여보십시오. Crux가 기존 시스템에 AI를 더하는 방식 보기 또는 전문가 상담 신청.