블로그 목록으로 
174
회사에서 누군가 퇴사할 때, 한 번쯤은 이런 상황을 겪어보셨을 겁니다.
사실 대부분의 조직에는 노션, 컨플루언스, 프로젝트 회의록 등 퇴사자의 업무를 이어받을 만큼의 데이터가 이미 충분히 존재합니다. 문제는 정보가 여기저기 흩어져 있을 뿐 아니라, 정보와 관련된 실무자의 경험과 노하우가 함께 축적되지 않는다는 점입니다. 그 결과 문서는 남아 있지만 업무의 맥락은 온전히 이어지지 않습니다. 담당자가 퇴사하는 순간 그 맥락도 함께 사라지고, 남은 구성원들은 이미 해결했던 문제를 처음부터 다시 조사하며 같은 결론에 도달하는 악순환을 반복하게 되죠.
많은 기업이 이 문제를 해결하고자 RAG(Retrieval-Augmented Generation)를 도입했습니다. 질문하면 관련 문서를 빠르게 찾아 요약하고, 필요한 정보를 제공해 주기 때문입니다. 하지만 기존 RAG에는 치명적인 한계가 있습니다. 원하는 문서는 잘 찾아주지만, 과거에 어떤 내용을 조사했고 어떤 결론에 도달했는지는 기억하지 못합니다. 즉, 정보를 검색할 수는 있지만, 그 과정에서 얻은 지식은 시스템에 축적되지 않는 것입니다.
결국 조직의 경험은 자산으로 남지 않고, 같은 문제는 반복됩니다.
LLM Wiki 는 바로 이 한계를 해결하기 위해 등장했습니다. 그렇다면 ‘LLM Wiki v2’는 왜 필요했고, 기존 RAG와 무엇이 다를까요?
‘LLM Wiki v2’의 등장배경
LLM Wiki v2를 이해하려면 먼저 LLM Wiki가 어떻게 시작됐는지부터 살펴볼 필요가 있습니다. 그 출발점은 2026년 4월, Andrej Karpathy가 GitHub Gist를 통해 공개한 간단한 아이디어였습니다. 거창한 시스템 설계라기보다 “LLM을 이용해 지식을 어떻게 지속적으로 축적할 것인가”를 시험해 본 가벼운 프로젝트였죠. 그럼에도 반응은 폭발적이었습니다. 공개 2주 만에 GitHub에서 별(Star) 5,000개 이상과 수천 건의 포크(Fork)를 기록했고, 이를 기반으로 만든 다양한 구현체들이 전 세계에서 쏟아져 나왔습니다.
이후 커뮤니티가 이 원안을 ‘LLM 위키 v1’이라고 부르게 된 이유는 단순합니다. 매번 질문을 받을 때마다 문서를 다시 읽고 답을 생성하는 대신, LLM이 평소에 사내 문서를 미리 읽고 깔끔한 ‘노트(Wiki)’ 형태로 정리해 두게 하자는 것이죠. 원본 문서는 그대로 보존하면서, 새 정보가 들어올 때마다 AI가 기존 노트를 갱신하고 꼬인 내용을 바로잡으며 지식을 진화시키는 구조입니다.
가장 결정적인 차이는 ‘생각하는 타이밍’입니다. 기존 RAG는 질문을 받은 ‘후’에야 허겁지겁 관련 문서를 찾아 읽고 답을 고민합니다. 반면 LLM 위키는 질문을 받기 ‘전’에, 평소에 미리 모든 문서를 읽고 지식을 머릿속에 저장해 둡니다. 문제가 터진 뒤에야 서류를 뒤지는 방식에서, 평소에 완벽한 요약 노트를 만들어두고 필요할 때 꺼내 쓰는 방식으로 바뀐 것입니다.
하지만 실제 회사에서 써보니 한계가 있었습니다. 지식을 정리해 주긴 하는데, 시간이 흐르면서 변화하는 정보를 체계적으로 관리하는 기능은 부족했습니다. 예를 들어 2024년에 작성된 “이 기능은 곧 폐기될 예정”이라는 옛날 문서와 2026년의 “최신 배포 가이드”가 동시에 존재한다면, 어떤 정보를 우선해야 하는지 시스템이 스스로 판단하기 어려웠습니다. 결국 지식의 최신성이 보장되지 않다 보니, 시간이 흐를수록 시스템 전체의 신뢰도가 떨어지는 한계가 생겼습니다.
이 문제를 해결하기 위해 등장한 대안이 바로 ‘LLM 위키 v2’입니다. v2는 기존의 한계를 극복하기 위해 크게 두 가지 방향으로 진화했습니다.
- 지식 거버넌스(Governance): 단순히 지식을 쌓아두는 게 아니라, 정보마다 ‘신뢰도 점수’와 ‘유통기한’을 매깁니다. 새로운 팩트가 들어오면 과거의 지식을 깔끔하게 대체하고, 수명이 다한 옛날 정보는 자동으로 폐기합니다. 끊임없이 수정되고 갱신되는 업무 지식의 현실적 특성을 시스템에 반영한 것입니다.
- 검색 및 인프라(Search & Infrastructure): 단어 검색과 맥락 검색을 섞은 하이브리드 검색, 정보의 탄생부터 소멸까지 관리하는 시스템, 기억의 중요도에 따라 뇌의 영역을 나누는 계층형 메모리 구조 등을 도입했습니다. 단순한 ‘노트 메모장’을 넘어, 언제든 꺼내 쓸 수 있는 강력한 ‘지식 발전소’로 업그레이드한 것입니다.
그렇다면 기존 RAG와 LLM Wiki 원안(v1), 그리고 LLM Wiki v2는 실제로 무엇이 다를까요?
아래 표를 통해 핵심적인 차이를 한눈에 살펴보겠습니다.
하지만 무조건 기능을 많이 넣고 복잡하게 만드는 것만이 정답은 아니었습니다. 실제로 v2 구조를 현업에 도입해 본 기업들 사이에서는, 몇몇 기능이 오히려 시스템만 복잡하게 만들 뿐 실질적인 효과는 없었다는 피드백도 나옵니다.
이는 안드레 카파시가 처음부터 경고했던 지점이기도 합니다. 규모가 그리 크지 않은 조직이나 문서 양이 적은 곳에서는, 비용을 들여 복잡한 AI 검색(벡터 검색)을 도입하는 것보다 그냥 단순한 키워드 찾기가 훨씬 더 빠르고 정확하기 때문입니다.
결국 전 세계 커뮤니티가 수많은 실험 끝에 찾아낸 진짜 핵심은 따로 있습니다. 우리가 주목해야 할 v2는 단순히 ‘기능이 많아진 버전’이 아닙니다. 원안(V1)이 지식을 ‘어떻게 쌓을 것인가’에 집중했다면, v2는 그 쌓인 지식을 실무에서 ‘어떻게 잘 굴릴 것인가’까지 고민을 확장한 개념입니다.
검색에서 이해로, 그리고 추론까지
LLM 위키 V2를 관통하는 핵심은 ‘이해’와 ‘추론’입니다. 단순 검색을 넘어, 질문의 맥락을 파악하고 답을 도출하는 구조로 바뀌기 때문입니다.
기존 RAG는 질문을 받으면 그때야 유사한 문서를 찾아 답변을 만듭니다. 유연하긴 하지만 매번 답변의 품질이 달라지고, 검색할 때마다 비용이 반복해서 발생한다는 단점이 있습니다.
반면 LLM 위키 V2는 이미 사내 문서를 읽고 개념과 관계를 모두 정리해 둔 상태입니다. 따라서 질문이 들어왔을 때 데이터를 새로 ‘찾는’ 것이 아니라, 이미 만들어진 ‘지식 지도’를 그대로 활용합니다.
앞서 언급한 클라우드 비용 급증 상황을 예로 들어보겠습니다. 기존 시스템은 질문을 받은 뒤에야 비용 리포트, 로그, 배포 기록을 새로 수집하고 관계를 짜 맞추어야 합니다. 반면 LLM 위키 V2는 이미 이를 ‘비용 증가 이벤트’라는 하나의 개념으로 묶고, 그 아래에 [원인·영향·대응]이라는 구조로 미리 정리해 둡니다.
이 상태에서 질문을 던지면, 시스템은 단편적인 문서 요약을 넘어 이미 짜인 구조를 바탕으로 전후 상황을 논리적으로 설명합니다. 필요하다면 이전의 유사 사례까지 연결해 주기도 하죠. 단순한 단답형 ‘답변’이 아니라, 맥락이 있는 ‘설명’이 나오는 이유입니다.
결국 LLM 위키 V2는 정보를 단순히 찾아주는 검색 엔진에서, 지식을 이해하고 추론하여 제공하는 지능형 시스템으로의 진화를 뜻합니다.
3개의 레이어로 작동하는 시스템 구조
LLM 위키 V2의 핵심은 기능의 종류가 아니라 명확한 ‘역할 분리’에 있습니다. 시스템의 책임을 세 가지 계층(레이어)으로 깨끗하게 나누어 관리하는 구조입니다.
- 사실 계층 (Fact Layer): 로그, 리포트, 회의록 등 변하지 않는 원본 데이터를 사실 그대로 보존합니다. 이 바닥이 단단해야 전체 시스템이 신뢰를 얻습니다.
- 지식 계층 (Knowledge Layer): AI가 개입해 데이터에서 개념을 뽑아내고, 관계를 엮고, 충돌하는 정보를 수정합니다. v1이 단순한 ‘요약 노트’였다면, v2의 지식 계층은 실시간으로 ‘업데이트되는 백과사전’에 가깝습니다.
- 추론 계층 (Reasoning Layer): 사용자의 질문을 분석해 어떤 지식이 필요한지 판단하고, 이를 조합해 논리적인 설명을 만들어냅니다.
이 세 구조가 맞물리면 데이터는 온전히 보존되고, 지식은 끊임없이 정제되며, 답변의 품질은 계속해서 좋아집니다.
이 구조가 자리 잡으면 직원의 업무 방식도 완전히 바뀝니다. 더 이상 필요한 문서를 찾기 위해 시간을 허비하는 게 아니라, 잘 차려진 지식을 곧바로 업무에 활용하는 사람이 됩니다. 매번 처음부터 다시 분석해야 했던 문제들을, 이제는 쌓여 있는 지식을 바탕으로 단번에 해결할 수 있게 됩니다.
‘그 사람 없으면 안 돌아가는’ 조직을 구하는 법
이 구조가 중요한 진짜 이유는 기술적 우수성 때문만은 아닙니다. 조직이 겪는 가장 고질적인 문제를 해결해 주기 때문입니다.
대부분의 조직은 규모가 커질수록 정보가 사방에 흩어집니다. 결국 “그거 아는 사람 누구지?” 하며 특정 전문가에게만 의존하는 병목 현상이 발생하죠. 이 상태에서 가장 낭비되는 것은 다름 아닌 ‘의사결정 비용’입니다. 이미 내렸던 결론을 다시 도출하느라 똑같은 조사를 반복하고 시간을 허비하기 때문입니다.
LLM Wiki v2는 이 문제를 뿌리부터 바꾸는 세 가지 변화를 만들어냅니다.
- 첫째, 지식이 자산으로 누적됩니다. 기존 시스템에서는 아무리 좋은 답변을 만들어도 일회성으로 사라지지만, V2에서는 그 답변이 다시 지식 계층으로 흡수됩니다. 시간이 흐를수록 시스템이 더 똑똑해지는 구조입니다.
- 둘째, 정보의 모순을 잡아냅니다. 서로 다른 문서 사이에 존재하던 충돌과 왜곡이 구조적으로 드러나기 때문에, 철 지난 정보로 인한 판단 오류를 미리 막을 수 있습니다.
- 셋째, 조직의 ‘지워지지 않는 기억’이 됩니다. 특정 개인의 머릿속에만 있던 노하우가 시스템에 자산으로 남습니다. 사람이 바뀌어도 조직의 역량은 안정적으로 유지됩니다.
결과적으로 조직은 “그 일을 누가 알고 있는가”를 찾는 구조에서, “시스템이 무엇을 알고 있는가”를 활용하는 구조로 체질이 바뀝니다.
이 변화는 단순히 업무 효율을 높이는 데 그치지 않습니다. 남들이 사람을 찾고 서류를 뒤지는 동안, 정확한 데이터를 바탕으로 단번에 의사결정을 내리게 만듭니다. 속도와 정확도의 차이, 시장에서 치고 나가는 격차는 바로 이 지점에서 벌어집니다.
Wiki를 넘어, 스스로 일하는 Agent로
LLM Wiki V2를 지식 시스템으로만 보면 절반만 이해한 것입니다. 실제로 중요한 것은 그 이후의 방향입니다.
지식이 충분히 축적되고 구조적으로 관리되기 시작하면, 다음 단계는 자연스럽게 이어집니다. 지식을 활용한 판단, 그리고 그 판단을 기반으로 한 실행입니다.
예를 들어, 특정 비용 패턴이 비정상적으로 나타났을 때 시스템이 이를 감지하고, 과거 유사 사례를 기반으로 원인을 추정하며, 대응 방안을 제안하는 것까지는 현재 구조에서도 가능합니다. 여기서 한 걸음 더 나아가면, 실제로 조치를 취하는 단계까지 연결될 수 있습니다.
이 시점에서 시스템은 단순한 Wiki가 아니라 하나의 agent로 동작하기 시작합니다. 상황을 인식하고, 목표를 설정하고, 필요한 정보를 선택하고, 결과를 만들어내며, 그 결과를 다시 학습합니다.
중요한 것은 이 모든 과정이 하나의 루프를 형성한다는 점입니다. 이 루프가 안정적으로 작동하기 시작하면, 시스템은 더 이상 정적인 도구가 아니라 스스로 개선되는 구조를 가지게 됩니다.
결국 우리가 지금 고민하고 구축하고 있는 것은 단순한 문서 저장소로서의 Wiki가 아닙니다. 어쩌면 우리는 단순한 Wiki를 넘어, 조직의 축적된 경험을 가장 효율적으로 활용하는 ‘집단 지성 인프라’를 구축하고 있는 것일지도 모릅니다.
