규정·문서·데이터와 현업의 경험을 분석하고, 컨설팅 방법론과 산업별 베스트 프랙티스의 적용 가능성을 검토해 업무 개념과 판단 기준을 정의합니다. 용어와 관계, 계산식과 예외 조건을 정의하고, AI Agent와 업무 시스템이 조회·적용할 수 있도록 구현합니다. 기존 문서·검색·SQL로 충분한 범위는 유지하며, 관계 탐색이 필요한 업무에는 Ontology와 Knowledge Graph를 적용합니다.
RAG는 관련 문서를 찾고 답변을 만드는 데 유용합니다. 그러나 동일한 용어의 다른 의미, 규칙의 적용 조건과 예외, 서로 상충하는 근거와 승인 상태까지 관리하려면 Knowledge 구조와 Business Rules가 필요합니다.
부서와 업무에 따른 용어의 의미 차이를 분석하고, 개념의 정의와 적용 조건을 명시합니다.
계산 기준과 판단 조건, 임계값, 적용 순서, 예외와 승인 절차를 명시합니다.
각 지식의 출처와 적용 시점을 기록하고 서로 다른 주장은 근거와 조건을 비교할 수 있도록 구분합니다.
소유자와 승인 상태, 버전, 접근권한과 변경 영향을 관리해 Agent가 사용할 수 있는 지식의 경계를 정합니다.
대상 업무와 기존 자료를 검토해 아래 항목 중 필요한 구현 범위를 정합니다.
핵심 업무 개념과 속성, 관계, 상태, 이벤트, 책임과 판단 맥락을 정의합니다.
문서와 데이터, 규정, 조직, 업무 객체와 판단 근거를 식별 가능한 Node와 관계로 구성합니다.
원천에서 지식 후보를 추출하고 Entity Resolution, 관계 매핑, 중복과 상충 처리를 구현합니다.
업무 질문과 지표, 판단 조건, 임계값, 예외, 승인과 실행 조건을 구조화합니다.
Agent와 Application이 업무 규칙과 근거를 검색·조회하고, 관련 개체와 관계를 탐색할 수 있는 API를 구현합니다.
출처와 소유자, 품질 상태, 버전, 권한, 승인, 변경과 폐기 절차를 적용합니다.
개체와 관계를 그래프로 표현하는 것만으로는 업무에서 사용할 수 없습니다. 무엇을 같은 개체로 볼지, 어떤 관계를 허용할지, 상충하는 지식과 변경을 어떻게 처리할지를 명시적인 규칙으로 정의합니다.
개체의 고유 식별자와 명칭, 속성, 개체와 관계의 업무 의미와 적용 범위를 정의합니다.
중복 개체의 통합 기준과 서로 다른 주장, 예외, 적용 시점이 충돌할 때의 처리 원칙을 정합니다.
필수 속성과 허용 관계, 값의 범위, 완전성과 일관성 검사를 규칙으로 적용합니다.
출처와 근거, 소유자, 유효기간, 승인 상태와 사용할 수 있는 지식의 범위를 관리합니다.
사용자와 Agent의 접근권한, 버전, 변경·폐기 절차와 변경이 Agent·Application에 미치는 영향을 관리합니다.
실제 업무 질문을 이용해 필요한 지식과 근거를 제공하는지 확인하고 누락과 미확정 영역을 찾습니다.
문서와 데이터에서 개체·관계·Business Rules를 추출하고, Schema 기반 Ontology 모델링, Entity Resolution, 근거 대조, Multi-Model Review와 품질 검증을 거쳐 관리 가능한 Knowledge로 구축합니다. 승인 상태와 버전, 변경 영향도 같은 기준으로 지속적으로 관리합니다.
규정과 매뉴얼, 데이터 사전, SQL, 보고서와 인터뷰 기록에서 업무 개념과 관계, 규칙 후보와 근거 위치를 추출합니다.
대상 업무의 개체 유형과 속성, 허용 관계와 출력 구조를 Schema로 정의해 추출 범위와 표현 방식을 통제합니다.
서로 다른 명칭과 코드가 같은 고객·제품을 가리키는지 식별합니다. 동일 개체의 식별 기준을 정하고, 관련 문서·데이터와 근거의 대응 관계를 명시합니다.
복수 LLM의 결과를 비교하고 추출한 지식을 원문과 데이터 정의에 대조해 누락, 과도한 해석과 상충 항목을 찾습니다.
식별자와 필수 속성, 허용 관계, Business Rules와 실제 업무 질문을 이용해 구조와 내용의 품질을 검사합니다.
확인된 내용과 미확정 내용을 구분하고 승인 상태, 버전, 변경·폐기 이력과 Agent·Application에 미치는 영향을 관리합니다.
같은 ‘매출’도 조직과 보고 목적에 따라 계산 기준이 다릅니다. 제품과 고객을 구분하는 방식, 원가 배부와 예외 처리도 기업마다 다릅니다. 이러한 차이를 명확히 하고, AI가 분석에 사용할 기준으로 구현하는 것이 Knowledge Engineering입니다.
판매처와 최종 고객을 구분하지 않으면 고객별 실적의 의미도 달라집니다. Ontology에 각 개념의 정의와 관계를 명시하고 원천 데이터와 대응시킵니다. 여러 시스템이 같은 의미를 공유하거나 관계에서 새로운 사실을 추론해야 할 때 RDF·OWL을 활용할 수 있습니다.
원가가 누락된 제품을 수익성이 높은 제품으로 해석해서는 안 됩니다. 필수값, 허용 관계, 값의 범위를 검사하고 문제가 있는 항목을 분리합니다. RDF 그래프는 SHACL로, 테이블은 SQL 검사와 지원되는 데이터베이스 제약으로 검증할 수 있습니다.
매출에 반품을 언제 반영할지, 공통비를 어떤 기준으로 배부할지가 수치의 의미를 결정합니다. Semantic Model에 계산식·집계 단위·기간·조인 기준을 명시하고 Semantic View나 승인된 SQL에 반영합니다. 계산 결과는 기준 보고서나 검증 데이터와 대조합니다.
규정이 개정되면 유사한 문서를 찾는 것만으로는 부족합니다. Knowledge Service는 적용 시점과 승인 상태, 조회 권한을 확인해 분석에 쓸 근거를 제공합니다. 자료의 성격에 따라 Keyword·Vector 검색, SQL, Graph 질의를 조합하고 출처와 버전을 함께 남깁니다.
가격 변경안을 제시하는 것과 실제 가격을 바꾸는 것은 다른 권한입니다. Agent의 Tool 호출 전에 입력 Schema, 업무 조건과 승인 여부를 코드로 확인합니다. 데이터 변경과 외부 전송에는 중복 실행 방지, 재시도 기준과 감사 기록이 필요합니다.
원가 배부 기준 하나가 바뀌어도 지표, 보고서와 Agent의 설명이 함께 달라질 수 있습니다. Knowledge·규칙·Skill·조회 서비스의 버전과 의존 관계를 추적하고, 영향을 받는 분석을 다시 테스트합니다. 배포 단위와 이전 버전으로 복구할 범위도 이 관계를 기준으로 정합니다.
고객 환경에 맞는 구성 — 기존 데이터·검색 서비스를 활용하며 관계 탐색과 추론 요건에 따라 Graph Database나 OWL 엔진을 선택합니다. 전용 Knowledge Graph 제품 도입을 전제로 하지 않습니다. 구체적인 기술 구성은 아키텍처 검토에서 정합니다.
“어떤 제품의 수익성이 왜 하락했는가?”라는 질문에는 계산보다 먼저 정리할 기준이 있습니다. 아래는 이를 Knowledge와 분석 절차에 반영하는 설계 예시입니다.
매출총이익과 공헌이익은 답하는 질문이 다릅니다. 사용할 지표, 비교 기간, 비용 배부와 일회성 비용의 처리 기준을 정하고 제품·고객·거래 데이터에 대응시킵니다.
원가 누락, 코드 중복, 통화·단위 불일치를 먼저 확인합니다. 미확정 비용을 임의로 채워 계산하기보다, 분석 가능한 범위와 추가 확인이 필요한 항목을 구분해 제시합니다.
가격·물량·제품 구성·원가의 영향을 검증된 SQL과 계산 모듈로 분석합니다. LLM은 분석 순서와 해석을 지원하고, 원인별 기여도 합계가 전체 변동과 일치하는지는 계산 코드로 확인합니다.
분석 결과에는 적용 지표와 규칙 버전, 데이터 기준일, 가정과 예외를 남깁니다. 가격 조정이나 제품 구성 변경을 검토할 수 있도록 근거를 제시하되, 실제 변경은 해당 업무의 권한과 승인 절차에 따릅니다.
질문과 관련된 문서, 개념과 근거를 찾고 출처와 적용 범위를 확인할 수 있도록 제공합니다.
Agent가 분석할 지표와 확인 순서, 판단 조건과 예외, 결과에 제시할 근거로 Knowledge를 사용합니다.
업무 조건과 승인 규칙에 따라 다음 검토 항목과 대안을 준비하고 사람의 승인 절차에 반영합니다.
규정과 데이터 정의가 바뀔 때 관련 개념, 규칙, Agent와 Application에 미치는 영향을 확인합니다.
대상 업무와 보유 자료, 지식 활용 과정의 어려움을 알려주세요. 현업의 판단 기준을 정의하고 시스템에 반영하는 데 필요한 작업 범위를 검토합니다.
Enterprise Knowledge 문의하기 →