여기서 <<( ... )>> 안에 들어간 것이 triple term입니다. ex:stmt1은 이 트리플을 가리키는 reifier입니다. rdf:reifies는 둘을 이어 줍니다. RDF 1.2 Concepts 문서도 reifying triple을 이렇게 설명합니다. predicate는 rdf:reifies이고, object는 triple term인 트리플입니다.
employment의 두 번째 컬럼을 stmt(P, "worksAt", C) 패턴으로 구조분해하고, 세 번째 컬럼을 ctx(Start, End, Source) 패턴으로 구조분해합니다. 별도의 reifies relation도, context relation도, ID 조인도 없습니다.
현재 재직 회사를 묻는 규칙은 더 짧습니다. 여기서는 종료일이 0이면 현재 재직 중이라고 두겠습니다.
RDF 1.2에서는 triple term 덕분에 reification이 덜 장황해졌습니다. compound term을 쓰면 Datalog relation 안에서도 비슷한 식으로 구조를 유지할 수 있습니다.
pyrewire로 실행해보기
아래 코드는 로컬에서 pyrewire로 실행해 확인한 코드입니다. stmt와 ctx는 side compound로 선언했습니다. 그래서 Python 쪽에서는 make_compound()로 compound 값을 만들고, employment relation에는 그 handle을 넣습니다.
이 한 줄은 worksAt 진술만 골라서, 그 주어와 목적어와 맥락을 꺼낸다는 뜻입니다. RDF/SPARQL로 치면 triple term과 annotation을 한 번에 펼치는 쿼리에 가깝습니다.
셋째, 애플리케이션 내부 표현으로 가볍습니다.
RDF를 외부와 교환해야 한다면 Turtle 1.2나 RDF dataset을 쓰는 편이 맞습니다. 표준 도구, triple store, SPARQL 생태계와 이어지기 때문입니다. 반대로 애플리케이션 내부에서 “진술과 그 맥락”을 빠르게 검사하고 조금씩 갱신하고 싶다면, compound term 쪽이 가볍습니다.
이 관계를 그림으로 보면 이렇습니다.
graph LR
A["RDF 1.1<br/>rdf:Statement"] --> B["RDF 1.2<br/>triple term"]
B --> C["wirelog<br/>stmt(S, P, O)"]
C --> D["Datalog pattern<br/>stmt(P, worksAt, C)"]
A2["rdf:subject<br/>rdf:predicate<br/>rdf:object"] --> A
B2["rdf:reifies<br/><<(S P O)>>"] --> B
C2["compound column<br/>stmt/3 side"] --> C
물론 둘이 같은 것은 아닙니다. RDF 1.2 triple term은 RDF abstract data model의 일부이고, 웹 표준입니다. wirelog compound term은 Datalog 엔진 안에서 쓰는 값입니다. 하나는 교환 포맷과 의미론의 문제이고, 다른 하나는 실행 엔진의 표현 문제입니다.
다만 이 예제에서는 비슷한 효과가 납니다. RDF 1.2에서는 ex:김철수 ex:worksAt ex:삼성전자라는 트리플을 rdf:subject, rdf:predicate, rdf:object 세 조각으로 풀지 않습니다. triple term 하나로 가리킵니다.
wirelog 쪽에서도 마찬가지입니다. 김철수, worksAt, 삼성전자를 별도 relation에 흩어 놓고 ID로 다시 조인하지 않습니다. stmt(김철수, worksAt, 삼성전자)라는 compound term 안에 함께 둡니다. 그래서 규칙에서는 stmt(P, "worksAt", C)처럼 바로 꺼내 쓸 수 있습니다.
언제 RDF 1.2를 쓰고, 언제 compound term을 쓰나
외부 지식 그래프와 주고받아야 한다면 RDF 1.2 표현이 자연스럽습니다. 여기서 “주고받는다”는 것은 다른 triple store, 다른 팀의 ontology, 또는 RDF를 입력으로 받는 분석 도구에 데이터를 넘긴다는 뜻입니다.
이 형태라면 RDF 도구는 ex:김철수, ex:worksAt, ex:삼성전자, ex:startDate를 모두 IRI로 이해합니다. 다른 그래프와 합치거나, SPARQL로 조회하거나, ontology에 정의된 ex:worksAt의 의미를 따라갈 수 있습니다. 반대로 외부 RDF에서 이 데이터를 읽어와 내부 규칙 엔진으로 넘길 때는 rdf:reifies의 triple term을 읽어 stmt(김철수, worksAt, 삼성전자)로, 나머지 속성을 ctx(...)로 옮기면 됩니다.
반대로 애플리케이션 내부에서 추론하고, 쿼리 결과를 변경분으로 받아보고, Python 값으로 바로 넣고 빼고 싶다면 compound term이 더 직접적입니다. 이 경우에는 매번 Turtle 문자열을 만들고 RDF 파서에 태우는 단계가 필요 없습니다.
지난 글에서 Reification을 설명할 때의 결론은 “트리플 자체에 대해 말할 수 있어야 한다”였습니다. RDF 1.2는 이 요구를 표준 문법과 데이터 모델 안으로 더 가까이 끌어옵니다. wirelog의 compound term은 같은 요구를 Datalog 실행 모델 안에서 다룹니다.
문제는 결국 같습니다. 현실의 사실은 대개 벌거벗은 트리플 하나로 끝나지 않습니다. 언제, 누가, 어떤 근거로, 어느 기간 동안 참인지가 따라옵니다.
RDF 1.1에서는 그 맥락을 붙이려고 트리플을 분해했습니다. RDF 1.2에서는 트리플을 term으로 만들 수 있습니다. 그리고 wirelog에서는 그 term에 해당하는 값을 compound value로 넣고, Datalog 규칙에서 구조분해해 쿼리할 수 있습니다.
표현이 짧아졌다는 것은 단순히 글자 수가 줄었다는 뜻이 아닙니다. 사람이 생각하는 단위와 코드가 다루는 단위가 조금 가까워졌다는 뜻입니다. Reification이 어렵게 느껴졌던 이유도, 어쩌면 그 간격이 너무 컸기 때문인지 모릅니다.
]]>Justin KimAskitect의 SPARQL 루프를 Datalog로 바꾸기2026-06-20T09:00:00+09:002026-06-20T09:00:00+09:00https://groou.com/research/2026/06/20/askitect-datalog-pyrewire지난번 Askitect 프로토타입 글에서는 LLM이 사용자의 자연어를 RDF 트리플로 바꾸고, 그 중간 상태를 SPARQL로 검사하는 구조를 구현했습니다. 사용자가 “친구랑 도쿄 가려고. 맛집이 제일 중요해.”라고 말하면 LLM은 hasDestination, hasCompanionType, hasPriority를 추출하고, SPARQL은 hasDuration과 hasBudget이 빠졌다는 사실을 찾아냈습니다.
그 글의 핵심은 LLM을 추론 엔진으로 쓰지 않는다는 점이었습니다. LLM은 자연어와 구조화된 데이터 사이를 오가는 번역가이고, “무엇이 빠졌는가”를 판단하는 일은 심볼릭 엔진이 맡았습니다. 당시에는 그 심볼릭 레이어를 RDF 그래프와 SPARQL로 구현했습니다.
이번 글에서는 같은 Askitect 루프를 pyrewire로 다시 구현해보려 합니다. 결론부터 말하면, 이 예제의 SPARQL은 Datalog로 충분히 대체할 수 있습니다. 더 정확히 말하면, Askitect가 필요로 하는 것은 “그래프 표준” 자체라기보다 필수 조건과 현재 사실을 비교해 새 사실을 도출하는 작은 규칙 엔진입니다.
바꾸려는 부분
기존 구조는 다음과 같았습니다.
graph LR
User(("User")) -->|자연어| A["Semantic Parser<br/>(LLM)"]
A -->|Turtle| B[("Knowledge Graph<br/>(rdflib)")]
B -->|SPARQL| C{"Completeness<br/>Check"}
C -->|Missing| D["Question Generator<br/>(LLM)"]
C -->|Complete| E["Execute"]
D -->|질문| User
이번에는 가운데만 바꿉니다.
graph LR
User(("User")) -->|자연어| A["Semantic Parser<br/>(LLM)"]
A -->|Python facts| B[("Datalog Facts<br/>(pyrewire)")]
B -->|Rules| C{"Completeness<br/>Check"}
C -->|Missing| D["Question Generator<br/>(LLM)"]
C -->|Complete| E["Execute"]
D -->|질문| User
LLM의 역할은 그대로입니다. 자연어에서 구조를 뽑고, 빠진 속성 목록을 자연스러운 질문으로 바꿉니다. 달라지는 것은 상태 표현과 검증 방식입니다. RDF 트리플과 SPARQL 대신, Datalog의 사실(fact)과 규칙(rule)을 씁니다.
RDF의 URI 대신 짧은 심볼을 썼습니다. 이 예제에서 중요한 것은 RDF 네임스페이스가 아니라, 속성 이름이 안정적인 식별자로 유지된다는 점입니다. 필요하다면 "http://example.org/travel/hasBudget"처럼 전체 URI를 그대로 symbol 값으로 넣어도 됩니다.
이런 형태는 Datalog 관점에서 안전하지 않은 규칙이 되기 쉽습니다. 그래서 먼저 “값이 무엇이든 그 속성이 존재한다”는 present_prop(R, P)로 투영한 뒤, 그 관계를 부정합니다. 실무적으로도 이쪽이 더 읽기 쉽습니다. Askitect가 궁금한 것은 값 자체가 아니라, 그 속성이 채워졌는지 여부이기 때문입니다.
참고로 wirelog의 부정 문법은 not rel(...)이 아니라 !rel(...)입니다. 흔히 Datalog 설명에서는 not을 쓰지만, 현재 wirelog 0.51.0의 문법 문서와 실제 파서는 !Rel(x)를 사용합니다.
pyrewire 코드
이제 Python에서 이 규칙을 실행합니다. 여기서는 이전 노트 그래프 글과 마찬가지로 EasySession을 씁니다.
이 변화는 작지만 중요합니다. RDF를 쓰면 표준 도구와 연결하기 쉽고, 외부 지식 그래프와 합치기 좋습니다. 반면 내부 대화 상태를 검증하는 작은 루프라면, RDF 직렬화와 파싱을 매 턴 거칠 필요가 없을 수 있습니다. Datalog는 이 중간 표현을 더 얇게 만들어줍니다.
조건부 질문도 규칙으로 밀어 넣기
SPARQL 버전의 프로토타입은 모든 필수 속성을 동등하게 다뤘습니다. 하지만 실제 대화에서는 조건부 요구사항이 자주 생깁니다.
예를 들어 해외여행이면 여권 여부를 물어봐야 하지만, 국내여행이면 필요하지 않습니다. 이런 규칙은 Datalog에서 자연스럽게 추가할 수 있습니다.
그러면 hasPassport는 모든 여행에 필요한 속성은 아니지만, international 여행에는 필요한 속성이 됩니다. 이후 missing 규칙은 그대로입니다. 필요한 속성의 집합이 커졌을 뿐, 누락을 찾는 방식은 바뀌지 않습니다.
이 지점이 Datalog가 SPARQL보다 편하게 느껴지는 부분입니다. SPARQL로도 당연히 표현할 수 있습니다. 하지만 규칙이 늘어날수록 “조회 쿼리” 안에 조건을 계속 덧붙이는 느낌이 강해집니다. Datalog에서는 요구사항 자체를 required_for라는 관계로 먼저 도출하고, 그 다음 missing을 도출합니다. 단계가 이름을 갖기 때문에 읽는 사람이 중간 개념을 붙잡기 쉽습니다.
순환 루프에 끼워 넣기
전체 Askitect 루프는 크게 달라지지 않습니다.
defrun_askitect():print("Askitect: 여행 계획을 도와드릴게요. 어디로 가고 싶으세요?")accumulated:dict[str,str]={}whileTrue:user_input=input("User: ")ifnotuser_input:breakparsed=parse_to_structured_facts(user_input)foriteminparsed["facts"]:accumulated[item["property"]]=item["value"]facts=list(accumulated.items())missing=check_completeness(facts)ifnotmissing:print("Askitect: 필요한 정보가 모두 모였습니다!")breakquestion=generate_question(missing,context=user_input)print(f"Askitect: {question}")
여기서 parse_to_structured_facts와 generate_question은 여전히 LLM 호출입니다. 하지만 check_completeness는 LLM과 무관합니다. 같은 입력 사실을 넣으면 같은 missing 결과가 나옵니다.
대화 예시는 기존과 거의 같습니다.
Askitect: 여행 계획을 도와드릴게요. 어디로 가고 싶으세요?
User: 친구랑 도쿄 가려고. 맛집이 제일 중요해.
Askitect: 도쿄 맛집 여행이라니 좋네요. 며칠 정도 다녀오실 계획이세요?
그리고 대략적인 예산 범위도 알려주세요.
User: 3박 4일이고 인당 100만원 정도.
Askitect: 필요한 정보가 모두 모였습니다!
차이는 사용자에게 보이지 않습니다. 내부에서 누락 정보를 판단하는 엔진이 SPARQL에서 Datalog로 바뀌었을 뿐입니다.
SPARQL을 버리자는 이야기는 아니다
이 글의 목적은 SPARQL을 대체 불가능한 표준에서 끌어내리자는 것이 아닙니다. RDF 그래프를 외부와 교환해야 하거나, 이미 온톨로지와 시맨틱 웹 도구 체인 위에서 시스템을 만들고 있다면 SPARQL은 여전히 자연스러운 선택입니다.
다만 Askitect 프로토타입에서 SPARQL이 맡았던 역할은 생각보다 좁았습니다. 그것은 거대한 지식 그래프 질의가 아니라, 현재 대화 상태가 스키마의 요구사항을 만족하는지 확인하는 일이었습니다. 이 정도 범위에서는 Datalog가 더 작고 직접적인 표현을 제공합니다.
비교하면 이렇습니다.
관점
SPARQL 버전
Datalog 버전
상태 표현
RDF 트리플 그래프
관계형 fact
누락 검사
FILTER NOT EXISTS
missing 규칙
중간 개념
쿼리 안의 패턴
이름 붙은 관계
외부 표준 연계
강함
약함
애플리케이션 임베딩
RDF 파싱 필요
Python 값 직접 삽입
Askitect를 지식 그래프 플랫폼의 일부로 만들고 싶다면 RDF/SPARQL이 좋은 출발점입니다. 반대로 하나의 애플리케이션 안에서 대화 상태를 빠르게 검증하고 싶다면, pyrewire 같은 임베디드 Datalog 엔진이 더 가벼운 선택지가 될 수 있습니다.
마치며
이번 실험에서 확인한 것은 Askitect의 핵심이 특정 표준 문법에 묶여 있지 않다는 점입니다. 중요한 것은 역할의 분리입니다.
LLM은 자연어를 구조화된 사실로 번역합니다. Datalog는 그 사실과 규칙을 결합해 missing 같은 새 사실을 도출합니다. 다시 LLM은 그 결과를 사용자에게 자연스러운 질문으로 바꿉니다.
지난 글에서는 이 구조를 RDF와 SPARQL로 구현했습니다. 이번에는 pyrewire와 Datalog로 같은 구조를 다시 만들었습니다. 두 구현은 표면 문법은 다르지만, 아키텍처의 원칙은 같습니다. 확률적 모델에게 언어의 유연함을 맡기고, 심볼릭 엔진에게 판단의 일관성을 맡기는 것. Askitect에서 중요한 것은 바로 그 경계입니다.
]]>Justin KimWITH RECURSIVE로는 답답했던 질문들: 내 노트 그래프에 Datalog 얹기2026-06-06T09:00:00+09:002026-06-06T09:00:00+09:00https://groou.com/research/2026/06/06/datalog-pkm-wirelog지난 글 Datalog, 일상의 도구가 될 수 있을까의 마지막에 이렇게 적어두었습니다. “다음에는 이 고민을 코드로 옮겨볼 생각입니다. 가벼운 Datalog 엔진을 실제 일상적인 문제에 적용해보는 실험을 해보려 합니다.” 이번 글은 그 문장을 실제 코드로 옮겨본 기록입니다.
그때 일상적 유즈케이스 후보로 네 가지를 꼽았습니다. 노트 간 관계, 의존성 분석, 권한 추론, 설정 검증이었습니다. 이 중에서 가장 먼저 손이 간 것은 개인 지식 관리(PKM) 노트 그래프였습니다. 이유는 단순합니다. 별도의 데이터를 새로 만들 필요가 없었기 때문입니다. Obsidian이든 Logseq든, 이미 노트를 쓰고 있다면 링크와 태그가 쌓여 있습니다. 그 자체가 작은 그래프입니다.
엔진은 그동안 여러 글에서 슬쩍슬쩍 언급만 했던 wirelog를 씁니다. 직접 만들고 있는 Datalog 엔진입니다. 마침 Python 바인딩인 pyrewire도 나왔습니다. 지난 글에서 “가벼운 임베디드 Datalog 엔진을 Python에서 한 줄로 부르는” 형태가 가장 그럴듯하다고 적었는데, 적어도 실험 수준에서는 그 그림을 실제로 해볼 수 있게 된 셈입니다.
왜 노트 그래프인가: SQL이 답답해지는 바로 그 지점
지난 글에서 저는 스스로를 한 번 반박했습니다. “재귀적 추론이 필요한 일상적 상황이 드물다”고요. Datalog가 아무리 보기 좋고, SQL의 WITH RECURSIVE가 아무리 답답해도, 정작 그런 질문을 자주 던지지 않는다면 도구를 바꿀 이유가 없습니다. 불편함이 있어도 그 불편함을 느끼는 순간이 드물면, 결국 익숙한 도구가 이깁니다.
그런데 노트 그래프는 그 드문 예외에 꽤 정확히 걸립니다. Obsidian이나 Logseq에서 [[링크]]로 노트를 잇다 보면, 처음에는 한 단계 백링크만 봐도 충분합니다. 이 글이 어디에서 참조되는지, 이 노트가 어디를 가리키는지 정도는 기본 UI로도 잘 보입니다. 문제는 노트가 조금 쌓인 뒤입니다. 그때부터 궁금해지는 질문은 대개 한 단계 링크가 아니라 전이적(transitive) 관계입니다.
틀린 코드는 아닙니다. 실제로도 잘 동작합니다. 다만 이 코드를 매번 쓰고 싶지는 않습니다. WITH RECURSIVE의 앵커 항과 재귀 항을 나누어 적어야 하고, 어디서 재귀가 멈추는지, 중복은 어떻게 제거되는지, UNION을 쓸지 UNION ALL을 쓸지 계속 신경 써야 합니다. 여기에 조건이 하나 더 붙거나 관계가 두세 개로 늘어나면, 쿼리는 금방 “내가 지금 무엇을 묻고 있지?”라는 느낌을 줍니다.
“링크가 있으면 관련 있다. 그리고 한 다리 건너 관련된 것도 관련 있다.” 거의 말 그대로입니다. 여기서 제가 보고 싶었던 차이는 성능보다 표현 방식이었습니다. SQL에서는 재귀를 쿼리 안에 끼워 넣는 느낌이 강한 반면, Datalog에서는 재귀 관계 자체를 규칙으로 선언합니다. 종료는 고정점(fixed-point)에 도달했을 때 엔진이 판단합니다. 사람이 루프를 돌리는 것이 아니라, “이 규칙으로 더 이상 새 사실이 나오지 않을 때까지 적용하라”고 맡기는 쪽에 가깝습니다.
이번 실험의 핵심은 바로 이 차이를 실제 노트 데이터 위에서 확인하는 것이었습니다.
실험 셋업: 노트 볼트를 Datalog 사실(Fact)로 바꾸기
먼저 노트 볼트를 스캔해 Datalog가 다룰 사실로 바꿉니다. 여기서는 일부러 복잡한 파서를 쓰지 않았습니다. 실험의 목적이 마크다운 파싱 자체가 아니라, 노트 그래프를 Datalog로 다뤄보는 데 있었기 때문입니다.
마크다운에서 뽑을 것은 두 가지뿐입니다. [[위키링크]]와 태그입니다. 위키링크는 노트 사이의 간선이 되고, 태그는 노트를 느슨하게 묶는 속성이 됩니다.
importrefrompathlibimportPathLINK=re.compile(r"\[\[([^\]|#]+)")# [[제목]], [[제목|별칭]], [[제목#헤딩]] 모두 제목만
TAG=re.compile(r"(?:^|\s)#([A-Za-z0-9_\-/가-힣]+)")defscan_vault(vault:Path):links,tags=[],[]formdinvault.rglob("*.md"):title=md.stemtext=md.read_text(encoding="utf-8")fordstinLINK.findall(text):links.append((title,dst.strip()))fortinTAG.findall(text):tags.append((title,t))returnlinks,tagslinks,tags=scan_vault(Path("~/Notes").expanduser())print(f"notes linked: {len(links)} edges, {len(tags)} tag assignments")# notes linked: 4123 edges, 1880 tag assignments
제 볼트는 노트 약 1,200개, 링크 4,123개, 태그 1,880건 규모였습니다. 아주 큰 그래프라고 하기는 어렵습니다. 하지만 사람이 백링크 패널을 열어 눈으로 따라가기에는 이미 충분히 큽니다. 직접 링크된 노트는 보이지만, 두 단계나 세 단계 뒤에 무엇이 있는지는 잘 보이지 않습니다. 딱 이 지점부터 “조회”보다 “도출”이 조금씩 의미를 갖기 시작합니다.
규칙과 질의: pyrewire로 추론 돌리기
pyrewire는 wirelog를 Python에서 쓰기 위한 바인딩입니다. Datalog 규칙을 문자열로 전달하고, Python 값으로 사실을 등록한 뒤, 추론 결과를 다시 Python 객체로 읽어올 수 있게 해줍니다. 이번 실험처럼 마크다운 파일을 Python으로 스캔하고, 그 결과를 Datalog 엔진에 전달한 다음, 다시 Python에서 후처리하는 흐름에는 이 형태가 잘 맞습니다.
이제 pip install pyrewire로 패키지를 설치한 뒤, 스키마와 규칙을 전달하고 위에서 추출한 사실을 등록합니다. 여기서는 EasySession을 사용했습니다. 이름 그대로 복잡한 런타임 설정을 직접 만지지 않고, 사실을 하나씩 insert하고 결과를 snapshot으로 읽는 형태입니다.
노트 제목에는 공백도 있고 한글도 있습니다. 이런 문자열을 Datalog 소스 문자열 안에 직접 이어 붙이면 따옴표와 이스케이프를 계속 신경 써야 합니다. 여기서는 Python 리스트로 값을 넘기기 때문에 그 문제를 피할 수 있습니다. 이 작은 편의가 실제 노트 데이터를 넣어볼 때는 꽤 중요합니다.
여기서 엔진에 직접 넣은 것은 link뿐입니다. 그런데 snapshot("related")를 읽어보면 직접 링크되지 않은 노트까지 들어옵니다. “Datalog 소개”에서 “논리 프로그래밍”으로 가고, 거기서 “Prolog”로 가고, 다시 “고정점”으로 이어지는 식의 사슬을 엔진이 바닥부터(bottom-up) 조립해 낸 것입니다.
이것이 Datalog에서 ‘사실’이라고 부르는 이유에서 이야기한 “도출(derivation)”입니다. 단순히 저장된 값을 꺼내는 조회가 아닙니다. 이미 알고 있는 사실과 규칙을 결합해서, 명시적으로 넣지 않았던 새 사실을 만들어 내는 일입니다. 노트 그래프에서는 related("Datalog 소개", "고정점") 같은 관계가 그렇게 생겨납니다.
전체 파이프라인을 그림으로 보면 이렇습니다.
graph LR
A[Obsidian 볼트<br/>*.md] -->|regex 스캔| B[Facts<br/>link/2, tag/2]
B -->|EasySession.insert| C[wirelog 엔진<br/>고정점 평가]
C -->|snapshot / step| D[추론된 관계<br/>related, cotag]
D --> E[Python에서<br/>후처리·질의]
style C fill:#e6f3ff,stroke:#0066cc,stroke-width:1px
같은 태그로 묶인 노트 클러스터
링크만 보면 주로 “한 노트에서 다른 노트로 갈 수 있는가”를 묻게 됩니다. 여기에 태그를 사실로 더하면 조금 다른 것도 볼 수 있습니다. 예를 들어 “직접 링크하지 않았지만 같은 주제를 공유하는 노트는 무엇인가” 같은 것입니다.
결과의 각 튜플은 같은 태그를 공유하는 노트 쌍입니다. 두 노트가 직접 링크되어 있다는 뜻은 아닙니다. 같은 태그를 통해 느슨하게 같은 주제권에 들어온다는 뜻에 가깝습니다.
여기서 a < b 필터는 일부러 Datalog가 아니라 Python에서 했습니다. cotag(A, B) 규칙만 쓰면 같은 노트끼리의 쌍(A = A)도 나오고, (A, B)와 (B, A)가 함께 나옵니다. 이걸 Datalog 안에서 더 정교하게 처리할 수도 있겠지만, 여기서는 그럴 필요를 느끼지 못했습니다. 결과를 받아온 뒤 Python에서 한 줄로 걸러내는 편이 더 읽기 쉽습니다.
이 대목이 의외로 중요했습니다. Datalog를 쓰기 시작하면 모든 문제를 규칙으로 옮기고 싶어집니다. 하지만 그 순간 도구가 목적을 앞서기 쉽습니다. 이번 실험에서 제가 얻은 감각은 “어디까지 Datalog로 두고, 어디부터 Python으로 빼야 하는가”에 가까웠습니다.
고아 노트는 Datalog로 풀지 않았다
“어디서도 참조되지 않는 노트”도 처음에는 Datalog로 풀어볼까 생각했습니다. 하지만 이 질문은 부정(negation)이 필요합니다. 전체 노트 집합에서, 링크의 목적지로 등장한 노트를 빼면 됩니다.
그리고 다시 생각해보면, 이건 재귀도 아니고 전이도 아닙니다. 단순한 집합 차집합입니다. 그래서 그냥 Python에 맡겼습니다.
여기서 고아 노트는 “어디에서도 링크의 목적지로 등장하지 않은 노트”입니다. 노트 자체가 쓸모없다는 뜻은 아닙니다. 아직 다른 노트에서 참조하지 않았거나, 제목이 바뀌면서 링크가 끊겼거나, 단순히 독립적인 메모일 수 있습니다.
지난 글에서 “도구가 주는 가치가 전환 비용을 넘지 못하면 채택은 일어나지 않는다”고 적었는데, 그 기준을 스스로에게 적용한 셈입니다. 차집합 한 줄로 끝나는 일에 엔진을 부르는 건 과합니다. 이 정도 작업은 Python의 집합 연산이 더 직접적이고, 더 읽기 쉽습니다.
제 결론은 조금 좁습니다. Datalog는 재귀·전이가 등장하는 순간에만 제값을 합니다. 그 밖의 일까지 억지로 끌어안기 시작하면, 오히려 일상 도구로 쓰기 어려워집니다.
wirelog가 일반 Datalog와 다른 점: 증분
여기까지는 사실 어떤 Datalog 엔진으로도 됩니다. 링크를 넣고, 전이 폐쇄를 구하고, 결과를 읽는 정도라면 특별히 wirelog여야 할 이유는 없습니다. 제가 wirelog를 굳이 만들고 있는 이유는 증분 계산 쪽에 있습니다.
노트는 한 번에 완성되는 데이터가 아닙니다. 오늘 한 장 쓰고, 내일 한 장 고치고, 어떤 날은 링크 하나만 추가합니다. 이런 변화는 전형적인 “사실 하나 추가” 또는 “사실 하나 제거” 상황입니다. 나이브한 엔진이라면 이때 전체 추론을 처음부터 다시 돌립니다. 그래프가 작을 때는 괜찮지만, 데이터가 계속 자라면 금방 부담이 됩니다.
wirelog는 timely-differential dataflow 위에서 바뀐 부분만 전파합니다.
step()은 그 전파되는 델타를 (relation, row, diff)로 그대로 보여줍니다. diff = +1은 새로 도출된 사실이고, -1은 철회된 사실입니다. 전체 결과를 다시 덤프하는 것이 아니라, 이번 변경 때문에 무엇이 새로 생겼고 무엇이 사라졌는지를 보는 방식입니다.
withEasySession(SRC_RELATED)ass:forsrc,dstinlinks:s.insert("link",[src,dst])s.snapshot("related")# 초기 그래프 확정
# 새 노트 한 장: "Magic Sets" → "Datalog 소개" 로 링크
s.insert("link",["Magic Sets","Datalog 소개"])forrelation,row,diffins.step():print(relation,row,diff)# related ('Magic Sets', 'Datalog 소개') 1
# related ('Magic Sets', 'Prolog') 1
# related ('Magic Sets', '고정점') 1
# ... (Magic Sets에서 새로 닿게 된 노트만 +1로 출력)
출력은 전체 related 관계가 아니라, 이번 변경으로 새로 생긴 사실만 보여줍니다.
related ('Magic Sets', 'Datalog 소개') 1
related ('Magic Sets', 'ASP') 1
related ('Magic Sets', 'Prolog') 1
related ('Magic Sets', 'RDF') 1
related ('Magic Sets', '고정점') 1
related ('Magic Sets', '논리 프로그래밍') 1
related ('Magic Sets', '재귀') 1
이 예제에서는 새 노트 “Magic Sets”가 “Datalog 소개”를 가리키는 링크 하나를 추가했습니다. 그러면 “Magic Sets”에서 직접 닿는 노트뿐 아니라, “Datalog 소개”를 거쳐 닿을 수 있는 노트들이 related 사실로 새로 생깁니다.
중요한 점은 기존 4천여 개의 관계를 다시 계산하지 않는다는 것입니다. “Magic Sets”가 새로 닿게 된 노트들만 증분으로 튀어나옵니다. 노트를 한 장 쓸 때마다 그래프 전체를 재평가하지 않아도 된다는 것. PKM처럼 끊임없이 조금씩 자라는 데이터에서는 이 성질이 특히 잘 맞습니다.
한계와 남은 과제
여기까지 해보고 나니, Datalog를 노트 도구 위에 얹을 때의 경계도 어느 정도 보였습니다. 노트 전체를 Datalog로 다루겠다는 접근은 과합니다. 직접 링크와 단순 검색은 기존 도구로 충분하고, Datalog가 필요한 지점은 생각보다 좁았습니다.
대부분의 질문에는 여전히 백링크 패널과 grep이면 충분합니다. 특정 노트가 어디에서 언급되는지, 특정 단어가 어느 파일에 들어 있는지 확인하는 일은 기존 도구가 더 빠릅니다. Datalog가 이기는 구간은 “전이적 관계”와 “조금씩 갱신되는 그래프”로 꽤 좁습니다. 그 밖에서는 전환 비용이 가치를 넘지 못한다는 지난 글의 결론이 그대로 유효했습니다.
사실 추출의 품질이 전부입니다. 이번 실험에서는 정규식으로 [[ ]]와 태그를 뽑았습니다. 간단해서 좋지만, 코드블록 안의 [[ ]]나 별칭·헤딩 링크에서 어긋나기 쉽습니다. 결국 시맨틱 태깅에서 이야기한 “문자열이 아닌 개념으로 잇기” 문제로 되돌아옵니다.
부정·집계는 의도적으로 Python에 남겼습니다. 이번 글에서 검증한 것은 재귀·전이까지입니다. 고아 노트 찾기나 클러스터 후처리까지 엔진 안으로 옮길 수도 있지만, 아직은 그게 더 좋은 선택인지 확신하지 못했습니다. 이 부분은 다음 과제로 둡니다.
엔진 성숙도.wirelog는 아직 0.x이고, pyrewire도 막 1.0.0이 나온 참입니다. 일상 도구라기보다 “일상 도구가 될 수 있는지 확인하는 실험대”에 가깝습니다.
마치며
“특수한 도메인에서만 빛난다”던 Datalog가, 적어도 제 노트 위에서는 일상의 도구에 한 발 다가왔습니다. 다만 그 방식은 거창하지 않았습니다. Obsidian을 대체하거나, 노트 시스템 전체를 논리 프로그래밍으로 다시 만드는 쪽이 아니었습니다.
핵심은 Datalog로 모든 걸 하려 들지 않는 것이었습니다. 재귀와 전이가 나오는 자리에만 규칙 두 줄을 얹고, 나머지는 Python에 맡겼습니다. 그렇게 하니 지난 글에서 그렸던 “기존 워크플로우에 가볍게 얹히는 형태”가 그럭저럭 모양을 갖췄습니다.
다음에는 같은 엔진을 두 번째 후보였던 의존성/영향 분석에 적용해 보려 합니다. “이 모듈을 고치면 무엇이 깨지나”라는 질문은 노트 그래프보다 더 노골적으로 전이 관계를 요구합니다. 그리고 그동안 배경으로만 등장하던 wirelog의 내부 구조도 한 번 제대로 풀어볼 생각입니다. Datalog를 어떻게 nanoarrow 컬럼과 실행 계획으로 컴파일하는지에 대한 이야기입니다.
]]>Justin KimDatalog에서 ‘데이터’ 대신 ‘사실(Fact)’이라고 부르는 이유2026-06-01T09:00:00+09:002026-06-01T09:00:00+09:00https://groou.com/essay/ai/2026/06/01/datalog-fact-vs-dataDatalog나 Prolog 같은 논리 프로그래밍 언어를 이야기하다 보면, 자연스럽게 “이건 데이터가 아니라 사실(fact)과 규칙(rule)으로 이루어져 있다”고 말하게 됩니다. 그런데 생각해보면 표에 들어있는 값이나 그래프에 들어있는 노드나 똑같은 ‘데이터’로 보일 수 있습니다. 그럼에도 굳이 ‘사실’이라는 다른 단어를 가져와서 쓰는 데에는 시스템의 전제와 관련된 분명한 이유가 있습니다. 이 작은 단어의 차이는 궁극적으로 시스템이 단순한 ‘조회’를 넘어 ‘추론(Inference)’과 ‘추리(Reasoning)’로 나아가기 위한 출발점이 됩니다.
데이터(Data)와 사실(Fact)의 미묘한 차이
우리가 보통 ‘데이터’라고 부를 때는 구조나 그릇을 먼저 떠올립니다. 관계형 데이터베이스(RDB)에서는 테이블의 행(row) 하나가 데이터입니다. student 테이블에 (1, '홍길동', '컴퓨터공학')이라는 레코드가 들어있다고 해보죠. 이 자체로는 그냥 값의 묶음입니다. 이 값이 무슨 의미인지는 테이블의 스키마와 애플리케이션의 로직이 알고 있습니다. 테이블이나 구조 밖으로 꺼내면 데이터는 의미를 잃기 쉽습니다. (1, '홍길동', '컴퓨터공학')만 떼어놓고 보면 이것이 학생 정보인지, 교수 정보인지, 동명이인인지 알기 어렵습니다.
반면 ‘사실(Fact)’은 명제(proposition)입니다. 참(true)이라고 선언된 완결된 문장에 가깝습니다. Datalog에서 이를 표현하면 student(1, "홍길동", "컴퓨터공학").이 됩니다. 이 문장은 그 자체로 하나의 주장을 담고 있습니다. 술어(predicate)인 student가 정보의 맥락을 감싸고 있기 때문입니다.
이 둘은 겉보기엔 비슷해 보이지만, 시스템이 이를 다루는 전제가 다릅니다. 데이터베이스에서 레코드는 “저장된 정보”이지만, Datalog에서 fact는 “참으로 알려진 명제”입니다.
사실에서 출발하는 기계적 도출: 추론(Inference)
‘사실(Fact)’이라는 명제가 준비되면, 시스템은 이를 바탕으로 연산을 시작할 수 있습니다. 여기서 등장하는 것이 ‘규칙(Rule)’입니다. 사실과 규칙이 만나면 시스템은 ‘추론(Inference)’을 수행합니다.
데이터베이스에서는 쿼리를 통해 데이터를 ‘조회’하거나 필터링합니다. 하지만 논리 프로그래밍 시스템은 규칙이라는 논리적 뼈대 위에서 기존의 사실들을 결합해 ‘새로운 사실’을 기계적으로 만들어냅니다.
이 규칙은 “어떤 ID와 Name을 가진 사람이 컴퓨터공학 student라는 사실이 참이라면, 그 Name은 engineering_student라는 사실 또한 참이다”라는 선언입니다. Datalog 엔진(추론기, Inference Engine)은 이 규칙을 기존 사실들에 적용하여, 데이터베이스에는 명시적으로 저장되어 있지 않던 engineering_student("홍길동").이라는 새로운 사실을 연역해 냅니다.
추론(Inference)은 수학적이고 기계적인 과정입니다. 주어진 전제(사실)와 논리적 규칙(룰)에 어긋남 없이, 참이라고 보장할 수 있는 새로운 명제들을 바닥부터 쌓아 올리는 작업입니다. 필터링이 아니라 도출(derivation)에 가깝습니다.
추론(Inference)을 넘어선 추리(Reasoning)
그렇다면 추론(Inference)이 모이면 무엇이 될까요? 우리는 종종 추론을 넘어 ‘추리(Reasoning)’라는 단어를 마주하게 됩니다. 두 단어는 혼용되기도 하지만, 인공지능과 지식 표현의 관점에서 보면 그 층위가 조금 다릅니다.
추론(Inference)이 규칙을 적용해 명제를 하나하나 연역해 내는 미시적이고 기계적인 ‘과정(Process)’이라면, 추리(Reasoning)는 그러한 추론들을 엮어서 복잡한 문제를 해결하거나 결론에 도달하는 거시적인 ‘행위(Activity)’에 가깝습니다.
예를 들어, “홍길동은 어느 캠퍼스에서 수업을 듣는가?”라는 질문에 답하기 위해 시스템은 여러 단계의 도약을 거쳐야 합니다.
홍길동이 컴퓨터공학 학생이라는 사실을 찾습니다.
컴퓨터공학 학생은 공과대학 소속이라는 규칙을 적용해 새로운 사실을 추론합니다.
공과대학 소속 학과는 제2캠퍼스를 사용한다는 사실과 결합합니다.
이 모든 기계적 추론(Inference)의 사슬을 엮어, 최종적으로 “홍길동은 제2캠퍼스에서 수업을 듣는다”는 결론을 냅니다.
이 전체의 과정, 즉 목적을 가지고 여러 논리적 도출 단계를 설계하고 연결하여 해답을 찾아내는 행위 자체가 바로 추리(Reasoning)입니다. 단순히 A에서 B가 나온다는 기계적 단계를 넘어, 맥락을 이해하고 여러 사실과 규칙 사이의 경로를 탐색하는 인지적 성격을 띠게 됩니다.
추론과 추리가 층위를 가진 것일까?
앞서 추론과 추리의 층위가 다르다고 언급했지만, 과연 이 둘 사이에 명확한 상하 관계나 층위가 존재하는지는 다시 생각해 볼 문제입니다. 이 차이를 명확히 보기 위해 Datalog 코드 두 개를 비교해 보겠습니다.
먼저 전형적인 추론(Inference)의 예제입니다.
% 사실 (Fact)parent("영희","철수").parent("철수","민수").% 규칙 (Rule)grandparent(X,Y):-parent(X,Z),parent(Z,Y).
엔진은 단순히 조부모 규칙에 맞춰 grandparent("영희", "민수").라는 새로운 사실을 기계적으로 도출합니다. 이것은 주어진 명제와 규칙에 따른 가장 기초적인 연역 과정입니다. Datalog 엔진의 관점에서 보면, 시스템 내부에는 목적 의식이나 거시적인 방향성이 존재하지 않으며 오직 규칙에 따른 이러한 평면적인 연산(Inference)만이 일어납니다.
반면, 이 시스템을 설계하고 질문을 던지는 사람의 관점이 개입되면 이것은 추리(Reasoning)의 영역으로 넘어갑니다. “사내망에서 발생한 보안 규정 위반자를 찾아라”라는 목적을 가진 다음의 예제를 보시죠.
% 사실 (Fact)employee("홍길동","개발팀").access_log("홍길동","보안서버A","2026-06-01").policy("보안서버A","보안팀").% 규칙 (Rule): 단계별 논리 설계% 1. 인가된 접근 권한 정의authorized_access(Person,Server):-employee(Person,Dept),policy(Server,Dept).% 2. 보안 위반 탐지security_violation(Person,Server,Date):-access_log(Person,Server,Date),notauthorized_access(Person,Server).
엔진 입장에서는 이전 예제와 똑같이 주어진 규칙(authorized_access와 security_violation)을 기계적으로 순차 적용하여 security_violation("홍길동", "보안서버A", "2026-06-01").이라는 사실을 하나 더 만들어냈을 뿐입니다.
하지만 사람의 눈으로 보면 이야기가 다릅니다. 직원 정보, 서버 정책, 접속 로그라는 각기 다른 맥락의 사실들을 엮고, ‘권한 확인’과 ‘위반 탐지’라는 다단계 논리 경로를 설계하여 “홍길동이 보안을 위반했다”는 해답에 도달했습니다. 이것은 거시적 목적을 가진 추리(Reasoning)입니다.
결국 추론과 추리의 층위는 시스템 자체의 논리적 구조라기보다, 그것을 바라보는 ‘관점의 차이’에서 비롯됩니다. 밑바닥에서 연산이 돌아가는 기계의 눈으로 보면 모든 것이 동등한 추론(Inference)이지만, 질문을 던지고 해답을 해석하는 사람의 눈으로 보면 그것은 목적을 가진 추리(Reasoning)로 묶입니다. 단순한 연역 엔진이 지식 표현(Knowledge Representation)의 강력한 도구가 되는 이유는, 이 평면적인 연산 과정에 인간이 의미와 맥락을 부여해 입체적인 추리의 과정으로 이끌어낼 수 있기 때문입니다.
닫힌 데이터에서 열린 지식으로
단순히 값을 기록하고 꺼내보는 것이 목적이라면 ‘데이터’라는 이름으로도 충분했을 것입니다. 데이터 대신 굳이 ‘사실(Fact)’이라는 단어를 밑바탕에 두는 것은, 이 시스템의 목적지가 단순한 조회(Query)가 아니라 지식의 확장(Reasoning)에 있기 때문입니다.
참거짓을 판별할 수 있는 명제들을 선언하고(Fact), 그 명제들을 규칙(Rule)으로 엮어 새로운 명제를 기계적으로 도출하며(Inference), 마침내 복잡한 문제의 해답을 찾아가는 과정(Reasoning). 표의 칸을 채우는 데이터 관리(Data Management)의 관점을 벗어나, 사실에서 출발해 논리를 전개하는 지식 표현(Knowledge Representation)의 세계관이 이 작은 용어 차이에 담겨 있습니다.
]]>Justin KimTBox로 LLM 환각을 줄이는 방법: Datalog Facts 수준의 스키마 제약2026-05-13T16:00:00+09:002026-05-13T16:00:00+09:00https://groou.com/research/2026/05/13/datalog-tbox-llm-hallucinationLLM으로 비정형 텍스트에서 구조화된 데이터를 뽑아내다 보면 결국 한 가지 문제가 남습니다. 바로 환각(hallucination)입니다. 모델은 입력에 없는 관계를 만들어내거나, 스스로 새로운 클래스를 정의하거나, 원문에 없는 속성값을 그럴듯하게 채워 넣습니다.
이번 글에서는 이 문제를 프롬프트만으로 억제하는 대신, TBox와 Datalog facts를 이용해 구조적으로 제약하는 방법을 정리해 보았습니다. 완전히 새로운 기법이라기보다는, 온톨로지와 논리 프로그래밍 쪽에서 이미 익숙한 구분을 LLM 추출 파이프라인에 적용해 보는 시도에 가깝습니다.
문제: LLM은 스키마도 데이터도 동시에 생성한다
LLM에게 “이 텍스트에서 지식 그래프를 뽑아줘”라고 요청하면, 모델은 단순히 사실(fact)만 추출하지 않습니다. 어떤 개념을 클래스로 잡을지, 어떤 관계를 속성(property)으로 모델링할지, 심지어 어떤 계층 구조를 둘지까지 즉석에서 결정합니다. 스키마 설계와 데이터 채움을 한 번에 처리하는 셈입니다.
문제는 여기서부터 시작됩니다. LLM은 입력 텍스트에 실제로 존재하는 정보와, 문맥상 있을 법하다고 판단한 정보를 늘 엄격하게 구분하지 않습니다. 예를 들어 Person이라는 클래스를 만들고 나면, 이어서 hasJob이나 livesIn 같은 속성도 자연스럽게 붙일 수 있다고 생각합니다. 원문에 그런 정보가 없어도 말입니다.
입력: "홍길동은 2024년 한국에서 태어났다."
LLM 출력 (환각 포함):
Person(홍길동)
bornIn(홍길동, 한국)
bornYear(홍길동, 2024) # OK
hasNationality(홍길동, 한국) # 애매함
hasJob(홍길동, ???) # 원문에 없음
age(홍길동, 1) # 계산 결과이지 추출된 사실은 아님
스키마와 데이터를 동시에 생성하게 두면 이런 식의 오염이 쉽게 섞입니다.
TBox와 ABox의 구분
Description Logic(DL)이나 OWL에서 온톨로지는 보통 두 레이어로 나누어 설명합니다.
TBox (Terminological Box): 클래스, 속성, 계층 관계, 제약을 정의하는 스키마 레이어입니다. “Person은 Agent의 하위 클래스다”, “hasAge의 치역(range)은 xsd:integer다” 같은 내용이 여기에 들어갑니다.
ABox (Assertional Box): 실제 개별 인스턴스에 대한 사실 레이어입니다. “홍길동은 Person이다”, “홍길동의 나이는 30이다” 같은 주장이 여기에 해당합니다.
Datalog 관점으로 옮겨 보면 TBox는 주로 규칙(rule)과 제약에 가깝고, ABox는 facts에 해당합니다. 규칙은 새로운 사실을 추론하는 데 쓰이고, facts는 추론의 출발점이 되는 기저 데이터입니다.
TBox를 추출 제약으로 제공하기
실제로 프롬프트에 스키마를 명시하는 방식은 이미 많이 쓰입니다. 예를 들어 “Person, Organization, Event 클래스만 사용하고, 속성은 hasName, worksFor, occursAt만 허용한다”는 식으로 모델에게 작업 범위를 알려주는 방식입니다.
이 방식은 어느 정도 효과가 있습니다. 허용된 클래스와 속성을 명시하면, 모델이 임의의 클래스를 새로 만들어내는 빈도는 줄어듭니다. 다만 이것만으로 충분하다고 보기는 어렵습니다.
왜 부분적으로만 효과가 있는가
문제는 LLM이 프롬프트 지시를 항상 완벽하게 따르지는 않는다는 점입니다. 특히 다음과 같은 상황에서 스키마 밖의 출력이 섞입니다.
1. 스키마가 커질수록 준수율이 떨어집니다
TBox가 50개, 100개의 클래스와 속성을 포함하기 시작하면 모델이 컨텍스트 안에서 이를 모두 안정적으로 따라가기가 어려워집니다. 주의가 분산되고, 어느 순간 스키마에 없는 표현이 섞여 들어옵니다.
2. 모호한 입력에서 스키마를 스스로 확장합니다
텍스트에 기존 스키마로 매핑하기 어려운 개념이 등장하면, LLM은 가장 가까워 보이는 표현을 새로 만들어내려는 경향을 보입니다. TBox에 없는 속성을 추가하거나, 기존 클래스를 임의로 세분화하는 식입니다.
3. TBox 자체의 해석에서도 드리프트가 생깁니다
“TBox를 줬으니 그대로 따르겠지”라고 기대하지만, 모델은 그 TBox를 자기 방식으로 해석합니다. hasJob이 없으면 worksAt을 쓰거나, occupation을 만들어내기도 합니다.
결국 TBox를 프롬프트로 제공하는 것만으로는 스키마 일탈을 안정적으로 막기 어렵습니다.
핵심 아이디어: TBox는 사람이 만들고, LLM은 ABox만 채운다
여기서는 역할을 나누는 편이 낫습니다.
이 구성에서 LLM은 TBox를 생성하지 않습니다. 이미 만들어진 TBox를 참조 스키마로 받아 보고, 그 범위 안에서만 facts를 추출합니다. 작은 차이처럼 보이지만 실제 파이프라인에서는 큰 차이를 만듭니다.
모델에게 주어지는 작업도 단순해집니다.
“이 텍스트에서 온톨로지를 설계하고 인스턴스를 추출해” (스키마 설계 + 데이터 추출)
“이 TBox에 정의된 클래스와 속성만 써서, 텍스트에 실제로 나오는 사실만 Datalog facts로 뽑아줘” (데이터 추출만)
작업 범위가 ABox 채우기로 좁혀지면, 모델이 임의로 결정할 수 있는 영역도 같이 줄어듭니다.
여기서 LLM이 hasJob(홍길동, 의사)를 만들어내려 해도, TBox에 hasJob이 없으면 출력 검증 단계에서 걸러낼 수 있습니다. 단순히 프롬프트로 “이것만 써라”라고 지시하는 것이 아니라, 파싱과 검증 레벨에서 TBox 밖의 심볼을 차단하는 방식입니다.
Datalog facts 형식은 이런 검증을 구현하기에 적합합니다. 각 fact가 predicate(arg1, arg2, ...) 형태이므로, predicate name이 TBox에 등록되어 있는지 확인하는 과정은 단순한 집합 조회(set lookup)로 처리할 수 있습니다.
추출은 위 타입과 관계만 사용한다.
다른 술어가 필요해 보이면 새 술어를 만들지 말고 unmapped에 넣는다.
unmapped의 source에는 근거가 된 원문 일부를 그대로 둔다.
TBox를 수정하거나 확장할 권한은 없다.
예를 들어 논문 요약에서 “Transformer was pretrained on WMT 2014 English-German”이라는 문장이 나왔는데, 현재 TBox에 evaluated_on이나 pretrained_on이 없다면 모델은 새 predicate를 만들지 않습니다. 대신 다음과 같이 남깁니다.
unmapped(model_transformer,pretrained_on,dataset_wmt_2014_en_de,"Transformer was pretrained on WMT 2014 English-German").
이렇게 하면 LLM은 ABox 추출자로만 일하고, 나머지는 사람이 통제합니다. unmapped에 비슷한 패턴이 계속 쌓이면 사람이 보고 판단할 수 있습니다. “이건 자주 등장하는 관계이니 TBox에 추가하자”라고 결정할 수도 있고, “이건 문맥상 노이즈에 가깝다”라고 버릴 수도 있습니다. 중요한 점은 LLM이 직접 TBox를 건드리지 않는다는 것입니다.
모델이 새 엔티티를 만들 때 prefix를 고르게 하면 자연스럽게 타입 분류를 한 번 더 하게 됩니다. 잘못된 타입 추론도 나중에 grep이나 간단한 validator로 잡아낼 수 있습니다.
이 구성의 장점은 에러가 조용히 사라지지 않는다는 데 있습니다. TBox가 없으면 LLM은 적당해 보이는 관계를 만들어 fact를 계속 채워 넣습니다. 어떤 것이 원문에 근거한 추출이고 어떤 것이 환각인지 나중에 구분하기 어렵습니다. 반면 TBox와 unmapped fallback을 같이 쓰면, 추출하지 못한 후보가 한곳에 모입니다. 그 목록은 단순한 실패 로그가 아니라, 현재 위키나 온톨로지의 빈 곳이 어디인지 보여주는 지도에 가깝습니다.
결국 TBox는 LLM이 모르는 것을 모른다고 표시하게 만드는 장치입니다. 환각을 완전히 막는다기보다는, 환각으로 번질 수 있는 지점을 드러나게 만드는 쪽에 가깝습니다. provenance를 함께 남기는 이유도 같은 맥락입니다.
한계와 남은 과제
물론 이 접근이 모든 문제를 해결하지는 못합니다.
TBox가 커버하지 못하는 정보는 정식 fact가 되지 못합니다.unmapped를 두면 완전히 잃어버리지는 않지만, 쿼리 가능한 지식으로 바로 들어오지는 않습니다. 도메인을 미리 잘 정의해 두지 않으면 recall이 떨어지고, 결국 TBox 설계와 갱신 주기가 병목이 됩니다.
같은 클래스 안에서의 환각은 여전히 가능합니다. 예를 들어 Person이 허용되어 있을 때, 텍스트에 언급되지 않은 사람 이름을 만들어내는 것은 TBox만으로 막기 어렵습니다. 개체 자체를 조작하는 ABox 수준의 환각에는 별도의 NER 기반 검증이나 텍스트 어라인먼트가 필요합니다.
TBox 설계 자체도 쉽지 않습니다. 도메인 전문가가 스키마를 미리 설계해야 하므로 초기 비용이 듭니다. 다만 한 번 잘 만들어 두면 여러 추출 작업에서 재사용할 수 있다는 장점도 있습니다.
왜 Datalog인가
OWL Full처럼 표현력이 높은 온톨로지 언어 대신 Datalog를 택하는 데는 몇 가지 이유가 있습니다.
표현력과 decidability 사이의 균형이 좋습니다. Datalog는 재귀를 허용하면서도 decidable합니다. 추출된 facts 위에 규칙 기반 추론을 적용할 수 있습니다.
기존 Datalog 엔진과 바로 연동됩니다. 추출된 facts를 Soufflé나 DLV 같은 엔진에 바로 넣으면 TBox의 규칙으로 추론을 돌릴 수 있습니다.
이렇게 구성하면 파이프라인도 비교적 단순해집니다.
LLM은 facts 추출만 담당하고, 추론은 Datalog 엔진이 담당합니다. 각 컴포넌트의 책임이 분리되기 때문에 디버깅도 쉬워집니다. 문제가 생겼을 때 모델이 잘못 추출한 것인지, TBox 규칙이 잘못된 것인지, 검증기가 느슨한 것인지 따로 확인할 수 있습니다.
마치며
이 아이디어의 본질은 LLM이 할 수 있는 결정의 자유도를 줄이는 것입니다. 스키마 설계는 모델 밖에서 이루어지고, 모델은 “이 텍스트에 이 사실이 실제로 존재하는가?”만 판단합니다. 환각을 없애는 방법이라기보다는, 환각이 발생할 수 있는 공간을 구조적으로 좁히는 접근에 가깝습니다.
완벽한 해결책은 아닙니다. 개체 수준의 환각을 막으려면 추가 검증이 필요하고, TBox를 미리 잘 만들어야 한다는 전제도 있습니다. 다만 unmapped 같은 fallback을 함께 두면 실패가 조용히 사라지지 않고 검토 가능한 형태로 남습니다. LLM에게 스키마와 데이터를 동시에 만들게 하는 방식보다는 훨씬 안정적인 파이프라인을 구성할 수 있다고 생각합니다.
특히 법률, 의학, 금융처럼 도메인 스키마가 비교적 잘 정의되어 있고 환각의 비용이 큰 분야에서는 이런 접근이 실용적인 대안이 될 수 있습니다. TBox 설계에 초기 비용을 투자하고, 그 스키마 안에서 LLM을 facts 추출기로 사용하는 방식입니다.
관련 키워드
Datalog: 재귀적 쿼리를 지원하는 논리 프로그래밍 언어. 지식 표현과 추론에 자주 사용됩니다.
TBox (T-Box): Description Logic에서 개념(클래스)과 역할(속성)의 계층 구조 및 제약을 정의하는 스키마 레이어입니다.
ABox (A-Box): 개별 인스턴스에 대한 사실 주장(assertion)을 담는 데이터 레이어입니다.
Hallucination: LLM이 입력 근거 없이 사실처럼 보이는 정보를 생성하는 현상입니다.
]]>Justin KimKSUID와 UUIDv7을 동시에 지원하는 경량 UID 생성기: libchronoid 이야기2026-05-02T13:00:00+09:002026-05-02T13:00:00+09:00https://groou.com/research/2026/05/02/ksuid-uuidv7-simd-neon-uidDatalog 엔진을 개발하던 중, 목적에 맞는 ID 생성기가 필요해 직접 구현하게 되었습니다. 단순 난수 기반으로 중복만 피하는 것이 아니라, 생성 순서를 보존하면서 DB 정렬 성능에 악영향을 주지 않아야 했습니다. 동시에 외부 시스템과의 호환성도 중요했습니다. 기존 UID 라이브러리들은 C 외부 의존성이 많아 임베디드 환경이나 서버 확장 모듈에 넣기 부담스러웠기 때문에, 결국 C11 규격 안에서 완전히 통제 가능한 경량 UID 생성기를 직접 만들기로 결정했습니다.
처음에는 KSUID만 지원하려고 했지만, 외부 API나 로그 시스템과 연동하다 보니 범용적인 UUIDv7의 필요성을 느꼈습니다. 어차피 두 형식 모두 타임스탬프 기반이므로, 하나의 라이브러리에서 같이 제공하는 편이 합리적이었습니다.
이 글에서는 libchronoid를 설계하면서 고민했던 부분들과 대량 ID 생성 성능을 끌어올리기 위해 SIMD/NEON을 적용한 과정을 정리해 보았습니다.
왜 KSUID와 UUIDv7을 같이 쓸까요?
KSUID는 20바이트 크기에 4바이트 타임스탬프와 16바이트 페이로드를 담습니다. 타임스탬프가 맨 앞에 위치해 생성 순서대로 정렬하기 좋습니다. 반면 UUIDv7은 2021년 이후 표준화된 시간 기반 UUID로, 128비트 레이아웃 안에 타임스탬프와 랜덤 값을 섞어 넣습니다.
굳이 두 가지를 모두 구현한 이유는 다음과 같습니다.
내부 저장소 인덱싱이나 로그 추출 시에는 정렬이 보장되는 KSUID가 압도적으로 편합니다.
하지만 외부 서비스나 클라이언트와 통신할 때는 범용 표준인 UUIDv7을 내려주는 것이 호환성 면에서 낫습니다.
두 포맷 모두 근본적으로는 ‘시간’을 기반으로 하므로, 타임스탬프 원천(source-of-truth)만 동일하게 유지하면 사실상 같은 ID나 다름없습니다.
결론적으로, 내부 식별자로는 KSUID를 사용하되 외부 API 연동 시에는 UUIDv7을 제공하는 투트랙 전략이 가장 합리적이라고 판단했습니다.
KSUID와 UUIDv7 로직을 디렉토리 레벨에서 명확히 분리하여, 필요한 모듈만 떼어내 소스 레벨에서 통합 빌드할 수 있게 구성했습니다. 무거운 동적 라이브러리(.so/.dll)를 따로 관리할 필요가 없어서, C 확장이 필요한 서버 프레임워크나 리소스가 빡빡한 임베디드 환경에서도 부담 없이 가져다 쓸 수 있습니다.
내부 레이아웃: 16바이트 단위 정렬
KSUID의 기본 구조는 다음과 같습니다.
uint32_t timestamp : 생성 시각 (초)
uint8_t payload[16] : 임의 데이터
UUIDv7 구조는 다음과 같습니다.
uint64_t time_hi : 48비트 타임스탬프 + 버전
uint64_t time_lo : 시퀀스/랜덤
이 두 구조 모두 16바이트 단위로 정렬 가능하고, 대량 생성 시 128비트 로드/스토어를 활용하기 유리합니다.
여기서 timestamp_be를 big-endian으로 저장하는 이유는 정렬 순서를 메모리 레이아웃과 일치시키기 위해서입니다. 이렇게 하면 CPU 아키텍처(Endianness)와 무관하게 언제나 동일한 정렬 결과를 보장할 수 있습니다.
SIMD 적용: 포맷팅과 검증 경로에서 성능 최적화
libchronoid의 SIMD 최적화는 ID 생성이 아니라 포맷팅(문자열 변환)과 검증에 집중했습니다. 생성 함수(chronoid_ksuid_new(), chronoid_uuidv7_new())는 스칼라 코드로 유지하고, 수천 개의 ID를 한 번에 직렬화하는 벌크 함수(chronoid_ksuid_string_batch(), chronoid_uuidv7_string_batch())에서 SIMD로 성능을 끌어올렸습니다.
그 이유는 다음과 같습니다.
생성 경로: 단일 ID 생성 자체는 스칼라 연산만으로도 충분히 가볍고 빨라야 합니다.
포맷팅 경로: 병목은 주로 대규모 데이터를 문자열로 직렬화하거나 역직렬화할 때 발생하므로, 여기서 SIMD 효과가 가장 크게 나타납니다.
/* AVX2 8-wide chronoid_ksuid_string_batch 커널
* 기법: Granlund-Möller multiply-high를 활용한 나눗셈
* 각 KSUID 20바이트를 5개의 32비트 limb로 분해
* 벡터화된 64비트 곱셈-고위수(mulhi64)로 base62 변환
*/staticinline__m256ichronoid_ksuid_mulhi64_avx2(__m256ia,__m256ib){// 64x64 → 128 multiply-high, 4-lane wide// Schoolbook 방식: a*b의 상위 64비트를 벡터로 계산__m256ill=_mm256_mul_epu32(a,b);// low*low__m256ilh=_mm256_mul_epu32(a,b_hi);// low*high__m256ihl=_mm256_mul_epu32(a_hi,b);// high*low__m256ihh=_mm256_mul_epu32(a_hi,b_hi);// high*high// ... 중간 항 누적으로 최종 high 계산}
/* ARM NEON base62 16-byte translate-and-validate
* 파일: chronoid/ksuid/base62_neon.c
*/intchronoid_base62_translate16_neon(uint8_tout[16],constuint8_tin[16]){uint8x16_tv=vld1q_u8(in);// 범위 1: 0-9 → 0-9uint8x16_td=vsubq_u8(v,vdupq_n_u8('0'));uint8x16_td_mask=vcleq_u8(d,vdupq_n_u8(9));uint8x16_td_val=vandq_u8(d_mask,d);// 범위 2: A-Z → 10-35uint8x16_tu=vsubq_u8(v,vdupq_n_u8('A'));uint8x16_tu_mask=vcleq_u8(u,vdupq_n_u8(25));uint8x16_tu_val=vandq_u8(u_mask,vaddq_u8(u,vdupq_n_u8(10)));// 범위 3: a-z → 36-61uint8x16_tl=vsubq_u8(v,vdupq_n_u8('a'));uint8x16_tl_mask=vcleq_u8(l,vdupq_n_u8(25));uint8x16_tl_val=vandq_u8(l_mask,vaddq_u8(l,vdupq_n_u8(36)));// 결과 병합: 16개 문자를 한 번에 처리uint8x16_tvalues=vorrq_u8(vorrq_u8(d_val,u_val),l_val);vst1q_u8(out,values);return0;}
#include<chronoid/uuidv7.h>
#include<stdio.h>intmain(void){chronoid_uuidv7_tuuid;// 현재 시간으로 새 UUIDv7 생성if(chronoid_uuidv7_new(&uuid)!=CHRONOID_UUIDV7_OK){fprintf(stderr,"Failed to generate UUIDv7\n");return1;}// 36자 정규 하이픈 형식으로 포맷팅chars[CHRONOID_UUIDV7_STRING_LEN+1];chronoid_uuidv7_format(&uuid,s);s[CHRONOID_UUIDV7_STRING_LEN]='\0';printf("Generated UUIDv7: %s\n",s);// Output: Generated UUIDv7: 019de2b2-7c56-7e59-98be-2ed3cffbd12ereturn0;}
여기서도 벌크 경로는 큰 차이를 만들어냅니다. 타임스탬프와 버전 비트 삽입을 16바이트 청크 단위로 한 번에 밀어버릴 수 있기 때문입니다.
staticinlinevoidset_uuid7_timestamp(uuid7_t*u,uint64_tts_ms){uint64_ttop=(ts_ms&0xFFFFFFFFFFFFULL)<<16;top|=0x7000ULL;// 버전 7u->parts.hi=htobe64(top|((uint64_t)rand()&0xFFFF));}
이후 lo 필드는 그대로 랜덤/시퀀스 값으로 채우고 htobe64()로 네트워크 바이트 오더를 맞춥니다. 이렇게 메모리 상에 배치해 두면, 외부 시스템에서 UUID를 다룰 때 기대하는 표준 바이트 배열 포맷과 정확히 일치하게 됩니다.
코어 스택 지향: 의존성을 덜어내다
이 라이브러리를 만들면서 지키고자 했던 철학은, 불필요한 기능까지 엮인 ‘풀 스택’ 프레임워크가 아니라 필요한 기능만 쏙 빼서 쓸 수 있는 ‘코어 스택’을 제공하는 것이었습니다.
헤더에는 작은 구조체와 함수 선언만 노출
난수 생성은 xoroshiro128+ 또는 xorshift 같은 가벼운 알고리즘 채택
무거운 외부 암호화(Crypto) 라이브러리 배제
SIMD 관련 코드는 매크로로 분리해 필요 없을 땐 빌드에서 제외 가능
실제로 libchronoid를 -Os 옵션으로 빌드하면 바이너리 크기가 10KB 안팎에 불과합니다. 벌크 연산 루틴마저 제외하면 실행 코드는 훨씬 더 가벼워집니다.
실무 적용 후기
이 라이브러리를 실제 Datalog 엔진에 연동해 보며 느낀 점은 다음과 같습니다.
ID 생성이 병목이 되는 경우는 드물었습니다. 보통은 네트워크나 DB I/O에서 먼저 막힙니다. 하지만 데이터를 Batch Insert로 한꺼번에 밀어 넣을 때는 SIMD로 최적화된 포맷팅 로직 덕분에 직렬화 오버헤드가 눈에 띄게 줄어들었습니다.
UUIDv7 지원은 신의 한 수였습니다. 내부적으로 KSUID가 아무리 편하더라도, 로그 수집기나 메시지 큐 등 외부 시스템과 연동할 때는 다들 표준 UUID 포맷을 기대합니다. 이를 기본 지원하니 연동 과정에서 겪는 호환성 스트레스가 사라졌습니다.
내부 인덱싱에는 역시 KSUID가 깡패입니다. 앞부분 4바이트가 타임스탬프라 굳이 복잡하게 쿼리하지 않아도 시간순 정렬이 보장됩니다. DB에 인덱스 태우거나 시계열 히트맵을 뽑아낼 때 정말 편했습니다.
마치며
시스템 아키텍처를 설계할 때 억지로 단일 ID 포맷만 고집할 필요는 없습니다. 목적에 맞게 내부용으론 KSUID를, 외부 인터페이스용으론 UUIDv7을 제공하는 유연한 접근이 실무에서는 훨씬 유리했습니다.
또한 무거운 라이브러리를 통째로 끌어다 쓰는 대신, 필요한 핵심 로직만 C11로 가볍게 구현해 내재화한 덕분에 장기적인 유지보수 측면에서도 골칫거리를 덜어낸 기분입니다.
릴리즈 계획
현재 libchronoid 은 1.0.1 상태입니다. 이미 두 포맷 모두 충분히 안정화되었고 CI/CD 커버리지도 든든하게 갖추었습니다. 2026-05-02부로 1.0 stable 릴리즈 하였습니다.
]]>Justin Kim순수 소프트웨어로 구현하는 비디오 스태빌라이저: GStreamer 파이프라인의 이해2026-04-30T00:00:00+09:002026-04-30T00:00:00+09:00https://groou.com/engineering/gstreamer/2026/04/30/gstreamer-stabilizer순수 소프트웨어로 구현하는 비디오 스태빌라이저: GStreamer 파이프라인의 이해
왜 소프트웨어 스태빌라이저인가
손으로 촬영한 영상은 항상 떨립니다. 손 떨림, 바람, 움직임—대부분의 영상에는 이런 흔들림이 있죠. 비디오 스태빌라이제이션은 이 문제를 푸는 방법인데, 기술에 따라 세 가지로 나뉩니다.
OIS(Optical Image Stabilization)는 렌즈나 센서 자체를 움직여서 보정하고, EIS(Electronic Image Stabilization)는 자이로 센서 데이터를 써서 보정합니다. 둘 다 하드웨어 지원이 필요하고 성능도 좋습니다. 하지만 우리가 항상 이런 고급 센서에 접근할 수 있는 건 아닙니다.
예를 들어 이미 촬영이 끝난 예전 영상, 자이로 없는 저가형 웹캠, 혹은 센서 정보가 전혀 없는 산업용 카메라를 보정해야 한다면? 이 경우 순수하게 영상의 프레임 정보만으로 흔들림을 감지하고 보정하는 소프트웨어 방식(DIS, Digital Image Stabilization)이 유일한 방법입니다.
이 글에서는 이 소프트웨어 방식을 GStreamer로 구현하는 방법을 살펴봅니다.
세 가지 방식 비교:
구분
OIS
EIS
소프트웨어 (DIS)
효과
최고
우수
중상
지연
거의 없음
낮음
수십 프레임
하드웨어 의존성
높음
중간
없음
기존 영상 적용
불가
불가
가능
비용
높음
중간
낮음
언제 소프트웨어 방식을 쓸까?
실제로 마주치는 상황들:
기존 영상의 후처리: 예전에 찍은 흔들리는 영상을 다시 살려내야 할 때
고정 카메라의 흔들림: 야외의 보안 카메라나 중계 카메라가 강풍에 흔들릴 때
센서가 없는 장비: 스마트폰처럼 자이로를 쓸 수 없는 산업용 카메라의 영상 분석
핵심 아이디어는 간단합니다. 4K 같은 고해상도로 촬영한 뒤, 1080p 같은 낮은 해상도로 출력하는 겁니다. 그러면 가장자리에 화소의 ‘마진’이 생기는데, 카메라가 흔들릴 때마다 이 마진 안에서 화면을 움직여가며 잘라내면 흔들림이 상쇄됩니다.
과거에는 이런 무거운 연산을 실시간으로 처리하는 것이 불가능했지만, 멀티코어 CPU와 GPU의 성능 향상, 그리고 GStreamer와 OpenCV와 같은 도구들 덕분에 이제는 소프트웨어를 활용한 실시간 스태빌라이제이션이 가능하게 되었습니다.
flowchart LR
A["📷 4K 입력<br/>(3840 × 2160)"]
B["🔍 흔들림 감지<br/>Motion Estimation"]
C["🔄 안정화 변환<br/>Homography 적용"]
D["✂️ Safe Zone Crop<br/>안전 영역 추출"]
E["📺 1080p 출력<br/>(1920 × 1080)"]
A --> B --> C --> D --> E
subgraph margin["← 해상도 마진 활용 구간 (약 15~20% 화소 손실) →"]
B
C
D
end
style A fill:#1d3557,color:#fff,stroke:#0d2035
style E fill:#1b4332,color:#fff,stroke:#0a2218
style B fill:#457b9d,color:#fff,stroke:#1d3557
style C fill:#457b9d,color:#fff,stroke:#1d3557
style D fill:#457b9d,color:#fff,stroke:#1d3557
style margin fill:#fff8e1,stroke:#f9a825,stroke-dasharray:6 4
흔들림의 모델: 3축 기반 접근
카메라는 3차원 공간에서 세 방향의 흔들림이 있을 수 있습니다. 각각을 다음과 같이 부릅니다:
Yaw(좌우): Y축을 중심으로 회전. 카메라가 옆으로 흔들립니다.
Pitch(상하): X축을 중심으로 회전. 카메라가 위아래로 기울립니다.
Roll(회전): Z축(렌즈 중심축)을 중심으로 회전. 카메라가 시계/반시계 방향으로 회전합니다.
이 세 가지 움직임을 모두 추적해야 전체 흔들림을 보정할 수 있습니다. 3차원 회전을 2차원 이미지 평면으로 표현할 때는 호모그래피(Homography) 변환을 사용합니다.
프레임 간 변환의 핵심은 세 가지 요소입니다:
$C_t$: $t$번째 프레임에서 측정된 누적 모션 행렬 (카메라가 움직인 량)
$S_t$: $t$번째 프레임에서의 목표 궤적(smooth trajectory). 저주파 모션만 포함.
$B_t$: 보정 변환. $B_t = S_t \cdot C_t^{-1}$
보정 변환 $B_t$를 각 프레임에 적용하면, 카메라의 누적 모션 $C_t$가 목표 궤적 $S_t$로 변환됩니다.
호모그래피 행렬 $H$는 $3 \times 3$ 행렬로, 2D 이미지 평면에서의 임의의 단사 사영 변환을 나타냅니다:
\[\begin{pmatrix} x' \\ y' \\ 1 \end{pmatrix} = H \begin{pmatrix} x \\ y \\ 1 \end{pmatrix} = \begin{pmatrix} h_{11} & h_{12} & h_{13} \\ h_{21} & h_{22} & h_{23} \\ h_{31} & h_{32} & h_{33} \end{pmatrix} \begin{pmatrix} x \\ y \\ 1 \end{pmatrix}\]
이 행렬 하나가 3차원 회전, 스케일 변화, 평행이동 등을 모두 포함할 수 있습니다.
저주파 vs 고주파 분리:
측정된 모션 $C_t$ 중에서:
저주파(Low Frequency): 카메라 워크(deliberate movement). 3~5프레임에 걸친 부드러운 움직임.
고주파(High Frequency): 손떨림(jitter). 1~2프레임 단위의 빠른 진동.
필터(예: Gaussian blur)를 사용해 저주파만 추출하면 $S_t$를 얻을 수 있고, 이를 통해 고주파만 제거할 수 있습니다.
호모그래피의 기하학적 의미
호모그래피 행렬 $H$는 단순히 수치의 집합이 아니라 기하학적 의미를 지닙니다. 이를 분해하면:
\[H = K' R K^{-1}\]
여기서:
$K$: 카메라 내부 파라미터(focal length, principal point).
$R$: 회전 행렬(3×3).
$K’$: 변환 후 카메라 파라미터.
실제로는 $H$를 직접 사용하되, 때로는 이를 회전, 스케일, 평행이동 성분으로 분해하기도 합니다. 예를 들어, roll을 과도하게 보정하는 것을 피하기 위해 roll 성분만 추출하여 제한할 수 있습니다.
평활화 전략
목표 궤적 $S_t$를 계산하는 방법은 여러 가지가 있습니다:
이동 평균(Moving Average): $S_t = \frac{1}{N} \sum_{i=t-N}^{t} C_i$
Gaussian 필터: 최근 프레임에 높은 가중치, 과거로 갈수록 낮은 가중치.
Kalman 필터: 시스템 모델(상수 속도 가정)과 측정치를 결합.
Spline 보간: 부드러운 곡선으로 궤적 모델링.
Kalman 필터가 가장 정확하지만 계산량이 많고, 이동 평균이 가장 간단하지만 지연이 늘어납니다. 실무에서는 보통 Gaussian 필터 with lookahead(향후 정보 활용)를 선택합니다.
(D2 도식 참조 - 3축 회전(Yaw/Pitch/Roll) 시각화)
Motion Estimation: 움직임의 측정
두 프레임 간의 움직임을 측정하는 방법은 크게 두 가지입니다.
방식 1: 특징점 기반 방식(Feature-Based)
프레임에서 특징적인 점(코너, 엣지 등)을 찾아서:
현재와 이전 프레임에서 특징점 검출 (ORB, FAST 등)
두 프레임의 특징점을 매칭 (어떤 점이 어디로 이동했는지 찾기)
RANSAC으로 잘못된 매칭 제거
남은 점들로 호모그래피 계산
장점은 빠르고 간단하다는 것입니다. 밝기가 조금 변해도 잘 작동합니다. 단점은 특징점이 없는 영역(밤하늘, 흰 벽 같은)에서 무너질 수 있다는 점입니다.
방식 2: Dense Optical Flow
모든 픽셀에 대해 움직임을 추정합니다.
Farnebäck: 다항식 계수 기반. 빠름, 중간 정확도.
DIS (Dense Inverse Search): 실시간 비디오용. Farnebäck보다 빠름.
RAFT: 최신 신경망 기반. 정확하지만 느림(5~10 fps @ 1080p).
장점: 밀도 높은 정보, 특징점 의존성 없음.
단점: 계산량 많음, 그래픽 카드 필요(RAFT의 경우).
방식 3: 하이브리드 접근
최근 추세는 두 방식을 결합하는 것입니다:
조대(Coarse) 단계: Dense optical flow로 전체 그림 파악.
세밀(Fine) 단계: Feature-based로 중요 영역 정밀화.
이렇게 하면 특징점이 없는 영역도 처리하고, 계산량도 줄일 수 있습니다.
호모그래피 vs 어파인(Affine) 변환
간단한 경우(평행이동, 회전, 스케일)에는 Affine 변환으로 충분합니다:
\[\begin{pmatrix} x' \\ y' \end{pmatrix} = \begin{pmatrix} a & b \\ c & d \end{pmatrix} \begin{pmatrix} x \\ y \end{pmatrix} + \begin{pmatrix} e \\ f \end{pmatrix}\]
매개변수는 6개(a, b, c, d, e, f)이므로 3개 점이 필요합니다. 호모그래피는 원근 변환까지 포함하므로 8개 매개변수이고 4개 점이 필요합니다.
실무에서는 호모그래피를 기본으로 사용하되, 카메라가 렌즈 중심축에 대해 큰 각도로 회전하지 않는 한 근사적으로 Affine처럼 동작합니다.
성능 팁: 다운샘플 추정
4K(3840×2160) 영상에서 매 프레임마다 호모그래피를 추정하는 것은 느립니다. 대신:
원본을 540p로 다운샘플.
540p에서 호모그래피 $H_{540}$ 추정.
$H_{4K} = \text{scale}(3840/540) \cdot H_{540}$ 로 스케일 조정.
$H_{4K}$를 원본 4K 프레임에 적용.
이 방식으로 계산량을 대략 50배 줄일 수 있습니다.
실패 케이스와 Fallback
호모그래피 추정이 실패할 수 있습니다:
장면 컷(Scene cut): 이전 프레임과 완전히 다른 내용.
대규모 움직임(Fast pan): 특징점이 화면을 벗어남.
움직이는 피사체: 배경 특징점만 감지하여 잘못된 추정.
이 경우 confidence score를 계산하고, 신뢰도가 낮으면:
직전 프레임의 모션 재사용.
또는 항등 변환(Identity transform) 적용 (보정 없음).
신뢰도 점수 계산 방법:
confidence = (RANSAC 내부점 수) / (전체 매칭점 수)
예를 들어, 1000개 점 중 800개가 호모그래피를 만족하면 confidence = 0.8입니다. 보통 임계값(threshold):
importcv2importnumpyasnpdefestimate_homography(prev_frame,curr_frame,downsample_factor=4):"""두 프레임 간 흔들림을 호모그래피로 구합니다.
4K 프레임 전체를 매번 분석하면 너무 느리므로, 해상도를 줄여서 빠르게 계산합니다.
"""prev_gray=cv2.cvtColor(prev_frame,cv2.COLOR_BGR2GRAY)curr_gray=cv2.cvtColor(curr_frame,cv2.COLOR_BGR2GRAY)# 다운샘플
h,w=prev_gray.shapedown_h,down_w=h//downsample_factor,w//downsample_factorprev_down=cv2.resize(prev_gray,(down_w,down_h))curr_down=cv2.resize(curr_gray,(down_w,down_h))# ORB 특징점 검출 및 매칭
orb=cv2.ORB_create(nfeatures=5000)kp1,des1=orb.detectAndCompute(prev_down,None)kp2,des2=orb.detectAndCompute(curr_down,None)ifdes1isNoneordes2isNoneorlen(kp1)<4orlen(kp2)<4:returnnp.eye(3),0.0# Brute-force 매칭
bf=cv2.BFMatcher(cv2.NORM_HAMMING,crossCheck=True)matches=bf.match(des1,des2)iflen(matches)<4:returnnp.eye(3),0.0# 매칭점 추출
src_pts=np.float32([kp1[m.queryIdx].ptforminmatches]).reshape(-1,1,2)dst_pts=np.float32([kp2[m.trainIdx].ptforminmatches]).reshape(-1,1,2)# RANSAC으로 호모그래피 추정
H_down,mask=cv2.findHomography(src_pts,dst_pts,cv2.RANSAC,5.0)ifH_downisNone:returnnp.eye(3),0.0# 신뢰도 계산: RANSAC 내부점 비율
inlier_count=np.sum(mask)confidence=min(1.0,inlier_count/len(matches))# 스케일 조정: 다운샘플 → 원본 해상도
scale_matrix=np.array([[downsample_factor,0,0],[0,downsample_factor,0],[0,0,1]])H=np.linalg.inv(scale_matrix)@H_down@scale_matrixreturnH,confidence
(D3 도식 참조 - Feature 검출→매칭→이상치 제거→호모그래피 파이프라인)
flowchart TD
A["🎬 Frame t"]
B["🎬 Frame t+1"]
C["Step 1 · 두 프레임 수신"]
D["Step 2 · Feature Detection<br/>🔎 ORB / FAST 특징점 검출"]
E["Step 3 · Feature Matching<br/>🔗 KNN 매칭 (k = 2, ratio test)"]
F["Step 4 · Outlier Rejection<br/>🎯 RANSAC 이상치 제거"]
G["Step 5 · Homography 계산<br/>📐 최소자승법 (DLT 알고리즘)"]
H["✅ H 행렬 출력<br/>3 × 3 투시 변환"]
A --> C
B --> C
C --> D --> E --> F --> G --> H
style A fill:#6c3483,color:#fff,stroke:#5b2c6f
style B fill:#6c3483,color:#fff,stroke:#5b2c6f
style C fill:#34495e,color:#fff,stroke:#2c3e50
style D fill:#1a5276,color:#fff,stroke:#154360
style E fill:#1a5276,color:#fff,stroke:#154360
style F fill:#784212,color:#fff,stroke:#6e2f1a
style G fill:#1a5276,color:#fff,stroke:#154360
style H fill:#145a32,color:#fff,stroke:#0e3d22
GStreamer 파이프라인 구현
이제 실제로 이 스태빌라이저를 GStreamer로 구현해봅시다. GStreamer는 오픈소스 멀티미디어 프레임워크로, 작은 부품(Elements)들을 레고처럼 조립해서 영상 처리 파이프라인을 만듭니다.
전체 구조는 이렇습니다:
입력(카메라나 파일) → 디코딩 → 분기 → [모션 추정 경로] + [변환 경로] → 합성 → 인코딩 → 출력
importgigi.require_version('Gst','1.0')fromgi.repositoryimportGst,GLibimportcv2importnumpyasnpclassGStreamerStabilizer:"""
GStreamer 파이프라인에 통합되는 스태빌라이저 클래스.
gststabilizer 커스텀 element의 골격.
"""def__init__(self,downsample=4,lookahead=5):self.downsample=downsampleself.lookahead=lookaheadself.prev_frame=Noneself.motion_history=[]# 모션 벡터 히스토리
self.smooth_trajectory=None# S_t
defprocess_frame(self,frame):"""
한 프레임을 처리합니다.
Args:
frame: (H, W, 3) BGR numpy array
Returns:
H: 3x3 호모그래피 행렬
confidence: 신뢰도
"""ifself.prev_frameisNone:self.prev_frame=framereturnnp.eye(3),1.0# 호모그래피 추정 (§3의 코드 샘플 1 사용)
H,confidence=self._estimate_homography(self.prev_frame,frame)# 모션 히스토리 저장
self.motion_history.append((H,confidence))iflen(self.motion_history)>self.lookahead:self.motion_history.pop(0)# 부드러운 궤적 계산 (Gaussian 필터)
# 실제 구현에서는 Kalman 필터나 더 정교한 방식 사용
smoothed_H=self._compute_smooth_trajectory(H)self.prev_frame=frame.copy()returnsmoothed_H,confidencedef_estimate_homography(self,prev,curr):"""호모그래피 추정. 코드 샘플 1의 함수 사용."""# (여기서는 생략, 실제로는 코드 샘플 1의 함수 호출)
passdef_compute_smooth_trajectory(self,H):"""
현재 호모그래피와 히스토리를 이용해 부드러운 궤적을 계산합니다.
간단한 예: 최근 N프레임의 평균.
"""iflen(self.motion_history)==0:returnH# 호모그래피를 행렬로 축적할 수 없으므로,
# 실제로는 회전/스케일/평행이동 성분을 분해 후 평균
# 여기서는 개념 시연용으로 직접 평균 (부정확함)
avg_H=np.mean([hforh,_inself.motion_history],axis=0)returnavg_Hdefwarp_and_crop(self,frame,H,margin=0.15):"""
호모그래피를 적용하고 마진만큼 crop합니다.
Args:
frame: 입력 프레임
H: 호모그래피 행렬
margin: 마진 비율 (0.15 = 15%)
Returns:
warped_frame: 변환 및 crop된 프레임
"""h,w=frame.shape[:2]# 호모그래피 변환 적용
warped=cv2.warpPerspective(frame,H,(w,h))# Crop 계산
crop_x=int(w*margin/2)crop_y=int(h*margin/2)crop_w=w-2*crop_xcrop_h=h-2*crop_ycropped=warped[crop_y:crop_y+crop_h,crop_x:crop_x+crop_w]# 다시 원본 크기로 스케일 (또는 고정된 출력 해상도)
output_h,output_w=h//2,w//2# 예: 4K → 1080p
final=cv2.resize(cropped,(output_w,output_h))returnfinal# GStreamer 파이프라인 예
defcreate_stabilizer_pipeline():Gst.init(None)pipeline=Gst.Pipeline.new("stabilizer-pipeline")# 요소 생성
source=Gst.ElementFactory.make("v4l2src","source")decoder=Gst.ElementFactory.make("decodebin","decoder")encoder=Gst.ElementFactory.make("x264enc","encoder")sink=Gst.ElementFactory.make("filesink","sink")ifnotall([source,decoder,encoder,sink]):print("Failed to create elements")returnNone# 속성 설정
source.set_property("device","/dev/video0")sink.set_property("location","stabilized.mp4")# 파이프라인에 추가
pipeline.add(source,decoder,encoder,sink)# 링크 (실제로는 더 많은 캡스 필터링 필요)
source.link(decoder)decoder.link(encoder)encoder.link(sink)returnpipeline
AI 기반 고급 보정
기본 호모그래피 기반 스태빌라이저도 효과적이지만, AI 기반 보정으로 한 단계 더 나아갈 수 있습니다.
조명 변화 보정
카메라가 떨릴 때 장면의 밝기가 급격히 변할 수 있습니다. Auto-exposure(자동 노출) 조정이 느려서 일부 프레임이 너무 밝거나 어두워집니다. 이를 조명 flicker라고 부릅니다.
해결 방법:
CNN 기반 denoising: 밝기 변화 패턴을 학습한 신경망으로 평활화(smoothing).
LUT(Lookup Table) 기반: 프레임 간 밝기 차이를 분석하여 히스토그램 매칭.
# 간단한 예: 프레임 간 평균 밝기 차이로 보정
defcompensate_exposure(frame,prev_frame,alpha=0.8):curr_brightness=np.mean(cv2.cvtColor(frame,cv2.COLOR_BGR2GRAY))prev_brightness=np.mean(cv2.cvtColor(prev_frame,cv2.COLOR_BGR2GRAY))# 지수 이동 평균으로 부드럽게 보정
target_brightness=alpha*prev_brightness+(1-alpha)*curr_brightnessadjustment=target_brightness/(curr_brightness+1e-5)returncv2.convertScaleAbs(frame,alpha=adjustment,beta=0)
피사체 인식 기반 안정화
일반적인 스태빌라이저는 모든 픽셀을 동등하게 취급합니다. 하지만 메인 피사체(main subject)가 있다면, 그 영역을 우선적으로 안정화할 수 있습니다.
YOLO(You Only Look Once): 빠른 물체 감지. 실시간 비디오에 적합.
SAM(Segment Anything Model): 프롬프트 기반 세분화. 특정 피사체만 추출.
알고리즘:
YOLO로 메인 객체(사람, 자동차 등) 감지.
해당 BBox(Bounding Box) 내의 특징점에 더 높은 가중치.
가중치가 반영된 호모그래피 추정.
# 의사 코드: 가중치 기반 호모그래피
defweighted_homography(src_pts,dst_pts,weights):"""
가중치가 적용된 RANSAC.
"""# 실제로는 weighted RANSAC 또는 Huber loss 사용
H,mask=cv2.findHomography(src_pts,dst_pts,cv2.RANSAC,5.0)# 가중치는 outlier rejection에 반영
returnH
Edge Inpainting
호모그래피 변환과 crop으로 인해 프레임의 가장자리가 손실됩니다. 이 부분을 복원(inpainting)할 수 있습니다.
전통적: 인접 픽셀 복제 또는 선형 보간.
AI 기반: 조건부 생성 모델(Conditional GAN) 또는 확산 모델(Diffusion Model)로 자연스러운 콘텐츠 생성.
definpaint_edges(frame,mask,kernel_size=5):"""
마스크된 영역을 Telea 알고리즘으로 inpaint합니다.
"""returncv2.inpaint(frame,mask,kernel_size,cv2.INPAINT_TELEA)
GStreamer 통합
AI 모듈을 GStreamer에 통합하는 방법:
gst-nvinfer (NVIDIA DeepStream): NVIDIA GPU에서 추론 실행. 가장 빠름.
ONNX Runtime 커스텀 element: 다양한 백엔드(CPU, GPU) 지원. 더 유연.
TensorFlow Lite: 경량 모델용.
⚠️ GPU 기반 추론은 별도 글에서 자세히 다룰 예정입니다. 여기서는 CPU 기반 처리에 집중합니다.
# 의사 코드
classAIStabilizerModule:def__init__(self):self.yolo_model=load_yolo_model("yolov8n.pt")# nano 버전
self.prev_features=Nonedefprocess(self,frame):# YOLO 추론 (GPU 또는 CPU)
detections=self.yolo_model(frame)# 메인 피사체 추출 (신뢰도 > 0.5)
main_objects=[dfordindetectionsifd.confidence>0.5]ifmain_objects:# BBox 내 특징점에 높은 가중치
weights=self._compute_weights(frame.shape,main_objects)H=self._weighted_homography(frame,weights)else:# 폴백: 기본 호모그래피
H=self._default_homography(frame)returnH
이 방식으로 사람이 많은 환경에서도 주요 피사체(예: 강사, 발표자)의 안정성을 우선할 수 있습니다.
성능 트레이드오프
AI 보정을 추가하면 다음과 같은 트레이드오프가 발생합니다:
측면
CPU 기본
AI 기반
정확도
중간
높음
지연(Latency)
~50ms
~200ms+
리소스
낮음
매우 높음
실시간성
1080p@30fps 가능
1080p@5fps (CPU)
(D6 도식 참조 - 기본 파이프라인 + AI 모듈 추가 시 변경 토폴로지)
graph LR
SRC["📹 v4l2src"]
DEC["avdec_h264<br/>디코더"]
TEE["⬡ tee"]
STAB["⚙️ gststabilizer<br/>모션 추정"]
WARP["✂️ gstwarpcrop<br/>Warp + Crop"]
COMP["compositor<br/>합성"]
ENC["x264enc<br/>mp4mux"]
SINK["📁 filesink"]
EXP["💡 gstexposuresmoothing<br/>조명 변화 보정"]
SAL["👁️ gstsaliencydetector<br/>YOLO / SAM2 피사체 감지"]
EDGE["🖌️ gstedgeinpainter<br/>경계 복원 인페인팅"]
subgraph aimodules["🤖 AI 확장 모듈 (심화 편 예정)"]
EXP
SAL
EDGE
end
SRC --> DEC --> TEE
TEE -->|"추정 경로"| STAB
TEE -->|"변환 경로"| WARP
STAB -.->|"H 행렬"| WARP
STAB --> COMP
WARP --> EXP --> SAL --> EDGE --> COMP
COMP --> ENC --> SINK
style SRC fill:#2c3e50,color:#fff,stroke:#1a252f
style DEC fill:#34495e,color:#fff,stroke:#2c3e50
style TEE fill:#e67e22,color:#fff,stroke:#d35400
style STAB fill:#27ae60,color:#fff,stroke:#1e8449
style WARP fill:#27ae60,color:#fff,stroke:#1e8449
style COMP fill:#8e44ad,color:#fff,stroke:#6c3483
style ENC fill:#34495e,color:#fff,stroke:#2c3e50
style SINK fill:#2c3e50,color:#fff,stroke:#1a252f
style EXP fill:#1a5276,color:#fff,stroke:#154360
style SAL fill:#1a5276,color:#fff,stroke:#154360
style EDGE fill:#1a5276,color:#fff,stroke:#154360
style aimodules fill:#d6eaf8,stroke:#2980b9,stroke-dasharray:6 4
색상 범례:
🟢 녹색 박스 = 기본 CPU element (gststabilizer, gstwarpcrop)
🔵 파란 박스 = AI 가속 element (별도 글에서 상세 설명 예정)
🟠 주황 = tee 분기점 / 🟣 보라 = compositor
D4: GStreamer 메인 파이프라인 (Mermaid graph) - tee/queue/커스텀 element 토폴로지
D5: Crop window 계산 시각화 (SVG 인라인) - 입력 프레임 + safe zone + 출력 영역
D6: AI 모듈 추가 토폴로지 (Mermaid graph) - 기본 파이프라인 + CNN/YOLO 분기
]]>Justin KimSymbolic AI에서 Datalog가 필요한 이유2026-03-26T12:00:00+09:002026-03-26T12:00:00+09:00https://groou.com/essay/datalog/2026/03/26/prolog-datalog-symbolic-aiDatalog와 Prolog는 논리 프로그래밍(Logic Programming)이라는 동일한 뿌리에서 파생되어 시각적으로 매우 유사한 문법을 공유하고 있습니다. 때문에 Datalog를 처음 접하게 되면 이미 익숙하고 범용적인 Prolog와의 실질적인 차이를 체감하기 쉽지 않습니다.
하지만 그 동작 원리와 목적을 자세히 들여다보면 이 둘이 지향하는 방향은 완전히 다릅니다. 이 글에서는 겉보기에 비슷해 보이는 두 언어의 근본적인 차이점을 구체적으로 비교하고, 최근 기호주의(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에서 위와 같은 ‘좌측 재귀(Left-recursion)’ 형태로 규칙을 작성하고 순환 그래프를 탐색시키면 큰 문제가 발생합니다. Prolog는 위에서 아래로, 왼쪽부터 파고들기 때문에 끝없이 path(X, Z)를 재귀 호출하며 a -> b -> c -> a -> b... 순으로 영원히 연산을 반복하게 됩니다. 구현자가 이 함정을 회피하기 위해서는 규칙의 순서를 수동으로 조작하거나, 이미 방문한 노드를 일일이 리스트에 기록해 두는 등 복잡한 예외 처리 코드를 추가해야만 합니다.
하지만 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가 자신만의 확고한 입지를 구축하고 있습니다.
]]>Justin Kim캐시 히트율을 위한 Radix Sort 도입 기대2026-03-25T00:00:00+09:002026-03-25T00:00:00+09:00https://groou.com/research/datalog/2026/03/25/radix-sort-in-datalogDatalog 엔진을 구현하다 보면 성능 병목을 해결하기 위해 다양한 최적화 기법을 도입하게 됩니다. 특히 다량의 데이터를 처리해야 하는 데이터베이스나 논리 프로그래밍 엔진에서는 어떤 정렬 알고리즘을 선택하느냐에 따라 전체적인 성능 차이가 극명하게 나타날 수 있습니다.
이번 글에서는 기수 정렬(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)까지, 혹은 그 반대로 각 자릿수를 기준으로 정렬을 반복합니다.
초기화: 0부터 9까지(혹은 진법에 따른 기수만큼)의 버킷(Queue 등)을 준비합니다.
분배: 정렬할 데이터의 일의 자리를 기준으로 각 버킷에 데이터를 넣습니다.
병합: 0번 버킷부터 순서대로 데이터를 다시 가져옵니다.
반복: 십의 자리, 백의 자리 등 가장 큰 자릿수까지 위 과정을 반복합니다.
이렇게 요소 간의 직접적인 크기 비교 없이 자릿수 기반의 버킷 배치를 통해 정렬을 수행하기 때문에, 정수나 문자열 같은 일정한 형식의 키를 가진 데이터를 정렬할 때 매우 강력한 성능을 발휘합니다.
Datalog 엔진 구현에서 정렬이 필요한 이유
Datalog는 선언형 논리 프로그래밍 언어로, 사실(Fact)과 규칙(Rule)을 기반으로 새로운 사실을 추론해 냅니다. 엔진 내부에서는 이러한 추론 과정이 주로 관계형 대수(Relational Algebra) 연산으로 변환되어 실행됩니다.
Datalog 엔진에서 데이터를 정렬해야 하는 주된 이유는 다음과 같습니다.
중복 제거 (Deduplication)
Datalog의 평가 과정(특히 Bottom-up 방식의 Semi-naïve Evaluation)에서는 매 반복마다 새롭게 생성된 데이터(Fact) 중에서 기존의 데이터와 겹치는 중복을 제거해야 합니다. 데이터가 정렬되어 있다면 선형 탐색 한 번만으로 중복된 튜플을 쉽게 걸러낼 수 있습니다.
조인 연산 (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) 특성 덕분에 실제 하드웨어 최우선 과제인 캐시 히트율을 대폭 향상시켜 훨씬 더 빠른 쿼리 응답 속도를 얻을 수 있을 것으로 기대하고 있습니다. 향후 최적화가 완료되면 벤치마킹을 통해 얼마나 속도가 개선되었는지 다시 정리해 보도록 하겠습니다.
]]>Justin Kim시맨틱 태깅, 단순한 키워드를 넘어 지식의 연결로2026-03-22T00:00:00+09:002026-03-22T00:00:00+09:00https://groou.com/essay/knowledge-graph/2026/03/22/semantic-tagging기록이 쌓일수록 고민도 깊어집니다. 우리는 매일 수많은 노트를 작성하고, 나중에 찾기 쉽게 ‘태그’를 답니다. #datalog, #pkm, #ai 같은 키워드들이 그 예입니다. 하지만 시간이 흘러 노트가 수백, 수천 개가 되었을 때, 이 태그들이 정말 우리에게 의미 있는 ‘지식’으로 기능하고 있는지는 돌이켜볼 문제입니다.
키워드 태깅의 한계: 단순한 문자열의 나열
우리가 흔히 쓰는 태깅은 텍스트를 있는 그대로 대조하는 문자열(String) 매칭에 불과합니다. 내가 ‘Datalog’라는 태그를 달았다고 해서 기계가 그것을 ‘선언형 논리 프로그래밍 언어’나 ‘Prolog의 일종’으로 이해하지는 않습니다. 그저 ‘D-a-t-a-l-o-g’라는 7개의 알파벳 조합으로 무미건조하게 받아들일 뿐이죠.
문자가 의미를 제대로 담지 못할 때 여러 답답한 상황이 벌어집니다. 당장 ‘Apple’이라는 태그만 봐도 이것이 과실을 뜻하는지 거대 IT 기업을 의미하는지 문맥 없이는 알 길이 없습니다. 게다가 ‘Datalog’와 ‘Logic Programming’이 서로 어떤 포함 관계인지도 파악하지 못하기 때문에, “논리 프로그래밍에 관한 노트를 다 찾아줘”라고 검색하면 정작 ‘Datalog’ 태그가 달린 핵심 노트들은 모조리 누락되고 맙니다. 기계 입장에서는 두 문자열이 완전히 배타적이기 때문입니다.
시맨틱 태깅이란?
시맨틱 태깅(Semantic Tagging)은 텍스트를 단순한 문자열이 아닌 개념(Concept)과 개체(Entity)로 연결하는 과정입니다. 태그를 다는 행위가 단순히 ‘이름표’를 붙이는 것이 아니라, 전 세계적으로 정의된 지식 체계(Ontology)나 개인의 지식 그래프에 해당 노드를 ‘위치’시키는 작업이 됩니다.
예를 들어, “Datalog”라는 단어에 시맨틱 태깅을 한다는 것은 다음과 같은 정보를 포함하는 것을 의미합니다.
이렇게 태깅된 데이터는 더 이상 고립된 섬이 아닙니다. 이미 정의된 거대한 지식의 네트워크(Linked Data)와 연결됩니다.
지식 그래프의 기초: 태그가 엣지가 되는 순간
시맨틱 태깅을 거치면, 우리의 노트 테이킹은 조금 다르게 동작하게 됩니다. 태그는 단순한 분류 도구가 아니라, 지식 그래프의 엣지(Edge)가 됩니다.
이 연결망이 구축되면, 우리는 “Datalog”라고 직접 태그하지 않은 노트라 할지라도, 그것이 논리 프로그래밍과 관련되어 있다는 사실을 시스템을 통해 찾아낼 수 있습니다. 태깅이 분류(Classification)에서 연결(Connection)로 진화하는 것입니다.
흩어진 메모가 지식의 그물망이 될 때
시맨틱 태깅이 적용된 환경에서는 검색의 차원이 달라집니다. “사과”를 검색하더라도 이것이 과일인지 기업인지 명확히 구분하여, 작성자의 본래 의도(Intent)에 부합하는 결과를 얻을 수 있습니다. 단순한 키워드 매칭이 아닌, 개념 기반의 탐색이 이루어지기 때문입니다.
이러한 맥락의 연결은 자연스럽게 자동화된 추론의 기반이 됩니다. 이 블로그에서 자주 다루는 Datalog나 RDF 같은 도구들을 사용할 수 밖에 없는 부분입니다. 데이터가 정보의 그물망 위에 시맨틱하게 엮여 있다면, 단방향 검색을 넘어 “20세기 후반에 등장한 논리 프로그래밍 언어 중, 현재 내가 학습 중인 것들은 무엇인가”와 같은 복합적인 질의를 시스템에 넘길 수 있게 됩니다.
Obsidian이나 Logseq처럼 개인 지식 관리(PKM) 도구를 깊게 활용하는 사람들에게도 이는 중요한 시사점을 던집니다. 매번 태그를 꼼꼼히 관리하고 노트를 수동으로 ‘분류’하는 수고를 크게 덜어주기 때문이죠. 새로운 메모를 올바른 개념 공간에 연결해두기만 하면, 시간이 흘러 쌓인 지식의 연결망 속에서 의미 있는 통찰이 자연스럽게 출현(Emergence)하게 됩니다.
LLM이 낮춘 지식 연결의 문턱
그렇다면 시맨틱 태깅은 어떻게 실천할 수 있을까요? 예전에는 사용자가 직접 복잡한 온톨로지(Ontology) 구조를 학습하고, 지루한 수작업으로 일일이 메타데이터를 입력해야만 했습니다. 개념의 정합성을 맞추는 일 자체가 거대한 노동이었죠.
이 견고했던 장벽은 거대 언어 모델(LLM)의 등장으로 빠르게 허물어지고 있습니다. LLM은 다듬어지지 않은 일상적인 글에서 핵심 개념을 짚어내고, 이를 적절한 지식 베이스의 URI와 매핑하는 작업에 놀라운 적성을 보입니다. 글쓴이가 무심코 메모를 남기기만 해도, 모델이 문맥을 소화하여 백그라운드에서 지식의 엣지를 이어붙이는 식입니다. 시맨틱 그래프를 엮어내는 비용이 극적으로 낮아진 셈입니다.
마치며: ‘정리’를 넘어 ‘추론’을 향해
결국 시맨틱 태깅은 ‘내 기록을 어떻게 다룰 것인가’에 대한 관점의 전환입니다. 정성껏 쓴 메모들을 그저 서랍장에 쌓아두는 데 만족할 것인지, 서로 관계를 맺고 새로운 결론을 엮어내는 동적인 지식 기반으로 키울 것인지의 선택이기도 합니다.
기계적인 키워드 분류는 언젠가 분명한 한계에 부딪히게 마련입니다. 파편화된 단어들의 늪에서 헤매지 않으려면, 이제는 단순 문자열의 나열이 아닌 ‘연결 가능한 의미’를 기록하는 연습을 시작해봐야 할 것입니다.
