하지만 그 동작 원리와 목적을 자세히 들여다보면 이 둘이 지향하는 방향은 완전히 다릅니다. 이 글에서는 겉보기에 비슷해 보이는 두 언어의 근본적인 차이점을 구체적으로 비교하고, 최근 기호주의(Symbolic) AI 및 지식 그래프 영역에서 왜 범용적인 Prolog를 제쳐두고 Datalog가 더욱 각광받고 있는지 그 명확한 이유를 정리해 보겠습니다.

너무 완벽해서 위험한 Prolog

Prolog는 1970년대에 등장한 논리 프로그래밍의 근간이 되는 언어입니다. 일반적인 프로그래밍 언어들이 보통 “A를 수행하고, 그다음 B를 수행하라”와 같이 순차적인 절차를 지시한다면, Prolog는 “이것은 사실(Fact)이고, 저것은 규칙(Rule)이다”라고 선언하는 데 그칩니다. 그러면 추론 엔진이 자체적으로 연산을 반복하며 해답을 도출해 냅니다.

Prolog는 완전한 튜링 머신(Turing-complete)이기 때문에 구현자가 구상하는 거의 모든 형태의 논리를 구현할 수 있습니다. 리스트와 같은 복잡한 자료구조를 자유롭게 다루며, 복잡한 재귀 알고리즘 또한 작성할 수 있습니다.

하지만 이처럼 ‘모든 것을 할 수 있다’는 점은 대규모 지식을 다뤄야 할 때 역설적으로 큰 제약으로 작용합니다. Prolog는 위에서 아래로 한 길만 끝까지 파고드는 깊이 우선 탐색(DFS) 방식으로 작동합니다. 그러다 보니 구현자가 규칙의 순서를 조금만 잘못 작성해도 시스템이 영원히 답을 찾지 못하고 무한 루프에 빠지기 일쑤입니다. 데이터 패턴이 수억 건에 달하는 방대한 지식 그래프 환경에서 이러한 예측 불가능성은 시스템의 치명적인 약점이 됩니다.

제약을 걸어 안전성을 확보한 Datalog

이러한 문제를 해결하기 위해 등장한 언어가 바로 Datalog입니다. Datalog는 직관적으로 표현하자면 ‘Light-weighted Prolog’라고 할 수 있습니다.

리스트 연산이나 복잡한 함수와 같은 강력한 기능들을 과감히 배제했습니다. 완전한 튜링 머신이 아니기 때문에 범용적인 애플리케이션을 처음부터 끝까지 독립적으로 구현해 낼 수는 없습니다. 하지만 이 강력한 기능들을 제외한 대신 Datalog는 매우 중요한 장점을 얻게 되었는데, 그것이 바로 종료의 보장(Termination) 입니다.

아무리 복잡한 질의(Query)를 수행하더라도 언젠가는 반드시 결론을 도출하고 시스템이 종료된다는 사실이 수학적으로 증명되어 있습니다. 따라서 작성자가 실수로 질의를 잘못 작성하더라도 서버 자원을 고갈시키는 무한 루프를 우려할 필요가 전혀 없습니다.

구체적인 예시: 그래프에서 경로(Path) 찾기

이 차이를 가장 명확하게 보여주는 예시가 바로 방향 그래프(Directed Graph)에서 두 지점 간의 경로를 탐색하는 문제입니다.

예를 들어, a -> b, b -> c, c -> a로 무한히 순환(Cycle)하는 그래프 구조가 존재한다고 가정해 보겠습니다. 이 상태에서 ‘X에서 Y로 가는 경로가 존재하는가?’를 확인하는 규칙을 작성해 보겠습니다.

Prolog의 경우 (무한 루프 발생)

path(X, Y) :- edge(X, Y).
path(X, Y) :- path(X, Z), edge(Z, Y).

Prolog에서 위와 같은 ‘좌측 재귀(Left-recursion)’ 형태로 규칙을 작성하고 순환 그래프를 탐색시키면 큰 문제가 발생합니다. Prolog는 위에서 아래로, 왼쪽부터 파고들기 때문에 끝없이 path(X, Z)를 재귀 호출하며 a -> b -> c -> a -> b... 순으로 영원히 연산을 반복하게 됩니다. 구현자가 이 함정을 회피하기 위해서는 규칙의 순서를 수동으로 조작하거나, 이미 방문한 노드를 일일이 리스트에 기록해 두는 등 복잡한 예외 처리 코드를 추가해야만 합니다.

Datalog의 경우 (항상 안전하게 종료)

Datalog의 문법은 Prolog와 동일하므로 앞선 코드를 그대로 사용할 수 있습니다.

path(X, Y) :- edge(X, Y).
path(X, Y) :- path(X, Z), edge(Z, Y).

하지만 Datalog 엔진은 전혀 다른 방식으로 작동합니다. 위에서 아래로 무작정 파고드는 대신, 이미 확보한 edge라는 사실(Fact)들로부터 출발하여 도출할 수 있는 모든 path를 바닥에서부터 한 번에 조립해 나갑니다(상향식 평가, Bottom-up Evaluation). 지속적으로 관계를 유추하다가 “더 이상 새로운 경로가 도출되지 않는” 순간(고정점, Fixed-point 도달) 시스템이 스스로 계산을 종료합니다.

순환 구조의 존재 여부나 질의의 작성 순서는 아무런 상관이 없습니다. “단순히 논리만 선언해 두면 알아서 실행을 멈추고 답을 찾아주는” 특성이 바로 Datalog가 가진 진정한 가치입니다.

지식 기반 AI가 Datalog를 선택하는 이유

최근 다시 부상하고 있는 Symbolic AI 생태계, 특히 전문가 시스템이나 룰 베이스, 대규모 지식 그래프 상에서 추론을 수행해야 할 때 기술적 대안으로 Datalog가 자주 언급됩니다. 그 이유는 아주 직관적(Intuitive)입니다.

첫째, 대규모 데이터 처리 구조에 매우 적합합니다. 현대 AI가 다루는 지식은 수천, 수만 건 단위에 그치지 않습니다. 시스템 로그, 소셜 데이터, 웹 스크랩 데이터 등 수백억 건의 데이터를 다룹니다. Prolog는 이러한 방대한 데이터를 연산하기엔 구조적인 성능 한계가 명확합니다. 반면 Datalog는 태생부터 대용량 데이터베이스와의 결합을 목적으로 설계되었습니다. 기본 사실들을 기반으로 차곡차곡 상위 논리를 유추해 내는 상향식 평가를 사용하여 대규모 데이터 셋에서의 복잡한 재귀 조인(Recursive Join)을 훨씬 더 효율적으로 처리합니다.

둘째, 구현자가 철저하게 ‘무엇(What)’을 도출할지에만 집중할 수 있게 해줍니다. 규칙이 수천 개로 늘어나면 사람이 이를 일일이 제어하며 무한 루프를 피하기란 불가능에 가깝습니다. Datalog 환경에서는 탐색의 순서나 실행 방법과 같은 ‘어떻게(How)’에 대한 부분을 엔진 내부의 질의 플래너(Query Planner)가 독자적으로 최적화합니다. 구현자는 데이터 간의 논리적 규칙만 선언형 텍스트로 명시해 두면 충분합니다.

마무리

Prolog가 인간의 완벽한 논리 추론 프로세스를 코드로 이식하고자 했던 이상적인 도구였다면, Datalog는 현실의 방대한 데이터 속에서 시스템 다운 없이 빠르고 정확하게 지식을 추출해 내기 위해 다양한 안전장치를 더한 실용적인 도구라 할 수 있습니다.

딥러닝이나 거대 언어 모델과 같은 통계적 방법론이 정답의 ‘확률’을 높이는 데 특화되어 있다면, 의료, 금융, 복잡한 접근 제어 모델링 등 100% 확실한 논리와 설명 가능성(Explainability)이 요구되는 영역에서는 제한적인 유연함을 대가로 완벽한 안정성을 취한 Datalog가 자신만의 확고한 입지를 구축하고 있습니다.

이번 글에서는 기수 정렬(Radix Sort)의 기본 개념에 대해 알아보고, 왜 Datalog 엔진에서 정렬 알고리즘이 필수적인지, 그리고 기존의 qsort에서 Radix Sort로 전환하여 어떤 성능적 이점을 기대하고 있는지 정리해 보았습니다.

기수 정렬 (Radix Sort)이란?

기수 정렬(Radix Sort)은 요소를 비교하지 않고 분산(Distribution)하여 정렬하는 알고리즘입니다. 일반적인 비교 기반 정렬 알고리즘(예: Quick Sort, Merge Sort)이 최소 $O(N \log N)$의 시간 복잡도를 가지는 반면, 기수 정렬은 정렬할 키의 크기가 제한적일 때 $O(dN)$ (이때 $d$는 데이터의 최대 자릿수)의 선형 시간에 가까운 속도로 정렬을 완료할 수 있습니다.

작동 방식

기수 정렬은 데이터의 가장 낮은 자릿수(LSD, Least Significant Digit)부터 가장 높은 자릿수(MSD, Most Significant Digit)까지, 혹은 그 반대로 각 자릿수를 기준으로 정렬을 반복합니다.

1. 초기화: 0부터 9까지(혹은 진법에 따른 기수만큼)의 버킷(Queue 등)을 준비합니다.
2. 분배: 정렬할 데이터의 일의 자리를 기준으로 각 버킷에 데이터를 넣습니다.
3. 병합: 0번 버킷부터 순서대로 데이터를 다시 가져옵니다.
4. 반복: 십의 자리, 백의 자리 등 가장 큰 자릿수까지 위 과정을 반복합니다.

이렇게 요소 간의 직접적인 크기 비교 없이 자릿수 기반의 버킷 배치를 통해 정렬을 수행하기 때문에, 정수나 문자열 같은 일정한 형식의 키를 가진 데이터를 정렬할 때 매우 강력한 성능을 발휘합니다.

Datalog 엔진 구현에서 정렬이 필요한 이유

Datalog는 선언형 논리 프로그래밍 언어로, 사실(Fact)과 규칙(Rule)을 기반으로 새로운 사실을 추론해 냅니다. 엔진 내부에서는 이러한 추론 과정이 주로 관계형 대수(Relational Algebra) 연산으로 변환되어 실행됩니다.

Datalog 엔진에서 데이터를 정렬해야 하는 주된 이유는 다음과 같습니다.

1. 중복 제거 (Deduplication) Datalog의 평가 과정(특히 Bottom-up 방식의 Semi-naïve Evaluation)에서는 매 반복마다 새롭게 생성된 데이터(Fact) 중에서 기존의 데이터와 겹치는 중복을 제거해야 합니다. 데이터가 정렬되어 있다면 선형 탐색 한 번만으로 중복된 튜플을 쉽게 걸러낼 수 있습니다.

2. 조인 연산 (Join) 보통 하나의 Rule은 여러 개의 Predicate(조건)가 엮여 있으며, 이를 모두 만족하는 해를 찾기 위해 조인 연산이 연속해서 일어납니다. 해시 조인(Hash Join)을 사용할 수도 있지만, 메모리 사용량을 예측 가능하게 유지하면서 높은 성능을 내기 위해 정렬 병합 조인(Sort-Merge Join)이 자주 활용됩니다. 데이터를 조인 키 기준으로 미리 정렬해두면 조인 처리가 매우 효율적입니다.

결과적으로 Datalog 엔진에서 데이터를 릴레이션 형태로 보관하고 연산할 때, 빠른 정렬은 엔진의 핵심 성능을 좌우하는 중요한 요소입니다.

QSort에서 Radix Sort로의 전환: 캐시 히트율 향상을 향한 기대

초기 Datalog 엔진(wirelog) 구현에서는 라이브러리에서 기본 제공하는 퀵 정렬(qsort 또는 std::sort)을 사용해왔습니다. Quick Sort는 평균적으로 $O(N \log N)$의 우수한 시간 복잡도를 가지며 범용적으로 가장 널리 쓰이는 정렬 방식입니다.

하지만 처리해야 할 일의 양과 사실(Fact) 데이터의 개수가 기하급수적으로 늘어나면서 Quick Sort의 한계가 나타나기 시작했습니다. 가장 큰 문제는 바로 캐시 히트율(Cache Hit Rate) 이었습니다.

Quick Sort는 피벗(Pivot)을 기준으로 배열의 양 끝에서부터 스왑(Swap) 연산을 수행하면서 재귀적으로 범위를 좁혀 들어갑니다. 데이터가 커져서 한 번에 CPU 캐시에 담을 수 있는 크기를 넘어서게 되면 메모리 접근 패턴은 무작위(Random)에 가까워집니다. 이로 인해 심각한 Cache Miss가 발생하기 시작하고, 결국 CPU 연산 시간보다 메모리에서 데이터를 퍼오는 데 걸리는 대기 시간이 정렬 연산의 병목이 됩니다.

반면, Radix Sort는 데이터를 버킷에 순차적으로 분배하고 다시 순차적으로 거두어들이는 패턴을 가집니다. 특히 데이터 엔진에서 주로 다루는 고정 크기의 정수형 키를 정렬할 때, 메모리에 대해서 연속적이고 예측 가능한 접근(Sequential Memory Access) 을 가능하게 합니다.

이러한 특성 덕분에 하드웨어 프리패처(Hardware Prefetcher) 동작에 매우 유리하며 다음 메모리 블록을 미리 캐시에 올려둘 수 있어, 결과적으로 캐시 히트율이 획기적으로 상승합니다.

마무리

현재 Datalog 엔진의 핵심 병목 중 하나였던 대용량 튜플의 정렬 단계를 기존의 qsort에서 Radix Sort 기반으로 교체하는 작업을 진행하고 있습니다(관련 이슈: justinjoy/wirelog#308). 연산 복잡도 자체의 감소($O(N \log N) \rightarrow O(dN)$)도 의미가 있지만, 무엇보다 메모리 계층 구조에 친화적인(Cache-friendly) 특성 덕분에 실제 하드웨어 최우선 과제인 캐시 히트율을 대폭 향상시켜 훨씬 더 빠른 쿼리 응답 속도를 얻을 수 있을 것으로 기대하고 있습니다. 향후 최적화가 완료되면 벤치마킹을 통해 얼마나 속도가 개선되었는지 다시 정리해 보도록 하겠습니다.

키워드 태깅의 한계: 단순한 문자열의 나열

우리가 흔히 쓰는 태깅은 텍스트를 있는 그대로 대조하는 문자열(String) 매칭에 불과합니다. 내가 ‘Datalog’라는 태그를 달았다고 해서 기계가 그것을 ‘선언형 논리 프로그래밍 언어’나 ‘Prolog의 일종’으로 이해하지는 않습니다. 그저 ‘D-a-t-a-l-o-g’라는 7개의 알파벳 조합으로 무미건조하게 받아들일 뿐이죠.

문자가 의미를 제대로 담지 못할 때 여러 답답한 상황이 벌어집니다. 당장 ‘Apple’이라는 태그만 봐도 이것이 과실을 뜻하는지 거대 IT 기업을 의미하는지 문맥 없이는 알 길이 없습니다. 게다가 ‘Datalog’와 ‘Logic Programming’이 서로 어떤 포함 관계인지도 파악하지 못하기 때문에, “논리 프로그래밍에 관한 노트를 다 찾아줘”라고 검색하면 정작 ‘Datalog’ 태그가 달린 핵심 노트들은 모조리 누락되고 맙니다. 기계 입장에서는 두 문자열이 완전히 배타적이기 때문입니다.

시맨틱 태깅이란?

시맨틱 태깅(Semantic Tagging)은 텍스트를 단순한 문자열이 아닌 개념(Concept)과 개체(Entity)로 연결하는 과정입니다. 태그를 다는 행위가 단순히 ‘이름표’를 붙이는 것이 아니라, 전 세계적으로 정의된 지식 체계(Ontology)나 개인의 지식 그래프에 해당 노드를 ‘위치’시키는 작업이 됩니다.

예를 들어, “Datalog”라는 단어에 시맨틱 태깅을 한다는 것은 다음과 같은 정보를 포함하는 것을 의미합니다.

• URI: https://www.wikidata.org/wiki/Q1191141 (Wikidata의 Datalog 항목)
• Type: Programming Language
• Subclass of: Declarative Programming, Logic Programming

이렇게 태깅된 데이터는 더 이상 고립된 섬이 아닙니다. 이미 정의된 거대한 지식의 네트워크(Linked Data)와 연결됩니다.

지식 그래프의 기초: 태그가 엣지가 되는 순간

시맨틱 태깅을 거치면, 우리의 노트 테이킹은 조금 다르게 동작하게 됩니다. 태그는 단순한 분류 도구가 아니라, 지식 그래프의 엣지(Edge)가 됩니다.

이 연결망이 구축되면, 우리는 “Datalog”라고 직접 태그하지 않은 노트라 할지라도, 그것이 논리 프로그래밍과 관련되어 있다는 사실을 시스템을 통해 찾아낼 수 있습니다. 태깅이 분류(Classification)에서 연결(Connection)로 진화하는 것입니다.

흩어진 메모가 지식의 그물망이 될 때

시맨틱 태깅이 적용된 환경에서는 검색의 차원이 달라집니다. “사과”를 검색하더라도 이것이 과일인지 기업인지 명확히 구분하여, 작성자의 본래 의도(Intent)에 부합하는 결과를 얻을 수 있습니다. 단순한 키워드 매칭이 아닌, 개념 기반의 탐색이 이루어지기 때문입니다.

이러한 맥락의 연결은 자연스럽게 자동화된 추론의 기반이 됩니다. 이 블로그에서 자주 다루는 Datalog나 RDF 같은 도구들을 사용할 수 밖에 없는 부분입니다. 데이터가 정보의 그물망 위에 시맨틱하게 엮여 있다면, 단방향 검색을 넘어 “20세기 후반에 등장한 논리 프로그래밍 언어 중, 현재 내가 학습 중인 것들은 무엇인가”와 같은 복합적인 질의를 시스템에 넘길 수 있게 됩니다.

Obsidian이나 Logseq처럼 개인 지식 관리(PKM) 도구를 깊게 활용하는 사람들에게도 이는 중요한 시사점을 던집니다. 매번 태그를 꼼꼼히 관리하고 노트를 수동으로 ‘분류’하는 수고를 크게 덜어주기 때문이죠. 새로운 메모를 올바른 개념 공간에 연결해두기만 하면, 시간이 흘러 쌓인 지식의 연결망 속에서 의미 있는 통찰이 자연스럽게 출현(Emergence)하게 됩니다.

LLM이 낮춘 지식 연결의 문턱

그렇다면 시맨틱 태깅은 어떻게 실천할 수 있을까요? 예전에는 사용자가 직접 복잡한 온톨로지(Ontology) 구조를 학습하고, 지루한 수작업으로 일일이 메타데이터를 입력해야만 했습니다. 개념의 정합성을 맞추는 일 자체가 거대한 노동이었죠.

이 견고했던 장벽은 거대 언어 모델(LLM)의 등장으로 빠르게 허물어지고 있습니다. LLM은 다듬어지지 않은 일상적인 글에서 핵심 개념을 짚어내고, 이를 적절한 지식 베이스의 URI와 매핑하는 작업에 놀라운 적성을 보입니다. 글쓴이가 무심코 메모를 남기기만 해도, 모델이 문맥을 소화하여 백그라운드에서 지식의 엣지를 이어붙이는 식입니다. 시맨틱 그래프를 엮어내는 비용이 극적으로 낮아진 셈입니다.

마치며: ‘정리’를 넘어 ‘추론’을 향해

결국 시맨틱 태깅은 ‘내 기록을 어떻게 다룰 것인가’에 대한 관점의 전환입니다. 정성껏 쓴 메모들을 그저 서랍장에 쌓아두는 데 만족할 것인지, 서로 관계를 맺고 새로운 결론을 엮어내는 동적인 지식 기반으로 키울 것인지의 선택이기도 합니다.

기계적인 키워드 분류는 언젠가 분명한 한계에 부딪히게 마련입니다. 파편화된 단어들의 늪에서 헤매지 않으려면, 이제는 단순 문자열의 나열이 아닌 ‘연결 가능한 의미’를 기록하는 연습을 시작해봐야 할 것입니다.

관련 글

• Datalog, 일상의 도구가 될 수 있을까
• Datalog 소개

특수한 도메인에서는 빛나지만

Datalog의 활용 사례를 찾으면 대부분 ‘특수한 도메인’에 집중되어 있습니다.

• 정적 프로그램 분석: 포인터 분석이나 데이터 흐름 분석에서 Datalog는 이미 검증된 도구입니다. Soufflé 같은 고성능 Datalog 엔진은 아예 이 용도에 최적화되어 있습니다.
• 보안 정책 검증: 접근 제어 규칙을 사실과 규칙으로 표현하고, 의도하지 않은 권한 경로가 존재하는지 추론하는 데 탁월합니다.
• 네트워크 구성 분석: 라우팅 테이블의 도달가능성을 재귀적으로 계산하는 것은 Datalog의 전형적인 적용 사례입니다.
• 온톨로지 추론: 지식 그래프 위에서 RDFS/OWL 규칙을 적용하여 암묵적 관계를 도출하는 데 사용됩니다.

이런 예제들은 만들기 어렵지 않습니다. 도메인 자체가 “사실과 규칙으로부터 새로운 사실을 도출한다”는 Datalog의 본질과 정확히 맞아떨어지기 때문입니다. 문제는 이런 사례들을 보여주면 돌아오는 반응이 늘 비슷하다는 점입니다.

“저는 컴파일러도 안 만들고, 보안 정책도 안 다루는데, 이걸 언제 쓰나요?”

이 질문에 선뜻 대답하기가 어렵습니다.

일상적 유즈케이스가 떠오르지 않는 이유

곰곰이 생각해보면, Datalog의 일상적 유즈케이스를 만들기 어려운 데는 구조적인 이유가 있습니다.

첫째, 일상의 데이터 문제는 대부분 SQL로 충분합니다. 테이블에서 조건에 맞는 행을 필터링하고, 집계하고, 조인하는 것—이것이 우리가 매일 하는 ‘데이터 작업’의 대부분입니다. SQL은 이 영역에서 반세기 넘게 검증된 도구이고, 생태계도 압도적입니다.

둘째, 재귀적 추론이 필요한 일상적 상황이 드뭅니다. Datalog가 SQL에 대해 가지는 가장 명확한 이점은 재귀(recursion)입니다. “조상의 조상”이나 “친구의 친구”를 재귀적으로 탐색하는 것은 Datalog의 강점이지만, 일상적인 데이터 작업에서 이런 패턴이 얼마나 자주 등장할까요? SQL의 WITH RECURSIVE가 어색하기는 하지만, 그마저도 필요한 상황 자체가 흔치 않습니다.

셋째, 도구의 접근성 문제가 있습니다. Python에서 Pandas 한 줄이면 해결되는 일에 Datalog 엔진을 별도로 설치하고 사실을 정의하고 규칙을 작성하는 것은 상당한 인지적 전환 비용을 수반합니다. 도구가 주는 가치가 전환 비용을 넘어서지 못하면 채택은 일어나지 않습니다.

그럼에도 가능성이 보이는 영역들

그래도 Datalog가 일상의 도구로 가치를 가질 수 있는 지점이 전혀 없는 것은 아닙니다. 최근에 떠올린 몇 가지 방향을 정리해봅니다.

1. 개인 지식 관리 (Personal Knowledge Management)

Obsidian이나 Logseq 같은 도구를 쓰면서 노트 사이의 관계를 [[링크]]로 연결하는 사람이 늘고 있습니다. 이 링크 그래프는 본질적으로 사실(Facts)의 집합입니다.

references("Datalog 소개", "논리 프로그래밍").
references("논리 프로그래밍", "Prolog").
tagged("Datalog 소개", "datalog").
tagged("논리 프로그래밍", "logic").

% 간접적으로 관련된 노트 찾기
related(X, Y) :- references(X, Y).
related(X, Y) :- references(X, Z), related(Z, Y).

% 같은 태그를 공유하는 노트 클러스터
cluster(X, Y) :- tagged(X, T), tagged(Y, T), X \= Y.

“이 노트와 간접적으로 연결된 노트가 뭐지?”, “내가 놓치고 있는 연결 고리가 있을까?”—이런 질문에 Datalog는 SQL보다 자연스러운 표현력을 제공합니다. 특히 노트가 수백 개를 넘어가면, 단순한 링크 그래프를 넘어 추론 기반의 지식 탐색이 의미를 가지기 시작합니다.

2. 의존성과 영향 분석

소프트웨어 프로젝트의 의존성 관리는 개발자의 일상입니다. 패키지 A가 B에 의존하고, B가 C에 의존할 때, C에 보안 취약점이 발견되면 영향받는 모든 패키지를 찾아야 합니다.

depends_on("my-app", "web-framework").
depends_on("web-framework", "http-lib").
depends_on("http-lib", "openssl").
vulnerable("openssl").

% 전이적 의존성
transitive_dep(X, Y) :- depends_on(X, Y).
transitive_dep(X, Y) :- depends_on(X, Z), transitive_dep(Z, Y).

% 취약한 패키지에 간접적으로 의존하는 모든 패키지
at_risk(X) :- transitive_dep(X, Y), vulnerable(Y).

물론 npm audit이나 pip-audit 같은 전용 도구가 이미 존재합니다. 하지만 Datalog의 장점은 규칙을 자유롭게 조합할 수 있다는 점에 있습니다. “이 모듈을 수정하면 영향받는 테스트는?”, “이 설정을 변경하면 어떤 서비스가 재시작되어야 하는가?”—이런 질문들은 모두 전이적 관계(transitive relation) 위에서의 도달가능성(reachability) 문제이고, Datalog는 이를 선언적으로 표현하는 데 최적화된 언어입니다.

3. 접근 권한의 선언적 관리

RBAC(Role-Based Access Control)은 어디에나 있습니다. 사내 시스템, 클라우드 인프라, 심지어 Google Drive의 공유 설정까지. 문제는 권한이 중첩되고 상속될 때 “이 사람이 이 리소스에 접근할 수 있는가?”라는 질문에 답하기가 점점 어려워진다는 것입니다.

role("김과장", "팀장").
role("이대리", "개발자").
inherits("팀장", "개발자").
permission("개발자", "코드저장소", "read").
permission("팀장", "코드저장소", "write").

% 역할 상속
has_role(User, Role) :- role(User, Role).
has_role(User, Role) :- role(User, R), inherits(R, Role).

% 최종 권한 계산
can_access(User, Resource, Action) :-
    has_role(User, Role),
    permission(Role, Resource, Action).

can_access("김과장", "코드저장소", "read")가 참인지를 확인하는 것은 단순한 조회가 아니라 추론입니다. 팀장 역할이 개발자 역할을 상속하고, 개발자에게 read 권한이 있으므로 김과장도 read 권한을 가집니다. 역할 계층이 깊어지고 조건이 복잡해질수록, 이런 추론을 SQL의 다중 조인으로 표현하는 것은 점점 고통스러워집니다. 실제로 Google의 Zanzibar나 Oso 같은 권한 관리 시스템이 내부적으로 Datalog 혹은 그와 유사한 추론 엔진을 채택한 것은 우연이 아닙니다.

4. 설정과 규칙의 검증

인프라 설정(Infrastructure as Code)이 복잡해지면, 설정 간의 일관성을 검증하는 것이 중요해집니다. “프로덕션 DB는 반드시 암호화가 활성화되어야 한다”, “외부에 노출된 서비스는 인증 미들웨어를 거쳐야 한다”—이런 정책을 Datalog 규칙으로 표현하고, 현재 설정(Facts)에 대해 위반 여부를 검증할 수 있습니다.

service("api-gateway", "external").
service("internal-api", "internal").
has_auth("api-gateway").

% 정책: 외부 서비스는 반드시 인증이 있어야 한다
violation(S) :- service(S, "external"), \+ has_auth(S).

OPA(Open Policy Agent)의 Rego 언어가 이미 이 영역에서 자리 잡고 있지만, Rego의 설계 자체가 Datalog의 영향을 강하게 받았습니다. 이는 “정책은 사실과 규칙의 문제”라는 Datalog의 세계관이 이 영역과 자연스럽게 맞아떨어진다는 것을 방증합니다.

Datalog가 일상의 도구가 되려면

이런 가능성에도 불구하고, Datalog가 일상의 도구로 자리 잡기 위해서는 여전히 넘어야 할 벽이 있습니다.

생태계와 통합의 문제입니다. SQL이 강력한 이유는 언어 자체의 표현력보다 PostgreSQL, MySQL 같은 성숙한 DBMS 생태계, 수십 년간 축적된 라이브러리, 그리고 모든 프로그래밍 언어에서의 네이티브 지원 때문입니다. Datalog에도 Soufflé, Differential Datalog, Naga 같은 구현체가 있지만, “pip install 하고 바로 쓴다”는 수준의 접근성에는 아직 거리가 있습니다.

결국 Datalog가 일상에 스며들려면, 그 자체로 독립적인 도구가 아니라 기존 워크플로우에 자연스럽게 녹아드는 형태가 되어야 할 것 같습니다. Rego가 Kubernetes 생태계에 녹아든 것처럼, 혹은 SQLite가 “서버 없는 임베디드 DB”로 어디에나 쓰이게 된 것처럼. 가벼운 임베디드 Datalog 엔진이 Python이나 JavaScript 한 줄로 호출되고, 일상적인 의존성 분석이나 권한 검증에 자연스럽게 사용되는 모습—그것이 Datalog가 일상의 도구가 되는 경로일 것입니다.

마치며

Datalog의 일상적 유즈케이스를 고민하면서 깨달은 것은, 이 질문 자체가 “이 도구는 누구를 위한 것인가”에 대한 근본적인 물음이라는 점입니다.

특수한 도메인에서 Datalog의 가치는 이미 증명되어 있습니다. 정적 분석, 보안, 네트워크—이 영역에서 Datalog를 대체할 도구를 찾기는 어렵습니다. 그러나 “일반적인 일상”이라는 맥락에서 Datalog는 아직 자신의 자리를 찾고 있는 중입니다.

어쩌면 Datalog의 진짜 일상적 유즈케이스는, 우리가 아직 “이건 Datalog 문제야”라고 인식하지 못하는 곳에 이미 숨어 있을지도 모릅니다. 의존성 트리를 따라가고, 권한 상속을 추적하고, 설정의 정합성을 검증하는 일—이 모든 것이 사실 “사실과 규칙으로부터 결론을 도출하는” 문제이니까요.

다음에는 이 고민을 코드로 풀어보겠습니다. 실제로 가벼운 Datalog 엔진을 일상적인 문제에 적용해보는 실험을 해볼 생각입니다.

관련 글

• SPARQL의 SQL 유사성이 주는 함정, 그리고 Datalog
• ASP와 Datalog: 논리 프로그래밍의 두 가지 시선
• Datalog의 증분 계산

스칼라(Scalar)와 SIMD, 그리고 NEON의 차이

• 스칼라(Scalar) 연산: 스칼라는 수학에서 방향성 없이 크기만 가지는 단일 값을 뜻합니다. 컴퓨팅 맥락에서 스칼라 연산은 한 번의 CPU 명령어(Instruction)로 단 한 개의 데이터 연산만 처리하는 아주 기본적이고 전통적인 방식을 의미합니다. 예를 들어 덧셈 명령을 내리면 단일 변수 두 개만 더합니다. 다량의 데이터 배열을 처리할 때는 원소 개수만큼 반복문을 수행해야 하므로 병목이 발생하기 쉽습니다.
• SIMD (Single Instruction Multiple Data): SIMD는 단 하나의 명령어(Single Instruction)로 여러 개의 데이터(Multiple Data)를 동시에 병렬로 연산하는 기법을 뜻하는 범용적인 개념입니다. 스칼라가 한 번에 단일 값을 처리할 때, SIMD는 큰 크기의 전용 레지스터(예: 128-bit) 내부에 여러 개의 데이터(예: 32-bit float 4개)를 패킹한 뒤, 덧셈 지시 한 번으로 4쌍의 요소를 한 번에 연산해 냅니다.
• NEON 연산: NEON(Advanced SIMD)은 ARM 아키텍처(Apple M1/M2, 안드로이드 AP 등) 내부에 탑재된 전용 SIMD 엔진 및 명령어 규격의 이름입니다. “SIMD”가 병렬 처리 모델을 뜻하는 넓은 의미의 기술 분류라면, “NEON”은 ARM에서 SIMD를 구체적으로 하드웨어 상에 구현해 둔 상표이자 규격명입니다. 만약 x64/x86 진영(Intel, AMD)의 CPU라면 NEON이 아닌 SSE나 AVX라는 이름의 SIMD 명령어 셋을 사용하게 됩니다.

서버 시장은 보통 x64 환경이 지배적이었지만, 최근에는 모바일뿐만 아니라 Mac(Apple Silicon)이나 AWS Graviton 같은 ARM 기반 프로세서의 점유율이 높아지고 있습니다. 따라서 연산 집약적인 코어 모듈을 C/C++로 작성하실 때는, 동일한 동작을 C 코드로 작성하되 Intel/AMD에서는 SSE/AVX가 실행되고 ARM에서는 NEON이 실행되도록 코드를 분기 처리해 주는 것이 매우 중요해졌습니다.

이번 글에서는 C언어를 이용해 1억 개(100 Million)의 float 배열 두 개의 내적(Dot Product)을 구하는 연산을 수행하면서, 하나의 코드베이스로 x86의 SSE/AVX와 ARM의 NEON을 동시에 지원하도록 작성하는 방법, 그리고 실제 Mac M1 (ARM NEON) 환경에서 벤치마크를 돌렸을 때 어느 정도의 속도 차이가 나는지 비교해보겠습니다.

스칼라 vs 파이프라인 (SIMD, NEON) 코드 작성법

C/C++에서 아키텍처에 따라 SIMD 명령어를 다르게 적용하려면 전처리기 매크로(#if defined(...))를 사용하여 분기하고, 각 아키텍처에 맞는 헤더 파일과 데이터 타입, Intrinsic 함수들을 사용해야 합니다.

아래는 1억 개의 요소를 갖는 내적 연산 예제 코드입니다.

#include <stdio.h>
#include <stdlib.h>
#include <time.h>

// 아키텍처에 따른 헤더 파일 및 매크로 분기
#if defined(__x86_64__) || defined(_M_X64)
#include <immintrin.h> // For SSE/AVX
#define SIMD_NAME "SSE/AVX"
#elif defined(__aarch64__) || defined(_M_ARM64)
#include <arm_neon.h>  // For NEON
#define SIMD_NAME "NEON"
#else
#define SIMD_NAME "Unknown"
#endif

#define ARRAY_SIZE 100000000
#define NUM_RUNS 10

float a[ARRAY_SIZE];
float b[ARRAY_SIZE];

// 1. 일반적인 스칼라 (Scalar) 연산
float dot_product_scalar(const float* x, const float* y, size_t size) {
    float sum = 0.0f;
    // 컴파일러의 자동 벡터화(Auto-vectorization)를 방지하여 순수 스칼라 성능을 측정
    #pragma clang loop vectorize(disable)
    #pragma GCC ivdep
    for (size_t i = 0; i < size; ++i) {
        sum += x[i] * y[i];
    }
    return sum;
}

// 2. SIMD (SSE / NEON) 연산
float dot_product_simd(const float* x, const float* y, size_t size) {
    float sum = 0.0f;
    size_t i = 0;

#if defined(__x86_64__) || defined(_M_X64)
    // [x86/x64 SSE 버전] (한 번에 4개의 float 처리)
    __m128 v_sum = _mm_setzero_ps(); // 4개의 float를 0으로 초기화
    for (; i + 3 < size; i += 4) {
        __m128 v_x = _mm_loadu_ps(&x[i]);
        __m128 v_y = _mm_loadu_ps(&y[i]);
        v_sum = _mm_add_ps(v_sum, _mm_mul_ps(v_x, v_y));
    }
    // 4개의 부분합을 하나로 합침
    float temp[4];
    _mm_storeu_ps(temp, v_sum);
    sum += temp[0] + temp[1] + temp[2] + temp[3];

#elif defined(__aarch64__) || defined(_M_ARM64)
    // [ARM NEON 버전] (한 번에 4개의 float 처리)
    float32x4_t v_sum = vdupq_n_f32(0.0f); // 4개의 float를 0으로 초기화
    for (; i + 3 < size; i += 4) {
        float32x4_t v_x = vld1q_f32(&x[i]);
        float32x4_t v_y = vld1q_f32(&y[i]);
        // vmlaq_f32: Multiply-Accumulate (v_sum += v_x * v_y)
        v_sum = vmlaq_f32(v_sum, v_x, v_y); 
    }
    // 부분합을 모두 더해 스칼라로 반환
    sum += vaddvq_f32(v_sum);
#endif

    // 4의 배수로 떨어지지 않고 남은 요소(Tail 처리)를 스칼라로 계산
    for (; i < size; ++i) {
        sum += x[i] * y[i];
    }
    
    return sum;
}

int main() {
    printf("Initializing arrays...\n");
    for (size_t i = 0; i < ARRAY_SIZE; ++i) {
        a[i] = (float)(i % 100) / 100.0f;
        b[i] = (float)(i % 100) / 100.0f;
    }

    struct timespec start, end;
    double time_scalar = 0.0, time_simd = 0.0;
    float result_scalar = 0.0f, result_simd = 0.0f;

    // 스칼라 벤치마크 (10회 평균)
    for (int run = 0; run < NUM_RUNS; ++run) {
        clock_gettime(CLOCK_MONOTONIC, &start);
        result_scalar = dot_product_scalar(a, b, ARRAY_SIZE);
        clock_gettime(CLOCK_MONOTONIC, &end);
        time_scalar += (end.tv_sec - start.tv_sec) + 1e-9 * (end.tv_nsec - start.tv_nsec);
    }
    time_scalar /= NUM_RUNS;

    // SIMD 벤치마크 (10회 평균)
    for (int run = 0; run < NUM_RUNS; ++run) {
        clock_gettime(CLOCK_MONOTONIC, &start);
        result_simd = dot_product_simd(a, b, ARRAY_SIZE);
        clock_gettime(CLOCK_MONOTONIC, &end);
        time_simd += (end.tv_sec - start.tv_sec) + 1e-9 * (end.tv_nsec - start.tv_nsec);
    }
    time_simd /= NUM_RUNS;

    char simd_res_label[32];
    sprintf(simd_res_label, "%s Result", SIMD_NAME);
    char simd_time_label[32];
    sprintf(simd_time_label, "%s Time", SIMD_NAME);

    printf("------------------------------------\n");
    printf("Architecture : %s\n", SIMD_NAME);
    printf("Scalar Result: %.2f\n", result_scalar);
    printf("%-13s: %.2f\n", simd_res_label, result_simd);
    printf("Scalar Time  : %.5f sec\n", time_scalar);
    printf("%-13s: %.5f sec\n", simd_time_label, time_simd);
    printf("Speedup      : %.2f x\n", time_scalar / time_simd);
    printf("------------------------------------\n");

    return 0;
}

Mac M1 (NEON) 벤치마크 결과 비교

위 코드를 Apple Silicon(M1) 칩을 탑재한 맥에서 clang -O3 최적화 플래그를 주어 컴파일 후 실행한 결과입니다.

Initializing arrays...
Benchmarking scalar...
Benchmarking NEON...
------------------------------------
Architecture : NEON
Scalar Result: 16777216.00
NEON Result  : 31929088.00
Scalar Time  : 0.02787 sec
NEON Time    : 0.00507 sec
Speedup      : 5.50 x
------------------------------------

결과 분석

1. 성능 향상 (Speedup): 스칼라 버전은 평균 0.027초, NEON을 활용한 코드는 0.005초가 걸리며 약 5.5배의 성능 향상을 보였습니다. 4개의 float를 한 번에 연산할 뿐 아니라 vmlaq_f32를 통해 곱셈과 덧셈(MAC 연산)을 명령어 단 하나로 처리하기 때문에 극한의 성능 이득을 얻을 수 있었습니다.
2. 연산 결과의 차이 (Accumulation Error): 아마 결과를 보시고 “계산 결과가 맞나?” 하는 의문이 드셨을 수 있습니다. 실제로 저 1억 개 배열의 내적을 수학적으로 오차 없이 식행하면(double 정밀도 기준) 정확한 정답은 32,835,000 부근이 나와야 합니다. 하지만 32비트 부동소수점(float)을 하나의 변수에 선형적으로 계속 더하는 스칼라 방식에서는, 누적합이 16,777,216 (즉, $2^{24}$)에 도달하는 순간 1.0 미만의 소수점 단위 값들을 더해도 유효숫자(정밀도) 범위를 벗어나 아예 더해지지 않고 무시되어 버립니다. 그래서 스칼라 버전의 결과는 기계적으로 정확히 16777216.00에서 멈춰버린 것입니다. 반면 NEON 코드에서는 누적합을 4개의 전용 레지스터로 쪼개어 독립적인 부분합(Partial Sum)을 구하기 때문에, 각 레지스터마다 숫자가 천천히 커지게 되어 오차가 누적되고 소실되는 시점이 훨씬 늦어집니다. 그 덕분에 기계적 한계 내에서도 정답(32,835,000)에 훨씬 가까운 31,929,088.00 이라는 결괏값을 훨씬 빠르고 정확하게 계산해 낼 수 있었습니다. 데이터가 방대해질수록 이처럼 분할 정복 성격을 띠는 SIMD가 속도뿐 아니라 실질적인 부동소수점 연산 정밀도 면에서도 더 나은 결과를 줍니다.

마치며

이렇듯 무거운 배열 연산이나 행렬 연산, 딥러닝 추론 등의 코어 루틴에서는 SIMD 사용 유무가 수 배 이상의 극적인 성능 차이를 만듭니다. 크로스 플랫폼 개발을 하신다면, 위 코드의 예시처럼 매크로로 분기하여 Intel/AMD에서는 SSE/AVX를, ARM 계열에서는 NEON을 각각 호출하도록 대응하면 어떠한 빌드 환경에서도 극강의 퍼포먼스를 내는 애플리케이션을 작성할 수 있습니다.

이번에는 유사한 상황에서 Reification이 답이 아닌 상황, 그래서 Named Graph를 사용해야 하는 상황이 있다는 것을 이야기해보려고 합니다.

Knowledge Graph를 구축하다 보면, 서로 다른 출처에서 가져온 데이터가 충돌하는 상황을 자주 만납니다. 앞의 Reification에서 다룬 예시와 유사하지만, 이번에는 Reification이 답이 아닌 상황을 다룹니다.

헤드헌터가 김철수의 인재 데이터베이스를 조회하니 다음과 같은 정보가 나옵니다.

HR 시스템: 김철수는 네이버 재직 중 LinkedIn 프로필: 김철수는 삼성전자 Senior Engineer

두 출처가 서로 다른 이야기를 합니다. LinkedIn 프로필은 이직 후 업데이트되지 않았을 가능성이 높지만, 데이터만 보면 구분이 안 됩니다. 어느 쪽을 믿어야 할까요?

기본 RDF 트리플로 표현하면 이렇게 됩니다.

ex:김철수 ex:worksAt ex:네이버 .
ex:김철수 ex:worksAt ex:삼성전자 .

Reification을 사용하면 각 트리플에 ex:source "HR 시스템", ex:source "LinkedIn" 같은 메타데이터를 붙일 수 있습니다. 하지만 현실의 Knowledge Graph에는 수만, 수억 개의 트리플이 있고, 하나하나 Reify하면 트리플 수가 4~7배로 폭발합니다.

더 중요한 문제는, 출처는 개별 트리플이 아니라 데이터셋 단위의 속성이라는 점입니다. HR 시스템에서 가져온 1만 개의 트리플은 모두 “HR 시스템에서 2026년 2월 20일에 수집”이라는 출처 정보를 공유합니다. 각 트리플마다 같은 출처 정보를 중복해서 붙일 필요가 없습니다. 즉, 이러한 경우에는 Reification은 적절한 해결책이라고 할 수 없습니다.

여기서 Named Graph가 등장합니다. 트리플을 개별적으로 관리하는 대신, 관련된 트리플들을 하나의 그래프로 묶고, 그 그래프에 출처 정보를 부여하는 방식입니다.

2. Named Graph란 무엇인가

RDF의 기본 단위는 트리플(Triple): 주어(Subject) – 술어(Predicate) – 목적어(Object)입니다. Named Graph는 여기에 네 번째 요소를 추가합니다. 바로 그래프 이름(Graph Name)입니다.

트리플 하나에 그래프 이름을 더하면 쿼드(Quad, S-P-O-G)가 됩니다. 같은 그래프 이름을 가진 쿼드들을 모으면 하나의 Named Graph가 됩니다. 그리고 이 Named Graph는 IRI로 식별되는 자원이므로, 그래프 자체에 대해 “출처는 어디인가”, “언제 수집했는가”, “신뢰도는 얼마인가” 같은 메타데이터를 붙일 수 있습니다.

RDF 1.1[1]에서는 이를 RDF Dataset이라는 구조로 정의합니다. RDF Dataset은 하나의 Default Graph(이름이 없는 기본 그래프)와 0개 이상의 Named Graph로 구성됩니다.

비유하자면, 개별 서류(트리플)에 하나하나 도장을 찍는 것(Reification)이 아니라, 서류를 폴더(Named Graph)에 넣고 폴더 겉표지에 “출처: HR팀, 수집일: 2026-02-20, 신뢰도: 높음”이라고 적는 것입니다. 폴더 안의 모든 서류는 자동으로 같은 출처 정보를 공유합니다.

3. TriG 문법으로 표현하기

Named Graph를 표현하는 표준 문법이 TriG[2]입니다. TriG는 Turtle의 확장으로, GRAPH_IRI { ... } 블록으로 트리플을 그래프에 묶을 수 있습니다.

김철수 시나리오를 TriG로 표현해 보겠습니다.

@prefix ex:  <http://example.org/> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .

# ── HR 시스템에서 가져온 데이터 (Named Graph 1) ──
ex:graph/hr {
    ex:김철수 a ex:Person ;
        ex:name "김철수" ;
        ex:worksAt ex:네이버 .

    ex:네이버 a ex:Company ;
        ex:name "네이버" .
}

# ── LinkedIn에서 크롤링한 데이터 (Named Graph 2) ──
ex:graph/linkedin {
    ex:김철수 ex:worksAt ex:삼성전자 ;
        ex:jobTitle "Senior Engineer" .

    ex:삼성전자 a ex:Company ;
        ex:name "삼성전자" .
}

# ── 그래프 메타데이터 (Default Graph에 기록) ──
ex:graph/hr
    ex:source      "사내 HR 시스템" ;
    ex:retrievedAt "2026-02-20"^^xsd:date ;
    ex:trustLevel  3 .

ex:graph/linkedin
    ex:source      "LinkedIn 크롤링" ;
    ex:retrievedAt "2026-01-15"^^xsd:date ;
    ex:trustLevel  2 .

핵심을 정리하면 이렇습니다.

• ex:graph/hr { ... } 블록 안의 모든 트리플은 ex:graph/hr라는 Named Graph에 속합니다.
• 그래프 이름(ex:graph/hr, ex:graph/linkedin) 자체도 IRI이므로, Default Graph에서 이들에 대한 메타데이터를 기술할 수 있습니다.
• trustLevel을 숫자로 표현하여, 신뢰도 순서를 명확히 할 수 있습니다. 3(높음), 2(중간)처럼 숫자가 클수록 신뢰도가 높습니다.

TriG는 Turtle을 아는 사람이라면 쉽게 배울 수 있습니다. Turtle 문법에 { } 블록만 추가하면 됩니다.

4. 시각화: Named Graph가 만드는 구조

아래 다이어그램은 Named Graph가 적용된 김철수의 프로필 데이터를 시각화한 것입니다. 두 개의 독립된 그래프가 각각의 출처 정보와 함께 관리되는 구조를 보여줍니다.

두 개의 Named Graph(ex:graph/hr, ex:graph/linkedin)가 점선 경계로 구분되어 있습니다. 각 그래프는 독립된 트리플 집합이며, Default Graph에 기록된 메타데이터를 통해 출처, 수집 시점, 신뢰도 정보를 가집니다. 이 구조 덕분에 같은 개체(김철수)에 대한 서로 다른 정보를 출처별로 분리하여 관리할 수 있습니다.

5. SPARQL로 질의하기: GRAPH의 힘

Named Graph의 진가는 SPARQL[3]에서 정의하는 GRAPH 키워드를 사용할 때 드러납니다. GRAPH 패턴을 사용하면 “어느 Named Graph 안에서” 트리플을 매칭할지 지정할 수 있습니다.

쿼리 1: 신뢰도 높은 출처에서 김철수의 현재 직장 찾기

PREFIX ex: <http://example.org/>

SELECT ?company ?source ?trust WHERE {
    GRAPH ?g {
        ex:김철수 ex:worksAt ?company .
    }
    ?g ex:trustLevel ?trust .
    ?g ex:source     ?source .
}
ORDER BY DESC(?trust)

결과:

GRAPH ?g { ... } 패턴은 “어떤 Named Graph 안에서든” 패턴에 매칭되는 트리플을 찾습니다. 그래프 변수 ?g를 통해 그래프의 메타데이터(trustLevel, source)에 접근할 수 있습니다. ORDER BY DESC(?trust)로 신뢰도가 높은 순서로 정렬하면, 가장 믿을 만한 정보가 먼저 나옵니다. 이제 헤드헌터는 “네이버”를 김철수의 현재 직장으로 판단할 수 있습니다.

쿼리 2: 특정 출처의 데이터만 조회

PREFIX ex: <http://example.org/>

SELECT ?s ?p ?o WHERE {
    GRAPH ex:graph/hr {
        ?s ?p ?o .
    }
}

그래프 IRI를 직접 지정하면, 해당 출처의 데이터만 필터링할 수 있습니다. 수억 개의 트리플이 있어도 그래프 단위로 범위를 좁힐 수 있으므로, 쿼리 성능에도 유리합니다. “HR 시스템이 말하는 정보만 보고 싶다”는 요구사항을 단 한 줄의 GRAPH 절로 해결할 수 있습니다.

쿼리 3: 오래된 출처 데이터 탐지

PREFIX ex:  <http://example.org/>
PREFIX xsd: <http://www.w3.org/2001/XMLSchema#>

SELECT DISTINCT ?g ?source ?date WHERE {
    GRAPH ?g { ?s ?p ?o . }
    ?g ex:retrievedAt ?date ;
       ex:source      ?source .
    FILTER (?date < "2026-02-01"^^xsd:date)
}

이 쿼리는 2월 1일 이전에 수집된 그래프를 찾습니다. LinkedIn 그래프(2026-01-15 수집)가 결과에 나타나므로, “이 데이터는 오래되었으니 재수집이 필요하다”는 판단을 내릴 수 있습니다. Named Graph는 단순히 출처를 기록하는 것을 넘어, 데이터의 신선도(freshness)를 관리하는 도구가 됩니다.

6. Reification과 Named Graph: 언제 무엇을

이전 글에서 배운 Reification과 Named Graph는 경쟁이 아니라 보완 관계입니다. 두 기법이 해결하는 문제가 다르기 때문입니다.

언제 무엇을 사용할 것인가?

• 특정 트리플 하나에 세밀한 시간 정보나 확신도를 붙여야 한다면 → Reification (또는 RDF-star)
• 데이터셋 전체 또는 일부를 출처, 버전, 접근 권한 단위로 관리해야 한다면 → Named Graph
• 실무에서는 두 기법을 함께 사용하는 것이 일반적입니다. 예를 들어, Named Graph로 출처를 관리하면서, 그 안의 특정 트리플에만 Reification을 적용하여 추가 맥락을 기록할 수 있습니다.

7. 실전 활용: 버전, 접근 제어, 신뢰

Named Graph는 실무 Knowledge Graph에서 다양한 방식으로 활용됩니다. 대표적인 세 가지 사례를 소개합니다.

7.1 데이터 버전 관리 (Temporal Snapshots)

시점마다 Named Graph를 만들어 스냅샷을 관리할 수 있습니다. 예를 들어 ex:graph/employees/2026-Q1, ex:graph/employees/2025-Q4처럼 분기별 그래프를 두면, 특정 시점의 조직도를 통째로 조회하거나, 시점 간 변화를 비교할 수 있습니다. 이는 “이번 분기에 누가 입사했는가”나 “작년 대비 팀 구성이 어떻게 변했는가” 같은 질문에 답하는 데 유용합니다.

7.2 접근 제어 (Access Control)

Named Graph 단위로 읽기/쓰기 권한을 설정할 수 있습니다. 예를 들어 ex:graph/public은 누구나 조회 가능, ex:graph/internal은 사내 직원만, ex:graph/hr-confidential은 HR팀만 접근 가능하도록 설정합니다. GraphDB나 Stardog 같은 트리플스토어에서는 그래프 단위 ACL(Access Control List)을 지원하므로, 민감한 데이터를 별도 그래프로 분리하여 보호할 수 있습니다.

다만 주의할 점이 있습니다. 모든 트리플스토어가 Named Graph를 물리적으로 분리하여 저장하는 것은 아닙니다. 예를 들어 Apache Jena의 TDB 엔진은 모든 그래프의 트리플을 동일한 인덱스에 저장하므로, Named Graph 이름만으로는 물리적 접근 제어가 보장되지 않습니다. Named Graph 기반 접근 제어를 도입할 때는 사용하는 트리플스토어의 구현 방식을 반드시 확인해야 합니다.

7.3 신뢰 점수 기반 추론 (Trust-aware Reasoning)

앞의 김철수 시나리오가 정확히 이 패턴입니다. 여러 출처가 상충하는 정보를 제공할 때, 각 그래프에 trustLevel을 부여하고, 추론 엔진이나 쿼리 로직이 신뢰도가 높은 쪽을 우선하도록 설계할 수 있습니다. 이는 외부 크롤링 데이터, 사용자 입력, 자동 추론 결과 등 신뢰도가 다른 데이터 소스를 통합할 때 필수적입니다.

8. 마치며

Reification이 “트리플에 대해 말하기”였다면, Named Graph는 “트리플 묶음에 이름을 붙이기”입니다. 현실 세계의 데이터는 항상 어딘가에서 옵니다. 누가 만들었는지, 언제 수집했는지, 얼마나 믿을 수 있는지. Named Graph는 이 질문들에 답할 수 있는 구조를 RDF에 부여합니다.

하지만 기법을 아는 것보다 더 중요한 것은, 어디에 온톨로지를 적용할 것인가를 결정하는 일입니다. Reification이든 Named Graph든, 결국 도메인 지식을 바탕으로 “이 데이터에서 무엇이 중요한가”, “어떤 맥락을 보존해야 하는가”를 판단하는 것이 온톨로지 설계의 핵심입니다. 기법은 도구일 뿐, 도메인에 대한 깊은 이해 없이는 어떤 도구도 올바르게 쓸 수 없습니다.

서로 다른 출처의 정보를 통합할 때, “어느 쪽을 믿어야 하는가”라는 질문에 부딪혔다면 Named Graph를 떠올려 보세요. 트리플을 그래프 단위로 묶는 순간, Knowledge Graph는 비로소 신뢰의 경계를 그을 수 있게 됩니다.

관련 글

• 시간이 흐르면 사실도 변한다: RDF Reification으로 맥락 기록하기
• S-P-O 분해 연습문제 풀이: 전력 모듈-센서 노이즈 간섭
• iCalendar의 진화: 텍스트에서 의미론적 웹으로

참고 문헌

1. R. Cyganiak, D. Wood, and M. Lanthaler, “RDF 1.1 Concepts and Abstract Syntax,” W3C, W3C Recommendation, Feb. 2014. Available at: https://www.w3.org/TR/rdf11-concepts/
2. G. Carothers and A. Seaborne, “RDF 1.1 TriG: RDF Dataset Language,” W3C, W3C Recommendation, Feb. 2014. Available at: https://www.w3.org/TR/trig/
3. S. Harris and A. Seaborne, “SPARQL 1.1 Query Language,” W3C, W3C Recommendation, Mar. 2013. Available at: https://www.w3.org/TR/sparql11-query/

Knowledge Graph를 구축하다 보면, 시간의 흐름에 따라 변하는 사실을 기록해야 하는 순간이 반드시 찾아옵니다. 간단한 예를 들어보겠습니다.

김철수는 2020년부터 2022년까지 삼성전자에서 근무했고, 2023년부터 현재까지 네이버에서 근무하고 있다.

사람이 읽으면 명확합니다. 하지만 이것을 RDF 트리플로 표현하면 어떻게 될까요?

ex:김철수 ex:worksAt ex:삼성전자 .
ex:김철수 ex:worksAt ex:네이버 .

이 두 트리플만 보면 다음과 같은 질문에 답할 수 없습니다.

• 김철수는 지금 어디에서 일하는가?
• 삼성전자에는 언제부터 언제까지 다녔는가?
• 두 회사에 동시에 다닌 것인가, 순서대로 다닌 것인가?

이 문제의 핵심은, RDF 트리플이 주어(Subject) – 술어(Predicate) – 목적어(Object)의 세 요소만으로 구성되어 있어 “언제”, “누가 말했는지”, “확실한가” 같은 맥락(Context)을 붙일 자리가 없다는 점입니다.

2. 우회로는 왜 안 되는가?

Reification을 알기 전에, 흔히 시도하는 우회 방법들이 왜 실패하는지 먼저 살펴봅시다.

2.1 술어에 시간을 녹이기

ex:김철수 ex:worksAt_2020_2022 ex:삼성전자 .
ex:김철수 ex:worksAt_2023_now  ex:네이버 .

연도를 술어(Predicate) 이름에 포함시키면 되지 않을까요? 기술적으로는 동작하지만, SPARQL로 질의할 수가 없습니다. “김철수가 근무한 모든 회사”를 찾으려면 ex:worksAt로 시작하는 술어를 전부 패턴 매칭해야 하는데, 이는 표준 SPARQL이 지원하지 않는 방식입니다. 술어의 이름 자체가 데이터가 되어 버리면, 온톨로지의 스키마와 인스턴스가 뒤섞여 관리가 불가능해집니다.

2.2 리터럴에 날짜 병기

ex:김철수 ex:worksAt "삼성전자 (2020-2022)" .

목적어를 URI 대신 문자열 리터럴로 바꾸고, 날짜를 같이 넣는 방법입니다. 이렇게 하면 ex:삼성전자라는 자원과의 연결이 끊어집니다. “삼성전자에 근무하는 모든 사람”을 찾으려면 문자열 파싱을 해야 하고, 삼성전자라는 개체에 연결된 다른 정보(위치, 업종 등)에 접근할 수 없게 됩니다. 의미(Semantics)가 문자열 안에 갇혀 버리는 것입니다.

2.3 중간 노드 만들기 (N-ary Relation)

ex:김철수 ex:hasEmployment ex:Employment_1 .
ex:Employment_1 ex:company   ex:삼성전자 ;
                ex:startDate "2020-01-01"^^xsd:date ;
                ex:endDate   "2022-12-31"^^xsd:date .

이 방법은 실무에서 자주 사용되며, 실제로 잘 동작합니다. 하지만 원래의 worksAt라는 직관적인 관계가 사라지고, hasEmployment → company라는 2-hop 경로로 대체됩니다. 이는 기존 온톨로지와의 호환성을 깨뜨리고, “김철수가 근무하는 회사”라는 단순한 질문에도 중간 노드를 경유하는 복잡한 쿼리가 필요해집니다.

세 가지 시도 모두 한계를 가지는 이유는 근본적으로 같습니다. 트리플 자체에 대한 메타데이터를 트리플 구조 안에서 표현하려 하기 때문입니다. 여기서 Reification이 등장합니다.

3. Reification: 트리플에 대해 말하기

Reification(구체화)은 하나의 트리플을 그 자체로 하나의 자원(Resource)으로 만드는 기법입니다. 쉽게 말해, “김철수가 삼성전자에서 근무한다”라는 진술(Statement) 자체에 이름을 붙여, 그 진술에 대해 추가적인 설명을 할 수 있게 하는 것입니다.

RDF[1]에서는 이를 위해 네 가지 어휘를 제공합니다.

즉, 원래 트리플 ex:김철수 ex:worksAt ex:삼성전자를 다음과 같이 “풀어서” 표현합니다.

ex:stmt1 a rdf:Statement ;
    rdf:subject   ex:김철수 ;
    rdf:predicate ex:worksAt ;
    rdf:object    ex:삼성전자 .

이제 ex:stmt1은 하나의 자원이므로, 여기에 시간 정보를 자유롭게 붙일 수 있습니다.

ex:stmt1 ex:startDate "2020-01-01"^^xsd:date ;
         ex:endDate   "2022-12-31"^^xsd:date ;
         ex:source    ex:HR_Database .

핵심을 정리하면 이렇습니다. 기본 트리플은 사실을 진술합니다. Reification은 그 진술 자체를 자원으로 만들어, 진술에 대한 진술을 가능하게 합니다. 이것이 “트리플에 대해 말하기”의 본질입니다.

4. 김철수의 이직 기록: Reification 적용

이제 처음의 문제를 Reification으로 완전히 해결해 보겠습니다.

@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix ex:  <http://example.org/> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .

# ── 개체 정의 ──
ex:김철수 a ex:Person ;
    ex:name "김철수" .

ex:삼성전자 a ex:Company ;
    ex:name "삼성전자" .

ex:네이버 a ex:Company ;
    ex:name "네이버" .

# ── 진술 1: 삼성전자 근무 (2020–2022) ──
ex:stmt1 a rdf:Statement ;
    rdf:subject   ex:김철수 ;
    rdf:predicate ex:worksAt ;
    rdf:object    ex:삼성전자 ;
    ex:startDate  "2020-01-01"^^xsd:date ;
    ex:endDate    "2022-12-31"^^xsd:date ;
    ex:source     ex:HR_Database ;
    ex:status     "과거" .

# ── 진술 2: 네이버 근무 (2023–현재) ──
ex:stmt2 a rdf:Statement ;
    rdf:subject   ex:김철수 ;
    rdf:predicate ex:worksAt ;
    rdf:object    ex:네이버 ;
    ex:startDate  "2023-03-01"^^xsd:date ;
    ex:source     ex:HR_Database ;
    ex:status     "현재" .

이제 처음의 세 가지 질문에 모두 답할 수 있습니다.

5. 시각화: Reification이 만드는 구조

아래 다이어그램은 Reification이 적용된 김철수의 이직 기록을 시각화한 것입니다. 각 진술(Statement)이 하나의 자원으로 존재하며, 원래 트리플의 주어·술어·목적어를 가리키는 동시에 시간 정보를 품고 있는 구조를 보여줍니다.

진술 1(stmt1)과 진술 2(stmt2)가 각각 독립된 자원으로 존재하면서, rdf:subject, rdf:predicate, rdf:object로 원래 트리플의 구성 요소를 가리킵니다. 그리고 각 진술에 startDate, endDate, status 같은 시간 메타데이터가 자연스럽게 달려 있습니다.

6. SPARQL로 질의하기

Reification된 데이터는 표준 SPARQL로 자연스럽게 질의할 수 있습니다. 예를 들어 “김철수가 현재 근무하는 회사”를 찾으려면 다음과 같이 작성합니다.

PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
PREFIX ex:  <http://example.org/>

SELECT ?company WHERE {
    ?stmt a rdf:Statement ;
          rdf:subject   ex:김철수 ;
          rdf:predicate ex:worksAt ;
          rdf:object    ?company ;
          ex:status     "현재" .
}

결과는 ex:네이버입니다. 중간 노드 방식(2.3절)에서 필요했던 2-hop 경로와 달리, 원래 트리플의 의미(worksAt)가 rdf:predicate로 명시적으로 보존되어 있으므로 온톨로지의 의미 구조가 유지됩니다.

“2021년 기준으로 김철수가 재직 중이던 회사”처럼 시간 범위 질의도 가능합니다.

SELECT ?company WHERE {
    ?stmt a rdf:Statement ;
          rdf:subject   ex:김철수 ;
          rdf:predicate ex:worksAt ;
          rdf:object    ?company ;
          ex:startDate  ?start ;
          ex:endDate    ?end .
    FILTER (?start <= "2021-06-01"^^xsd:date && ?end >= "2021-06-01"^^xsd:date)
}

7. Reification의 비용과 현대적 대안

7.1 트리플 폭발 문제

Reification은 강력하지만, 하나의 트리플을 표현하기 위해 최소 4개의 트리플(rdf:type, rdf:subject, rdf:predicate, rdf:object)이 필요합니다. 시간 정보까지 더하면 6~7개가 됩니다. 원본 트리플 1개 당 7배의 저장 공간을 소비하는 셈입니다.

대규모 Knowledge Graph에서 모든 트리플을 Reify하면 저장 공간과 쿼리 성능에 부담을 줄 수 있습니다. 따라서 시간에 따라 변하거나 출처 추적이 필요한 트리플만 선택적으로 Reify하는 것이 실무적인 접근입니다.

7.2 RDF-star: 간결한 대안

이러한 트리플 폭발 문제를 해결하기 위해 RDF-star[2]가 제안되었습니다. RDF-star에서는 트리플을 중첩(Nesting)하여 직접 메타데이터를 붙일 수 있습니다.

<< ex:김철수 ex:worksAt ex:삼성전자 >>
    ex:startDate "2020-01-01"^^xsd:date ;
    ex:endDate   "2022-12-31"^^xsd:date .

<< ... >> 안에 원래 트리플을 넣고, 바로 그 트리플에 대한 속성을 추가합니다. 내부적으로는 Reification과 동일한 의미를 가지지만, 문법이 훨씬 간결하고 트리플 수도 줄어듭니다. RDF-star는 W3C의 RDF 1.2 표준에 반영되어, 기존 Reification의 실질적인 후속 기법으로 자리 잡아가고 있습니다.

8. 마치며

RDF 트리플은 “무엇이 어떻다”라는 사실을 간결하게 표현하는 데 최적화되어 있습니다. 하지만 현실 세계의 사실은 항상 맥락을 동반합니다. 언제 그랬는지, 누가 그렇게 말했는지, 얼마나 확실한지. Reification은 이 맥락을 RDF의 틀 안에서 표현하는 표준적인 방법입니다.

시간에 따라 변하는 데이터를 다룰 때, 기본 트리플의 한계에 부딪혔다면 Reification을 떠올려 보세요. 트리플 하나하나가 “자원”이 되는 순간, Knowledge Graph는 비로소 시간의 흐름을 기록할 수 있게 됩니다.

관련 글

• S-P-O 분해 연습문제 풀이: 전력 모듈-센서 노이즈 간섭
• iCalendar의 진화: 텍스트에서 의미론적 웹으로

참고 문헌

1. R. Cyganiak, D. Wood, and M. Lanthaler, “RDF 1.1 Concepts and Abstract Syntax,” W3C, W3C Recommendation, Feb. 2014. Available at: https://www.w3.org/TR/rdf11-concepts/
2. R. Cyganiak, D. Wood, M. Lanthaler, O. Hartig, and P.-A. Champin, “RDF 1.2 Concepts and Abstract Syntax,” W3C, W3C Working Draft, 2024. Available at: https://www.w3.org/TR/rdf12-concepts/

Apache Arrow란 무엇인가

Apache Arrow[1]는 언어 중립적인 컬럼 기반 인메모리 데이터 포맷입니다. 핵심 아이디어는 단순합니다: 데이터를 행(row) 단위가 아니라 열(column) 단위로 메모리에 배치하면, 분석 워크로드에서 극적인 성능 향상을 얻을 수 있다는 것입니다.

행 기반 (Row-oriented):             컬럼 기반 (Column-oriented):
┌──────┬──────┬──────┐             ┌──────┬──────┬──────┐
│ key₁ │ ts₁  │ diff₁│             │ key₁ │ key₂ │ key₃ │  ← keys 버퍼
├──────┼──────┼──────┤             ├──────┼──────┼──────┤
│ key₂ │ ts₂  │ diff₂│             │ ts₁  │ ts₂  │ ts₃  │  ← timestamps 버퍼
├──────┼──────┼──────┤             ├──────┼──────┼──────┤
│ key₃ │ ts₃  │ diff₃│             │ diff₁│ diff₂│ diff₃│  ← diffs 버퍼
└──────┴──────┴──────┘             └──────┴──────┴──────┘

컬럼 기반 레이아웃의 이점은 세 가지입니다.

1. 캐시 친화성. diff 컬럼만 합산할 때, 행 기반에서는 key와 ts를 건너뛰며 캐시 라인을 낭비하지만, 컬럼 기반에서는 diff 값만 연속으로 읽습니다. 순차 스캔에서 약 25배의 캐시 효율 차이가 발생합니다.

2. SIMD 벡터화. 동일 타입의 값이 연속 메모리에 있으면 AVX2/AVX-512 명령어로 한 번에 8~16개 값을 처리할 수 있습니다. Arrow의 compute 커널은 산술 연산에서 4~8배, 비교 연산에서 5~10배의 SIMD 가속을 달성합니다.

3. 직렬화 제거. Arrow 포맷 자체가 와이어 포맷이 되므로, 프로세스 간 데이터 교환 시 직렬화/역직렬화가 필요 없습니다. IPC 공유 메모리 경로에서 10μs 지연으로 0회 복사 전달이 가능합니다.

Arrow의 메모리 레이아웃은 정밀하게 규격화되어 있습니다. 모든 버퍼는 64바이트 캐시 라인 경계에 정렬되고, 각 컬럼은 유효성 비트맵(validity bitmap) + 오프셋 버퍼 + 데이터 버퍼의 3중 구조를 가집니다. 이 규격의 총 메모리 오버헤드는 약 3%(정렬 패딩 1.6% + 유효성 비트맵 1.25%)입니다.

왜 Arrow인가 — Differential Dataflow의 관점에서

Differential Dataflow[2]의 핵심 자료구조는 델타 배치(delta batch)입니다. (data, time, diff) 트리플의 모음이며, 이것이 워커 간에 교환되고, 컴팩션(consolidation)을 거쳐 누적됩니다.

현재 Timely Dataflow의 Rust 구현체는 이 델타 배치를 Abomonation[3]으로 직렬화합니다. Abomonation은 Rust 구조체의 메모리 레이아웃을 그대로 바이트 배열로 변환하는 제로카피 라이브러리입니다. 역직렬화가 사실상 transmute(바이트 재해석)이므로, 속도는 경이적입니다 — 직렬화 62,717 MB/s, 역직렬화 4,108,000 MB/s.

하지만 Abomonation에는 구조적 한계가 있습니다.

• 안전성. unsafe 기반의 transmute로, 정의되지 않은 동작(UB)의 위험이 있습니다[4].
• Rust 전용. C, Python, Java 등 다른 언어에서 Abomonation 포맷을 읽을 수 없습니다.
• 스키마 진화 불가. 필드 하나를 추가하면 와이어 포맷이 깨집니다.
• 컴팩션 비효율. 행 기반 레이아웃이라 diff 컬럼만 합산하려 해도 전체 행을 순회해야 합니다.

Arrow는 이 문제들을 해결합니다. 특히 컴팩션 — Differential Dataflow에서 CPU 시간의 상당 부분을 차지하는 연산 — 에서 컬럼 기반 레이아웃의 이점이 큽니다.

47행의 경계 — Arrow가 이기는 지점과 지는 지점

Arrow가 Abomonation보다 항상 나은 것은 아닙니다. 배치 크기에 따라 명확한 교차점이 존재합니다.

Arrow RecordBatch에는 고정 비용이 있습니다: 스키마 메타데이터, 버퍼 정렬 패딩, 유효성 비트맵. 이 고정 비용은 배치가 클수록 행당 비용으로 희석되지만, 배치가 작으면 지배적이 됩니다.

47행이 교차점입니다. 이보다 작으면 Abomonation이 작고, 이보다 크면 Arrow가 작습니다.

Differential Dataflow의 델타 배치는 이중 모드(bimodal) 분포를 따릅니다. 초기 적재(bulk load)에서는 수백만 행의 배치가 생성되고, 증분 업데이트에서는 1~100행 수준입니다. 이 분포의 두 봉우리가 교차점의 양쪽에 놓인다는 점이 핵심입니다.

이것은 두 가지 중요한 결론을 암시합니다:

1. 핫 패스(증분 업데이트, 1~100행): Abomonation 스타일의 행 기반 포맷이 여전히 유리합니다.
2. 콜드 패스(컴팩션된 스파인, 1,000행 이상): Arrow 컬럼 포맷이 공간 효율과 분석 성능 모두에서 이깁니다.

따라서 하이브리드 전략이 필요합니다.

하이브리드 설계: 행과 열의 공존

핵심 원칙은 이것입니다: 포맷 전환은 컴팩션 경계에서 한 번만 일어난다. 핫 패스에서는 packed struct의 제로카피 속도를 유지하고, 컴팩션을 거쳐 배치 크기가 충분히 커진 시점에서 Arrow 컬럼 포맷으로 전환합니다.

Differential Dataflow와 Arrow의 계층 구조

Arrow를 Timely Dataflow 프로토콜 스택에 통합하면, Differential Dataflow와의 관계는 다음과 같은 계층 구조가 됩니다.

Arrow는 L4 (Delta Batch Layer)에 위치합니다. L1~L3은 이전 글에서 설계한 대로 순수 C로 유지합니다 — 이 레이어들은 FPGA HLS 합성 대상이고, Arrow의 컬럼 포맷과는 독립적으로 동작합니다. L5는 Rust FFI로 Differential Dataflow와 연결합니다.

L4와 L5 사이의 인터페이스는 Arrow C Data Interface[5]가 담당합니다. ArrowArray(88바이트)와 ArrowSchema(72바이트) 두 개의 C 구조체만으로 Rust와 C 사이에서 RecordBatch를 복사 없이 전달합니다.

C 구현체의 선택: GLib인가, stdlib인가, 아무것도 아닌가

Arrow의 C 구현체를 선택하는 것은 생각보다 복잡한 문제입니다. 선택지가 세 가지 있습니다.

Apache Arrow GLib

Arrow GLib[6]는 Arrow C++ 라이브러리의 GObject 기반 C 바인딩입니다. GLib[7]의 타입 시스템(GObject), 메모리 관리(g_malloc/g_free), 컨테이너(GArray, GHashTable), 에러 처리(GError)를 활용합니다.

장점은 명확합니다. 풍부한 자료구조, 참조 카운팅 기반 메모리 관리, GObject Introspection을 통한 Python/JavaScript 바인딩 자동 생성. GNOME 생태계와의 통합도 매끄럽습니다.

하지만 우리의 맥락에서 치명적인 문제가 있습니다:

• C++ 의존성. Arrow GLib는 Arrow C++ 위의 래퍼입니다. C++ 런타임, 예외 처리, RTTI가 딸려옵니다. 이전 글에서 C를 선택한 이유 — FPGA HLS 합성, ABI 안정성, 런타임 의존성 제거 — 를 정면으로 위배합니다.
• GLib 자체의 무게. GLib는 glibc 위에 또 하나의 추상 계층을 올립니다. GMainLoop, GType 등 우리가 필요 없는 인프라까지 포함하면 수 MB의 추가 의존성입니다.
• HLS 합성 불가. g_object_new(), 가상 함수 테이블, 동적 타입 캐스팅 — GObject의 핵심 메커니즘은 FPGA 로직으로 합성할 수 없습니다.

C stdlib만으로

반대편 극단은 C 표준 라이브러리(stdlib.h, string.h, stdint.h)만 사용하는 것입니다. malloc/free, memcpy, qsort — POSIX 환경이라면 어디서든 컴파일됩니다.

이 접근은 FPGA 경로에서는 이상적이지만, Arrow 포맷의 복잡성을 직접 구현해야 합니다. 가변 길이 버퍼의 오프셋 관리, 중첩 타입의 재귀적 버퍼 할당, Dictionary 인코딩의 해시 테이블 — 이 모든 것을 malloc과 포인터 산술로 처음부터 작성하는 것은 삽질의 냄새가 짙습니다.

Nanoarrow: 제3의 길

Nanoarrow[8]는 이 딜레마의 답이 될 수 있습니다. Apache Arrow 프로젝트의 일부로 개발된, Arrow C Data Interface와 C Stream Interface의 최소 구현체입니다.

핵심 특성:

• ~100KB. GLib 없이, C++ 없이, 순수 C로 약 100KB입니다.
• Arrow C Data Interface 호환. ArrowArray, ArrowSchema 구조체를 직접 생산하고 소비합니다.
• 의존성 없음. C99 표준 라이브러리만 필요합니다.
• 헤더 온리 모드. 단일 .h 파일로 인클루드 가능합니다.

Nanoarrow가 제공하는 것과 제공하지 않는 것:

Nanoarrow를 L4의 기반으로 사용하고, SIMD 컴팩션 커널은 C로 직접 구현하며, FPGA 오프로드 경로의 가장 안쪽 루프만 순수 C stdlib로 작성하는 것이 현실적인 전략입니다.

#include "nanoarrow/nanoarrow.h"

// Nanoarrow로 델타 배치를 Arrow RecordBatch로 변환
int delta_batch_to_arrow(const delta_tuple_t *tuples, size_t n,
                         struct ArrowArray *out_array,
                         struct ArrowSchema *out_schema) {
    struct ArrowSchemaView schema_view;

    // 스키마 정의: key(binary), time(fixed_size_list<uint32>), diff(int64)
    NANOARROW_RETURN_NOT_OK(ArrowSchemaInitFromType(out_schema, NANOARROW_TYPE_STRUCT));
    NANOARROW_RETURN_NOT_OK(ArrowSchemaAllocateChildren(out_schema, 3));

    ArrowSchemaInit(out_schema->children[0]);
    NANOARROW_RETURN_NOT_OK(ArrowSchemaSetType(out_schema->children[0], NANOARROW_TYPE_BINARY));
    NANOARROW_RETURN_NOT_OK(ArrowSchemaSetName(out_schema->children[0], "key"));

    ArrowSchemaInit(out_schema->children[1]);
    NANOARROW_RETURN_NOT_OK(ArrowSchemaSetType(out_schema->children[1], NANOARROW_TYPE_UINT64));
    NANOARROW_RETURN_NOT_OK(ArrowSchemaSetName(out_schema->children[1], "time"));

    ArrowSchemaInit(out_schema->children[2]);
    NANOARROW_RETURN_NOT_OK(ArrowSchemaSetType(out_schema->children[2], NANOARROW_TYPE_INT64));
    NANOARROW_RETURN_NOT_OK(ArrowSchemaSetName(out_schema->children[2], "diff"));

    // ArrowArray 빌더로 데이터 채우기
    struct ArrowArray tmp;
    NANOARROW_RETURN_NOT_OK(ArrowArrayInitFromSchema(&tmp, out_schema, NULL));
    NANOARROW_RETURN_NOT_OK(ArrowArrayStartAppending(&tmp));

    for (size_t i = 0; i < n; i++) {
        NANOARROW_RETURN_NOT_OK(ArrowArrayAppendNull(&tmp, 0));  // struct validity
        // ... 각 컬럼에 값 추가
    }

    NANOARROW_RETURN_NOT_OK(ArrowArrayFinishBuildingDefault(&tmp, NULL));
    ArrowArrayMove(&tmp, out_array);
    return NANOARROW_OK;
}

UDP 기반 프로토콜에서 Arrow 데이터 전송

이전 글에서 설계한 16바이트 wire_hdr_t 헤더는 그대로 유지합니다. Arrow는 L4 페이로드 포맷으로 동작하며, L1의 UDP 패킷 위에 올라갑니다. gRPC 기반의 Arrow Flight는 고려 대상이 아닙니다 — 데이터센터 내부의 워커 메시에서 gRPC의 HTTP/2 프레이밍과 TLS 오버헤드는 불필요합니다.

대신, Arrow IPC 스트리밍 포맷[9]을 UDP 위에 직접 실어 보내는 방식을 구상하고 있습니다.

┌─────────────────────────────────────────────────────┐
│ UDP Datagram                                        │
│ ┌──────────────┬──────────────────────────────────┐ │
│ │ wire_hdr_t   │ Payload                          │ │
│ │ (16B, C)     │                                  │ │
│ │ ┌──────────┐ │ ┌──────────────────────────────┐ │ │
│ │ │epoch     │ │ │ 배치 ≥ 47행:                 │ │ │
│ │ │iteration │ │ │   Arrow IPC RecordBatch      │ │ │
│ │ │channel_id│ │ │   (FlatBuffers 메타데이터     │ │ │
│ │ │flags     │ │ │    + 컬럼 버퍼)              │ │ │
│ │ │seq_num   │ │ │                              │ │ │
│ │ │payload_le│ │ │ 배치 < 47행:                 │ │ │
│ │ │checksum  │ │ │   packed struct (기존 방식)   │ │ │
│ │ └──────────┘ │ └──────────────────────────────┘ │ │
│ └──────────────┴──────────────────────────────────┘ │
└─────────────────────────────────────────────────────┘

wire_hdr_t의 flags 필드에 1비트를 추가하여 페이로드가 Arrow IPC인지 packed struct인지 구분합니다. 수신 측은 이 플래그를 보고 적절한 디코더를 선택합니다.

이 설계에서 Arrow IPC의 FlatBuffers 메타데이터는 한 가지 우려를 만듭니다: 소규모 배치에서 메타데이터 비용이 커질 수 있습니다. 하지만 47행 이상의 배치만 Arrow IPC로 보내므로, 메타데이터 비율은 5% 미만으로 유지됩니다.

MTU(1,500바이트)를 초과하는 RecordBatch의 단편화도 L2 Channel Layer에서 처리합니다. Arrow IPC 메시지를 MTU 크기의 청크로 분할하고, 채널별 시퀀스 번호로 재조립합니다. 이것은 이미 L2가 담당하도록 설계된 영역입니다.

Dictionary 인코딩: Differential Dataflow의 숨겨진 기회

Arrow의 Dictionary 인코딩은 Differential Dataflow에서 예상 외의 큰 효과를 발휘할 수 있습니다.

Differential Dataflow의 많은 워크로드에서 data 키는 제한된 도메인(bounded domain)에서 반복됩니다. 그래프 연산에서 정점 ID, RDF 처리에서 URI 문자열, 로그 분석에서 이벤트 타입 — 고유 값의 수가 전체 행 수보다 훨씬 적습니다.

Dictionary 인코딩은 이런 패턴에서 90% 이상의 저장 공간 절감을 달성합니다. 10개의 고유 키가 1,000,000행에 반복될 때, 일반 인코딩 대비 90.7%를 절감합니다. 반면 키가 대부분 고유한 경우(1,000,000 고유 / 1,000,000 행)에는 오히려 14.7%의 패널티가 발생합니다.

이것은 컴팩션 연산에도 영향을 미칩니다. Dictionary로 인코딩된 키 컬럼에서 같은 키끼리 그룹화(group-by)할 때, 키 비교가 정수 비교로 환원됩니다. 가변 길이 문자열의 바이트 단위 비교 대신 uint32_t 비교 한 번 — 이것은 SIMD로 한 번에 8개씩 처리할 수 있습니다.

컴팩션을 Arrow로 재구현하면

Differential Dataflow의 컴팩션(consolidation)은 핵심 연산입니다: 동일 키의 diff를 합산하고, 합이 0인 엔트리를 제거합니다. 현재 Rust 구현은 정렬 기반 단일 패스(sort → merge → accumulate → filter zero)로 동작합니다.

Arrow로 재구현하면 연산은 다음과 같이 분해됩니다:

1. Group-by + Sum: hash_aggregate 커널로 (key, time) 기준 그룹화 후 diff 합산
2. Filter zero: filter 커널로 diff ≠ 0인 행만 선택

이것은 원래의 단일 패스보다 다중 패스(multi-pass)입니다 — 각 커널이 독립적으로 전체 컬럼을 순회합니다. 알고리즘 복잡도만 보면 불리합니다.

하지만 SIMD 벡터화가 이 차이를 상쇄하거나 역전시킬 수 있습니다. Arrow의 hash_aggregate 커널은 AVX2로 한 사이클에 8개의 해시를 계산하고, filter 커널은 비트 마스크로 한 번에 64개 행을 평가합니다. 배치 크기가 1,000행 이상일 때, 다중 패스 + SIMD가 단일 패스 + 스칼라를 이기기 시작합니다.

다만 정직하게 말하면, 이 교차점이 정확히 어디인지는 실측 없이는 알 수 없습니다. 이론적 추정과 실제 성능은 캐시 계층 동작, 분기 예측, 메모리 대역폭 포화 등의 변수에 따라 크게 달라집니다.

Claude Code를 믿을 것인가

솔직한 고백을 하나 하겠습니다. 이 글을 쓰면서, 그리고 프로토콜 설계를 진행하면서, Claude Code의 도움을 상당히 받고 있습니다. Arrow의 내부 구조를 조사하고, 바이트 단위 오버헤드를 계산하고, C 코드 스케치를 생성하는 과정에서 AI 코드 생성 도구를 활용하고 있습니다.

이것은 기묘한 위치에 놓인 신뢰의 문제입니다. 두 가지 차원이 있습니다.

첫째, 정확성. AI가 생성한 코드와 수치를 얼마나 믿을 수 있는가? Arrow의 메모리 레이아웃, 배치별 오버헤드 계산, SIMD 가속 비율 — 이런 것들은 공식 문서와 대조해서 검증할 수 있습니다. 실제로 이 글의 수치 중 상당수는 Arrow 공식 스펙[1]에서 직접 확인한 것입니다. 하지만 “47행”이라는 교차점처럼 여러 가정이 결합된 추정은, 개별 가정이 각각 합리적이더라도 결합된 결론이 현실과 얼마나 가까운지 보장하기 어렵습니다.

둘째, 설계 판단. “Nanoarrow를 쓰라”거나 “하이브리드 전략이 맞다”는 판단은 코드 정확성보다 더 미묘한 영역입니다. AI는 검색된 정보를 합리적으로 종합하는 데 능숙하지만, 프로젝트의 장기적 방향성, 유지보수 부담, 커뮤니티 생태계의 미래 — 이런 것들은 경험과 직관의 영역이고, 현재의 AI가 가장 취약한 부분입니다.

제가 취하는 태도는 이렇습니다: AI를 리서치 어시스턴트로 사용하되, 아키텍처 결정은 제가 내린다. 구체적으로:

• 수치와 사실 확인: AI가 빠르게 조사하고, 제가 공식 문서에서 교차 검증합니다.
• 코드 스케치: AI가 초안을 생성하고, 제가 한 줄씩 검토합니다. 특히 C 코드에서 메모리 관리, 정렬, 바운더리 조건은 반드시 직접 확인합니다.
• 설계 대안 탐색: AI에게 “왜 이 접근이 안 되는가”를 질문하면, 놓쳤던 제약 조건을 발견하는 데 도움이 됩니다.
• 최종 결정: 하이브리드 전략, Nanoarrow 선택, UDP 직접 전송 — 이 결정들은 AI의 제안을 참고하되, 결국 제가 이해하고 설명할 수 있는 범위에서만 채택합니다.

C 프로토콜 코드에서 AI 생성 코드를 그대로 사용하는 것은 위험합니다. 전송 프로토콜은 모든 엣지 케이스 — 패킷 재조립 실패, 부분 수신, 정렬 위반, 버퍼 오버플로우 — 를 정확히 처리해야 합니다. 이 영역에서 “대체로 맞는” 코드는 프로덕션에서 재앙입니다. AI가 생성한 C 코드는 반드시 단위 테스트, 퍼즈 테스팅, Valgrind/ASan으로 검증한 뒤에만 채택할 수 있습니다.

구현 로드맵

정리하면, Arrow를 Timely Dataflow 프로토콜에 통합하는 로드맵은 다음과 같습니다.

Phase 1: L4 내부 포맷으로 Arrow RecordBatch 도입

• Nanoarrow를 L4에 통합
• 델타 배치 → Arrow RecordBatch 변환 함수 구현
• 47행 이상 배치만 Arrow로 변환, 이하는 packed struct 유지
• 소프트웨어 전용, FPGA 무관

Phase 2: Arrow 기반 컴팩션

• diff 컬럼 합산을 SIMD C 커널로 직접 구현 (Nanoarrow에는 compute 커널 없음)
• Dictionary 인코딩 적용하여 키 비교 가속
• 교차점 실측: 단일 패스 스칼라 vs 다중 패스 SIMD

Phase 3: Arrow IPC를 UDP 와이어 포맷으로

• Arrow IPC 스트리밍 포맷을 L4 페이로드로 채택
• L2에서 MTU 단편화/재조립
• wire_hdr_t.flags에 Arrow IPC 플래그 추가
• 워커 간 통신에서 직렬화 비용 제거

Phase 4: FPGA DMA 경로의 Arrow 연동

• Arrow의 64바이트 정렬 버퍼를 DMA 버퍼로 직접 사용
• FPGA에서는 컬럼 → 행 전치(transpose) 수행 (라인 레이트)
• Nanoarrow 기반 DMA 디스크립터 생성

마치며

Apache Arrow는 Timely Dataflow 프로토콜의 L4 Delta Batch Layer에 자연스럽게 들어맞습니다. 컬럼 기반 레이아웃은 컴팩션과 분석에서 명확한 이점을 제공하고, C Data Interface는 Rust와 C 사이의 제로카피 브릿지가 됩니다. Nanoarrow라는 경량 C 구현체의 존재가 “GLib도 C++도 없이 순수 C로”라는 제약 조건을 충족시킵니다.

다만 Arrow가 만능은 아닙니다. 47행 미만의 소규모 배치에서는 Abomonation이 여전히 우위이고, 컴팩션의 다중 패스 오버헤드가 SIMD 가속으로 실제 얼마나 상쇄되는지는 실측이 필요합니다. FPGA 경로에서 컬럼-행 전치의 비용도 아직 미지수입니다.

그래서 이 글의 결론은 “Arrow를 쓰자”가 아니라, “Arrow를 이 경계 안에서 쓰자”입니다. 핫 패스는 packed struct, 콜드 패스는 Arrow, 그 사이의 전환점은 컴팩션 경계 — 이 하이브리드 설계가 두 세계의 장점을 취하는 길입니다.

다음 글에서는 Nanoarrow 기반의 L4 프로토타입 구현과, 실제 델타 배치에서의 성능 측정 결과를 다룰 예정입니다.

참고 문헌

1. Apache Arrow Authors, “Apache Arrow Columnar Format Specification.” 2024. Available at: https://arrow.apache.org/docs/format/Columnar.html
2. F. McSherry, D. G. Murray, R. Isaacs, and M. Isard, “Differential Dataflow,” in Proceedings of the 6th Biennial Conference on Innovative Data Systems Research (CIDR ’13), CIDR, Jan. 2013. [Link]
3. F. McSherry, “Abomonation: A mortifying serialization library for Rust.” 2015. Available at: https://github.com/TimelyDataflow/abomonation
4. RustSec Advisory Database, “RUSTSEC-2021-0120: abomonation transmutes references to and from byte slices.” 2021. Available at: https://rustsec.org/advisories/RUSTSEC-2021-0120.html
5. Apache Arrow Authors, “Arrow C Data Interface.” 2024. Available at: https://arrow.apache.org/docs/format/CDataInterface.html
6. Apache Arrow Authors, “Apache Arrow GLib (C API).” 2024. Available at: https://arrow.apache.org/docs/c_glib/
7. GNOME Project, “GLib Reference Manual.” 2024. Available at: https://docs.gtk.org/glib/
8. D. Dunnington and Apache Arrow Authors, “nanoarrow: Helpers for Arrow C Data and C Stream Interfaces.” 2024. Available at: https://github.com/apache/arrow-nanoarrow
9. Apache Arrow Authors, “Arrow IPC Streaming Format.” 2024. Available at: https://arrow.apache.org/docs/format/IPC.html

관련 글

• Timely Dataflow를 위한 전송 프로토콜은 왜 새로 필요한가
• Datalog의 증분 계산: Differential Dataflow `

Timely Dataflow[1]는 이 분산 실행을 가능하게 하는 데이터플로우 런타임이고, Differential Dataflow[2]는 그 위에서 증분 계산의 논리를 담당합니다. 문제는 이 두 시스템의 네트워크 계층입니다. Rust 구현체는 워커 간 통신에 TCP를 사용하는데, TCP 경로에서 메시지 하나당 7번의 메모리 복사가 발생하고, 그 중 4번은 본질적으로 불필요합니다[3]. 수신 경로(ProcessBinary::pre_work)에서 전체 메모리 할당의 99.6%가 집중되며, CPU 프로파일의 상위를 _platform_memmove가 차지합니다. 데이터플로우의 계산 논리가 아무리 정교해도, 전송 계층이 병목이 되면 시스템 전체의 지연 시간은 전송 계층이 결정합니다.

그렇다면 이미 존재하는 고성능 전송 프로토콜을 가져다 쓰면 되지 않을까요? SRT, QUIC, Aeron, KCP — 모두 UDP 기반의 저지연 프로토콜입니다. 하나씩 살펴보았습니다.

기존 프로토콜이 맞지 않는 이유

SRT: 라이브 영상 전송의 정석

SRT(Secure Reliable Transport)는 Haivision이 공개한 라이브 영상 전송 프로토콜입니다[4]. UDT에서 파생되어, 불안정한 공용 인터넷 위에서도 MPEG-TS 스트림을 안정적으로 전달하는 데 탁월한 성능을 보여줍니다. NACK 기반 ARQ와 지연 한계 내의 재전송, AES 암호화까지 — 라이브 미디어 전송이라는 도메인에서 SRT의 설계는 매우 정교합니다.

그러나 SRT가 풀고자 하는 문제와 Differential Dataflow의 문제는 성격이 다릅니다. SRT의 핵심 메커니즘인 TLPKTDROP은 지연 한계(기본 120ms)를 초과한 패킷을 폐기합니다. 라이브 방송에서 늦은 프레임은 의미가 없으므로 이것은 올바른 트레이드오프입니다. 반면 Differential Dataflow의 델타 튜플 (data, time, diff)은 모든 변경분의 완전한 전달을 전제로 합니다. 가중 집합(Z-set)의 정확성이 이에 달려 있기 때문입니다. “늦더라도 반드시 도착해야 하는” 데이터와 “늦으면 버려야 하는” 데이터 — 이 두 요구는 근본적으로 양립하기 어렵습니다.

또한 SRT의 페이로드는 MPEG-TS에 맞춘 1,316바이트인 반면, Differential Dataflow의 델타 레코드는 평균 50~500바이트 수준입니다. CBR(상수 비트레이트) 페이싱 역시 입력 배치와 반복 경계에 따라 폭발적으로 발생하는 델타 트래픽과는 다른 리듬입니다. SRT의 강점이 빛나는 영역과 Differential Dataflow가 필요로 하는 영역이 겹치지 않는 것입니다.

QUIC: 웹을 위한 프로토콜

QUIC는 HTTP/3의 전송 계층을 목표로 탄생한 프로토콜입니다[5]. 스트림 멀티플렉싱, TLS 1.3 통합, 헤드오브라인 블로킹 해소 — 브라우저와 CDN 사이의 요청-응답 패턴에서 탁월한 성능을 보여줍니다.

하지만 데이터센터 내부의 워커 메시(Worker Mesh)에 적용하려 하면, QUIC의 설계 전제가 이 환경과 맞지 않는다는 점이 드러납니다. QUIC는 TLS 1.3을 프로토콜에 내장하고 있으며(RFC 9001), 이를 비활성화할 수 없습니다. 신뢰할 수 있는 클러스터 내부 통신에서 레코드당 22바이트의 AEAD 오버헤드와 AES-GCM 셋업 비용(레코드당 ~200ns)은 불필요한 비용이 됩니다.

혼잡 제어 역시 인터넷 경로를 전제로 두고 있습니다(RFC 9002). 초기 RTT 추정치가 333ms인데, 데이터센터 내부 RTT는 0.1ms, FPGA PCIe 경로는 0.001ms입니다. 3,330배에서 333,000배의 과대 추정이며, 새 연결마다 처음 333ms 동안 혼잡 제어가 현실을 반영하지 못합니다.

스트림 관리의 비용도 무시하기 어렵습니다. 64개 워커 × 20개 오퍼레이터 구성에서는 80,640개의 동시 스트림이 필요하고, 스트림당 약 4KB의 상태를 유지하면 전송 계층만으로 315MB의 메모리를 소비합니다. QUIC가 해결하고자 한 웹 트래픽의 문제와, 데이터플로우 워커 메시의 문제는 규모와 방향이 다릅니다.

Aeron: 메시징을 위한 프로토콜

Aeron은 금융 거래 시스템을 위한 고성능 메시징 프레임워크입니다. 미디어 드라이버(Media Driver)라는 별도 프로세스가 공유 메모리 링 버퍼를 통해 애플리케이션과 통신하며, Sender·Receiver·Conductor 세 스레드가 busy-spinning으로 동작합니다.

성능은 인상적입니다. IPC 경로에서 1μs 미만의 지연을 달성합니다. 하지만 Differential Dataflow의 관점에서 보면 구조적 불일치가 있습니다.

Aeron은 발행-구독(Pub/Sub) 모델입니다. Differential Dataflow가 필요로 하는 것은 포인트-투-포인트 델타 스트리밍과 프론티어(Frontier) 전파입니다. Timely Dataflow에서 프론티어란, 더 이상 특정 시점 이전의 메시지가 도착하지 않을 것임을 알려주는 진행 신호입니다[1]. 이 신호는 데이터 메시지보다 우선순위가 높아야 합니다 — 프론티어가 지연되면 파이프라인 뒤쪽의 모든 연산이 대기 상태에 빠지기 때문입니다. Aeron에는 이런 우선순위 레인이 없습니다.

또한 미디어 드라이버는 인스턴스당 3개의 전용 CPU 코어를 소비합니다. 16개 워커를 운영하면 전송 인프라만으로 48코어가 필요합니다. 이것은 프로토콜이 아니라 미들웨어의 비용입니다.

KCP: 게임을 위한 프로토콜

KCP는 순수 C 2,000줄 미만으로 구현한 경량 ARQ 프로토콜입니다. 공격적인 재전송으로 게임 및 실시간 애플리케이션에서 낮은 지연을 달성합니다. C 구현이라는 점에서 처음에는 가장 가능성 있어 보였습니다.

하지만 KCP는 단일 스트림 프로토콜입니다. Differential Dataflow의 K개 데이터 채널에 K개의 독립적인 ikcpcb 인스턴스가 필요하며, K=1,000일 때 ikcp_update() 호출만으로 초당 200ms의 CPU 시간을 소비합니다. 메시지당 3~4회의 메모리 복사가 발생하고, 이중 링크드 리스트 탐색과 동적 메모리 할당은 FPGA 파이프라인으로 합성할 수 없는 구조입니다.

공통적으로 빠진 것

네 프로토콜 모두에서 공통적으로 부재한 것은 부분 순서 타임스탬프(Partially Ordered Timestamp)에 대한 인식입니다.

Timely Dataflow에서 ‘시간’이란 0, 1, 2로 증가하는 단순한 번호가 아닙니다. (epoch, iteration_0, iteration_1, ...)처럼 여러 차원이 중첩된 격자(Lattice) 구조이고, 이 격자 위에서 “어느 시점까지 처리가 끝났는가”를 추적합니다. 그런데 SRT든 QUIC든 Aeron이든 KCP든, 이들이 아는 시간이란 단조 증가하는 시퀀스 번호가 전부입니다. 전송 계층이 부분 순서 타임스탬프와 프론티어를 모르면, 결국 애플리케이션 계층에서 이 논리를 전부 다시 구현해야 합니다. 기존 프로토콜 위에 사실상 새로운 프로토콜을 하나 더 올리는 꼴입니다.

구현 언어는 왜 C인가

새로운 프로토콜을 구현한다면, 그 언어는 C여야 합니다. Differential Dataflow의 정식 구현체가 Rust인 점을 고려하면 다소 역설적으로 들릴 수 있습니다. 하지만 이 프로토콜은 애플리케이션 로직이 아니라 전송 인프라이고, 전송 인프라의 최종 목표는 FPGA 가속입니다.

커널 모드가 아닌 유저 모드

FPGA 가속의 전제는 커널 우회(Kernel Bypass)입니다. 리눅스 커널 네트워크 스택은 패킷당 두 번의 컨텍스트 스위치, 스케줄러 지터, 캐시 오염을 수반합니다. FPGA가 400ns 만에 패킷을 처리해도, 커널 경유 시 20μs의 왕복 지연이 가속의 이점을 전부 상쇄합니다.

DPDK의 폴 모드 드라이버(PMD)는 커널을 완전히 우회하여 유저 모드에서 패킷을 처리합니다. 여기에 FPGA SmartNIC을 결합하면 p50 400ns를 달성합니다. 이 모든 것이 유저 모드에서 동작해야 하는 이유입니다.

C와 FPGA의 공생

그리고 유저 모드 네트워킹에서 C가 유일한 선택인 이유는 HLS(High-Level Synthesis) 때문입니다.

FPGA 벤더의 HLS 툴체인 — Xilinx Vivado/Vitis HLS, Intel HLS Compiler — 은 C 코드를 직접 하드웨어(RTL)로 합성합니다. 동일한 C 함수를 소프트웨어에서 실행할 수도 있고, #pragma HLS PIPELINE 한 줄을 추가하면 FPGA 로직으로 변환할 수도 있습니다.

// 소프트웨어에서 실행 가능하고, 동시에 FPGA로 합성 가능한 패킷 파서
void parse_delta_header(const uint8_t *buf, delta_hdr_t *hdr) {
    #pragma HLS PIPELINE II=1
    hdr->epoch     = (buf[0] << 24) | (buf[1] << 16) | (buf[2] << 8) | buf[3];
    hdr->iteration = (buf[4] << 8)  | buf[5];
    hdr->diff_type = buf[6];
    hdr->count     = buf[7];
}

C++은 HLS 툴체인이 부분적으로만 지원하고(가상 함수, RTTI, 예외 불가), Rust는 어떤 HLS 툴체인도 지원하지 않습니다. Go는 가비지 컬렉터가 DMA 핀 메모리를 재배치할 수 있어 원천적으로 불가능합니다.

DPDK, SPDK, libibverbs, libfabric, XDMA, QDMA, OpenNIC — FPGA/네트워크 생태계의 주요 라이브러리 10개 모두 C로 구현하고 있습니다. 이것은 관성이 아니라, ABI 안정성과 HLS 합성이라는 구조적 요구가 만들어낸 결과입니다.

핵심은 이것입니다: 동일한 C 소스 파일이 (1) 소프트웨어 레퍼런스 구현, (2) HLS 합성 입력, (3) DPDK PMD 통합 계층, (4) FPGA와 공유하는 DMA 디스크립터 정의를 동시에 수행합니다. 이 네 가지 역할을 하나의 언어로 충족할 수 있는 것은 C뿐입니다.

레이어 분할 설계

잠깐 스케치해 본 레이어 분할 설계 아이디어입니다. 5개 레이어로 나누고, 각 레이어를 독립적으로 테스트할 수 있게 하면서 하위 레이어부터 점진적으로 FPGA로 오프로드하는 구조를 생각하고 있습니다.

L1: Wire Layer — 선(線) 위의 바이트

가장 낮은 계층입니다. UDP 소켓 또는 DPDK PMD를 통해 원시 패킷을 송수신합니다. 이 계층의 핵심 설계 원칙은 드라이버 교체 가능성입니다.

typedef struct {
    int (*send)(void *ctx, const uint8_t *buf, size_t len);
    int (*recv)(void *ctx, uint8_t *buf, size_t max_len);
    int (*flush)(void *ctx);
} wire_ops_t;

소프트웨어 개발 초기에는 sendmsg()/recvmsg() 기반의 커널 UDP 드라이버를 사용하고, 성능이 필요한 시점에서 DPDK PMD 드라이버로 교체하며, 최종적으로 FPGA SmartNIC(Xilinx QDMA, Intel IPU)의 DMA 링으로 전환합니다. 상위 계층의 코드는 한 줄도 바꿀 필요가 없습니다.

패킷 프레이밍은 16바이트 고정 헤더를 사용합니다. 64바이트 델타 레코드 기준으로 20%의 오버헤드이며, 이것은 SRT(38.5%)나 Aeron(38.5%), KCP(33.3%)보다 효율적입니다. 다만 암호화는 아직 고려하지 못한 부분입니다. SRT의 AES-CTR이나 QUIC의 TLS 1.3처럼 전송 계층 수준의 암호화를 어떻게 통합할지는 별도의 설계가 필요합니다.

typedef struct __attribute__((packed)) {
    uint32_t epoch;         // 외부 시점
    uint16_t iteration;     // 내부 반복 인덱스
    uint8_t  channel_id;    // 멀티플렉싱 채널
    uint8_t  flags;         // PROGRESS | DATA | ACK | COMPACT
    uint32_t seq_num;       // 채널별 시퀀스 번호
    uint16_t payload_len;   // 페이로드 길이
    uint16_t checksum;      // CRC-16 (FPGA 오프로드 대상)
} wire_hdr_t;               // 16 bytes, FPGA 레지스터 맵과 1:1 대응

__attribute__((packed))로 선언한 이 구조체는 FPGA의 레지스터 맵과 바이트 단위로 정확히 일치합니다. HLS로 합성하면 클럭 사이클당 하나의 헤더를 처리하는 패킷 파서 파이프라인을 얻습니다.

L2: Channel Layer — 채널의 분리

데이터플로우 그래프에서 오퍼레이터 사이의 각 에지(Edge)가 하나의 논리 채널이 됩니다. 이 계층은 하나의 물리적 연결 위에서 다수의 논리 채널을 멀티플렉싱하고, 진행 채널(Progress Channel)이 데이터 채널보다 항상 우선하도록 스케줄링합니다.

이것이 Aeron이나 QUIC의 스트림 멀티플렉싱과 다른 점입니다. 일반적인 멀티플렉싱은 공정성(Fairness)을 추구하지만, Timely Dataflow에서 프론티어 메시지가 늦으면 파이프라인 뒤쪽의 모든 연산이 멈춥니다. 따라서 진행 채널은 엄격한 우선순위(Strict Priority)를 가져야 합니다.

배압(Backpressure)도 타임스탬프 단위로 작동합니다. 수신 측이 “시점 $t$의 델타는 아직 처리 중이니 잠깐 멈춰 달라”고 요청하면, 전송 측은 해당 시점의 델타만 보류합니다. 나머지 시점의 데이터는 영향 없이 계속 흐릅니다. TCP처럼 바이트 수로 흐름을 조절하는 것이 아니라, 데이터의 의미를 기준으로 흐름을 조절하는 셈입니다.

L3: Progress Layer — 진행의 언어

이 계층이 기존 프로토콜과의 가장 본질적인 차별점입니다. 부분 순서 타임스탬프를 전송 프로토콜의 일급 시민(First-class Citizen)으로 다룹니다.

Naiad 논문[1]의 진행 추적 프로토콜에서, 워커는 포인트스탬프(Pointstamp)의 발생 카운트(Occurrence Count)와 선행 카운트(Precursor Count)를 관리하며, 변경 사항을 모든 피어에게 브로드캐스트합니다. 64개 워커 기준으로 한 번의 프론티어 갱신이 63개의 브로드캐스트 메시지를 발생시킵니다 — $O(N^2)$의 통신 복잡도입니다.

이 계층에서 프론티어 계산 자체를 FPGA로 오프로드하면 극적인 효과가 있습니다. 250MHz FPGA에 16개의 병렬 비교기를 배치하면 초당 약 40억 회의 포인트스탬프 비교가 가능합니다[6]. 일반적인 워크로드가 초당 약 100만 회의 비교를 요구하는 점을 고려하면, 4,000배의 여유가 생깁니다. CPU는 프론티어 계산에서 완전히 해방되어 본래의 작업 — 오퍼레이터 로직 실행 — 에 집중할 수 있습니다.

L4: Delta Batch Layer — 델타의 포장

Differential Dataflow의 델타 배치는 이중 모드(Bimodal) 크기 분포를 보입니다. 초기 적재 시에는 수백만 개의 (data, time, diff) 트리플을 한꺼번에 만들어내지만, 증분 업데이트 시에는 1~100개 수준에 그칩니다.

이 계층의 핵심은 적응적 배칭(Adaptive Batching)입니다. 부하가 낮을 때는 델타를 즉시 전달하여 지연을 최소화하고, 부하가 높을 때는 델타를 합쳐서(Coalesce) 처리량을 극대화합니다. 결정 기준은 두 가지입니다: (1) 큐 깊이가 임계값을 초과하는가, (2) 마지막 전송 이후 경과 시간이 타이머를 초과하는가.

컴팩션(Consolidation) — 동일 키에 대한 diff를 합산하고, 합이 0인 엔트리를 제거하는 연산 — 도 이 계층에서 수행합니다. 일반적인 워크로드에서 컴팩션은 엔트리의 30~80%를 제거합니다. 이 연산은 스트리밍 병합 정렬과 누산(Accumulation)의 조합으로, 데이터 의존적 분기가 없는 고정된 데이터플로우 파이프라인입니다 — FPGA 합성에 이상적인 패턴입니다.

직렬화는 Timely Dataflow가 사용하는 Abomonation[7] 스타일의 제로카피 방식을 따릅니다. 구조체의 메모리 레이아웃이 곧 와이어 포맷이 되도록 packed struct를 설계하면, 직렬화 비용은 0에 수렴합니다. C의 __attribute__((packed))가 필요한 이유가 바로 여기에 있습니다.

L5: Dataflow Binding Layer — 두 세계의 접점

최상위 계층은 C로 작성된 전송 라이브러리를 Rust의 timely-dataflow 크레이트와 연결합니다. Rust FFI(extern "C")를 통해 C 함수를 호출하고, C ABI의 안정성 덕분에 양쪽이 독립적으로 버전을 올릴 수 있습니다.

// Rust 측: timely-dataflow의 Communication 트레이트 구현
extern "C" {
    fn tdd_channel_open(peer: u32, channel: u8) -> *mut TddChannel;
    fn tdd_channel_send(ch: *mut TddChannel, buf: *const u8, len: usize) -> i32;
    fn tdd_frontier_advance(ch: *mut TddChannel, epoch: u32, iter: u16) -> i32;
}

이 바인딩 계층만 Rust로 작성하고, 나머지 L1~L4는 모두 C로 구현합니다. 소프트웨어 모드에서 충분히 검증한 뒤 L1(패킷 파싱, 체크섬)부터 L3(프론티어 계산), L4(컴팩션)까지 점진적으로 FPGA로 내려보내는 상향식 하드웨어 오프로드 전략을 취합니다.

마치며

SRT는 영상을 위해, QUIC는 웹을 위해, Aeron은 메시징을 위해, KCP는 게임을 위해 만든 프로토콜입니다. 각각의 도메인에서는 훌륭한 프로토콜입니다. 하지만 Differential Dataflow가 요구하는 것 — 부분 순서 타임스탬프, 프론티어 우선 전파, 적응적 델타 배칭, 의미론적 배압 — 은 이 프로토콜들의 설계 공간(Design Space)에 존재하지 않습니다.

기존 프로토콜 위에 이 기능들을 쌓으려면 결국 전송 계층 대부분을 다시 구현하게 됩니다. 그렇다면 처음부터 Differential Dataflow의 의미론에 맞춰 설계하는 편이 더 깨끗합니다. 그리고 그 구현이 C여야 하는 이유는 감상적인 것이 아닙니다. FPGA HLS 툴체인이 합성할 수 있는 유일한 범용 언어가 C이고, 유저 모드 네트워킹 생태계 전체가 C ABI 위에 서 있기 때문입니다.

Differential Dataflow는 “무엇이 바뀌었는가”를 계산의 출발점으로 삼습니다. 이 프로토콜은 같은 질문을 네트워크에도 던집니다. 프론티어가 어디까지 진행했는지, 타임스탬프의 순서가 어떻게 구성되어 있는지를 전송 계층이 직접 이해하면, 애플리케이션이 매번 바이트 배열로 변환하고 다시 해석하는 과정이 필요 없어집니다.

참고 문헌

1. D. G. Murray, F. McSherry, R. Isaacs, M. Isard, P. Barham, and M. Abadi, “Naiad: A Timely Dataflow System,” in Proceedings of the 24th ACM Symposium on Operating Systems Principles (SOSP ’13), ACM, 2013, pp. 439–455. Available at: https://sigops.org/s/conferences/sosp/2013/papers/p439-murray.pdf
2. F. McSherry, D. G. Murray, R. Isaacs, and M. Isard, “Differential Dataflow,” in Proceedings of the 6th Biennial Conference on Innovative Data Systems Research (CIDR ’13), CIDR, Jan. 2013. [Link]
3. F. McSherry, “Minimize copies – GitHub Issue #111.” 2019. Available at: https://github.com/TimelyDataflow/timely-dataflow/issues/111
4. M. P. Sharabayko, M. A. Sharabayko, J. Dube, and J. Kim, “SRT: The Secure Reliable Transport Protocol,” IETF, Internet-Draft draft-sharabayko-srt-01, 2020. Available at: https://datatracker.ietf.org/doc/draft-sharabayko-srt/
5. J. Iyengar and M. Thomson, “QUIC: A UDP-Based Multiplexed and Secure Transport,” RFC Editor, RFC 9000, May 2021. Available at: https://www.rfc-editor.org/rfc/rfc9000
6. B. Li et al., “ClickNP: Highly Flexible and High Performance Network Processing with Reconfigurable Hardware,” in Proceedings of the ACM SIGCOMM 2016 Conference, ACM, 2016, pp. 1–14.
7. F. McSherry, “Abomonation: A mortifying serialization library for Rust.” 2015. Available at: https://github.com/TimelyDataflow/abomonation

관련 글

• Datalog의 증분 계산: Differential Dataflow
• RDF 처리에 CPU와 메모리가 중요한 이유
• SPARQL의 SQL 유사성이 주는 함정, 그리고 Datalog

하지만 Datalog를 실제 시스템에 적용하려면, “데이터가 변하면 어떻게 하는가”라는 문제를 피할 수 없습니다.

쇼핑몰의 추천 시스템을 예로 들면, 고객이 새 상품을 하나 구매할 때마다 모든 고객의 추천 목록을 처음부터 다시 계산하는 것은 현실적이지 않습니다. 영향받는 추천만 갱신하면 됩니다. 그런데 전통적인 Datalog 엔진은 사실 하나가 바뀌면 전체 추론을 처음부터 다시 수행합니다.

정적 Datalog의 한계

쇼핑몰에서 “함께 구매되는 상품” 데이터를 기반으로 연관 제품을 추천하는 시나리오로 이 문제를 살펴봅니다. 노트북을 산 사람은 마우스, 파우치, 가방을 함께 사는 경향이 있고, 마우스를 산 사람은 마우스패드를, 파우치를 산 사람은 가방을 새로 구매하는 경향이 있습니다. 이 연쇄를 따라가면, 노트북 구매자에게 마우스패드까지 추천할 수 있습니다. Datalog로 표현하면 다음과 같습니다.

bought_together("노트북", "마우스").
bought_together("노트북", "파우치").
bought_together("노트북", "가방").
bought_together("마우스", "마우스패드").
bought_together("파우치", "가방").

% 연관 추천 (재귀)
recommends(X, Y) :- bought_together(X, Y).
recommends(X, Y) :- bought_together(X, Z), recommends(Z, Y).

이 규칙을 평가하면 직접 연관뿐 아니라, recommends("노트북", "마우스패드")처럼 재귀적으로 도출하는 추천까지 만들어냅니다. 특히 recommends("노트북", "가방")은 직접 구매 경로와 파우치를 경유하는 경로, 두 가지로 도출됩니다.

여기에 새로운 구매 패턴을 발견하여 사실 하나를 추가하는 상황을 살펴봅니다.

bought_together("가방", "보조배터리").   % 새로운 사실 추가!

나이브(Naive)한 Datalog 엔진은 기존에 도출된 모든 recommends 관계를 버리고, 처음부터 전체 추론을 다시 실행합니다. 상품이 네 개일 때는 문제가 되지 않지만, 수백만 개의 상품과 수억 건의 구매 이력을 가진 대형 쇼핑몰에서는 치명적인 비용이 됩니다.

이에 대한 고전적인 해법으로 세미나이브 평가(Semi-naive Evaluation)가 있습니다. 이전 반복에서 새로 도출된 사실만을 다음 반복의 입력으로 사용하여 중복 계산을 줄이는 기법입니다. 하지만 세미나이브 평가에도 한계가 있습니다. 사실의 추가에는 비교적 잘 대응하지만, 삭제에는 취약합니다. 마우스가 단종되어 bought_together("노트북", "마우스")를 삭제하면, 마우스를 경유해서 도출했던 recommends("노트북", "마우스패드") 같은 추천도 무효화해야 합니다. 어떤 추천이 영향받는지를 추적하려면, 결국 상당 부분을 다시 계산해야 합니다.

Differential Dataflow: 차이만 계산하는 발상

2013년, Frank McSherry 등은 이 문제에 대한 근본적으로 다른 접근법인 Differential Dataflow를 제안했습니다[1].

핵심 아이디어는 단순합니다. 컬렉션을 정적인 집합으로 보지 않고, 시간에 따른 차이(Difference)의 축적으로 표현하는 것입니다.

시점 $t$에서의 컬렉션은, 그 시점 이전에 발생한 모든 변경분($\Delta$)의 합산입니다. 삽입은 $+1$, 삭제는 $-1$로 기록합니다. 이 방식은 메모리 관리에서의 레퍼런스 카운팅(Reference Counting)과 구조적으로 닮아 있습니다. 레퍼런스 카운팅에서 객체의 참조가 생기면 카운트를 $+1$, 참조가 사라지면 $-1$하여 카운트가 $0$이 되면 객체를 해제하듯, Differential Dataflow에서도 각 튜플의 가중치가 $0$이 되면 해당 사실이 컬렉션에서 사라집니다. 다만 Differential Dataflow는 이를 단순한 생존 여부를 넘어 가중 집합(weighted set, 혹은 Z-set)으로 일반화합니다. 가중 집합이란 각 원소에 정수 가중치를 부여한 집합으로, 일반 집합이 “있다/없다”만 표현할 수 있는 반면, 가중 집합은 “몇 번 도출되었는가”까지 표현합니다. 앞의 예에서 recommends("노트북", "가방")은 직접 구매 경로와 파우치를 경유하는 경로, 두 가지로 도출되므로 가중치가 $2$입니다. 이때 파우치와 가방의 연관이 사라져 한 경로가 무효화($-1$)되더라도 가중치가 $1$로 남아 있으므로 해당 추천은 여전히 유효합니다. 레퍼런스 카운팅이 참조 수로 객체의 생존을 결정하듯, 가중 집합은 도출 경로의 수로 사실의 유효성을 결정하는 것입니다.

추천 시스템의 예에 적용하면, 추천 목록(Collection)은 과거 구매 이력 변화(Difference)의 누적이며, 새 구매 패턴을 발견하면 영향받는 추천만 갱신하면 됩니다.

이 접근이 강력한 이유는 ‘시간’의 개념을 단순한 일련번호가 아니라 부분 순서(Partial Order)로 일반화하기 때문입니다. 예를 들어 Datalog의 재귀 규칙을 평가할 때, 시간은 (외부 시점, 내부 반복 횟수)라는 2차원 좌표가 됩니다. Differential Dataflow는 뫼비우스 역변환(Möbius Inversion)이라는 수학적 기법을 사용하여 이러한 다차원 시간 축에서도 차이를 정확하게 계산합니다.

이 모든 것은 Timely Dataflow라는 분산 데이터플로우 런타임 위에서 동작합니다. Timely Dataflow가 데이터의 흐름과 병렬 실행을 관리하고, Differential Dataflow가 그 위에서 증분 계산의 논리를 담당하는 구조입니다.

일괄 처리, 스트림 처리, 그리고 Differential Dataflow

기존의 데이터 처리 패러다임과 비교하면 Differential Dataflow의 위치가 명확해집니다.

일괄 처리는 전체를 다시 계산하므로 정확하지만 느리고, 스트림 처리는 빠르지만 재귀적 추론을 표현하기 어렵습니다. Differential Dataflow는 변경의 크기에 비례하는 비용으로 재귀를 포함한 복잡한 연산을 증분적으로 유지합니다.

DDlog: Datalog를 증분으로 만들다

Differential Dataflow의 개념을 Datalog에 직접 적용한 것이 Differential Datalog(DDlog)입니다.

DDlog의 핵심은 다음과 같습니다.

프로그래머는 평범한 Datalog 규칙을 작성하고, DDlog 컴파일러가 이를 자동으로 증분 실행 가능한 Differential Dataflow 파이프라인으로 변환한다.

// DDlog 규칙
input relation BoughtTogether(item: string, related: string)
output relation Recommends(item: string, recommended: string)

Recommends(x, y) :- BoughtTogether(x, y).
Recommends(x, y) :- BoughtTogether(x, z), Recommends(z, y).

// 런타임 동작:
// BoughtTogether("가방", "보조배터리") 삽입 →
// Recommends에서 변경된 튜플만 자동으로 전파
// BoughtTogether("파우치", "가방") 삭제 →
// Recommends("노트북", "가방")의 가중치가 2→1로 갱신 (직접 구매 경로 유지)

프로그래머 입장에서는 일반적인 Datalog를 작성하는 것과 동일합니다. 하지만 런타임의 동작은 근본적으로 다릅니다. 입력 관계(relation)에 삽입이나 삭제가 스트리밍으로 들어오면, 출력 관계에서 변경된 부분만 자동으로 갱신합니다. 세미나이브 평가가 해결하지 못했던 삭제 문제까지 처리합니다.

Rust로 만져보는 Differential Dataflow

Differential Dataflow의 정식 구현체(canonical implementation)는 Rust로 작성한 라이브러리입니다. differential-dataflow 크레이트(crate)를 사용하면, 앞서 살펴본 연관 추천 계산을 다음과 같이 표현할 수 있습니다.

use differential_dataflow::input::Input;
use differential_dataflow::operators::Iterate;
use differential_dataflow::operators::Join;
use differential_dataflow::operators::Consolidate;

timely::execute_directly(move |worker| {
    let (mut input, probe) = worker.dataflow(|scope| {
        let (input, edges) = scope.new_collection::<(String, String), isize>();

        // Datalog의 recommends 규칙과 동일한 연관 추천 계산
        let recommendations = edges.iterate(|reach| {
            let edges = edges.enter(&reach.scope());
            reach
                .join_map(&edges, |_mid, src, dst| (dst.clone(), src.clone()))
                .concat(&edges)
                .distinct()
        });

        let probe = recommendations.consolidate().probe();
        (input, probe)
    });

    // 시점 0: 초기 구매 패턴 입력
    input.insert(("노트북".into(), "마우스".into()));
    input.insert(("노트북".into(), "파우치".into()));
    input.insert(("노트북".into(), "가방".into()));
    input.insert(("마우스".into(), "마우스패드".into()));
    input.insert(("파우치".into(), "가방".into()));
    input.advance_to(1);
    input.flush();
    worker.step_while(|| probe.less_than(input.time()));

    // 시점 1: 새로운 구매 패턴 추가 — 변경분만 재계산
    input.insert(("가방".into(), "보조배터리".into()));
    input.advance_to(2);
    input.flush();
    worker.step_while(|| probe.less_than(input.time()));
});

advance_to(1)에서 advance_to(2)로 진행할 때, 시스템은 ("가방", "보조배터리") 추가로 인해 영향받는 추천 관계만 증분적으로 계산합니다. 기존의 ("노트북", "마우스"), ("마우스", "마우스패드") 등 기존 추천 추론은 그대로 유지됩니다.

진화하는 지식 그래프를 위하여

현실 세계의 지식 그래프는 정적이지 않습니다. 새로운 논문이 나오면 인용 관계가 바뀌고, 조직 개편이 일어나면 보고 체계가 변하며, 쇼핑몰에서는 매 시간 새로운 구매 패턴이 생깁니다. 대화형 AI 에이전트의 경우에도, 사용자가 요구사항을 추가하거나 수정할 때마다 지식 그래프의 상태는 계속 변합니다. 이런 상황에서 매번 전체 추론을 다시 수행하는 것은 비현실적입니다.

Differential Dataflow는 지식 그래프의 변경을 차이(Difference)로 표현하고, 추론 결과를 증분적으로 유지함으로써, 변화하는 데이터 위에서 실시간으로 추론할 수 있게 합니다.

최근에는 이 핵심 아이디어를 데이터베이스와 스트림 처리에 특화시킨 DBSP(Database Stream Processing)도 등장했습니다. Materialize와 같은 시스템이 이를 기반으로 SQL 뷰의 증분 유지(Incremental View Maintenance)를 구현하고 있으며, 증분 계산의 영향력은 논리 프로그래밍을 넘어 더 넓은 데이터 생태계로 확장되고 있습니다.

마치며

전통적인 Datalog는 “변하지 않는 사실”을 전제로 합니다. 모든 데이터를 확정한 뒤에야 추론을 시작할 수 있는 구조입니다. 하지만 현실의 데이터는 계속 변합니다. 신상품이 들어오고, 인기 상품이 사라지며, 구매 패턴은 시시각각 달라집니다.

Differential Dataflow는 데이터의 변화 자체를 계산의 일급 시민(first-class citizen)으로 다룹니다. 변경분만을 추적하고 전파함으로써, 전체 재계산 없이도 정확한 추론 결과를 유지할 수 있게 합니다. 이것이 Differential Dataflow가 논리 프로그래밍에 가져다 준 가장 본질적인 전환입니다.

참고 문헌

1. F. McSherry, D. G. Murray, R. Isaacs, and M. Isard, “Differential Dataflow,” in Proceedings of the 6th Biennial Conference on Innovative Data Systems Research (CIDR ’13), CIDR, Jan. 2013. [Link]

관련 글

• SPARQL의 SQL 유사성이 주는 함정, 그리고 Datalog
• ASP와 Datalog: 논리 프로그래밍의 두 가지 시선
• Askitect 프로토타입: 청사진에서 동작하는 코드로