Why Agentic Systems Need Ontologies — Frank Coyle, UC Berkeley

한 줄 핵심

에이전트 시스템은 LLM의 확률적 생성만으로는 불안정하므로, 온톨로지·RDFS·OWL 같은 형식적 지식 구조와 루프 검증을 붙여 환각과 오작동을 막아야 한다.

시간별 요약

1. 0:01
   AI 시대에는 단순한 코딩 역량만으로는 충분하지 않으며, 에이전트와 온톨로지를 함께 이해해 새로운 계산 환경을 활용해야 한다. 학습은 읽기보다 직접 만들고, 손으로 쓰고 그리며 감각을 동원할 때 더 빠르게 일어난다.
2. 3:01
   에이전트는 ‘인지하고 판단한 뒤 행동하는 것’으로 발전해 왔고, 온톨로지는 존재와 개념을 체계화한 형식적 지식 표현으로 이어져 왔다. 두 흐름은 현재 LLM과 그래프 기반 지식 표현이 결합하는 지점에서 만난다.
3. 5:00
   온톨로지는 엔티티, 관계, 속성을 그래프 형태로 표현하는 구조이며, 관계형 데이터베이스보다 확장과 연결에 유리하다. 도메인 전문가가 위에서 설계하든, 실제 고객 반응 같은 데이터에서 아래에서 끌어올리든, 이미 존재하는 schema.org, FOAF, Dublin Core, DBpedia 같은 표준을 재사용하는 편이 효율적이다.
4. 9:02
   RDFS와 OWL은 그래프에 제약과 추론 능력을 더해 도메인·레인지, 전이성, 함수성 같은 규칙을 검사할 수 있게 한다. 예를 들어 teaches의 domain과 range, ancestor의 전이성, father의 함수성은 데이터의 의미를 자동으로 확장하고 충돌을 잡아낸다.
5. 12:01
   에이전트는 루프를 가져야 유용하지만, 루프가 무한 반복되거나 드리프트하면 비용과 오류가 급증한다. 따라서 tool 호출-중단 사유 확인-검증-재질문으로 이어지는 루프를 두고, Pydantic으로 타입을 확인한 뒤 온톨로지와 reasoner로 결과를 검증해 side effects를 줄여야 한다.
6. 19:01
   온톨로지 기반 검증은 같은 주문에 대한 중복 환불, 고객 대신 지원팀으로 잘못된 지급, 허용되지 않은 상태값처럼 텍스트만으로는 잡기 어려운 오류를 잡아낸다. 결국 에이전트는 자유롭게 추론하되, 형식적 지식과 규칙으로 감싼 guardrails 안에서만 행동해야 한다.

실무 인사이트

• 에이전트의 신뢰성을 높이려면 모델 성능보다 먼저 도구 호출 전후의 검증 지점과 실패 시 재시도 조건을 설계해야 한다.
• 업무 도메인에는 이미 존재하는 온톨로지와 표준 스키마를 우선 연결하고, 부족한 부분만 보완하는 방식이 구축 속도와 일관성을 동시에 높인다.
• LLM 출력은 생성 결과가 아니라 후보안으로 취급하고, 타입 검사와 도메인 규칙 검사를 통과한 것만 실행하도록 분리해야 한다.