대화 전체 저장을 포기하고 LLM Wiki를 만든 이유

배경

처음에는 Slack 대화를 모두 저장하면 팀의 지식이 될 거라고 생각했습니다. 결과는 반대였습니다. 검색 결과만 늘고 중요한 결정은 더 찾기 어려워졌습니다. 그래서 허용된 대화를 정제한 뒤 재사용할 내용만 선별하는 LLM Wiki를 구축했습니다.

문제는 대화량 자체가 아니었습니다. 최종 결정, 실제 실행 결과, 장애 해결법과 산출물이 인사말과 진행 메시지 사이에 묻히는 것이 문제였습니다.

첫 시도는 대화 전체를 문서로 저장하는 방식이었습니다. 그러나 저장량이 늘수록 검색 결과도 흐려졌습니다. 반복 지시와 실패한 중간 과정이 섞였고, credential 형식이나 내부 정보가 남을 위험도 있었습니다.

그래서 목표를 '모두 저장하기’에서 '다시 쓸 수 있는 내용만 근거와 함께 남기기’로 바꿨습니다. 원문 보관과 지식 관리를 분리하고, 알려진 credential 패턴의 마스킹과 중복 검사를 LLM보다 먼저 실행하도록 설계했습니다.

별도의 노코드 툴은 사용하지 않았습니다.

Slack 전체를 읽지 않습니다. Hermes가 실제로 받은 DM, 멘션과 허용된 채널의 신규 수신 이벤트만 후보로 가져옵니다. 수집된 본문은 새 시스템 명령이 아니라 비신뢰 데이터로 취급합니다.

출처와 역할을 확인하고, 정의된 규칙으로 token, cookie, URL 인증정보와 개인키 형태를 마스킹합니다. 등록되지 않은 출처나 event ID 충돌이 발생하면 처리하지 않고 완료 위치도 전진시키지 않습니다.

이 필터는 모든 민감정보 탐지를 보장하지 않습니다. 개인정보와 프로젝트 기밀은 별도의 허용 정책과 사람의 공개 전 검토가 필요합니다.

서로 다른 메시지를 출처, 시각, 역할, 본문과 프로젝트 문맥을 가진 공통 형식으로 변환했습니다. 본문 hash는 익명화가 아니라 무결성과 중복 검사용으로만 사용합니다. 정제된 이벤트와 처리 상태는 Wiki 문서와 분리해 보관합니다.

예약 작업이 15분마다 신규 수신 이벤트를 확인합니다. LLM은 확정된 요구사항, 실행 근거가 있는 결과, 재사용 가능한 해결법과 주요 산출물만 기존 Wiki 문서에 통합합니다. 인사, 반복 지시, 임시 진행 상태와 확인되지 않은 완료 주장은 제외합니다.

15분은 실시간 처리 보장이 아니라 예약 실행 간격입니다.

필수 메타데이터, 색인 등록, 내부 링크와 페이지 수를 검사합니다. 검사에 실패하면 해당 batch를 완료 처리하지 않습니다. 문서를 작성했다는 사실보다 다시 열었을 때 구조와 근거가 유지되는지를 완료 조건으로 삼았습니다.

Nevermind는 이 파이프라인의 자동 출력이 아닙니다. Hermes가 프로젝트 범위를 명시하고 필요할 때 검색하거나 장기 기억을 기록하는 별도 MCP 경로입니다. LLM Wiki와 Nevermind는 자동으로 서로 복제하지 않습니다.

2026년 10월 3일 내부 운영 환경을 다시 검사했습니다.

이 수치는 제품 성능이나 생산성 향상을 입증하는 벤치마크가 아닙니다. 특정 시점에 내부 파이프라인이 정해 둔 완료 조건을 충족했는지 보여주는 운영 스냅샷입니다. 첨부파일, 미등록 credential 형식과 자연어로 적힌 민감정보가 모두 탐지된다는 뜻도 아닙니다.

가장 큰 변화는 저장량보다 완료 기준에서 나왔습니다. 메시지를 파일에 썼다고 끝내지 않고, 허용 범위 확인, 알려진 credential 패턴의 마스킹, 중복 검사와 문서 구조 검증을 통과해야 지식으로 남았다고 판단했습니다.

아직 Wiki와 의미기억 사이의 자동 양방향 동기화는 구현하지 않았습니다. 다음 단계는 무조건 복제하는 방식보다, Wiki에서 사람이 검토한 규칙만 의미기억으로 승격하는 승인형 흐름입니다.