개요
보안, 컴플라이언스, ERP를 맡고 있는 팀이라면 한 번쯤 이런 제안을 받아보셨을 겁니다. "지금 쓰는 룰 기반 시스템은 낡았으니, 완전히 새로운 AI 플랫폼으로 갈아타야 한다"는 이야기죠. 기존 엔진을 걷어내고 데이터를 옮기고 팀을 다시 교육하면 그때부터 똑똑해진다는 겁니다. 하지만 이 전면 교체(rip-and-replace) 방식이야말로 가장 비싸고 위험한 AI 도입 방법입니다. 이 글에서는 그 이유와 함께, 시스템을 갈아엎는 대신 '증강(augmentation)'하는 편이 어떻게 훨씬 적은 혼란으로 필요한 만큼의 커버리지를 확보하는지 살펴봅니다.
룰엔진이 실제로 무엇을 잘하는지, 어디서 구조적으로 한계를 드러내는지, 전면 교체에 정말 얼마가 드는지, 그리고 API 한 줄로 시작할 수 있는 훨씬 간단한 대안까지 차례로 짚어보겠습니다.
배경: 룰엔진이 아직도 어디에나 있는 이유
결정론적 룰엔진은 지금도 기업 통제의 근간입니다. ERP의 직무분리(SoD) 매트릭스, 네트워크의 IDS 시그니처, 자산관리의 패치 기준선, 출입 통제의 화이트리스트가 대표적이죠. 하나같이 빠르고, 감사가 되고, 설명이 됩니다. 룰이 걸리면 왜 걸렸는지 정확히 알 수 있고, 감독기관 앞에서도 그대로 근거를 댈 수 있습니다. 이건 걷어내야 할 기술 부채가 아니라, 제 몫을 하고 있는 통제 장치입니다.
시장의 흐름도 이미 '전부 AI로 갈아치우자'는 단계를 지났습니다. 앞서가는 이상거래 탐지 시스템은 룰을 먼저 돌리고, 애매한 것만 모델과 분석가에게 넘깁니다. 요즘 SOC 도구도 탐지 로직을 버리는 대신 LLM 추론과 결정론적 가드레일을 함께 씁니다. 기존 시그널을 대체하지 않고 우선순위만 매겨주는 것이 핵심 가치인 Wiz를 구글이 사들인 것도 같은 맥락입니다. 결국 기업이 지갑을 여는 지점은, 쓰던 시스템을 더 똑똑하게 만들어 주는 '한 겹'입니다.
if-else의 구조적 한계
룰엔진은 만들 때 미리 적어둔 것만 판정합니다. 거기에 없는 상황은 전부 else 분기로, 다시 말해 아예 판정 대상 밖으로 빠져버립니다. 이건 룰의 결함이 아니라 룰이라는 방식 자체의 성질입니다. 그리고 진짜 골치 아픈 리스크는 바로 그 빈 공간, 아무도 판정 규칙을 써두지 않은 곳에 숨어 있습니다.
전면 교체에 숨은 진짜 비용
잘 돌아가는 룰엔진을 AI 플랫폼으로 갈아엎는 비용은 라이선스 값이 다가 아닙니다. 영업 자료에는 좀처럼 나오지 않는 네 가지가 따라붙습니다.
- 룰 카탈로그 이관 — 검증된 룰을 하나하나 새 시스템에서 다시 만들어야 하고, 그 하나하나가 회귀(regression) 리스크입니다.
- 데이터 마이그레이션 — 통제가 기대고 있는 과거 데이터를 옮기는 순간, 무결성과 데이터 주권 문제가 함께 따라옵니다.
- 운영팀 재교육 — 지금 시스템을 능숙하게 다루는 팀의 숙련도 자체가 자산인데, 교체는 그 가치를 한순간에 날려버립니다.
- 리스크 비대칭 — 결정론적 시스템의 이미 아는 실패 방식을, 확률적 시스템의 알 수 없는 실패 방식과, 그것도 전체 범위에서 한꺼번에 바꿔치기하는 셈입니다.
네 번째가 이 함정의 핵심입니다. 룰은 이미 잘 정의된 대부분의 상황을 제대로 처리하고 있습니다. 그런데 전면 교체는 이미 풀어둔 문제까지 전부 다시 풀게 만들고, 그 과정에서 전부를 리스크에 노출시키면서, 정작 얻는 건 룰이 놓치던 소수의 케이스뿐입니다.
증강: 아직 못 푼 부분만 푼다
해법은 결정론적 엔진이 잘하는 일은 그대로 두고, 남는 부분 — else 분기 — 만 AI에 맡기는 겁니다. 그러면 '잘못될 수 있는 범위'가 전체에서 '어차피 판정도 못 하던 케이스'로 확 줄고, 도입도 조금씩, 언제든 되돌릴 수 있는 방식이 됩니다.
실제로는 룰엔진이 지금 판정을 포기하는 그 지점에, 호출 한 줄을 더하는 게 전부입니다.
// 기존 결정론적 룰은 그대로, 손대지 않고 실행됩니다.
if (matchesKnownRule(event)) {
return ruleVerdict(event);
} else {
// 사각지대: 원래는 그냥 허용하고 로그만 남기던 지점.
// 이제 이 케이스만 AI 판정에 맡깁니다.
return await crux.evaluate(event); // 딱 한 줄, 간편 연동
}판정 서비스는 알 수 없는 점수 하나가 아니라, 근거까지 담긴 구조화된 결정을 돌려줍니다. 그래서 기존 파이프라인이 그 결과를 결정론적으로 그대로 처리할 수 있습니다.
{
"verdict": "review",
"confidence": 0.62,
"mode": "HYBRID",
"rationale": "SoD 매트릭스에 없는 위임 승인. 사람 검토로 넘깁니다."
}교체 vs 증강 한눈에 비교
| 구분 | 전면 교체 | 증강 (Crux) |
|---|---|---|
| 도입 노력 | 전체 플랫폼 마이그레이션 | else 분기 API 호출 1줄 |
| 데이터 마이그레이션 | 필요 | 없음 |
| 기존 룰 | 폐기 후 재작성 | 그대로 유지 |
| 잘못될 수 있는 범위 | 전체 커버리지 | 원래 판정 못 하던 케이스만 |
| 되돌리기 | 롤백이 어려움 | 호출 한 줄만 빼면 끝 |
| AI 거버넌스 | 대개 블랙박스 | AI가 추천, 사람이 승인 |
자주 나오는 반론과 대응
교체 대신 증강을 검토하다 보면 꼭 두 가지 걱정이 나옵니다.
"시스템이 둘이 되면 하나일 때보다 관리가 더 어렵지 않나요?" 실제로는 반대입니다. 결정론적 엔진은 그대로 '기록의 원천(system of record)'으로 남고, 판정 레이어가 그 위에 근거가 남는 확신도 기반 결정 이력을 얹어줍니다. 감사할 대상을 잃는 게 아니라 오히려 하나 더 생기는 셈이죠.
"그래도 결국 AI한테 우리 데이터를 줘야 하는 것 아닌가요?" 새 벤더에게 데이터를 복제해 넘기는 게 아닙니다. BYOM(Bring Your Own Model) 구조에서는 판정 레이어를 이미 검증해 쓰고 있는 엔드포인트 — Azure OpenAI, AWS Bedrock, 온프레미스 모델 — 에 연결합니다. 그래서 추론은 지금의 데이터 주권 경계 안에서 이뤄집니다.
SI 프로젝트처럼 도입하는 AI
Crux는 새로 갈아타는 플랫폼이 아닙니다. 이미 돌아가고 있는 시스템에 AI를 가장 쉽게 얹는 방법이자, SI(시스템 통합) 프로젝트처럼 진행되는 도입 방식입니다. 잘 쓰던 엔진을 바꾸는 대신, 그 시스템이 놓치는 else 분기를 찾아 API 한 줄로 AI 판정을 더합니다. ERP, 운영, 재무처럼 도메인 단위로, 구조를 바꾸지도 데이터를 옮기지도 않고 진행됩니다. 이게 Crux의 전부입니다. 이미 가진 시스템을 위한 AI를, 가장 쉬운 방법으로 붙입니다.
결론
교체 프로젝트에 사인하기 전에, 대안의 비용부터 솔직하게 따져보시기 바랍니다. 요점은 이렇습니다.
- 룰엔진은 고장 난 게 아닙니다 — 검증을 거쳐 지금도 돌아가고 있는 조직의 노하우입니다.
- 교체의 진짜 비용은 리스크입니다 — 아는 실패를 모르는 실패와, 그것도 전 범위에서 바꿔치기합니다.
- 증강이 계산상으로도 더 쌉니다 — 이미 푼 문제가 아니라 남은 부분만 풀기 때문입니다.
- 간편한 연동은 곧 되돌릴 수 있다는 뜻입니다 — 한 줄로 넣었다가, 한 줄로 뺄 수 있습니다.
다음 단계: 가치가 높은 룰엔진을 하나 골라 그 else 분기를 짚어보고, 지금 '허용하고 로그만 남기는' 이벤트가 얼마나 되는지 재본 다음, 그 한 분기에만 판정 레이어를 파일럿으로 붙여보십시오. Crux의 룰엔진 증강 방식 보기 또는 전문가 상담 신청.