AI 답변이 매번 달라진다면? RAG 다음에 기업 온톨로지가 필요한 순간
개인이 쓰면 똑똑한 AI, 왜 회사의 공식 분석에는 조금 불안할까?
생성형 AI를 개인 업무에 사용해 보면 놀랄 만큼 유용합니다.
보고서를 요약하고, 아이디어를 정리하고, 메일 초안을 만들고, 긴 문서를 분석하고, 여러 대안을 비교하는 데 매우 뛰어납니다. 한 명의 구성원이 자신의 업무를 보조하는 도구로 사용할 때는 이미 충분한 생산성 향상을 경험할 수 있습니다. 그런데 AI를 회사 차원의 업무로 확대하려고 하면 이야기가 달라집니다.
예를 들어 경영회의에서 사용할 분석,
영업 파이프라인 판단,
프로젝트 위험 분석,
인력 수요 예측,
경영지표 해석과 같은 영역입니다.
이때 담당자들은 비슷한 불편을 느끼기 시작합니다.
“분명 AI가 똑똑하기는 한데 질문을 조금 바꾸면 답이 달라진다.”
“지난번에는 A라고 분석했는데 오늘은 B라고 한다.”
“사람이 쓰기에는 괜찮은데 회사의 공식 숫자나 판단으로 쓰기에는 조금 불안하다.”
“우리 회사에서는 이 용어를 그렇게 쓰지 않는데 AI가 일반적인 의미로 해석한다.”
이 문제를 단순히 AI 모델의 성능 부족으로만 볼 필요는 없습니다. 오히려 다음 질문을 해볼 필요가 있습니다.
AI가 우리 회사의 업무와 판단방식을 충분히 알고 있는가?
GS비즈플이 Enterprise AI에서 주목하는 지점도 바로 이것입니다.
AI가 일반적인 지식은 많이 알고 있어도, 우리 회사가 어떤 데이터를 믿고 어떤 규칙으로 계산하며 어떤 기준으로 판단하는지는 스스로 알 수 없습니다.
RAG와 시스템 프롬프트까지 했는데 왜 약간 아쉬울까?
기업에서 생성형 AI를 도입할 때 보통 두 가지 방법을 먼저 사용합니다.
RAG입니다.
사내 규정, 업무 매뉴얼, 보고서, 프로젝트 자료와 같은 문서를 검색해 AI에게 제공하면 회사 정보를 기반으로 답하도록 만들 수 있습니다.
시스템 프롬프트 또는 업무 지침입니다.
예를 들어 AI에게 다음과 같은 지침을 줍니다.
우리 회사의 용어를 사용하라.
답변은 특정 형식으로 작성하라.
추정하지 말고 근거를 제시하라.
특정 기준에 따라 분석하라.
답변에서 주의사항을 포함하라.
이 두 가지를 잘 구성하면 상당히 좋은 AI Assistant를 만들 수 있습니다. 실제로 사내 문서검색, 규정 질의응답, 보고서 작성지원, 제안서 작성, 업무 지식 검색과 같은 영역에서는 높은 활용가치를 얻을 수 있습니다.
그런데 어느 순간부터 이런 느낌이 들 수 있습니다.
“80점 정도까지는 왔는데 나머지 20점이 잘 안 채워진다.”
바로 이 단계에서 기업 지식구조를 다시 살펴볼 필요가 있습니다.
RAG는 ‘관련 정보를 찾는 것’에는 강하지만 ‘회사 기준으로 판단하는 것’은 다른 문제입니다
RAG의 기본적인 역할은 사용자의 질문과 관련된 정보를 찾아 LLM에게 제공하는 것입니다.
간단히 표현하면 다음과 같습니다.
질문→ 관련 문서 검색→ LLM→ 답변
예를 들어,
“우리 회사의 출장비 규정은?”, “계약변경 절차를 알려줘.”, “프로젝트 종료 프로세스는?”
같은 질문에는 RAG가 매우 유용할 수 있습니다. 하지만 질문이 다음처럼 바뀌면 조금 복잡해집니다.
“현재 손실 위험이 높은 프로젝트는 어디인가?”
이 질문의 정답이 하나의 문서 안에 그대로 존재하지 않을 가능성이 높습니다.
AI는 다음을 함께 알아야 할 수 있습니다.
어떤 프로젝트가 존재하는가?
프로젝트별 현재 매출과 원가는 얼마인가?
일정은 정상인가?
추가 인력이 투입되었는가?
계약 변경이 발생했는가?
회사는 어떤 조건을 손실위험이라고 정의하는가?
어느 정도의 위험부터 보고대상으로 보는가?
어떤 데이터를 공식 Source로 사용하는가?
이제 문제는 정보 검색을 넘어 업무 해석과 판단의 문제로 바뀝니다.
시스템 프롬프트도 모든 회사 지식을 담을 수는 없습니다
그렇다면 시스템 프롬프트를 더 정교하게 만들면 되지 않을까요?
일정 범위에서는 도움이 됩니다. 예를 들어 다음과 같이 지시할 수 있습니다.
“우리 회사에서 위험 프로젝트는 일정지연, 원가증가, 추가투입 여부를 종합적으로 판단한다.”
하지만 업무가 복잡해질수록 하나의 지침 안에 모든 지식을 넣기는 어려워집니다. 회사의 실제 업무에는 수많은 요소가 서로 연결되어 있기 때문입니다. 예를 들어 ‘프로젝트 위험’만 해도 다음이 연결될 수 있습니다.
Project→ Customer와 연결
Project→ Contract와 연결
Project→ Employee가 투입
Project→ Revenue와 Cost 발생
Project→ 일정 상태 변화
Project→ Change Request 발생
Project→ 특정 Rule에 따라 Risk 상태 판단
여기에 다시 다음 질문들이 붙습니다.
어떤 데이터가 ERP에 있는가?
어떤 데이터가 PMS에 있는가?
어떤 숫자를 공식값으로 볼 것인가?
누가 이 데이터를 볼 수 있는가?
어떤 예외조건이 존재하는가?
판단의 근거는 무엇인가?
이 구조 전체를 긴 프롬프트 안에 자연어 문장으로 계속 추가하는 방식은 어느 순간 관리하기 어려워질 수 있습니다.
문제는 AI가 덜 똑똑해서가 아니라 ‘회사의 지식구조’를 충분히 모르기 때문입니다
여기서 중요한 관점 전환이 필요합니다.
AI는 이미 일반적인 언어와 업무 개념을 상당히 잘 이해합니다.
하지만 회사마다 다른 것은 AI가 스스로 알 수 없습니다.
예를 들어 회사마다 다음 기준은 다를 수 있습니다.
매출을 어떤 기준으로 집계하는가?
어떤 영업기회를 유효 파이프라인으로 보는가?
어떤 프로젝트를 위험 프로젝트로 분류하는가?
가동률을 어떻게 계산하는가?
어떤 인력을 가용인력으로 보는가?
어떤 데이터가 공식 Source인가?
어떤 정보까지 부서장이 볼 수 있는가?
어느 수준에서 AI가 추천하고 사람이 판단해야 하는가?
이 정보들은 일반적인 LLM 지식이 아닙니다.
기업이 직접 가지고 있는 지식입니다.
따라서 AI를 회사의 분석과 의사결정에 활용하려면,
AI에게 더 많은 일반 지식을 주는 것보다
우리 회사가 어떻게 일하고 어떻게 판단하는지를 구조적으로 알려주는 것
이 중요해집니다.
이때 기업 온톨로지가 필요해집니다
기업 온톨로지는 단순한 용어사전이 아닙니다.
기업의 업무 현실을 AI와 시스템이 이해할 수 있도록 다음 요소를 구조화하는 지식체계입니다.
Entity무엇이 존재하는가?
Relation무엇과 무엇이 연결되는가?
Event어떤 일이 발생했는가?
State현재 어떤 상태인가?
Rule어떤 기준으로 판단하는가?
KPI / Calculation어떤 방식으로 계산하는가?
Evidence어떤 근거로 판단하는가?
Decision그래서 무엇을 판단해야 하는가?
예를 들어 ‘영업기회’를 단순히 CRM 데이터의 한 행으로 보는 것이 아니라,
고객과 연결되고,
담당 영업사원과 연결되고,
영업 Stage가 변화하고,
활동 Event가 발생하고,
회사가 정한 Rule에 따라 유효 파이프라인 여부가 결정되는
업무개체로 이해하게 만드는 것입니다.
이것이 자연어 지침과 구조화된 기업 지식의 차이입니다.
RAG와 시스템 프롬프트 다음에 온톨로지가 필요한 이유
RAG, 시스템 프롬프트, 온톨로지는 서로 대체하는 개념으로 볼 필요가 없습니다.
오히려 역할이 다릅니다.
구분 | 주요 역할 |
LLM | 질문 이해, 생성, 분석, 설명 |
시스템 프롬프트 | AI의 행동방식과 답변 원칙 설정 |
RAG | 관련 문서와 지식 검색 |
Enterprise Ontology | 업무 개념·관계·상태·규칙·판단기준 구조화 |
RDB / API | 실제 기업 데이터와 확정값 제공 |
계산 로직 | KPI·금액·비율의 결정적 계산 |
Evidence | 판단의 데이터·Source·기준 연결 |
따라서 기존에 RAG와 시스템 프롬프트를 잘 구축했다면 그것을 버리는 것이 아닙니다.
그 위에 기업의 의미와 판단구조를 추가하는 것입니다.
예를 들어 RAG만 있는 AI에게 영업 질문을 해보면
사용자가 질문합니다.
“이번 분기 영업 파이프라인 상황을 분석해 줘.”
RAG는 관련된 영업보고서와 업무규정을 찾아줄 수 있습니다.
시스템 프롬프트에는 다음과 같은 내용이 들어 있을 수도 있습니다.
“영업 파이프라인을 보수적으로 분석하고 위험요인을 함께 제시하라.”
여기까지도 꽤 좋은 분석이 나올 수 있습니다.
하지만 회사 차원의 공식 분석으로 사용하려면 더 많은 정보가 필요합니다.
어떤 영업기회가 존재하는가?
현재 CRM 데이터를 봐야 합니다.
어느 Stage부터 파이프라인으로 인정하는가?
회사의 영업 Rule이 필요합니다.
장기 미활동 기회는 어떻게 처리하는가?
예외규칙이 필요합니다.
파이프라인 금액은 어떻게 계산하는가?
공식 계산식이 필요합니다.
어떤 조직까지 사용자가 볼 수 있는가?
권한정보가 필요합니다.
AI가 왜 이 기회를 위험하다고 판단했는가?
Evidence가 필요합니다.
이 구조를 알게 되면 AI의 답변은 단순한 문서 해석을 넘어 회사의 업무기준에 따른 분석에 가까워질 수 있습니다.
AI 답변이 달라지는 것과 AI 판단기준이 달라지는 것은 구분해야 합니다
생성형 AI는 본질적으로 확률적인 특성을 가지고 있기 때문에 같은 질문에도 표현이나 분석 방식이 완전히 동일하지 않을 수 있습니다. 따라서 온톨로지를 적용한다고 모든 문장이 매번 똑같아지는 것은 아닙니다.
기업에서 더 중요한 것은 다른 문제입니다.
표현이 조금 달라져도 같은 회사 기준으로 판단하는가?
예를 들어 AI가 다음 두 답변을 했다고 생각해 보겠습니다.
첫 번째 답변:
“A 프로젝트는 우선 점검이 필요합니다.”
두 번째 답변:
“A 프로젝트는 손실위험 관리대상으로 검토할 필요가 있습니다.”
표현은 다릅니다.
하지만 두 답변 모두
동일한 ERP 데이터,
동일한 프로젝트 상태,
동일한 KPI 계산,
동일한 위험 Rule,
동일한 기준시점
을 바탕으로 했다면 판단의 일관성은 유지되고 있다고 볼 수 있습니다.
기업 AI에서 필요한 것은 모든 문장을 똑같이 만드는 것이 아니라,
AI가 사용하는 사실·계산·규칙·판단기준을 일관되게 만드는 것입니다.
회사의 공식 분석에 사용하려면 ‘사실·계산·추론’을 구분해야 합니다
기업 AI의 답변을 신뢰하려면 무엇이 무엇인지 구분할 필요가 있습니다.
사실
원천시스템에서 조회한 데이터입니다.
예:
현재 매출 72억 원
진행 중 프로젝트 15개
CRM 영업기회 23건
계산
회사에서 정의한 공식 로직으로 산출한 결과입니다.
예:
목표 달성률 72%
유효 파이프라인 18억 원
프로젝트 예상손익
AI 추론
사실과 계산, 업무규칙을 바탕으로 AI가 분석한 결과입니다.
예:
목표달성 위험이 존재한다
특정 영업기회 점검이 필요하다
특정 프로젝트의 위험도가 증가하고 있다
이렇게 구분하면 사용자는
“이 숫자는 사실인가?”
“이 값은 어떤 계산 결과인가?”
“이 부분은 AI의 해석인가?”
를 구분해서 볼 수 있습니다.
RAG 고도화의 핵심은 문서를 더 넣는 것이 아닐 수 있습니다
RAG 품질이 조금 아쉽다고 느끼면 흔히 가장 먼저 하는 일이 있습니다.
문서를 더 넣는 것입니다.
Vector DB를 튜닝하고,
Chunk 크기를 조정하고,
검색 알고리즘을 바꾸고,
프롬프트를 더 길게 만듭니다.
물론 이런 개선도 필요할 수 있습니다.
하지만 현재 문제가 정말 검색 품질인지 먼저 구분해야 합니다.
예를 들어 AI가
“규정 문서를 못 찾는다.”
면 RAG 검색 품질 문제일 가능성이 있습니다.
하지만 AI가
“규정은 찾았는데 현재 상황에서 어떤 기준을 적용해야 하는지 모른다.”
면 문제의 성격이 달라집니다.
또
“업무규칙은 알지만 현재 ERP 값이 없다.”
면 데이터 연결 문제입니다.
“데이터는 있지만 어느 계산식을 사용해야 하는지 모른다.”
면 KPI 정의 문제입니다.
즉 RAG 다음 단계는 RAG를 계속 확장하는 것이 아니라, 현재 부족한 것이 검색인지·데이터인지·업무규칙인지·지식구조인지 구분하는 것에서 시작해야 합니다.
이런 증상이 있다면 온톨로지 적용을 검토할 시점입니다
다음과 같은 상황이 반복된다면 기업 지식구조를 점검해 볼 필요가 있습니다.
RAG 검색 자체는 잘 되는데 최종 판단이 매번 조금씩 달라진다.
시스템 프롬프트가 점점 길어지고 복잡해지고 있다.
같은 업무용어를 부서마다 다르게 사용한다.
문서에 답이 있지만 실제 현재 데이터까지 함께 봐야 한다.
여러 시스템을 연결해야 질문에 답할 수 있다.
같은 KPI를 조직마다 다르게 계산한다.
AI가 어떤 기준으로 결론을 냈는지 설명하기 어렵다.
공식 분석과 AI의 분석 결과를 어떻게 연결할지 고민하고 있다.
RAG는 잘 쓰지만 AI Agent로 확장하기에는 불안하다.
특정 담당자의 경험과 판단기준이 여전히 사람 머릿속에 남아 있다.
이런 문제가 있다면 LLM을 한 단계 더 좋은 모델로 바꾸는 것만으로는 충분하지 않을 수 있습니다.
기업 온톨로지는 모든 지식을 처음부터 정리하는 프로젝트가 아닙니다
온톨로지라는 단어를 들으면
“회사의 모든 지식을 다 정리해야 하나?”
라는 부담을 느낄 수 있습니다.
그럴 필요는 없습니다.
GS비즈플의 U.STRA Enterprise Ontology AI는 Problem-First, Ontology-for-Decision 관점에서 접근합니다.
먼저 AI가 답해야 하는 중요한 질문을 선정합니다.
예를 들어 다음과 같습니다.
목표 달성이 어려운 조직은?
실제 영업 파이프라인은?
손실위험 프로젝트는?
다음 달 가용 가능인력은?
경영보고 숫자가 달라진 이유는?
그다음 질문에 필요한 지식을 역으로 구조화합니다.
Question→ Entity→ Relation→ Event / State→ Rule→ KPI→ Data→ Evidence→ Decision
즉 기업 전체를 모델링하는 것이 아니라 실제 업무 질문을 해결하는 데 필요한 지식부터 구조화하는 방식입니다.
RAG에서 Ontology AI로 확장하면 무엇이 달라질까?
예를 들어 기존 RAG AI가 다음과 같이 동작했다고 가정해 보겠습니다.
질문→ 관련 문서 검색→ 시스템 프롬프트 적용→ LLM 답변
이를 기업의 분석·판단 업무까지 확장하면 다음 구조를 검토할 수 있습니다.
질문→ Ontology→ 업무개체 확인→ Rule→ Permission→ RDB / API 데이터→ RAG 문서→ Deterministic Calculation→ Evidence→ AI Reasoning→ 답변 / Decision Support
여기서 중요한 것은 RAG가 사라지지 않았다는 점입니다.
RAG는 여전히 중요한 역할을 합니다.
다만 기업의 실제 데이터와 업무규칙, 계산식과 판단근거가 추가됩니다.
RAG를 버리는 것이 아니라 RAG가 기업의 판단구조 안에서 역할을 갖게 만드는 것입니다.
기업 AI의 다음 단계는 ‘더 똑똑한 AI’보다 ‘우리 회사를 더 잘 아는 AI’입니다
기업이 생성형 AI를 도입하는 초기에는 모델 성능 차이가 매우 크게 느껴질 수 있습니다.
하지만 일정 수준 이상의 AI와 RAG를 사용하기 시작하면 다른 문제가 보이기 시작합니다.
AI가 우리 회사의 용어를 충분히 아는가?
우리 회사의 데이터를 어디에서 가져와야 하는지 아는가?
우리 회사의 KPI를 같은 방식으로 계산하는가?
우리 회사의 업무규칙과 예외를 아는가?
우리 회사에서 누가 무엇을 볼 수 있는지 아는가?
왜 그런 판단을 했는지 근거를 제시할 수 있는가?
이 질문들은 LLM 자체의 일반지능 문제가 아닙니다.
기업이 자신의 지식을 얼마나 명확하게 구조화했는가의 문제에 가깝습니다.
자주 묻는 질문
RAG와 시스템 프롬프트를 잘 만들었는데도 온톨로지가 필요한가요?
반드시 필요한 것은 아닙니다. 문서검색과 질의응답이 주요 목적이라면 RAG와 지침만으로 충분한 경우도 있습니다. 다만 여러 시스템의 데이터, KPI 계산, 업무규칙, 상태 변화와 판단기준을 함께 반영해야 한다면 추가적인 기업 지식구조를 검토할 가치가 있습니다.
온톨로지를 적용하면 AI 답변이 항상 똑같아지나요?
그렇지는 않습니다. 생성형 AI는 확률적인 특성이 있기 때문에 표현이 달라질 수 있습니다. 온톨로지의 목적은 모든 문장을 동일하게 만드는 것이 아니라 AI가 같은 업무 정의, 데이터, 규칙과 판단기준을 사용하도록 기반을 만드는 데 있습니다.
시스템 프롬프트를 더 길게 만들면 되지 않나요?
일정 범위까지는 가능합니다. 하지만 업무개체, 관계, 상태, KPI, 규칙, 권한과 여러 데이터소스가 복잡하게 연결되기 시작하면 모든 지식을 긴 자연어 지침만으로 관리하기 어려울 수 있습니다. 이 경우 구조화된 기업 지식체계를 검토할 수 있습니다.
기존 RAG를 다시 구축해야 하나요?
반드시 그렇지는 않습니다. 기존 RAG를 유지하면서 업무규칙, Ontology, 기업 데이터 API, 계산 로직과 Evidence 등을 추가하는 방식으로 확장할 수 있습니다. 실제 범위는 현재 RAG와 시스템 환경을 확인해야 합니다.
온톨로지를 구축하면 Knowledge Graph도 반드시 필요한가요?
그렇지 않습니다. 고객 상황에 따라 기존 RDB, API, RAG와 AI 지침을 활용해 시작할 수 있고, 관계 탐색의 필요성이 커질 때 Knowledge Graph나 GraphRAG를 검토할 수 있습니다.
어떤 시점에 온톨로지를 검토하는 것이 좋나요?
RAG 검색 품질은 어느 정도 확보되었는데 실제 업무 판단의 일관성이 부족하거나, 여러 시스템 데이터와 업무규칙을 함께 해석해야 하거나, AI Agent로 확장하려는 시점이라면 기업 지식구조를 점검해 볼 가치가 있습니다.
RAG가 80점까지 왔다면, 나머지 20점은 회사의 지식구조에서 찾아보십시오 무엇이 무엇과 연결되고,어떤 Event가 발생하고,현재 어떤 State이며,어떤 데이터를 Source로 믿고,어떤 KPI를 어떻게 계산하며,어떤 Rule로 판단하고,어떤 Evidence를 제시해야 하는지 구조화할 수 있어야 합니다. GS비즈플의 U.STRA Enterprise Ontology AI는 RAG를 대체하는 것이 아니라, RAG와 기업 데이터 위에 회사의 업무 의미와 판단기준을 연결하는 Enterprise Knowledge Architecture를 지향합니다. 이미 RAG를 구축했지만 활용 수준이 조금 아쉽다면, 새로운 AI 모델을 검토하기 전에 현재 AI가 우리 회사의 어떤 지식과 판단기준을 모르고 있는지부터 진단해 보십시오 |
[함께 읽으면 좋은 글]
댓글