온톨로지 핵심 개념

온톨로지가 표현하는 대상

온톨로지(Ontology)는 조직에서 다루는 대상과 사건을 정의하고, 그 대상의 특성, 다른 대상과의 관계, 수행할 수 있는 변경을 데이터에 연결한 체계입니다. 데이터셋과 모델 같은 디지털 자산을 항공편, 공항, 항공사처럼 업무에서 사용하는 개념에 연결하여 조직의 상태를 디지털 트윈(digital twin)으로 표현합니다.

항공사 업무를 예로 들면 원천 데이터에는 항공편 번호, 출발지 코드, 지연 시간 등이 열로 저장되어 있을 수 있습니다. 온톨로지에서는 항공편을 하나의 대상으로 보고, 출발 공항을 찾아가거나 항공편에 발생한 지연을 조사하고, 필요한 변경을 액션으로 제출합니다.

객체 유형, 속성, 링크 유형, 액션 유형이 이 구조의 기본 요소입니다. 함수, 역할, 인터페이스와 객체 뷰는 이 구조를 바탕으로 데이터를 조회하고 변경하거나 업무 화면에 표시하는 방식을 구성합니다.

정의와 실제 데이터를 먼저 구분하기

객체 유형(Object type)은 현실의 대상이나 사건을 표현하는 스키마 정의입니다. 객체(Object)는 그 유형에 속하는 개별 인스턴스입니다. Flight라는 객체 유형은 항공편이 가져야 할 특성을 정의하고, 특정 날짜에 운항하는 항공편 한 건은 그 유형의 객체가 됩니다.

객체 집합(Object set)은 여러 객체를 모아 다루는 단위입니다. 예를 들어 조건에 맞는 지연 항공편을 검색하면 그 결과를 객체 집합으로 사용할 수 있습니다. 이 집합을 화면에 표시하거나 함수에 전달할 수 있으며, 검색 조건이 달라졌다고 해서 새로운 객체 유형을 정의한 것은 아닙니다.

개발자가 스키마와 레코드를 구분하듯이, Foundry에서도 정의하는 대상과 실제 데이터의 수준을 나누어 읽어야 합니다.

이 구분은 권한에도 영향을 줍니다. 객체 유형의 정의를 볼 수 있는 권한과 실제 객체 데이터를 볼 수 있는 권한은 같지 않습니다. 이 차이는 뒤의 역할과 접근 권한 절에서 설명합니다.

데이터셋과의 대응 관계

데이터셋의 행과 열을 객체와 속성에 대응시키면, 데이터 구조와 업무 대상 사이의 관계를 이해하기 쉽습니다.

예를 들어 직원 데이터의 각 행이 직원 한 명을 나타내고, 각 열이 이름이나 입사일을 나타낸다고 생각하면 객체와 속성의 구분을 이해하기 쉽습니다. 관계형 데이터에서 두 테이블을 결합하는 방식에 익숙하다면, 온톨로지의 링크 유형은 두 객체 유형을 어떤 관계로 연결할지 정의한다는 점에서 대응시킬 수 있습니다.

데이터셋과 객체 유형은 별도의 리소스입니다. 객체를 구성할 때에는 기반 데이터소스(backing datasource), 속성 매핑(property mapping), 식별 기준과 보안 설정을 정합니다. 모든 속성을 액션으로 채우는 경우에는 기반 데이터소스 없이 객체 유형을 만들 수도 있습니다. 이 경우 객체 유형을 프로젝트에 저장하고 객체 보안 정책을 설정해야 합니다.

객체를 식별하고 속성값을 읽는 방법

객체 유형과 객체의 식별

객체를 사용할 때에는 어떤 유형에 속하는 객체인지와 그 유형 안의 어느 객체인지를 함께 알아야 합니다. 기본 키(primary key)는 같은 객체 유형 안에서 객체를 구분하는 기준입니다.

모든 객체에는 고유한 기본 키가 필요합니다. 기반 데이터소스가 있는 객체 유형에서는 키가 실행마다 임의로 달라지지 않도록 결정적으로 생성해야 합니다. 객체 편집과 링크가 객체의 키에 연결되어 있기 때문입니다.

화면의 표시 이름(display name), 프로그램에서 사용하는 API 이름(API name), 개별 객체의 기본 키는 서로 다른 역할을 합니다. 가상의 직원 모델에서 객체 유형의 표시 이름을 직원, API 이름을 Employee로 정했다고 가정하면, 직원 한 명을 식별하는 값 50030은 유형의 두 이름과 별도로 존재합니다.

프로그램에서 개별 객체를 조회하는 실제 입력 형식은 객체 조회 API에서 다룹니다.

속성과 속성값

속성(Property)은 객체 유형이 가지는 특성의 정의입니다. 속성값(Property value)은 개별 객체에 들어 있는 실제 값입니다. 항공편의 지연 시간을 분 단위로 표현한다고 가정하면, delayMinutes라는 속성을 정의하는 일과 특정 항공편에 38이라는 값을 갖게 하는 일은 다릅니다.

다음은 항공편 한 건의 속성을 표현한 가상 데이터입니다.

{
  "flightId": "F-001",
  "status": "Delayed",
  "delayMinutes": 38
}

이 JSON은 개념을 설명하는 예시이며 Foundry API 응답 형식을 재현한 것은 아닙니다. status와 delayMinutes는 속성을 가리키는 예시 이름이고, Delayed와 38은 한 객체의 속성값입니다. 같은 객체 유형의 다른 항공편에는 다른 값이 들어갈 수 있습니다.

공유 속성: 정의를 여러 객체 유형에서 재사용하기

공유 속성(Shared property)은 여러 객체 유형에서 재사용할 수 있는 속성 정의입니다. 여러 유형을 일관되게 모델링하고 속성의 메타데이터를 한곳에서 관리할 때 사용합니다.

예를 들어 Employee와 Contractor 객체 유형이 모두 start date라는 속성을 사용한다면, 이를 공유 속성으로 정의할 수 있습니다. 그러면 두 유형에서 같은 속성 정의를 사용하고, 관련 메타데이터를 한곳에서 수정할 수 있습니다.

공유되는 것은 속성 정의와 메타데이터입니다. 개별 직원과 계약자의 실제 입사일은 각 객체에 저장되며, 한 객체의 입사일을 바꾸어도 다른 객체의 값은 바뀌지 않습니다.

공유 속성은 객체 유형 사이에서 공통 정의를 재사용하는 기능입니다. 여러 유형을 하나의 공통 계약으로 다루는 인터페이스와는 역할이 다릅니다.

링크 유형과 링크: 대상 사이의 관계 표현

링크 유형(Link type)은 두 객체 유형 사이의 관계를 정의합니다. 링크(Link)는 그 관계에 따라 연결된 개별 객체들의 관계입니다.

예를 들어 항공편과 공항 사이에 출발 공항 관계를 정의했다면, 특정 항공편과 JFK 공항의 연결이 링크가 됩니다. 도착 공항도 공항 객체 유형을 가리키지만, 출발 공항과는 다른 의미의 관계입니다.

항공사의 공항, 항공편, 지연, 항공사와 항공기를 객체로 표현하면 다음과 같이 연결할 수 있습니다.

그림에는 다섯 객체 유형이 있습니다.

• Airport: JFK라는 공항 객체와 개항일, 운영 용량, 위도와 경도 같은 속성을 표시합니다.
• Flight: JFK → SFO 24-02-2020 15:22라는 항공편 객체와 출발, 도착, 승객 수 관련 속성을 표시합니다.
• Delay: 38 Minute Delay라는 지연 객체와 지속 시간, 도착 또는 출발 구분, 원인 관련 속성을 표시합니다.
• Airline: Skybourne Airlines라는 항공사 객체와 본사, 설립일, 항공 동맹 관련 속성을 표시합니다.
• Aircraft: Boeing 747-001 1234라는 항공기 객체와 운항 투입, 승객 수용 규모, 항속 거리 관련 속성을 표시합니다.

항공편은 공항과 Departed From, Arrived To 관계로 연결되고, 항공사와 Operated By, 지연과 Delayed By, 항공기와 Flown By 관계로 연결됩니다. 공항과 항공사 사이에는 Hub For, 항공기와 항공사 사이에는 Owned By 관계가 있습니다.

그림에 표시한 이름과 값은 항공 업무 모델의 예시입니다. 실제 운영에 사용할 객체 유형과 데이터는 각 환경의 업무와 데이터에 맞춰 구성합니다.

액션 유형: 허용할 변경을 정의하기

액션 유형(Action type)은 사용자가 한 번에 수행할 수 있는 객체, 속성값, 링크의 변경을 정의합니다. 액션(Action)은 그 정의에 입력을 넣어 제출하는 동작입니다. 액션 유형에는 변경과 함께 실행할 부수 효과(side effect)도 구성할 수 있습니다.

액션 유형을 온톨로지에 구성하면 사용자는 애플리케이션에서 그 액션을 적용하여 데이터를 변경할 수 있습니다. 여기서 객체 유형의 스키마를 수정하는 것과 객체의 실제 값을 변경하는 것을 구분해야 합니다. Flight Alert에 새 속성을 추가하는 것은 유형 정의의 변경이고, 경보 한 건의 값을 수정하는 것은 객체 데이터의 변경입니다.

Workshop에서는 이미 정의된 액션 유형을 버튼에 연결할 수 있습니다. 버튼은 대상 객체와 사용자 입력을 액션에 전달하고, 액션 유형에 구성된 규칙이 변경을 결정합니다. 항공편 경보 처리함은 이 연결을 사용해 선택한 경보에 조치를 제출하는 구성입니다.

입력 매개변수는 액션에 전달할 값을 정의하고, 변경 규칙은 그 입력으로 수행할 작업을 정합니다. 제출 조건은 입력값과 사용자 등의 실행 맥락을 판단하여 액션을 제출할 수 있는지를 결정합니다.

함수: 객체를 입력으로 받는 코드 로직

함수(Function)는 입력 매개변수를 받아 로직을 수행하고 출력을 제공하는 코드입니다. Foundry의 함수는 온톨로지와 통합되어 있어 객체나 객체 집합을 입력으로 받고, 객체의 속성값을 읽으며, 온톨로지를 사용하는 앱이나 액션 유형에서 활용할 수 있습니다.

가상의 항공편 처리 함수가 경보 객체 집합을 받아 지연 시간이 긴 경보부터 처리하도록 우선순위를 계산한다고 가정하겠습니다. 객체 집합은 입력이고 우선순위 계산 결과는 출력입니다. 같은 계산을 여러 화면에서 사용하면 각 화면에 같은 로직을 따로 구현할 필요가 줄어듭니다.

함수와 액션은 서로 결합할 수 있습니다. 함수 기반 액션(Function-backed action)은 함수가 액션의 변경 로직을 구현하는 구성입니다. 일반적인 함수 호출과 액션 제출을 구분하려면 해당 함수의 기능과 호출 경로를 함께 확인해야 합니다.

함수는 조회와 계산뿐 아니라 온톨로지 편집이나 외부 시스템 호출에도 사용할 수 있습니다. 호출 결과를 이해하려면 반환값과 함께 어떤 데이터를 변경하거나 외부 요청을 발생시키는지 살펴봐야 합니다.

인터페이스: 서로 다른 객체 유형을 공통 계약으로 다루기

인터페이스(Interface)는 객체 유형의 구조와 기능을 설명하는 온톨로지 유형입니다. 공통 구조를 가진 여러 객체 유형을 일관된 방식으로 다루도록 하며, 객체 유형의 다형성을 제공합니다.

시설을 공통으로 다루는 Facility 인터페이스가 Facility Name과 Location을 정의하고, Airport, Manufacturing Plant, Maintenance Hangar가 이를 구현할 수 있습니다. 각 유형은 시설의 공통 속성을 제공하면서 자체적인 속성도 가질 수 있습니다.

• 객체 유형은 구체적인 데이터의 유형이며 객체를 생성할 수 있습니다.
• 인터페이스는 공통 구조와 기능을 나타내는 추상적 정의입니다. 인터페이스 자체를 직접 객체로 생성하지 않고, 이를 구현한 구체적인 객체 유형으로 생성합니다.
• 객체 유형은 여러 인터페이스를 구현할 수 있습니다. 인터페이스도 다른 인터페이스를 확장할 수 있습니다.

공유 속성은 속성 정의를 재사용하는 기능이며, 인터페이스는 여러 객체 유형을 공통 계약으로 다루는 유형입니다. 인터페이스 속성은 인터페이스 안에서 정의하거나 공유 속성을 이용할 수 있습니다.

인터페이스를 실제로 사용할 수 있는 범위는 앱, SDK 언어와 위젯에 따라 다릅니다.

역할과 접근 권한

역할(Role)은 온톨로지 리소스에서 사용자가 수행할 수 있는 작업의 권한을 묶습니다. 온톨로지에는 프로젝트 기반 권한 방식과 이전의 온톨로지 역할 방식이 존재하므로, 해당 환경에서 사용하는 방식을 먼저 구분해야 합니다.

프로젝트 기반 방식에서는 객체 유형 등의 온톨로지 리소스를 프로젝트에 저장하고, 프로젝트나 폴더의 역할을 통해 조회, 편집과 관리 권한을 부여합니다. 새 온톨로지에서는 이 방식을 사용하며, 기존 온톨로지는 소유자가 전환을 활성화하고 리소스를 이전해야 할 수 있습니다.

이전의 온톨로지 역할 방식에서는 온톨로지 전체나 개별 리소스에 온톨로지 전용 역할을 부여합니다. 또 다른 이전 방식인 데이터소스 유래 권한은 기반 데이터소스의 권한으로 객체 유형의 권한을 결정합니다.

권한을 이해할 때에는 다음 두 질문을 분리합니다.

1. 객체 유형의 정의를 보거나 편집할 수 있는가?
2. 그 유형에 속한 실제 객체 데이터를 볼 수 있는가?

Building 객체 유형을 조회할 수 있어도 스키마와 연락 정보만 보이고 실제 건물 데이터는 보이지 않는 구성이 가능합니다. 객체 데이터를 보려면 객체 유형에 대한 조회 권한과 데이터 접근 조건을 함께 충족해야 합니다. 객체 및 속성 보안 정책을 사용하는 유형에서는 그 정책이 객체의 공개 범위를 결정하고, 데이터소스 정책을 사용하는 유형에서는 기반 데이터소스에 대한 권한이 데이터 접근을 결정합니다.

애플리케이션과 API로 객체를 조회할 때도 객체 유형에 대한 권한과 데이터 접근 조건을 함께 충족해야 합니다.

객체 뷰: 개별 객체를 중심으로 정보와 업무 연결하기

객체 뷰(Object view)는 특정 객체와 관련된 정보 및 업무 흐름을 모아 보여 주는 화면입니다. 객체의 주요 정보, 연결된 객체, 관련 지표뿐 아니라 분석, 대시보드와 애플리케이션도 포함할 수 있습니다.

예를 들어 항공편 하나를 열었을 때 항공편의 속성, 연결된 공항이나 항공사, 지연 분석과 관련 업무 화면을 한곳에서 제공하는 방식입니다. 객체 뷰를 사용하는 사람은 먼저 어느 객체를 보고 있는지 결정하고, 그 객체를 중심으로 필요한 정보를 확인하거나 연결된 업무를 수행합니다.

객체 집합을 탐색하는 화면과 개별 객체의 상세 정보를 보는 화면도 구분합니다. Workshop 사용 가이드에서는 객체 테이블에 여러 경보를 표시한 뒤, 활성 객체를 객체 뷰에 전달하여 선택한 경보의 상세 정보를 보여 줍니다.