이 기사는 원래 davidohnstad.net에 게시되었습니다. Dev.to 커뮤니티에 전달하기 위해 이곳에 교차 게시합니다.

우리는 AI 기반 공급업체 리스크 평가 시스템을 구축하는 데 14개월을 보냈습니다. 그리고 그것을 폐기했습니다.

요청은 2024년 3월 CISO(정보보호최고책임자)로부터 왔습니다: 자연어 처리 (NLP)를 사용하여 우리의 제3자 보안 설문지를 자동화하라는 것이었습니다. 컴플라이언스 (Compliance) 대기열에는 340개의 공급업체가 있었고, 각 공급업체는 18개월마다 90개의 질문으로 구성된 보안 평가를 받아야 했습니다. 수동 프로세스는 세 부서에 걸쳐 11명의 전업 인력 (FTE)을 소모했습니다. 경영진은 AI 기반 공급업체 리스크 플랫폼을 도입하면 응답 정확도를 높이면서도 그 인력을 70%까지 줄일 수 있을 것이라고 판단했습니다.

우리는 2025년 5월에 제품을 출시했습니다. 10월이 되었을 때, 컴플라이언스 팀은 원래의 스프레드시트 워크플로우 (Workflow)로 돌아갔습니다. AI 모델은 평가를 더 빠르게 생성했지만, 신뢰도가 낮은 엣지 케이스 (Edge cases)를 충분히 발생시켰고, 이로 인해 검토자들은 수동으로 응답을 작성할 때보다 출력값을 검증하는 데 더 많은 시간을 소비하게 되었습니다. Gartner의 2024년 제3자 리스크 관리 설문 조사에 따르면, AI 기반 공급업체 리스크 도구를 도입한 기업의 62%가 유사한 결과, 즉 처리는 빨라졌으나 인간의 검토 시간은 줄어들지 않았다고 보고했습니다. 우리는 시장이 원하는 기능을 만들었지만, 우리의 특정 워크플로우가 이를 수용할 수는 없었습니다.

실수는 기술적 실행에 있지 않았습니다. 모델은 제대로 작동했습니다. 실수는 프로젝트 시작 6주 만에, 규칙 기반 자동화 (Rule-based automation)가 비용의 15%만으로 가치의 80%를 제공할 것이라는 점을 알려주었을 의사결정 프레임워크 (Decision framework)를 건너뛴 것이었습니다. Veeam에서 기업용 소프트웨어의 AI 및 머신러닝 (AI & Machine Learning in Enterprise Software) 제품 전략을 담당하는 David Ohnstad는 이후 AI 역량과 운영 준비성 사이의 이러한 값비싼 불일치를 방지하기 위한 반복 가능한 프로세스를 구축했습니다.

왜 공급업체 리스크 관리가 AI 테스트 베드가 되었는가 — 그리고 왜 대부분의 구현이 정체되는가

공급업체 리스크 관리 (Vendor risk management)가 초기 AI 도입 카테고리로 부상한 데에는 세 가지 이유가 있습니다. 첫째, 규모의 문제가 실재합니다. Deloitte의 2023년 제3자 리스크 관리 설문조사 (Third-Party Risk Management Survey)에 따르면 기업들은 평균 583개의 제3자 관계를 관리하고 있으며, 규제 압박으로 인해 평가 빈도는 더욱 증가하고 있습니다. 둘째, 이 작업은 패턴 친화적으로 보입니다. 보안 설문지 (security questionnaires)는 유사한 구조를 반복하므로, 자연어 처리 (NLP) 분류에 표면적으로 적합해 보입니다. 셋째, 공급업체들은 예산의 냄새를 맡습니다. 이사회에 AI 도입 로드맵을 방어해야 하는 컴플라이언스 (compliance) 리더들에게는 구체적인 유스케이스 (use case)가 필요하며, 공급업체 리스크 플랫폼은 중견 시장 배포 시 연간 18만 달러에서 45만 달러의 비용이 발생하여 수익성 높은 영업 사이클을 형성합니다.

하지만 성공률은 다른 이야기를 들려줍니다. GRC 도구의 AI 도입에 관한 Forrester의 2024년 4분기 분석에 따르면, AI 기반 공급업체 리스크 플랫폼을 배포한 조직 중 사용 12개월 후 검토 주기 시간이 측정 가능할 정도로 단축되었다고 보고한 조직은 23%에 불과했습니다. 나머지 77%는 세 가지 결과 중 하나를 보고합니다: 도입 정체 (도구는 존재하지만 팀이 이전 워크플로우로 회귀), 범위 축소 (AI 기능이 비활성화되어 플랫폼이 값비싼 데이터베이스로 기능함), 또는 포기 (계약이 갱신되지 않음). David Ohnstad가 기업용 AI 파일럿 (AI pilots)에서 관찰한 패턴이 여기서도 정확하게 적용됩니다. 즉, 팀들은 자신들의 워크플로우가 확률적 출력 (probabilistic output)을 수용할 수 있는지 감사하지 않은 채 그 기능만을 구매합니다.

이러한 실패 모드(failure mode)는 기술적인 문제가 아니라 구조적인 문제입니다. AI 기반의 벤더 리스크(vendor risk) 도구들은 대규모 문서 세트에 대한 패턴 인식 (pattern recognition)에는 탁월합니다. 즉, 보안 설문지 (security questionnaires)를 파싱하고, 벤더 문서의 이상 징후를 식별하며, 과거 데이터를 기반으로 컴플라이언스 (compliance) 격차를 드러내는 데 능숙합니다. 하지만 이들은 예외적인 사례 (edge-case)에 대한 판단, 모호한 벤더의 답변, 그리고 부서마다 다른 문맥 특화적 리스크 허용 임계값 (risk tolerance thresholds)을 처리하는 데 어려움을 겪습니다. "데이터를 저장 시 암호화(encrypt data at rest)합니까?"라는 벤더의 답변을 읽는 컴플라이언스 검토자는 답변의 회피성을 평가하고, 후속 질문을 던지며, 벤더의 전략적 중요도에 따라 문제를 에스컬레이션 (escalate)할 수 있습니다. 반면 AI 모델은 신뢰도 점수 (confidence score)를 반환할 뿐입니다. 만약 귀하의 워크플로우가 평가의 18% — 저희의 사후 분석 (post-mortem analysis) 결과 나타난 중앙값 — 에 대해 미묘한 판단을 필요로 한다면, 귀하는 워크플로우를 자동화한 것이 아닙니다. 여전히 완전한 인간의 검토를 필요로 하는 전처리 (preprocessing) 단계를 하나 더 추가했을 뿐입니다.

벤더 리스크 AI 준비도 프레임워크 (The Vendor Risk AI Readiness Framework)

이것은 4단계 게이트 (four-gate) 의사결정 모델입니다. 각 게이트는 진행 여부를 결정하는 체크포인트 (checkpoint)입니다. 만약 특정 게이트의 기준에 대해 '예'라고 답할 수 없다면, 규칙 기반 자동화 (rule-based automation) 또는 프로세스 재설계 (process redesign)가 AI 도입보다 더 나은 성과를 낼 것입니다. 이 프레임워크의 명칭은 '벤더 리스크 AI 준비도 프레임워크 (Vendor Risk AI Readiness Framework)'입니다. 이는 6개월짜리 타당성 조사 (feasibility study)가 아니라, 여러 부서의 이해관계자들이 참석한 가운데 90분 내에 적용할 수 있도록 설계되었습니다.

게이트 1: 볼륨 및 패턴 일관성 (Volume and Pattern Consistency). 귀하의 벤더 평가 작업량이 연간 완료된 설문지 200개를 초과하며, 질문의 최소 60%가 벤더 유형 전반에 걸쳐 동일하거나 거의 동일한 문구로 반복됩니까? 만약 작업량이 이보다 적거나 질문이 벤더 카테고리별로 크게 다르다면, 템플릿 기반 답변과 조건부 로직 (conditional logic)을 사용하는 규칙 기반 자동화가 구현 비용을 10분의 1로 줄이면서도 AI의 성능과 대등한 결과를 낼 것입니다. 저희는 설문지 이력을 감사(audit)한 결과 연간 340건의 벤더 평가를 수행하고 있었으나, 질문 일관성은 41%에 불과하다는 것을 발견했습니다. 헬스케어, 금융, 인프라 카테고리의 벤더들은 패턴 인식 모델을 깨뜨리는 도메인 특화적 (domain-specific) 질문들을 요구했습니다. 게이트 1 탈락 (fail).

게이트 2: 확률적 출력에 대한 허용치 (Tolerance for Probabilistic Output). 귀사의 컴플라이언스 워크플로우 (compliance workflow)가 전체 수동 재검토를 요구하지 않고도, 신뢰도 점수(confidence scores)가 65%에서 85% 사이로 표시된 답변들을 수용할 수 있습니까? AI 모델은 양극단, 즉 신뢰도가 매우 높은 일치 항목이나 명백한 실패 사례에서는 성능이 뛰어나지만, 벤더 리스크 (vendor risk)의 예외 사례들은 중간 대역에 집중됩니다. 만약 귀사의 규제 환경, 감사 요구사항, 또는 내부 리스크 성향 (risk appetite)이 모호한 응답에 대한 인간의 검토를 요구한다면, 귀하는 노동을 제거하는 것이 아니라 재배치하고 있는 것입니다. SOC 2 및 ISO 27001 감사 요구사항에 따라 움직이는 저희 컴플라이언스 팀의 리스크 허용치는 신뢰도가 90% 미만인 모든 응답에 대한 검증을 요구했습니다. 실제로 AI가 생성한 답변의 34%가 해당 검증 대기열 (validation queue)에 포함되었습니다. 게이트 2 탈락 (fail).

게이트 3: 구조화된 피드백 루프 인프라 (Structured Feedback Loop Infrastructure). AI 모델이 부정확하거나 도움이 되지 않는 출력을 생성할 때 이를 포착할 수 있는 기존 메커니즘이 있습니까? 그리고 해당 피드백을 30일 주기 내에 모델 재학습 (retrain)에 사용할 수 있습니까? McKinsey의 2024년 AI 현황 보고서 (State of AI Report)에 따르면, 운영 워크플로우에 AI 도구를 배치한 기업의 68%가 사용자 수정을 기반으로 모델을 반복 개선할 수 있는 MLOps 인프라가 부족한 것으로 나타났습니다. 피드백 루프 (feedback loop)를 닫을 수 없다면, 벤더의 언어가 진화하고 규제 표준이 변화하며 내부 리스크 정의가 바뀜에 따라 모델의 정확도는 저하됩니다. 저희는 모델 성능에 대한 원격 측정 (telemetry) 데이터는 보유하고 있었으나, 수정 사항을 학습 데이터 (training data)로 다시 공급할 프로세스는 없었습니다. 게이트 3 탈락 (fail).

Gate 4: 변경 관리 (Change Management) 및 사용자 신뢰 (User Trust). 스프린트 제로 (sprint zero) 단계부터 컴플라이언스 검토자 (compliance reviewers)가 모델의 동작을 정의하는 데 참여했는가? 그리고 그들이 수동으로 재검증하지 않고도 확률적 출력 (probabilistic output)을 신뢰하고 이를 바탕으로 조치를 취할 수 있는가? 이는 가장 기술적이지 않은 게이트이자 가장 흔히 간과되는 게이트입니다. 기존 워크플로우에 사용자의 공동 설계 (co-design) 없이 삽입된 AI 도구는 저항을 불러일으킵니다. 이는 도구에 결함이 있어서가 아니라, 사용자가 언제 도구를 신뢰해야 하는지에 대한 멘탈 모델 (mental model)이 없기 때문입니다. 저희 컴플라이언스 팀은 요구사항에 대해 자문을 구했을 뿐, 반복적인 모델 테스트 (iterative model testing)에는 참여하지 않았습니다. 도구가 출시되었을 때, 그들은 모든 AI 생성 응답을 전체 검증이 필요한 초안으로 취급했습니다. Gate 4 탈락 (fail).

네 개의 게이트 중 통과한 것이 하나도 없습니다. 만약 Vendor Risk AI Readiness Framework를 사용했다면, 6주 차에 조건부 분기 (conditional branching)가 포함된 규칙 기반 템플릿 시스템 (rule-based template system)으로 피벗 (pivot)하라는 조언을 들었을 것입니다. 그랬다면 34만 달러의 개발 비용과 8개월의 로드맵 시간을 절약했을 것입니다. David Ohnstad가 이후 모든 AI 기능 논의에서 견지해 온 교훈은 다음과 같습니다. 단순히 규모(volume)가 크다는 것만으로는 AI 도입을 정당화할 수 없습니다. 패턴의 일관성 (pattern consistency), 모호성에 대한 허용치 (tolerance for ambiguity), 피드백 인프라 (feedback infrastructure), 그리고 사용자 신뢰 (user trust)가 똑같이 결정적인 요소입니다. 이 중 하나라도 놓친다면, 당신은 1년 안에 비활성화될 기능을 만들고 있는 것입니다.

CISO가 옳았던 점 — 그리고 제품 팀이 이의를 제기했어야 했던 점

저희 CISO의 직관은 타당했습니다. 수동 벤더 리스크 평가 (manual vendor risk assessments)는 리소스 병목 현상이었으며, 자동화 (automation)는 올바른 전략적 방향이었습니다. 실수는 자동화의 정의에 있었습니다. 영업 사이클이 경영진으로 하여금 AI를 기대하도록 유도했기 때문에, AI가 기본 가정 (default assumption)이 되어버렸습니다. 2024년의 모든 벤더 리스크 플랫폼 데모는 NLP 기반의 설문지 파싱 (questionnaire parsing) 기능을 선보였고, 가격 모델은 AI 티어 (AI tier)를 선호하도록 설계되어 있었습니다. 규칙 기반 자동화는 18만 달러, AI 기능 활성화 버전은 42만 달러였습니다. 이러한 비용 차이는 앵커링 효과 (anchoring effect)를 만들어냈습니다. 더 많은 비용을 지불하는 것이 현대화에 대한 더 진지한 의지를 나타내는 신호로 작용했습니다.

제품 관리(Product management) 팀은 다음과 같은 강제 질문(forcing question)을 통해 해당 가정을 반박했어야 했습니다. '우리의 공급업체 평가 중 규칙으로 인코딩할 수 없는 판단이 필요한 비율은 몇 퍼센트인가?' 사후 분석(post-mortem)을 통해 해당 분석을 실행한 결과, 그 답은 18%였습니다. 이는 모호한 공급업체 답변이 포함된 예외 사례(edge cases), 신흥 리스크 카테고리에 속하는 공급업체, 또는 전략적 중요성으로 인해 높은 수준의 정밀 조사가 필요한 공급업체들이었습니다. 나머지 82%의 경우, 공급업체 유형, 과거 답변, 조건부 로직 트리(conditional logic trees)를 기반으로 규칙 기반 템플릿(rule-based templates)이 답변을 자동 채울 수 있었습니다. 대다수는 규칙으로 처리하고 예외 사례는 사람이 검토하는 하이브리드 모델(hybrid model)을 채택했다면, 오류 허용 범위가 낮은 워크플로(workflow)에 확률적 출력(probabilistic output)을 도입하지 않고도 70%의 시간 절감 효과를 거둘 수 있었을 것입니다.

David Ohnstad는 이제 이를 기업용 AI 파일럿 개념 증명(enterprise AI pilots proof of concept) 범위 설정을 위한 리트머스 시험지로 사용합니다. 만약 예외 사례의 비율을 정의할 수 있고 그 비율이 25% 미만이라면, 결정론적 자동화(deterministic automation)로 시작하되 패턴 인식(pattern recognition)이 규칙보다 진정으로 뛰어난 경우에만 AI를 추가하십시오. 그 반대, 즉 AI를 먼저 배포하고 나중에 예외 사례의 비율을 발견하는 방식은 우리가 경험한 결과를 초래합니다. 즉, 기술적으로는 성공적인 모델이지만 워크플로가 그 출력을 수용할 수 없기 때문에 운영상으로는 실패하는 결과입니다.

대신 구축했어야 할 규칙 기반 피벗(Rule-Based Pivot)

AI 모델을 폐기한 지 3개월 후, 우리는 조건부 로직(conditional logic)과 템플릿 기반 답변을 사용하여 공급업체 리스크 시스템을 재구축했습니다. 아키텍처는 더 단순했습니다. 공급업체 유형을 사전 승인된 답변 뱅크(answer banks)에 매핑하고, 컴플라이언스 검토가 필요한 답변에 대해서는 플래깅 규칙(flagging rules)을 적용하는 설문 엔진(questionnaire engine) 방식이었습니다. "인프라(infrastructure)" 카테고리의 공급업체는 90개 질문 중 68개에 대해 자동으로 작성된 답변을 받았으며, 나머지 22개 질문은 공급업체의 데이터 액세스 계층(data access tier)에 따라 사람의 검토로 전달되었습니다. "헬스케어(healthcare)" 카테고리의 공급업체는 다른 템플릿 세트를 받는 식이었습니다.

구현에는 11주가 소요되었습니다. 비용은 개발 시간 비용 47,000달러와 설문 플랫폼 운영을 위한 연간 18,000달러가 들었습니다. 시간 절감 효과는 출시 후 첫 6개월 동안 측정된 결과, 컴플라이언스 검토 시간(compliance review hours)이 64% 감소했습니다. 사용자 채택은 즉각적이었습니다. 컴플라이언스 팀은 시스템의 로직이 투명했기 때문에 시스템을 신뢰했습니다. 즉, 답변이 왜 자동으로 채워졌는지(auto-populated) 또는 왜 검토 대상으로 플래그(flagged)가 지정되었는지 정확히 확인할 수 있었고, 답변 뱅크(answer bank)를 직접 제어할 수 있었기 때문입니다. 재차 의구심을 가질 만한 확률적 신뢰 점수(probabilistic confidence score)도 없었습니다.

이 대조적인 사례는 시사하는 바가 큽니다. AI 모델은 더 정교했고, 언어적 변이(linguistic variation)를 더 잘 처리했으며, 데모에서 이해관계자들에게 깊은 인상을 남겼습니다. 규칙 기반 시스템(rule-based system)은 덜 우아했고, 더 많은 사전 설정(upfront configuration)이 필요했으며, 수동 업데이트 없이는 새로운 질문 문구에 적응할 수 없었습니다. 하지만 규칙 기반 시스템은 워크플로우의 실제 자동화 허용 범위와 일치했고, MLOps 인프라가 필요하지 않았으며, 5분기 대신 1분기 만에 투자 대비 수익(ROI)을 달성했습니다. David Ohnstad의 가이드라인은 다음과 같습니다: 정교함이 목표가 아니라, 운영 적합성(operational fit)이 목표입니다. 만약 더 단순한 도구가 비용의 20%만으로 가치의 80%를 제공하고, 사용자 재교육 없이 기존 워크플로우에 통합될 수 있다면, 비록 기술적으로는 덜 흥미로울지라도 그것이 올바른 선택입니다.

AI 투자가 정당화되는 경우 — 세 가지 반사실적 시나리오 (Three Counterfactual Scenarios)

공급업체 리스크 AI 준비도 프레임워크(Vendor Risk AI Readiness Framework)는 '아니오'라고 말하기 위해 설계되었습니다. 하지만 AI 기반의 공급업체 리스크 관리(vendor risk management)가 네 가지 관문을 모두 통과하고 투자를 정당화할 수 있는 시나리오들이 존재합니다. 다음은 David Ohnstad가 이러한 도구들을 성공적으로 배포하는 것을 관찰한 기업들로부터 추출한 세 가지 사례입니다.