13. 온톨로지 에이전트 시리즈 총정리: 12편의 결론을 하나의 조사 구조로 잇기

핵심 결론

앞선 열두 편이 도달한 결론은 “온톨로지를 붙이면 AI가 똑똑해진다”가 아닙니다. 조직의 말과 규칙을 같은 뜻으로 이해하게 하고, 근거와 제약을 보존하며, 질문마다 가설·반례·미지를 갱신하고, 검증되지 않은 판단과 지식 변경을 막는 작업환경이 필요하다는 것입니다. 이 부품들은 하나의 조사 하네스로 연결됩니다.

온톨로지, 지식그래프, RAG, 에이전트, Judge, Pack, 계획, 반증. 열두 편의 주장은 결국 한 질문으로 모입니다.

그래서 이 모든 것이 어떻게 하나의 에이전트로 연결되는가?

1~12번의 결론은 지속 지식, 질문별 조사 계획, 조사 상태, 검증 기록과 조건부 판단이라는 구조로 이어집니다.

결제는 끝났지만 주문 상태가 며칠째 상품 준비 중인 온라인 쇼핑몰 주문이 있습니다. 단순한 에이전트는 관련 문서를 검색한 뒤 “재고가 부족합니다”라고 답할 수 있습니다. 하지만 실제로는 재고 예약이 실패했을 수도 있고, 상품은 확보됐지만 창고 처리나 상태 갱신이 누락됐을 수도 있습니다. 필요한 것은 첫 설명을 빨리 확정하는 일이 아니라, 가능한 원인을 비교하고 빠진 자료를 확인하며, 고객에게 지금 안내할 내용과 확인 뒤 실행할 조치를 구분하는 일입니다.

열두 편의 네 가지 흐름

열두 편은 크게 네 부로 묶을 수 있습니다.

구분	글	핵심 질문	이 부가 내린 결론
1부. 의미와 검증	1~4번	온톨로지를 붙인 에이전트는 무엇이 달라야 합니까?	같은 말을 같은 뜻으로 이해하고, 근거·제약·판정·승인 권한을 분리해야 합니다.
2부. 도입 경계와 구현	5~7번	모든 문제에 온톨로지가 필요합니까?	아닙니다. 관계 재사용, 변경 영향과 감사 비용이 커질 때만 복잡성이 값을 합니다.
3부. Pack과 문맥 조립	8~10번	조직의 지식을 어떤 형태로 에이전트에게 줍니까?	그래프만 넘기지 말고 근거, 결정, 실패, 반례와 출처를 버전 있는 Pack으로 묶어야 합니다.
4부. 계획과 반증	11~12번	검색한 지식으로 어떻게 행동하고, 틀린 첫 판단을 어떻게 고칩니까?	계획의 조건을 명시하고, 새 외부 근거로 가설을 갱신하며, 필요하면 보류해야 합니다.

이 네 부는 서로 독립된 주제가 아닙니다. 앞부분에서 발견한 문제가 다음 부의 질문이 됐습니다.

뜻을 맞춘다
  → 근거와 행동을 검증한다
  → 언제 온톨로지가 필요한지 경계를 정한다
  → 조직 지식을 Pack으로 묶는다
  → 질문에 필요한 문맥만 조립한다
  → 계획을 만들고 반례로 수정한다
  → 근거가 부족하면 멈춘다

1부. 온톨로지 에이전트는 의미와 행동의 계약에서 시작합니다

1번: 온톨로지는 AI에게 같은 뜻을 쓰게 하는 약속입니다

1번 글은 가장 기본적인 질문에서 시작했습니다. 온톨로지는 단순한 용어 사전이나 그래프 데이터베이스가 아닙니다. 사람과 시스템이 고객, 장애, 근거, 승인 같은 말을 어떤 뜻으로 쓰고, 서로 어떻게 연결하며, 어떤 제약을 적용할지 명시하는 공유 의미 계약입니다.

LLM은 자연어를 유연하게 다루지만, 그 유연함 때문에 같은 단어를 문맥마다 다르게 해석할 수 있습니다. 온톨로지는 모델의 추론을 대신하지 않습니다. 대신 모델이 조직 안에서 어떤 개념과 관계를 기준으로 답해야 하는지 경계를 제공합니다.

주문 배송 사례에서는 결제 완료, 상품 준비 중, 재고 예약, 창고 처리, 배송 시작이 각각 무엇을 뜻하고 어떻게 이어지는지 같은 언어로 표현하는 일이 첫 단계입니다.

2번: 에이전트 시대의 온톨로지는 실행의 의미 계층입니다

2번 글은 의미 계약을 행동으로 확장했습니다. 질문에 답하는 시스템이라면 개념을 잘 찾는 것만으로도 쓸모가 있습니다. 그러나 도구를 호출하고 설정을 바꾸는 에이전트라면 무엇을 할 수 있는가, 어떤 조건에서 가능한가, 누가 승인해야 하는가까지 알아야 합니다.

그래서 에이전트 시대의 온톨로지는 지식을 설명하는 층을 넘어 다음 항목을 연결해야 합니다.

• 현재 상태와 목표 상태
• 가능한 행동과 선행조건
• 정책과 접근 권한
• 예상 효과와 부작용
• 관찰할 신호와 롤백 조건

고객 불편을 줄이려고 즉시 재발송하는 것이 가능하더라도, 이미 출고된 상품이 있다면 중복 배송이 생길 수 있습니다. 환불과 재발송의 조건, 고객에게 먼저 안내할 내용과 사람 승인이 필요한 예외까지 알아야 합니다. 의미를 안다는 것은 행동의 허용 범위도 안다는 뜻입니다.

3번: 그럴듯한 답과 통과한 판단은 다릅니다

3번 글은 LLM이 스스로 낸 답을 그대로 믿지 않는 검증 구조를 다뤘습니다. 검증은 하나의 거대한 Judge에게 맡기기보다 역할을 나눠야 합니다.

• 기계가 확실히 확인할 수 있는 형식, 인용, 수치, 권한과 상태 전환
• 문맥을 읽어야 하는 품질, 충실성, 반례와 설명
• 위험한 예외와 최종 승인에 대한 사람의 판단

여기서 중요한 것은 Judge의 점수 자체가 아닙니다. 어떤 기준을 검사했고, 어떤 근거로 통과하거나 보류했는지 남기는 일입니다. 주문 배송 답변이라면 주문 번호와 결제 상태가 맞는지, 재고 예약과 창고 처리 기록이 같은 주문을 가리키는지, 서로 다른 날짜의 상태를 섞지 않았는지부터 확인해야 합니다.

4번: 창발은 멋진 답이 아니라 검증 가능한 행동 변화입니다

4번 글은 “온톨로지를 주면 새로운 행동이 창발한다”는 표현을 엄격하게 다뤘습니다. 온톨로지를 바꾼 뒤 에이전트의 행동이 달라졌다고 해서 곧바로 온톨로지의 효과라고 말할 수는 없습니다. 프롬프트, 검색 결과와 모델의 우연한 변동 때문일 수도 있습니다.

행동 변화는 다음처럼 추적해야 합니다.

지식 또는 정책 변경
  → 에이전트가 읽은 문맥 변경
  → 제안한 행동 변경
  → Validator 결과
  → 사람 승인 또는 거절
  → 실제 관찰
  → 필요하면 롤백

1부의 결론

온톨로지 에이전트의 첫 번째 가치는 더 많은 지식을 저장하는 데 있지 않습니다. 의미, 근거, 제약, 판정과 승인 권한을 모델 바깥의 계약으로 만드는 데 있습니다.

다만 이런 계약이 모든 문제에 필요한 것은 아닙니다. 간단한 규칙 하나를 확인하는 데 온톨로지를 구축하면 해결책이 문제보다 커질 수 있습니다.

2부. 온톨로지는 항상 정답이 아니라 조건부 선택입니다

5번: 먼저 더 작은 기준선과 비교해야 합니다

5번 글은 “온톨로지가 정말 필요한가?”를 실험 문제로 바꿨습니다. 비교 대상은 일반 LLM 하나가 아닙니다.

• 프롬프트에 직접 적은 규칙
• JSON 정책
• 검색 카드
• SHACL 같은 구조 검증
• 실제 관계를 가진 온톨로지
• 모양만 비슷하고 의미가 없는 가짜 온톨로지

단순한 정책 판정에서는 JSON 규칙이나 검색 카드가 더 싸고 명확할 수 있습니다. 온톨로지를 도입했다는 사실만으로 나은 결과를 기대해서는 안 됩니다.

6번: 관계가 재사용되고 변경이 퍼질 때 온톨로지가 값을 합니다

6번 글은 JSON 규칙과 온톨로지의 경계를 더 구체적으로 정리했습니다.

JSON은 한 장소에서 읽고 바로 판정할 수 있는 작은 규칙에 강합니다. 반면 다음 조건이 커지면 관계 모델이 유리해질 수 있습니다.

• 한 관계를 여러 질문과 기능에서 반복해 사용합니다.
• 두세 단계 이상 떨어진 관계를 따라가야 합니다.
• 개념 하나의 변경이 여러 정책과 결과에 영향을 줍니다.
• 판단의 근거 경로를 나중에 감사해야 합니다.
• 서로 다른 팀의 데이터와 용어를 연결해야 합니다.

즉, 온톨로지의 가치는 노드 수가 아니라 관계 재사용, 변경 영향과 감사 비용에서 나타납니다.

7번: 구현은 저장, 검색, 검증, 추론과 쓰기를 분리해야 합니다

7번 글은 현실적인 로컬 구현 경계를 다뤘습니다. 한 시스템이 모든 일을 맡으면 빠르게 복잡해집니다. 최소한 다음 층을 분리해야 합니다.

정본 저장
검색과 문맥 조립
형식·정책 검증
빠른 규칙 추론
필요할 때의 깊은 LLM 추론
후보 지식 제안
사람 검토와 정본 승격

처음부터 거대한 추론기를 만드는 대신, 읽기 전용 질의와 제한된 템플릿부터 시작하는 편이 안전합니다. 쓰기는 별도의 후보·검증·승인 경로로 보내야 합니다.

2부의 결론

5~7번은 온톨로지에 대한 기대를 낮추는 대신 도입 기준을 선명하게 만들었습니다.

단순한 문제에는 단순한 규칙을 씁니다. 관계가 여러 질문에서 재사용되고, 변경 영향과 감사 경로가 커질 때 온톨로지를 비교합니다. 도입하더라도 읽기, 검증과 승인 쓰기를 한 덩어리로 만들지 않습니다.

온톨로지를 도입하기로 했다면 다음 문제는 무엇을 담고, 어떤 단위로 에이전트에게 전달할지입니다.

3부. 그래프를 넘기는 대신 조직의 판단 문맥을 Pack으로 묶습니다

8번: OpenCrab이 만든 것은 온톨로지 파일 하나가 아니라 배포 단위입니다

8번 글은 OpenCrab의 공개 구조를 살펴보며 온톨로지 빌드가 무엇을 만들어야 하는지 분석했습니다.src_015

OpenCrab의 중요한 아이디어는 다음을 한 흐름으로 묶는 데 있습니다.

• 질문을 여러 관점으로 보는 9-Space
• 원문 근거인 Evidence와 해석인 Claim
• 개념과 관계를 담는 Graph
• 특정 도메인의 지식을 묶는 Pack
• 에이전트가 접근하는 MCP 표면
• 후보, 검증과 승격을 나누는 거버넌스

여기서 Pack은 단순한 파일 묶음이 아닙니다. 어떤 지식이 어디서 왔고, 어떤 버전이며, 누구에게 공개되고, 어떻게 검증됐는지를 함께 전달하는 배포 단위입니다.

9번: 온톨로지는 추론기보다 문맥 컴파일러에 가깝습니다

9번 글은 OpenCrab의 실제 공개 구현과 목표 구조 사이의 간극을 짚었습니다. 공개 구현은 완성된 판단 엔진이라기보다 Pack을 만들고 여러 방식으로 검색하는 기반에 더 가깝습니다.

질문에 답할 수 있는 문맥을 만들려면 검색 결과 목록만으로는 부족합니다.

자연어 질문
  → 질문의 역할과 필요한 근거를 정하는 계획
  → 벡터·키워드·그래프 검색
  → 원문 근거와 출처 보강
  → 사실·주장·정책·누락을 구분한 문맥 묶음
  → LLM의 해석과 계획
  → 결정론적 검사

이 관점에서 온톨로지는 답을 직접 계산하는 기계라기보다, 질문에 맞는 사실과 관계, 근거, 정책과 빠진 정보를 골라 LLM에 전달하는 문맥 컴파일러입니다.

10번: 전문가의 지식은 사실 목록보다 넓습니다

10번 글은 “시니어 엔지니어의 사고를 외부화할 수 있는가?”를 물었습니다. 시니어의 전문성은 용어와 정답 목록만으로 설명되지 않습니다.

실제 판단에는 다음 내용이 함께 들어갑니다.

• 과거 사건과 당시 관찰
• 선택한 결정과 버린 대안
• 결정 당시의 전제와 제약
• 성공 사례뿐 아니라 실패 사례
• 인과 가설과 반례
• 아직 모르는 부분
• 가설을 구분할 다음 관찰과 실험

Expertise Pack은 “무엇이 사실인가”뿐 아니라 “왜 그렇게 판단했으며, 언제 그 판단이 더는 유효하지 않은가”까지 보존해야 합니다.

주문 배송 질문에서 필요한 것은 상품 준비 중이라는 상태의 정의만이 아닙니다. 과거의 비슷한 지연, 실제 재고 부족 사례와 창고 처리 누락 사례, 주문 마감 시간, 환불·재발송 정책과 고객 안내 기록이 함께 필요합니다.

3부의 결론

8~10번은 지식그래프의 역할을 다시 정의했습니다.

에이전트에게 필요한 것은 큰 그래프 자체가 아닙니다. 사실과 해석, 결정과 실패, 반례와 미지, 출처와 버전을 함께 가진 조직 지식 Pack이며, 질문마다 그중 필요한 부분만 문맥으로 조립해야 합니다.

그러나 좋은 문맥을 가져왔다고 좋은 답이 자동으로 나오지는 않습니다. 에이전트가 첫 가설에 고착되거나, 그럴듯하지만 실행 불가능한 계획을 만들 수 있기 때문입니다.

4부. 지식을 계획으로 바꾸고, 첫 판단을 반례로 고칩니다

11번: 지식그래프는 계획을 계산하기보다 계획의 재료와 제약을 제공합니다

11번 글은 지식그래프가 LLM의 계획을 어떻게 도울 수 있는지 다뤘습니다.

계획에는 목표만 있으면 안 됩니다. 적어도 다음 요소가 필요합니다.

목표와 현재 상태
가능한 행동
행동의 선행조건
정책과 권한
예상 효과와 부작용
관찰할 신호
실패 조건과 롤백

Think-on-Graph와 KG-Agent는 LLM이 그래프의 개체와 관계를 단계적으로 탐색해 복합 질의를 다루는 구조를 보여줬습니다.src_003src_004 그래프는 이 관계를 명시해 LLM이 행동 공간과 제약을 보도록 돕습니다. 그러나 그래프 경로가 존재한다고 그 행동이 현실에서 옳거나 안전하다는 뜻은 아닙니다. LLM은 후보 계획을 만들고, 실행 가능성과 정책은 별도 플래너나 Validator가 확인해야 합니다.src_007src_008src_009

12번: 좋은 조사 에이전트는 한 번 검색하고 답하지 않습니다

12번 글은 계획과 가설을 어떻게 수정할지 다뤘습니다. 중요한 것은 같은 모델에게 “다시 생각해”라고 여러 번 말하는 것이 아닙니다. 새로운 외부 신호를 요구하고, 그 신호 때문에 무엇이 바뀌었는지 기록해야 합니다.

조사 상태에는 다음 내용이 필요합니다.

현재 관찰
주 가설과 경쟁 가설
지지 근거와 반례
유사 사례와 대조 사례
정책과 제약
미지
다음 검색 또는 도구 호출
가설을 수정한 이유
종료 또는 보류 이유

ReAct와 CRITIC은 외부 환경과 도구의 관찰을 추론에 다시 넣는 가능성을 보여줬습니다.src_010src_011 반면 외부 피드백 없는 자기교정은 실패하거나 성능을 떨어뜨릴 수 있고, 여러 차례 보고서를 고치는 과정에서 기존의 맞는 주장과 인용이 손상될 수도 있습니다.src_012src_013src_014

반복에는 종료 조건도 필요합니다. 근거가 충분하면 진행하고, 가설을 구분할 자료가 없으면 보류하며, 위험이 크면 사람에게 넘깁니다.

4부의 결론

11~12번은 지식을 행동으로 바꾸는 마지막 연결 고리를 만들었습니다.

그래프는 계획의 재료와 제약을 제공하고, LLM은 경쟁 가설과 후보 계획을 만듭니다. 조사 루프는 새 외부 근거로 가설을 갱신합니다. 근거가 부족하거나 위험이 크면 ABSTAIN 또는 ESCALATE가 정상적인 답입니다.

열두 편의 종합 결론

온톨로지 에이전트는 그래프에서 정답을 꺼내는 시스템이 아니라, 조직의 의미·근거·결정·실패·정책을 지속 가능한 지식으로 보존하고, 질문마다 필요한 조사 문맥을 조립해 LLM이 가설과 계획을 만들도록 하며, 기계와 사람이 그 결과와 지식 변경을 검증하는 작업환경입니다.

여섯 가지 원칙

1. 의미를 명시합니다. 같은 말이 시스템마다 다른 뜻이 되지 않게 합니다.
2. 근거와 해석을 나눕니다. 원문 근거(Evidence)와 그 위에 세운 해석·주장(Claim)을 구분합니다.
3. 온톨로지는 필요한 곳에만 씁니다. 작은 규칙은 JSON과 구조 검증으로 해결합니다.
4. 오래 남을 지식과 임시 가설을 분리합니다. 조사 중 생긴 추측을 곧바로 조직의 사실로 만들지 않습니다.
5. LLM, Validator와 사람의 권한을 나눕니다. 답을 만든 모델이 조직의 공식 지식 변경까지 스스로 승인하지 않습니다.
6. 답보다 조사 상태를 남깁니다. 무엇을 알고, 무엇을 모르며, 무엇을 다음에 확인해야 하는지 기록합니다.

이 여섯 원칙은 다섯 가지 책임으로 구현됩니다.

다섯 질문으로 나눈 조사 구조

가장 중요한 원칙은 오래 남길 지식과 이번 질문에서만 쓰는 조사 상태를 섞지 않는 것입니다.

오래 남는 조직 지식
Expertise Pack
 
이번 질문의 조사
Investigation Plan → Investigation State
 
검사와 답변
Validation Receipt → Judgment Packet
 
지식을 바꿀 때
Proposal → 검증 → 사람 검토 → 승인

첫 조사에서 나온 미확정 가설을 장기 지식에 바로 넣으면, 다음 질문에서 추측이 사실처럼 재사용될 수 있습니다. 반대로 모든 내용을 임시 대화에만 남기면 과거 결정의 이유와 출처를 다시 찾을 수 없습니다. 그래서 기억할 지식, 질문별 추론, 검사 기록과 지식 변경을 서로 다른 수명으로 관리해야 합니다.

쉬운 질문	계약	역할
다음 질문에도 무엇을 기억해야 합니까?	Expertise Pack	조직의 사실, 근거, 사건, 결정, 실패, 정책과 버전을 보존합니다.
이번 질문에서 무엇을 반드시 확인해야 합니까?	Investigation Plan	필요한 자료, 경쟁 가설, 반례, 정책 검사와 종료 조건을 정합니다.
조사하면서 무엇이 바뀌었습니까?	Investigation State	관찰, 가설, 근거, 반례, 미지, 다음 검사와 수정 이유를 누적합니다.
무엇까지 실제로 검사했습니까?	Validation Receipt	인용, 수치, 시간, 권한, 지식 버전과 종료 조건의 검사 범위를 남깁니다.
지금 무엇을 해도 되며 무엇을 보류해야 합니까?	Judgment Packet	조건부 판단, 대안, 다음 검사와 PROCEED·ABSTAIN·ESCALATE를 전달합니다.

계약의 이름보다 중요한 것은 무엇을 기억할지, 무엇을 확인할지, 조사 중 무엇이 바뀌었는지, 어디까지 검사했는지, 지금 어떤 행동이 가능한지를 분리하는 일입니다.

인터랙티브 탐색기

탐색기는 전체 구조, 다섯 질문과 주문 배송 사례를 탭으로 비교합니다. 수치는 성능이나 구현 완료율이 아니라 각 단계의 책임과 수명주기를 나타냅니다.

탐색기를 새 화면에서 크게 열기

주문 배송 지연에 적용한 조사 구조

결제한 지 사흘이 지났는데 주문이 아직 상품 준비 중인 이유는 무엇이며, 고객에게 지금 무엇을 안내해야 합니까?

1단계. 다음 질문에도 쓸 지식을 가져옵니다

주문 상태의 정의, 결제 기록, 재고 예약 방식, 창고 작업 기록, 배송 마감 시간, 환불·재발송 정책과 과거 지연 사례를 찾습니다. 출처와 적용 기간도 함께 확인합니다.

2단계. 첫 설명 외의 가능성도 확인합니다

재고 부족만 지지하는 자료를 모으지 않습니다. 상품은 확보됐지만 창고의 포장 처리나 상태 갱신이 빠졌을 가능성도 경쟁 가설로 둡니다. 두 설명을 구분할 자료가 무엇인지 먼저 정합니다.

3단계. 새 자료에 따라 조사 상태를 바꿉니다

observations:
  - 결제 완료 뒤 사흘째 상품 준비 중
hypotheses:
  - id: H1
    statement: 재고 예약 실패 또는 실제 재고 부족
  - id: H2
    statement: 재고는 확보됐지만 창고 처리나 상태 갱신 누락
constraints:
  - 확인 없이 재발송하면 중복 배송 위험이 있음
unknowns:
  - 해당 주문의 재고 예약과 창고 작업 기록이 존재하는가
next_test:
  - 주문·재고 예약·창고 작업 기록을 같은 시간순으로 비교

재고 예약 기록이 없다면 H1이 강해집니다. 재고는 예약됐지만 창고 작업 기록이 없다면 H2가 강해집니다. 포장 완료 기록까지 있는데 배송 인계만 없다면 새로운 가설을 추가해야 합니다. 중요한 것은 첫 추측을 지키는 것이 아니라 새 관찰에 맞춰 설명을 바꾸는 것입니다.

4단계. 확인한 범위를 기록합니다

주문 번호, 결제 상태, 재고 예약, 창고 기록과 각 시간값이 같은 주문을 가리키는지 검사합니다. 환불이나 재발송 조건이 현재 정책과 맞는지도 확인합니다. 필요한 기록이 없다면 없는 상태 자체를 검증 결과에 남깁니다.

5단계. 확정된 사실과 다음 행동을 함께 답합니다

현재 자료로 H1과 H2를 구분할 수 없다면 “재고 부족입니다”라고 단정하면 안 됩니다.

결제 완료와 배송 지연은 확인됐지만, 재고 예약 기록과 창고 작업 기록을 아직 확인하지 못해 재고 부족인지 처리 누락인지 구분할 수 없습니다. 먼저 두 기록을 같은 주문 번호와 시간순으로 확인해야 합니다. 그동안 고객에게는 지연 사실과 다음 확인 시점을 안내할 수 있습니다. 중복 배송 가능성이 있으므로 확인 전 자동 재발송은 보류하고, 재고가 없으면 환불·대체 상품 정책을, 재고가 확보됐다면 창고 처리를 우선 점검해야 합니다.

최종 답변은 현재 아는 사실뿐 아니라 미확정 원인, 다음 확인과 즉시 가능한 안내까지 함께 담습니다.

LLM, 결정론적 계층과 사람이 맡을 일을 나눕니다

주체	맡기기 좋은 일	맡기면 안 되는 권한
LLM	자연어 질문 해석, 경쟁 가설, 사례 비교, 다음 조사 후보와 설명	조직의 공식 지식 변경 승인, 권한 우회, 근거 없는 확정
검색·그래프 계층	조직 지식 검색, 관계 경로, 출처와 빠진 지식 영역 표시	그래프의 빈칸을 사실로 추정
결정론적 Validator	인용, 지식 버전, 권한, 수치, 상태 전환과 종료 조건 검사	입력 사실이 현실에서 참인지 자동 보증
사람	고위험 판단, 예외 승인, 공식 지식 변경과 책임	모든 저위험 검색을 수작업으로 대체

한 계층이 모든 권한을 가져서는 안 됩니다. 검색 결과를 만든 모델이 자기 가설을 조직의 공식 지식으로 확정하거나, 같은 평가 모델이 평가와 배포까지 맡으면 오류의 원인과 책임을 분리하기 어렵습니다.

실패 방식과 중단 조건

Pack은 조직의 지식을 보존하지만, 오래된 임시 결정과 편견까지 더 권위 있게 재사용하게 만들 수 있습니다. 그래서 유효 기간, 출처, 폐기와 재검증 절차가 필요합니다.

반복 조사도 자동 개선 장치가 아닙니다. 같은 모델이 최초 오류를 공유할 수 있고, 검색 결과가 쌓이면 문맥 간섭이 생깁니다. 수정 과정에서 이전의 맞는 내용과 인용이 손상될 수도 있습니다.src_006src_012src_013src_014

다음 세 상태는 모두 정상 종료입니다.

• PROCEED: 필수 근거와 정책 검사가 충족됐고 가역적인 행동이 가능합니다.
• ABSTAIN: 필수 근거가 없거나 경쟁 가설을 구분할 자료가 없습니다.
• ESCALATE: 위험이 높거나 예외 승인과 책임 있는 사람 판단이 필요합니다.

계속 검색하는 것보다 멈추는 편이 더 정확하고 안전한 경우가 있습니다.

효과는 복잡성을 단계별로 나눠 검증해야 합니다

이 구조가 실제로 더 좋은 판단을 만드는지는 아직 확인되지 않았습니다. 같은 모델, 자료, 질문과 예산에서 다음 단계를 따로 비교해야 합니다.

1. 한 번 검색하고 바로 답하는 방식
2. Pack과 그래프 문맥을 추가한 방식
3. 경쟁 가설과 반례를 갱신하는 반복 조사 방식
4. 반복 조사에 기계적 검증과 사람 승인 경계를 더한 전체 구조

평가할 때도 정답률만 보면 부족합니다. 근거가 붙은 주장 비율, 중요한 반례를 찾은 비율, 첫 가설에 고착된 정도, 적절한 보류와 사람 검토, 수정 중 기존 내용이 손상된 정도, 시간·토큰·검토 비용을 함께 봐야 합니다.

Harness-Bench는 같은 모델도 프롬프트, 도구, 상태 관리와 실행 하네스에 따라 결과가 달라질 수 있다는 문제를 측정하려는 프리프린트입니다. PlanBench와 다중 턴 수정 연구도 계획 능력과 수정 회귀를 따로 평가할 필요성을 보여줍니다. 다만 이 연구들은 여기서 정리한 전체 구조가 우월하다는 직접 증거는 아닙니다.src_005src_007src_014

결론: 시니어의 정답이 아니라 조사 방법을 외부화합니다

열두 편은 서로 다른 기술을 소개한 글처럼 보이지만, 한 방향으로 이어집니다.

• 1~4번은 에이전트가 따라야 할 의미와 검증 원칙을 만들었습니다.
• 5~7번은 온톨로지가 필요한 조건과 현실적인 구현 경계를 정했습니다.
• 8~10번은 조직 지식을 Pack으로 묶고 질문별 문맥으로 조립하는 방법을 제안했습니다.
• 11~12번은 그 문맥으로 계획을 만들고, 반례와 새 관찰로 첫 판단을 수정하는 과정을 정의했습니다.

온톨로지 에이전트가 검색기에서 조사 하네스로 발전하려면, 조직의 사실과 판단 근거를 지속 지식으로 보존하고, 질문마다 가설·반례·미지와 다음 검사를 별도 상태로 관리하며, LLM의 제안과 기계의 검사, 사람의 승인 권한을 분리해야 합니다.

온톨로지로 시니어 엔지니어의 머릿속을 복제할 수는 없습니다. 다만 시니어가 결론을 내리기 전에 확인하는 관찰, 경쟁 가설, 반례, 과거 결정, 제약, 미지와 다음 실험을 밖으로 꺼내 여러 사람이 검토하고 다시 사용할 수는 있습니다.

검증 상태

표준, 동료심사 논문, 프리프린트와 공개 프로젝트 자료 15건을 검토했습니다. 통합 구조의 직접 비교 실험과 독립 리뷰는 아직 없습니다.

함께 읽기

• 1. 온톨로지 에이전트: 의미를 아는 AI를 만드는 방법
• 5. 온톨로지 에이전트는 정말 필요한가
• 8. OpenCrab 온톨로지 빌드는 무엇을 만드는가
• 10. 온톨로지로 시니어 엔지니어의 사고를 외부화할 수 있을까
• 11. 지식그래프는 LLM의 계획을 어떻게 돕는가
• 12. 한 번 검색하고 답하지 않는 에이전트

출처

• src_001 — Thomas R. Gruber. (1993). A Translation Approach to Portable Ontology Specifications. 원문
• src_002 — W3C OWL Working Group. (2012). OWL 2 Web Ontology Language Document Overview (Second Edition). 원문
• src_003 — Jin Sun et al. (2024). Think-on-Graph: Deep and Responsible Reasoning of Large Language Model on Knowledge Graph. ICLR 2024. 원문
• src_004 — Jinhao Jiang et al. (2025). KG-Agent: An Efficient Autonomous Agent Framework for Complex Reasoning over Knowledge Graph. ACL 2025. 원문
• src_005 — Yao Yao et al. (2026). Harness-Bench: Measuring Harness Effects across Models in Realistic Agent Workflows. arXiv preprint. 원문
• src_006 — Dingyi Zhou et al. (2026). What Breaks Knowledge Graph based RAG? Benchmarking and Empirical Insights into Reasoning under Incomplete Knowledge. EACL 2026. 원문
• src_007 — Karthik Valmeekam et al. (2023). PlanBench: An Extensible Benchmark for Evaluating Large Language Models on Planning and Reasoning about Change. NeurIPS 2023. 원문
• src_008 — Bo Liu et al. (2023). LLM+P: Empowering Large Language Models with Optimal Planning Proficiency. 원문
• src_009 — Yilun Hao et al. (2025). Large Language Models Can Solve Real-World Planning Rigorously with Formal Verification Tools. NAACL 2025. 원문
• src_010 — Shunyu Yao et al. (2023). ReAct: Synergizing Reasoning and Acting in Language Models. ICLR 2023. 원문
• src_011 — Zhibin Gou et al. (2024). CRITIC: Large Language Models Can Self-Correct with Tool-Interactive Critiquing. ICLR 2024. 원문
• src_012 — Jie Huang et al. (2024). Large Language Models Cannot Self-Correct Reasoning Yet. ICLR 2024. 원문
• src_013 — Ryo Kamoi et al. (2024). When Can LLMs Actually Correct Their Own Mistakes? A Critical Survey of Self-Correction of LLMs. TACL 2024. 원문
• src_014 — Boya Chen et al. (2026). Beyond Single-shot Writing: Deep Research Agents are Unreliable at Multi-turn Report Revision. ACL 2026. 원문
• src_015 — OpenCrab project. (2026). OpenCrab public integration repository at analyzed commit. 원문