온톨로지 기반 에이전트 ① 에이전트 개발과 온톨로지의 필요성

에이전트에게 온톨로지는 「LLM 정확도를 올리는 도구」 이상이다. 현재 LLM 기반으로 구현되는 에이전트는 보통 사람을 대신해 어떤 작업을 수행하는 인공지능 서비스로 정의된다. 작업이라는 단어가 모호하지만, 대부분의 에이전트에게 기대하는 작업이 지식 노동이라는 점에는 큰 이견이 없을 것이다.

그렇다면 에이전트와 인간의 차이는 무엇일까? 더 정확하게는, 에이전트와 인간이 지식을 다루는 방식은 어떻게 다를까? 철학적인 질문처럼 보이지만, 사람의 작업을 대신할 만큼 똑똑하고 상황에 잘 적응하는 에이전트를 만들려면 꼭 짚어야 할 문제다. 인간은 지식을 의식하지 않고도 구조로 다룬다. 무엇이 규칙이고 무엇이 사실인지, 어떤 정보가 지금 문제와 상관없는지를 따로 애쓰지 않고 가른다. 반면 LLM 기반 에이전트가 입력으로 받는 지식은 텍스트뿐이고, 그 구조는 매번 텍스트에서 다시 읽어 내야 한다. 이 차이를 메울 힌트는 최근의 LLM 연구보다 오히려 지식 표현(knowledge representation) 연구의 역사에 있다.

지식을 기계가 다룰 수 있는 형태로 표현하려는 시도는 1960~70년대의 의미망(semantic network)과 프레임(frame)에서 시작됐다. 1970~80년대에는 전문가 시스템(expert system)이 유행하면서, 전문가의 지식을 이식한 인공지능이 처음으로 실무에 쓰이기 시작했다. 이때 연구자들이 가장 크게 부딪힌 문제는 전문가의 머릿속에 있는 지식을 끌어내 시스템에 옮기는 일이 너무 비싸다는 것이었고, 이 문제는 지식 획득 병목(knowledge acquisition bottleneck)이라는 이름으로 불렸다. 시스템을 만들 때마다 지식을 처음부터 다시 끌어내고 다시 표현했기 때문이다. 그렇다면 한 번 표현한 지식을 다른 시스템이 공유하고 재사용할 수는 없을까? 1990년대 초의 지식 공유 연구는 이 질문에서 출발했고, 그 과정에서 Gruber는 온톨로지를 「개념화의 명시적 명세」로 정의했다(Gruber 1993). 이 생각이 개념의 의미를 형식적으로 다듬어 온 기술 논리(Description Logic)와 함께 웹을 만나, RDF와 OWL, 오늘의 온톨로지가 되었다.

지식을 다루는 방식은 그동안 크게 두 갈래로 발전해 왔다. 하나는 사람이 지식을 명시적으로 표현하는 기호적 접근(symbolic)이다. 프레임과 기술 논리에서 RDF와 OWL을 거쳐, Linked Data(2006)와 Wikidata(2012) 같은 지식그래프, 데이터가 정의된 구조를 지키는지 검사하는 SHACL(2017)까지 이어졌다. 다른 하나는 지식을 따로 정의하지 않고, 데이터 더미에서 표현을 학습하는 신경망 접근(neural)이다. 단어와 문장을 고차원 벡터로 계산하는 이 방식은 역전파(1986)에서 word2vec(2013)과 Transformer(2017)를 거쳐 오늘의 LLM이 되었다. 오랫동안 서로 다른 길을 걸어온 두 접근이 이제 에이전트에서 만난다.

LLM은 두 번째 접근의 정점이다. 지식은 모델의 가중치 안에 암묵적으로 녹아 있고, 작업에 필요한 맥락은 텍스트로 주어진다. 그런데 그 텍스트 안에서 무엇이 지시이고 무엇이 참고 사항인지, 어느 내용이 아직 유효한지를 가려내고 유지하기는 생각보다 어렵다. ChatGPT와 대화가 길어지면 앞에서 정해 둔 조건을 놓치는 경험이 흔하다. 실제로 같은 지시를 한 번에 주지 않고 여러 턴에 나눠 주면 성능이 평균 39% 떨어졌다는 실험도 있다(Laban 외 2025).

실제 에이전트 시스템에서는 이 어려움이 더 커진다. 에이전트는 LLM 하나가 아니라 여러 LLM의 협업으로 움직이고, 간단한 챗봇조차 LLM 한 번 호출로 끝나는 경우는 드물다. 대화 하나에서도 어려운 일을 여러 노드 사이에서 해내야 하는 것이다. 텍스트로 표현된 지식은 원석에 가깝다. 이를 재사용하고 관리하려면 구조로 다듬을 도구가 필요하다. 그 도구가 왜 온톨로지여야 하는지는 실제 에이전트의 구조를 보면 분명해진다.

에이전트의 성능은 노드 사이의 정보 교환에서 갈린다

업무에 들어가는 에이전트는 대개 여러 LLM 호출을 잇거나 나눠 실행한다. Anthropic은 이 구성을 프롬프트 체이닝, 라우팅, 병렬화, 오케스트레이터-워커, 평가자-최적화자 다섯 가지 패턴으로 정리한다(Anthropic 2024). 하나의 LLM이 워크플로를 처음부터 끝까지 수행하지 못하는 이유는 여러 가지지만, 이 글이 주목하는 것은 두 가지다.

첫 번째는 컨텍스트의 한계다. 입력 컨텍스트는 빠르게 커지고 있지만, 복잡한 워크플로를 한 번에 담기에는 입출력 토큰이 여전히 부족하다. 창 안에 들어간다고 해결되는 문제도 아니다. 관련 정보가 긴 입력의 중간에 있으면 정확도가 눈에 띄게 떨어지고(Liu 외 2023), 18개 모델을 시험한 실험에서는 단순한 작업에서도 입력이 길어질수록 성능이 불안정해졌다(Chroma 2025). 컨텍스트 압축이나 요약으로 이를 피하려 해도, 무엇을 남길지 판단할 기준이 텍스트 안에 없다. 무엇이 개념의 정의이고 무엇이 개별 사실인지(TBox와 ABox의 구분), 무엇이 끝까지 지켜야 할 규칙인지가 텍스트에는 표시돼 있지 않기 때문이다. 입출력이 길어질수록 비용이 커지는 현실적인 문제도 있다.

두 번째는 자연어의 한계다. 자연어는 표현이 자유로운 대신 구조가 암묵적으로만 드러나고, 문맥은 문장 밖에 남는다. 그래서 읽는 쪽이 해석해야 하고, 해석에는 모호성이 따른다. 누구나 아는 상식을 다룰 때는 이 모호성이 거의 문제가 되지 않지만, 도메인 지식에서는 바로 문제가 된다. 기업 인수 전에 쓰는 재무 실사(due diligence) 보고서에 적힌 「매출」만 해도 연결 기준인지 별도 기준인지, 「기준일」이 결산일인지 실사 기준일인지 문장 자체에는 나와 있지 않다. 실사를 해 본 사람은 맥락으로 알아채지만, 모델은 매번 짐작해야 한다.

그래서 작업을 여러 노드로 나눈다. 노드마다 컨텍스트를 작게 유지하면 첫 번째 한계는 줄어든다. 그런데 나누는 순간 노드 사이의 정보 교환이 생기고, 그 교환은 다시 자연어로 이뤄진다. 두 번째 한계가 노드 사이마다 되살아나는 것이다. 에이전트의 성능이 결국 노드 사이의 정보 교환에서 갈리는 이유다.

이 한계를 줄이기 위해 지금의 에이전트 시스템은 대부분 같은 방향으로 진화하고 있다. LLM 노드마다 역할을 나눠 주고, 노드 사이에 오가는 정보를 제한하며, 그 정보를 JSON 같은 구조화된 형식으로 주고받게 한다. 노드 사이의 정보 교환은 크게 직접적인 교환과 간접적인 교환으로 나눌 수 있다.

직접적인 정보 교환은 한 노드가 다음 노드에 넘기는 메시지와 페이로드다. 여기서 가장 주의할 점은 다음 노드의 역할과 무관한 정보를 많이 넘기지 않는 것이다. 데이터 분석을 맡은 노드에 디자인 관련 정보까지 넘기면, 그 노드는 분석이라는 역할을 받았는데도 디자인에 관한 판단으로 끌려간다. 컨텍스트에 들어온 무관한 정보가 출력의 질을 떨어뜨리는 이 현상을 컨텍스트 혼동(context confusion)이라고 부른다(Breunig 2025).

이질적인 도메인의 정보가 함께 넘어가면 문제가 하나 더 생긴다. 모델은 두 정보를 함께 아우르는 답을 찾으려 한다. 기술 논리의 개념으로 비유하자면, 두 개념을 모두 포함하는 가장 구체적인 상위 개념을 최소 공통 상위 개념(least common subsumer)이라고 하는데(Baader 외 1999), 두 개념이 멀수록 이 상위 개념은 계층의 위쪽, 즉 더 추상적인 쪽에 놓인다. 재무 분석과 디자인의 최소 공통 상위 개념은 「업무」나 「문서」 정도밖에 없다. 멀리 떨어진 두 정보를 함께 받은 모델의 답이 일반론으로 흐르는 것도 이와 비슷하다. JSON으로 형식을 맞춰도 이 문제는 남는다. JSON은 필드의 모양을 정할 뿐, 그 값이 무엇을 뜻하고 어느 노드에 필요한지는 정하지 않기 때문이다.

더 까다로운 쪽은 간접적인 정보 교환이다. 이것은 메시지로 오가지 않는다. 노드마다 프롬프트에 적힌 지시는 사실상 규칙의 목록, 즉 규칙 베이스다. 간접적인 교환이란 노드들이 같은 규칙을 공유하느냐, 곧 프롬프트 사이의 일관성 문제다. 노드 A(추세 분석)의 프롬프트가 분석 범위를 「올해 1월 1일부터 작업 시점까지의 매출」로 정했다고 하자. 노드 B(결론 작성)의 프롬프트도 같은 범위 규칙을 갖고 있어야 한다. B의 프롬프트가 「연간 매출」을 전제하고 있다면, B는 A의 결과를 받아 들고 「일부 기간뿐이라 결론을 낼 수 없다」고 엉뚱하게 답한다. 모든 규칙이 어긋나는 것도 아니다. 금액 단위처럼 두 프롬프트에 똑같이 적힌 규칙도 있지만, A는 연결 기준으로 집계하고 B는 별도 기준을 전제하는 식으로 일부만 어긋난다. 대부분의 규칙이 맞고 몇 개만 다를수록, 그 어긋남은 오히려 눈에 띄지 않는다. 앞에서 본 「매출」과 「기준일」의 모호성이 노드 사이로 번진 모습이다. Breunig(2025)는 한 컨텍스트 안의 정보끼리 어긋나는 현상을 컨텍스트 충돌(context clash)이라고 불렀는데, 간접 교환의 어긋남은 이 충돌이 여러 노드의 프롬프트로 흩어진 형태라고 볼 수 있다. 이 규칙은 어느 메시지에도 적혀 있지 않고 각 프롬프트 안에 암묵적으로만 있어서, 메시지 형식을 아무리 구조화해도 맞춰지지 않는다.

노드가 주고받는 정보도, 함께 지키는 규칙도 온톨로지로 정의해야 한다

일반적으로 LLM 노드가 받는 입력은 두 가지로 구분할 수 있다. 하나는 그 노드가 따라야 할 규칙이고, 보통 프롬프트에 명시한다. 다른 하나는 작업에 필요한 데이터이고, 보통 이전 노드나 도구의 결과가 메시지로 들어온다. 근본적인 문제는 두 입력 모두 의미가 정의되지 않은 텍스트라는 데 있다. 규칙이 무엇을 대상으로 하는지, 메시지의 값이 무엇을 뜻하는지가 글로만 설명되어 있어 읽는 쪽이 해석해야 하고, 그 해석에서 모호성이 생긴다. 온톨로지는 두 입력의 의미를 형식적으로 정의해 이 모호성을 줄인다.

온톨로지를 지식의 타입 시스템에 견주는 시각은 시맨틱 웹 초기부터 있었다. W3C는 2000년 RDF Schema 명세 후보안에서 RDF Schema가 「RDF 모델을 위한 기본 타입 시스템」을 제공한다고 소개하며, Java 같은 객체지향 언어의 타입 시스템에 견주었다. 다만 클래스에 속성을 붙이는 객체지향과 달리, RDF는 속성이 어느 클래스에 적용되는지를 정의하는 속성 중심 방식이라는 차이도 함께 밝혔다(W3C 2000). 타입 시스템이 어떤 종류의 값이 있는지 정해 두듯, 온톨로지는 어떤 종류의 지식이 있고 서로 어떤 관계인지를 정의한다. 여기에 더해 이미 정의된 사실에서 새로운 사실을 추론할 수 있다는 점에서, 온톨로지는 타입 시스템보다 훨씬 넓은 영역을 다루는 지식 시스템이다.

온톨로지의 역할을 살펴보면 지금의 에이전트가 왜 불안한지도 엿볼 수 있다. 온톨로지로 지식의 종류와 관계를 정의하고 그 위에 제약을 걸어 두면, 잘못된 값이나 모순된 관계, 규칙 사이의 충돌을 걸러 낼 수 있다. 그러나 이런 정의가 없으면 상식으로 판단할 수 없는 도메인 지식은 검증할 방법이 없다. 프롬프트와 JSON만으로 노드를 잇는 에이전트가 바로 그렇다. 규칙이 어긋나거나 메시지에 필요한 값이 빠져도, 노드가 이를 스스로 추론해서 알아내기란 매우 어렵다.

온톨로지는 프롬프트의 규칙을 정의한다

첫 번째는 프롬프트에 명시되던 규칙을 모델링하는 일이다. 「분석 범위는 올해 1월 1일부터 작업 시점까지」라는 규칙을 온톨로지로 옮기면, 이 규칙은 범위 규칙이라는 클래스의 인스턴스(R1)가 된다. 그리고 이 규칙이 무엇을 대상으로 하는지(매출), 어느 노드에 할당되는지(이 범위의 매출을 다루는 노드 A와 B), 범위가 언제 시작하는지(2026년 1월 1일)가 각각 관계로 적힌다. 같은 방식으로 「매출은 연결 기준으로 본다」는 규칙도 기준 규칙이라는 클래스의 인스턴스(R2)로 적을 수 있다.

범용 개념은 W3C 어휘를 그대로 쓸 수 있다. 규칙과 할당, 대상은 ODRL로, 시간은 OWL-Time으로, 노드 자체는 PROV-O의 소프트웨어 에이전트로 표현한다. ODRL은 원래 데이터 이용 정책(허용·금지·의무)을 적는 어휘지만, 「누구에게(assignee) 무엇에 대해(target) 무엇을(action) 어떤 조건으로」라는 뼈대가 노드에 규칙을 할당하는 구조와 그대로 맞는다. 노드가 반드시 지켜야 하는 범위 규칙은 이 셋 가운데 의무(Duty)에 해당하므로, 범위 규칙을 ODRL의 Duty 하위 클래스로 두면 ODRL이 이미 정해 둔 의무의 의미를 그대로 물려받는다(W3C 2018). 매출이나 범위 규칙처럼 도메인에 고유한 개념만 따로 정의하면 된다.

이렇게 적어 두면 프롬프트는 사람이 노드마다 손으로 쓰는 글이 아니라, 그래프에서 생성하는 결과가 된다. 사람이 노드마다 자연어로 규칙을 쓰면 같은 규칙도 노드마다 조금씩 다르게 적히기 쉽다. 그래프에서 생성하면 모든 노드의 프롬프트가 같은 정의에서 나온다. 각 노드의 프롬프트에는 그 노드에 할당된 규칙만 들어가고, 다른 노드의 역할에 필요한 규칙은 들어가지 않는다. R1은 A와 B 모두에 할당되어 있으므로 두 프롬프트에는 같은 정의에서 나온 같은 범위가 들어간다. 규칙은 온톨로지 한 곳에서 관리되기 때문에, 노드 A와 B의 프롬프트에 서로 다른 범위가 적히는 일도, 규칙의 중복과 모순도 줄어든다.

온톨로지는 메시지의 스키마를 정의한다

두 번째는 노드 사이를 오가는 메시지의 스키마를 모델링하는 일이다. 노드 A가 다음 노드에 이런 JSON을 넘긴다고 해 보자.

{ "회사": "A사", "매출": 41.2, "영업이익": 3.1, "단위": "억 원", "기간": "YTD", "기준": "연결" }

회계 전문가는 워크플로의 맥락에서 「단위」·「기간」·「기준」이 매출과 영업이익 모두를 꾸미는 말이라고 암묵적으로 이해한다. 그러나 다른 전문가는 「기준: 연결」이 매출에만 해당하고 영업이익은 다른 기준이라고 읽을 수도 있다. 그리고 그 해석이 틀렸다고 말할 근거가 JSON 안에는 없다. 여섯 키가 모두 같은 높이에 놓여 있을 뿐, 「단위」나 「기준」이 어느 값에 붙는지는 구조 어디에도 없기 때문이다. JSON에는 키만 있고 키 사이의 관계, 곧 스키마가 빠져 있다. JSON Schema를 쓰면 구조를 중첩해 「매출에는 기간과 기준이 반드시 있다」까지는 강제할 수 있다. 그러나 이 스키마는 메시지 하나의 모양에 그쳐서, 이 「기준」이 규칙이 말하는 기준과 같은 개념인지, 「A사」가 다른 시스템의 A사와 같은 회사인지는 정할 수 없다.

온톨로지는 이 빠진 스키마를 채운다. 매출과 영업이익은 각각 클래스가 되고, 메시지에 담긴 「A사의 2026년 누적 연결 매출 41.2억 원」은 매출 클래스의 인스턴스가 된다. 기준·기간·금액·단위는 매출이 갖는 속성으로 정의되고, 영업이익 인스턴스도 자기 기준과 기간, 단위를 따로 갖는다. 그러면 「기준이 영업이익에도 해당하는가」는 읽는 사람의 해석이 아니라 그래프에 적혀 있느냐의 문제가 된다. A사는 문자열이 아니라 고유한 식별자(IRI)를 가진 회사가 된다. 이미 JSON으로 메시지를 주고받는 시스템이라도 형식을 크게 바꿀 필요는 없다. W3C 표준인 JSON-LD를 쓰면 JSON의 모양을 거의 그대로 둔 채, 각 키를 온톨로지의 속성에 대응시킬 수 있다(W3C 2020).

스키마를 이렇게 정의해 두면 검증도 쉬워진다. SHACL은 데이터가 정해진 모양과 제약을 지키는지 확인하는 W3C 표준이다(W3C 2017). 「매출에는 기준이 반드시 하나 있어야 한다」를 SHACL로 적어 두면, 기준이 빠진 메시지는 다음 노드에 들어가기 전에 걸러진다. 결국 노드의 입력은 온톨로지의 클래스와 제약으로 선언되고, 그 선언을 지키지 않은 메시지는 노드에 들어가지 못한다.

두 유형의 정의는 같은 의미 기반을 공유한다

규칙의 대상인 매출과 메시지에 담긴 매출이 같은 클래스를 가리키기 때문에, 메시지가 규칙을 지켰는지도 기계가 확인할 수 있다. 기준 규칙 R2를 예로 들면, R2에서 「매출의 기준은 연결이어야 한다」는 SHACL 제약을 생성해 두면 된다. 별도 기준의 매출이 담긴 메시지는 이 제약에 걸리고, 그 어긋남은 다음 노드에 들어가기 전에 드러난다. 메시지의 기간을 「YTD」 같은 문자열이 아니라 OWL-Time의 구간으로 적어 두면, 그 기간이 범위 규칙 R1과 맞는지도 같은 방식으로 검사할 수 있다. 앞에서 메시지 형식을 아무리 구조화해도 맞춰지지 않는다고 했던 어긋남을, 이제는 기계가 잡아낼 수 있다.

맺으며

에이전트의 성능은 모델 하나의 능력보다 노드들이 정보를 어떻게 주고받느냐에 달려 있다. 노드 사이의 정보 교환은 두 유형으로 나뉜다. 메시지로 직접 넘어가는 데이터와, 각 프롬프트에 담긴 규칙이다. 지금은 둘 다 의미가 정의되지 않은 텍스트로 오간다. 그래서 같은 「매출」을 노드마다 다르게 읽고, 프롬프트 사이의 어긋남도 드러나지 않는다.

온톨로지는 이 두 유형을 같은 어휘로 정의한다. 규칙은 그래프에서 꺼내 노드에 할당하고, 메시지는 클래스와 SHACL 제약으로 검증한다. 규칙과 메시지가 같은 개념을 가리키기 때문에, 메시지가 규칙을 지켰는지도 기계가 확인할 수 있다. 처음에 에이전트에게 필요한 것이 더 많은 텍스트가 아니라 구조화된 지식이라고 한 것은 이런 뜻이다.

온톨로지가 언제 필요해지는지는 데이터의 양보다, 정보와 규칙을 공유하는 노드의 수가 정한다. 노드 하나가 짧은 작업을 처리할 때는 프롬프트에 용어와 계산식을 적어 두는 것으로도 충분하다. 그러나 업무에 들어가는 에이전트는 대부분 여러 노드로 이루어지고, 워크플로가 전문적일수록 노드와 분기는 늘어난다. 노드가 늘수록 주고받는 메시지와 함께 지켜야 할 규칙도 늘고, 그 어긋남은 사람이 프롬프트를 하나씩 읽어서는 찾기 어려워진다. 그때부터 규칙과 메시지의 의미를 노드 밖 한 곳에 정의해 두는 일은 에이전트 설계의 일부가 된다.

참고 문헌