QA 봇이 너무 느렸다 — 위키 구조 재편과 검색 인덱스

지난 글에서 만든 QA 봇은 동작은 했지만 느렸습니다. 그리고 가끔은 컨텍스트 한계를 넘겨 아예 답을 못 했습니다. 이 시리즈의 마지막 글은, 그 느림의 진짜 이유를 파고들어 구조를 갈아엎은 기록입니다.

느림의 진짜 이유

처음엔 "모델이 느린가" 싶었습니다. 하지만 뜯어 보니 원인은 모델이 아니라 우리 쪽이었습니다.

봇은 질문을 받으면 "관련 있어 보이는" 문서를 잔뜩 긁어 모델에 밀어 넣었습니다. 어디에 뭐가 있는지 몰라서, 일단 많이 넣고 보자는 식이었죠. 그러니 입력이 비대해지고, 생성은 느려지고, 심하면 12만 8천 토큰 한계를 넘겼습니다.

즉 문제는 "어디서 무엇을 찾을지"가 없다는 것이었습니다. 이건 모델을 바꿔서 풀 문제가 아니라, 위키 구조와 검색의 문제였습니다.

index.md를 '지도'로 재편

가장 먼저 손댄 건 index.md였습니다. 원래는 전체 문서를 다 나열하려다 보니 파일 자체가 너무 커져서, 오히려 길잡이 역할을 못 하고 있었습니다.

그래서 index를 전체 목록이 아니라 지도로 바꿨습니다. 1차 깊이만 연결해 주는 얇은 진입점으로요.

wiki/
├── index.md          # 1차 깊이 지도 (얇게)
├── timeline.md       # 최근순 타임라인
├── confluence/
└── jira/
    └── assignees/    # 담당자별 정리

index.md는 "confluence는 여기, jira는 여기, 담당자별은 여기" 정도만 가리킵니다. 상세는 각 하위 문서가 갖습니다. 봇은 지도를 먼저 읽고 필요한 가지로만 내려가면 됩니다. 쓰지 않게 된 허브 페이지(예: 작성자별 허브)는 과감히 걷어냈습니다 — 메타데이터는 남기되, 길만 단순하게요.

시스템 프롬프트를 조이고 도구를 줄이다

구조를 바꾼 만큼, 봇에게 "이렇게 찾아라" 를 명확히 알려줘야 했습니다. chat.md 시스템 프롬프트를 조였습니다.

• 먼저 index.md를 읽고 어디를 볼지 정한다
• 관련 가지만 열어 본다
• 위키에 근거가 없으면 지어내지 말고 "없다"고 답한다

동시에 봇이 쓸 수 있는 도구 범위도 줄였습니다. 선택지가 많으면 모델이 헤매고, 헤매면 느려집니다. 할 수 있는 걸 좁히니 오히려 경로가 또렷해졌습니다.

역색인: 그래프와는 다른 물건

그래도 "질문에 맞는 문서 찾기"는 여전히 필요했습니다. 여기서 역색인(inverted index) 을 붙였습니다.

역색인은 검색 엔진의 기본 자료구조입니다. "문서 → 단어"가 아니라 "단어 → 그 단어가 든 문서들" 로 뒤집어 둔 표죠. 이러면 질문에 나온 단어로 후보 문서를 즉시 좁힐 수 있습니다. 문서를 전부 훑지 않아도 되니 빠릅니다.

_graph.json   # 문서 간 연결 관계 (누가 무엇과 이어지나)
_search.json   # 역색인 (단어 → 문서들)  ← 이번에 추가

이미 있던 _graph.json(문서 연결 그래프)과는 역할이 다릅니다. 그래프는 "관계"를, 역색인은 "검색"을 담당합니다. 둘을 헷갈리지 않게 파일도 이름도 나눴습니다. 이 인덱스들은 위키가 갱신될 때 함께 빌드됩니다.

이제 봇은: 역색인으로 후보를 좁히고 → 지도로 맥락을 잡고 → 필요한 문서만 모델에 넘깁니다. 입력이 가벼워지니 컨텍스트 한계도 넘지 않고, 답변도 빨라졌습니다.

관측 로그로 확인하기

3편에서 배운 교훈이 여기서도 유효했습니다 — 보이지 않으면 못 고친다.

QA 봇이 한 턴을 처리하는 동안 어떤 문서를 골랐는지, 입력이 몇 토큰이었는지, 각 단계가 얼마나 걸렸는지를 로그로 드러냈습니다. 그러자 "어디서 시간이 새는지"가 눈에 보였고, 개선의 효과도 숫자로 확인할 수 있었습니다.

회고

• 느림의 원인은 모델이 아니라 "어디서 뭘 찾을지" 부재였다.
• index.md는 전체 목록이 아니라 지도여야 한다.
• 시스템 프롬프트를 조이고 도구를 줄이면 경로가 또렷해진다.
• 역색인(검색)과 그래프(관계)는 다른 물건이다.
• 관측 로그 없이는 최적화도 없다.

여기까지가 사내 지식을 LLM 위키로 만든 여정입니다. 흩어진 Jira·Confluence를(1편) 원문 그대로 모아(2편), 여러 모델로 빠르게 요약하고(3편), 그 위에 스크럼봇(4편)과 QA 봇(5편)을 얹고, 마지막으로 빠르게 다듬었습니다.

지식이 "쌓여만 있는" 상태에서 "물어보면 답하는" 상태로 옮겨 가는 일 — 결국 가장 중요한 건 화려한 모델이 아니라, 찾을 수 있게 정리하는 구조였습니다.