개요 서버 에러 로그를 자동으로 분석하는 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 코드...
BM25 하이브리드 검색을 도입하고 나서 자연스럽게 궁금증이 생겼다. “검색이 실제로 잘 되고 있는 걸까?” 로그를 보면 파일 목록이 반환되는 건 확인되지만, 그게 맞는 파일인지 판단할 기준이 없었다. RAG 품질을 수치로 측정하는 평가 시스템을 만든 이유다. 무엇을 측정하나 RAG 평가에서 핵심은 “정답 파일이 검색 결과에 포함됐는가”다. ...
처음엔 Ollama만 쓰다가 Gemini를 주력으로 바꿨다. 이유는 속도다. Ollama에서 gemma4:12b를 쓰면 응답 시간이 20~30초다. Gemini API는 2~3초다. 일상적으로 쓰는 개인 비서에서 응답을 30초 기다리는 건 너무 불편하다. 그렇다고 Ollama를 완전히 버리면 API 할당량이 소진됐을 때 쓸 수 없게 된다. Gemi...
