서버에서 에러가 발생하면 자동으로 원인을 분석하고, 코드 수정안을 만들어 GitHub PR까지 생성하는 AI 파이프라인을 구축했다. 이 포스트는 전체 시스템 구조와 각 단계에서 적용한 AI 기법들을 정리한다. 전체 파이프라인 서버 에러 발생 ↓ Webhook 수신 (FastAPI) ↓ ① Error Memory 검색 — 과거 유사...

에이전트가 에러를 분석하고 코드 수정을 제안할 때, 그 결과가 실제로 올바른지 어떻게 보장할 수 있을까? self-reflection(자기 검증)을 이미 구현했지만 이건 같은 모델이 자기 출력을 검토하는 구조다. 생성한 사람과 검토하는 사람이 같으니 자기 편향(self-evaluation bias)이 생길 수 있다. 이 문제를 외부 LLM을 Judg...

같은 서버에서 비슷한 에러가 반복되는 상황은 흔하다. 배포 직후 설정 오류가 여러 번 발생하거나, 특정 트래픽 패턴에서 항상 같은 NPE가 터지는 식이다. 현재 RAG 파이프라인은 매번 처음부터 분석한다. 과거에 같은 에러를 분석했다는 사실을 모른다. Error Memory는 분석 결과를 벡터 DB에 저장해두고, 다음 유사 에러 발생 시 과거 사례...

에러 스택 트레이스에는 보통 하나의 클래스가 명시된다. 하지만 실제 원인은 그 클래스가 의존하는 다른 파일에 있는 경우가 많다. java.lang.NullPointerException at UserService.findById(UserService.java:42) UserService를 찾아서 LLM에게 주면 분석은 시작할 수 있다. 하지만 Us...

기능 구현보다 배포와 운영에서 더 많은 시간을 썼다. 로컬에서 잘 되던 게 Docker 환경에서 안 되는 일이 반복됐다. 마주친 문제들을 정리했다. Jenkins CI/CD 파이프라인 pipeline { environment { APP_NAME = 'personal-assistant' APP_PORT = '6...

에러 분석 에이전트의 가장 핵심적인 기능은 수정 코드를 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...

서버 에러 로그를 LLM이 분석해서 Slack으로 원인과 수정 코드를 보내주는 시스템을 만들고 있었다. LLM이 단순히 로그를 받아서 답을 내는 게 아니라, 필요하면 직접 소스 파일을 검색해가며 분석하는 에이전트 구조였다. 처음엔 이 루프를 직접 구현했는데, 문제가 생겼다. 직접 구현한 에이전트 루프 LLM 에이전트의 동작 방식은 단순하다. 1....

개인 프로젝트에서 RAG(Retrieval-Augmented Generation)를 구축하면서 벡터 검색만으로는 해결되지 않는 문제를 겪었다. LLM이 에러 스택 트레이스를 분석할 때 UserService, findById 같은 정확한 클래스명·메서드명을 언급하는데, 벡터 검색이 그 파일을 상위에 올려놓지 못하는 경우가 있었다. 이 문제를 BM25와...