AI 자동화가 기존 소프트웨어와 다른 답을 내놓는 이유와 그 중요성

중견 유통업체의 한 물류 매니저는 자신들의 외상매입금 (Accounts Payable) 프로세스가 왜 일관성을 잃었는지 이해하기 위해 3주를 보냈습니다. 8년 동안 사용해 온 그들의 ERP는 공급업체 송장을 2초도 안 되어 승인했습니다. 반면, 그들의 새로운 AI 기반 자동화 플랫폼은 동일한 송장을 잠재적인 중복 항목으로 표시했습니다. 두 시스템 모두 동일한 데이터에 접근할 수 있었습니다. 두 공급업체 모두 높은 정확도를 주장했습니다. 매니저는 두 판결을 조정할 수 없었고, 결국 CFO에게 보고했습니다. CFO는 단 2초면 끝났어야 할 송장을 조사하는 데 반나절을 소비했습니다.

시스템들은 오작동하고 있었던 것이 아닙니다. 설계된 대로 정확히 작동하고 있었습니다. 문제는 매니저나 CFO에게 각각의 소프트웨어가 실제로 어떤 종류인지 아무도 설명해주지 않았다는 점이었습니다.

규칙 기반 (Rule-Based) 소프트웨어가 실제로 하는 일

레거시 소프트웨어(Legacy software) — ERP, CRM, 컴플라이언스 체크 도구, 빌링 시스템 등 — 는 개발자가 작성한 명시적인 규칙을 기반으로 구축됩니다. 모든 결정은 인간이 작성한 조건, 즉 '만약 이렇다면, 저렇다(if this, then that)'로 거슬러 올라갑니다.

외상매입금 규칙은 다음과 같을 수 있습니다: 만약 공급업체가 승인 목록에 있고 AND 송장 금액이 구매 주문 한도 미만이며 AND 지난 90일 동안 일치하는 송장 번호가 존재하지 않는다면 → 승인. 만약 어떤 조건이라도 실패하면 → 검토를 위해 표시.

이것이 바로 결정론적 (Deterministic) 소프트웨어입니다. 동일한 입력은 항상 동일한 출력을 생성합니다. 예외도 없고, 변동도 없습니다. 화요일에 천 번 실행하든 금요일에 천 번 실행하든 동일한 결과를 얻습니다. 로직은 투명하며, 개발자, 감사인, 규제 기관, 판사 등 누구에게나 감사 가능하고 설명 가능합니다.

그러한 예측 가능성은 한계가 아닙니다. 대부분의 비즈니스 핵심 결정에 있어서, 그것은 바로 당신이 원하는 것입니다.

AI 자동화가 내부적으로 실제로 하는 일

AI 자동화는 근본적인 수준에서 다르게 작동합니다. 개발자가 작성한 규칙 대신, 학습 데이터(수천 또는 수백만 개의 과거 사례)로부터 학습된 패턴을 사용하여 정답이 무엇일 가능성이 높은지 추정합니다.

출력값은 판결(verdict)이 아니라 확률(probability)입니다. 모델은 다음과 같이 말합니다: "내가 학습한 모든 것을 바탕으로 할 때, 이 송장이 정당할 확률은 91%입니다." 그런 다음 시스템은 그 점수를 행동으로 변환합니다. 임계값(threshold)보다 높으면 승인하고, 낮으면 플래그(flag)를 지정합니다.

이것은 확률적 (probabilistic) 소프트웨어입니다. 동일한 입력을 두 번 제출하더라도 점수가 동일하지 않을 수 있습니다. 모델의 신뢰도(confidence)는 현재 입력이 학습 과정에서 보았던 패턴과 얼마나 유사한지에 따라 달라집니다. 입력을 약간만 변경해도—다른 서식, 자주 보지 못한 공급업체 이름, 해당 카테고리에서 이례적인 금액 등—점수가 변합니다. 사실 관계가 바뀌었기 때문이 아니라, 모델의 확신(certainty)이 변했기 때문입니다.

결과가 갈라지는 지점 — 그리고 그것이 비용을 발생시키는 이유

이러한 차이는 세 가지 시나리오에서 실제 비즈니스 문제로 직결됩니다.

감사 가능성 (auditability)이 필요할 때. 규제 기관이 왜 특정 거래가 승인되었는지 묻습니다. 규칙 기반 (rule-based) 소프트웨어의 경우, 통과된 정확한 조건과 시점을 출력할 수 있습니다. 하지만 AI의 경우, 정직한 답변은 "모델이 임계값보다 높은 점수를 부여했습니다"가 됩니다. 이 답변은 금융 규제 기관, HIPAA 감사관, 또는 계약 분쟁 상황을 만족시키지 못합니다. 금융 서비스, 의료, 보험과 같은 일부 산업은 설명 가능한 자동화된 결정 (explainable automated decisions)에 대한 명시적인 요구 사항을 가지고 있습니다. 확률적 시스템은 설명 가능성 계층 (explainability layers)을 갖추어 특수 제작되지 않는 한, 이 기준을 충족하지 못합니다.

오답의 비용이 높을 때. 규칙 기반 시스템은 예측 가능한 방식으로 실패합니다. 잘못된 규칙을 작성하면 매번 동일한 방식으로 실패하므로, 이를 포착하고 수정하기가 쉽습니다. 반면 AI 시스템은 예측 불가능한 방식으로 실패합니다. 모델이 98%의 시간 동안은 올바르게 작동하다가, 테스트 과정에서 전혀 드러나지 않았던 특정 엣지 케이스 (edge case)에서 실패할 수 있습니다. 대출 승인, 약물 용량 계산, 또는 컴플라이언스 (compliance) 체크에서 그 2%의 오차는 허용 가능한 오차 범위가 아닙니다.

팀 간의 일관성이 중요한 경우. 동일한 규칙 기반 (rule-based) 시스템을 사용하는 두 직원은 동일한 답변을 얻습니다. 하지만 AI 시스템을 통해 동일한 요청을 서로 다른 시간에 실행하는 두 직원은 서로 다른 답변을 얻을 수 있으며, 이는 혼란과 불일치, 그리고 앞서 물류 관리자가 겪었던 것과 정확히 같은 종류의 운영상의 혼란 (operational chaos)으로 이어집니다.

그럼에도 불구하고 AI 자동화가 승리하는 지점

이것이 기존 소프트웨어가 항상 더 낫다는 의미는 아닙니다. 규칙 기반 시스템에는 명확한 한계가 있습니다. 개발자가 가능한 모든 조건을 예측하고 그에 맞는 규칙을 작성해야 하기 때문입니다. 결정 사항이 잘 정의되어 있고 입력값이 구조화되어 있을 때는 이 방식이 작동합니다. 하지만 다음 세 가지 상황에서는 빠르게 한계에 부딪힙니다.

비구조화된 입력 (Unstructured input). 규칙은 구조화된 데이터 (structured data)를 필요로 합니다. 만약 귀하의 워크플로가 자유 형식의 고객 불만 사항 처리, 이미지 분류, 스캔된 문서에서 정보 추출, 또는 지원 티켓 (support tickets) 분석을 포함한다면, 규칙으로는 이를 처리할 수 없습니다. AI는 가능합니다.

인간의 규칙 작성 능력을 넘어서는 규모 (Scale). 일일 1,000만 건의 거래에 걸친 사기 탐지 (fraud detection)에는 개발자가 일일이 열거할 수 없는 패턴이 포함되어 있습니다. 50만 개의 SKU 카탈로그에 걸친 추천 엔진 (recommendation engines)은 규칙 기반으로 구동될 수 없습니다. 결정 공간 (decision space)이 직접 코딩하기에는 너무 클 때, 데이터로부터 학습하는 AI의 능력은 선택 사항이 아니라 유일하게 실행 가능한 접근 방식입니다.

인간의 판단이 이미 일관되지 않았던 결정들. 만약 귀하의 회사에서 두 명의 선임 검토자가 정답에 대해 30%의 확률로 의견이 갈린다면, 규칙 기반 시스템은 실제 일관성 없이 일관성이 있다는 환상만을 제공할 뿐입니다. 충분한 레이블이 지정된 데이터 (labeled data)로 학습된 AI는 때때로 이러한 일관성 없는 기준점 (baseline)보다 더 나은 성능을 보여줄 수 있습니다.

비즈니스에 실제로 어떤 시스템이 필요한지 결정하는 방법

기존 시스템을 AI로 교체하기 전, 또는 진정으로 발목을 잡고 있는 기존 소프트웨어를 유지하기 전, 워크플로의 각 결정 지점에서 다음 네 가지 질문으로 구성된 감사를 실시하십시오:

1. 이 결정을 올바르게 내리는 데 필요한 모든 조건을 문서로 작성할 수 있습니까?
만약 그렇다면, 규칙 기반 시스템 (rule-based system)이 더 단순하고 신뢰할 수 있습니다. 만약 그렇지 않다면 — 결정 과정에 패턴 인식 (pattern recognition), 비정형 데이터 (unstructured data), 또는 너무 많은 변수가 포함되어 있기 때문이라면 — AI가 적합한 도구입니다.

2. 잘못된 답변에 대한 비용은 얼마입니까?
높은 비용 (재무적, 법적, 컴플라이언스 (compliance) 관련) → 결정론적 규칙 (deterministic rules)을 유지하거나, AI 레이어 위에 하드 규칙 (hard rules)을 제약 조건으로 추가하십시오. 높은 볼륨에서의 낮은 비용 (콘텐츠 태깅, 라우팅, 추천) → AI의 변동성 (variance)을 감수할 가치가 있습니다.

3. 결정 사항을 외부 당사자에게 완전히 설명할 수 있어야 합니까?
규제 기관, 감사인, 고객, 법원 → 결정론적 규칙 또는 설명 가능성 (explainability)이 내장된 AI를 사용하십시오. 내부 최적화 → AI를 사용해도 괜찮습니다.

4. 입력 데이터에 비정형 데이터가 포함되어 있습니까?
문서, 이미지, 자유 텍스트, 오디오 → AI. 깔끔하게 정리된 정형 데이터베이스 (structured database) 레코드 → 규칙 (rules)이 이를 깔끔하게 처리합니다.

대부분의 잘 설계된 프로덕션 시스템 (production systems)은 두 가지를 모두 사용합니다. 결정론적 규칙은 하드 제약 조건(hard constraints)을 강제합니다. 예를 들어, '반드시 승인된 벤더 목록에 있어야 한다'거나 '금액이 승인된 한도 미만이어야 한다'는 식입니다. AI는 이러한 제약 조건 내에서 패턴 인식을 처리합니다. 즉, '승인된 벤더 중에서, 과거 패턴과 비교했을 때 통계적으로 특이해 보이는 송장은 무엇인가?'를 판단하는 것입니다.

실제로 재구축해야 합니까, 아니면 레이어를 쌓아야 합니까?

제품 창업자들이 저지르는 가장 흔한 실수는 이를 이분법적인 선택으로 취급하는 것입니다. 그들은 기존 레거시 시스템 (legacy system)을 보고 구식이라고 판단한 뒤, 이를 AI 자동화 플랫폼으로 통째로 교체해 버립니다. 그러고 나서 AI가 기존 시스템과 다르게 처리하는 일관성 부족, 설명 가능성의 공백, 그리고 예외 케이스 (edge cases)를 해결하느라 수개월을 허비합니다.

더 나은 질문은 대개 다음과 같습니다: 이 워크플로의 어떤 구체적인 결정들이 확률적 지능 (probabilistic intelligence)으로부터 진정으로 이득을 얻으며, 어떤 결정들이 결정론적 (deterministic)으로 유지되어야 하는가?

Aviasole에서는 단 한 줄의 자동화 코드가 작성되기 전에 기업들이 그 질문에 답할 수 있도록 돕습니다. 우리의 AI 개발 서비스 (AI development services)에는 의사결정 지점 (decision points)을 매핑하고, AI가 가치를 창출하는 지점과 리스크를 유발하는 지점을 식별하며, 각 접근 방식이 유행을 따르는 것이 아니라 실제로 적합한 곳에 사용되도록 시스템을 설계하는 워크플로우 감사 (workflow audits)가 포함됩니다.

대부분의 경우, 올바른 아키텍처 (architecture)는 대체재가 아닙니다. 그것은 하나의 계층 (layer)입니다.

자동화 의사결정을 감사할 준비가 되셨나요?

워크플로우를 자동화할지 여부를 평가 중이거나, 기존 AI 시스템이 왜 일관되지 않은 결과를 생성하는지 이해하려고 노력 중이라면, 첫 번째 단계는 기술 선택이 아니라 의사결정 지점 감사 (decision-point audit)입니다.

워크플로우 매핑에 대해 저희 팀과 상담하세요 (Talk to our team). AI가 도움이 되는 곳, 리스크를 유발하는 곳, 그리고 기존의 레거시 규칙 (legacy rules)이 정확히 제 역할을 수행하고 있는 곳이 어디인지 솔직하게 말씀드리겠습니다.