배경 에이전트 구축기 (3)에서 ChromaDB 기반 RAG로 소스코드를 검색하는 방식을 구현했다. 에러가 발생하면 관련 파일을 청킹·임베딩해 벡터로 저장하고, 분석 시 유사도 검색으로 관련 청크를 가져오는 방식이었다. 실제 운영하면서 이 방식이 생각만큼 잘 동작하지 않는다는 걸 깨달았다. 이 포스트는 왜 RAG를 버렸는지, 어떻게 바꿨는지를 정리...
Slack 기반 AI 개인 비서에 LlamaIndex를 도입했다. 기억 저장/검색 파이프라인을 교체하고, 대화 히스토리 압축과 Knowledge Graph를 추가했다. 왜 LlamaIndex인가 기존 memory_service.py는 LlamaIndex 없이 직접 구현되어 있었다. # AS-IS: 수동 구현 async def _embed(te...
개요 서버 에러 로그를 자동으로 분석하는 Log Agent에서 프로젝트 소스코드 검색 방식을 변경했습니다. 기존에는 RAG(Retrieval-Augmented Generation) 방식으로 ChromaDB에 코드를 청킹·임베딩해 벡터 검색으로 관련 파일을 찾았습니다. 하지만 실제 운영 중에 여러 한계를 발견했고, 로컬 파일을 직접 읽는 Tool 방...
BM25를 붙이고 나서 “또리 생일”은 잘 찾는데, “내차가 뭐지?”는 여전히 못 찾는 문제가 생겼다. 증상 사용자: 내차는 기아 ev6야 봇: 💾 이렇게 기억할게요: _사용자의 차: 기아 EV6_ 맞나요? 사용자: 예 봇: ✅ 기억했습니다! 사용자: 내차가 뭐지? 봇: 사용자의 차량 정보에 대해서는 아직 기억해 둔 내용이 없습니다. 로그...
기억 기능을 만들고 실제로 써보니 예상 못한 곳에서 계속 터졌다. 구현보다 디버깅에 더 많은 시간을 쓴 날이었다. 문제들을 순서대로 정리했다. 1. “또리” 를 못 찾는 문제 — 순수 벡터 검색의 한계 사용자: 또리 생일 기억해줘 봇: ✅ 기억했습니다! 사용자: 또리 생일이 언제야 봇: 죄송합니다. 또리의 생일 정보는 찾을 수 없었습니다. ...
서버에서 에러가 발생하면 자동으로 원인을 분석하고, 코드 수정안을 만들어 GitHub PR까지 생성하는 AI 파이프라인을 구축했다. 이 포스트는 전체 시스템 구조와 각 단계에서 적용한 AI 기법들을 정리한다. 전체 파이프라인 서버 에러 발생 ↓ Webhook 수신 (FastAPI) ↓ ① Git fetch — 최신 소스코드 로컬 ...
에이전트가 에러를 분석하고 코드 수정을 제안할 때, 그 결과가 실제로 올바른지 어떻게 보장할 수 있을까? self-reflection(자기 검증)을 이미 구현했지만 이건 같은 모델이 자기 출력을 검토하는 구조다. 생성한 사람과 검토하는 사람이 같으니 자기 편향(self-evaluation bias)이 생길 수 있다. 이 문제를 외부 LLM을 Judg...
같은 서버에서 비슷한 에러가 반복되는 상황은 흔하다. 배포 직후 설정 오류가 여러 번 발생하거나, 특정 트래픽 패턴에서 항상 같은 NPE가 터지는 식이다. 현재 RAG 파이프라인은 매번 처음부터 분석한다. 과거에 같은 에러를 분석했다는 사실을 모른다. Error Memory는 분석 결과를 벡터 DB에 저장해두고, 다음 유사 에러 발생 시 과거 사례...
에러 스택 트레이스에는 보통 하나의 클래스가 명시된다. 하지만 실제 원인은 그 클래스가 의존하는 다른 파일에 있는 경우가 많다. java.lang.NullPointerException at UserService.findById(UserService.java:42) UserService를 찾아서 LLM에게 주면 분석은 시작할 수 있다. 하지만 Us...
에러 분석 에이전트의 가장 핵심적인 기능은 수정 코드를 GitHub PR로 자동 생성하는 것이다. LLM이 before/after 스니펫을 제안하면, 실제 파일에서 before를 찾아 after로 교체한다. 이 패칭 과정에서 겪은 문제들과 최종 해결 방법을 정리한다. 처음 겪은 문제: string 매칭 실패 LLM이 제안하는 before 코드...