article · 2026-07-14
온톨로지는 에이전트의 두뇌가 아니다
Semantic Web의 오래된 언어를 Agentic AI의 기억·질의·검증 계약으로 다시 읽기
요약
이번 리서치는 질문 하나를 고쳐 쓰는 데서 끝났다. 처음 던진 질문은 온톨로지를 붙이면 에이전트가 얼마나 똑똑해지는가였다. RDF와 OWL로 세계를 모델링하고 SPARQL로 필요한 지식을 꺼내 주면 계획과 판단도 나아질 것 같았다.
전통적인 Semantic Web이 풀던 문제와 Agentic AI 시스템이 부딪히는 문제는 시간축부터 다르다. Semantic Web은 여러 시스템이 같은 대상을 같은 의미로 읽게 만드는 데 강하다. 에이전트는 불완전한 정보 안에서 다음 행동을 고르고, 실패하면 재시도하고, 권한을 확인하고, 때로는 사람에게 결정을 넘긴다. 앞은 의미의 문제고 뒤는 실행의 문제다.
온톨로지는 에이전트의 두뇌가 아니라 계약 계층에 가깝다. RDF와 OWL은 대상과 관계의 의미를 고정하고, PROV-O는 근거와 실행과 책임을 연결한다. SPARQL은 그 연결을 재현 가능한 방식으로 묻고, SHACL은 필요한 기록이 빠졌을 때 작업을 멈춘다. 계획, 도구 호출, 재시도, 승인은 여전히 runtime의 몫이다.
이렇게 보면 SPARQL도 “그래프용 검색창”이 아니다. 어떤 주장에 어떤 근거가 연결됐고, 그 주장이 어느 실행에서 만들어졌으며, 누가 책임지는지를 같은 조건으로 다시 물을 수 있게 하는 질의 계약이다. Agentic AI에 더 필요한 건 지식을 많이 넣는 일이 아니라, 에이전트가 남긴 결과를 다음 에이전트와 사람이 검증 가능한 경로로 이어받게 하는 일일 수 있다.
1. 질문을 잘못 잡고 있었다
온톨로지를 공부하다 보면 쉽게 두뇌의 비유로 끌려간다. 개념과 관계와 추론 규칙이 있으니 에이전트의 머릿속 세계 모델처럼 보인다. 지식그래프를 붙이면 기억이 좋아지고, OWL 추론을 더하면 판단이 논리적이 되고, SPARQL을 연결하면 필요한 사실을 정확히 찾을 것 같다.
나도 그렇게 접근했다. evidence, assertion, workflow run, agent, source를 정리하고 서로 연결하면 에이전트가 더 나은 결정을 내릴 거라고 생각했다. 실제 시스템에서 필요한 질문을 적어 보니 서로 다른 책임이 한데 섞여 있었다.
“이 주장은 어느 원문에서 파생됐는가?”는 의미와 provenance의 질문이다. “source 없이 저장돼도 되는가?”는 검증의 질문이다. “실패한 도구 호출을 몇 번 재시도할 것인가?”는 runtime policy의 질문이다. “외부 시스템에 쓰기 전에 누구의 승인을 받을 것인가?”는 권한과 거버넌스의 질문이다.
겉으로는 모두 에이전트의 지능처럼 보인다. 시스템 안에서는 아니다. 이 구분을 놓치면 온톨로지에 현재 상태, 실행 정책, 권한 규칙, 평가 기준까지 계속 집어넣게 된다. 처음에는 하나의 일관된 모델처럼 보이지만, 시간이 지나면 무엇이 안정된 지식이고 무엇이 한 번의 실행에서 생긴 임시 상태인지 가르기 어려워진다.
온톨로지를 더 크게 만드는 일보다, 온톨로지가 책임질 경계를 정확히 긋는 일이 먼저였다.
2. Semantic Web과 Agentic AI는 다른 속도로 움직인다
전통적인 Semantic Web의 핵심 과제는 공유 가능한 의미였다. 서로 다른 조직과 데이터베이스가 같은 URI와 어휘를 사용해 데이터를 연결하고, 명시된 의미론 안에서 같은 관계를 읽게 만드는 일이다. Person, Organization, worksFor가 무엇을 뜻하는지 정하고, 한 데이터셋의 식별자를 다른 데이터셋과 연결한다. RDF와 OWL은 이 일을 오래 다듬어 왔다.
Agentic AI는 같은 그래프를 보더라도 다른 질문을 던진다. 지금 어떤 도구를 호출할지, 호출이 실패했는지, 결과가 충분한지, 사람을 부를지 판단해야 한다. 같은 사실을 읽고도 예산, 권한, 마감, 실패 횟수에 따라 다른 행동을 고른다.
| Semantic Web이 잘 다루는 것 | Agent runtime이 다뤄야 하는 것 |
|---|---|
| 대상의 식별자와 타입 | 현재 실행 상태 |
| 개념과 관계의 의미 | 도구 선택과 호출 순서 |
| 데이터셋 사이의 연결 | timeout, retry, fallback |
| 명시된 공리 안의 entailment | 승인, 권한, 비용 예산 |
| provenance와 데이터 계보 | 불확실한 상황의 다음 행동 |
핵심은 단순한 정적과 동적의 차이가 아니다. 안정성의 속도가 다르다. Assertion이 무엇인지에 대한 정의는 자주 바뀌면 안 된다. 특정 assertion이 이번 run에서 pending인지 rejected인지는 계속 바뀐다. 전자는 시스템들이 공유해야 할 의미이고, 후자는 실행 중인 상태다.
둘을 같은 층에 놓으면 실행할 때마다 TBox가 흔들리거나, 반대로 runtime이 오래된 공리에 묶인다. 최신 상태를 표현하려고 클래스와 속성을 계속 추가하면 온톨로지는 실행 로그처럼 부푼다. 실행 정책을 공리로 고정하면 예외 처리가 어려워진다.
그래서 Agentic AI가 Semantic Web을 받아들이는 방식은 “온톨로지가 행동을 결정한다”보다 “온톨로지가 행동의 입력과 결과를 서로 알아볼 수 있게 한다”에 가까워야 한다.
3. 두뇌의 자리에 놓으면 신뢰 경계가 사라진다
온톨로지를 에이전트의 두뇌라고 부르면 과신하기 쉬운 지점이 있다.
표현할 수 있으면 판단할 수 있다고 착각하는 지점이다. 어떤 도구가 SearchTool이고 어떤 작업이 ResearchTask인지 아는 것과, 지금 검색을 한 번 더 할지 멈출지를 정하는 것은 다른 문제다. 후자는 비용, 시간, 결과 품질, 중복 가능성을 함께 본다. 온톨로지는 판단에 필요한 항목을 명명할 수 있지만 최종 선택까지 대신하지는 않는다.
추론된 사실과 생성된 문장을 같은 지식으로 취급하게 되는 지점도 있다. LLM이 “A가 B를 지지한다”고 썼다고 곧바로 확정된 triple이 되는 것은 아니다. 원문에서 직접 나온 사실인지, 모델이 요약한 주장인지, 여러 근거를 조합한 해석인지 구분해야 한다. 모든 출력을 ABox에 넣으면 그래프는 풍부해지는 대신 신뢰 경계를 잃는다.
실패와 책임이 지워지는 지점도 있다. 최종 assertion만 남고 그것을 만든 activity, 사용한 source, 실행한 agent, 거친 revision이 빠지면 그래프는 답은 가지지만 답의 이력은 잃는다. 잘못된 결과를 발견해도 어느 실행에서 생겼고 무엇을 다시 돌려야 하는지 찾기 어렵다.
Agent memory에서 필요한 것은 “무엇을 알고 있는가”만이 아니다. “왜 그렇게 알고 있는가”, “누가 어떤 과정으로 만들었는가”, “지금도 유효한가”가 함께 남아야 한다. 두뇌의 비유는 첫 문제만 강조한다. 계약의 비유는 나머지를 시스템에 돌려놓는다.
4. 계약 계층은 네 겹으로 나뉜다
온톨로지가 계약이라면 구체적으로 무엇을 계약해야 할까. 이번 리서치에서는 네 겹으로 나누는 편이 가장 선명했다.
가장 아래에 의미 계약이 있다. RDF와 OWL로 evidence, assertion, source, workflow run, agent 같은 대상의 식별자와 관계를 고정한다. 같은 이름이 같은 대상을 가리키고, supportsEvidence와 wasDerivedFrom이 다른 뜻이라는 사실을 시스템들이 공유하게 한다. 자주 바뀌지 않는 말의 뼈대다.
그 위에 출처 계약이 있다. PROV-O로 Entity, Activity, Agent를 연결한다. 근거 발췌가 원문에서 파생됐고, 분석 activity가 그 근거를 사용했으며, assertion이 그 activity에서 생성됐고, 특정 agent나 사람이 결과에 책임을 가진다는 경로를 남긴다. provenance는 텍스트 옆 각주가 아니라 다시 따라갈 수 있는 데이터가 된다.
질의 계약은 SPARQL로 반복해서 물어야 하는 질문을 고정한다. “이 assertion의 1차 source는 무엇인가”, “이 source를 사용해 생성된 결과 중 검증을 통과하지 못한 것은 무엇인가”, “특정 run에서 생성됐지만 사람 승인이 없는 결과는 무엇인가.” 자연어 표현이 달라져도 같은 그래프 패턴을 실행한다.
검증 계약은 SHACL로 다음 단계에 필요한 최소 모양을 선언한다. evidence에는 source URL과 수집 시각이 있어야 하고, assertion에는 evidence 연결이 있어야 하며, workflow result에는 run id와 status가 있어야 한다. 필드가 빠지면 나중으로 미루지 않고 그 자리에서 멈춘다.
RDF/OWL은 뜻을 정하고, PROV-O는 계보를 남기고, SPARQL은 경로를 묻고, SHACL은 빠진 기록을 막는다. 어느 하나가 나머지를 대신하지 않는다. 이 분업 바깥에서 runtime은 도구를 호출하고 실패를 처리하며 사람에게 승인을 요청한다.
온톨로지가 두뇌가 아니라 계약이라는 말은 기능을 낮춰 부르는 표현이 아니다. 책임을 정확히 주는 표현이다.
5. SPARQL은 검색이 아니라 재현 가능한 질문이다
SPARQL을 “그래프 데이터베이스의 SQL” 정도로 이해하면 Agentic AI에서의 의의를 놓친다. SPARQL의 본질은 RDF 그래프 패턴에 변수를 놓고 여러 triple pattern을 조인해 일관된 binding을 얻는 데 있다.
에이전트가 이런 문장을 남겼다고 하자.
“복합 Text-to-SPARQL은 아직 안정적이지 않다.”
벡터 검색은 이 문장과 비슷한 문서를 찾아줄 수 있다. 우리가 정말 알고 싶은 것은 조금 다르다. 어느 benchmark를 근거로 했는지, 그 benchmark의 어떤 결과를 사용했는지, 누가 어느 run에서 문장을 만들었는지, 이후 사람이 검토했는지까지 따라가고 싶다.
그래프에서는 질문이 경로가 된다.
Assertion
-> wasGeneratedBy -> Research Activity
-> used -> Evidence
-> wasDerivedFrom -> Source
-> wasAssociatedWith -> Agent
SPARQL은 이 경로를 하나의 질의로 묶는다. OPTIONAL로 사람 검토가 없는 결과도 포함하고, FILTER로 특정 날짜 이후의 run만 좁히며, named graph로 원천 데이터와 모델 생성 데이터를 구분할 수 있다. 결과는 “관련 있어 보이는 문서 묶음”이 아니라 조건을 만족한 변수 binding이다.
이 차이가 중요하다. 벡터 검색은 발견에 강하고, SPARQL은 관계 조건의 재현에 강하다. 먼저 벡터 검색으로 후보 evidence를 찾고, 확정된 관계는 RDF로 올린 뒤, 반복되는 검증 질문은 SPARQL로 고정하는 구성이 자연스럽다.
SPARQL은 연합 질의도 제공한다. SERVICE 절을 사용하면 모든 데이터를 한곳에 복제하지 않고 원격 endpoint의 그래프 패턴을 로컬 데이터와 결합할 수 있다. 내부 assertion을 외부 공공 지식그래프나 생명과학 지식그래프의 식별자와 잇는 식이다. 다만 endpoint 선택, 인증, timeout, 부분 실패, 재시도는 질의 언어가 해결하지 않는다. 그 결정은 runtime에 남는다.
그래서 SPARQL은 Agent가 지식을 마음대로 탐색하는 언어라기보다, Agent가 허용된 방식으로 근거를 읽는 계약에 가깝다.
6. 실증 사례는 가능성과 운영비를 함께 보여준다
SPARQL이 실제로 쓰이는지 확인하려고 공개 endpoint 사례를 봤다. 결과는 예상보다 컸고, 동시에 꽤 현실적이었다.
Wikimedia가 2021년 공개한 Wikidata Query Service 운영 자료에는 9,500만 개 entity, 132억 triple, 하루 최대 2,514만 request가 등장한다. SPARQL이 장난감 규모의 기술이 아니라는 증거다. 같은 자료는 update lag, timeout, backend 한계도 함께 다룬다. 데이터 크기, write load, query load가 동시에 커지면 최신성과 응답 시간을 모두 지키기 어렵다.
DBpedia는 Wikipedia의 제각각인 infobox를 공유 온톨로지로 매핑해 언어권을 가로지르는 구조 질의를 가능하게 했다. 자연어 문서 속에서는 한 번에 묻기 어려운 다중 조건을 공통 식별자와 관계로 묶는 사례다. 여기서 SPARQL의 가치는 문서 검색보다 서로 다른 출처의 구조를 같은 질문으로 통과시키는 데 있다.
UniProt의 SPARQL endpoint는 2026_02 릴리스 기준 2,325억 개가 넘는 triple과 22개 named graph를 제공한다. 단백질, 데이터베이스 교차참조, 분류와 기능 관계를 identifier 중심으로 조인한다. 동시에 45분 timeout을 둔다. 대규모 구조 질의는 가능하지만, 질의 비용과 자원 통제는 운영 설계의 일부라는 뜻이다.
| 사례 | SPARQL이 만든 가치 | 함께 드러난 비용 |
|---|---|---|
| Wikidata Query Service | 대규모 공개 지식그래프의 관계 질의 | update lag, timeout, backend 확장 |
| DBpedia | 다국어·이종 infobox의 공통 온톨로지 질의 | 매핑 품질과 데이터 정렬 |
| UniProt | 생명과학 identifier와 named graph의 결합 | 고비용 질의와 endpoint 자원 통제 |
세 사례는 같은 결론을 준다. SPARQL은 충분히 실용적이다. 대신 endpoint를 세우는 순간부터 freshness, timeout, query complexity, access control을 함께 운영해야 한다. 질의 언어를 도입하는 것과 신뢰할 수 있는 질의 서비스를 운영하는 것은 다른 일이다.
7. Agent에게는 자유 질의보다 작은 계약이 먼저다
그렇다면 LLM에게 자연어 질문을 받아 SPARQL을 자유롭게 만들게 하면 될까.
Spider4SPARQL은 166개 knowledge graph와 138개 domain을 포함한 복합 benchmark에서 당시 평가한 시스템의 최고 execution accuracy가 45%였다고 보고했다. 자연어를 그럴듯한 SPARQL 문자열로 바꾸는 것과, 실제 schema에 맞고 실행 결과까지 옳은 질의를 만드는 것은 다른 문제다.
존재하지 않는 predicate를 만들고, domain과 range를 뒤집고, 필요한 join을 빠뜨릴 수 있다. 너무 넓은 경로로 endpoint를 오래 붙잡기도 한다. 문법상 맞아도 의미상 틀릴 수 있다. LLM 출력에서 보던 문제가 질의 안에서도 반복된다.
자유 생성보다 작은 계약이 먼저다. Agent가 사용할 수 있는 predicate와 named graph를 제한하고, 자주 쓰는 질문은 parameterized template로 만든다. query lint와 비용 제한을 두고, 처음에는 read-only endpoint만 연다. 결과가 비어 있거나 지나치게 크면 fallback 검색이나 사람 검토로 넘긴다.
Agent가 직접 긴 질의를 만드는 대신 get_primary_sources(assertion_id), get_unvalidated_results(run_id), trace_revision(entity_id) 같은 도구를 제공할 수 있다. 내부에서는 SPARQL template가 실행되지만 Agent가 바꿀 수 있는 것은 identifier와 몇 개의 안전한 filter뿐이다. 이 정도면 SPARQL은 모델의 자유 작문이 아니라 시스템의 안정된 read interface가 된다.
8. 기억이 자산이 되는 순간
Agent memory라는 말을 들으면 대화 이력, 벡터 저장소, 요약 노트를 떠올리게 된다. 모두 필요하다. 하지만 다음 에이전트가 “왜 이 결론을 믿어야 하는가”를 물었을 때 답하지 못하면 기억은 오래된 문장 묶음에 가깝다.
리서치 에이전트가 Spider4SPARQL을 읽고 “복합 Text-to-SPARQL은 아직 취약하다”는 assertion을 만들었다고 하자. 제대로 된 기억은 assertion 하나만 저장하지 않는다.
Source
-> Evidence excerpt
-> Research activity
-> Assertion
-> Human review
-> Adopted design rule
원문과 발췌가 연결되고, 어느 run의 어떤 activity가 그것을 사용했는지 남고, assertion이 생성되고, 사람이 검토한 뒤 “Agent의 SPARQL은 read-only template로 제한한다”는 설계 규칙으로 이어진다. 다음 에이전트는 규칙만 읽지 않고 그 근거까지 거슬러 올라갈 수 있다.
이때 RDF/OWL이 각 노드의 의미를 고정하고, PROV-O가 생성과 파생 경로를 잇는다. SHACL은 source나 run id가 빠진 결과를 막고, SPARQL은 규칙에서 원문까지의 경로를 다시 읽는다.
기억이 자산이 되는 순간은 저장할 때가 아니다. 다른 주체가 다시 검증하고 이어서 쓸 수 있을 때다.
9. 가장 비싼 기능은 가장 늦게 산다
온톨로지와 그래프 이야기는 쉽게 큰 인프라 계획으로 번진다. triple store를 고르고, 추론 엔진을 붙이고, federation을 열고, 자연어 질의까지 한 번에 만들고 싶어진다. 그 전에 확인할 것이 있다. 반복해서 추적해야 할 관계가 있는가. 식별자가 안정돼 있는가. 어떤 기록이 빠지면 작업을 멈춰야 하는가.
이번 리서치에서 잡은 순서는 이렇다. provenance가 있는 RDF export부터 만든다. 기존 Markdown이나 JSONL을 버리지 않고, evidence, assertion, run, agent 사이의 핵심 관계만 그래프로 투영한다. 그 위에 SHACL gate를 건다. source URL, retrieved_at, run id, status, evidence 연결처럼 실제 사고를 막는 필수 항목부터 검사한다. 그다음 반복되는 질문만 read-only SPARQL template로 연다. 실제 질의 빈도를 확인하고 허용된 predicate와 timeout을 정한다. 운영 데이터가 쌓인 뒤에야 OWL reasoning, federation, write endpoint를 검토한다. 의미론적 추론이 줄여 주는 중복이 있는지, 외부 endpoint를 직접 잇는 편이 복제보다 나은지, Agent의 쓰기 권한을 감당할 governance가 있는지 본다.
기술을 덜 쓰자는 얘기가 아니다. 가장 비싼 기능을 가장 늦게 산다는 얘기다. 관계를 표현하고, 빠진 기록을 막고, 반복 질문을 안정시키는 데서 이미 큰 가치가 나온다.
마무리
이번 리서치를 시작할 때는 온톨로지가 에이전트의 세계 모델이 되고, 그 세계 모델이 더 나은 판단을 만들 것이라고 생각했다.
에이전트의 판단은 모델, 도구, runtime state, 정책, 비용, 사람의 승인 사이에서 일어난다. 온톨로지가 그 모든 것을 대신하려고 하면 경계가 흐려진다. 대신 이들이 서로 건네는 대상의 이름과 관계를 고정할 수 있다. 무엇이 근거이고, 무엇이 주장이고, 어느 실행에서 생겼으며, 누가 책임지는지. SPARQL은 그 경로를 같은 방식으로 다시 묻게 하고, SHACL은 경로가 끊긴 기록을 멈춘다.
온톨로지는 에이전트의 두뇌가 아니다. 에이전트가 남긴 일을 다음 에이전트와 사람이 함부로 오해하지 않게 만드는 계약에 가깝다. Agentic AI에서 더 희소한 것은 더 많은 지식이 아니라, 그 지식이 어디서 왔는지 끝까지 따라갈 수 있는 구조일 수 있다.