AI가 KPI와 숫자를 직접 계산하게 해도 될까? 기업 AI의 숫자 신뢰성 설계
AI에게 “이번 분기 목표 달성률을 계산해 줘”라고 해도 될까?
생성형 AI를 기업 업무에 적용하다 보면 자연스럽게 숫자를 묻게 됩니다.
예를 들어 다음과 같은 질문입니다.
“이번 분기 목표 달성률은 얼마인가?”
“실제로 수주 가능성이 높은 영업 파이프라인은 얼마인가?”
“현재 손실 위험이 높은 프로젝트는 어디인가?”
“조직별 가동률은 어떻게 되는가?”
“지난달 대비 원가율이 얼마나 높아졌는가?”
생성형 AI는 이런 질문을 이해하고 자연스럽게 설명할 수 있습니다.
그렇다면 필요한 데이터를 모두 LLM에게 넘기고 계산까지 맡기면 되는 것일까요?
기업 업무에서는 조금 다르게 접근할 필요가 있습니다.
특히 매출, 원가, 손익, 목표 달성률, 가동률, 파이프라인처럼 중요한 경영 숫자는 단순한 산술문제가 아닙니다.
어떤 데이터를 사용할 것인지, 어느 시점을 기준으로 할 것인지, 어떤 항목을 포함하고 제외할 것인지, 어떤 계산식을 적용할 것인지가 함께 정의되어야 합니다.
GS비즈플이 기업 AI에서 중요하게 보는 원칙도 이 부분입니다.
중요한 금액·비율·KPI는 LLM이 임의로 계산하게 하기보다, 원천 데이터와 검증된 계산 로직을 기준으로 산출하고 AI는 그 결과를 분석하고 설명하는 역할을 담당하도록 분리하는 것이 중요합니다.
기업 AI에서 숫자는 왜 단순 계산 문제가 아닐까?
예를 들어 AI에게 다음 질문을 했다고 가정해 보겠습니다.
“이번 분기 영업 파이프라인은 얼마인가?”
겉으로 보면 CRM의 영업기회 금액을 더하면 될 것처럼 보입니다.
하지만 실제 기업에서는 먼저 여러 기준을 확인해야 합니다.
어느 영업단계부터 파이프라인으로 인정하는가?
이미 장기간 활동이 없는 영업기회도 포함하는가?
예상수주일이 이번 분기인 건만 포함하는가?
영업기회 금액 전체를 포함하는가?
수주확률을 적용하는가?
계약 완료 건은 제외하는가?
취소되거나 보류된 건은 어떻게 처리하는가?
어느 시점의 CRM 데이터를 기준으로 하는가?
회사마다 이 기준은 다를 수 있습니다.
따라서 KPI는 숫자의 합계가 아니라 기업이 정한 업무 정의와 계산기준의 결과입니다.
AI가 숫자를 다루려면 데이터뿐 아니라 그 숫자가 기업에서 어떤 의미를 갖는지 이해할 수 있는 구조가 필요합니다.
LLM Non-Calculation이란 무엇인가?
U.STRA Enterprise Ontology AI에서는 중요한 설계 원칙 중 하나로 LLM Non-Calculation을 둡니다.
의미는 단순합니다.
중요한 금액·비율·KPI를 LLM이 임의로 계산하게 하지 않는 것입니다.
여기서 핵심은 AI에게 숫자를 보여주지 않는다는 뜻이 아닙니다. 역할을 나누는 것입니다.
검증된 시스템과 계산 로직이 담당하는 일
원천 데이터 조회
금액 계산
비율 계산
KPI 산출
조건 적용
집계
기준시점 관리
LLM이 담당하는 일
사용자의 질문 이해
계산결과 분석
차이 설명
원인 정리
주요 위험요인 요약
추가 확인사항 제안
경영진이 이해하기 쉬운 자연어 설명
즉,
계산은 결정적 로직으로, 해석은 AI로 분리하는 구조입니다.
첫 번째 원칙은 RDB / Source First입니다
기업의 중요한 숫자에는 출처가 있어야 합니다.
예를 들어 “이번 달 매출은 얼마인가?” 라는 질문에 답한다면 AI가 과거 보고서나 회의자료에서 숫자를 찾는 것보다 ERP 등 원천시스템의 확정값을 사용하는 것이 적절할 수 있습니다.
GS비즈플은 이를 RDB / Source First 관점에서 봅니다.
확정된 숫자는 가능한 범위에서 원천 시스템에서 가져옵니다.
예를 들면 다음과 같습니다.
ERP
매출
원가
매입
비용
청구
수금
CRM
영업기회 금액
영업단계
예상수주일
영업활동
HR
조직
인력
투입상태
가용상태
PMS
프로젝트 일정
진척
변경사항
AI는 이러한 시스템의 데이터를 근거로 분석해야 합니다.
문서와 보고서는 중요한 설명과 정성적 맥락을 제공할 수 있지만, 확정된 숫자의 Source와 같은 역할을 한다고 단정할 수는 없습니다.
문서의 숫자와 원천시스템의 숫자는 역할이 다릅니다
예를 들어 지난주 경영회의 보고서에 “이번 분기 예상 매출 100억 원” 이라고 적혀 있다고 가정하겠습니다.
이번 주 ERP와 CRM 데이터를 다시 조회하면 상황이 달라졌을 수 있습니다.
새로운 수주가 발생했을 수도 있고, 계약이 연기됐을 수도 있으며, 일부 프로젝트의 청구시점이 변경됐을 수도 있습니다. RAG가 지난주 보고서를 잘 찾아준다고 해도 현재 데이터를 기준으로 한 답과 같다고 볼 수는 없습니다.
그래서 기업 AI에서는 다음 두 가지를 구분하는 것이 중요합니다.
문서→ 당시 판단, 설명, 사유, 보고내용
원천 데이터→ 현재 또는 지정된 기준시점의 실제 값
둘은 경쟁 관계가 아닙니다. 오히려 함께 사용할 때 더 의미가 있습니다.
예를 들어 AI가
“현재 예상 매출은 95억 원이며 지난주 보고 대비 5억 원 감소했습니다. 주요 원인은 A 영업기회의 예상수주일 변경입니다.” 라고 설명하려면,
현재 CRM과 ERP 데이터, 과거 보고자료, 계산식, 변경된 영업기회 상태를 함께 연결할 수 있어야 합니다.
KPI 계산에서는 ‘공식’을 먼저 정해야 합니다
기업 AI를 구축하면서 자주 발견되는 문제가 있습니다. 같은 KPI를 부서마다 다르게 이해하는 것입니다.
예를 들어 ‘가동률’이라는 지표 하나만 보겠습니다.
어떤 조직에서는 실제 프로젝트 투입시간 ÷ 전체 근무가능시간 으로 계산할 수 있습니다.
다른 조직에서는 교육이나 제안업무를 포함할 수도 있습니다. 휴가와 교육시간을 분모에서 제외하는 회사도 있을 수 있습니다. 이처럼 KPI의 이름이 같아도 계산기준은 다를 수 있습니다.
AI에게 단순히
“가동률 계산해 줘.” 라고 요청하기 전에 먼저 확인해야 합니다.
가동률의 정의는 무엇인가?
분자는 무엇인가?
분모는 무엇인가?
어떤 데이터를 포함하는가?
어떤 데이터를 제외하는가?
어느 기준시점을 사용하는가?
조직별 예외규칙이 있는가?
이를 명확히 해야 AI의 분석결과도 일관될 수 있습니다.
기업 온톨로지는 KPI의 ‘의미’를 연결합니다
숫자의 신뢰성은 계산식만으로 끝나지 않습니다.
AI가 계산결과를 업무적으로 해석하려면 KPI가 어떤 업무개체와 연결되는지도 알아야 합니다.
예를 들어,
Project Profitability
라는 KPI가 있다고 가정해 보겠습니다.
이 KPI는 다음과 연결될 수 있습니다.
Project→ Customer와 연결
Project→ Contract와 연결
Project→ Employee 투입과 연결
Project→ Revenue와 연결
Project→ Cost와 연결
그리고 회사가 정한 계산식으로
Revenue / Cost / Forecast
등을 이용해 프로젝트의 상태를 판단할 수 있습니다. 온톨로지는 단순히 KPI의 수식을 저장하는 것이 아니라,
어떤 Entity와 데이터가 연결되고 어떤 Rule을 적용하며 그 결과가 어떤 Decision에 사용되는지
구조화하는 역할을 할 수 있습니다.
‘손실 위험 프로젝트’를 AI에게 묻는다면 무엇이 필요할까?
예를 들어 경영진이 AI에게 다음과 같이 질문합니다.
“현재 손실 위험이 높은 프로젝트를 알려줘.”
AI가 답하려면 먼저 데이터를 가져와야 합니다.
ERP
매출
원가
청구
비용
PMS
일정
진행률
변경과업
검수상태
HR
투입인력
추가투입
인건비
그다음 회사의 계산기준이 필요합니다.
예를 들어 예상손익을 계산한다면 어떤 매출과 원가를 포함할지 정의해야 합니다.
다음으로 업무규칙을 적용합니다.
일정지연이 발생했는가?
추가 투입이 증가했는가?
계약 변경이 발생했는가?
검수나 청구가 지연되고 있는가?
이 과정을 거쳐 시스템이 위험지표와 관련 수치를 계산합니다.
그다음 AI가 설명합니다.
“A 프로젝트는 예상원가 증가와 일정 지연이 동시에 발생하고 있어 우선 점검이 필요합니다.”
여기에서 LLM의 역할은 손익을 임의로 만드는 것이 아니라,
검증된 데이터와 계산결과를 바탕으로 의미를 해석하고 사람이 판단하기 쉽게 설명하는 것입니다.
AI가 계산하지 않는다고 해서 AI 분석이 약해지는 것은 아닙니다
오히려 역할을 분리하면 기업 AI의 활용 범위가 더 명확해질 수 있습니다.
예를 들어 시스템이 다음 데이터를 계산했다고 가정해 보겠습니다.
매출 목표: 100억 원
현재 실적: 72억 원
유효 파이프라인: 18억 원
예상 실적: 90억 원
AI는 이 숫자를 다시 임의로 계산하는 것이 아니라, 이를 바탕으로 질문에 답할 수 있습니다.
“목표 달성이 가능한가?”
“부족한 10억 원을 채우려면 어떤 영업기회를 점검해야 하는가?”
“어느 조직의 차이가 가장 큰가?”
“지난달보다 전망이 나빠진 이유는 무엇인가?”
여기에 AI의 가치가 있습니다.
AI는 숫자를 만드는 계산기가 아니라, 검증된 숫자를 업무 맥락에서 해석하는 분석 인터페이스가 될 수 있습니다.
계산과 추론을 분리해야 합니다
기업 AI에서는 다음 세 영역을 구분해서 보는 것이 좋습니다.
사실
원천 시스템에서 확인할 수 있는 데이터입니다.
예:
매출 72억 원
프로젝트 15개
영업기회 23건
계산
검증된 공식과 조건을 적용한 결과입니다.
예:
목표 달성률
프로젝트 손익
가동률
파이프라인 금액
AI 추론
사실과 계산결과, 업무규칙을 바탕으로 AI가 제공하는 분석입니다.
예:
목표 미달 가능성이 높다
특정 프로젝트의 우선 점검이 필요하다
특정 영업기회의 관리가 중요하다
이 세 가지를 구분하면 사용자는 AI 답변에서
무엇이 사실이고,무엇이 계산이며,무엇이 AI의 분석인지
확인할 수 있습니다.
기업 AI의 신뢰성을 높이는 중요한 구조입니다.
Evidence First가 필요한 이유
AI가 다음과 같이 답했다고 생각해 보겠습니다.
“A사업부는 이번 분기 목표 달성 가능성이 낮습니다.”
경영진은 바로 물을 수 있습니다.
“왜 그렇게 판단했지?”
좋은 기업 AI라면 다음 정보를 함께 확인할 수 있어야 합니다.
현재 실적
목표
유효 파이프라인
적용한 계산식
데이터 기준시점
사용한 ERP·CRM Source
적용한 업무 Rule
AI가 해석한 주요 원인
GS비즈플은 이를 Evidence First 관점에서 접근합니다.
AI 답변의 신뢰성은 자연스러운 문장만으로 만들어지지 않습니다.
결론을 데이터·계산식·기준시점·Source와 연결할 수 있어야 합니다.
기준시점을 반드시 표시해야 합니다 숫자는 언제의 값인지에 따라 의미가 달라집니다.
예를 들어,
“이번 분기 예상 매출은 90억 원입니다.”
라는 답에는 최소한 어느 시점의 데이터인지 확인할 수 있어야 합니다.
8월 1일의 CRM과 8월 19일의 CRM은 결과가 다를 수 있습니다.
프로젝트 원가도 추가 투입이나 비용처리 시점에 따라 달라질 수 있습니다.
그래서 기업 AI의 숫자 답변에는 가능한 범위에서 다음과 같은 정보가 연결되는 것이 좋습니다.
데이터 기준시점
원천 시스템
조회조건
적용한 계산식
포함·제외 기준
사용자는 숫자 자체뿐 아니라 숫자가 만들어진 조건을 확인할 수 있어야 합니다.
같은 KPI를 여러 부서가 다르게 계산하면 AI보다 먼저 기준을 정리해야 합니다
AI PoC를 하다 보면 기술 문제가 아니라 조직의 기준 문제가 발견될 수 있습니다.
예를 들어
영업본부는 파이프라인을 80억 원이라고 보고,
경영관리팀은 65억 원이라고 보고할 수 있습니다.
둘 중 하나가 반드시 틀렸다고 단정할 수는 없습니다.
포함하는 Stage와 수주확률, 예상수주일 기준이 다를 수 있기 때문입니다.
이 상태에서 AI만 연결하면 AI도 어떤 계산기준을 사용해야 하는지 결정하기 어렵습니다.
따라서 다음과 같은 기준을 정리해야 합니다.
KPI Name실질 영업 파이프라인
Definition무엇을 의미하는가?
Data Source어느 시스템을 기준으로 하는가?
Formula어떻게 계산하는가?
Inclusion Rule무엇을 포함하는가?
Exclusion Rule무엇을 제외하는가?
Reference Date어느 시점을 기준으로 하는가?
Owner누가 공식 기준을 관리하는가?
이 과정 자체가 기업의 중요한 지식자산이 될 수 있습니다.
RAG만으로 KPI 계산이 어려울 수 있는 이유
RAG는 관련 문서와 정보를 검색해 AI 답변에 제공하는 데 유용합니다.
예를 들어
“우리 회사의 매출 인식 기준은 무엇인가?”
“프로젝트 위험관리 기준은?”
같은 질문에는 업무 규정이나 매뉴얼을 찾아줄 수 있습니다.
하지만
“현재 프로젝트별 예상손익을 계산해 줘.”
와 같은 질문에는 현재 ERP나 PMS의 실제 데이터가 필요합니다.
따라서 기업 AI에서는 다음과 같이 역할을 분리할 수 있습니다.
RAG→ 규정·매뉴얼·보고서·정성정보
RDB / API→ 현재 확정 데이터
Deterministic Calculation→ KPI와 금액 계산
Ontology / Rules→ 업무 의미와 판단기준
LLM→ 분석과 설명
이렇게 구성하면 문서와 숫자가 각각 적절한 역할을 맡을 수 있습니다.
KPI 계산 구조를 단계별로 보면
기업 AI의 KPI 분석은 다음과 같이 설계할 수 있습니다.
1단계. 질문을 이해합니다
사용자가 묻습니다.
“이번 분기 목표 달성 가능성을 알려줘.”
2단계. 필요한 KPI를 식별합니다
목표
현재 실적
예상 실적
유효 파이프라인
3단계. 원천 데이터를 조회합니다
ERP와 CRM 등 필요한 시스템에서 데이터를 가져옵니다.
4단계. 검증된 계산식을 적용합니다
회사에서 정의한 공식 로직으로 KPI를 계산합니다.
5단계. 업무규칙을 적용합니다
어떤 파이프라인을 인정하는지와 같은 업무 기준을 반영합니다.
6단계. Evidence를 연결합니다
Source, 기준시점과 계산기준을 기록합니다.
7단계. AI가 분석합니다
계산결과를 바탕으로 목표 차이와 주요 원인을 설명합니다.
8단계. 사람이 판단합니다
중요한 경영판단은 사람이 최종적으로 결정합니다.
이를 정리하면 다음과 같습니다.
Question→ Data Source→ Deterministic Calculation→ Business Rule→ Evidence→ AI Reasoning→ Decision Support
AI Agent에서는 숫자 신뢰성이 더 중요해집니다
AI가 단순히 답변만 하는 단계에서는 사용자가 결과를 검토할 수 있습니다.
하지만 AI Agent가 실제 업무까지 수행한다면 계산의 영향이 커집니다.
예를 들어 Agent가
“손실 위험 프로젝트를 찾아 PM에게 점검 요청을 만들어라.”
라는 업무를 수행한다고 가정해 보겠습니다.
위험 판단의 숫자가 잘못되면 엉뚱한 프로젝트에 업무를 생성할 수 있습니다.
영업 Agent가 잘못된 파이프라인 계산을 기준으로 Follow-up Task를 생성할 수도 있습니다.
그래서 AI Agent로 확장할수록
원천 데이터
공식 계산식
업무규칙
Evidence
권한
Human Approval
을 더 명확히 설계해야 합니다.
Agent에게 실행 권한을 주기 전에 Agent가 사용하는 숫자의 생성 구조부터 검증해야 합니다.
기업 AI 숫자 설계 전 체크리스트
AI가 답해야 할 주요 KPI가 정의되어 있는가?
각 KPI의 업무적 의미가 명확한가?
공식 계산식이 존재하는가?
같은 KPI를 부서마다 다르게 계산하고 있지는 않은가?
계산에 사용할 원천 데이터가 명확한가?
데이터가 어느 시스템에 존재하는지 알고 있는가?
포함·제외 조건이 정의되어 있는가?
기준시점을 명확하게 표시할 수 있는가?
중요한 계산을 검증된 로직으로 처리할 수 있는가?
AI 답변에 Source를 연결할 수 있는가?
사실·계산·AI 추론을 구분할 수 있는가?
사용자별 데이터 권한을 확인할 수 있는가?
현업 담당자가 계산결과를 검증할 수 있는가?
AI Agent 실행 전에 Human Approval이 필요한 영역이 정의되어 있는가?
여러 항목이 정리되어 있지 않다면 LLM을 바꾸기보다 먼저 KPI와 데이터 기준을 정리하는 것이 필요할 수 있습니다.
기업 AI PoC에서는 숫자를 어떻게 검증해야 할까?
AI PoC에서도 답변이 자연스러운지만 평가해서는 부족합니다.
KPI 질문을 선정했다면 최소한 다음 항목을 비교해야 합니다.
Source 검증
AI가 사용한 데이터가 실제 ERP·CRM 등의 Source와 일치하는가?
계산 검증
기존 공식 보고서와 동일한 계산식이 적용되는가?
기준시점 검증
같은 시점의 데이터를 비교하고 있는가?
Rule 검증
회사에서 사용하는 포함·제외 기준이 적용되는가?
현업 검증
실제 경영관리, 영업, PMO, HR 담당자가 결과를 인정할 수 있는가?
AI가 계산을 “해냈다”는 사실보다 회사에서 공식적으로 사용할 수 있는 결과인가가 중요합니다.
그렇다면 AI에게 숫자를 전혀 계산시키면 안 되는가?
핵심은 모든 숫자 계산을 일률적으로 금지하는 것이 아닙니다.
기업의 중요한 금액·비율·KPI처럼 의사결정에 영향을 주는 계산은 검증 가능한 구조에서 처리해야 한다는 것입니다.
특히 다음 질문을 해볼 필요가 있습니다.
이 숫자가 틀리면 실제 업무나 의사결정에 영향을 주는가?
그렇다면 가능한 범위에서
Source → 공식 계산식 → 검증 → Evidence
구조를 적용하는 것이 중요합니다. 반대로 임시 분석이나 참고용 설명 등은 업무 영향도와 사용 목적에 따라 다른 수준의 통제를 적용할 수 있습니다.
중요한 것은 숫자의 위험도에 따라 계산 책임을 설계하는 것입니다.
기업 AI에서 중요한 것은 ‘숫자를 말하는 AI’가 아니라 ‘숫자를 설명할 수 있는 AI’입니다
기업에는 이미 많은 숫자가 있습니다.
ERP에는 실적이 있고, CRM에는 파이프라인이 있으며, HR에는 인력 데이터가 있고, PMS에는 프로젝트 정보가 있습니다. 기업 AI의 가치가 단순히 이 숫자를 다시 보여주는 데만 있는 것은 아닙니다.
더 중요한 질문은 다음입니다.
왜 목표와 차이가 발생했는가?
어떤 고객과 프로젝트가 영향을 주고 있는가?
어떤 변화가 위험신호인가?
어디를 먼저 점검해야 하는가?
이 질문에는 LLM의 분석과 설명 능력이 도움이 될 수 있습니다.
하지만 그 출발점은 신뢰할 수 있는 숫자여야 합니다.
GS비즈플의 U.STRA Enterprise Ontology AI는 이를
RDB / Source First→ LLM Non-Calculation→ Evidence First
원칙으로 접근합니다.
확정된 숫자는 원천시스템에서 가져오고,
중요한 KPI는 검증된 방식으로 계산하며,
AI는 그 결과를 기업의 업무규칙과 지식구조를 기준으로 해석합니다.
그리고 사용자는 어떤 데이터와 계산기준으로 답했는지 확인할 수 있어야 합니다.
자주 묻는 질문
생성형 AI가 숫자 계산을 하면 안 되나요?
모든 계산을 금지한다는 의미는 아닙니다. 다만 기업의 매출, 원가, 손익, KPI처럼 중요한 의사결정에 사용되는 숫자는 가능한 범위에서 원천 데이터와 검증된 계산 로직을 이용하는 구조가 필요합니다. LLM은 결과의 분석과 설명 역할로 분리할 수 있습니다.
AI가 ERP 데이터를 직접 읽어 계산하면 되지 않나요?
데이터 조회 외에도 공식 계산식, 포함·제외 조건, 기준시점과 권한을 확인해야 합니다. 단순히 데이터를 읽는 것만으로 회사의 공식 KPI가 만들어지는 것은 아닐 수 있습니다.
RAG로 KPI를 계산할 수 있나요?
RAG는 KPI 정의와 업무규정을 찾는 데 활용할 수 있습니다. 하지만 현재 기업 데이터에 기반한 확정된 KPI가 필요하다면 ERP·CRM 등 원천 데이터와 검증된 계산 로직을 함께 연결하는 방식을 검토하는 것이 좋습니다.
AI 경영분석에서 가장 중요한 숫자 원칙은 무엇인가요?
확정된 숫자의 Source를 명확히 하고, 공식 계산식과 기준시점을 관리하며, AI가 어떤 근거로 분석했는지 확인할 수 있도록 하는 것이 중요합니다.
KPI 계산식도 온톨로지에 포함할 수 있나요?
U.STRA Enterprise Ontology AI에서는 KPI·계산식·Rule·Evidence를 기업 지식구조의 중요한 요소로 다룹니다. 구체적인 구현방식은 고객의 시스템과 적용범위에 따라 달라질 수 있습니다.
부서마다 KPI 계산방식이 다르면 어떻게 하나요?
AI 구축 전에 각 KPI의 정의, Source, 공식 계산식, 포함·제외 조건과 책임 주체를 확인하는 것이 좋습니다. PoC 과정에서 이런 차이를 발견하는 것 자체도 중요한 결과가 될 수 있습니다.
AI Agent에서도 같은 원칙이 필요한가요?
더 중요해질 수 있습니다. Agent가 계산결과를 기준으로 실제 Task를 생성하거나 업무를 실행한다면 Source, Rule, 계산식과 Human Approval 구조를 충분히 검증해야 합니다.
AI가 계산한 숫자의 근거를 어떻게 보여줄 수 있나요?
적용 가능한 구조에서는 데이터 Source, 기준시점, 계산식, 적용한 Rule과 주요 입력값을 답변 또는 별도의 Evidence 정보로 연결하는 방식을 검토할 수 있습니다.
AI에게 KPI를 계산시키기 전에 우리 회사의 ‘공식 숫자’부터 정의해 보십시오 GS비즈플과 함께 경영진과 현업이 반복해서 사용하는 핵심 KPI와 경영 질문부터 정리하고, Source·계산식·업무규칙·Evidence 구조를 진단해 보십시오. AI가 숫자를 만드는 구조가 아니라 신뢰할 수 있는 숫자를 이해하고 설명하는 기업 AI 구조부터 설계하는 것이 중요합니다. |
---------------------------------------------------------------------------------------------------------------------------------
[함께 읽으면 좋은 글]
댓글