피드로 돌아가기
When Your Agent Slowly Eats All the Memory
Dev.toDev.to
Backend

Agent 게이트웨이가 세션 정리 부재와 스킬셋 중복으로 1시간에 200MB에서 850MB로 메모리 누수되는 현상 분석

When Your Agent Slowly Eats All the Memory

Wu Long2026년 3월 26일6intermediate

Context

Agent 게이트웨이가 22개 스킬, 12개 크론 작업, 빈번한 서브 에이전트 생성 환경에서 명확한 에러 없이 점진적으로 메모리를 소진하는 문제가 발생했다. 초기 200MB RSS에서 7분 후 660MB, 30분 후 850MB, 60분 후 응답 불능 상태에 도달했다.

Technical Solution

  • 완료된 세션의 무한 보관 제거: 78개 완료된 서브에이전트 세션과 40개 크론:run 세션이 sessions.json에 영구 저장되는 문제 해결을 위한 세션 만료 시간 설정 필요
  • skillsSnapshot 중복 제거: 세션당 41KB의 전체 스킬셋 스냅샷이 188개 세션에 걸쳐 6.4MB 중복 누적되는 구조 개선
  • 고아 트랜스크립트 정리: 153개의 매칭되는 세션 없는 .jsonl 파일(36.4MB)을 재시작 시 자동으로 삭제하는 프로세스 추가
  • 세션 상태 머신 완성: created → active → completed → pruned 상태 전환 구현으로 임시 데이터의 자동 정리 경로 마련
  • 성장률 계측 도입: 세션 수, 파일 크기, RSS 메모리를 시간대별로 추적하는 모니터링 지표 추가

Impact

본문에서 명시된 정량적 개선 수치가 없음. 다만 문제 상황을 정량화함: 78개 + 40개의 좀비 세션, 41KB × 188 = 6.4MB 중복, 36.4MB 고아 파일, 1시간 내 650MB 메모리 증가

Key Takeaway

메모리 누수는 전형적인 누수가 아닌 '축적 누수'로, 단기 생명주기를 가진 데이터(크론 작업, 서브에이전트)가 만료 정책 없이 영구 저장될 때 발생한다. 에이전트 시스템에서 요청당 생성되는 임시 데이터는 반드시 구현된 정리 경로를 가져야 한다.


다중 세션을 관리하는 에이전트 시스템에서는 생명주기가 명확한 임시 세션(크론, 서브에이전트)에 대해 TTL 기반 만료 정책을 설계해야 한다. 현재 workaround가 '주기적으로 수동 정리'라면 이미 자동 정리 메커니즘이 누락된 신호이며, 단일 복사본 10배 증가 시나리오(41KB × 1,880세션 = 64MB)를 항상 사전 검토하면 누적 누수를 조기에 발견할 수 있다.

원문 읽기