요즘 팀에서 AI를 붙여도 생산성이 생각만큼 안 오르는 경우가 많습니다.
코드는 빨리 나오는데, 결과가 들쑥날쑥하고, 같은 조사/정리를 계속 반복하고, 새로 온 사람이 맥락을 못 따라가서 다시 처음부터 설명하는 일이 계속 생깁니다.
문제는 모델 성능이 아니라 운영 방식일 때가 많습니다.
이 글은 그 문제를 푸는 방법으로 LLM Knowledge Base를 설명합니다.
핵심 메시지는 간단합니다.
많은 팀의 실제 흐름은 이렇습니다.
다음 주에 비슷한 이슈가 다시 오면? 또 1)로 돌아갑니다.
이 흐름의 문제는 크게 세 가지입니다.
좋은 답변이 생겨도 채팅 로그에 묻힙니다. 결국 팀의 공용 자산이 되지 못합니다.
새 사람에게 배경을 설명하는 데 시간이 많이 듭니다. 문서가 있어도 흩어져 있으면 실질적으로는 없는 것과 비슷합니다.
그날그날 LLM에 넣는 문서가 다르고 질문 방식이 다르니 결과도 흔들립니다.
즉, 코드 생성 속도는 빨라졌는데 맥락 관리 속도가 못 따라오는 상태입니다.
핵심은 "질문할 때만 검색"하는 구조를 "평소에 정리해두는 구조"로 바꾸는 겁니다.
kb/
raw/ # 원문(기사, 회의록, PR, RFC, 리포트)
wiki/ # LLM이 유지하는 md 지식 문서
index.md # 전체 지도
log.md # 변경 이력
여기서 중요한 건 사람이 위키 문서를 직접 다 쓰지 않는다는 점입니다. 사람은 방향을 잡고, LLM은 반복 정리 작업을 담당합니다.
Software 3.0을 어렵게 말할 필요 없습니다.
그럼 생산성 병목도 바뀝니다.
여기서 LLM KB가 맞는 이유는 명확합니다.
결국 팀이 매번 같은 고민을 반복하지 않게 됩니다.
예시: 결제 장애가 월 2~3회 나는 SaaS 팀
기존 방식
LLM KB 적용 후
체감 변화
이건 모델이 갑자기 천재가 돼서가 아니라, 팀 지식이 검색 가능한 구조로 정리되었기 때문입니다.
복잡하게 시작할 필요 없습니다. 이 세 루프만 지키면 됩니다.
새 소스를 넣으면 LLM이
질문이 들어오면
주 1회라도
이 루프를 놓치면 지식베이스는 금방 썩습니다. 반대로 이 루프만 돌면 문서 품질이 계속 올라갑니다.
벡터DB, 에이전트, 대시보드부터 다 올리면 유지 못 합니다. 처음엔 markdown + index + log면 충분합니다.
"좋은 답변이면 나중에 정리하자"는 거의 실패합니다. 파일링은 규칙으로 강제해야 합니다.
원문(raw)을 수정하기 시작하면 추적이 깨집니다. raw는 불변, wiki는 가변으로 분리해야 합니다.
한 달만 지나도 문서 충돌/중복/낡은 정보가 쌓입니다. lint 없는 위키는 오래 못 갑니다.
raw, wiki, index.md, log.md)2주만 해도 "문서가 살아있다"는 느낌을 받을 수 있습니다.
AI 시대에 코드 생성 속도만으로는 팀 생산성이 결정되지 않습니다. 실제로 병목이 되는 건 팀 컨텍스트와 지식 정리입니다.
LLM Knowledge Base는 이 병목을 직접 겨냥합니다.
한 줄로 정리하면 이겁니다.
LLM을 '답을 주는 도구'로만 쓰지 말고, '팀 지식을 운영하는 시스템'으로 써야 합니다.
다음 글에서는 이 구조를 Obsidian 기준으로 실제 파일/프롬프트/운영 규칙까지 더 구체적으로 풀어보겠습니다.