🧠 레슨

온톨로지가 필요 없는 순간 — GraphRAG 마케팅에 속지 않기

RAG·GraphRAG·GraphDB·온톨로지를 분리해서 보고, 전사 온톨로지보다 먼저 해야 할 검색 기본기를 판단한다.

① 반대편 관점도 같이 보기

온톨로지는 좋은데, 항상 필요한 건 아닙니다

앞 레슨에서는 에이전트 루프에 온톨로지와 지식그래프를 붙이면 LLM 결과를 업무 규칙으로 검증할 수 있다고 봤습니다.

이번 글은 반대편 질문을 던집니다. “그런데 우리 회사가 정말 온톨로지부터 사야 할까?”입니다. 결론은 온톨로지를 깎아내리는 게 아니라, 쓸 자리를 정확히 보자는 쪽입니다.

오늘의 한 문장

온톨로지는 만능 AI 인프라가 아니라, 합의된 도메인과 닫힌 규칙이 있을 때 강한 도구입니다.

📚 「온톨로지가 필요 없는 순간 — GraphRAG 마케팅에 속지 않기」 레슨 내용 전체 텍스트로 훑어보기

온톨로지는 좋은데, 항상 필요한 건 아닙니다

앞 레슨에서는 에이전트 루프에 온톨로지와 지식그래프를 붙이면 LLM 결과를 업무 규칙으로 검증할 수 있다고 봤습니다.

오늘의 한 문장

온톨로지는 만능 AI 인프라가 아니라, 합의된 도메인과 닫힌 규칙이 있을 때 강한 도구입니다.

글에서 가장 먼저 지적하는 오해는 무엇일까요?

맞아요. RAG는 ‘외부 근거를 찾아 LLM에 넣는 패턴’입니다. backend는 vectorDB일 수도, BM25일 수도, SQL/metadata filter/reranker/graph일 수도 있습니다. vectorDB 하나만 써놓고 ‘RAG가 약하다’고 말하면 비교가 불공정해집니다.

둘은 적이 아니라 쓰임이 다른 도구입니다.

온톨로지: 합의된 개념, 관계, 규칙을 엄밀하게 표현한다. 표준 분류, 규제 코드, 닫힌 룰셋, 재사용 가능한 도메인 모델에 강하다.

Hybrid RAG: 원문 문서를 보존하고 BM25, vector, metadata filter, reranker 등으로 근거를 찾는다. 사내 문서 QA, 정책 검색, 고객지원 assistant처럼 의미가 흔들리는 업무에 먼저 적용하기 쉽다.

일반 회사에서 온톨로지가 어려워지는 이유는 기술보다 조직 합의입니다.

같은 단어, 다른 뜻

영업팀의 customer: 아직 계약 전인 리드까지 포함할 수 있음
마케팅팀의 customer: 캠페인 대상 또는 가입자를 뜻할 수 있음
회계팀의 customer: 청구가 시작된 계정만 뜻할 수 있음

이 차이를 하나의 정의로 고정하려면 데이터베이스 프로젝트가 아니라 거버넌스와 변경관리 프로젝트가 됩니다. 그래서 ‘전사 온톨로지’는 생각보다 오래 걸리고 무거워질 수 있습니다.

회사에 사내 문서 검색봇을 만들었는데 답이 자주 틀립니다. 현재는 vector 검색만 쓰고, 권한/문서 타입/날짜 metadata도 부실하고, 평가셋도 없습니다.

이때 가장 먼저 할 일로 적절한 것은?

정답입니다. 글의 핵심 실무 순서는 ‘먼저 작고 지루한 기본기’입니다. 원문 보존, 권한, metadata, hybrid search, reranker, 평가셋, 실패 로그가 정리되지 않은 상태에서 온톨로지부터 가면 비용이 먼저 커집니다.

실무 데이터는 기록 시점에 의미가 고정되지 않는 경우가 많습니다.

1일 차: 사용자는 “로그인이 안 됩니다”라고 문의합니다.
1일 차 오후: 상담사는 비밀번호 재설정 이슈로 봅니다.
2일 차: 엔지니어는 OAuth callback 설정 문제로 봅니다.
3일 차: 보안팀은 의심 IP 패턴을 보고 계정 보호 이슈로 재분류합니다.
5일 차: 고객 성공팀은 엔터프라이즈 온보딩 실패 사례로 기록합니다.

하나의 티켓이 인증 문제, 설정 문제, 보안 이벤트, 온보딩 리스크로 계속 재해석됩니다. 이럴 때는 “최종 정답 하나”보다 원문과 관점의 변화를 보존하는 편이 더 실용적입니다.

아래 중 글의 관점에 가장 맞는 설명은 무엇일까요?

맞아요. GraphRAG는 그래프를 검색/요약 구조로 쓰는 RAG 패턴일 수 있고, graph DB는 저장소입니다. 온톨로지는 도메인 모델입니다. OWL은 그중에서도 형식 논리와 추론에 가까운 강한 표현입니다. 한 덩어리로 사면 안 됩니다.

‘온톨로지로 만들었다’는 말은 실제로 여러 뜻으로 쓰입니다.

내부 사전/인스턴스 그래프: 우리 회사에서만 통하는 용어 정의, 제품 목록, 고객 245만 명, 작품 세계관의 인물 관계처럼 특정 조직/작품 안의 사실 모음이다.

온톨로지에 가까운 것: 다른 조직이나 시스템도 재사용할 수 있는 분류 체계와 관계 모델이다. 의료 표준, 행정 코드, schema.org 같은 공통 모델에 가깝다.

그래프 화면은 회의에서 강합니다. 고객, 제품, 계약, 문서, 담당자가 노드와 엣지로 연결되면 매우 똑똑해 보입니다.

하지만 결재 기준은 화면이 아닙니다

사용자는 대개 그래프 탐색 화면이 아니라 검색 결과, 답변, 알림, 업무 화면을 봅니다.

깊은 관계 탐색이 제품 가치인 사기 탐지, 자금세탁, 공급망 리스크, 권한 전파 같은 영역은 graph가 맞을 수 있습니다. 하지만 단순 1~2 hop 질의라면 SQL JOIN과 metadata filter로 충분할 수도 있습니다.

사내 문서 QA나 정책 검색을 만들 때, 글이 권하는 현실적인 순서를 맞춰보세요.

좋습니다. 핵심은 처음부터 모든 의미를 고정하지 않는 것입니다. 의미가 안정적으로 반복되는 작은 구간이 보이면 그때 모델로 올리는 편이 빠르고 싸고 검증 가능합니다.

아래 중 온톨로지/강한 도메인 모델이 상대적으로 잘 맞는 경우는 무엇일까요?

맞아요. 분류 자체가 제품이거나, 표준 코드가 있거나, 닫힌 규칙 추론이 핵심이거나, 관계 탐색 자체가 비즈니스 가치인 경우에는 온톨로지/그래프 설계가 좋은 선택일 수 있습니다.

오늘 배운 판단 기준을 한 줄로 정리해봅시다.

정답입니다. 온톨로지는 좋은 도구지만, 먼저 원문·권한·검색·평가를 정리하고, 안정적으로 반복되는 의미만 작은 모델로 올리는 순서가 실무적입니다.

GraphRAG/ontology 제안을 받으면 아래 질문으로 범위를 좁히면 됩니다.

“기존 RAG의 한계”가 vectorDB 단독의 한계인가요, hybrid RAG까지 포함한 한계인가요?
인용한 GraphRAG 사례가 OWL 추론을 썼나요, property graph + LLM extraction인가요?
우리 도메인에는 이미 재사용 가능한 표준이 있나요?
결과물이 외부 조직도 재사용할 수 있는 모델인가요, 내부 glossary인가요?
첫 사용자가 결과를 보기까지 며칠이 걸리나요?
구축 후 누가 definition, mapping, rule 변경을 승인하나요?

답이 흔들리면 프로젝트를 버리라는 뜻이 아니라, 전사 온톨로지가 아니라 작은 schema layer나 hybrid RAG 개선으로 이름과 범위를 줄이라는 신호입니다.