운영 로그에서 문제를 찾고 AI 분석으로 연결하기

사용자 신고 후에야 장애를 조사하던 환경에서 로그 수집·요청 추적 기반을 만들고, 로그와 소스를 함께 분석하는 AI 서비스로 확장했습니다.

<aside>

로그와 소스를 연결한 분석 서비스를 동료들의 장애 조사에 활용하고 있습니다.

기간: 2026.05 – 현재

기술: Java, MDC, ELK, Python, FastAPI, PostgreSQL, Ollama, Claude API, Qwen·Gemma

개발 검증: Python 코드는 pytest로, 화면 JavaScript는 Vitest로 검증하는 테스트를 구성했습니다.

현재 분석 흐름

근거 대조와 모델의 의견을 구분하고, 적용 여부는 개발자의 검토와 테스트를 거쳐 결정합니다.

로그 형식이 제각각이고 모니터링 기반도 부족해, 사용자 신고가 들어온 뒤 관련 로그를 찾아 원인을 조사해야 했습니다.

백엔드에 MDC 필터와 요청 추적 ID(trace ID)를 적용하고, ELK 기반 중앙 수집·조회 환경을 구축했습니다. 같은 요청 안의 기록을 연결하고 Kibana에서 HTTP 응답, 느린 요청과 SQL 호출을 확인할 수 있도록 했습니다.

SQL 호출 정보는 관련 소스의 매퍼 위치를 찾는 데 활용했습니다. 로그에서 의심되는 호출을 확인한 뒤 코드 검토로 이어갈 수 있는 기반을 만든 것입니다.

반복 오류나 SQL 호출을 로그와 코드 양쪽에서 검토할 수 있도록 분석 서비스를 개발했습니다. 로그를 전처리하고 관련 소스 위치와 연결한 뒤, AI가 문제 설명과 수정 방향을 제안하도록 구성했습니다.

단계	역할
로그 수집·정리	백엔드 요청·오류·SQL 기록을 수집하고 조사에 필요한 형태로 정리
소스 연결	호출 정보와 MyBatis 매퍼 등 실제 코드의 위치를 연결
AI 제안	로그·소스 맥락을 바탕으로 문제 설명과 수정 방향 제안
근거 대조·추가 검토	소스·호출 참조를 입력 근거와 대조하고 별도 모델의 의견을 함께 표시
개발자 판단	분석 리포트를 보고 업무상 필요한 동작인지 확인한 뒤 수정·테스트 여부 결정

AI가 그럴듯한 설명을 만들어도 실제 로그·소스에 연결되지 않으면 조사 방향을 잘못 잡을 수 있습니다.

참조 근거 대조: 제안이 가리키는 소스 위치·SQL 호출 정보가 조사 근거와 연결되는지 확인하고, 연결되지 않는 결과를 구분했습니다. 패턴 발생 횟수는 실제 로그 집계로 교정하고 근거가 없는 패턴은 제외했습니다.
별도 모델 검토: 다른 모델이 제안과 요약을 다시 검토해 의견을 남기도록 했습니다.
검토 상태 표시: 근거 부족이나 모델 실패를 개발자가 확인할 수 있도록 구분했습니다.