🤖
1303 in / 3675 out / 4978 total tokens
오늘 트렌딩 repo 두 개가 눈에 띄었다. 둘 다 LLM을 실무에 어떻게 끼워넣나에 대한 접근이지만, 방향이 완전히 다르다. 하나는 영업 자동화고, 하나는 에이전트 아키텍처 근본 문제를 건드린다.
🔥 핫 토픽
Agent-Memory-Compressor — LLM 에이전트의 컨텍스트 윈도우 고갈 문제를 정면으로 파고든 프로젝트
긴 시간 동작하는 LLM 에이전트를 만들어본 사람이라면 누구나 겪는 문제가 있다. 바로 컨텍스트 윈도우가 터지는 거다. 에이전트가 작업을 수행하면서 대화 기록, 도구 호출 결과, 중간 추론 과정을 계속 컨텍스트에 쌓다 보면, 어느 순간 토큰 리미트에 부딪혀서 에이전트가 사실상 맹인이 된다. 게임 서버에서 메모리 릭 잡는 거랑 똑같은 느낌이다. 방치하면 크래시 나고, 처리 안 하면 성능이 점진적으로 저하된다.
이 프로젝트는 요약(summarization)과 임베딩 기반 검색을 결합해서 해결하려 시도한다. 단순히 오래된 메시지를 날리는 게 아니라, 임베딩 벡터로 중요도를 판별해서 task-critical한 정보는 보존하고 나머지는 압축하는 방식이다. UE5에서 오브젝트 풀링하면서 중요한 애터는 Keep하고 나머지는 Destory하는 로직이랑 구조가 비슷하다. 발상 자체는 새롭지 않지만, 구현체가 깔끔하게 나왔다.
실무적으로 이게 왜 중요하냐면, 에이전트 기반 시스템을 프로덕션에 넣으려면 이 문제를 반드시 해결해야 한다. 단발성 채팅은 컨텍스트 관리가 필요 없지만, 자율적으로 행동하는 에이전트는 상태를 유지해야 한다. 현재 주요 프레임워크(LangChain, AutoGen 등)도 메모리 관리 모듈을 제공하지만, 대부분이 단순 슬라이딩 윈도우나 전체 요약에 그친다. 임베딩 기반 선택적 보존은 더 정교한 접근이다.
기술적으로 흥미로운 지점은 evaluation 파이프라인이 포함되어 있다는 거다. 압축 후에도 핵심 정보가 유지되는지 검증하는 메커니즘이 있다는 건, 실제로 돌려보면서 임계값을 튜닝할 수 있다는 의미다. 프로파일링 툴 없이 최적화하는 거랑 툴 달고 하는 거 차이만큼 중요하다.
게임 개발 관점에서 보면, 이건 결국 "有限한 자원(컨텍스트 윈도우) 안에서 중요한 정보를 어떻게 유지할 것인가"라는 문제다. LOD 시스템이랑 비슷하다. 멀리 있는 건 디테일 줄이고, 가까이 있는 건 디테일 유지하고. 에이전트 메모리도 중요도에 따라 해상도를 다르게 가져가야 한다.
ai-leadgen-system — LLM으로 리드 생성부터 스코어링, 아웃리치까지 자동화
리드 제너레이션(lead generation)은 B2B 세일즈의 생명줄이다. 잠재 고객을 찾고, 점수를 매기고, 적절한 타이밍에 연락하는 이 과정이 사람 손으로 하면 시간이 무지하게 든다. 이 프로젝트는 그 전체 파이프라인을 LLM으로 자동화하려는 시도다.
FastAPI 기반이라는 점이 마음에 든다. 파이썬 생태계에서 API 서버 만들 때 FastAPI는 거의 표준이 됐다. Flask보다 타입 힌팅이 깔끔하고, 자동 문서 생성되고, 비동기 처리가 기본이라 성능도 잘 나온다. UE5 C++ 하다가 파이썬으로 넘어올 때 Flask부터 시작했는데, FastAPI로 갈아타고 나서 생산성 차이가 확실히 느껴졌다.
LLM 기반 분류(classification)가 핵심인데, 전통적인 머신러닝 모델로 리드 스코어링하려면 특성 공학(feature engineering)이 엄청나게 귀찮다. 산업, 기업 규모, 최근 펀딩 라운드, 기술 스택 등등 수십 개 특성을 정의하고 라벨링 데이터를 모아야 한다. LLM은 이걸 프롬프트 하나로 우회할 수 있다. 물론 정확도는 검증해야 하지만, 초기 프로토타입 속도는 압도적이다.
다만, 실제 프로덕션에서 쓰려면 고려할 게 많다. LLM API 비용이 리드 하나당 얼마나 드는지, 응답 속도는 실시간 처리에 견디는지, 환각(hallucination)으로 인해 잘못된 리드를 잡는 건 아닌지. 특히 아웃리치 자동화는 한 번 잘못 나가면 브랜드 이미지에 타격이 크다. 게임에서 툴팁 하나 잘못 번역해도 커뮤니티에서 난리 나는 거랑 비슷하다.
이 프로젝트의 가치는 완성된 솔루션이라기보다는, LLM을 활용한 비즈니스 로직 자동화의 좋은 레퍼런스라는 데 있다. 아키텍처 구조, API 설계, LLM 호출 방식 등을 참고해서 자기 서비스에 맞게 변형해서 쓰기 좋다. 나도 사이드프로젝트에서 사용자 행동 분석하는 부분에 비슷한 패턴을 적용할 수 있을 것 같다.
두 프로젝트의 연결점
언뜻 보면 관련 없는 두 프로젝트지만, 사실 깊은 연결고리가 있다. ai-leadgen-system 같은 자동화 파이프라인을 실제로 돌리다 보면, 장시간 실행되는 에이전트 상태가 되고 결국 컨텍스트 관리 문제에 부딪힌다. 예를 들어, 리드를 계속 모니터링하면서 최적의 아웃리치 타이밍을 잡는 에이전트를 만든다면, Agent-Memory-Compressor 같은 메모리 관리가 필수다.
또한 두 프로젝트 모두 "LLM을 어디에 쓸 것인가"가 아니라 "LLM을 어떻게 안정적으로 돌릴 것인가"에 초점이 맞춰져 있다. 이건 업계가 초기 hype 단계를 지나서 실제 engineering 문제로 넘어가고 있다는 신호다. 게임 개발에서도 언리얼 엔진 초기에는 "3D 게임을 만들 수 있다"가 중요했지만, 지금은 "어떻게 최적화해서 60프레임을 유지할까"가 핵심이 됐다. LLM 분야도 같은 성숙 과정을 밟고 있다.
임베딩 기반 정보 검색은 두 프로젝트 모두에서 활용 가능한 기술이다. 리드 데이터에서 유사한 기업을 찾을 때도 임베딩을 쓸 수 있고, 에이전트 메모리에서 중요 정보를 찾을 때도 임베딩을 쓴다. 벡터 데이터베이스와 임베딩 모델에 익숙해지는 건 이제 선택이 아니라 필수 같다.
에이전트 시대의 핵심은 모델 성능이 아니라, 제한된 컨텍스트 안에서 어떻게 중요한 걸 유지하고 버릴 걸 버리느냐다. 게임 최적화랑 다를 바 없다.