LLM Knowledge Base를 도입해도 성과가 안 나는 팀이 있습니다.
대부분 원인은 같습니다.
질문이 너무 넓고, 결과를 파일로 남기지 않고, 검증 질문이 없습니다.
이 글에서는 위키 품질을 실제로 끌어올리는 운영 질문 12개를 정리합니다.
1. 질문이 넓으면 답도 흐려진다
예를 들어 이런 질문은 결과가 약합니다.
반면 아래처럼 질문하면 결과가 바로 실행 가능합니다.
- “지난 60일 결제 실패 로그 기준으로,
실패 원인 TOP3를 정리하고,
각 원인별 재시도 정책(횟수/간격/중단 조건)을 표로 제안해.
제안은 우리 현재 아키텍처 제약 3개를 반영해.”
질문의 단위가 작고 구체적일수록 문서 품질이 올라갑니다.
2. 운영 질문 12개 (바로 복붙 가능)
A. 사실 정리 질문
- “이 주제에서 현재 위키가 확정적으로 말할 수 있는 사실 10개만 뽑아줘.”
- “사실이지만 근거 링크가 없는 문장만 찾아줘.”
- “같은 사실이 중복으로 반복되는 페이지를 묶어줘.”
B. 모순 점검 질문
- “서로 충돌하는 주장 5개를 찾아서 충돌 이유를 적어줘.”
- “최신 문서 기준으로 폐기된 결론이 남아있는 페이지를 표시해줘.”
- “숫자(비율/기간/비용)가 페이지마다 다르게 적힌 항목을 모아줘.”
C. 실행 전환 질문
- “지금 상태에서 2주 내 실행 가능한 액션 5개로 변환해줘.”
- “각 액션에 담당 역할(백엔드/프론트/PM/CS)을 붙여줘.”
- “리스크가 큰 순서대로 재정렬해줘.”
D. 누락 보완 질문
- “자주 언급되는데 독립 페이지가 없는 개념을 찾아줘.”
- “최근 한 달 로그 기준으로 업데이트가 필요한 페이지를 뽑아줘.”
- “다음 주에 추가로 수집할 소스 10개를 우선순위로 제안해줘.”
이 12개만 매주 돌려도 위키 품질이 확 달라집니다.
3. 질문 후 반드시 해야 할 후처리
좋은 질문보다 더 중요한 건 후처리입니다.
- 결과를
outputs/에 저장
- 재사용 가치 있으면
wiki/로 승격
- index/log 갱신
- 다음 질문 후보 3개 기록
여기서 끊기면 KB는 단순 Q&A 기록이 됩니다.
이걸 끝까지 하면 KB는 학습 시스템이 됩니다.
4. "그럴듯한 말"을 줄이는 검증 규칙
아래 문장이 나오면 경고 신호입니다.
- “일반적으로 볼 때…”
- “보통은…”
- “업계에서는…”
이런 표현이 나오면 바로 다시 묻습니다.
- “근거 문서 링크를 붙여줘.”
- “숫자로 바꿔서 말해줘.”
- “우리 시스템 제약 기준으로 다시 써줘.”
검증 질문이 없으면 KB는 금방 추상화됩니다.
5. 팀에 적용하는 최소 운영안
- 월/수/금: ingest
- 화: query + 결과 파일링
- 목: lint
- 금: 주간 결론 페이지 1개 생성
그리고 금요일 결론 페이지는 반드시 이 4개 섹션을 넣습니다.
- 이번 주 확정 사실
- 미해결 쟁점
- 다음 주 실험
- 의사결정 필요 항목
이 문서 하나가 다음 주의 출발점이 됩니다.
결론
LLM Knowledge Base에서 성과를 가르는 건 모델이 아니라 질문 운영입니다.
- 질문을 작고 구체적으로 만들고
- 검증 질문으로 추상을 제거하고
- 결과를 문서로 고정하면
지식이 누적되고 팀 실행 속도가 올라갑니다.
오늘 바로 할 수 있는 건 간단합니다.
위 12개 질문 중 3개만 골라서 지금 위키에 돌려보세요.
그 결과가 현재 KB의 수준을 가장 정확하게 보여줍니다.
