Simple Event Model(SEM) 완전 해부: 세상의 모든 사건을 구조화하는 법

들어가며: "무슨 일이 있었는데요"

우리는 매일 사건(Event) 속에서 산다.

"오늘 오전 10시, 서울 코엑스에서 AI 컨퍼런스가 열렸다. 발표자는 김철수 교수였고, 주제는 LLM 안전성이었다."

이 한 문장 안에는 놀라울 정도로 많은 정보가 담겨 있다. 언제(오전 10시), 어디서(코엑스), 누가(김철수 교수), 무엇을(AI 컨퍼런스 발표) 했는지. 인간은 이걸 자연스럽게 이해하지만, 컴퓨터에게는 전혀 다른 이야기다.

구글 캘린더에 저장된 일정은 "장소"와 "시간"은 알지만 "누가 어떤 역할로 참여했는지"는 모른다. 뉴스 기사는 사건을 서술하지만, 같은 사건에 대한 다른 관점을 연결하지 못한다. 위키피디아는 역사적 사건을 설명하지만, 그 사건들 사이의 인과관계를 기계가 추론할 수 있는 형태로 제공하지 않는다.

바로 이 질문에 답하기 위해 2011년, 네덜란드 암스테르담 자유대학교의 연구진이 Simple Event Model(SEM) 을 만들었다.

1부: 왜 이벤트 모델이 필요해졌을까

웹이 만든 데이터의 바벨탑

2000년대 중반, 웹은 폭발적으로 성장하고 있었다. 하지만 데이터의 양이 늘어날수록 "같은 것을 다르게 말하는" 문제가 심각해졌다.

시맨틱 웹의 꿈

SEM을 이해하려면 먼저 시맨틱 웹(Semantic Web) 을 알아야 한다. 웹의 아버지 팀 버너스리가 2001년에 제안한 비전이다.

현재 웹은 사람이 읽기 위한 것이다. HTML 문서에 "이순신 장군이 1592년 한산도에서 해전을 벌였다"라고 쓰여 있어도, 컴퓨터는 이것이 사람에 대한 것인지, 장소에 대한 것인지, 사건에 대한 것인지 구분하지 못한다.

시맨틱 웹은 이걸 바꾸려 했다. 데이터에 의미(semantics) 를 부여하여 기계가 추론할 수 있게 만드는 것이다.

그런데 문제가 있었다. 시맨틱 웹 기술 스택(RDF, OWL, RDFS)은 존재했지만, "사건을 어떻게 표현할 것인가" 에 대한 표준은 여전히 혼란스러운 상태였다.

SEM 이전의 이벤트 모델들

SEM이 등장하기 전에도 여러 이벤트 모델이 있었다. 각각 장단점이 뚜렷했다.

• Event Ontology(EO) 는 BBC Music에서 음악 공연을 기록하기 위해 만들어졌다. 심플하지만 역할(Role)이나 관점(View) 개념이 없어서, "같은 사건에 대한 다른 해석"을 담을 수 없었다.

• LODE(Linking Open Descriptions of Events) 는 클래스가 Event 단 하나인 극단적 미니멀리즘을 택했다. 가볍지만, 사건의 복잡한 맥락을 표현하기엔 역부족이었다.

• CIDOC-CRM 은 정반대로 갔다. 국제 박물관 위원회가 만든 이 모델은 140개 클래스, 144개 속성의 거대한 온톨로지다. 표현력은 뛰어났지만, 학습 곡선이 높고 범용성이 떨어졌다.

SEM은 이 세 모델의 교훈을 종합하여, "충분히 단순하면서도 복잡한 현실을 담을 수 있는" 균형점을 찾았다.

2부: SEM의 핵심 구조 — "누가, 무엇을, 어디서, 언제"

SEM의 설계 철학: 관대한 모델

SEM의 가장 큰 특징은 "최소한의 의미적 약속(minimal semantic commitment)" 이다. 논문의 핵심 문장을 직접 인용하면:

이 철학이 왜 혁신적이었을까? 당시 시맨틱 웹 커뮤니티에서는 "더 엄격한 온톨로지가 더 좋은 온톨로지" 라는 믿음이 지배적이었다. 하지만 현실의 웹 데이터는 지저분하고, 불완전하고, 모순적이다. SEM은 이 현실을 인정한 최초의 이벤트 모델 중 하나였다.

SEM의 핵심 설계 원칙들:

1. 이벤트의 정의를 고정하지 않는다 — 아서 왕의 탐험, 로즈웰 UFO 착륙, 조지 W. 부시의 선거 모두 SEM에서 유효한 이벤트다.
2. disjointness를 최소화한다 — 장소와 행위자를 분리하지 않는다. 지리적 지역이 동시에 통치 기관일 수 있기 때문이다.
3. 카디널리티를 강제하지 않는다 — 한 사람의 생년월일이 여러 개 기록되어도 시스템이 깨지지 않는다.
4. SKOS 매핑을 사용한다 — 다른 온톨로지와의 연결에 owl:sameAs 대신 느슨한 SKOS 매핑을 쓴다.

4개의 핵심 클래스

SEM의 구조는 놀라울 정도로 단순하다. 4개의 핵심(Core) 클래스가 전부다.

각 핵심 클래스에는 대응하는 타입 클래스(Type Class) 가 있다:

타입 클래스가 별도로 존재하는 이유가 재밌다. 웹에는 수천 가지 어휘(vocabulary)가 존재하고, 각각 "타입"을 다르게 정의한다. SEM은 어떤 어휘의 타입이든 빌려 쓸 수 있도록 유연한 타입 시스템을 제공한다. DBpedia에서 "Police_action"이라는 이벤트 타입을 가져오고, Getty TGN에서 "republic"이라는 장소 타입을 가져와서 조합할 수 있는 것이다.

3부: SEM의 진짜 힘 — 관점(View)과 역할(Role)

SEM이 다른 이벤트 모델과 결정적으로 차별화되는 것은 속성 제약(Property Constraints) 시스템이다. 세 가지 제약이 있다: 역할(Role), 시간 제약(Temporary), 관점(View).

역사 속 논쟁으로 이해하는 SEM

이 개념들을 설명하기 위해, 논문이 사용하는 역사적 예시를 함께 살펴보자.

이 한 문장이 왜 이벤트 모델에게 도전적인지 분석해 보자.

대부분의 이벤트 모델은 이런 복잡성을 처리할 수 없다. "네덜란드 = 행위자"로 저장하면, 그 역할이 해방자인지 점령자인지 구분할 방법이 없다.

sem:Role — 맥락 속의 역할

sem:Role은 행위자가 특정 사건의 맥락에서 어떤 역할을 하는지를 정의한다.

핵심은 역할이 사건에 묶여 있다는 점이다. 네덜란드라는 국가가 영구적으로 "해방자"나 "점령자"인 것이 아니라, "이 사건의 맥락에서" 그 역할을 가지는 것이다. 다른 사건에서는 완전히 다른 역할을 가질 수 있다.

sem:View — 누구의 이야기인가

sem:View는 SEM에서 가장 독창적인 개념이다. 같은 사실에 대한 서로 다른 관점을 명시적으로 모델링한다.

sem:Authority는 특정 주장의 출처를 나타낸다. 반드시 행위자일 필요는 없다 — 데이터 소스 자체가 권위(authority)가 될 수도 있다. 이것은 출처 추적(provenance) 과 신뢰 추론(trust reasoning) 의 기반이 된다.

sem:Temporary — 시간이 바꾸는 진실

sem:Temporary는 속성의 시간적 유효 범위를 정의한다.

예를 들어, "인도네시아"라는 장소의 타입은 시간에 따라 달라진다:

이것이 바로 sem:Temporary가 해결하는 문제다. 사실은 영원하지 않다. 장소의 성격도, 사람의 직함도, 조직의 상태도 시간에 따라 변한다. SEM은 이런 시간 한정적 진실(time-bounded validity) 을 일급 시민(first-class citizen)으로 다룬다.

4부: 실전 사례 — 아덴만 해적 추적

SEM의 진가는 실전 적용에서 드러난다. 논문은 두 번째 사례로 소말리아 해적 사건 모델링을 소개한다.

배경: 아덴만의 위기

2006~2009년, 소말리아 해안의 아덴만(Gulf of Aden) 은 세계에서 가장 위험한 해역이었다. 국제상업회의소(ICC-CCS)는 피해 선박이 보고한 모든 해적 공격을 기록하고 있었다.

연구진은 ICC-CCS의 2006~2009년 해적 보고서를 크롤링하고, SEM API를 사용해 RDF로 변환했다. 각 해적 사건은 다음과 같이 구조화되었다:

Prolog API로 쉽게 만드는 SEM 인스턴스

SEM의 Prolog API는 사용이 놀라울 정도로 간단하다. 위의 해적 사건을 생성하는 코드:

% 이벤트 타입 설정: 납치
assert_event(ex:event_2008_164, ex:hijacked),

% 행위자: 요트형 익명 선박
assert_event_actor(ex:event_2008_164, -, ex:yacht),

% 장소: 좌표와 해상 타입
assert_event_location(ex:event_2008_164,
    -, ex:out_at_sea, point(9.5899, 51.635)),

% 시간: ISO 8601 형식
assert_event_time(ex:event_2008_164,
    literal(type(xsd:dateTime,
        '2008-08-04T03:00+0400Z'))).

이 몇 줄의 코드만으로 완전한 SEM RDF 그래프가 자동 생성된다. API가 모델의 구조를 알아서 처리하기 때문에, 사용자는 SEM의 클래스나 속성 이름을 외울 필요가 없다.

놀라운 발견: 안전 회랑의 역설

이렇게 구조화된 데이터를 SPARQL + 공간 추론으로 분석하자 흥미로운 패턴이 드러났다.

연구진은 Google Earth로 아덴만의 안전 통항 회랑(safety transit corridor) 좌표를 KML 형식으로 만들고, 이것을 SEM 데이터와 결합했다. 그 결과:

* 괄호 안 숫자는 실제 납치 성공 건수. 출처: van Hage et al., 2011, Table 1

이 발견은 SEM의 공간-시간 통합 추론 능력을 보여주는 강력한 사례다. 이벤트의 좌표, 시간, 유형을 하나의 프레임워크에서 다룰 수 있기 때문에 가능한 분석이었다.

5부: SEM의 건축학 — 세 가지 속성 제약 표현

SEM의 기술적 핵심 중 하나는 속성 제약을 세 가지 방식으로 표현할 수 있다는 점이다. 같은 의미를 다른 기술적 방식으로 표현하되, API가 이들 사이를 투명하게 번역해 준다.

이 세 가지 방식은 서로 다른 RDF 스토어와 도구에서 선호되는 패턴이 다르기 때문에 모두 지원된다. SEM API는 어떤 방식이든 통일된 인터페이스로 질의할 수 있게 해준다.

6부: 2026년, SEM이 우리에게 말하는 것

2011년에 발표된 SEM이 2026년인 지금 왜 중요할까?

Knowledge Graph의 르네상스

2023년부터 시작된 AI 붐은 역설적으로 구조화된 지식의 가치를 재확인시켰다. LLM은 놀라운 언어 능력을 보여주지만, 사실의 정확성(factual accuracy) 과 추론의 일관성(reasoning consistency) 에서 한계가 있다.

SEM의 설계 원칙이 AI 시대에 더 빛나는 이유

SEM이 15년 전에 채택한 설계 원칙들은 2026년의 AI 과제와 정확히 맞물린다.

현대적 적용: 이벤트 중심 지식 그래프

SEM의 정신을 이어받은 현대적 접근들이 여러 분야에서 활약하고 있다.

1. 디지털 인문학 (Digital Humanities)

역사적 사건을 SEM으로 모델링하면, "1945~1950년 동남아시아에서 일어난 모든 독립 운동을 찾아서, 각 운동에 대한 식민 본국의 관점과 독립 운동가의 관점을 비교해 줘"라는 복잡한 질의가 가능해진다.

2. 해양 안보 (Maritime Security)

논문에서 시연한 해적 추적 사례는 지금도 유효하다. 아덴만뿐 아니라, 말라카 해협, 기니만 등 전 세계 해적 위험 지역의 사건을 통합적으로 분석할 수 있다.

3. 뉴스 팩트체크

같은 뉴스 사건에 대한 다양한 보도를 SEM으로 구조화하면, 관점(View) 과 권위(Authority) 시스템으로 "이 주장은 어떤 출처에서 나왔는가"를 체계적으로 추적할 수 있다. LLM + SEM 조합은 자동화된 팩트체크의 유력한 후보다.

4. GraphRAG와의 결합

Microsoft의 GraphRAG가 텍스트에서 지식 그래프를 자동 추출하지만, 추출된 사건들의 구조를 표현하는 데는 아직 표준이 없다. SEM의 이벤트 모델을 GraphRAG 파이프라인에 통합하면, 더 풍부하고 질의 가능한 지식 그래프를 구축할 수 있다.

7부: SEM을 직접 만져보기 — 실습 가이드

SEM을 실제로 사용하려면 어떻게 할까? 논문에서 제공하는 Prolog API의 핵심 패턴을 현대적 관점에서 정리한다.

이벤트 생성 — assert 패턴

% 이벤트 + 행위자 + 행위자 타입을 한 번에 선언
assert_event_actor(
    ex:'FirstPoliceAction',  % 이벤트
    dbpedia:'Netherlands',   % 행위자
    wordnet:'government-1'). % 행위자 타입

이 한 줄의 Prolog 코드가 실행되면, API가 자동으로:

• ex:FirstPoliceAction이 rdf:type sem:Event임을 선언
• dbpedia:Netherlands가 rdf:type sem:Actor임을 선언
• wordnet:government-1이 rdf:type sem:ActorType임을 선언
• sem:hasActor 관계를 생성
• sem:actorType 관계를 생성

6개의 RDF 트리플이 자동 생성된다.

이벤트 질의 — query 패턴

% 요트가 관련된 모든 이벤트 찾기
event_actor(Event, Actor, ex:yacht).

% 결과: Event = ex:event_2008_164, Actor = _:anonymous_ship, ...

변수에 값을 넣으면 결과가 제한된다. -로 표시하면 "아무 값이나", _로 시작하면 "관심 없음"을 의미한다.

공간 추론 — space 패턴

% 특정 좌표에서 100km 이내의 모든 이벤트 찾기
event_location(Event, Place, _PlaceType),
space_nearest(Place, point(12.0, 45.0), 100).

% 특정 다각형(안전 회랑) 내부의 이벤트 찾기
event_location(Event, Place, _PlaceType),
space_within_range(Place, polygon(...)).

SEM API는 SWI-Prolog의 space 패키지와 통합되어, 공간 근접성 검색, 범위 내 포함 여부 검사 등의 지리 공간 추론을 지원한다.

맺으며: 단순함의 지혜

SEM의 이름에 "Simple"이 들어간 것은 겸손함이 아니라 의도적 설계다.

이 원칙은 소프트웨어 엔지니어링의 YAGNI(You Aren't Gonna Need It) 원칙과 놀라울 정도로 닮았다. 그리고 15년이 지난 지금, 이 선택은 옳았음이 증명되고 있다.

지식 그래프가 AI의 핵심 인프라로 부상하는 2026년, SEM이 2011년에 제시한 교훈은 여전히 유효하다:

세상의 모든 사건을 담을 수 있는 그릇은, 역설적으로 가장 단순한 그릇이었다.