🧠 레슨

에이전트와 온톨로지 — LLM 루프에 업무 규칙 붙이기

확률적 에이전트에 지식그래프·RDFS/OWL·검증 루프를 붙여 가드레일을 세우는 법.

① 오늘의 질문

에이전트에게 업무 규칙을 어떻게 붙일까?

LLM 에이전트는 말도 잘하고 도구도 호출하지만, 본질적으로는 확률 모델입니다. 그럴듯한 다음 말을 만들고, 그럴듯한 도구 호출을 제안합니다.

Frank Coyle의 강연은 여기서 온톨로지(ontology)를 붙이자고 말합니다. 쉽게 말하면, 회사/업무 세계의 개념·관계·규칙을 그래프와 제약으로 표현해 에이전트 루프를 검증하는 방식입니다.

오늘의 한 문장

에이전트는 움직이는 엔진이고, 온톨로지는 그 엔진이 넘어가면 안 되는 업무 세계의 지도와 규칙입니다.

📚 「에이전트와 온톨로지 — LLM 루프에 업무 규칙 붙이기」 레슨 내용 전체 텍스트로 훑어보기

에이전트에게 업무 규칙을 어떻게 붙일까?

LLM 에이전트는 말도 잘하고 도구도 호출하지만, 본질적으로는 확률 모델입니다. 그럴듯한 다음 말을 만들고, 그럴듯한 도구 호출을 제안합니다.

오늘의 한 문장

에이전트는 움직이는 엔진이고, 온톨로지는 그 엔진이 넘어가면 안 되는 업무 세계의 지도와 규칙입니다.

강연의 관점에서 에이전트와 온톨로지의 관계로 가장 알맞은 설명은 무엇일까요?

맞아요. 에이전트는 perceive → decide → act 루프를 돌고, 온톨로지는 조직이 합의한 개념과 규칙을 형식화합니다. 둘을 붙이면 확률적 에이전트에 상식이 아니라 업무 규칙 기반 가드레일을 줄 수 있습니다.

온톨로지는 이름이 어렵지만 출발점은 단순합니다.

온톨로지의 기본 재료

엔티티: 고객, 주문, 환불, 상담원
관계: 고객이 주문한다, 주문이 환불된다, 상담원이 처리한다
속성: 주문 상태, 결제 금액, 환불 일자

관계형 DB가 표와 컬럼 중심이라면, 온톨로지/그래프는 새로운 관계나 속성을 더 유연하게 붙일 수 있습니다. 특히 AI 에이전트가 여러 업무 개념을 오가며 판단해야 할 때 유용합니다.

Neural-symbolic AI의 감각은 이 대비로 잡으면 됩니다.

LLM/에이전트: 자연어를 이해하고, 상황을 요약하고, 다음 행동을 제안한다. 하지만 확률적이라 그럴듯하지만 틀린 말이나 애매한 값을 만들 수 있다.

온톨로지/규칙: 도메인의 개념·관계·제약을 명시한다. 예: 주문 상태는 paid/shipped/refunded 중 하나여야 한다. 환불은 구매자에게 가야지 상담원에게 가면 안 된다.

강연에서는 RDFS와 OWL 같은 보조 기술을 예로 듭니다. 이것들은 그래프 옆에서 추론과 제약을 담당합니다.

domain/range: teaches의 주어는 Teacher, 목적어는 Student라고 정하면 “Bob teaches Scooter”에서 Bob은 Teacher, Scooter는 Student라고 추론할 수 있습니다.
transitive property: 조상 관계처럼 A가 B의 조상이고 B가 C의 조상이면 A는 C의 조상입니다.
functional property: hasFather처럼 값이 하나여야 하는 관계는 중복/충돌을 잡아낼 수 있습니다.
disjoint property: 고객과 상담원처럼 겹치면 안 되는 타입을 분리해 잘못된 지급 대상을 잡을 수 있습니다.

에이전트가 환불 처리 도구를 호출한 뒤 이런 결과를 냈다고 해봅시다.

refund_target = "support_rep_17"

온톨로지 검증기가 잡아야 할 문제는 무엇일까요?

정답입니다. 영어 문장만 보면 그럴듯하게 넘어갈 수 있지만, 온톨로지에는 Customer와 SupportRep가 분리된 타입으로 정의되어 있을 수 있습니다. 그러면 '환불 대상은 Customer여야 한다'는 규칙으로 막을 수 있습니다.

강연에서 가장 실무적인 비유입니다.

Pydantic / 타입 검증: 도구 호출 전에 입력 모양을 본다. amount는 숫자인가? order_id는 문자열인가? status 필드는 존재하는가? 문 앞에서 형식을 검사한다.

Ontology / 업무 검증: 도구 호출 후 결과가 업무 세계에서 말이 되는지 본다. 두 번째 환불인가? 환불 대상이 고객인가? 주문 상태 전이가 허용되는가? 장부와 규칙으로 검사한다.

실제 루프는 이렇게 생각하면 됩니다.

안전한 에이전트 루프

1. LLM이 다음 행동/도구 호출을 제안한다
2. Pydantic이 도구 입력 타입을 검사한다
3. 도구를 실행하되, 가능하면 먼저 부작용 없는 형태로 실행한다
4. 결과를 온톨로지/업무 규칙 검증기에 통과시킨다
5. 이상하면 재시도하거나 human-in-the-loop로 넘긴다

핵심은 LLM에게 “잘해봐”라고 맡기는 게 아니라, LLM 바깥에 검증 루프를 세우는 것입니다.

에이전트 결과를 온톨로지로 검증해야 하는 이유로 가장 중요한 것은 무엇일까요?

맞아요. LLM은 '아마 맞는 말'을 잘 만들지만, 업무 시스템은 '절대 틀리면 안 되는 규칙'이 있습니다. 두 번째 환불, 잘못된 지급 대상, 허용되지 않은 상태값 같은 문제는 확률이 아니라 규칙으로 막아야 합니다.

오늘 배운 관계를 한 줄로 정리해봅시다.

정답입니다. 에이전트는 움직이는 쪽, 온톨로지는 업무 세계의 규칙을 붙잡는 쪽입니다. 둘을 연결하는 것이 실무형 neuro-symbolic AI의 핵심 감각입니다.

세컨팀 강의/실습 관점에서는 이렇게 이어집니다.

Claude Code 실습: 도구 입력은 타입으로 먼저 막고, 결과는 업무 규칙으로 다시 막는다.
사내 문서봇/RAG: 문서 검색만 하지 말고, 고객·주문·제품·정책의 관계를 그래프로 잡는다.
업무 자동화 에이전트: DB를 바로 바꾸기 전에 검증기와 human-in-the-loop를 둔다.
AI 심화 학습: LLM 단독보다 LLM + 도구 + 검증기 + 지식그래프 조합으로 본다.

즉, 앞으로의 에이전트 설계는 “프롬프트 잘 쓰기”를 넘어 업무 세계를 기계가 검사 가능한 형태로 표현하는 일까지 포함합니다.