개인 일과 업무를 기억 서버 안에서 두 방으로 나눠 두었습니다.
그런데 처음 기록을 옮기던 날, 업무 대화 일부가 개인 방으로 들어가 있었습니다. 방을 나눠 놓고 정작 문 앞에서 잘못 안내한 셈입니다.
이번 포스팅에서는 세션 분류기가 왜 틀렸는지, 고친 뒤에도 왜 잘못 들어간 기록이 그대로 남아 있었는지, 그리고 끝내 남은 한계까지 풀어 보도록 하겠습니다.
2026-09-18, 처음 옮긴 날
그날 지난 세션 35건과 메모리 105건을 기억 서버로 옮겼습니다.
옮기는 과정에서 업무 세션 일부가 개인 쪽으로 분류된 것이 드러났습니다.
원인: 메모리용 분류기를 세션에 그대로 썼습니다
메모리는 이미 분류기가 있었습니다. 메모 파일 이름이 영문 슬러그라서, 파일 이름에 든 단어로 어느 방인지 가렸습니다.
세션 기록에도 그 분류기를 가져다 썼습니다.
그런데 세션의 제목과 요약은 영문 슬러그가 아니라 한글 문장입니다. 영문 단어를 찾는 분류기는 한글 제목을 제대로 읽지 못했고, 업무 세션이 개인 쪽으로 샜습니다.
제가 가장 쓰게 느낀 대목입니다. 분류기가 잘 돈다는 걸 확인한 대상은 메모리였지, 세션이 아니었습니다. 입력의 생김새가 다른데 같은 규칙이 통할 거라고 넘겨짚었습니다.
고친 방법: 한글 낱말 점수
세션용 분류기를 따로 만들었습니다. 대화 본문에서 업무 쪽 낱말이 몇 번 나오는지 셉니다. 줄여 옮기면 이렇습니다.
def classify_session(body, title, profile):
ent = len(BUSINESS_WORDS.findall(body))
is_ent = ent >= 3 or (ent >= 1 and len(body) < 4000) # 짧은 세션은 한 번으로도
...
세 번 이상 나오면 업무 쪽입니다. 다만 짧은 세션(4,000자 미만)은 한 번만 나와도 업무로 봅니다. 짧은 대화에서는 그 한 번이 주제 자체인 경우가 많기 때문입니다.
고친 뒤 최종 결과는 세션이 개인 12건, 업무 23건이었습니다. 메모리는 개인 26건, 업무 79건이었습니다.
업무 쪽 낱말 목록은 이 글에 싣지 않습니다. 그 목록 자체가 어떤 일을 하는지 말해 주기 때문입니다.
그런데 고쳐도 남아 있었습니다
같은 날 메모리 쪽에서도 비슷한 일이 있었습니다. 분류를 고쳐 업무 쪽으로 옮긴 메모리 하나가, 개인 방에도 그대로 남아 있었습니다.
이유는 적재 방식이었습니다. 적재기는 새 것을 더하기만 했습니다. 새 판단에 따라 업무 방에는 들어갔지만, 개인 방에 있던 옛 사본을 지우는 단계가 없었습니다.
그 옛 사본은 개인 세션을 열 때마다 계속 주입되고 있었습니다.
그래서 적재를 동기화로 바꿨습니다. 적재할 때 "이번 판단으로 이 방의 몫이 아니게 된 행" 을 찾아 지웁니다.
⚠️ 분류 규칙을 바꾸는 순간, 예전 규칙으로 들어간 것들이 문제가 됩니다. 더하기만 하는 적재는 고친 규칙을 반쪽만 적용합니다.
끝내 남은 한계: 두 주제를 오간 세션
그래도 못 고친 것이 하나 있습니다. 한 세션에서 개인 일과 업무를 다 다룬 경우입니다.
실제로 기억 서버를 설계하면서 업무 쪽 배포도 함께 본 세션이 있었는데, 이 세션은 업무 방으로 갔습니다. 그래서 개인 방에서 WireGuard 를 검색하면 0건이 나옵니다. 기억 서버 설계의 상당 부분이 그 세션에 있는데도요.
고치려면 세션을 턴 단위로 쪼개 따로 분류해야 합니다. 들이는 품에 비해 얻는 게 적다고 판단해서 하지 않았습니다. 대신 이 한계를 문서에 적어 두었습니다.
그 뒤로는 한 세션에서 성격이 다른 일을 섞지 않으려고 합니다. 분류기를 고치는 것보다 그쪽이 쌌습니다.
분류기를 붙일 때 확인할 것
1. 다른 데이터에서 잘 돌던 분류기를 가져올 때, 입력의 생김새(언어·길이·형식)가 같은지 먼저 봅니다.
2. 분류가 아무것도 못 찾았을 때 어느 쪽으로 보내는지 정합니다. 기본값이 곧 새는 방향입니다.
3. 분류 기준이 되는 낱말 목록도 민감한 정보일 수 있습니다. 공개하는 문서에 싣지 않습니다.
4. 규칙을 바꿨다면 예전 결과를 지우는 단계까지 넣습니다. 적재는 더하기가 아니라 동기화입니다.
5. 못 고친 한계는 고친 척하지 말고 적어 둡니다. 다음에 검색이 0건일 때 이유를 알 수 있습니다.
나누는 규칙을 만드는 것보다, 규칙이 바뀐 뒤에 예전 것을 치우는 일이 더 쉽게 빠졌습니다.
혹시 데이터를 자동으로 분류해 쌓고 계신다면, 규칙을 고친 뒤 예전에 잘못 들어간 것이 아직 남아 있지는 않은지 한번 세어 보시는 건 어떨까요?
그러면 오늘도 모두 스테이블 하세요.
만든 것들
'Coding, Testing, Challenge' 카테고리의 다른 글
| Claude Code 기억 서버 하나에 개인 일과 업무를 섞지 않는 법, 같은 서버 다른 방 (0) | 2026.10.09 |
|---|---|
| 대시보드가 멀쩡해 보이는데 영영 갱신이 안 됐다, 파이썬 조용한 except 잡는 법 (0) | 2026.10.08 |
| AI 기억 서버 백업, DB가 정본이고 git이 백업인데 복원 리허설까지 한 이유 (0) | 2026.10.08 |
| Claude Code 기억 서버를 VPS 월 12달러로 만든 구조, 서버에 둔 것과 PC에 남긴 것 (0) | 2026.10.08 |
| AI 대화 기록에 비밀번호·키 144개가 남아 있었다, 바이브코딩 전에 할 보안 점검 (0) | 2026.10.08 |