LLM을 중심에 두지 않는 트렌드 분석: 온톨로지와 LLM Wiki로 매일 자라는 뉴스 지식 그래프 (KBES 발표)

이 글은 한국 비즈니스 실험 학회(KBES)에서 발표한 "온톨로지 기반 뉴스 트렌드 지식 그래프" 세션을 글로 옮긴 것입니다. 상단에 임베드된 발표 영상과 함께 보시면 좋습니다. 본문 속 모든 수치는 이 사이트 프로덕션 DB의 실측값(기사 1,909편, 2026-04-01~07-05, 조회 2026-07-07)입니다.

들어가며: 뉴스 홍수에서 가설 건지기

매일 쏟아지는 기술 뉴스와 데이터를 다 따라가려다 지친 적이 있으실 겁니다. 저도 마찬가지였습니다. 그래서 이 홍수 속에서 알맹이만 건져 올리는 방법이 없을까 고민했고, 그 답을 온톨로지에서 찾아보기로 했습니다.

오늘 이야기를 한 문장으로 요약하면 이렇습니다. 거대 언어 모델(LLM)을 시스템의 중심에 두지 않고, 매일 자동으로 자라나는 뉴스 트렌드 지식 그래프를 직접 만들고 운영해 본 토이 프로젝트 이야기입니다. 그 결과물이 바로 지금 이 글이 올라와 있는 TrendHacker이고, 이 글은 그 시스템이 어떻게 설계됐는지를 설계자의 관점에서 정리한 것입니다.

미리 말씀드리면 저는 온톨로지 전문가가 아닙니다. 이 글은 정답을 알려 드리는 강의가 아니라, 아무것도 몰랐던 사람이 개념을 공부하고 정의하고 부딪히면서 무엇을 만들었는가에 대한 기록입니다.

가설은 어디서 오는가

본론에 앞서 질문을 하나 드리겠습니다. 업무나 연구에서 다음 분석 주제나 실험 아이디어는 어떻게 정해지나요? 대개는 누군가의 직감, 아니면 회의실에서 나옵니다. 좋은 분석은 좋은 질문에서 시작하는데, 가설을 세운 다음 그것을 검증하는 방법론은 많지만 정작 가설 자체를 만드는 업스트림 과정은 여전히 감(感)에 맡겨져 있습니다.

이 시스템은 바로 그 지점을 겨냥합니다. 매일 쏟아지는 데이터에서 "무엇을 분석할 가치가 있는가"를 찾아 주는 발굴 레이어입니다. 여기서 나오는 것은 결론이 아니라 가설입니다. 그 뒤에 어떤 검증을 붙일지는 별도의 데이터 분석과 실험의 몫이고, 이 시스템은 그 출발점을 만들어 주는 역할만 맡습니다.

개념 1 — RAG에서 LLM Wiki로

첫 번째 재료는 지식을 쌓는 방식입니다. 비교 대상인 RAG(Retrieval-Augmented Generation)부터 보겠습니다. RAG는 질문이 들어오면 문서 더미에서 관련 조각을 검색해 프롬프트에 붙이고 LLM이 답하는 방식입니다. 동작 시점은 질문할 때이고 산출물은 답변입니다. 모델을 재학습하지 않고도 최신 문서로 답할 수 있으니 훌륭한 패턴이지만, 구조적 한계가 하나 있습니다. 지식이 쌓이지 않는다는 것입니다. 원본은 원본 그대로 있고, 같은 질문이 오면 매번 다시 검색해서 답합니다.

한 번 읽은 것을 지식으로 저장하고 갱신하는 방법은 없을까요? 그 질문에 대한 답이 2026년 4월 Andrej Karpathy가 공개한 LLM Wiki 패턴입니다. 소스가 들어오면 LLM이 읽고 핵심을 요약해 기존 위키 문서에 통합합니다. 새로 안 것이 기존 지식 위에 반영되고, 다음 읽기는 갱신된 위키 위에서 이루어집니다. 이전에 읽은 것을 기억하는 상태로 새 소스를 읽는 구조입니다.

구조는 세 계층입니다.

• Raw: 불변의 원본. LLM은 읽기만 합니다.
• Wiki: LLM이 쓰고 고치는 지식 문서. 원본을 증류한 서사가 여기 쌓입니다.
• Schema: LLM을 제멋대로 쓰는 필경사가 아니라 규율 있는 사서로 만드는 규칙 문서. 무엇을 어디에 어떻게 적을지를 정합니다.

사실 "자동으로 유지되는 위키"라는 아이디어 자체는 오래됐지만 늘 같은 이유로 실패해 왔습니다. 누가 유지보수하는가입니다. Wikipedia는 사람들의 자발적 편집 노동으로 굴러가지만 그 비용 때문에 개인이나 팀 규모에서는 자동화가 어려웠습니다. LLM이 이 장부 처리 비용을 사실상 0으로 만들면서, 오래된 아이디어가 드디어 수면 위로 올라온 것입니다.

개념 2 — 택소노미, 온톨로지, 지식 그래프

두 번째 재료는 지식의 뼈대입니다. 온톨로지는 택소노미·지식 그래프와 함께 봐야 이해가 됩니다.

택소노미(taxonomy) 는 위아래가 있는 분류입니다. 도서관 분류표나 쇼핑 카테고리를 떠올리면 됩니다. 가전 아래 주방 가전이 있고 그 아래 전자레인지와 냉장고가 있습니다. 핵심은 하나입니다 — 위와 아래(super/sub)가 있고, 아래는 위의 부분집합이라는 것. 이 구조가 생기는 순간 기계가 할 수 있는 일이 생깁니다. 상하로 합산하고 분리하는 것입니다. 전자레인지가 100대, 냉장고가 50대 팔렸으면 주방 가전은 150대 팔린 것입니다. 택소노미는 단순한 분류표가 아니라 기계가 상위 개념으로 집계할 수 있게 해 주는 장치입니다.

온톨로지(ontology) 는 여기에 관계와 제약을 더한 것입니다. 저는 "한 문장을 지식으로 적기 전에 맺는 약속"이라고 정의합니다. 학계 표준 정의는 1993년 Tom Gruber의 문장입니다.

An ontology is a formal, explicit specification of a shared conceptualization.

쉽게 풀면 "기계도 읽을 수 있게 명시적으로 적은, 모두가 합의한 개념 정의서"입니다. 이 정의서에는 네 가지가 들어갑니다. 클래스(어떤 종류가 있는가), 관계(어떤 사이가 허용되는가), 제약(무엇을 적으면 안 되는가), 인스턴스(약속대로 채워진 실물 데이터). 왜 이런 약속이 필요할까요? 핵심은 관계를 데이터에 심는 것입니다. "RAG는 LLM 기술의 일종이다", "Claude는 Anthropic이 만들었다" — 사람은 문장만 봐도 관계를 이해하지만, 기계는 데이터에 정의되어 있어야 즉시 확인하고 답할 수 있습니다. 그리고 사람·LLM·수집 파이프라인이 모두 정보를 적어 넣는 시스템에서는, 모두가 같은 약속을 공유해야 데이터가 유효한 그물로 얽힙니다.

지식 그래프(knowledge graph) 는 그 정의서대로 쌓인 데이터 인스턴스들입니다. 표준 데이터 모델은 트리플(triple)입니다. "세종대왕은 한글을 창제했다"는 (주어, 술어, 목적어) 세 조각으로 나뉘고, 주어와 목적어가 노드, 술어가 방향 있는 엣지가 됩니다. 노드는 그냥 점이 아니라 개념이고, 엣지는 그냥 선이 아니라 의미입니다. 트리플 하나가 벽돌 하나라면, 지식 그래프는 그 벽돌들이 얽힌 전체 그물입니다.

한 줄로 구분하면 이렇습니다. 온톨로지는 스키마(틀)이고, 지식 그래프는 그 틀에 채워진 데이터(인스턴스)입니다. 둘은 자주 함께 쓰이지만 같은 것이 아닙니다.

시스템 전체 그림 — 네 걸음

이제 이 두 재료를 하나로 합칩니다. TrendHacker의 소스는 GeekNews — Hacker News 스타일의 한국어 기술 뉴스 큐레이션입니다. 매일 좋은 글이 올라오지만 너무 많아서 다 못 읽습니다. 그렇다면 이 매일의 뉴스에서 지식과 관계를 도출해 보면 어떨까, 가 출발점이었습니다.

매일 아침 6시(KST) cron이 돌면서 수집부터 그래프 적재, 관계 추출, 위키 증류까지 한 시간 안에 끝납니다. 구조는 단순합니다. 무거운 계산은 전부 Supabase(Postgres) 안에 미리 정의해 둔 함수(RPC)가 수행하고, 프론트는 그 결과를 보여 주기만 합니다. 파이프라인 자체는 Ingest(수집) → Tokenize(후보 발굴) → Promote(엔티티 승격) → Enrich(매칭·그래프 적재) 4단계입니다.

이 파이프라인이 지식 그래프를 만드는 과정은 네 걸음으로 요약됩니다.

1. 노드 — 무엇이 키워드가 될 자격이 있는가 (결정론 규칙)
2. 엣지 — 어떤 키워드끼리 얽히는가 (통계 공출현)
3. 의미 — 그 얽힘이 무슨 관계인가 (닫힌 타입 집합의 LLM 분류)
4. 서사 — 오늘 하루를 어떻게 읽을 것인가 (LLM Wiki)

앞의 세 걸음이 온톨로지, 마지막 걸음이 LLM Wiki입니다. 앞에서 소개한 두 개념을 그대로 섞은 것입니다.

첫걸음, 노드 — 키워드는 빈도가 아니라 자격으로

노드가 되는 경로는 두 가지입니다. 하나는 사람이 사전에 등록한 주제(폐쇄형) — RAG, 보안, 임베딩처럼 미리 합의한 주제 어휘집(topics.json)입니다. 사전에 없으면 절대 승격되지 않습니다. 다른 하나는 매일 기사에서 자동으로 발굴하는 고유명사(개방형)입니다. 제가 천재가 아닌 이상 미리 정의하지 못한 이름이 반드시 나오기 때문입니다. NER 모델도 LLM도 없이, 표기 형태(shape) 규칙으로 뽑습니다 — 약어(GPT), 카멜케이스(TensorFlow), 점 패키지(Next.js) 같은 형태는 고유명사 후보가 되고, 한글 일반명사는 빈도와 무관하게 영구 거절됩니다.

이 비대칭이 설계의 핵심입니다. 주제(Topic)는 폐쇄형으로 정밀도를, 실체(Entity)는 개방형으로 재현율을 챙깁니다. "AI"를 1만 번 외쳐도 일반어는 키워드가 못 됩니다.

처음부터 이랬던 것은 아닙니다. 초기에 필터 없이 본문 전체에서 후보를 발굴해 승격시켰더니 엔티티가 9,200개를 넘어갔고, 기사 하나에 태그가 43개씩 붙어 그래프가 의미를 잃었습니다. 회수 방법은 모델을 키우는 것이 아니라 입력을 좁히는 것이었습니다. 발굴은 제목+요약에서만 하고 본문은 매칭에만 쓰도록 바꿨고, 채택 기준도 올렸습니다 — 고유명사조차 서로 다른 기사 2건 이상에서 재등장해야 정식 노드가 됩니다. 우리가 보려는 것이 관계이고 트렌드의 정의가 재등장이라면, 한 번 뜬 단어는 아직 트렌드가 아니기 때문입니다.

둘째 걸음, 엣지 — 같은 기사에 나왔다는 통계

노드가 확정되면 관계를 만듭니다. 확정된 키워드로 각 기사를 훑어 기사마다 중요한 상위 10개를 태깅하고, 한 기사에 함께 태깅된 키워드 쌍마다 공출현(co-occurrence) 점수를 1씩 올립니다. 원래 데이터는 "어느 기사가 어느 키워드를 언급했나"라는 기사↔키워드 관계지만, 기사를 매개로 삼아 키워드↔키워드 관계로 한 번 더 엮은 것입니다. "같은 기사에 나왔다"를 "두 키워드는 연관이 있다"로 바꿔 읽은 것이죠. 기사는 그래프에 직접 그리지 않지만 버리지도 않습니다 — 대시보드에서 엣지를 클릭하면 그 관계를 만든 대표 기사들이 나옵니다.

관계의 강도는 세 가지 지표로 봅니다. 단순 공출현 횟수, Jaccard, 그리고 NPMI(정규화 상호정보량)입니다. NPMI가 왜 필요한지는 실측 파트에서 보여 드리겠습니다.

셋째 걸음, 의미 — 전체 시스템에서 LLM이 들어가는 유일한 자리

공출현은 "얼마나 자주 함께 나왔나"까지만 말해 줍니다. 두 사람이 30번 통화했다는 것은 세면 알 수 있지만, 둘이 친구인지 직장 동료인지는 내용을 읽어야 압니다. 그래서 세는 일은 결정론 규칙에 맡기고, 읽어내는 일만 LLM에 맡겼습니다. 이것이 전체 시스템에서 LLM이 사실 판단에 개입하는 유일한 자리입니다.

대신 LLM이 아무 관계나 지어내지 못하도록 세 겹으로 가뒀습니다.

• 닫힌 타입 집합: 관계 종류를 made_by, is_a, part_of, uses, alternative_to, related_to 여섯 가지로 미리 고정했습니다. 자유 텍스트 출력은 금지입니다.
• 신뢰도 임계: confidence가 0.8 미만이면 노출하지 않고 억제(suppression)합니다.
• 타입별 제약(domain/range): 예컨대 is_a의 상위 자리에는 분류나 개념만 올 수 있습니다. "Claude는 Anthropic의 일종이다" 같은 넌센스는 적재 전에 걸러집니다. 앞에서 계층(택소노미)을 정의해 뒀기 때문에 가능한 검사입니다.

데이터에서 패턴을 읽는 신경망(LLM)과 명시된 규칙으로 제약하는 심볼릭 로직을 결합한 이런 설계를 뉴로심볼릭(neuro-symbolic) 접근이라고 부릅니다. LLM의 유연한 이해에 규칙의 엄밀함을 더해 신뢰성과 설명 가능성을 확보하는 것입니다. 실측 예를 들면 Claude 노드에는 Claude —made_by→ Anthropic(0.95), Claude —is_a→ LLM(0.95), Claude —alternative_to→ ChatGPT(0.92), Claude —uses→ MCP(0.90) 같은 관계가 붙어 있습니다.

비용 이야기를 덧붙이면, 이 분류는 OpenRouter의 무료 모델 폴백 체인으로 돌립니다. 서버 운영비 외에 LLM 비용이 0원인 대신, 무료 쿼터(일 50 요청)와 지연이라는 다른 대가를 치릅니다. 이 트레이드오프는 마지막 장에서 정직하게 정리하겠습니다.

넷째 걸음, 서사 — 위키와 온톨로지가 만나는 곳

여기서 두 줄기가 만납니다. LLM Wiki 패턴의 가장 큰 부담은 교차 참조입니다. 새 글이 들어올 때마다 "이게 기존의 어느 페이지와 연관되는가"를 LLM이 판단해 링크를 걸어야 하는데, 페이지가 쌓일수록 이 판단은 무거워지고 없는 연결을 지어내는 환각의 여지도 생깁니다.

이 프로젝트는 그 교차 참조를 LLM에게 맡기지 않았습니다. 이미 그래프가 연결을 알고 있기 때문입니다. 기사에는 파이프라인이 붙여 준 태그가 있고, 태그마다 허브 페이지가 있어 그 태그가 등장한 모든 날짜의 페이지를 자동으로 모읍니다. 7월 10일의 일일 페이지는 "Claude" 태그 허브를 거쳐 Claude가 등장했던 6월 16일 페이지로 자연스럽게 이어집니다. 두 페이지가 직접 링크하지 않아도 같은 태그를 공유하며 허브를 경유해 연결되는 것 — 테이블 두 개가 같은 키로 조인되는 것과 같은 원리입니다. "무엇이 무엇과 연관되는가"를 LLM이 매번 판단하는 대신 단순 조회로 해결합니다.

역할 분담은 이렇게 요약됩니다. 표는 DB에서 결정론적으로, 서사만 LLM이. 그래프에서 태그와 관계라는 구조를 받고, LLM은 읽을 문장만 씁니다. 이렇게 만들어지는 위키는 세 가지 해상도를 가집니다 — 일일 페이지(오늘 무슨 일이), 주간 롤업(이번 주의 흐름), 월간 롤업(이번 달의 지각 변동). 같은 지식이 세 해상도로 접혀 올라갑니다.

시스템은 어떻게 자라는가 — 액티브 온톨로지

폐쇄형 설계에는 대가가 있습니다. 사전에 없는 "바이브 코딩" 같은 한글 신조어는 거절 풀에 묻힙니다. 이것을 메우는 것이 휴먼-인-더-루프 큐레이션이고, 원칙은 한 줄입니다. 증거는 DB에, 결정은 git에.

런타임 파이프라인은 건드리지 않습니다. 대신 거절된 후보들의 통계(빈도, 문서 수, 최근 급증 여부)를 DB에 계속 쌓아 두고, 주기적으로 사람이 추천을 받아 검토합니다. 채택한 것만 corpus 파일에 추가해 git 커밋으로 남기면, 다음 시딩부터 정식 노드가 되고 태그 허브 페이지가 생기며 다른 문서와의 관계까지 도출됩니다. LLM이 후보를 정리하고 사전 라벨을 붙여 돕지만 결정은 하지 않습니다. 온톨로지는 한 번 만들고 끝나는 산출물이 아니라, 자동화(증거 수집)와 사람(의미 판단)이 역할을 나눠 유지하는 살아 있는(active) 자산이라는 것이 이 프로젝트에서 얻은 가장 큰 교훈입니다.

실측 1 — 너무 흔하면 키워드가 아니다

여기서부터는 프로덕션 실측입니다. 기사 1,909편(2026-04-01~07-05, 약 96일, 단일 소스 GeekNews) 기준입니다. 참고로 이 수치들로 투자 판단을 하시면 안 됩니다.

먼저 배경색 이야기입니다. 전체 기사의 45.7%가 "AI"를 언급합니다(멘션 872건). 이건 트렌드가 아니라 이 대시보드의 배경색입니다. "AI 에이전트"도 25.5%입니다. 그래서 멘션이 전체 기사의 25%를 넘는 상시어는 리더보드에서 자동 제외합니다. 정보검색의 IDF(역문서빈도)와 같은 직관입니다 — 절반의 문서에 들어간 토큰은 그 문서들을 구별해 주지 못합니다. 이 필터를 켜는 순간 절대 빈도 1·2위(AI, AI 에이전트)가 통째로 사라지고, 하위권에 눌려 있던 진짜 신호(스타트업, 바이오, Gemini)가 리더보드로 올라옵니다.

실측 2 — 빈도가 아니라 가속도, 그리고 창이 곧 렌즈

트렌드 점수는 절대량이 아니라 요청 기간을 반으로 갈라 후반 합 ÷ 전반 합으로 계산합니다. 즉 "지금 가속 중인가 감속 중인가"입니다. 이 정의에서 재미있는 현상이 나옵니다. 같은 엔티티가 창(window) 길이에 따라 정반대로 읽힙니다.

절대 빈도 1위 Claude(멘션 422)는 장기 모멘텀 0.72로 식어가는 중이지만 14일 창에서는 1.50으로 급반등입니다. 빈도 리더보드만 보면 놓치는 신호를 창 반분 비율이 드러내고, 어느 창으로 보느냐 자체가 가설 설계 포인트가 됩니다. 트렌드는 단일 숫자가 아니라 다중 척도로 읽어야 합니다.

실측 3 — raw 공출현 vs NPMI: 많이 나오는 것과 특별한 것

공출현 횟수 상위 쌍은 전부 한쪽 끝이 AI인 "당연한" 쌍입니다. 둘 다 인기 있으면 무조건 커지기 때문입니다. 진짜 의미 있는 관계를 가리려면 "우연히 겹칠 기대치 대비 실제로 얼마나 자주 함께 나오나"를 재야 하고, 그것이 NPMI입니다.

0이면 독립(우연), 1에 가까울수록 강한 연관입니다. 실측으로 보면 "오픈소스—AI"는 146번이나 같은 기사에 나왔지만 NPMI는 0.01 — 사실상 독립입니다. 둘 다 워낙 흔해서 그 정도는 우연으로 설명됩니다. 반대로 "취약점—보안"은 46번밖에 안 겹쳤지만 NPMI 0.53으로 최상위입니다. 같은 그래프에 던지는 다른 질문인 셈입니다 — raw는 "무엇이 많이 같이 나오나", NPMI는 "무엇이 특별히 함께 나오나".

방향도 통계로 잡힙니다. 조건부확률의 비대칭인데, Cursor를 언급한 기사의 72%가 Claude를 함께 언급하지만 역방향은 9%에 불과합니다. "Cursor 이야기는 거의 항상 Claude 이야기지만 그 역은 아니다" — 도구가 모델에 의존하는 위계가 LLM 없이 숫자로 드러납니다. 그리고 이 통계 신호(공출현이 후보를 만들고 NPMI가 정렬)가 그대로 셋째 걸음 LLM 분류기의 입력이 됩니다. 각 단계가 다음 단계의 입력이 되는 구조입니다.

실측 4 — 기간 비교: 같은 그래프, 다른 이야기

주간 비교(최근 7일 vs 직전 7일)에서 상위 15개 중 6개(40%)가 교체됐습니다. 일주일 창을 한 칸 밀었을 뿐인데요. 직전 주는 아키텍처·라이선스·인증·취약점 같은 보안·인프라 담론이었다면, 최근 주는 Codex·GPT·CLI·프롬프트 엔지니어링이 새로 진입하고 Claude가 4위에서 1위로 반등한 코딩 에이전트 담론 재점화였습니다. 같은 주간에 위키가 자동으로 뽑은 주간 롤업 헤드라인이 "Claude와 Codex 중심의 AI 코딩·개발자 도구 생태계 확장"이었으니, 두 경로가 서로를 교차 검증한 셈입니다.

월 단위로 당기면 반대로 느린 지각 변동이 보입니다. Claude·오픈소스·API·LLM·Google·AI 코딩·GitHub 일곱 개는 4~6월 석 달 연속 top10에 머문 "주제 중력 중심"이고, CLI는 4월 4위에서 6월 top10 밖으로 밀려나는 유동을 보였습니다. 짧은 창은 빠른 회전을, 긴 창은 구조를 읽습니다.

얻은 것과 포기한 것

각 설계 결정에는 대가가 있습니다. 정직하게 정리하면 이렇습니다.

남은 한계도 네 가지 키워드로 짚어 둡니다.

• 상관이지 인과가 아닙니다: 공출현·조건부확률·NPMI는 모두 상관 신호입니다. 이 시스템이 제공하는 것은 발견이 아니라 가설 후보이고, 확인에는 별도 검증이 필요합니다.
• 무료 LLM의 품질 편차: 실측된 진짜 대가는 품질보다 쿼터와 지연이었지만, 모델이 예고 없이 폐기되는 일도 실제로 겪었습니다. 폴백 체인과 신뢰도 임계가 흡수하는 구조입니다.
• 관계 평가지표 부재: LLM이 붙인 타입 관계의 정밀도/재현율을 정량 평가하는 파이프라인이 아직 없습니다. 신뢰도 분포 모니터링과 정성 점검으로 보완 중입니다.
• 키워드 매칭의 사각지대: 표기가 같아도 맥락이 뒤집힌 쓰임(비유·반어·동명이의어)은 문자열 매칭이 잡지 못합니다.

맺으며

발표의 클로징을 그대로 옮깁니다.

거대 모델을 시스템의 중심에 두지 않고도, 명시적 온톨로지(뼈대) + 결정론 노드 파이프라인 + LLM 보조 타입드 관계 + 사람의 큐레이션이라는 겹으로 "읽을 수 있는" 트렌드 지식 그래프를 매일 자동으로 만들 수 있다. 핵심은 모델 크기가 아니라 각 층에 그 층이 잘하는 도구를 배치하고, 최종 결정은 사람에게 남기는 일이다.

정리하면 이렇습니다. 노드는 결정론(자격 규칙)으로, 엣지는 통계(공출현·NPMI)로, 의미는 닫힌 타입 집합 안의 LLM으로, 서사는 그래프가 이미 아는 연결 위에서 LLM Wiki로. 그리고 이 전부가 자라는 방법은 "증거는 DB에, 결정은 git에"라는 액티브 온톨로지 루프입니다. 이 글에서 소개한 대시보드(트렌드·그래프·기간 비교)와 위키는 모두 이 사이트에서 직접 열어 볼 수 있습니다 — 오늘도 아침 6시에 새로 자랐습니다.