느린 LLM 호출 중 DB connection을 잡지 않는 이유

느린 LLM 호출 중 DB connection을 잡지 않는 이유 AI 기능의 latency는 모델 응답 시간으로만 끝나지 않습니다. 요청이 LLM이나 embedding API를 기다리는 동안 데이터베이스 session까지 긴 범위로 유지하면, 느린 외부 호출이 DB connection pool의 압력으로 전파될 수 있습니다. 이 글은 AI memory OSS인 Honcho의 변경 이력과 pinned source를 읽으면서, 외부 호출과 DB transaction/session 경계를 어떻게 분리했는지 추적한 기록입니다. Scenario Honcho의 dialectic 경로(저장된 memory를 근거로 사용자 질문에 답하는 질의 경로)는 답하기 전에 다음 작업을 수행합니다. peer·session·workspace 확인 -> 관련 memory 검색 -> embedding·LLM 호출 -> 필요하면 tool로 추가 조회·기록 -> 답변 생성 여기에는 짧은 DB 조회와 상대적으로 느리고 변동성이 큰 외부 호출이 섞여 있습니다. 두 작업을 하나의 session scope로 묶으면, DB가 필요하지 않은 대기 시간까지 session lifetime에 포함됩니다. 변경 전에는 무엇이 묶여 있었나 PR #477 직전의 agentic_chat 은 하나의 tracked_db context 안에서 peer와 설정을 읽고, 그 session을 DialecticAgent 에 전달한 뒤, agent.answer() 가 끝날 때까지 같은 context를 유지했습니다. streaming 경로도 같은 형태였습니다. 구조를 단순화하면 다음과 같습니다. DB session open -> preflight read -> DialecticAgent receives session -> embedding / memory tools / LLM answer DB session close commit 0533c6d 의 제목도 이 문제를 dialectic held connection 으로 기록합니다. 다만 이번 분석에서는 실제 pool checkout 시간이나 장애를 재현하지 않았습니다. 여기서 확인한 것은 코드의 session scope와 변경 의도입니다. SQLAlchemy의 session 객체를 만들었다고 곧바로 connection을 점유하는 것은 아닙니다. 하지만 이 경로처럼 SQL을 실행해 transaction이 시작되면 session은 pool에서 빌린 connection을 commit·rollback까지 유지합니다. Honcho의 tracked_db 는 종료할 때 rollback() 과 close() 를 호출하므로, SQL 실행 뒤 이 context를 LLM 대기까지 유지하던 범위를 줄이는 것은 이 경로의 connection 점유 구간도 줄이는 일입니다. 어떻게 경계를 줄였나 변경 후에는 tracked_db("dialectic.preflight") 가 본 작업 전 검증과 설정 조회(preflight), 즉 peer 존재 여부, session/workspace 설정, peer card를 읽는 구간만 감쌉니다. context가 끝난 다음에 DialecticAgent 를 만들고 LLM 답변을 생성합니다. Agent 생성자에서도 DB session 인자가 제거됐습니다. short DB preflight -> 필요한 값 읽기 DB session close agent execution -> embedding / LLM / tools tool needs DB -> tool-owned short DB session -> close 핵심은 DB 사용을 없앤 것이 아닙니다. 요청 전체가 session을 소유하는 대신, DB가 필요한 작업이 자기 범위의 session을 소유하도록 바꾼 것 입니다. pinned current code에서도 유지되는가 분석 기준 commit 85239a6 에서도 이 경계는 유지되고 더 구체화돼 있습니다. src/dialectic/chat.py 의 일반·streaming 경로 모두 preflight context를 닫은 뒤 agent를 실