흩어진 사내 지식을 LLM Wiki로 묶다

회사의 지식은 메일에, 엑셀에, 누군가의 폴더에, 그리고 가장 많게는 사람의 머릿속에 흩어져 있습니다. 필요한 순간 그걸 찾지 못하면, 같은 고민을 매번 처음부터 다시 합니다. 지식이 새지 않게 한곳에 모으고, 그 위에 AI가 답하게 만드는 일을 시작했습니다. 이 글은 “AI 지식 시스템의 8할은 똑똑한 AI가 아니라 먼저 모으는 일”이라는, 다소 김빠지지만 결정적인 이야기입니다.

지식이 새는 회사 — 거의 모두가 앓는 병

제조업에서 정말 비싼 자산은 설비가 아니라 “왜 그렇게 했는지”의 기록입니다. 이 셀을 왜 이 공급사에서 받기로 했는지, 저 인증이 왜 그렇게 까다로웠는지, 작년에 그 불량을 어떻게 잡았는지 — 이런 맥락은 대부분 문서로 남지 않습니다. 회의에서 말로 오가고, 결정한 사람의 기억에만 남습니다.

그 사람이 바쁘면 회사가 멈추고, 떠나면 지식이 사라집니다. 새 직원은 “예전에 누가 정리해 둔 게 있을 텐데”를 찾다 못 찾고 같은 시행착오를 반복합니다. 이건 한 회사만의 문제가 아니라, 거의 모든 회사가 조용히 앓는 병입니다.

지식이 사는 곳	문제	결과
사람 머릿속	그 사람만 안다	바쁘면 병목, 떠나면 소멸
개인 메일·폴더	남이 못 찾는다	”있는데 닿을 수 없음”
흩어진 엑셀	맥락이 빠져 있다	”왜 그랬는지”가 사라짐
한곳 + AI 검색	필요할 때 닿는다	시스템에 노하우 축적

함정: “검색 안 되는 지식”은 없는 지식이다

지식이 어딘가에 분명히 있어도, 필요한 순간 못 찾으면 그건 없는 것과 같습니다. 폴더 깊숙이 잠든 문서, 누군가의 메일함에만 있는 결정, 머릿속에만 있는 노하우 — 모두 “있지만 닿을 수 없는” 지식입니다. 그래서 지식 관리의 첫 목표는 “더 많이 쓰자”가 아니라 **“필요할 때 닿게 하자”**여야 합니다.

먼저 한곳에 모은다 — Obsidian과 마크다운

출발점은 단순합니다. 흩어진 문서를 일단 한곳에 모으는 것. 그래서 Obsidian 같은 마크다운 기반 지식 저장소를 택했습니다.

용어: 마크다운(Markdown)

# 제목, - 목록처럼 특수 기호 몇 개로 서식을 표현하는 평범한 텍스트 형식입니다. 워드나 한글 같은 전용 프로그램 없이도 메모장으로 열립니다. 단순한 만큼 어떤 도구에도 갇히지 않습니다.

용어: Obsidian

마크다운 문서들을 서로 링크로 엮어 “내 머릿속 지식 지도”처럼 관리하는 도구입니다. 문서 A가 문서 B를 가리키면 자동으로 연결선이 생겨, 흩어진 메모들이 그물망(네트워크)을 이룹니다.

왜 화려한 위키 솔루션 대신 “평범한 텍스트 + 링크”를 택했을까요. 지식 저장소의 수명은 그 포맷의 단순함에 비례하기 때문입니다.

왜 마크다운인가 — 두 가지 이유

① 오래갑니다. 독점 포맷에 넣은 지식은 그 도구가 사라지면 같이 사라집니다. 평범한 텍스트(마크다운)는 10년 뒤에도, 어떤 프로그램으로도 열립니다.

② AI가 읽기 좋습니다. 텍스트라서 AI가 그대로 읽고, 색인하고, 답할 수 있습니다. 모으는 단계에서 이미 “나중에 AI가 쓸 것”을 염두에 둔 셈입니다. 즉 마크다운 선택은 보관 방식이자, AI 시대의 준비였습니다.

그 위에 LLM이 답하게 — 자동 Wiki

모으기만 해서는 부족합니다. 폴더 가득한 문서는 안 찾으면 없는 것과 같습니다. 그래서 다음 단계는, 모인 문서를 AI가 읽고 지식 그래프로 구조화한 뒤, 사람이 자연어로 물으면 근거 문서를 찾아 답하게 만드는 것입니다.

용어: RAG (검색 증강 생성)

AI가 답하기 전에 먼저 관련 문서를 찾아 읽고, 그 내용을 근거로 답하는 방식입니다. “아는 척 지어내기”가 아니라 “찾아보고 답하기”입니다. 그래서 출처를 함께 보여 줄 수 있고, 근거 없는 환각이 줄어듭니다.

그림으로 보면 흐름은 이렇습니다. “작년 그 불량 어떻게 처리했지?”라고 물으면, 시스템이 흩어진 회의록·이슈 기록 중 관련된 것을 찾아, 묶어서 답하고, 출처를 보여 줍니다.

흩어진 지식(①)을 평범한 텍스트로 한곳에 모으고(②), AI가 지식 그래프로 구조화한 뒤(③), 자연어 질문에 근거 문서와 함께 답합니다. 핵심은 "출처를 보여 준다"는 것 — 그래야 답을 믿을 수 있습니다.

흥미로운 점이 있습니다. 이 프로젝트 자체도 코드와 문서를 지식 그래프로 변환하는 도구(graphify)를 개발 내내 써 왔습니다. 문서를 노드와 연결로 만들고, AI가 필요한 부분만 조회하게 하는 방식입니다. 즉, 우리가 우리 개발 과정에서 이미 효과를 본 발상을, 사내 지식 전반으로 넓히는 것이 이 LLM Wiki의 방향입니다. 1인 개발로 진행 중이라 전사 도입까지는 갈 길이 있지만, “지식을 모으고 → 구조화하고 → AI가 답하게”라는 골격은 분명합니다.

모으기 → 답하기, 실제로 이렇게 흘러간다

1. 모은다 — 흩어진 회의록·결정 기록·노하우를 마크다운으로 한곳에 옮깁니다. 가장 지루하지만 가장 중요한 단계입니다.
2. 엮는다 — 문서끼리 링크로 잇습니다. “이 불량 이슈”가 “그때 공급사 결정”을 가리키게 합니다. 흩어진 메모가 그물망이 됩니다.
3. 구조화한다 — AI가 이 그물망을 읽어 지식 그래프(노드와 연결)로 만듭니다.
4. 묻는다 — 사람이 자연어로 “작년 그 불량 어떻게 처리했지?”라고 묻습니다.
5. 근거와 함께 답한다 — AI가 관련 문서를 찾아 묶어 답하고, 출처를 보여 줍니다(RAG). 사람은 출처를 보고 답을 믿을지 판단합니다.

핵심은 1·2단계가 4·5단계의 전제라는 것입니다. 모으고 엮는 지루한 단계를 건너뛰면, 아무리 좋은 AI도 답할 거리가 없습니다. 화려한 마지막 단계는 늘 지루한 첫 단계 위에서만 동작합니다.

이 모든 게 노리는 한 가지

왜 이렇게까지 지식을 모으고 구조화할까요. 단지 검색을 편하게 하려는 게 아닙니다. 더 큰 목표가 있습니다 — 회사의 노하우가 사람이 아니라 시스템에 쌓이게 만드는 것입니다.

지식이 사람 머릿속에만 있으면, 그 사람의 퇴사·휴가·인수인계가 곧 회사의 리스크가 됩니다. 하지만 지식이 시스템에 쌓이고 AI가 그걸 풀어 준다면, 누가 떠나도 회사는 잊지 않습니다. 이건 이 프로젝트 전체가 지향하는 방향과 같습니다 — 회사의 전문성이 사람이 아니라 시스템에 축적되는 구조입니다.

교훈

AI 지식 시스템의 8할은 **“먼저 모으는 것”**입니다. 아무리 좋은 LLM도 흩어진 지식은 읽을 수 없습니다. 그러니 순서는 ① 평범하고 오래가는 포맷(마크다운)으로 한곳에 모으고, ② 그 위에 AI 검색·요약(RAG)을 얹습니다. 화려한 AI 기능부터 욕심내면, 정작 읽을 지식이 흩어진 채로 남습니다. 그리고 이 모든 건 결국 한 가지를 노립니다 — 회사의 노하우가 사람이 아니라 시스템에 쌓이게 만드는 것. 그래야 누가 떠나도 회사가 잊지 않습니다.

---

이 글은 SL.AIMS를 만들며 겪은 현장 회고 중 하나입니다. 전체 그림은 〈사례연구: SL.AIMS〉에, 지식 그래프로 코드를 다루는 같은 발상은 〈graphify·Serena를 너무 늦게 도입한 것〉에 있습니다.