LangMem을 기본값으로 사용하지 않게 된 이유와 전환하며 배운 점
Why I stopped defaulting to LangMem and what I learned from switching
핵심 요약
LangMem의 비용과 지연 시간 문제로 인해 상태 비저장 방식과 구조화된 프롬프트 활용의 중요성을 깨달은 경험담.
- 비용 및 지연 시간 — 사용량이 늘어날수록 LangMem의 메모리 상태 유지 비용과 지연 시간이 실질적인 부담으로 작용함.
- 커스텀 메모리 계층 — 제어력은 높지만 유지보수 부담이 3배 이상 증가하여 운영 효율이 떨어짐.
- 상태 비저장 방식 — 구조화된 시스템 프롬프트를 활용하면 메모리 저장 데이터의 상당 부분을 대체할 수 있음.
- 운영 환경의 변수 — 프로덕션 단계에 진입하기 전까지는 프레임워크별 잠금 효과와 비용 구조를 파악하기 어려움.
지난 10월 LangGraph가 정식 출시(GA)되었을 때, LangMem을 사용하는 것이 당연한 선택처럼 보여 도입했습니다. 7개월이 지난 지금, 몇 가지 의견이 생겼습니다.
LangMem은 메모리 검색이 추론 비용과 경쟁하기 전까지는 아주 잘 작동합니다. 사용량이 적을 때는 거의 눈에 띄지 않죠. 하지만 매일 수백 개의 세션을 실행하게 되면, 메모리 상태를 유지하는 데 드는 검색 지연 시간과 세션당 비용이 실질적인 항목으로 다가옵니다. 우리는 두 달쯤 지났을 때 이 문제를 겪었고, 이에 대한 예산은 전혀 고려하지 않은 상태였습니다.
우리가 시도한 대안은 커스텀 메모리 계층이었습니다. 제어하기가 더 쉽고 우리만의 특정 검색 패턴에 맞춰 튜닝하기도 좋았죠. 하지만 유지보수 부담은 대략 3배 정도 늘어났습니다. 프레임워크가 업데이트될 때마다 제가 수동으로 고쳐야 하는 부분들이 생길 가능성이 컸거든요.
처음에 완전히 과소평가했던 옵션은 잘 구조화된 시스템 프롬프트를 사용하는 상태 비저장(stateless) 방식이었습니다. 메모리에 저장하던 데이터의 상당 부분은 사실 프롬프트 내의 구조적 컨텍스트로 충분히 대체할 수 있었습니다. 지금은 그 세션들 중 일부를 다시 상태 비저장 방식으로 마이그레이션하고 있습니다.
아직 명확한 결론을 내린 건 아닙니다. 단지 프로덕션 환경에 들어가기 전까지는 드러나지 않는 세 가지 다른 잠금 프로필과 비용 구조가 있을 뿐이죠. 다들 현재 어떤 설정을 사용하고 계신가요?
