온톨로지, 지식그래프, RAG — R&D 관점에서 정리해 봅니다
지식관리 시리즈·기술편
세 편에 걸쳐 지식관리 이야기를 했습니다.
1편 — 지식은 전달되는 것이 아니라 쌓이는 것입니다
2편 — 쌓는 것과 꺼내 쓰는 것은 다른 문제입니다
3편 — 판단의 전제가 남아야 상황이 바뀌었을 때 알아챕니다
여기까지 읽으신 분들이 하실 만한 질문이 있습니다.
"좋은 얘기인데, 그거 원래 다들 하려던 거 아닌가요?"
맞습니다. 새로운 이야기가 아닙니다. 20년 전에도 하려던 이야기입니다. 그런데 잘 안 됐습니다.
오늘은 왜 그동안 잘 안 됐고, 지금은 무엇이 달라졌는지를 다뤄보겠습니다. 그리고 요즘 자주 들리는 온톨로지, 지식그래프, RAG 같은 말들이 이 이야기와 어떻게 연결되는지도 정리하겠습니다.
20년 전에도 지식관리는 있었습니다
2000년대 초반에 KMS(지식관리시스템) 붐이 있었습니다. 많은 기업이 도입했고, 많은 기업이 실패했습니다.
그때 무엇이 걸림돌이었는지 되짚어 보면 이렇습니다.
| 걸림돌 | 당시 상황 |
|---|---|
| 분류를 사람이 전부 해야 했음 | 자료를 올릴 때마다 분류코드를 고르고, 키워드를 달고, 관련 문서를 지정. 하나 올리는 데 몇 분씩 소요 |
| 표현이 다르면 못 찾았음 | 시스템은 글자가 일치해야 검색. 같은 것을 다르게 부르면 검색 결과 0건 |
| 관계를 일일이 손으로 이어야 했음 | 문서 간 관련성을 사람이 지정. 자료가 늘어날수록 감당 불가 |
세 가지 모두 결국 같은 문제입니다. 사람의 부담이 너무 컸습니다.
이 시리즈에서 계속 말씀드린 것처럼, 부담이 크면 지속되지 않습니다. 처음 몇 달은 열심히 합니다. 그리고 바빠지면 건너뜁니다. 몇 년 뒤 그 시스템은 아무도 안 들어가는 공간이 됩니다.
즉, 방향이 틀렸던 게 아니라 도구가 부족했던 것입니다.
무엇이 달라졌나
최근 몇 년 사이에 이 세 가지 걸림돌이 상당 부분 낮아졌습니다.
| 변화 | 효과 |
|---|---|
| 의미 기반 검색 | 글자가 일치하지 않아도 뜻이 비슷하면 찾아냄. 같은 원료를 국문으로 쓰든 영문 약어로 쓰든 연결 가능 |
| 분류 · 관계 자동 제안 | 자료 등록 시 어떤 분류에 속할지, 어떤 기존 자료와 관련 있을지를 시스템이 먼저 제시. 사람의 일이 "만드는 것"에서 "확인하는 것"으로 전환 |
| 자동 요약 · 정리 | 과제를 새로 맡은 사람이 수십 건의 자료를 다 읽지 않아도, 지금까지의 흐름을 정리한 형태로 열람 가능 |
세 가지 모두 1장에서 말한 걸림돌에 정확히 대응합니다. 그래서 지금이 다시 시도해 볼 만한 시점인 것입니다.
온톨로지와 지식그래프
여기서 용어를 정리하고 가겠습니다. 요즘 자주 들리는데 헷갈리기 쉬운 개념들입니다.
온톨로지는 개념과 관계를 정의해 둔 것입니다. 2편에서 이미 다뤘습니다. 무엇이 무엇과 어떤 관계로 이어지는지를 정리해 둔 지도라고요.
- 처방은 원료를 포함한다
- 시험은 가정을 검증한다
- 과제는 다른 과제의 후속이다
- 판단은 자료를 근거로 한다
이런 개념과 관계의 종류를 미리 정의해 두는 것이 온톨로지입니다. 설계도에 가깝습니다.
지식그래프는 그 설계도에 실제 데이터가 채워진 것입니다.
- 처방 A-3은 원료 B를 포함한다
- 시험 #127은 "이 조건에서 안정성이 확보된다"는 가정을 검증했다
- 과제 P-2024-01은 과제 P-2021-05의 후속이다
이렇게 실제 대상들이 실제 관계로 연결된 거대한 그물이 지식그래프입니다. 온톨로지가 틀이라면 지식그래프는 그 틀에 내용이 들어간 결과물입니다.
연구소 관점에서 왜 중요하냐면, 이 그물이 있어야 2편에서 말한 연결이 실제로 작동하기 때문입니다. 원료 하나에 문제가 생겼을 때 그물을 따라가면 영향받는 처방과 과제가 나옵니다. 어떤 판단의 근거가 무엇이었는지도 따라갈 수 있습니다.
그리고 3편의 재검토 연쇄도 이 그물 위에서 일어납니다. 새 정보가 어떤 가정을 흔들고, 그 가정이 어떤 판단에 걸려 있고, 그 판단이 어떤 과제로 이어졌는지. 전부 연결을 따라가는 일입니다.
RAG — 회사 지식을 AI에 연결하는 방식
또 하나 자주 듣는 말이 RAG입니다.
먼저 전제부터 짚겠습니다. LLM은 우리 회사 내부를 모릅니다. 일반적인 언어 모델은 공개된 자료로 학습되어 있습니다. 우리 연구소가 어떤 과제를 했고 어떤 판단을 내렸는지는 당연히 모릅니다.
RAG는 이 간극을 메우는 방식입니다. 질문이 들어오면 회사 내부 자료에서 관련된 부분을 먼저 찾아온 다음, 그것을 함께 제공해서 답을 만들게 합니다.
여기서 중요한 오해 하나를 짚겠습니다.
AI를 도입한다고 우리 회사를 학습하는 것이 아닙니다.
학습이 아니라 참조입니다. 질문할 때마다 자료를 찾아서 보여주고 그걸 근거로 답하게 하는 것입니다. 그래서 찾아올 자료가 없으면 아무것도 할 수 없습니다.
이 구분이 실무에서 중요합니다. "AI를 도입했는데 왜 우리 과제를 모르나요"라는 질문이 나오는 이유가 여기 있습니다.
그런데 자료를 찾아오는 것만으로는 부족합니다
RAG는 강력하지만 한계가 있습니다. 그리고 이 한계가 2편에서 말씀드린 것과 정확히 같습니다.
일반적인 RAG는 문서를 잘게 잘라 저장해 두고, 질문과 의미가 비슷한 조각을 찾아옵니다. 비슷한 것을 찾는 데는 잘 작동합니다.
문제는 관계를 따라가야 하는 질문입니다.
"이 원료를 쓴 과제가 뭐였지?"까지는 됩니다. 그런데 "그 과제에서 내린 판단이 지금 개정된 규제에 걸리나?"는 다릅니다. 원료 → 과제 → 판단 → 규제로 여러 단계를 건너가야 답이 나옵니다.
조각으로 잘라놓은 자료에서는 이게 잘 안 됩니다. 각 조각은 비슷한 것을 담고 있지만, 조각과 조각 사이의 관계는 담고 있지 않기 때문입니다.
2편에서 저희는 "검색은 점, 연결은 선"이라고 말씀드렸습니다. 같은 한계가 여기서 기술적인 형태로 반복되는 것입니다.
그래서 지식그래프를 결합합니다
이 문제를 풀기 위해 지식그래프와 RAG를 결합하는 접근이 나왔습니다. GraphRAG라고 부르는데, 2024년 마이크로소프트 리서치에서 제시한 이후 기업 환경에서 활발히 논의되고 있습니다.
원리는 단순합니다. 비슷한 것을 찾는 방식과, 관계를 따라가는 방식을 함께 쓰는 것입니다. 넓게 훑어서 후보를 모으는 일은 기존 방식이 하고, 관계를 여러 단계 따라가야 하는 일은 그래프가 합니다.
다만 정직하게 덧붙일 것이 있습니다. 이 방식이 만능은 아닙니다. 지식그래프를 구축하는 일 자체가 어렵고, 운영 비용도 만만치 않습니다. 무엇을 개념으로 볼지, 어떤 관계를 정의할지, 그것을 어떻게 계속 갱신할지를 다 정해야 합니다.
그리고 이 작업이 바로 2편에서 말씀드린 분류체계 설계와 이어집니다. 여러 관점의 축을 세우고, 각 축이 섞이지 않게 유지하는 일이요. 기술이 발전해도 이 부분은 여전히 사람이 판단해야 하는 영역입니다.
그래서 순서가 있습니다
지금까지 이야기를 한 문장으로 줄이면 이렇습니다.
구조가 먼저이고, AI는 그 위에 얹힙니다.
AI가 분류를 제안하려면 분류체계가 있어야 합니다. 관련 자료를 찾아오려면 관계가 정의되어 있어야 합니다. 판단의 근거를 알려주려면 판단이 기록되어 있어야 합니다.
AI는 없는 것을 만들어내지 못합니다.
이게 가장 중요한 지점입니다. 어떤 과제에서 왜 그 방향을 골랐는지가 아무 데도 적혀 있지 않다면, AI도 알 수 없습니다. 그럴듯한 추측을 제시할 수는 있지만, 그건 회사의 지식이 아닙니다.
그리고 이게 실제로 가장 위험한 상황입니다. 구조 없이 AI만 얹으면, 정리되지 않은 문서 더미에서 그럴듯한 답이 나옵니다. 문장은 매끄럽고 근거도 있어 보입니다. 그런데 그게 맞는지 확인할 방법이 없습니다. 근거가 어디서 왔는지, 무엇을 빠뜨렸는지 추적이 안 되니까요.
틀린 답보다 확인할 수 없는 답이 더 위험합니다.
| 1편 | 판단이 기록된다 (족적) |
| ↓ | |
| 2편 | 관계가 정리된다 (연결) |
| ↓ | |
| 3편 | 전제가 명시된다 (재검토의 기반) |
| ↓ | |
| 4편 | 그 위에 AI가 얹힌다 (활용) |
아래가 없으면 위가 서지 않습니다.
그러면 지금 무엇을 해야 하나
"그럼 구조부터 다 갖추고 나서 AI를 하라는 말인가요?"
그렇지는 않습니다. 다 갖추고 시작하려면 시작을 못 합니다. 현실적인 접근은 두 가지입니다.
첫째, 지금 쌓고 있는 데이터의 구조를 봐두십시오.
당장 AI를 도입하지 않더라도, 지금 쌓는 자료에 최소한의 구조가 있는지는 확인할 수 있습니다. 어떤 과제의 자료인지, 어떤 판단과 연결되는지, 왜 만들어졌는지. 이 정도만 붙어 있어도 나중에 활용할 수 있습니다.
반대로 구조 없이 몇 년치를 쌓아두면, 나중에 그것을 정리하는 데 처음부터 만드는 것보다 더 큰 비용이 듭니다.
둘째, 한 영역부터 시작하십시오.
전사 지식관리를 한 번에 하려는 시도는 대개 실패합니다. 자료가 가장 많이 쌓이는 한 영역, 담당자 교체가 잦은 한 영역부터 해보는 것이 낫습니다. 거기서 작동하는 것을 확인한 뒤 넓히면 됩니다.
마치며 — 시리즈를 닫으며
네 편에 걸쳐 지식관리를 다뤘습니다. 기술 이야기로 끝나지만, 결론은 처음과 같습니다.
지식관리는 도구의 문제가 아닙니다. 20년 전에 실패한 이유가 도구 때문이었으니 도구가 좋아지면 될 것 같지만, 그렇지 않습니다. 도구는 부담을 낮춰줄 뿐이고, 무엇을 남길 것인지, 어떻게 연결할 것인지, 무엇을 전제로 판단했는지는 여전히 조직이 정해야 합니다.
그리고 이것은 결국 그 조직이 어떻게 일하는가의 문제입니다. 이 블로그에서 계속 말씀드려 온 이야기와 같은 자리로 돌아옵니다.
저희가 25년간 "시스템이 아닌 기업 자산을 만듭니다"라고 말해 온 것의 의미가 여기 있습니다. 기술은 계속 바뀝니다. 지금 최신인 방식도 몇 년 뒤에는 달라질 것입니다. 다만 그 안에 쌓인 판단과 관계와 이력은 회사에 남습니다.
다음 시리즈 예고
이번 시리즈는 기업의 지식을 어떻게 관리할 것인가에 집중했습니다.
그런데 R&D 관리에는 또 하나의 축이 있습니다. 기업의 의도를 관리하는 영역입니다. 전략과 방향, 과제 포트폴리오, 자원 배분, 그리고 그 판단들이 어떻게 연결되고 갱신되는가.
지식이 축적의 문제라면, 의도는 정렬의 문제입니다. 그리고 이 둘은 결국 만나게 됩니다.
다음 시리즈에서 이어가겠습니다.
네 편 모두 읽어주셔서 감사합니다.
CONTACT US