top of page

ERP·CRM·HR 데이터를 생성형 AI와 연결하는 방법

5일 전
11분 분량
기업 데이터와 AI 연계를 설명하는 파란색 인포그래픽, ERP·CRM·HR·Excel 아이콘과 질문/답변 흐름, U.STRA Enterprise Ontology AI 문구 포함
기업에는 데이터가 많은데 왜 AI는 회사 상황을 제대로 답하지 못할까? 

기업에는 이미 많은 데이터가 있습니다. ERP에는 매출, 원가, 회계 데이터가 있고 CRM에는 고객과 영업기회가 있습니다. HR 시스템에는 조직과 인력 정보가 있고 PMS에는 프로젝트 일정과 진행상태가 있습니다. 문서시스템과 그룹웨어에는 보고서, 승인문서, 회의자료와 업무기록도 쌓여 있습니다. 그런데 생성형 AI에게 다음과 같이 물어보면 상황은 달라집니다.

“이번 분기 목표 달성이 어려운 조직은 어디인가?”

“실제로 믿을 수 있는 영업 파이프라인은 얼마인가?”

“손실 위험이 높은 프로젝트는 무엇인가?”

“프로젝트 종료 후 가용 가능성이 높은 인력은 누구인가?”

이 질문들은 한 시스템의 데이터를 검색하는 것만으로 답하기 어렵습니다.

ERP의 숫자와 CRM의 영업상태를 연결해야 할 수도 있고, PMS의 프로젝트 일정과 HR의 투입인력을 함께 봐야 할 수도 있습니다. 여기에 회사가 사용하는 KPI 계산식, 업무규칙, 조직별 권한과 판단기준까지 적용해야 합니다. 그래서 기업 데이터와 AI를 연결하는 문제는 단순히 “LLM에 API를 붙이는 문제”가 아닙니다.


GS비즈플이 주목하는 지점은 다음입니다.

AI가 어떤 질문에 답해야 하는지 먼저 정의하고, 그 질문을 실제 데이터·업무규칙·계산식·권한·근거와 연결해야 합니다.


기업 데이터 AI 연계란 무엇인가? 

기업 데이터 AI 연계란 ERP·CRM·HR·PMS·SCM 등 업무시스템의 데이터를 생성형 AI가 필요한 시점에 조회하고, 회사의 업무 의미와 판단기준에 따라 분석할 수 있도록 연결하는 구조를 의미합니다. 단순화하면 다음과 같습니다.


사용자 질문 → 업무 의미 해석 → 필요한 데이터 판단 → 기업 시스템 조회 

검증된 계산 → 업무규칙 적용 → 근거 확인 → AI 분석과 설명 → 답변

예를 들어 사용자가 “현재 손실 가능성이 높은 프로젝트를 알려줘.” 라고 질문한다고 가정해 보겠습니다.


AI가 제대로 답하려면 먼저 다음을 알아야 합니다.

  • ‘프로젝트’가 회사에서 어떤 업무개체인지

  • 손실위험을 어떤 기준으로 판단하는지

  • 프로젝트 매출과 원가는 어느 시스템에 있는지

  • 투입인력은 어디서 조회하는지

  • 현재 일정과 진행률은 어디에서 확인하는지

  • 어떤 계산식을 적용하는지

  • 사용자가 어느 프로젝트까지 볼 수 있는지

  • 어느 시점의 데이터를 사용했는지

데이터 연결과 업무지식 연결이 동시에 필요합니다.


ERP·CRM·HR을 AI와 연결한다고 해서 기존 시스템을 교체할 필요는 없습니다 

기업 AI 도입을 검토할 때 자주 생기는 오해가 있습니다. “AI를 제대로 쓰려면 ERP나 CRM부터 새로 구축해야 하는 것 아닌가?” 반드시 그렇지는 않습니다.


이미 안정적으로 운영되고 있는 업무시스템이 있다면 기존 시스템을 데이터의 원천으로 유지하고, AI가 필요한 정보를 조회할 수 있는 연결구조를 추가하는 방식을 검토할 수 있습니다.


예를 들면 다음과 같습니다.

ERP CRM HR PMS 레거시 시스템

조회용 API / 데이터 접근 계층

Ontology · 업무규칙 · 계산식 · 권한

LLM / AI Assistant


이 방식의 핵심은 기존 업무시스템의 역할을 없애는 것이 아닙니다. ERP는 여전히 ERP의 역할을 하고, CRM은 CRM의 역할을 합니다. AI는 여러 시스템에 흩어진 데이터를 사용자의 질문에 맞춰 연결하고 해석하는 새로운 인터페이스 역할을 담당합니다.


왜 처음에는 Read-only API부터 검토하는가?

기업 데이터와 생성형 AI를 연결할 때는 AI가 모든 시스템 데이터를 자유롭게 변경하도록 만드는 것보다 조회 중심으로 시작하는 방식을 우선 검토할 수 있습니다. 예를 들어 AI가 다음 질문에 답한다고 생각해 보겠습니다.

“이번 달 목표 대비 매출 실적을 알려줘.”

AI에게 필요한 것은 우선 ERP에서 현재 실적을 조회하는 기능입니다. 매출 데이터를 수정할 권한까지 필요한 것은 아닙니다. 따라서 초기 데이터 연결 단계에서는 필요한 업무 질문을 기준으로 조회 범위를 제한하고, Read-only API 형태로 데이터를 제공하는 방식을 고려할 수 있습니다.


흐름은 다음처럼 설계할 수 있습니다.

AI 질문 → 업무개체 확인 → 필요한 데이터 판단 → Read-only API → 원천 시스템 조회 → 계산 → 분석 → Source → 답변


이 구조는 이후 AI의 데이터 조회와 판단 품질을 충분히 검증한 뒤 AI Agent의 업무 실행 기능으로 단계적으로 확장하는 데에도 도움이 됩니다.


단순 API 연결만으로는 부족한 이유

ERP API와 CRM API를 LLM에 연결하면 AI가 바로 업무를 이해할 것처럼 보일 수 있습니다.

하지만 API는 데이터를 가져오는 통로일 뿐입니다. AI가 데이터를 제대로 해석하려면 추가적인 의미가 필요합니다.


예를 들어 CRM에 다음과 같은 값이 있다고 가정하겠습니다.

  • Opportunity Amount: 5억 원

  • Stage: Proposal

  • Expected Close Date: 9월

  • Last Activity: 45일 전

이 데이터만 보고 “이번 분기 신뢰할 수 있는 영업 파이프라인은 얼마인가?” 를 판단할 수 있을까요?


  • 회사가 어떤 Stage부터 파이프라인으로 인정하는지 알아야 합니다.

  • 45일 동안 활동이 없으면 제외하는지 확인해야 합니다.

  • 예상수주일이 현재 분기에 포함되는지도 판단해야 합니다.

  • 확률을 적용한다면 어떤 계산식을 사용하는지도 알아야 합니다.

  • 결국 기업 AI에는 다음 구조가 필요합니다.

데이터 + 의미 + 업무규칙 + 계산식 + 권한 + 근거 GS비즈플이 기업 온톨로지와 데이터 연결을 함께 보는 이유입니다.


ERP·CRM·HR은 각각 어떤 데이터를 AI에 제공할 수 있을까?

ERP는 ‘확정된 숫자’의 중요한 Source가 될 수 있습니다 ERP에는 기업의 중요한 재무·업무 데이터가 존재합니다.

예를 들면,

  • 매출

  • 원가

  • 매입

  • 비용

  • 청구

  • 수금

  • 재고

  • 주문

등입니다.

기업 AI가 경영 실적이나 프로젝트 손익 등을 분석하려면 확정된 숫자의 출처를 명확히 해야 합니다. 중요한 숫자는 LLM의 기억이나 과거 보고서보다 가능한 범위에서 원천시스템의 값을 기준으로 사용하는 구조를 검토하는 것이 좋습니다.


CRM은 고객과 영업기회의 현재 상태를 제공합니다 

CRM에는 다음과 같은 정보가 있을 수 있습니다.

  • 고객

  • 담당자

  • 영업기회

  • 예상금액

  • 영업단계

  • 예상수주일

  • 영업활동

  • 상담이력

이 데이터를 AI와 연결하면 단순한 고객검색을 넘어 다음과 같은 질문으로 확장할 수 있습니다.

“오랫동안 활동이 없는 영업기회는?”

“이번 분기에 수주 가능성이 높은 영업기회는?”

“우선 대응해야 할 고객은?”

다만 이런 질문은 CRM 데이터를 조회하는 것만으로 끝나지 않습니다.

회사에서 사용하는 영업규칙과 판단기준을 함께 적용해야 합니다.


HR은 사람·조직·역량을 이해하는 기반이 됩니다

HR 시스템에는 일반적으로 조직과 인력에 관한 정보가 존재합니다.

  • 직원

  • 조직

  • 직책

  • 직무

  • 소속

  • 재직상태

  • 역량

  • 근태

  • 평가

  • 프로젝트 투입정보

적용 범위는 실제 고객의 HR 시스템과 데이터 구조에 따라 달라질 수 있습니다.

이러한 데이터를 프로젝트 데이터와 연결하면 다음과 같은 질문을 검토할 수 있습니다.

“프로젝트 종료 후 가용 가능성이 있는 인력은?”

“다음 프로젝트에 필요한 역량을 가진 후보자는?”

“어느 조직에서 인력 부족 가능성이 높은가?”

이 역시 HR 데이터만 보는 문제가 아니라 프로젝트 일정, 요구역량, 조직 정책 등 다른 업무정보와의 연결이 필요할 수 있습니다.


기업 AI의 가치는 여러 시스템을 연결할 때 커질 수 있습니다 

하나의 시스템 안에서 답할 수 있는 질문은 기존 검색이나 BI만으로도 충분한 경우가 있습니다. 하지만 기업의 중요한 질문은 여러 시스템의 경계를 넘는 경우가 많습니다. 예를 들어 다음과 같습니다.

“이 프로젝트가 왜 손실 위험인가?”

필요할 수 있는 데이터:

ERP

  • 매출

  • 원가

  • 청구

PMS

  • 일정

  • 진척

  • 변경사항

HR

  • 투입인력

  • 인건비

  • 가용상태

CRM / 계약정보

  • 고객

  • 계약금액

  • 계약조건

문서 / RAG

  • PM 보고

  • 회의록

  • 변경요청 사유

AI가 이 데이터를 연결해 의미 있게 분석하려면 ‘프로젝트’를 중심으로 서로 다른 시스템의 정보가 어떤 관계를 갖는지 알아야 합니다. 그래서 데이터 통합보다 먼저 업무 의미의 통합이 필요할 수 있습니다.


기업 온톨로지는 서로 다른 시스템의 의미를 연결합니다

기업시스템에는 서로 다른 코드와 데이터 구조가 존재합니다. ERP의 고객코드와 CRM의 Account가 같은 고객을 의미할 수 있습니다. HR의 Employee와 PMS의 Resource가 같은 사람을 의미할 수도 있습니다. 시스템별 데이터 이름이 비슷해도 실제 의미가 다를 수 있습니다. 기업 온톨로지는 이런 정보를 회사의 업무 관점에서 연결합니다.

예를 들어,

  1. Customer → 영업기회를 가진다 → 계약을 가진다 → 프로젝트와 연결된다

  2. Project → Customer와 연결된다 → Contract를 가진다 → Employee가 투입된다 → Revenue와 Cost가 발생한다

  3. Employee → Organization에 소속된다 → Project에 투입된다 → Skill을 가진다

이렇게 하면 AI는 테이블이나 필드 이름 자체가 아니라 업무적으로 무엇이 무엇과 연결되어 있는지를 기준으로 데이터를 해석할 수 있습니다.


RAG와 기업 데이터 연결은 어떻게 다른가?

기업 AI를 구축하면서 RAG와 데이터 API를 혼동하는 경우가 있습니다.

두 방식은 서로 다른 문제를 해결합니다.

구분 

RAG 

기업 데이터 API 

주요 대상 

문서·보고서·규정 등 

ERP·CRM·HR 등 시스템 데이터 

강점 

관련 내용 검색 

현재 확정값 조회 

대표 질문 

“출장비 규정은?” 

“현재 미수금은?” 

데이터 형태 

주로 비정형 정보 

주로 구조화 데이터 

기준시점 

문서 작성시점에 영향 

원천시스템 현재값 기준 가능 

계산 

별도 로직 필요 

계산 로직과 연결 가능 

역할 

설명과 문맥 제공 

사실과 숫자 제공 

실제 기업 업무에서는 둘 중 하나만 선택할 필요가 없습니다.

예를 들어 프로젝트 위험을 분석할 때, ERP·PMS에서 현재 숫자를 가져오고, RAG를 이용해 PM 보고서와 변경요청 문서를 검색한 뒤, 업무규칙과 계산식을 적용해 AI가 종합적으로 설명하도록 구성할 수 있습니다.


AI에게 중요한 숫자를 직접 계산하게 해도 될까?

생성형 AI는 자연어 설명과 분석에는 강점이 있지만, 중요한 기업 KPI를 LLM이 임의로 계산하도록 설계하는 것은 별도의 검증이 필요합니다.

예를 들어,

  • 목표 달성률

  • 프로젝트 예상손익

  • 영업 파이프라인

  • 가동률

  • 원가율

과 같은 지표는 회사가 사용하는 공식 계산방식을 적용해야 합니다.

따라서 기업 AI에서는 다음과 같이 역할을 분리하는 접근이 유용합니다.

LLM

  • 질문 이해

  • 분석

  • 설명

  • 요약

  • 추천

검증된 로직

  • 금액 계산

  • 비율 계산

  • KPI 산출

  • 업무규칙 적용

즉 AI가 숫자를 ‘그럴듯하게 만들어내는 구조’가 아니라,

원천 데이터를 검증된 방식으로 계산하고 AI가 그 의미를 설명하는 구조가 중요합니다.


데이터 권한은 AI 연결 전에 반드시 확인해야 합니다

기업 데이터에는 사용자마다 접근 가능한 범위가 다릅니다.

HR 데이터는 대표적인 예입니다.


AI가 기술적으로 데이터를 조회할 수 있다고 해서 모든 사용자가 모든 인사정보를 볼 수 있어야 하는 것은 아닙니다.

ERP의 원가와 수익정보도 마찬가지입니다. 프로젝트 관리자, 부서장, 경영진의 조회범위가 다를 수 있습니다.

따라서 기업 AI에서는 다음 질문이 필요합니다.

  • 사용자가 어떤 조직에 속해 있는가?

  • 어떤 역할을 가지고 있는가?

  • 어떤 데이터까지 볼 수 있는가?

  • 어떤 필드를 제한해야 하는가?

  • AI에게 전달하기 전 권한을 어디에서 확인할 것인가?


GS비즈플은 이를 Permission First 관점에서 봅니다.

AI가 어떤 데이터를 찾을 수 있는지보다 먼저, 이 사용자가 그 데이터를 볼 수 있는지 확인하는 구조가 필요합니다.

실제 권한정책과 적용 범위는 고객의 시스템 및 보안정책에 따라 설계해야 합니다.


AI 답변에는 Source와 기준시점이 필요합니다

기업 업무에서 AI가 “이번 분기 매출은 30억 원입니다.” 라고 답했다면 사용자는 다음을 확인할 수 있어야 합니다.

  • 어느 시스템의 데이터인가?

  • 언제 기준인가?

  • 어떤 조건으로 조회했는가?

  • 어떤 계산식을 적용했는가?

또,

“이 프로젝트는 위험도가 높습니다.” 라고 판단했다면,

  • 어떤 데이터가 위험 신호였는가?

  • 어떤 Rule이 적용되었는가?

  • 어떤 계산결과가 나왔는가?

  • 참고한 문서는 무엇인가?

를 검토할 수 있어야 합니다.

이를 Evidence First 관점으로 볼 수 있습니다. 기업 AI의 신뢰성은 좋은 문장을 생성하는 것만으로 만들어지지 않습니다. 답변과 Source·계산·업무기준을 연결할 수 있어야 합니다.


ERP·CRM·HR 데이터를 AI에 연결하는 7단계 

기업 데이터 AI 연계를 실제로 추진한다면 기술부터 선택하기보다 다음 순서로 접근하는 것이 좋습니다.

  1. AI가 답해야 할 대표 질문을 정합니다

    예를 들면,

    목표 달성이 어려운 조직은?

    실질 영업 파이프라인은?

    위험 프로젝트는?

    가용 예상인력은?

    처럼 실제 경영진과 현업이 반복하는 질문을 선정합니다.

  2. 질문에 필요한 업무개체를 정의합니다 

    예를 들어 ‘위험 프로젝트’를 분석한다면 다음 Entity가 필요할 수 있습니다.

    Project, Customer, Contract, Employee, Revenue, Cost

    모든 기업지식을 먼저 만들기보다 질문에 필요한 범위부터 정의합니다.

  3. 데이터가 어느 시스템에 있는지 찾습니다

    각 질문에 필요한 정보를 실제 시스템과 연결합니다. 예를 들면,

    ERP 매출·원가

    CRM 고객·영업기회

    HR 조직·인력

    PMS 프로젝트·일정

    이 단계에서 동일한 업무개체가 여러 시스템에 존재하는지도 확인해야 합니다.

  4. 데이터 조회방법을 설계합니다 

    기존 API가 있다면 활용 가능성을 검토합니다. 필요한 조회 API가 없다면 기존 시스템의 테이블, ERD, 화면, SQL 등의 구조를 분석해 AI가 필요한 데이터를 조회하는 API 설계를 검토할 수 있습니다. 초기 단계에서는 필요한 질문에 한정해 Read-only 방식으로 접근하는 것이 현실적인 출발점이 될 수 있습니다.

  5. KPI와 업무규칙을 정의합니다

    데이터를 가져왔다고 답이 만들어지는 것은 아닙니다.

    무엇을 실적으로 인정할 것인가?

    어떤 Stage를 유효 파이프라인으로 볼 것인가?

    어떤 조건에서 위험 프로젝트라고 판단할 것인가?

    같은 회사의 기준을 정의해야 합니다.

    중요한 KPI는 검증된 계산 로직으로 처리하도록 설계합니다.

  6. 권한과 Evidence를 연결합니다 

    사용자가 어떤 데이터를 볼 수 있는지 확인하고, AI가 어떤 Source와 계산식을 사용했는지 보여줄 수 있도록 설계합니다.

  7. 대표 질문으로 실제 품질을 검증합니다 

    “AI가 동작한다”는 것보다 중요한 것은 현업이 답을 신뢰할 수 있는가입니다.

    대표 질문별로, 데이터가 맞는가? 계산이 맞는가?, 근거가 맞는가?, 권한이 맞는가?. 설명이 업무적으로 타당한가? 를 검증해야 합니다.


기존 시스템을 분석할 때 무엇을 확인해야 할까?

기업에 AI용 API가 이미 잘 구축되어 있다면 활용할 수 있습니다. 하지만 오래 운영된 ERP나 레거시 시스템은 AI를 고려해서 설계되지 않은 경우가 있습니다. 이때는 다음 정보들을 검토할 수 있습니다.

  • 업무 화면

  • DB 테이블

  • ERD

  • 기존 SQL

  • API

  • 업무코드

  • 사용자 권한정책

  • 시스템 간 연계구조

  • 필요 시 관련 소스 구조

목적은 시스템 전체를 다시 만드는 것이 아닙니다. 대표 질문에 답하기 위해 어떤 데이터를 어디에서 어떤 조건으로 가져와야 하는지 정의하는 것입니다. U.STRA Enterprise Ontology AI는 업무 질문과 데이터소스, 필요한 조회와 권한정책을 연결하는 방향으로 AI 데이터 접근 구조를 설계합니다.


예시: “실질 영업 파이프라인은 얼마인가?”를 AI가 답하게 만들려면

하나의 질문을 실제로 따라가 보면 구조를 이해하기 쉽습니다.

질문

이번 분기 실제 수주 가능성이 높은 영업 파이프라인은 얼마인가?

필요한 Entity

  • Customer

  • Opportunity

  • Salesperson

  • Product

CRM 데이터

  • 영업기회 금액

  • Stage

  • 예상수주일

  • 최근 영업활동

  • 담당자

필요한 Rule

  • 어느 Stage부터 파이프라인으로 인정하는가?

  • 장기 미활동 기회는 제외하는가?

  • 이번 분기 예상 건만 포함하는가?

  • 수주확률을 어떻게 적용하는가?

계산

회사에서 정의한 공식 계산 로직을 사용합니다.

Permission

사용자는 전사 데이터를 볼 수 있는가, 자기 조직만 볼 수 있는가?

Evidence

AI는 다음 내용을 함께 제시할 수 있습니다.

  • CRM 기준시점

  • 포함된 영업기회

  • 제외 기준

  • 적용한 Rule

  • 계산 결과

AI의 역할

최종적으로 LLM은 계산결과를 바탕으로,

“어떤 영업기회가 전체 파이프라인을 좌우하는지”

“장기 미활동 기회가 얼마나 포함되어 있는지”

“어떤 고객을 우선 점검해야 하는지”

를 설명할 수 있습니다.

이것이 데이터 조회와 AI 분석을 분리하면서 연결하는 방식입니다.


ERP·CRM·HR 데이터를 한곳에 모두 복제해야 할까?

반드시 모든 데이터를 새로운 AI 데이터베이스에 복제해야 하는 것은 아닙니다. 기업의 목적과 시스템 구조에 따라 여러 방식이 가능합니다. 예를 들어,

  • 기존 시스템을 API로 실시간 조회하는 방식

  • 일부 데이터를 별도 분석계에 구성하는 방식

  • 기존 Data Warehouse를 활용하는 방식

  • 문서는 RAG로 연결하는 방식

  • 복잡한 관계가 필요할 때 Knowledge Graph를 활용하는 방식

등을 검토할 수 있습니다. 중요한 것은 특정 기술을 먼저 정하는 것이 아닙니다.

어떤 질문에 어떤 정확도와 기준시점으로 답해야 하는지에 따라 적절한 데이터 연결 방식을 선택해야 합니다.


Knowledge Graph나 GraphRAG가 반드시 필요한 것은 아닙니다

기업 데이터를 AI와 연결한다고 해서 처음부터 Knowledge Graph를 구축해야 하는 것은 아닙니다. 관계가 복잡하고 여러 도메인을 연결해 탐색해야 한다면 Knowledge Graph나 GraphRAG 활용 가능성을 검토할 수 있습니다.

하지만 비교적 명확한 질문과 RDB 데이터가 중심이라면,

Ontology + Read-only API + 기존 RDB + LLM

구조로 먼저 시작하는 것도 가능합니다.

문서검색이 중요하면 여기에 RAG를 추가할 수 있습니다.

기술은 고객의 현재 시스템과 해결해야 할 문제에 따라 선택하는 것이 중요합니다.


AI Assistant에서 AI Agent까지는 단계적으로 확장하는 것이 좋습니다

기업 데이터를 연결했다고 바로 AI에게 시스템 변경 권한을 줄 필요는 없습니다.

단계적으로 생각할 수 있습니다.

Level 1. AI Assistant

기업의 업무지식과 규칙을 활용해 질문에 답합니다.

Level 2. Data Connected AI

실제 ERP·CRM·HR 등의 데이터를 조회해 답합니다.

Level 3. Enterprise Intelligence

여러 시스템을 연결해 경영과 업무 질문을 통합 분석합니다.

Level 4. AI Agent

검증된 데이터와 판단구조를 바탕으로

분석 → 추천 → Human Approval → Tool 실행

으로 확장합니다.

이 과정에서는 데이터 조회권한과 실행권한을 구분하고, 중요한 업무에서는 사람의 승인 경계를 별도로 설계할 필요가 있습니다.


기업 데이터 AI 연계 전 체크리스트
  • AI가 반드시 답해야 할 대표 업무 질문이 정의되어 있는가?

  • 필요한 데이터가 어느 시스템에 있는지 알고 있는가?

  • ERP·CRM·HR에서 같은 업무개체를 서로 다른 코드로 관리하고 있지는 않은가?

  • 최신 확정값을 가져올 Source가 명확한가?

  • 기존 API로 필요한 데이터를 조회할 수 있는가?

  • 필요한 경우 Read-only API를 추가할 수 있는가?

  • KPI와 계산식이 명확하게 정의되어 있는가?

  • 부서마다 같은 KPI를 다르게 계산하고 있지는 않은가?

  • 업무규칙과 예외조건이 정리되어 있는가?

  • 사용자별 데이터 접근권한이 정의되어 있는가?

  • AI 답변에 데이터 기준시점과 Source를 표시할 수 있는가?

  • 문서 정보와 시스템 확정값을 구분할 수 있는가?

  • AI의 분석과 사람의 최종 판단 영역이 구분되어 있는가?

  • 대표 질문을 이용해 현업 품질평가를 할 수 있는가?

체크되지 않는 항목이 많다면 LLM 모델 선택보다 먼저 데이터와 업무 지식구조를 정리할 필요가 있습니다.


이런 기업이라면 데이터 연결형 AI를 검토할 시점입니다

다음과 같은 문제가 반복된다면 검토 가치가 있습니다.

  1. 경영보고를 만들 때 여러 시스템과 Excel을 매번 취합한다

    AI 문제라기보다 먼저 데이터와 업무 의미가 분리되어 있는 문제일 수 있습니다.

  2. ERP에는 숫자가 있지만 왜 그런 결과가 나왔는지 설명하기 어렵다

    CRM·PMS·HR·문서 정보와 연결하면 원인 분석 범위를 넓힐 수 있습니다.

  3. RAG를 구축했지만 현재 숫자를 제대로 답하지 못한다

    문서검색과 원천 데이터 조회의 역할을 분리할 필요가 있습니다.

  4. 시스템마다 같은 고객·프로젝트·직원을 다르게 관리한다

    업무개체와 관계를 연결하는 지식구조를 검토할 필요가 있습니다.

  5. AI Agent를 만들고 싶지만 Agent가 어떤 데이터를 믿어야 할지 정리되어 있지 않다

    실행 기능보다 먼저 Source, Rule, Permission과 Evidence를 정의하는 것이 좋습니다.


기업 데이터 AI 연계의 핵심은 ‘모든 데이터를 AI에게 주는 것’이 아닙니다

생성형 AI에 기업 데이터를 많이 연결한다고 좋은 기업 AI가 자동으로 만들어지는 것은 아닙니다. 중요한 것은 질문에 필요한 정확한 데이터를 선택하는 것입니다.


그리고 AI가

무엇을 조회하고, 무엇을 계산하며, 어떤 규칙을 적용하고, 누가 볼 수 있고, 어떤 근거로 답했는지 설명할 수 있어야 합니다.


GS비즈플의 U.STRA Enterprise Ontology AI는 이를 다음과 같은 구조로 접근합니다.

Question → Ontology → Entity → Read-only API → Enterprise Data → Deterministic Calculation → Rules / Permission → Evidence → AI Analysis → Answer

기업 AI의 목표는 ERP·CRM·HR을 없애는 것이 아닙니다.

기존 시스템에 축적된 기업 데이터를 AI가 업무의 의미에 맞게 이해하고 활용할 수 있도록 연결하는 것입니다.


자주 묻는 질문

ERP·CRM·HR 데이터를 생성형 AI와 바로 연결할 수 있나요?

기존 시스템의 API, 데이터 구조와 보안정책에 따라 달라질 수 있습니다. 기존 API를 활용하거나 필요한 업무 질문에 맞춰 조회용 API를 추가하는 방식을 검토할 수 있습니다. 구체적인 적용 범위는 고객 시스템 환경 확인이 필요합니다.

기존 ERP를 교체해야 하나요?

반드시 그럴 필요는 없습니다. 기존 시스템을 원천 데이터 Source로 유지하면서 Read-only API 등을 이용해 필요한 정보를 AI와 연결하는 방식을 검토할 수 있습니다.

RAG만으로 ERP 데이터를 조회할 수 있나요?

RAG는 주로 문서와 비정형 정보를 검색하는 데 활용됩니다. 현재 ERP의 확정값이나 실시간에 가까운 시스템 데이터를 사용해야 한다면 API나 별도의 데이터 접근구조를 함께 검토하는 것이 적절할 수 있습니다.

AI가 직접 SQL을 만들어 ERP를 조회하게 하면 되나요?

고객의 데이터베이스 구조와 보안정책에 따라 신중한 검토가 필요합니다. 기업 업무에서는 허용된 데이터와 조회 범위, 계산기준, 권한을 통제할 수 있는 구조를 두는 것이 중요합니다.

데이터가 여러 시스템에 흩어져 있어도 연결할 수 있나요?

검토할 수 있습니다. 중요한 것은 고객·직원·프로젝트 등 같은 업무개체가 시스템별로 어떻게 표현되는지 확인하고 관계를 정의하는 것입니다. 구체적인 연결방식은 각 시스템의 데이터 구조에 따라 달라집니다.

AI가 ERP 숫자를 직접 계산해도 되나요?

중요한 금액·비율·KPI는 회사가 정의한 검증된 계산 로직을 사용하는 것이 좋습니다. LLM은 계산 결과를 분석하고 설명하는 역할로 분리하는 구조를 검토할 수 있습니다.

데이터 권한은 어떻게 처리하나요?

기업 AI에 전달하기 전에 기존 사용자 권한과 업무 역할에 따라 조회할 수 있는 범위를 확인하는 구조가 필요합니다. 실제 방식은 고객의 인증·권한 및 보안정책에 맞춰 설계해야 합니다. 

처음부터 AI Agent까지 구축해야 하나요?

그럴 필요는 없습니다. 대표 질문과 Read-only 데이터 조회부터 검증한 뒤 Enterprise Intelligence, AI Agent로 단계적으로 확장할 수 있습니다.


RP·CRM·HR을 연결하기 전에 ‘AI가 답해야 할 질문’부터 정리해 보십시오 

기업 데이터 AI 연계의 첫 단계는 모든 시스템의 API를 만드는 것이 아닙니다.

먼저 경영진과 현업이 반복해서 묻지만 답을 만드는 데 오래 걸리는 핵심 질문 5개를 선정해 보십시오.


이 과정을 거치면 현재 필요한 것이 RAG인지, Read-only API인지, 기업 온톨로지인지, 여러 시스템을 연결하는 Enterprise Intelligence인지 구체화할 수 있습니다.


GS비즈플과 함께 ERP·CRM·HR 등 현재 운영 중인 업무시스템을 기준으로 우리 회사의 핵심 질문과 데이터 연결 가능성을 진단해 보십시오.


👉 유스트라 Enterprise Ontology AI 문의하기

---------------------------------------------------------------------------------------------------------------------------------함께 읽으면 좋은 글


댓글


서울특별시 종로구 창덕궁1길 13 (원서빌딩 1층)

02-2189-6700

bottom of page