마이위키 채팅을 쓰다 보면 먼저 느껴지는 건 청구서 숫자가 아니다. 답을 기다리는 그 몇 초다. 한 줄 보내고 가만히 있으면, 머릿속에는 “이 정도면 바로 나와야 하는 거 아닌가”가 먼저 돈다. 원장에서 채팅 쪽 원가를 보면 정리에 비하면 작은 편인데도, 체감은 반대였다. 느린 느낌의 중심은 달러가 아니라 대기 시간이었다.
그 답답함의 한 갈래는, 간단한 말도 검색을 타려는 쪽이었다. “응”, 후속 한 줄, 방금 이어가는 말인데도 파이프라인이 위키를 찾으러 가는 것 같았다. 그래서 분기를 넣었다. 이번 턴에 위키 근거가 진짜 필요한지부터 가르고, 필요할 때만 문서 선정으로 넘어가게. 코드 이름으로는 needSearch에 가까운 의도 게이트다.
검색 필요를 뭐로 판단하나
7월 중순에 코드를 따라가 보니 질문은 자연스러웠다. “대화 보낼 때 공간 문서 지도를 항상 프롬프트로 같이 보내?” 답은 아니오였다. 디스크에서 지도를 읽는 것과, 답 프롬프트에 지도를 붙이는 것과, 선정 단계에 지도를 넣는 것은 서로 달랐다.
그다음 질문이 더 날카로웠다. “검색 필요 판정을 모델이 하는데, 지도를 넣어야 하는 거 아님?” 직감은 서가 목록을 봐야 찾을지 말지 안다는 쪽이다. 그런데 당시 설계는 그걸 일부러 안 따랐다. 1단계는 “이 말이 새 위키 근거를 필요로 하는 말인가”만 본다. 2단계가 “그럼 어떤 문서인가”를 지도와 대조한다. 판정 재료는 규칙 프롬프트, 최근 대화 조각, 이번 유저 메시지다. 위키에 뭐가 있는지는 이 층에 없다.
비유하면 도서관 목록을 안 보고, 이 사람이 책을 찾아봐야 하는 질문을 했는지 방금 나눈 얘기만 이어가면 되는지 듣는 쪽에 가깝다. 지도를 판정에 넣으면 “검색 필요?”가 “목록에 비슷한 제목이 있나?”로 기울기 쉽고, 잡담 한 줄에도 토큰이 나간다. 그래서 의도와 목록 대조를 갈랐다. 구멍이 없는 건 아니다. 히스토리만으로 이어 답할 수 있다고 잘못 보면 위키에 있는 디테일을 못 연다. 그래도 그때는 과검색과 대기 시간을 먼저 줄이는 쪽을 골랐다.
문서 지도 전체를 답 프롬프트에 넣던 짐
분기로 “안 찾을 턴”을 줄여도, 찾을 턴의 짐은 남았다. 관련 문서가 잡히면 답 프롬프트에 공간 문서 지도 요약 전체와 본문을 같이 넣는 경로가 있었다. 선정기는 이미 지도를 보고 문서 id를 골랐다. 그런데 채팅 프롬프트에 지도 전체를 다시 넣는 건, 이미 본 목록을 답 모델에게 한 번 더 보여주는 셈이었다. 공간 문서가 늘수록 그 짐은 커진다.
정리 쪽에서는 이미 같은 교훈을 한 바퀴 돌았다. 핫패스 모델은 단가만 깎는 게 아니라 빈도·분량·주입 크기를 같이 조여야 한다. 채팅 주입도 그 버전이다. 손댄 건 단순하다. 후보 문서가 있을 때 답 프롬프트 문자열에서 전체 지도 문구를 빼고, 선정된 문서 메타(제목, 문서 id, 한 줄 요약)와 본문만 넣는다. 본문 캡은 문서당 4,000자, 합 10,000자로 내렸다. 그 전에는 14k/28k 근처였다. 선정부가 이미 지도를 봤으니 답 프롬프트에 지도를 다시 넣을 이유가 약해졌다는 게 근거였다.
스모크 기준도 그에 맞춰 잡았다. 관련 문서가 있는 픽스처에서 답 프롬프트에 “위키 문서 지도” 같은 전체 지도 문구가 없고, 주입 본문이 캡 안이어야 한다. 토큰 폭을 줄이는 작업으로는 여기서 한 칼이 들어갔다.
그런데 채팅은 아직 별로 안 나아졌다
여기까지 쓰면 성공 스토리처럼 들릴 수 있다. 실제 체감은 아직 그 정도가 아니다.
구술로 정리하면 이렇다. 문제는 일단 시간이었고, 간단한 것도 검색하려 해서 분기를 넣었다. 그 뒤에도 채팅은 개선을 많이 안 했다. 답이 너무 단답형이다. 검색을 제대로 붙이지 못한 이유도 비용이다. 위키 내용을 복붙한 느낌이 나고, 맥락을 잡고 새로 도출해야 하는데 그 층은 거의 안 건드렸다.
톤 쪽 프롬프트는 손댔다. 잡담·고민·위로도 가능하게 하고, 위키 히트 시 원문 장문 복붙 금지, 요약과 종합·의견을 쓰라는 쪽으로 문구를 바꿨다. “이 대화는 이후 자동으로 공간·문서로 정리됩니다” 같은 위키 중심 정체성 문구도 밀어붙이지 말자고 정리했다. 그래도 품질은 미완이다. 프롬프트 한 줄이 복붙 느낌을 바로 지우지는 않았다. 단답도 그대로 남는 날이 많다.
검색을 “제대로” 붙인다는 말도 아직 숙제다. 검색 필요 분기는 과검색을 줄이려는 쪽이고, 본검색 품질(무엇이 히트해야 하는지, 후속 질문에서 위키 디테일을 언제 열지, 비용 대비 얼마나 깊게 찾을지)은 다른 레버다. 그것도 호출이 늘면 다시 시간과 원가가 올라간다. 정리 비용을 조이느라 쌓인 감각이 채팅 검색에도 그대로 걸려 있다. 그래서 안 붙인 채로 둔 부분이 있다. 부끄러운 미완이 아니라, 같은 병목 지도 위에 아직 손 안 댄 칸이다.
시리즈 위치
이 시리즈 구현 편들로 보면, 핫패스에서 불필요하게 크던 주입은 잘랐다. 문서 지도 전체 재주입 제거, 본문 4k/10k 캡, 검색 의도 분기가 그 줄이다. 정리 쪽 비용 교훈을 채팅 주입에 옮긴 작업이기도 하다.
열어 둔 숙제는 채팅이 “쓰기 좋은 대화”인지 쪽이다. 짧은 답이 기본값처럼 나오는 문제, 검색이 비용 때문에 얕게 묶인 문제, 위키를 읽고 새 문장을 만들지 못하고 붙여 넣는 느낌. 톤 프롬프트만으로는 안 닫힌다. 제품이 실사용으로 넘어가면 이 세 칸이 다시 맨 앞으로 올 가능성이 크다.
원가 표에 찍히는 숫자와 내가 답답해하는 초는 같은 축이 아니다. 이번 편에서 자른 건 그중 대기와 주입 폭에 가깝고, 대화 품질은 아직 숙제 칸에 있다.