< 시멘틱 온톨로지 >

메타데이터와 온톨로지

메타데이터를 통한 의미(semantic) 설계

같은 주제인데 대화 환경에 따라 다른 답을 제시하는 AI
시멘틱은 환경의 변화와 상황의 문맥에 따라서 달라질 수 있기 때문이다.

소프트웨어공학에서 ERD 그리고.. 다이어그램 그리고.. 그러다가 AI를 도입했지만 블랙박스의 한계 때문에 잘 안됨.

AI를 도입하기 전에 왜 의미를 설계해야하는가

접근 방식에 대한 이해가 중요함
업무를 정의하고 전달하고 일관성있게 전달하는 것이 중요.

Vibe Code로 업무 자동 생성이 가능한 시대의 Agent 접근 방식

업무 환경과 상황이 복잡해지면서 맥락과 기준 설정이 중요해짐.
-> 데이터를 다양한 의미를 내재하는 메타 데이터로 재구성

• 메타 데이터의 속성
• 생성형 AI와 온톨로지 시대, 메타데이터의 역할의 진화
• 메타데이터의 성장에 따른 업무 Use Case 적용 영역과 범위의 통제

생성도 중요하지만, 거버넌스(통제)가 더 중요한 상황

AI데이터는 많은데 왜 의사결정과 판단은 어려운가?

-> 이제 현 상황에서는 이미 학습이 되어 있기 때문에 상관이 없다.

이제 내가 일을 시켜야하는데 "내 지식"이 중요해지는 시대이다.

기존의 메타데이터 구성 방식

객체 + 메소드 -> 객체지향프로그램
어떤 테이블에 어떤 데이터,속성을 저장 관리할것인가
데이터 모델링, ERD 구축

-> SaaS, MSA, Modularity 설계로 진화
-> 예기치 못한 이벤트 발생

Data, Information, Knowledge 차이

Entity(data) + Information -> Knowledge

이렇게 되어가는 과정에 메타데이터가 성숙해져가는 과정이다.

원래는 제약이 있었는데 그 제약을 풀어줘서 더 폭넓은 의미를 내포할 수 있도록 한다.

Data

Entity

Information

Knowledge

기존 데이터 모델과 의미 기반 모델링의 차이

앞의 규약이 풀어짐.

Knowledge는 Table과 Entity를 넘어서 폭넓고 깊이 있는 의미 전달 매체로 변화중.

Metedata와 MDR의 등장 배경

Data에서 Metadata 영역으로 전환

메타데이터는 단순히 데이터에 대한 설명이 아님.
어떤 환경에서 어떤 업무에서 어떤 맥락으로 쓰이느냐?

data + semantic (AI-Native Semantic) = Metadata
이 과정 자체가 MDR 이다.

기존 Metadata와 비교

Metadata Registry

Metadata는 데이터에 부여된 업무적 의미
Metadata가 성숙해진 상태를 Metadata Registry라고 표현

업무를 의미 구성 관점으로 보기

사고 체계를 의미기반 체계로 전환

AI는 온톨로지를 기준으로 어떤 규칙이 적용되는지 판단

• 누가 판단하는가? (Actor)
• 어떤 기준이 적용 되는가? (Rule/Policy)
• 언제 문제가 발생하는가? (Event,거버넌스)
• 무엇이 성공적인 결과인가? (Goal)

모델링 기술이 중요하다 (개발자들이 더 필요하게 될 것)

그리고 이 질문에 대한 답이 바로 MDR과 온톨로지가 관리하는 대상임.

AI 시대의 경쟁력은 의미를 구조적으로 전환하는 능력에 있음.

업무 지식지도(온톨로지)의 실체 그리고 그 구성

업무를 이루는 개념들이 어떻게 연결되어 판단으로 이어지는지를 보여주는 지도

업무를 의미 구성 관점으로 보기

지금까지는 이 의미를 어디까지 어떻게 app을 구현해왔을까?

Table-Key 구조를 통한 관계 형성 모델 + 객체와 메소드로 구현

AI를 활용해 업무 체계를 구축하기 위해서는 온톨로지와 같은 지식 지도 설계 체계가 필요하고, 기업 업무 전체를 보는 시각과 역량을 가지고 AI를 활용하는 전문가가 필요함.

온톨로지 적용 성공 사례와 추세

메타 데이터가 체계적으로 쌓인 것이 온톨로지이다.

온톨로지의 구조

온톨로지의 스키마는 클래스,인스턴스,관계로 구성되어있음.

AI의 업무 추론 능력, 프로그램 자동 생성 기능, 사람의 업무 지식을 이어주고, 그 의미가 실행 가능한 시스템으로 작성되도록 도와주는 중간 매체

온톨로지의 Schema 구성

Class, Relation, Instance, Property

그 위에 논리(규칙,정책,제약)과 이벤트 대응요건을 추가

-> 정적인 온톨로지

사람과 AI간에 물체를 바라보는 시각을 동기화

의미 기반 업무 설계의 첫 단계

현실세계의 업무를 사람이 사고할 수 있는 크기로 나눔

-> EA
BA
DA
AA
TAA

1 , 2, 3, 4, 5
1~3까지는 맥락을 의미, 4는 논리 , 5는 실행

업무 계층 설정

업무를 모ㅓㄱ적과 판단의 성격에 따라 단계적으로 구분한 체계

온톨로지 -> 에이전트 여러개 (하나의 워크 플로우) -> 업무 프로세스 흐름

이 때 업무 시스템 설계 과정에서 운영의 맥락을 알고 업무 프로세스 계층 1~5로 구분

업무 계층 단계

계층 1 : 가치 흐름 설정 계층

기업의 존재이유, 정관, 미션을 설정한다.

조직이 왜 이 업무를 수행하는지?

시사점

이때는 세부 규칙이나 시스템은 등장하지 않음.

계층 1 : 업무 영역

업무 맥락, 운영 환경

• 산업/업종
• 기업 규모, 성숙도
• 경영 철학, 위험 성향
• 운영 전략

시사점

최상위 업무 분류 체계 : 업무 Scope 자동 설정

-> 이 계층에서 잘못 주면 모든판단이 왜곡됨.

계층 2: 업무 영역

기업의 업무 영역과 관련 속성을 설정

-> 조직/직무 체계와 연동

업무 처리 영역 설정
데이터 체계 구축 방식 설정
목표함수를 정의하는 층 (KPI,우선순위 충돌 시 기준, 성과 평가 관점)

-> 이때 무엇을 최적화할지 스스로 결정하면 위험함.

계층 3: 판단 단위

기업의 운영 정책과 규칙을 설정한다.

3계층부터 의미 기반 설계가 본격적으로 시작함.

-> 4계층 부터 AI가 주도적으로 업무 자동화 영역 실행

• 정책, 규정, 법적 제약
• 금지 조건
• 승인 조건, 임계치

-> 이 때 할루시네이션과 위험 판단 발생 지점.

계층 4 : 실행 기준 규칙

구체적인 업무 실행 영역이 시작됨.

판단에 사용되는 기준이 정의되는 단계

-> MDR에 환경 설정 지식으로 등록
업무 지식 MDR가 업데이트 되고, 시간이 흐르면서 기업 고유의 실행 지식(노하우)가 축척

이 때 LOT를 스스로 지정을 하는 방법 말고 BOM에 대해서 LOT을 지정을 해봐라고 넓게 대답을 요구하는 지점이 필요함.

• 경우의 수 판단
• 대안 시나리오 비교
• 우회, 대체 경로 탐색

-> 과도한 간섭/설정은 오히려 AI 성능 저하 요인

계층5: 실행 현장 영역

현장에서 업무 처리 및 실행을 위한 논리와 해당 Agent를 생성

실제 실행 단계

AI에게 최대 자유도를 주는 층

업무 계층과 MDR 관계

MDR은 지식 Contents , 온톨로지는 지식을 담는 틀(스키마)

생성 및 실행 계층

온톨로지는 AI의 사고 기준 그 자체

온톨로지에서 의미로 정보를 관리하는 방식

과거 컴퓨터 소프트웨어 공학에서의 옛날의 모델링 관점으로 정의함.
이걸 참고를 해서 메타데이터를 다시 구성해야하는 방안을 모색해야됨.(지금의 방식과는 맞지않음.)

온톨로지 설계

온톨로지

온톨로지 : 프로세스가 모이는 곳
현장에서의 업무 처리 및 실행을 위한 논리와 해당 Agent를 생성

각 Level은 온톨로지에서 서로 다른 역할을 가짐.

결국 온톨로지는 결과가 되고, 그 과정은 레지스트리 과정이 있어야 있는것임.

MDR이 매핑 되어 들어가게 되고,온톨로지에서 스키마가 만들어지고, 에이전트가 붙어서 LLM이 만들어짐.

지식 그래프를 쓰게되면 우리가 기존에 정규화된 정합성이 맞아떨어지는 프로세스말고, 관계가 희미한 것 까지 볼 수 있음.

이 때 OWL이 감당할 수 없는 부분에서 SHACL을 차용한다.

메타데이터는 어떻게 지식으로 자라고 전환 되는가?

상위 업무 계층은 사람의 직관과 통찰력으로 주도
하위 업무 논리의 전개와 실행은 AI-LLM의 주도
업무 Proces 운영은 사람과 AI의 협업을 운영

업무 설계 접근 방식의 재정의

• 업무 절차를 정리하는 것

• 화면 흐름을 그리는 것(프로토타입)

• 시스템 기능 목록을 만드는 것

  업무를 데이터가 아니라 구조와 의미로 설계한다는 의미

  환경설정을 할 때 변수가 있는데 이 기준을 가지고 프로세스를 분해

  업무를 데이터가 아니라 구조와 의미로 설계한다는 의미

  AI는 전체를 행렬로 봐서 통으로 판단함.
  구조와 의미로 설계한다는 것은 많은 데이터를 가지고 한번에 처리를 할 수가 있음 -> 이 행렬 구조를 어떻게 풀어나갈까?

  온톨로지 스키마의 구조

  

  클래스

  클래스는 데이터가 아니라 업무 개념.
  개념은 단순한 명사가 아님.주어,목적어,활동 단위, 어떠한 프로세스의 자체

• 업무에서 반복적으로 등장

• 판단의 기준

• 다른 요소와 관계를 맺는 대상

  이러한 것들이 온톨로지에서의 클래스가 됨.

  
  

  릴레이션

  개념 간의 의미있는 연결

  이 때 개념이란 단순 데이터가 아니라 판단의 기준이 되는 개념들
  => Actor, What(class)에 대한 Acitivity, 활동(How)의 개념.

  클래스와 릴레이션 사이에 연결이 생기는데 이러한 모든 것들이 업무 use case가 됨.

• 어떤 조건에서 연결?

• 언제 유효한가?

• 다른 연결과 충돌할 수 있는가?

  
  

Rule

온톨로지의 확장 요소
규칙, 정책, 조건, Why, Condition의 개념

Constraint

Rule과 함께 반드시 구분해야 할 개념
Rule은 상황에 따라 달라질 수 있으나,Constraint는 어떤 경우에도 위반할 수 없는 조건

Event & Workflow

판단이 발생하는 흐름
workflow : 시간에 따른 업무 전개 형태

-> 이벤트를 기준으로 판단이 실행, 판단의 연속이 Workflow를 구성

property

클래스의 속성과 가깝다. 릴레이션 속성이랑도 가깝다.

instance

AI-LLM 지식 선별 구조화

한 prompt 엔지니어링

온톨로지 기반 Agent 생성

의미 기반 관리

MDR과 온톨로지는 기업관리의 기준을 설정

• MDR : 관리 대상이 되는 기준의 목록
• 온톨로지: 기준이 작동하는 구조

Agent 생성

prompt

단순한 질문이나 명령문이 아니라 우리가 설계한 의미 구조(온톨로지)를 AI가 실행할 수 있도록 표현한 언어적 형태

• 프롬프트를 실행하는 주체는 무엇인가?
• 프롬프트는 누가,언제, 어떤 책임 하에 실행되는가 ?

이 때 등장하는 개념이 Agent

Agent 속성

Agent는 업무 역할의 실행 단위
Activity / Action의 양면의 속성을 나타냄

• 활동 : 온톨로지에 설정된 지식 활동, 현장활동, 직무에 따른 업무 및 데이터 처리 요령

• 프로그램 : 온톨로지에 설정된 데이터 처리 프로그램, 정보 분석 로직을 처리하는 알고리즘, 업무 진행 상황을 표시하는 대시보드

Agent와 Prompt 관계

• Prompt : 무엇을 어떻게 판단할 것인지 표현
• Agent : Prompt를 실행할 책임을 가진 주체

Prompt는 통제, Agent는 역할 자체, 속성은 온톨로지에 설정

Agent는 LLM에 대해 독립적이다.

LLM은 Agent 안에서 어떤 역할을 하는가?

LLM은 학습된 업무 추론 논리를 Agent에 상속
LLM은 Agent의 논리판단 수행을 지원하는 도구임.

• 온톨로지는 판단의 기준
• Prompt는 판단의 표현/문장
• LLM은 판단을 계산하는 엔진
• Agent는 이 모든걸 묶은 실행단위

프롬프트를 통한 Agent 생성

프롬프트 템플릿(온톨로지+MDR)

프롬프트 템플릿 하나로 여러 Agent를 만들고, Agent를 연결해서 실제 기업 업무 흐름을 구성

Agent 분류

프롬프트 템플릿을 기준으로 여러 개의 Agent를 설계,분리
이를 하나로 연결해서 하나의 업무 흐름을 구성함.