지식그래프를 만들어보면서 가장 어려웠던 건 노드를 저장하는 일이 아니었다. API Gateway, 게이트웨이, Gateway API처럼 비슷해 보이는 표현을 언제 하나로 묶고, 그 사이의 관계를 어떤 의미로 연결할지가 훨씬 어려웠다. 이번에 자료를 깊게 찾아보며 내린 결론은 이렇다. 온톨로지의 중심은 클래스 계약이고, 지식그래프의 가치는 벡터 RAG와 같은...
지식그래프를 만들어보면서 가장 어려웠던 건 노드를 저장하는 일이 아니었다.
API Gateway, 게이트웨이, Gateway API처럼 비슷해 보이는 표현을 언제 하나로 묶고,
그 사이의 관계를 어떤 의미로 연결할지가 훨씬 어려웠다.
이번에 자료를 깊게 찾아보며 내린 결론은 이렇다. 온톨로지의 중심은 클래스 계약이고, 지식그래프의 가치는 벡터 RAG와 같은 조건에서 실제 질문으로 비교해야 증명할 수 있다.
이 글에서는 세 가지 질문을 따라간다.
에이전트의 메모리와 권한을 포함한 전체 운영 구조가 먼저 필요하다면 엔터프라이즈 AI Agent 설계를 함께 보면 좋다.
이 글의 클래스·관계 계약을 Neo4j에 옮기고 검색 도구로 구현하는 과정은 Neo4j GraphRAG로 에이전트 컨텍스트 제공자 만들기에서 이어간다.
처음에는 노드와 관계가 많아지면 자연스럽게 지식그래프가 좋아질 거라고 생각하기 쉽다. 하지만 그래프 데이터베이스는 데이터를 저장하고 탐색하는 기술이지, 무엇을 같은 것으로 볼지 결정해주지는 않는다.
온톨로지는 도메인에서 사용하는 의미의 계약이다.
W3C의 OWL 2 입문서는 온톨로지를 클래스, 속성, 개체와 이들 사이의 공리로 설명한다.
OWL은 웹 온톨로지 언어(Web Ontology Language)의 약자다. OWL 2는 어떤 도메인의 개념과 관계를 컴퓨터가 논리적으로 해석하고 새로운 사실을 추론할 수 있도록 의미를 명시하는 W3C 표준 언어다.
이름에 Web이 들어가지만 웹 화면을 만드는 기술은 아니다. 서로 다른 시스템이 같은 개념을 같은 의미로 교환하고, 명시된 규칙에서 추가 사실을 계산하는 지식 표현 언어에 가깝다.
OWL 2를 이해할 때는 다섯 가지를 먼저 보면 된다.
| 구성 요소 | 의미 | 코딩 지식그래프 예시 |
|---|---|---|
| 클래스 | 같은 성격을 가진 개체의 집합 | Component, APIGateway |
| 개체 | 현실의 구체적인 대상 | auth-gateway |
| 객체 속성 | 개체와 개체 사이의 관계 | dependsOn, ownedBy |
| 데이터 속성 | 개체와 문자열·숫자 같은 값의 관계 | version, createdAt |
| 공리 | 온톨로지 안에서 참이라고 선언한 의미 규칙 | 모든 APIGateway는 Component다 |
여기서 공리(axiom)가 OWL 2의 핵심이다. 공리는 단순한 설명 문장이 아니라 추론기가 새로운 사실을 도출할 때 사용하는 논리 규칙이다.
다음은 OWL의 Manchester 문법을 단순화한 예다.
Class: Component
Class: APIGateway
SubClassOf: Component
Class: AuthenticationGateway
SubClassOf: APIGateway
Individual: auth-gateway
Types: AuthenticationGateway직접 적은 사실은 auth-gateway가 AuthenticationGateway라는 것뿐이다.
하지만 추론기는 클래스 계층을 따라 다음 사실도 도출할 수 있다.
auth-gateway는 APIGateway다.auth-gateway는 Component다.AuthenticationGateway는 Component다.RDF가 auth-gateway dependsOn auth-service 같은 사실을 주어·관계·목적어 형태로 표현한다면,
OWL 2는 클래스 계층, 동등성, 배타성, 속성의 특성처럼
그 사실들을 해석할 규칙을 더한다.
OWL 2를 처음 접할 때 가장 헷갈리기 쉬운 부분이다.
일반적인 데이터베이스나 Zod 검증에서는 필드가 없으면 오류라고 판단할 수 있다. 반면 OWL 2는 열린 세계 가정(open-world assumption)을 따른다. 그래프에 어떤 사실이 없다고 해서 그 사실이 거짓이라고 결론 내리지 않고, 아직 알려지지 않았을 가능성을 남긴다.
예를 들어 auth-gateway에 소유 팀이 기록되지 않았다고 해보자.
owner가 필수라는 조건을 두고 누락을 오류로 판정할 수 있다.속성의 도메인과 범위도 입력 검증 규칙과 다르게 작동한다.
OWL 2에서 dependsOn의 시작과 끝을 Component로 선언한 뒤
A dependsOn B라는 사실이 들어오면,
추론기는 A와 B를 Component라고 추론할 수 있다.
잘못된 입력을 곧바로 거부하는 타입 검사와는 방향이 다르다.
역할을 구분하면 다음과 같다.
| 도구 | 답하려는 질문 |
|---|---|
| OWL 2 | 현재 사실과 의미 규칙에서 무엇을 논리적으로 추론할 수 있는가? |
| SHACL | RDF 데이터가 필요한 형태와 제약을 만족하는가? |
| Zod·JSON Schema | 애플리케이션 입력이 요구한 필드와 타입을 만족하는가? |
| Neo4j 제약 | 그래프 키와 속성의 유일성·존재 조건을 만족하는가? |
따라서 OWL 2와 SHACL은 경쟁 기술이라기보다 역할이 다르다. OWL 2로 의미와 추론 규칙을 표현하고, SHACL이나 애플리케이션 스키마로 실제 적재 데이터를 검증할 수 있다.
논리 표현력이 강해질수록 추론 비용도 커질 수 있다. OWL 2는 필요한 문제에 맞춰 표현력 일부를 제한한 세 가지 프로파일을 정의한다.
| 프로파일 | 적합한 문제 |
|---|---|
| OWL 2 EL | 클래스와 속성이 매우 많은 대규모 온톨로지에서 계층 추론이 중요할 때 |
| OWL 2 QL | 인스턴스가 많고 관계형 데이터베이스 위에서 질의 응답이 중요할 때 |
| OWL 2 RL | 규칙 엔진 방식으로 확장 가능한 추론을 구현할 때 |
프로파일은 더 좋은 버전을 고르는 문제가 아니다. 필요한 추론과 데이터 규모에 맞춰 표현력과 계산 비용을 교환하는 선택지다.
현재와 같은 Neo4j 속성 그래프가 있다고 해서 OWL 2로 전면 이주해야 하는 것은 아니다.
다음 요구가 생기면 OWL 2 도입을 검토할 가치가 있다.
반대로 클래스 수가 작고, 필요한 관계 탐색이 Cypher로 충분하며, 애플리케이션 코드에서 제약을 명확히 관리할 수 있다면 TypeScript, Zod, Neo4j 제약으로 시작하는 편이 단순하다.
내가 이 글에서 OWL 2를 언급한 이유도 라이브러리 도입을 권하기 위해서가 아니다. 클래스, 관계, 인스턴스, 공리, 추론을 분리해서 생각하는 설계 규율을 가져오기 위해서다.
내가 중요하게 본 구분은 다음과 같다.
| 구분 | 역할 | 예시 |
|---|---|---|
| 클래스 | 어떤 종류의 대상인지 정의한다 | Service, Component, Decision |
| 인스턴스 | 현실에 존재하는 구체적인 대상을 나타낸다 | 주문 API, 인증 게이트웨이 |
| 관계 유형 | 두 대상 사이에 허용되는 의미를 정의한다 | DEPENDS_ON, AFFECTS |
| 주장 | 특정 관계가 실제로 성립한다고 말한다 | 주문 API가 인증 게이트웨이에 의존한다 |
| 근거 | 그 주장을 뒷받침한다 | 설계 문서, 코드 위치, 업무 댓글 |
클래스가 불명확하면 같은 Concept 안에 기술, 제품, 코드 심볼, 일반 명사가 섞인다.
그 상태에서 관계를 추가할수록 그래프는 풍부해지는 게 아니라 모호해진다.
문서에서 명사를 모두 뽑아 클래스로 만들면 온톨로지가 빠르게 비대해진다. Stanford의 Ontology Development 101은 먼저 도메인, 사용 목적, 사용자, 그리고 온톨로지가 답해야 할 질문을 정하라고 권한다.
이때 사용하는 질문을 역량 질문(competency question)이라고 부른다.
코딩 에이전트를 위한 지식그래프라면 다음과 같은 질문이 출발점이 될 수 있다.
질문을 적고 나면 필요한 클래스가 보인다.
예를 들어 변경 영향 질문을 답하려면 Service와 CodeSymbol만으로는 부족하다.
변경을 설명하는 Decision, 근거가 되는 Document,
시간에 따라 유효성이 달라지는 Claim이 필요할 수 있다.
반대로 어떤 클래스도 질문, 제약, 행동에 연결되지 않는다면 정식 온톨로지에 넣기보다 후보 상태로 두는 편이 낫다.
클래스를 만드는 방향은 크게 두 가지다.
Asset 같은 상위 개념에서 SoftwareAsset, Service, API로 내려간다.order-service, gateway.yaml, PaymentController 같은 실제 데이터에서 공통점을 올려 찾는다.Ontology Development 101은
두 방향을 섞어 먼저 눈에 띄는 중간 수준의 개념을 정하고,
필요에 따라 일반화하거나 구체화하는 결합 방식을 설명한다.
영상의 방법론 발표에서도
중간 수준의 개념에서 시작해 상위와 하위로 확장하는 접근을 설명한다.
이를 코딩 에이전트에 적용하면
실제로 반복해서 묻는 Service, API, Decision, Test 같은 개념에서 시작할 수 있다.
이 방식은 코딩 에이전트용 온톨로지와 잘 맞는다.
역량 질문에 필요할 때만 위로는 Asset을 만들고,
아래로는 REST API나 GraphQL API처럼 세분화할 수 있기 때문이다.
반대로 Controller와 Repository를 별도 질의하거나 제약하지 않는다면
처음에는 CodeSymbol의 속성으로 남겨도 된다.
처음부터 모든 개발 지식을 모델링할 필요는 없다. 나는 다음 다섯 묶음부터 시작하는 편이 현실적이라고 봤다.
SystemServiceComponentAPIDataStoreCodeSymbolWorkItemDocumentCommentCommitPullRequestDecisionClaimEvidenceIncidentPersonTeamAgentActionCapabilityWorkflowPolicyInvariantTool시스템 자산만 모델링하면 에이전트가 무엇을 알고 있는지는 표현할 수 있지만, 무엇을 해도 되는지와 어떤 조건을 지켜야 하는지는 표현하기 어렵다. Palantir의 공식 온톨로지 문서는 객체, 속성, 링크 같은 의미 요소와 함께 행동, 함수, 동적 보안 같은 실행 요소를 온톨로지의 구성으로 설명한다.
코딩 에이전트에도 같은 구분이 필요하다.
예를 들어 renameSymbol은 단순한 동사가 아니다.
대상 심볼, 허용 범위, 변경되는 파일, 보존해야 할 불변 조건,
통과해야 할 테스트를 함께 가진 행동 계약이다.
이 구성에서 일반 기술어는 곧바로 시스템 자산으로 취급하지 않는다.
API Gateway라는 기술 개념과 조직이 운영하는 구체적인 게이트웨이 인스턴스는 다르다.
이 구분이 없으면 기술 문서에서 나온 일반 개념과 실제 운영 대상을 같은 노드로 합치게 된다. 그러면 에이전트가 변경 영향이나 소유권을 찾을 때 엉뚱한 경로를 따라간다.
API Gateway와 게이트웨이는 같은가표현이 비슷하다는 사실과 같은 개체라는 사실은 다르다.
다음 표현을 생각해보자.
API Gatewayapi-gateway게이트웨이인증 게이트웨이Gateway API앞의 두 표현은 표기 차이일 가능성이 높다.
게이트웨이는 문맥에 따라 API Gateway, 네트워크 게이트웨이,
결제 게이트웨이를 모두 가리킬 수 있다.
Gateway API는 Kubernetes의 별도 API 표준을 의미할 수도 있으므로
문자열 토큰이 같다는 이유로 합치면 안 된다.
나는 이 문제를 문자열 정규화가 아니라 개체 동일성 판정 문제로 보는 편이 맞다고 생각한다.
원문에서 발견한 표현은 먼저 Mention으로 취급한다.
검증을 통과한 뒤에만 정식 개체에 연결한다.
원문 표현
→ 동일성 후보 생성
→ 문맥과 관계 비교
→ 동일 / 관련 / 상하위 / 모호 / 별개 판정
→ 정식 개체 또는 검토 대기열 연결같은 개체로 병합하려면 다음 근거를 조합한다.
후보를 넓게 찾는 단계에서는 여러 방법을 함께 쓸 수 있다.
그러나 후보가 나왔다고 바로 병합하면 안 된다. 최종 판정에서는 다음 상태를 구분해야 한다.
| 판정 | 예시 | 처리 |
|---|---|---|
| 동일 | API Gateway, api-gateway | 정식 이름 하나와 별칭으로 관리한다 |
| 상위·하위 | Gateway, API Gateway | 클래스 또는 IS_A 관계를 검토한다 |
| 관련 | API Gateway, Ingress Controller | 목적에 맞는 관계로 연결한다 |
| 모호 | 게이트웨이 | 문맥이 충분해질 때까지 후보로 둔다 |
| 별개 | API Gateway, Gateway API | 다른 식별자를 유지한다 |
임베딩은 같은 후보를 찾는 데 유용하지만, 같은 개체임을 증명하지는 않는다. 병합은 검색 문제가 아니라 의미와 식별자의 변경이기 때문이다.
별칭 사전은 단순한 문자열 배열로 끝내기 쉽다. 하지만 운영하다 보면 누가 왜 같은 표현으로 승인했는지, 언제부터 유효했는지, 잘못된 병합을 어떻게 되돌릴지가 필요해진다.
최소한 다음 정보는 남기는 편이 좋다.
alias: 게이트웨이
canonicalEntityId: component:auth-gateway
status: candidate
scope: authentication-domain
evidence:
- source: architecture-document
approvedBy: null
validFrom: null
replacedBy: null출처와 범위가 없는 별칭은 전역 규칙으로 승격하지 않는다.
한 팀에서 게이트웨이가 인증 게이트웨이를 뜻한다고 해서
다른 저장소에서도 같은 의미라는 보장은 없기 때문이다.
클래스와 관계를 정의한 뒤 원문에서 실제 인스턴스와 관계를 만드는 일을 온톨로지 적재(ontology population)라고 부른다. 영상의 LLM·온톨로지 결합 발표는 이 과정을 개체 후보 추출, 개체 연결, 관계 추출, 관계 연결, 검증으로 나눈다.
이 단계들은 한 번의 LLM 호출로 뭉치기보다 분리하는 편이 좋다. 앞 단계의 오류가 뒤 단계에서 그럴듯한 관계로 증폭될 수 있기 때문이다.
자유 형식으로 개체와 관계를 추출하게 하면 같은 의미에 다른 클래스 이름을 붙이거나 허용하지 않은 관계를 만들기 쉽다. 따라서 추출 요청에는 다음 정보를 함께 제공한다.
Ontology Population using LLMs는 특정 역사 데이터셋 실험에서 모듈화한 온톨로지를 프롬프트에 제공했을 때 정답 지식 트리플의 약 90퍼센트를 생성했다고 보고한다. 이는 온톨로지 스키마가 추출을 제약하는 데 유용할 수 있다는 사례이지, 다른 도메인에서도 같은 정확도를 보장한다는 뜻은 아니다.
실제 추출 계약은 다음처럼 허용 범위와 실패 처리를 명시할 수 있다.
{
"allowedClasses": ["Service", "API", "CodeSymbol", "Decision"],
"allowedRelations": ["EXPOSES", "DEPENDS_ON", "AFFECTS"],
"requiredFields": ["sourceUri", "locator", "extractorVersion"],
"unknownEntityPolicy": "emit-candidate",
"unsupportedRelationPolicy": "reject"
}새로운 표현을 발견해도 즉시 클래스를 늘리지 않는다. 후보로 보관한 뒤 반복 빈도, 역량 질문, 기존 클래스와의 충돌을 검토한다. LLM을 이용한 지식그래프·온톨로지 공학 연구도 모델링, 확장, 수정, 적재, 정렬, 개체 모호성 해소를 서로 다른 작업으로 나누고, 모듈화한 온톨로지가 중요하다고 설명한다.
좋은 답변이 한 번 나왔다고 그래프가 정확하게 적재됐다고 볼 수 없다. 적재 단계마다 다음 지표를 분리해 본다.
| 단계 | 핵심 지표 | 확인하려는 실패 |
|---|---|---|
| 개체 추출 | 정밀도와 재현율 | 실제 개체를 놓치거나 일반 명사를 개체로 만든다 |
| 개체 연결 | 연결 정확도와 미연결 비율 | 별개 개체를 합치거나 기존 개체를 찾지 못한다 |
| 관계 추출 | 관계 정밀도와 방향 오류율 | 관계 의미나 주체와 객체를 뒤집는다 |
| 스키마 검증 | 제약 위반율 | 허용하지 않은 클래스와 관계를 만든다 |
| 근거 연결 | 출처 포함률과 원문 위치 정확도 | 관계를 원문까지 추적할 수 없다 |
| 사람 검토 | 승인율과 반려 사유 | 자동화가 반복해서 만드는 오류를 찾는다 |
자동 승인율을 높이는 것 자체가 목표는 아니다. 모호한 데이터를 정직하게 미연결 후보로 남기는 시스템이 틀린 관계를 자신 있게 확정하는 시스템보다 안전하다.
영상의 데이터 기반 발표는 온톨로지 이전에 신뢰할 수 있는 데이터 기반이 필요하다는 점을 강조한다. 코딩 지식그래프에서는 최소한 다음 조건을 확인할 수 있다.
이 정보가 없다면 먼저 메타데이터, 식별자, 변경 이력, 계약을 정비하는 편이 낫다. 작은 코드 인덱스나 관계형 테이블로 충분한 문제에 온톨로지를 추가해도 누락된 원천 데이터는 복구되지 않는다.
DEPENDS_ON, AFFECTS, CAUSED_BY 같은 관계는 문서에서 그대로 주어지지 않는 경우가 많다.
LLM이나 규칙이 여러 문장을 해석해 만든 결과일 수 있다.
이런 관계를 확정 사실처럼 저장하면 다음 문제가 생긴다.
작성자, 담당자, 댓글 소속, 명시적 링크처럼 원천에서 직접 얻는 관계는
구조적 사실로 저장해도 된다.
반면 해석이 들어간 관계는 Claim으로 승격하는 편이 안전하다.
모든 간선을 Claim 노드로 바꿀 필요는 없다.
충돌 가능성, 시간 변화, 검토 필요성이 큰 관계부터 적용하면 된다.
모든 주장에 같은 검토 비용을 쓰면 운영하기 어렵다. 그 주장이 틀렸을 때 생기는 피해를 기준으로 승인 문턱을 나눈다.
| 위험도 | 사용 예 | 승인 기준 |
|---|---|---|
| 낮음 | 검색 후보와 읽을 문서 추천 | 단일 근거와 낮은 신뢰도도 후보로 허용한다 |
| 중간 | 변경 영향과 팀 소유권 안내 | 복수 근거 또는 명시적 규칙으로 교차 검증한다 |
| 높음 | 코드 변경, 운영 조작, 정책 판단 | 테스트와 사람 승인을 거쳐야 실행한다 |
모델이 출력한 신뢰도 점수만으로 위험을 통제할 수는 없다.
출처, 생성 활동, 생성 주체, 생성 시각, 파생 관계를 함께 기록해야 한다.
W3C PROV-O의
Entity, Activity, Agent, wasGeneratedBy, wasDerivedFrom은
이 이력을 서로 다른 시스템에서도 표현하기 위한 기본 어휘를 제공한다.
영상의 온톨로지 진화 사례는 연료 기반 자동차 중심의 분류가 전기차의 등장으로 달라지는 예를 든다. 소프트웨어 조직에서도 서버리스, 생성형 AI, 새로운 배포 단위가 들어오면 기존 클래스의 경계와 관계가 달라질 수 있다.
Stanford의 Ontology Development 101도 온톨로지 개발을 반복적인 과정으로 설명한다. 운영 단계에서는 다음 변경을 코드처럼 관리해야 한다.
버전, 마이그레이션, 검증 없이 클래스를 계속 고치면 과거 근거와 현재 질문이 어느 스키마를 기준으로 하는지 알 수 없어진다.
지식그래프를 만들었다는 사실만으로 검색 품질이 좋아졌다고 말할 수는 없다. 그래프는 구축과 유지 비용이 크므로, 같은 데이터와 같은 질문에서 벡터 RAG보다 어떤 가치를 더했는지 측정해야 한다.
비교 대상은 최소 세 가지가 필요하다.
내 예상으로는 한 방식이 모든 질문에서 이기지는 않는다. 표현이 다양한 단일 문서 검색은 벡터 검색이 유리할 수 있고, 의존 관계나 결정 이력처럼 여러 단계를 따라가야 하는 질문은 그래프가 유리할 가능성이 크다. 중요한 것은 이 예상을 실제 질문으로 검증하는 것이다.
평가 질문을 섞어서 평균 하나만 내면 왜 좋아졌는지 알 수 없다.
| 질문 유형 | 예시 | 예상되는 강점 |
|---|---|---|
| 의미 검색 | 게이트웨이 장애 대응 문서는 어디에 있는가? | 벡터 RAG |
| 별칭 해소 | 게이트웨이가 가리키는 실제 컴포넌트는 무엇인가? | 혼합 검색 |
| 다단계 관계 | API 제거 결정과 영향을 받는 서비스를 찾아라 | 지식그래프 |
| 시간 변화 | 현재 유효한 결정과 대체된 결정을 구분하라 | 지식그래프 |
| 전역 요약 | 여러 프로젝트의 공통 장애 원인을 요약하라 | GraphRAG 또는 혼합 검색 |
| 코드 작업 | 이 심볼 변경에 필요한 파일과 근거를 찾아라 | 코드 인덱스와 혼합 검색 |
최종 답변 점수만 보면 검색 실패와 생성 실패를 구분하기 어렵다. 평가를 다섯 층으로 나누는 편이 좋다.
별칭 병합에서는 재현율보다 정밀도를 먼저 지키는 편이 안전하다. 놓친 별칭은 검색 후보를 늘려 보완할 수 있지만, 잘못 합친 개체는 이후의 모든 관계와 답변을 오염시킨다.
Recall@KPrecision@K그래프 쪽에 더 많은 원문과 토큰을 주면 공정한 비교가 아니다. 다음 조건을 같게 맞춘다.
그리고 각 방식을 여러 번 반복한다. LLM이 한 번 맞힌 결과는 안정성을 증명하지 못한다.
그래프를 도입한 뒤 유리한 지표만 고르면 결론을 믿기 어렵다. 실험 전에 성공 기준을 고정한다.
예를 들어 다음처럼 정의할 수 있다.
다단계 관계 질문:
필수 근거 Recall@5가 벡터 RAG보다 높아야 한다.
잘못된 관계 경로 비율은 기준 이하이어야 한다.
별칭 질문:
잘못 병합한 개체 비율을 증가시키지 않으면서
정식 개체 연결 성공률을 높여야 한다.
코딩 작업:
작업 성공률을 높이되
입력 토큰과 잘못 수정한 파일 수를 함께 줄여야 한다.그래프가 의미 검색에서 벡터 RAG보다 낮아도 실패라고 볼 필요는 없다. 벡터 검색이 잘하는 일은 벡터 검색에 맡기고, 그래프가 필요한 질문에서 이기는 혼합 구조가 더 현실적이다.
지식그래프를 만들고 나면 전체 그래프를 에이전트 프롬프트에 넣고 싶어진다. 하지만 컨텍스트 창이 크다고 검색 문제가 사라지는 것은 아니다. Lost in the Middle 연구는 긴 입력에서 관련 정보의 위치에 따라 모델의 활용 성능이 달라질 수 있음을 보여줬다.
에이전트에는 현재 작업에 필요한 작은 근거 묶음만 전달해야 한다.
지속 규칙은 AGENTS.md 같은 파일에 둔다.
세션을 넘어 보존할 관찰은 메모리 계층에 둔다.
변경 가능한 업무·문서·코드 사실은 검색 시점에 다시 가져온다.
이 차이는 OpenClaw는 context와 memory를 어떻게 관리하나에서 제품 사례를 중심으로 더 자세히 다뤘다.
첫 버전에서 그래프를 수정하는 도구까지 만들 필요는 없다. 에이전트가 근거를 찾고 확장할 수 있는 읽기 도구만으로 충분하다.
searchEntities(query, filters)
getEntity(id)
expandRelations(id, relationTypes, depth)
getEvidence(claimId)
getDecisionTrace(entityId, timeRange)
getChangeImpact(ontologyElementId)응답은 최종 자연어 답변보다 구조화된 근거여야 한다.
{
"id": "component:auth-gateway",
"kind": "entity",
"canonicalName": "인증 게이트웨이",
"aliases": ["API Gateway", "게이트웨이"],
"status": "active",
"relationPath": ["service:order", "DEPENDS_ON", "component:auth-gateway"],
"citations": [
{
"uri": "repo://architecture/gateway.md",
"locator": "인증 흐름"
}
],
"tokenEstimate": 180
}MCP는 이런 자원과 도구를 에이전트에 노출하는 표준 경계로 사용할 수 있다. 다만 MCP 서버를 만들었다고 검색 품질이 자동으로 좋아지는 것은 아니다. 검색 순위, 별칭 판정, 권한, 최신성, 중복 제거, 토큰 예산은 제공자 내부의 책임이다. MCP 공식 아키텍처 문서도 MCP가 컨텍스트 교환을 표준화하지만, 애플리케이션이 컨텍스트를 어떻게 선택하고 관리할지는 규정하지 않는다고 설명한다.
프로젝트 지침을 어떤 형태로 전달할지는 AGENTS.md 포맷도 함께 참고할 수 있다.
읽기 전용 제공자가 안정화된 뒤에도 에이전트가 정식 그래프를 직접 수정하게 해서는 안 된다. 작업 중 발견한 지식은 우선 근거가 딸린 후보 주장으로 되돌려 쓴다.
예를 들어 테스트 실패를 보고 새로운 의존 관계를 추론했다면 실패 로그, 패키지 선언, 실제 임포트 위치를 연결한 뒤 후보로 남긴다. 검증을 통과한 경우에만 정식 관계로 승격하고, 나중에 재평가할 수 있도록 승인과 대체 이력도 보존한다.
두 프로토콜은 경쟁 관계라기보다 연결 대상이 다르다.
| 경계 | 주된 역할 | 이 글에서의 사용 |
|---|---|---|
| MCP | 에이전트와 도구, 자원, API 연결 | 개체 검색, 관계 확장, 근거 조회를 제공한다 |
| A2A | 독립 에이전트 사이의 발견, 위임, 결과 공유 | 원격 전문 에이전트에 작업을 맡기고 결과를 받는다 |
A2A 공식 문서도 MCP를 에이전트와 도구·자원의 연결로, A2A를 독립 에이전트 사이의 협업으로 구분한다. 단일 코딩 에이전트가 지식그래프를 조회하는 단계에는 MCP로 충분하다. 서로 다른 권한과 수명 주기를 가진 원격 에이전트가 협업할 때만 A2A 같은 에이전트 간 경계를 추가하는 편이 단순하다.
처음부터 완성된 조직 지식그래프를 만들려고 하면 모델링과 데이터 정제에 시간을 쓰다가 실제 가치를 확인하지 못할 수 있다.
나는 다음 순서로 실험해보려 한다.
API Gateway와 Gateway API 같은 어려운 반례를 반드시 포함한다.
질문 유형별 근거 회수율, 정답률, 인용 정확도, 토큰, 도구 호출 수를 같은 조건에서 비교한다.
MCP 서버, 로컬 CLI, REST API 중 하나만 선택한다. 에이전트가 전체 그래프를 받지 않고도 개체, 관계, 원문 근거를 단계적으로 확장할 수 있는지 확인한다.
다음 조건에서는 벡터 RAG와 메타데이터 필터만으로 충분할 수 있다.
반대로 다음 요구가 반복되면 그래프의 가치가 커진다.
그래프의 장점은 정보를 많이 담는 데 있지 않다. 어떤 경로로 답에 도달했고, 그 관계를 왜 믿을 수 있는지 설명하는 데 있다.
이번 조사를 통해 클래스가 먼저라는 생각은 더 분명해졌다. 클래스는 보기 좋은 분류표가 아니라, 어떤 데이터를 인스턴스로 받아들이고 어떤 관계를 허용할지 결정하는 실행 계약이다.
동시에 온톨로지를 잘 만들었다는 것과 실제 검색이 좋아졌다는 것은 다른 문제다. 클래스와 관계는 역량 질문으로 검증하고, 검색과 에이전트 성능은 벡터 RAG·그래프·혼합 검색을 같은 조건에서 비교해야 한다.
앞으로 가장 먼저 해볼 일은 거대한 온톨로지를 만드는 것이 아니다.
API Gateway 주변의 작은 클래스와 별칭 골든셋을 만들고,
몇 개의 다단계 질문에서 그래프가 실제로 더 나은 근거를 찾아오는지 측정하는 일이다.
영상의 여러 발표도 문제와 의사결정, 데이터에서 출발해야 한다는 방향을 공유한다. 다만 환각 제거, 정확도 향상, 비용 절감처럼 수치로 제시된 효과 가운데 공개된 평가 설계와 원자료로 재현하기 어려운 내용은 이 글의 근거로 사용하지 않았다. 실제 도입 판단은 이 글에서 제시한 적재 지표와 검색·작업 평가로 다시 검증해야 한다.