AI 시스템을 인수하기 전에 증거 및 퇴출(Exit) 문서를 요구하세요
AI 제품은 통제된 시연에서는 인상적으로 보일 수 있지만, 여전히 부실한 인수 대상일 수 있습니다. 인터페이스가 수동 작업을 숨길 수 있고, 벤치마크가 실제 운영 환경과 맞지 않을 수 있으며, 모델이 약관을 변경할 수 있는 공급업체에 의존할 수 있고, 회사가 폐쇄된 후 운영하는 데 필요한 데이터나 코드를 소유하지 못할 수도 있습니다. 시연과 헤드라인의 정확성만을 검증하는 구매자는 기술 실사(technical due diligence)를 수행하고 있지 않습니다. 그들은 프레젠테이션을 검토하고 있는 것입니다.
중심적인 인수 질문은 “AI가 작동하나요?”가 아닙니다. 그것은 다음과 같습니다: 어떤 입력, 의존성, 통제 장치, 비용, 권리, 그리고 운영 조건 하에서 시스템이 허용 가능한 결과를 산출하는지—그리고 구매자가 거래 후에 그 조건을 보존하거나 대체할 수 있는지?
본 가이드는 범위(scope), 데이터 흐름(data flows), 성능 증거(performance evidence), 핵심 의존성(critical dependencies), 운영 거버넌스(operating governance), 조건, 그리고 교차 기능 인터뷰를 강조하는 기존의 AI 시스템 실사 프레임워크를 각색했습니다. 여기서는 이러한 아이디어를 증거 및 퇴출 문서 패키지(evidence and exit dossier)로 만듭니다. 이는 인수, 조건부 인수, 가격 조정, 개선을 위한 보류금(remediation holdback), 파일럿 테스트, 라이선싱 결정 또는 거부를 지원하는 패키지입니다.
이 방법론은 인수를 포함하여 전략적 투자, 주요 공급업체 계약, 그리고 AI 기반 제품 라인 구매에 적용됩니다. 이는 법률, 회계, 사이버 보안 또는 투자 자문이 아닙니다. 적격 전문가는 해당 거래와 관할권을 평가해야 합니다.
한 장으로 결정하기
모델이 정확해 보이거나, 독점적이거나, 빠르다는 이유만으로 AI 인수를 승인하지 마십시오. 구매자가 주장된 가치를 재현 가능한 증거에 연결하고, 모든 중요한 의존성을 매핑하며, 요구되는 서비스 수준에서 운영하는 비용을 정량화하고, 시스템 사용 및 개선 권리를 확립하며, 신뢰할 수 있는 전환 또는 퇴출 계획을 실행할 수 있을 때만 승인하십시오.
| 결정 | 증거 상태 | 일반적인 조건 |
|---|
| 진행 (Proceed) | 주장 재현; 권리 및 종속성 검증; 운영 계획 자금 확보 | 표준 마감 및 통합 통제 |
| ... | | |
| "조건부 진행(Proceed conditionally)"의 경우, 소유자, 기한, 수락 테스트, 구제책, 그리고 결과(consequence)를 명시해야 합니다. "마감 후 거버넌스를 개선하겠다"는 모호한 약속은 가격이나 통제를 변경하지 않으면서 불확실성을 구매자에게 전가할 뿐입니다. | | |
실제로 인수하는 것이 무엇인지 정의하기
'AI 시스템(AI system)'이라는 문구는 실사(diligence)를 하기에 너무 광범위합니다. 서류를 요청하기 전에 제품 경계(product boundary)를 설정해야 합니다. 자산에는 다음이 포함될 수 있습니다:
- 독점 애플리케이션 코드 (proprietary application code);
- 프롬프트, 라우팅, 가드레일, 검색 로직, 평가 자산 (prompts, routing, guardrails, retrieval logic, and evaluation assets);
- 미세 조정되거나 훈련된 모델 가중치 (fine-tuned or trained model weights);
- API를 통해 접근하는 제3자 기반 모델 (third-party foundation models accessed by API);
- 오픈 소스 모델 및 라이브러리 (open-source models and libraries);
- 라이선스가 부여된 훈련, 참조 또는 개선 데이터 (licensed training, reference, or enrichment data);
- 고객이 제공한 데이터 및 피드백 (customer-provided data and feedback);
- 주석 처리 프로세스 및 계약자 (annotation processes and contractors);
- 클라우드, 벡터 데이터베이스, 모니터링 및 보안 서비스 (cloud, vector database, monitoring, and security services);
- 인터페이스 뒤에 숨겨진 인간 검토 또는 이행 (human review or fulfillment hidden behind the interface);
- 운영 절차, 고객 지원 및 예외 처리 (operating procedures, customer support, and exception handling);
- 상표권, 도메인, 계약 및 배포 관계 (trademarks, domains, contracts, and distribution relationships).
각 구성 요소에 대해 소유 여부, 라이선스 여부, 고객 통제 여부, 오픈 소스 여부, 공급업체 호스팅 여부, 직원 생성 여부, 계약자 생성 여부, 또는 운영상 문서화되지 않았는지 표시해야 합니다. 그런 다음 그것이 양도 가능한지(transferable), 대체 가능한지(replaceable), 수출 가능한지(exportable), 그리고 수익 주장에 필수적인지(necessary for the revenue claim)를 표시합니다.
회사는 비양도성 API 계정, 더 좁은 목적을 위해 라이선스된 데이터, 또는 직원의 개인 작업 공간에 저장된 핵심 프롬프트에 의존하면서 'AI 제품을 소유'할 수 있습니다. 제품은 마감 전에 여전히 기능하지만, 구매자는 그것이 기능하게 만드는 조건(conditions) 자체를 인수하지 못할 수도 있습니다.
투자 가설부터 시작하여, 이를 깨뜨리려고 시도하기
모든 증거 요청은 가치 가설(value thesis)을 테스트해야 합니다. 일반적인 가설에는 다음이 포함됩니다:
- 시스템이 완료된 케이스당 노동력을 줄입니다.;
- 시스템이 전환율 또는 유지율을 개선합니다.;
- 독점 데이터는 지속 가능한 차별화를 창출합니다.;
- 기술은 새로운 시장으로 확장될 수 있습니다.;
- 제품은 허용 가능한 마진으로 더 높은 볼륨에서 운영될 수 있습니다.;
- 팀은 반복 가능한 개선 루프를 가지고 있습니다.;
- 구매자는 자체 구축하는 것보다 빠르게 역량을 통합할 수 있습니다.
각 논지를 반증 가능한 주장(falsifiable claim)으로 재작성합니다. “플랫폼이 지원을 자동화한다”는 “정의된 티켓 인구 집단에 대해, 시스템은 명시된 비율의 케이스에서 인간의 개입 없이 받아들여진 결과를 해결하며, 응답 시간, 품질, 안전 및 비용 임계값을 충족시킨다.”로 바뀝니다.
그런 다음 반증 증거(disconfirming evidence)를 식별합니다. 어떤 것이 그 주장이 틀렸음을 보여줄까요? 숨겨진 인간의 작업, 제외된 어려운 케이스, 지연된 에스컬레이션, 과도한 환불, 높은 검토자 시간, 비싼 추론 비용(inference), 고객 이탈(customer churn), 취약한 보안, 또는 공급업체의 보조금 지원이 모두 설득력 있는 최상위 수치(top-line metric)를 만들면서 논지를 파괴할 수 있습니다.
실사팀은 주장을 좁히는 증거에 보상을 해야 합니다. 제품이 어디에서 실패하는지 아는 판매자가 보편적인 성능을 주장하는 사람보다 운영적으로 더 성숙할 수 있습니다.
증거 및 퇴출 문서 패키지(exit dossier) 구성하기
문서 패키지는 버전 관리되고, 접근 통제가 이루어지며, 정확한 거래 범위와 연결되어야 합니다. 여기에는 12개의 섹션이 포함됩니다:
- 시스템 경계 및 아키텍처;
- 자산, 소유자 및 라이선스 등록부;
- 데이터 출처(data provenance) 및 허용 사용 등록부;
- 성능 주장 및 재현 패키지;
- 보안 및 오용 사례 평가;
- 운영 지표 및 사고 이력;
- 단위 경제학(unit economics) 및 용량 모델;
- 공급업체 및 오픈 소스 의존성 맵;
- 고객 약속 및 규제 사용 맵;
- 조직, 핵심 인물, 프로세스 의존성 맵;
- 통합 및 전환 계획;
- 퇴출(exit), 대체 및 실패 격리 계획.
안전하게 내보내기(export) 또는 원본 증거를 제공할 수 있는 스크린샷은 받지 마십시오. 대시보드 이미지는 정의, 필터, 제외 사례, 시간대를 누락합니다. 데이터 사전(data dictionaries), 계산 논리, 표본 크기, 코호트 경계, 그리고 재무적 또는 운영 기록과의 조정(reconciliation)을 요청하십시오.
민감한 증거는 최소 권한 접근(least-privilege access), 로깅, 적절한 워터마킹, 보존 기간 설정, 그리고 경쟁사나 개인정보 보호 문제로 인해 광범위한 접근이 부적절할 경우 클린팀(clean-team) 구성을 갖춘 통제된 데이터 룸에 보관되어야 합니다. 실사(Diligence)가 모든 고객 데이터를 복사할 수 있는 권한을 의미하는 것은 아닙니다.
종단 간(end-to-end) 데이터 흐름 매핑하기
입력부터 비즈니스 결과까지 실제 거래 하나를 재구성하십시오. 원본 데이터가 수집, 검증, 전처리, 저장, 모델 호출, 검색, 도구 사용, 인간 검토, 출력 전달, 피드백, 모니터링, 삭제 과정을 거치는 모든 단계를 추적해야 합니다.
모든 경계 지점에서 다음 사항을 질문하십시오:
- 어떤 데이터가 들어오며 누가 공급했습니까?
- 이 사용을 포괄하는 어떤 권한이나 계약적 근거가 있습니까?
- 어디에 저장되고 처리됩니까?
- 어떤 하위 프로세서(subprocessor) 또는 모델 제공업체가 이를 받습니까?
- 데이터가 시스템의 학습, 미세 조정(fine-tune), 평가, 또는 개선에 사용됩니까?
- 사람이나 고객과 연결하는 식별자(identifiers)는 무엇입니까?
- 어떤 변환 및 마스킹(redactions)이 발생합니까?
- 추가 사본을 생성하는 로그나 캐시가 있습니까?
- 수정, 접근, 보존 또는 삭제는 어떻게 실행됩니까?
- 시스템 밖으로 무엇이 나가며 어떤 조치를 유발할 수 있습니까?
문서화된 흐름을 원격 측정(telemetry) 및 구성과 대조하여 테스트하십시오. 아키텍처 다이어그램은 종종 이상적인 목표일 뿐입니다. 네트워크 경로, 클라우드 리소스, 데이터 웨어하우스 테이블, API 로그, 기능 플래그(feature flags), 그리고 지원 절차들이 실제로 구현된 시스템을 드러냅니다.
스프레드시트, 수동 내보내기, 비공개 노트북, 메시징 첨부 파일, 임시 버킷, 검토 도구에 대한 '섀도우 경로(shadow path)' 등록부를 작성하십시오. 섀도우 경로는 가장 높은 위험 데이터와 가장 취약한 통제 장치를 자주 보유합니다.
운영 의존성으로서의 데이터 권리 확인하기
데이터 가치는 데이터 권리로부터 분리될 수 없습니다. 단순히 데이터가 “공개적,” “익명화되었음,” 또는 “고객 소유”라는 일반적인 보증이 아니라, 데이터셋 수준에서 출처(provenance)를 요구해야 합니다.
레지스터는 출처, 수집 날짜, 목적, 관련 시 동의 또는 계약 근거, 라이선스, 지리적 제한, 민감 속성, 보유 기간, 삭제 능력, 파생 권한, 모델 학습 권한, 재배포 제한, 그리고 공급업체 권한에 대한 증거를 포함해야 합니다.
고객 데이터의 경우, 계약상의 문구와 실제 사용을 비교해 보세요. 제품이 한 고객의 데이터를 사용하여 다른 사람들을 위한 출력을 개선합니까? 옵트아웃(opt-out)은 파이프라인과 백업에서 준수됩니까? 고객이 데이터를 내보내거나 삭제할 수 있습니까? 임베딩, 미세 조정 예시, 피드백 레이블, 캐시된 프롬프트는 어떻게 되나요?
스크랩되거나 공개된 데이터의 경우, 정확한 출처, 획득 방법, 약관, 로봇 행동(robots behavior), 저작권 분석, 개인 데이터 노출, 그리고 업데이트 프로세스를 파악해야 합니다. “온라인에서 이용 가능”이라는 것은 완전한 권리 의견이 아닙니다.
합성 데이터의 경우, 생성기, 프롬프트 또는 절차, 출처 의존성, 품질 검사, 그리고 합성 결과물이 민감하거나 저작권이 있는 자료를 재현하는지 여부를 문서화해야 합니다. 합성이라는 것이 출처가 없다는 것을 의미하지 않습니다.
폐쇄 후 사용할 수 없는 모든 데이터셋은 성능 재현 테스트에서 제외되어야 합니다. 이는 구매자가 실제로 운영할 수 있는 것을 보여줍니다.
잠긴 코호트(locked cohorts)에서의 성능 주장 재현
판매자에게 정의, 데이터셋, 분모(denominator), 제외 항목, 모델 버전, 코드 버전, 프롬프트 버전, 평가 방법, 날짜, 그리고 소유주를 포함하여 모든 중요한 성능 주장을 나열해 달라고 요청하십시오. 투자 논제와 관련된 주장들을 선택하고 통제된 환경에서 재현해야 합니다.
세 가지 코호트를 사용합니다:
- 참조 코호트 (reference cohort): 판매자가 선언한 평가 세트;
- 운영 재현 코호트 (production replay cohort): 승인된 처리 방식과 알려진 결과를 가진 대표적인 과거 입력 데이터;
- 챌린지 코호트 (challenge cohort): 엣지 케이스(edge cases), 희귀 클래스, 분포 변화(distribution shifts), 오용 사례(abuse cases), 누락 정보 및 고위험 결정.
훈련-테스트 누수(train-test leakage)를 방지합니다. 데이터셋을 해시하고 중복을 검사하며, 평가 예제가 훈련 데이터, 프롬프트 템플릿, 데모 또는 검색 인덱스에 나타나는지 확인합니다. 실행 시점에 가능한 경우 구매자의 챌린지 세트는 기밀로 유지해야 합니다.
원시 예측(raw predictions)으로부터 지표를 재계산합니다. 임계값, 집계 방식, 클래스 균형, 거부(abstentions), 실패, 시간 초과 및 인간의 재정의 여부를 확인합니다. 만약 판매자가 불확실한 사례의 30%를 제외하고 92%의 정확도를 보고한다면, 두 숫자 모두 주장 내용에 포함되어야 합니다.
생성형 시스템의 경우, 정교한 루브릭(structured rubrics)과 여러 평가자를 활용하는 것이 정당화될 때 사용해야 합니다. 의견 불일치(disagreement)를 기록합니다. LLM-as-judge 방식은 대규모로 도움을 줄 수 있지만, 또 다른 모델 의존성을 도입하므로 검증된 인간의 결정에 맞춰 보정되어야 합니다.
모델 출력 대신 결과 수용도를 측정하라
모델 정확도가 비즈니스 성공과 일치하지 않을 수 있습니다. 추출 시스템은 필드를 올바르게 식별할 수 있지만, 워크플로우가 이를 조정하는 데 실패할 수 있습니다. 지원 담당자는 유창한 답변을 작성할 수 있지만, 고객들은 케이스를 재개합니다. 리드 점수 모델은 잠재 고객에게 순위를 매길 수 있지만, 영업팀이 이를 부적격으로 거부할 수 있습니다.
결과 대장(outcome ledger)을 구축합니다:
accepted_outcome_rate = accepted_business_outcomes / eligible_cases
straight_through_rate = accepted_outcomes_without_human_rework / eligible_cases
exception_rate = cases_routed_to_exception / eligible_cases
...
결과를 보기 전에 적격성(eligibility)과 수용 여부(acceptance)를 정의합니다. 제외된 경우, 시간 초과된 경우, 모호한 사례를 보고해야 합니다. 안전하게 거부할 수 있는 모델은 가치가 있을 수 있습니다. 하지만 거부를 조용히 제거하는 지표는 오해의 소지가 있습니다.
모델 출력에서 원장(ledger), CRM, 결제(payment), 지원(support) 또는 고객 활동까지 샘플을 추적하세요. 주장된 절감액이 이론적인 시간 연구에만 있는 것이 아니라 일정표, 인원 계획(headcount plans), 공급업체 지출(vendor spend), 처리량(throughput) 또는 서비스 용량에 나타나는지 확인하십시오.
단위 경제 분석 분해하기
AI 총 마진은 작업 부하 혼합 및 아키텍처에 민감합니다. 고정 비용과 변동 비용을 분리하세요:
contribution_per_accepted_case =
revenue_per_case - model_inference
...
코호트별 모델 비용 분석: 짧은 문서 대 긴 문서, 일반 언어 대 희귀 언어, 단순 도구 대 복잡한 도구, 신규 고객 대 기존 고객, 정상 트래픽 대 피크 트래픽. 평균 비용은 손실을 발생시키는 꼬리(tail)를 숨길 수 있습니다.
사용량을 공급업체 송장 및 클라우드 청구서와 조정하세요. 할인, 크레딧, 무료 등급(free tiers), 창립자 협정(founder arrangements), 최소 약정(minimum commitments)을 확인하십시오. 일시적인 보조금은 제거하세요. 공급업체의 가격 변동, 토큰 증가, 더 높은 검토 빈도, 낮은 캐시 적중률 등을 스트레스 테스트하세요.
용량도 중요합니다. 동시성(concurrency), 도구 의존성, 속도 제한(rate limits), 대기열 처리(queueing), 재시도(retries) 및 다운스트림 시스템을 반영하는 부하 테스트를 실행하세요. 현재 볼륨에서 작동하는 제품이라도 구매자의 규모에서는 다른 아키텍처와 자본 프로필이 필요할 수 있습니다.