안녕하세요. 엔터프라이즈 AI를 위한 AI-Ready Data Platform, Syntitan을 만드는 CUBIG입니다.
사내에 AI를 도입할 때 필요한 재료는 이미 회사 안에 있는 경우가 많습니다. 고객 데이터와 업무 규칙, 예외, 승인 기준은 데이터베이스와 문서, 엑셀 파일, 오래 일한 직원의 경험 속에 흩어져 있는데, 이 글에서는 이를 묶어 데이터 자산이라고 부릅니다.
어려운 건 그중 무엇이 아직 유효한지, 어떤 조건에서 의미가 있는지, AI를 적용하려는 업무에 실제로 쓸 수 있는지를 가려내는 일입니다. 엑셀 수식 하나에 꼭 지켜야 할 업무 규칙이 담겨 있는가 하면, 오래전에 쓰던 임시방편이 지워지지 않고 남아 있기도 합니다. 특정 고객에게만 적용하는 예외 역시 고객과의 약속일 수도 있고, 지금은 책임지는 사람이 없는 실수일 수도 있습니다.
이 글에서 말하는 AI-Ready Data는 정해진 업무와 모델 또는 에이전트, 평가 방식, 정책, 운영 환경에 맞춰 준비와 검증을 마친 데이터 상태를 말합니다. 데이터에 접근할 수 있다는 것만으로 AI-Ready 상태라고 보기는 어렵습니다. 데이터 자산이 무슨 뜻인지 설명할 수 있고, 업무에 맞는지 시험해 봤고, 무언가 바뀌었을 때 근거를 다시 꺼내 볼 수 있어야 비로소 AI에 쓸모가 생깁니다.
그래서 “AI부터 도입할지, 데이터부터 정리할지”를 따지는 질문은 오히려 판단을 흐리기 쉽습니다. 실제로 해야 할 일은 업무 하나를 정하고 그 업무에 필요한 데이터와 판단 기준을 준비하는 데서 시작합니다. 그다음 조건에 맞게 다듬고, 근거를 남기며 검증하고, 조건이 바뀌면 다시 확인합니다. 파일럿에서 그럴듯한 결과가 나와도 이 과정은 여전히 숙제로 남아 있을 수 있습니다.
업무가 그렇게 돌아가는 이유는 시스템 밖에 있는 경우가 많습니다
데이터베이스를 통해 승인된 결괏값은 확인할 수 있더라도, 왜 특정 고객에게만 예외 기준이 적용됐는지, 검토자가 왜 결과를 뒤집었는지, 엑셀 수식이 어떤 시스템 문제를 메우려고 들어갔는지는 파악하기 어렵습니다. 이런 이유는 공식 시스템과 문서, 엑셀, 사람의 기억 곳곳에 흩어져 있는 경우가 많습니다.
정부 기관과 민간 기업 재무 부서의 스프레드시트 6만 5천 개를 분석한 연구를 보면, 스프레드시트는 정식 시스템과 나란히 보고와 업무 처리에 쓰이고 있었습니다. 이 연구가 모든 스프레드시트가 가치 있거나 정확하다고 보여 주는 것은 아니지만, 데이터 목록을 정리할 때 뒷전으로 밀리는 자료에도 업무 노하우가 들어 있을 수 있다는 점은 뒷받침합니다.
문서와 승인 이력, 고객 응대 메모, 현업 전문가의 판단도 마찬가지입니다. 이런 자료를 보면 업무에서 무엇을 구분해야 하는지 알 수 있지만, 예외를 왜 두었는지, 그 예외가 지금도 유효한지는 적혀 있지 않을 때도 있습니다.
업무 노하우가 시스템 밖에 흩어져 있는 모습은 해외 제조 기업의 사례에서도 확인할 수 있습니다. 미국 제지 기업 조지아퍼시픽(Georgia-Pacific)은 설비 정비 노하우가 종이 문서와 디지털 파일, 오래 일한 직원의 경험에 나뉘어 있었고, AI로 현장 작업자를 돕기 위해 이 노하우를 한데 모았습니다(AWS가 공개한 고객 사례). 벤더가 공개한 사례라 CUBIG의 방법론을 검증한 자료는 아니지만, 사내 AI 도입에 시스템 하나에 담기지 않은 현장 노하우가 필요할 수 있다는 점은 보여 줍니다.
그래서 데이터 자산을 AI에 쓰려면, AI로 처리할 업무를 기준으로 그 자산이 무슨 뜻인지, 어디까지 적용되는지, 누가 책임지는지, 어떤 한계가 있는지를 먼저 정리해야 합니다. 데이터에 접근할 수 있는 것과 AI에 실제로 활용할 수 있는 것의 차이가 여기서 생깁니다.
겉으로는 같은 규칙도 생긴 이유는 다를 수 있습니다
견적을 승인하기 전에 금액을 수동으로 조정하는 엑셀 수식이 있다고 해 보겠습니다. 이 수식은 고객과 맺은 정당한 약속을 반영한 것일 수도 있고, 알려진 시스템 오류를 메우려고 넣은 것일 수도 있습니다. 예전에 사고가 났을 때 급하게 넣었다가 아무도 지우지 않아 그대로 남은 것일 수도 있습니다.
이 수식을 자동화된 업무에 그대로 옮기면 계산식은 따라오지만, 그 수식이 왜 생겼는지는 따라오지 않습니다.
업무 자료를 AI에 넣기 전에 아래 질문에 먼저 답해 보세요.
- 늘 적용하는 규칙인가요, 특정 고객만의 예외인가요, 아니면 임시방편인가요?
- 어떤 정책이나 계약, 운영 조건에 근거한 규칙인가요?
- 이 규칙을 지금 왜 쓰는지 설명하고 승인할 수 있는 사람이 있나요?
- 이 규칙으로 문제없는 결과가 나온 사례가 있나요?
- 어떤 일이 생기면 이 규칙을 더 이상 쓰지 않아야 하나요?
이 질문에 답하지 못한 채 자료를 AI에 넣으면, 회사의 노하우를 살리기는커녕 예전의 땜질을 더 넓게 퍼뜨릴 수 있습니다.
OMG(Object Management Group)의 의사결정 모델 표기법(DMN) 같은 표준을 쓰면 업무 판단과 규칙을 모델로 명확히 표현해 여러 사람이 함께 검토할 수 있어, 이렇게 따져 본 판단을 기록해 두는 데 도움이 됩니다. 이렇게 표현해 두는 것만으로도 도움은 되지만, 표준이 올바른 규칙을 찾아 주거나 그 규칙이 지금도 유효한지 확인해 주지는 않습니다. 그 판단은 여전히 근거를 보고, 결정에 책임질 사람이 내려야 합니다.
준비는 업무 하나를 정하는 데서 시작합니다
준비는 모든 데이터를 깨끗이 정리하는 데서가 아니라 업무를 정하는 데서 시작해야 합니다. 먼저 AI로 어떤 업무를 처리할지, 누가 쓸지, 모델이나 에이전트가 정해졌다면 무엇을 어떤 버전으로 쓸지, 무엇을 성공으로 볼지, 어떤 조건에서 평가할지를 정합니다. 지켜야 할 정책의 범위도 이때 함께 확인합니다.
업무 하나를 시험하려고 모든 데이터를 완벽하게 만들 필요는 없습니다. 반드시 지켜야 할 정책 조건은 그대로 지키면서, 그 업무에 필요한 데이터와 맥락, 접근 권한, 데이터 출처 기록(데이터 프로버넌스), 책임자를 찾아내는 것이 먼저입니다. 업무의 의미와 권한을 함께 관리하는 체계가 회사에 있다면, 맥락을 끝없이 모으지 않고 업무를 중심으로 정리하는 데 도움이 될 수 있습니다.
NIST의 AI 위험관리 프레임워크(AI RMF)는 쓰는 말은 다르지만, Map 단계에서 AI를 쓰는 목적과 사용자, 배포 환경, 적용 범위, 전제와 한계, 사람이 어떻게 감독할지를 문서로 남기도록 권고합니다. NIST가 CUBIG의 방법론이나 Syntitan을 보증하는 것은 아니지만, 어떤 맥락에서 쓸지 정해야 AI의 근거에도 의미가 생긴다는 일반 원칙은 뒷받침합니다.
CUBIG은 대상 업무를 정하고 업무별로 다듬기에 앞서 Baseline으로 데이터의 공통 준비 상태를 확인합니다. 특정 모델이나 에이전트와 상관없이 6가지 Core Readiness 축으로 진단하기 때문에, 모델을 고르기 전에도 써 볼 수 있습니다. 다만 이 점수가 최종 AI-Ready 판정이거나 특정 업무가 성공할 확률을 뜻하지는 않습니다.
같은 데이터도 업무마다 맞춰야 할 조건이 다릅니다
고객 상담 에이전트와 가격 산정 모델, 컴플라이언스 검토 도우미는 겹치는 기록을 쓰더라도 필요한 항목과 정의, 권한, 평가 데이터, 승인 기준이 저마다 다릅니다. 그래서 같은 데이터셋이 어떤 업무에는 맞고 어떤 업무에는 맞지 않을 수 있습니다.
조정 단계에서는 고른 자산을 Target Profile에 연결해 이 차이를 적어 둡니다. 실제 업무, 모델이나 에이전트 버전, 성공 지표, 승인 기준, 평가용 데이터나 홀드아웃 세트, 실행 환경, 프롬프트나 검색 조건, 적용되는 정책, 승인자가 여기에 들어갑니다.
이렇게 업무 기준을 세우는 것이 Qualification의 시작입니다. 데이터 품질을 일반적인 점수로 매기는 것과 달리, 정해진 업무에 맞게 데이터를 다듬고 결과를 제대로 비교할 수 있는 조건을 갖추는 단계입니다.
Target Profile을 채우다 보면 빠져 있던 맥락이 드러나기도 합니다. 빈칸 없이 채워진 항목이 지역마다 다른 뜻으로 쓰이고 있거나, 한 고객군에서는 맞던 수식이 다른 고객군에서는 맞지 않거나, 승인 규칙이 기록된 적 없는 전문가의 판단에 기대고 있는 경우입니다. 이런 문제는 정제로 고칠 수 있는 문제처럼 보여도, 실제로는 그 데이터를 AI를 도입할 업무에 쓸 수 있는지를 좌우하는 조건입니다.
파일럿 결과는 그 조건에서만 유효한 근거입니다
파일럿에서 좋은 결과가 나왔다는 것은 그 조건에서 좋은 결과가 나왔다는 뜻입니다. 모델이나 데이터, 업무 흐름, 배포 환경이 바뀐 뒤에도 같은 결과가 나온다고 보장하지는 않습니다.
CUBIG은 Qualification 단계에서 Proof Run으로, 조건을 통제하고 기록한 상태에서 AI 결과를 비교합니다. 이때 어떤 데이터 버전을 썼는지, 어떻게 평가했고 성공 기준은 무엇이었는지, 결과와 편차, 실패 사례, 중간에 바꾼 점, 아직 비어 있는 부분까지 함께 남겨야 합니다. 결과는 적합(Qualified), 부적합(Not Qualified), 판단 보류(Inconclusive)로 나뉘는데, 판단 보류는 근거가 부족하다는 뜻이므로 성공이나 실패로 포장하지 않아야 합니다.
이런 기록 없이 파일럿을 마치면 이른바 좀비 PoC(Zombie PoC)가 생깁니다. CUBIG은 결과는 나왔지만 운영으로 확대할지, 고칠지, 다시 시험할지, 멈출지를 근거를 갖고 판단하지 못하는 파일럿을 좁은 뜻에서 이렇게 부릅니다. 시장을 나누는 분류나 AI 실패율 통계가 아니고, 그 파일럿이 끝났다는 뜻도 아닙니다.
이런 파일럿은 시연 결과가 인상적이었어도, 당시 업무 기준을 다시 만들 수 없고, 시험에 쓴 데이터 상태를 되찾을 수 없고, 바뀐 조건과 비교할 수 없고, 검토자가 왜 결과를 받아들였는지도 설명하지 못하는 경우가 있습니다. 시연을 한 번 더 하면 결과는 또 나오겠지만, 그것만으로 빠진 의사결정 기록이 채워진다는 보장은 없습니다.
이럴 때는 다음 결정을 내리는 데 꼭 필요한 근거부터 다시 모읍니다.
- 대상 업무와 사용자, 성공 기준, 승인 기준
- 시험에 쓴 데이터 자산과 당시 데이터 상태
- 모델이나 에이전트, 프롬프트, 검색 출처, 도구, 실행 환경
- 평가 방법과 결과, 한계, 사람 검토 책임자
- 파일럿 범위 밖에 있던 실제 운영 조건
- 검토 이후에 생긴 중요한 변경 사항
목표는 지금 있는 근거로 어디까지 판단할 수 있는지 가려내는 것이고, 모든 파일럿을 살려 내려는 것은 아닙니다.
운영 중에는 언제 다시 검증할지 알 수 있어야 합니다
데이터가 바뀌고, 모델이나 에이전트가 업데이트되고, 프롬프트와 검색 출처, 도구, 권한, 정책, 실행 환경이 달라지면, 한 번 적합 판정을 받은 데이터도 더는 맞지 않을 수 있습니다. 릴리스(Release) 기록만으로는 실제 실행에서 무엇을 썼는지 알기 어렵고, 버전 이력만으로 운영 근거가 갖춰지지도 않습니다.
CUBIG은 릴리스 이후의 실행 조건을 기록하고 재검증이 필요한지 판단하는 운영 단계를 Assurance로 설명합니다. Release 또는 릴리스 상태(Release State)를 실제 실행과 묶는 런 바인딩(Run Binding)을 남기고, Change Event나 Change History로 무엇이 바뀌었는지 기록해, 재검증(Requalification)이 필요한지 판단할 수 있게 하는 흐름입니다. 개념상 단계를 나눈 것이며, 모든 단계가 자동으로 이뤄진다거나 Syntitan이 성능을 보장한다는 뜻은 아닙니다.
목적은 발생할 수 있는 실패를 모두 잡아내는 데 있지 않고, 예전에 내린 결정이 더는 맞지 않게 된 시점을 알아챌 수 있을 만큼 근거를 남겨 두는 데 있습니다. NIST도 AI 위험관리를 시스템 수명주기 전체에 걸쳐 이어지는 일로 보고, 모니터링과 정기 검토를 하고, 책임을 분명히 하고, 맥락이나 기능이 바뀌면 다시 검토하라고 권고합니다. 정책 문서만으로는 특정 실행 당시의 데이터 상태와 조건을 되짚을 수 없어서, AI 에이전트에게 실제로 일을 처리할 권한을 맡길수록 이런 기록이 더 중요해집니다.
근거가 보이면 다음 결정을 내릴 수 있습니다
업무와 데이터 자산, 시험 조건, 바뀐 점이 정리되면, 멈춰 있던 프로젝트도 막연한 걱정에서 벗어나 구체적인 결정을 내릴 수 있습니다. 아래 표는 CUBIG이 정리한 판단 틀이며, 업계 표준은 아닙니다.
중단했다고 사내 AI 도입에 실패한 것은 아닙니다. 검증해 보고 멈추는 것이 가장 책임 있는 결정일 때도 있습니다.
CUBIG의 관점
CUBIG은 회사의 카테고리를 AI-Ready Data Operating Layer로, Syntitan을 AI-Ready Data Platform으로 정의합니다. CUBIG이 보는 기회는 멈춘 파일럿을 되살리는 데서 그치지 않습니다. 회사에 이미 있는 자산을 AI를 활용할 구체적인 업무에 쓸 수 있는 데이터 자산으로 만들고, 다듬은 데이터가 그 업무에 맞는지 시험하고, 조건이 바뀌어도 계속 운영할 수 있도록 근거를 남기는 일까지 모두 기회로 봅니다.
다만 이 글은 Syntitan이 모든 규칙을 자동으로 찾아내거나, 모든 자료를 검증하거나, 모든 PoC를 살려 내거나, 운영 준비를 보장한다고 주장하지 않습니다. 그렇게 말하려면 실제 구현과 성과로 뒷받침되는 근거가 먼저 있어야 합니다.
필요한 데이터 자산은 이미 회사 안에 있을지 모릅니다. 앞으로 결정을 내릴 때 그 자산을 왜 써도 되는지 설명할 수 있을 때 사내 AI 도입 준비가 시작됩니다.
중요한 업무 하나에서 시작해 보세요. 그 업무가 기대고 있는 데이터와 노하우를 찾고, 지금도 유효한 규칙과 예전의 임시방편을 나누고, Target Profile을 정해 비교할 수 있는 근거를 만든 다음, 운영 확대와 보완, 재시험, 중단 가운데 무엇을 할지 정하면 됩니다.
지금 AI를 도입하려는 업무가 있다면 Syntitan이 이 과정을 어떻게 돕는지 확인해 보세요.
