RAG 다음은 Knowledge Graph일까? — Agent 시대에 Ontology가 필요한 이유

Agent 시대에 Ontology가 필요한 이유

“RAG를 구축했는데 답변이 기대만큼 정확하지 않습니다. 지식그래프를 만들면 해결될까요? 온톨로지는 또 무엇이 다른가요?”

기업에서 AI를 도입할 때 자주 나오는 질문입니다. 세 개념이 함께 등장하다 보니 RAG에서 지식그래프로, 다시 온톨로지로 넘어가는 기술 발전 단계처럼 느껴지기도 합니다.

하지만 이들은 서로를 대체하는 다음 버전이 아닙니다. 맡는 역할이 다릅니다. 특히 AI가 질문에 답하는 것을 넘어 실제 업무를 수행하는 에이전트로 확장되면, 어떤 기술을 선택할지보다 각 기술을 어떤 역할로 연결할지가 중요해집니다.

BeSir는 여기서 출발합니다. 기업의 지식을 먼저 모두 지식그래프로 만드는 대신, 기업의 업무 개념과 관계를 정의하고 필요한 데이터와 실행 기능을 연결하는 Ontology-first architecture를 지향합니다. 지식그래프를 필수 전제로 삼지 않되, 필요한 문제에서는 활용하는 접근입니다.

세 가지 개념을 먼저 구분해보면

쉽게 말하면 RAG는 근거를 가져와 답하는 방식, 지식그래프는 사실과 관계를 연결한 지도, 온톨로지는 그 지도에서 사용하는 개념과 관계의 의미를 정한 체계입니다.

실제 시스템에서는 이들이 함께 사용됩니다. 지식그래프를 검색해 RAG의 근거로 제공할 수도 있고, 온톨로지를 기준으로 지식그래프를 구성할 수도 있습니다. GraphRAG처럼 그래프를 검색과 답변 생성에 활용하는 접근도 있습니다. RAG를 벡터 검색 하나와 같은 뜻으로 이해할 필요는 없습니다. RAG 원 논문, Microsoft GraphRAG 문서

질문 하나에 여러 시스템이 필요해지는 순간

다음과 같은 요청을 생각해보겠습니다.

현재 납기가 지연되고 있는 프로젝트 중 주요 고객과 관련된 프로젝트를 찾고, 담당자와 최근 회의에서 논의된 미해결 이슈를 알려줘.

이 요청에 답하려면 먼저 몇 가지를 알아야 합니다.

• 우리 회사에서 ‘주요 고객’으로 분류하는 기준은 무엇인가?
• 어떤 상태의 프로젝트를 ‘납기 지연’으로 판단하는가?
• 해당 프로젝트의 담당자는 누구인가?
• 어떤 회의록이 그 프로젝트에 속하며, 어떤 이슈가 아직 해결되지 않았는가?

고객 등급은 CRM에, 프로젝트 일정과 상태는 업무 데이터베이스에, 회의 내용은 문서 저장소에 있을 수 있습니다. 회의에서 미해결로 기록한 이슈가 이후 업무 시스템에서 완료 처리되었을 수도 있습니다.

관련 문서를 찾는 것만으로는 충분하지 않은 이유입니다. 검색 결과가 비슷한 내용을 담고 있는지에 더해, 같은 고객과 프로젝트에 관한 정보인지, 어떤 시점의 상태인지, 어느 시스템을 기준으로 판단해야 하는지도 알아야 합니다.

지식그래프는 이런 관계를 표현하고 탐색하는 데 유용합니다. 예를 들어 ‘고객 → 프로젝트’ 관계를 찾은 뒤, 프로젝트에서 담당자와 회의로 나아가고, 회의에 연결된 이슈를 확인할 수 있습니다. 여러 관계를 단계적으로 따라가는 탐색을 흔히 멀티홉 탐색이라고 합니다. W3C RDF Primer

다만 관계를 탐색할 수 있다는 사실과, 업무상 올바른 결론을 낸다는 사실은 다릅니다. ‘주요 고객’의 기준이나 ‘미해결’의 의미가 일관되지 않으면, 연결된 데이터를 찾고도 잘못 판단할 수 있습니다.

지식그래프를 만들면 새롭게 운영해야 할 것도 생긴다

여러 시스템의 데이터를 추출해 별도의 지식그래프로 저장하는 방식에서는 데이터 연결과 함께 유지 관리도 설계해야 합니다.

CRM의 ‘서버키트’와 ERP의 ‘주식회사 서버키트’를 같은 고객으로 식별하고, 문서 속 프로젝트 이름을 실제 프로젝트 식별자와 연결해야 합니다. 원본의 담당자나 상태가 바뀌면 그래프에도 반영해야 합니다. 관계의 출처와 갱신 시점도 추적할 수 있어야 합니다.

이렇게 구축한 그래프는 재사용 가능한 자산이 될 수 있습니다. 동시에 추출, 식별, 갱신, 품질 관리에 들어가는 비용도 운영 계획에 포함해야 합니다. 문서에서 그래프를 추출하는 과정의 예는 Microsoft의 GraphRAG 문서에서도 확인할 수 있습니다. Microsoft GraphRAG 문서

물론 모든 지식그래프가 데이터를 별도 저장소에 복제해야 하는 것은 아닙니다. 원본 데이터에 매핑해 접근하는 가상 지식그래프 방식도 있습니다. 따라서 구분해야 할 것은 ‘그래프인가 아닌가’만이 아니라, 어떤 데이터를 어디에 두고 어떻게 최신 상태를 유지할 것인가입니다. Ontop 가상 지식그래프

BeSir가 던지는 질문도 여기에 있습니다.

“기업의 모든 데이터를 먼저 하나의 지식그래프로 구축해야 에이전트를 시작할 수 있을까?”

BeSir의 관점에서는 반드시 그럴 필요는 없습니다.

온톨로지: 데이터가 무엇을 의미하는지부터 정의하기

온톨로지는 기업의 업무에 등장하는 개념과 관계를 명시적으로 정의하는 모델입니다. ‘고객’, ‘프로젝트’, ‘계약’, ‘직원’은 어떤 대상인지, 프로젝트와 고객은 어떻게 연결되는지 등을 설명합니다. 실제 고객이나 프로젝트 하나하나의 연결 사실을 표현하는 것과는 역할이 다릅니다. W3C OWL 2 Primer

앞선 사례에서 온톨로지와 그에 연결된 업무 규칙을 설계한다면 다음과 같은 질문을 다룰 수 있습니다.

여기서 구분할 점이 있습니다. 온톨로지라는 개념 자체에 데이터베이스 접속이나 API 실행 기능이 자동으로 포함되는 것은 아닙니다. 데이터 소스 매핑, 조회 도구, 실행 기능, 권한 통제는 이를 사용하는 시스템에서 구현하고 연결해야 합니다.

BeSir는 온톨로지를 업무 의미의 중심에 두고, 그 의미를 실제 데이터 접근과 행동으로 이어주는 구조를 지향합니다. 단어와 관계를 정의하는 데서 멈추지 않고, 에이전트가 그 정의를 업무 수행에 활용하도록 만드는 것입니다.

BeSir의 관점: 의미를 먼저 정의하고, 적합한 접근 수단을 연결한다

기업에는 이미 업무별 기준 시스템이 있습니다. ERP에는 주문과 매출이 있고, CRM에는 고객 정보가 있으며, 프로젝트 DB에는 진행 상태가 있습니다. 회의록과 매뉴얼은 문서 저장소에 있습니다.

BeSir의 Ontology-first 접근은 이 기존 시스템들을 활용하면서, 에이전트가 공통된 업무 개념을 통해 필요한 정보와 기능에 접근하도록 연결하는 데 초점을 맞춥니다.

앞선 요청이라면 다음처럼 역할을 나눌 수 있습니다.

이때 SQL은 질의 언어이고, API는 시스템을 사용하는 인터페이스이며, 지식그래프는 데이터를 표현하는 모델입니다. RAG는 조회한 근거를 답변 생성에 활용하는 방식입니다. 서로 다른 역할을 맡기 때문에 하나를 고르고 나머지를 버릴 필요가 없습니다.

BeSir가 지향하는 구조를 개념적으로 정리하면 다음과 같습니다.

사용자의 업무 요청
        ↓
에이전트
        ↓
온톨로지 기반 업무 의미 + 데이터·기능 연결 정의
        ↓
조회 및 실행 계획
        ↓
SQL · API · 문서 검색 · 필요시 지식그래프 조회
        ↓
기업의 기존 시스템

조회 결과 → 근거를 바탕으로 답변
실행 요청 → 권한·검증·필요한 승인 → 실행 및 기록

이 그림은 설계 관점을 설명한 것입니다. 실제로 어떤 연결과 실행을 제공할지는 대상 시스템과 업무 범위에 따라 구체화해야 합니다.

‘프로젝트가 무엇인가’에서 ‘프로젝트에 무엇을 할 수 있는가’로

질문이 “담당자를 알려줘”에서 “담당자에게 지연 이슈를 전달해줘”로 바뀌면 에이전트는 조회를 넘어 행동해야 합니다.

그래서 BeSir는 업무 객체의 의미와 함께, 그 객체에 연결된 실행 기능을 중요하게 봅니다. 프로젝트를 예로 들면 다음과 같이 설계할 수 있습니다.

이는 특정 API 이름이나 모든 환경에서 제공되는 기능 목록이 아니라, 업무 객체와 기능을 연결하는 예시입니다.

에이전트가 ‘담당자 변경’ 기능의 존재를 이해하는 것과 실제로 변경 권한을 갖는 것은 별개입니다. 온톨로지는 의미와 기능을 연결하는 기준이 되고, 실제 실행 계층은 권한과 조건을 확인해야 합니다.

이런 의미에서 BeSir는 온톨로지를 Semantic & Action Layer, 즉 업무의 의미를 해석하고 허용된 행동으로 이어주는 계층의 중심으로 바라봅니다.

BeSir의 차별점은 에이전트가 늘어난 뒤에도 이어져야 한다

BeSir가 강조하는 차별점은 온톨로지라는 기술 이름 하나에 있지 않습니다. 업무 지식을 구조화하는 과정, 기존 시스템과 실행을 연결하는 방식, 내부 인력이 이를 이어서 운영하는 방식을 함께 설계하는 데 있습니다.

첫째, 현업의 설명을 에이전트가 사용할 수 있는 업무 구조로 연결합니다.

‘중요한 고객은 따로 관리한다’거나 ‘이 상태에서는 다음 단계로 넘기면 안 된다’는 지식은 문서보다 담당자의 경험에 남아 있을 수 있습니다. BeSir는 현업 인터뷰와 시스템 정보를 바탕으로 이런 지식을 명시적인 개념과 규칙으로 정리하는 데 초점을 둡니다. BeSir 제품 소개

둘째, 기존 시스템을 활용해 이해에서 실행까지 연결합니다.

공통된 업무 개념에 데이터와 기능을 연결하면, 에이전트를 추가할 때마다 같은 고객 정의나 프로젝트 조회 방법을 반복해서 설계하는 일을 줄일 수 있습니다. 예를 들어 지연 보고 에이전트와 고객 대응 에이전트가 같은 프로젝트 정의와 조회 기능을 활용하도록 설계하는 것입니다. 이것이 Ontology-first 접근으로 얻고자 하는 재사용의 가치입니다.

셋째, 다음 에이전트를 만들고 운영하는 역량을 기업 내부에 남기는 것을 목표로 합니다.

에이전트가 몇 개일 때는 외부 전문가가 개별적으로 구축하고 수정하는 방식으로 대응할 수 있습니다. 수십 개에서 수백 개로 늘리려면 업무 변경 때마다 누가 정의를 수정하고, 영향을 확인하고, 결과를 검증할지까지 정해야 합니다.

BeSir가 내부 인력의 구축·운영 역량을 중요하게 보는 이유입니다. 공통된 업무 정의와 기능을 바탕으로 다음 에이전트를 만들고, 업무를 아는 사람들이 변화에 대응하도록 하는 것이 목표입니다. BeSir의 공개 소개도 첫 에이전트 공동 구축 이후 고객 팀이 후속 에이전트를 만들 수 있도록 지원하는 방향을 설명합니다. BeSir 제품 소개

물론 공통 정의를 사용한다고 운영 비용이 자동으로 사라지는 것은 아닙니다. 여러 에이전트가 같은 정의를 사용하는 만큼, 변경의 영향 범위와 버전, 권한, 검증을 관리해야 합니다. 구축 시간을 줄이는 것에 더해 변경 후에도 의도대로 동작하는지 확인할 수 있어야 확산이 가능합니다.

에이전트는 기업을 어떻게 이해해야 할까?

RAG는 필요한 근거를 가져와 답변에 활용합니다. 지식그래프는 실제 대상 사이의 관계를 표현하고 탐색하게 합니다. 온톨로지는 그 대상과 관계의 의미를 정의합니다.

에이전트가 업무를 수행하려면 여기에 한 단계가 더 필요합니다. 그 의미를 실제 데이터와 연결하고, 수행할 수 있는 기능과 조건을 명확하게 정해야 합니다.

BeSir는 이 연결의 중심에 온톨로지를 둡니다. 필요한 곳에서는 문서를 검색하고, 데이터베이스를 조회하고, 지식그래프를 탐색하며, 허용된 범위에서 API를 실행하도록 설계합니다.

그래서 BeSir가 기업에 먼저 묻고 싶은 것은 “지식그래프를 도입할까요?”보다 구체적인 질문입니다.

“에이전트가 수행할 업무는 무엇이며, 그 업무를 이해하는 데 필요한 개념·데이터·행동은 어떻게 연결되어 있습니까?”

이 질문에 답하는 구조가 있다면 첫 번째 에이전트에서 얻은 지식과 기능을 다음 에이전트에도 이어갈 수 있습니다. BeSir가 Ontology-first 접근으로 만들고자 하는 것은, 기업이 스스로 에이전트를 확장하고 운영할 수 있는 기반입니다.