관계를 알지 못하는 검색
문서는 검색하지만 공급사 → 발주 → 송장 → 비용센터 같은 관계는 알지 못합니다. 같은 대상이 시스템마다 다른 코드와 용어로 관리되고, 기준정보는 수작업 매핑 테이블에 의존합니다.
객체 · 관계 · 액션을 하나의 메타모델로 정의합니다. 객체 타입 · 속성 · 관계 타입 · 액션 타입 · 인터페이스 · 쿼리 타입으로 구성되며, 자동으로 갱신 · 검증되는 기준정보 역할을 합니다.
Ontology Engine은 기업의 객체 · 관계 · 액션을 하나의 메타모델로 정의하는 Atman Agentic Portal의 시맨틱 레이어입니다. 사람과 에이전트가 같은 규칙으로 데이터를 조회하고, 모든 변경은 승인을 거쳐서만 반영됩니다. 문서를 검색하는 데서 그치는 RAG와 달리, 공급사 → 발주 → 송장 → 비용센터 같은 관계를 알고 판단합니다.
← 좌우로 밀어 전체 구성도를 볼 수 있습니다 →
검색 기반 생성(RAG)은 문서 조각을 찾아 줄 뿐, 데이터 사이의 관계와 권한, 변경 이력은 다루지 못합니다. Ontology Engine은 이 세 가지를 하나의 기준 체계로 묶어 다룹니다.
문서는 검색하지만 공급사 → 발주 → 송장 → 비용센터 같은 관계는 알지 못합니다. 같은 대상이 시스템마다 다른 코드와 용어로 관리되고, 기준정보는 수작업 매핑 테이블에 의존합니다.
객체 · 관계 · 액션을 하나의 메타모델로 정의합니다. 객체 타입 · 속성 · 관계 타입 · 액션 타입 · 인터페이스 · 쿼리 타입으로 구성되며, 자동으로 갱신 · 검증되는 기준정보 역할을 합니다.
원시 DB를 LLM에 직접 노출하면 보안상 위험하고, 시스템마다 개별 연동을 개발하면 기간이 길고 기준이 일관되지 않습니다.
모든 조회와 변경이 하나의 정책 게이트를 통과합니다. 주체 · 애플리케이션 · 자원 · 분류 등급의 교집합으로 판정하며 REST · MCP · CLI 어느 경로든 같은 기준을 적용합니다. 권한 없는 도구는 목록에 표시되지 않습니다.
에이전트의 판단과 실제 반영된 변경을 연결하는 기록이 없습니다. 충돌 시 덮어쓰기나 부분 적용이 발생해도 알 수 없고, 변경 사유를 사후에 증명할 수 없습니다.
실행 → 액션 → 변경 → 감사 기록이 하나로 연결됩니다. traceId · principalId · policyDecisionId로 이어지며, 모든 변경은 검증된 액션으로만 수행되고 변경 · 감사 · 이벤트 기록이 단일 트랜잭션으로 처리됩니다.
사람과 에이전트가 같은 규칙으로 조회하고, 승인을 거쳐 변경합니다. 그래프 DB와 달리 메타데이터 관리 · 패싯 검색 · 셀 수준 정책 · 계보 · 원자적 액션을 하나의 기준 체계로 결합하며, 그래프 탐색은 보조 기능입니다.
OpenAPI · MCP 매니페스트 · CLI 명령이 모두 메타모델에서 생성되므로, 같은 입력에 대해 REST · MCP · CLI가 같은 결과를 돌려줍니다.
※ Palantir 온톨로지의 객체 · 액션 모델을 참고하되, 단일 PostgreSQL에서 시작하는 자체 호스팅 구조로 벤더 종속이 없습니다.
동일한 입력에 대해 REST · MCP · CLI가 같은 결과(operationId · validation · edits)를 반환합니다. 어느 경로로 접근해도 다른 답이 나오지 않습니다.
자신의 변경 즉시 조회(read-your-writes), 낙관적 동시성, 멱등 재시도, 스냅샷 조회, 액션 원자성을 엔진 수준에서 보장합니다.
아트만파트너스가 직접 보유한 엔진입니다. 폐쇄망 Docker 온프레미스에서 시작해 같은 코드로 클라우드(AWS EKS)까지 운영하며, 데이터가 외부로 나가지 않습니다.
하나의 파이프라인이 원장 · 벡터 · 온톨로지 · 지식 그래프 네 저장소에 동시에 적재하고, 기존 시스템은 읽기 전용으로만 연결합니다. 운영 시스템을 바꾸지 않습니다.
파일(CSV · Excel · PDF · 이미지 OCR), 데이터베이스(PostgreSQL · MySQL · SQLite, 읽기 전용 SELECT), API(폴링 · 인증 유형별), 실시간(MQTT · OPC-UA · Modbus). 자격증명은 서버에서 암호화 저장하고 API로 반환하지 않습니다.
추출 → 검증 → 변환 → 적재. 레코드마다 엔티티 유형 · ID를 추출해 엔티티와 관계를 갱신하고(중복 생성 없음), 증분 수집과 크론 예약, 품질 점수(완전성 · 유효성 · 일관성 · 유일성)와 격리 큐, 실패 원인을 진단하는 Self-Heal을 제공합니다.
PostgreSQL 원장(System of Record) · 벡터 DB(FAISS 기본, pgvector · Milvus 교체 가능) · 온톨로지 엔진(엔티티 · 관계를 객체 · 링크로 반영, 타입 매핑 불일치 감지) · 지식 그래프(Neo4j, 읽기 전용 Cypher · 최단 경로 · 서브그래프).
에이전트(데이터 조사기 · 온톨로지 에이전트), 채팅의 엔진 MCP 조회 도구, 워크플로우 노드(ontology_search · get · query · viz · action), 온톨로지 콘솔, 외부 연동(REST · MCP · CLI · SDK)에서 같은 온톨로지를 사용합니다.
purchase_order → PurchaseOrder, issued_to → ISSUED_TO처럼 엔티티 유형이 객체 · 링크 타입으로 자동 대응됩니다. 새 도메인은 엔티티 유형 추가만으로 전 구간이 연결됩니다.
승인된 시나리오 병합 결과가 ETL 엔티티 저장소에 다시 반영되어, 온톨로지와 수집 저장소가 서로 어긋나지 않습니다.
소스 10개 · 파이프라인 10개 · 엔티티 11종(vendor · purchase_order · invoice · gl_account · cost_center · shipment 등)으로 구성한 조달 · 재무 데모를 바로 시연할 수 있습니다.
조사 · 탐색 · 관리 세 영역으로 구성되며, 모든 조회는 사용자 권한에 따라 필터링됩니다. 역할은 etl_viewer(조회) → etl_operator(실행 · 제안) → etl_admin(승인 · 관리)으로 나뉩니다.
※ 엔진 장애 시 오류 대신 안내 패널을 표시하고, 미제공 모듈의 기능(시나리오 · 모니터)은 자동으로 숨깁니다. 한국어/영어 전환, 진단 모드에서 원시 ID/JSON 표시를 지원합니다.
가설은 시나리오에서 안전하게 검증하고, 확정된 판단은 케이스로 축적합니다. 병합이 승인되기 전에는 운영 데이터가 변경되지 않습니다.
승인 전에는 에이전트의 어떤 동작도 온톨로지 데이터를 바꾸지 않습니다. 에이전트의 추론 루프에는 변경(action.*) 도구 자체가 등록되어 있지 않습니다.
기본 조사 에이전트 1종과 온톨로지 전문 프로필 8종으로 구성됩니다. 조회는 사용자 본인의 권한으로 수행하고, 변경은 승인 요청으로만 제안합니다.
| 에이전트 | 사용 권한 | 역할 |
|---|---|---|
| ETL Data Examiner기본 조사 에이전트 | 모든 사용자 | 온톨로지 그래프와 ETL 이벤트 저장소를 교차 참조하여 발생 원인 · 연관 객체 · 확인 사항을 두 출처의 근거와 함께 설명 |
| Ontology Operations Copilot | 모든 사용자 | 운영 객체 · 관계 · 저장된 뷰 · 승인된 액션을 검색 · 설명. 미처리 알림 분류, 일일 운영 요약, 액션 요청 초안 작성 |
| Ontology Process Intelligence Agent | 모든 사용자 | 상태 전이 · 변형 · 병목 · 재작업 · 적합성 분석으로 실제 프로세스를 재구성한 뒤 개선안 제시 |
| Ontology Decision Optimizer | 모든 사용자 | 제약 조건 아래 실행 가능한 대안을 비교하고, 선택한 변경을 시나리오로 작성하여 승인 요청 |
| Ontology Data Steward | 관리자 | 데이터 품질 · 매핑 · 계보 · 정책 · 스키마 불일치를 점검하여 데이터 신뢰성 관리 |
| Ontology Automation Designer | 관리자 | 담당자 · 효과 · 실패 처리 · 승인 지점을 포함한 자동화 규칙 설계 (이벤트 · 임계값 · 스케줄 · 알림 · 액션) |
| Ontology Architect | 관리자 | 업무 목표와 소스 데이터를 근거로 객체 · 관계 · 액션 · 애플리케이션 설계안 제안 (직접 게시하지 않음) |
| Ontology Solution Delivery Agent | 관리자 | 승인된 설계를 버전 관리 · 최소 권한 · 테스트 가능한 배포 패키지(워크스페이스 · SDK/MCP 인터페이스 규격)로 구성 |
| Ontology Customer Supervisor | 관리자 | 전문 에이전트들을 조율하고 사용 불가한 기능을 명시하며, 근거 · 승인 · 담당을 포함한 하나의 실행 계획으로 종합 |
데이터 연결 → 온톨로지 모델링 → 감시 · 조사 → 승인 실행의 같은 절차로 적용하며, 객체 · 관계 유형은 고객 데이터에 맞춰 정의합니다.
거래 → 카드 → 임직원 → 가맹점 → 증빙 → 전표 → 계정 → 정책
카드 거래 · 증빙 · 전표를 하나의 온톨로지로 연결합니다. 문서 에이전트가 증빙을 OCR로 읽어 전표 · 계정 매핑을 검증하고, 분할 결제 · 휴일 사용 · 업종 위반 같은 조건은 모니터가 감시합니다. 적합 건은 자동 처리하고 예외 건만 조사 → 케이스 기록 → 승인으로 처리합니다.
알람 → 설비 → 로트 → 불량 → 레시피 → 근본 원인
센서 · MES · 운영 시스템 데이터를 파이프라인으로 수집하고, 관계 그래프를 따라 원인을 추적합니다. What-if 시나리오로 조치의 영향을 검증한 뒤 승인을 거쳐 반영합니다.
공급사 → 발주 → 선적 → 송장 → 고객
납기 지연 · 공급사 리스크 신호를 모니터로 감시하고, Decision Optimizer가 제약 조건 아래 대안 경로를 비교하여 시나리오로 제안합니다. 승인된 대안만 운영 데이터에 반영됩니다.
시설 → 자산 → 품번 → 계약 → 담당 조직
여러 조직 · 시스템의 ERP와 자산 데이터를 읽기 전용으로 연결하고, 품번과 장비명 같은 표준 매핑을 온톨로지 유형으로 정의합니다. 표준 항목은 자동 매핑하고 예외는 담당자가 승인하며, 확정된 매핑은 다음부터 자동 적용됩니다.
변경 → 액션 → 주체 → 정책 결정 → 감사 기록
결론의 근거를 추론 단계 · 도구 호출 · 데이터 계보 · 변경 이력으로 제시합니다. 승인 없는 자동 변경이 발생하지 않는 구조로 내부 감사와 규제 대응에 활용합니다.
워크플로우 빌더의 온톨로지 노드(search · get · query · viz · action)로 구성하며, 온톨로지 액션 노드는 승인 필요로 설정하면 승인 대기열에 제안만 등록합니다.
※ 위 시나리오는 플랫폼 기능 조합의 예시입니다. 객체 · 관계 유형은 고객 데이터에 맞추어 스키마 작성 화면에서 정의합니다.
그래프 탐색은 Ontology Engine의 보조 기능입니다. 핵심은 메타데이터 관리 · 패싯 검색 · 셀 수준 정책 · 계보 · 원자적 액션을 하나의 기준 체계로 묶어 관리하는 것입니다. 지식 그래프(Neo4j)는 네 저장소 중 하나로 함께 운영됩니다.
아닙니다. 기존 시스템은 읽기 전용으로 연결하고, 파이프라인이 엔티티 · 관계를 온톨로지에 반영합니다. 운영 시스템에 대한 쓰기는 승인된 액션과 연계 노드를 통해서만 이루어집니다.
없습니다. 에이전트의 추론 루프에는 변경 도구가 등록되어 있지 않고, 모든 변경은 사전 검증 → 승인 대기 → 승인 → 실행 → 기록의 5단계를 거칩니다. 본인 요청은 본인이 승인할 수 없습니다.
대표 업무 하나(예: 구매 · 경비 · 설비)를 정해 주시면 소스 연결부터 모델 맵, 조사 화면까지 데모 환경으로 시연합니다. 1주 환경 구축 후 4주 파일럿으로 효과를 확인하는 방식을 권합니다.