Honcho는 대화를 저장하고 임베딩하는 자체 호스팅 메모리 시스템이다. 지금까지 LLM 추론과 임베딩 생성에 전부 Gemini API를 썼는데, 이걸 전부 GPT-5.6 Luna로 옮기는 작업을 했다. “Gemini API 쓰는 곳을 다 없애는 게 목표”라는 지시가 명확했다.
GPT-5.6 Luna가 기존 방식을 거부했다 — Function tools with reasoning_effort 400 에러
Honcho의 설정 파일(config.toml)엔 역할별로 모델을 지정하는
블록이 여러 개 있다 — 대화 내용을 정리하는 deriver, 질문에 답을
합성하는 dialectic(정확도 단계별로 다섯 개), 요약을 만드는 summary,
회고성 통찰을 뽑는 dream, 그리고 임베딩. 이 블록들의 transport와
모델명을 전부 GPT-5.6 Luna 쪽으로 바꿨다.
바꾸자마자 걸린 문제가 있었다. GPT-5.6 Luna는 툴콜(함수 호출) 기능과
reasoning_effort 옵션을 동시에 쓰는 요청을 거부했다 — “Function
tools with reasoning_effort are not supported… use /v1/responses or
set reasoning_effort to ‘none‘“이라는 400 에러가 돌아왔다. dialectic과
dream처럼 도구를 호출하는 역할들은 이 옵션을 반드시 "none"으로
꺼줘야 했다. 기존에 Gemini 쪽에서 쓰던 설정을 그대로 GPT-5.6 Luna에
옮기면 안 된다는 걸, 실제로 요청을 보내보고서야 알았다.
전환 작업 자체는 설정 파일 수정으로 끝나는 게 아니었다. Docker
구성이 config.toml을 빌드 시점에 이미지 안에 박아 넣는
방식이었어서, 볼륨 마운트가 아니라 컨테이너를 다시 빌드해야
새 설정이 반영됐다. 재빌드 후엔 실제로 새 워크스페이스를
만들고, 진짜 결론을 생성해보고, 실제 채팅 응답을 받아보는
식으로 기능이 살아있는지 직접 확인했다.
걷어내는 김에 다시 켜본 코드에서 버그가 나왔다 — pgvector 전용 모드 documents 동기화 누락
임베딩 제공자를 바꾸는 과정에서, 평소엔 잘 안 건드리는 코드 경로 하나를 다시 켜보게 됐다. Honcho에는 외부 벡터 스토어 없이 pgvector만으로 동작하는 모드가 있는데, 이 모드에서 주기적으로 돌아가는 재조정(reconciliation) 로직을 들여다봤다.
이 로직은 두 종류의 데이터를 동기화한다 — 메시지 임베딩과 문서(documents) 임베딩. 그런데 코드를 따라가 보니, pgvector 전용 모드에서 실행되는 경로는 메시지 임베딩과 정리 작업만 처리하고 있었다. documents를 동기화하는 함수는 아예 호출되지 않았다. Honcho를 pgvector 전용 모드로 오래 운영한 배포라면, 이 상태로는 documents 테이블이 조용히 계속 밀려 있었을 것이다 — 에러도 없고 로그도 없이, 그냥 처리가 안 되는 채로.
이 버그를 고치기 전에, 이미 밀려 있던 26,043건의 documents를 먼저 처리해야 했다. 컨테이너 안에 일회성 스크립트를 넣어 이 백로그를 전부 재임베딩한 뒤, 영구적인 코드 수정을 했다 — 이미 존재하던 메시지 임베딩 쪽의 pgvector 전용 처리 패턴을 그대로 documents 쪽에도 적용해서, 재조정 사이클이 두 종류의 데이터를 똑같이 처리하도록 맞췄다.
이 저장소의 로컬 테스트용 데이터베이스 설정이 실제 운영 데이터베이스와 접속 정보가 달라서, 자동화된 테스트 스위트를 그대로 돌려서 검증할 수는 없었다. 대신 실제로 떠 있는 컨테이너에 직접 붙어서, 수정 전후의 동작을 눈으로 비교하는 방식으로 검증했다. 테스트 코드 자체는 정상적으로 추가해뒀다 — 다음에 테스트 인프라가 갖춰지면 그때 자동으로 돌아갈 수 있게.
모델을 바꾸려던 것뿐이었는데
이번 작업의 원래 목적은 “Gemini API 사용을 없애는 것” 하나였다. 그런데 그 과정에서 설정 파일을 역할별로 하나씩 점검하다가 GPT-5.6 Luna의 API 제약을 만났고, 임베딩 경로를 다시 들여다보다가 원래 목적과 무관한 재조정 버그까지 찾았다. 모델을 바꾸는 것 자체는 계획된 일이었지만, 그 계획을 실행하려고 코드를 한 번 더 자세히 들여다본 덕분에 발견한 버그였다 — 원래 찾으려던 게 아니었던 것치고는, 오래 방치됐을수록 조용히 커지는 종류의 문제였다.
로컬에서 고치고 우리 배포에만 반영하고 끝낼 수도 있었다. 다음 편은 왜 그러지 않고 이 수정을 원본 프로젝트에 돌려주기로 했는지, 그리고 그 과정에서 겪은 것들이다.