우리 팀에도 Jarvis 가 생겼다 – 생성형 AI 로 만든 에러 분석가 이야기

팀 내에서 생성형 AI 를 활용한 사례를 공유합니다.

김성준 게시 날짜: 2025.07.01.

• 왜 에러 로그는 항상 늦게 처리되는가?
• 에러 로그 분석 자동화, 우리는 이렇게 구성했습니다.
  • LLM 응답 품질을 높이기 위한 반복 실험
  • MCP란 무엇인가? 우리는 왜 Jarvis 를 투명인간 취급하였을까
• 다음 목표는? 지나간 해결 방법 학습과 미지의 영역
• 자동 분석이 만든 변화
• 이 글을 마치며

왜 에러 로그는 항상 늦게 처리되는가?

안녕하세요. 컬리의 배송 시스템을 맡고 있는 딜리버리프로덕트의 김성준입니다.

개발자인 우리는 하루하루 개발을 하다 보면 수많은 에러 로그와 마주치게 됩니다. 이 로그들은 마치 복잡한 숲 속에서 길을 안내하는 작은 이정표 같습니다. 그러나 문제는, 그 이정표가 흐릿하거나 때로는 아예 보이지 않는다는 데 있었습니다. "에러났어요!"라는 메시지를 보는 순간, 우리는 익숙한 길 위로 다시 돌아가게 됩니다. 로그를 찾고, 읽고, 해석하고, 대책을 마련하는 긴 여정을 반복하면서 말이죠. 마치 어딘가로 떠나는 길 위에서 되풀이되는 지루한 습관처럼.

로그를 찾는 데만 5분, 10분, 때로는 그 이상이 걸리곤 합니다. 설령 로그를 발견하더라도, 그 내용을 이해하고 정확히 대처하는 데는 더 많은 시간이 필요합니다. 서비스에 익숙하지 않은 팀원들이나 이제 막 개발에 발을 디딘 주니어 개발자들에게는 이 여정이 더욱 길고 험난합니다. 그렇게 시간이 흐르다 보면 시스템의 안정성이라는 것은 점차 흔들리고 맙니다.

그래서 우리는 문득 생각했습니다.


"에러 메시지가 뜨는 순간, 바로 그 해결 방법도 함께 떠오르면 얼마나 좋을까?"


그렇게 해서 우리는 에러 분석을 도와줄 작고 현명한 비서를 만들기로 했습니다. 그 비서에게는 특별한 이름을 붙였죠. 아이언맨의 현명한 조수에서 영감을 받아, “Jarvis” 라는 이름을 말입니다.

목표는 간단했습니다. 에러가 발생하면 자동으로 로그를 분석하고, 신속히 해결 방안을 안내하는 것이었죠.

에러 로그 분석 자동화, 우리는 이렇게 구성했습니다.

비서에게 역할과 이름을 정해준 다음, 우리는 분석 자동화를 어떻게 구현할지 고민하기 시작했습니다. 가장 쉬운 방법은 구글이나 Stack Overflow에서 찾아 결과를 전달하는 것이었지만, 그 방법에는 몇 가지 문제가 있었습니다.

첫째, 정확성의 문제였습니다. 우리 시스템에 특화된 에러는 일반적인 검색으로 정확히 해석되지 않는 경우가 많았습니다. 둘째, 시간 소모였습니다. 검색 결과를 다시 확인하고 정확성을 검증하는 데 또다시 많은 시간이 걸렸습니다.

이러한 문제를 해결할 방법을 고민하던 중, 우리는 Gemini 같은 생성형 AI의 가능성에 주목하게 되었습니다. AI가 에러 로그를 읽고 분석하여 적절한 조치를 제안한다면, 우리의 문제를 더 쉽게 해결할 수 있을 거라 기대했습니다.

이러한 기대를 가지고 만든 에러 분석 자동화 시스템, Jarvis 는 다음과 같은 핵심 기능을 수행합니다.

1. 알림 수신: Slack 으로부터 에러 알림을 받습니다.
   

2. 에러 분석: Gemini와 같은 생성형 AI를 통해 첨부된 에러 메세지의 원인을 유추합니다.
   

3. 조치 가이드 제공: 분석 결과를 바탕으로 적절한 대응 방법을 제안합니다.
   
   

Jarvis 는 Slack 으로부터 받은 에러 알림의 내용을 바탕으로 Gemini 에게 분석을 요청하고, 분석 내용을 다시 Slack 으로 전달하는 흐름을 가지고 있습니다. 이를 위해 우리는 Slack의 Event Subscriptions 와 Gemini 연동을 위한 LangChain 등의 기술을 도입했고, 그 구조는 간략히 다음과 같습니다.

LLM 응답 품질을 높이기 위한 반복 실험

처음에는 그저 Jarvis 에게 "이 에러를 분석해 해결 방법을 알려줘"라고만 요청했습니다. 그러나 결과는 기대와는 거리가 멀었습니다. 요약은 부정확했고, 중요한 키워드를 놓치거나, 때로는 "요청을 이해할 수 없습니다"라는 건조한 답변만 돌아왔죠.

그래서 우리는 프롬프트 자체를 다시 생각하기 시작했습니다. Jarvis 에게 너무 모호한 질문을 던지고 있던 것은 아닐까 하는 생각이 들었죠. 누군가에게 부탁할 때처럼 구체적으로 요청하기 위해 우리는 다섯 가지의 규칙을 정했습니다.

1. 구체적이고 명확하게 작성할 것.
   

2. 목표 대상과 환경을 명확히 할 것.
   

3. AI가 맥락을 이해할 수 있도록 문맥을 제공할 것.
   

4. 구체적인 예시를 활용할 것.
   

5. 예/아니오 대신 개방형 질문을 할 것.
   
   

이러한 규칙을 기반으로 우리는 프롬프트를 재구성했습니다. "역할 정의", "에러 확인", "중요도 평가", "발생 원인", "조치 방안" 등의 명확한 카테고리를 설정해, Jarvis 가 원하는 답을 정확히 할 수 있도록 다듬었습니다.

몇 번의 시행착오 끝에, Jarvis 는 점점 숙련된 '시니어 개발자'처럼 대답하기 시작했습니다. 여전히 완벽하진 않지만, 에러 메시지의 원인과 해결 방안을 자신만의 언어로 설명할 수 있게 되었습니다.

MCP란 무엇인가? 우리는 왜 Jarvis 를 투명인간 취급하였을까

Jarvis 를 실무에 적용한 지 시간이 지나면서, 우리는 어느 순간부터 Jarvis 의 제안을 잘 참고하지 않는다는 것을 깨달았습니다. 이토록 열심히 만들었음에도 왜 Jarvis 를 마치 존재하지 않는 사람처럼 취급했을까 하는 생각에 우리는 다시 리서치를 진행했습니다.

조사 결과, 이유는 의외로 단순했습니다.

• 제공된 정보의 부족으로 기초적인 해결 방안만 제시됨.
  

• 제시된 해결 방안이 실제 업무에 적합하지 않음.
  
  

어찌보면 지극히 당연한 내용이었지만, 피부에 와닿기엔 너무나 가려져있던 진실이었습니다. 한마디로 Jarvis 는 필요한 정보를 충분히 받지 못하고 있었습니다. 에러 메시지만 가지고서는 실제 코드나 비즈니스 로직을 파악하기 어려웠던 것입니다. 이제 Jarvis 가 무엇을 더 원하는지 알게 되었으니 Jarvis 는 더이상 투명이간이 아닌 팀원으로써 같이 일하는 개발자로 변모하기 시작할 겁니다.

1. 전체적인 에러 메세지: Datadog 에 적재된 에러 메세지 전체를 전달.
   

2. 관련 비지니스 로직: Git 저장소의 관련 소스 코드 일부를 전달.
   
   

에러가 발생하면 전체적인 에러 메세지와 관련된 소스 코드를 보고 원인을 분석하는 것처럼 Jarvis 에게 관련 정보를 추가로 전달하기 위해 MCP(Model Context Protocol) 를 도입하기로 하였습니다.

이를 위해 Jarvis 의 내부 구조도 다소 변경할 필요가 있었습니다. GitHub 과 Datadog 에서 얻은 데이터를 MCP 로 연결해 Jarvis 가 더 풍부한 맥락을 이해할 수 있도록 만든 것이죠.

물론 MCP 라는 강력한 무기를 쥐어주기 전에, 우리는 Jarvis 가 필요로 하는 에러 메시지 형식을 수정하고, 추가적인 속성과 코드 주석을 정비하는 작업도 함께 진행했습니다. 이 모든 준비를 마친 후, 이제 Jarvis 에게 다시 한번 분석을 요청할 수 있게 되었습니다. 이렇게 하여 Jarvis 는 단순히 알림만 전달하는 존재에서 벗어나 팀원들과 함께 고민하고 해결 방안을 논의하는 진정한 개발자의 모습을 갖추게 되었습니다.

이러한 준비를 마치고 며칠이 지난 어느 날, 실제 운영 환경에서 문제가 발생했습니다. Jarvis 는 우리보다 한발 앞서 이를 분석하여 정확한 진단과 해결 방안을 우리에게 제시했습니다.

덕분에 우리는 더욱 빠르게 대응할 수 있었고, 이 일을 계기로 Jarvis 의 진정한 가치를 다시 한번 확인하게 되었습니다.

다음 목표는? 지나간 해결 방법 학습과 미지의 영역

Jarvis 는 이제 충분한 정보를 가지고 보다 나은 분석을 할 수 있게 되었습니다. 하지만 여기서 멈출 생각은 없습니다. Jarvis 는 무한한 가능성을 가진 존재이기 때문입니다. 그 가능성을 제대로 키우고 성장시키는 일은 오롯이 우리의 책임이죠.

우선 과거 팀원들이 문제를 해결하기 위해 나누었던 Slack 의 대화 내용을 Jarvis 가 학습할 수 있도록 하여, 보다 깊이 있고 현장감 있는 해결책을 제시할 수 있도록 개선할 계획입니다. 시간이 지날수록 팀의 경험과 지혜를 전달해주면, Jarvis 역시 더욱 정확하고 현명한 판단을 내릴 수 있게 되겠지요.

그 다음 단계는 아직 생각해보지 않았습니다. 미지의 영역이란 늘 우리 앞에 남겨져 있는 법이니까요. 그곳엔 아직 보지 못한 새로운 가능성이 숨어있을지도 모르겠다는 생각을 하며, 조금 더 천천히 고민해 보기로 합니다.

자동 분석이 만든 변화

처음 Jarvis 를 만들었을 때는 단지 호기심에 의한 실험 정도로 생각했습니다. 하지만 실제 팀에 적용해본 한 달 동안 많은 변화가 있었습니다.

"로그 좀 확인해볼게요"라는 말을 자주 듣던 Slack 채널에서는 이제 "아, 이 문제는 XX 부분이 문제인 것 같아요"라는 구체적인 말이 빠르게 등장하기 시작했습니다. 에러에 대한 대응 시간이 크게 줄어들었고, 팀원들은 더 이상 로그를 찾아 헤매느라 많은 시간을 허비하지 않게 되었습니다.

물론 Jarvis 가 모든 질문에 완벽히 대답할 수 있는 것은 아닙니다. 과거의 에러 대응 이력이나 로그 데이터가 아직 충분히 축적되지 않았기 때문입니다. 하지만 우리는 Jarvis 가 점점 더 현명한 비서가 될 수 있도록 데이터를 축적하고 학습시키는 중입니다. 언젠가는 아이언맨의 Jarvis 처럼 더 정확하고 믿음직스러운 비서가 되어줄 것을 기대하면서 말이죠.

이 글을 마치며

개발이라는 것은 언제나 예상하지 못한 문제를 우리에게 던져줍니다. 그 문제를 해결하는 과정에서 배운 지식과 경험도 소중하지만, 함께 고민하고 아이디어를 공유해준 팀원들이 없었더라면 결코 이만큼의 성과를 얻지 못했을 것이기에 진심으로 감사의 말을 전하며. 시간을 내어 읽어주신 분들도 감사합니다.