업무용 AI 비서의 탄생 (2편) — 기억을 입히는 이중 인덱싱

TL;DR

• 문제: 1편의 비서는 질문마다 백지에서 도구를 긁어, 과거 맥락이 전혀 쌓이지 않았습니다.
• 기억: 내 질문과 검색어를 마크다운으로 쌓고, 로컬 SQLite 벡터 저장소에 증분 인덱싱했습니다.
• 검색: 뜻으로 찾는 의미 기반 검색과 키워드로 찾는 단어 기반 검색을 하이브리드로 묶었습니다.
• 인사이트: 흩어진 조각 기록을 도메인별로 의미 군집해, 묶이기 전엔 안 보이던 패턴을 뽑아냅니다.
• 효과: 프롬프트에 과거 맥락과 인사이트가 얹히면서, 예전에 혼자 1인분 하던 일을 3~4배로 해냅니다.

이전 편 요약

1편 - 도구를 한 에이전트에 엮기에서는, 이슈 트래커·사내 위키·모니터링·운영 DB를 사람이 손으로 오가던 자료 수집을, 네 도구를 MCP로 한 비서에 물려 LLM이 직접 모으게 바꾼 이야기를 다뤘습니다. 자료를 줍는 노동이 사람에서 비서로 넘어간 게 1편의 핵심입니다.

이번 편은 그 비서의 약점 하나에서 출발합니다.

비서가 매번 백지에서 시작하는 게 아쉬웠다

1편의 비서는 빨랐지만, 질문이 끝나면 방금 한 일을 깨끗이 잊었습니다. 매번 백지에서 네 도구를 긁으니, “저번에 비슷한 이슈를 봤는데” 하는 맥락이 도무지 쌓이질 않았습니다.

사람은 같은 이슈를 두 번째 보면 첫 번째보다 빠릅니다. 어디를 봐야 하는지, 전에 뭐가 원인이었는지 기억하기 때문입니다. 비서에게는 그 기억이 없었습니다. 그래서 두 번째로 한 일이 비서에게 기억을 붙이는 것이었습니다.

질문을 기록으로, 기록을 검색 가능한 기억으로

먼저 제가 비서에게 던진 질문과 검색어들을 마크다운 파일로 차곡차곡 남겼습니다. 거창한 DB가 아니라, 그냥 텍스트 기록입니다.

그리고 이 마크다운을 로컬 SQLite에 벡터 검색을 얹은 저장소에 증분 인덱싱했습니다. 벡터 저장소는 문장을 좌표(숫자 묶음)로 바꿔서, 뜻이 비슷한 기록끼리 가깝게 모아두는 저장소입니다. 증분 인덱싱은 매번 전부 다시 넣지 않고 “새로 생긴 것만 골라 넣는” 방식입니다. 전체를 매번 다시 색인하면 느리고 비싸니까, 바뀐 부분만 얹는 것입니다.

이렇게 하니 비서가 과거의 내 질문과 그때 좁혀둔 원인을 다시 꺼내 볼 수 있게 됐습니다.

의미로도 찾고, 단어로도 찾는다

기억을 꺼내는 검색을 한 가지로만 하지 않았습니다. 두 방식을 겹쳤습니다.

• 의미 기반 검색: 단어가 안 겹쳐도 뜻이 비슷하면 찾아줍니다. “정산이 안 맞는다”로 물어도 예전 “결제 금액 불일치” 기록을 끌어옵니다.
• 단어 기반 검색: 특정 키워드(에러 코드, 테이블 이름)가 정확히 들어간 기록을 놓치지 않습니다.

한쪽만 쓰면 구멍이 납니다. 의미 검색만 쓰면 정확한 식별자를 흘리고, 단어 검색만 쓰면 표현이 조금만 달라도 못 찾습니다. 둘을 합친 하이브리드로 그 빈틈을 메웠습니다. 뜻도 맞고 키워드도 맞는 기록을 같이 보는 것입니다.

무의미한 조각에서 인사이트를 캐다

여기서 한 단계 더 갔습니다.

벡터 저장소에는 그 자체로는 의미 없어 보이는 조각 기록이 잔뜩 쌓입니다. 질문 하나, 검색어 하나는 따로 보면 별것 아닙니다. 이걸 그냥 두지 않고, 뜻이 가까운 것끼리 도메인별로 묶었습니다. 결제는 결제끼리, 인증은 인증끼리 모으는 식입니다. (의미 기반 군집화)

묶고 나니 흩어져 있을 땐 안 보이던 게 드러났습니다. “이 도메인에서 같은 류의 이슈가 계속 반복되고 있다” 같은 패턴입니다. 조각 하나로는 신호가 아니었던 것이, 모이니 신호가 됐습니다.

정리하면 인덱싱을 두 겹으로 돌립니다.

1. 1차 (검색층): 기록을 검색하기 좋게 벡터로 색인합니다. 의미·단어 하이브리드 검색이 여기서 돕니다.
2. 2차 (인사이트층): 색인된 조각을 도메인별로 군집해, 프롬프트에 얹을 인사이트로 가공합니다.

flowchart TD
    Q[내 질문·검색어] -->|마크다운으로 기록| MD[질의 기록]
    MD -->|증분 인덱싱| V[(로컬 SQLite<br/>벡터 저장소)]
    V -->|1차: 의미+단어 하이브리드 검색| H[과거 비슷한 맥락]
    V -->|2차: 도메인별 의미 군집| C[도메인 인사이트]
    NEW[새 질문] --> P[풍성한 프롬프트]
    H --> P
    C --> P
    P --> LLM[LLM 응답]

    style V fill:#ede9fe,stroke:#7C3AED,stroke-width:2px,color:#1a1a1a
    style P fill:#d1fae5,stroke:#059669,stroke-width:2px,color:#1a1a1a
    style LLM fill:#e0f2fe,stroke:#0EA5E9,stroke-width:2px,color:#1a1a1a

그래서 비서의 답이 달라졌다

이 두 겹을 거치고 나면, 비서가 LLM에게 건네는 프롬프트가 달라집니다.

예전엔 “방금 긁어온 날것의 자료”만 넘겼습니다. 지금은 거기에 “과거의 비슷한 맥락”과 “도메인 단위로 묶인 인사이트”까지 얹어서 넘깁니다. 같은 질문이어도 LLM이 받는 재료의 밀도가 다릅니다. 재료가 풍성하고 정확하니, 한 번에 더 좁혀진 답이 돌아옵니다.

체감으로 말하면, 예전엔 제가 혼자 1인분을 했다면 지금은 비서까지 합쳐 3~4배의 일을 해냅니다. 자료를 모으는 시간이 줄어든 데다, 비서가 건네는 맥락이 두꺼워지면서 같은 시간에 더 많은 이슈를 더 정확하게 처리하게 됐기 때문입니다. 스톱워치로 잰 수치라기보다, 하루에 쳐내는 일의 양이 분명히 달라졌다는 제 체감입니다.

기억에도 그늘은 있다

기억을 붙이면 다 좋아질 것 같지만, 새로 생긴 위험도 있었습니다.

• 오래된 기억: 과거의 원인이 지금도 맞다는 보장은 없습니다. 시스템이 바뀌면 옛 기억이 오히려 비서를 헷갈리게 합니다. 그래서 기억은 “참고”로만 쓰고, 결론의 근거로는 항상 지금의 도구 데이터를 우선합니다.
• 잘못된 군집: 엉뚱한 조각이 한 도메인으로 묶이면, 거기서 뽑은 인사이트도 틀립니다. 군집 결과는 가끔 사람이 들여다봐야 합니다.
• 커지는 인덱스: 기록이 쌓일수록 저장소가 커지고 비용도 늡니다. 오래되고 안 쓰는 기록은 주기적으로 정리합니다.

결국 1편에서 한 말이 2편에서도 그대로입니다. 비서가 똑똑해질수록, 그 결과를 의심하고 검증하는 사람의 몫은 사라지지 않습니다.

비슷하게 기억을 붙일 때 점검할 것

• 기록부터 남겼는가: 거창한 DB 전에, 내 질의를 텍스트로 남기는 것만으로 기억의 씨앗이 됩니다.
• 증분으로 색인하는가: 매번 전체 재색인은 느리고 비쌉니다. 바뀐 것만 얹습니다.
• 검색을 하이브리드로 묶었는가: 의미 검색과 단어 검색은 서로의 구멍을 메웁니다. 한쪽만 쓰지 않습니다.
• 조각을 인사이트로 가공하는가: 검색만 하면 조각에 그칩니다. 군집해야 패턴이 보입니다.
• 기억을 의심하는가: 오래된 기억과 잘못된 군집을 거를 장치가 있는지 확인합니다.

시리즈를 마치며

1편에서 비서는 여러 도구를 엮어 자료 수집을 대신하기 시작했고, 2편에서는 그 위에 기억을 얹어 과거 맥락과 도메인 인사이트까지 스스로 챙기게 됐습니다.

처음엔 그저 알트탭을 덜 누르고 싶었을 뿐인데, 만들고 나니 제 일하는 방식 자체가 바뀌어 있었습니다. 자료를 줍고 모으던 시간이 비서에게 넘어간 자리에, 비서가 모아온 걸 판단하고 결정하는 시간이 들어왔습니다. 같은 하루인데 처리하는 일의 양이 몇 배가 된 건, 제가 빨라져서가 아니라 옆에 기억을 가진 비서가 한 명 더 앉아 있기 때문입니다.

읽어주셔서 감사합니다.🖐