<div id="readability-page-1" class="page"><div aria-label="Content">
                    
            
                    <p>팀 내에서 생성형 AI 를 활용한 사례를 공유합니다.</p>
            
                    
                    <ul id="markdown-toc">
  <li><a href="#왜-에러-로그는-항상-늦게-처리되는가" id="markdown-toc-왜-에러-로그는-항상-늦게-처리되는가">왜 에러 로그는 항상 늦게 처리되는가?</a></li>
  <li><a href="#에러-로그-분석-자동화-우리는-이렇게-구성했습니다" id="markdown-toc-에러-로그-분석-자동화-우리는-이렇게-구성했습니다">에러 로그 분석 자동화, 우리는 이렇게 구성했습니다.</a>    <ul>
      <li><a href="#llm-응답-품질을-높이기-위한-반복-실험" id="markdown-toc-llm-응답-품질을-높이기-위한-반복-실험">LLM 응답 품질을 높이기 위한 반복 실험</a></li>
      <li><a href="#mcp란-무엇인가-우리는-왜-jarvis-를-투명인간-취급하였을까" id="markdown-toc-mcp란-무엇인가-우리는-왜-jarvis-를-투명인간-취급하였을까">MCP란 무엇인가? 우리는 왜 <strong>Jarvis</strong> 를 투명인간 취급하였을까</a></li>
    </ul>
  </li>
  <li><a href="#다음-목표는-지나간-해결-방법-학습과-미지의-영역" id="markdown-toc-다음-목표는-지나간-해결-방법-학습과-미지의-영역">다음 목표는? 지나간 해결 방법 학습과 미지의 영역</a></li>
  <li><a href="#자동-분석이-만든-변화" id="markdown-toc-자동-분석이-만든-변화">자동 분석이 만든 변화</a></li>
  <li><a href="#이-글을-마치며" id="markdown-toc-이-글을-마치며">이 글을 마치며</a></li>
</ul>


<h2 id="왜-에러-로그는-항상-늦게-처리되는가">왜 에러 로그는 항상 늦게 처리되는가?</h2>
<p><br>
안녕하세요. 컬리의 배송 시스템을 맡고 있는 딜리버리프로덕트의 김성준입니다.</p>

<div><p>개발자인 우리는 하루하루 개발을 하다 보면 수많은 에러 로그와 마주치게 됩니다. 이 로그들은 마치 복잡한 숲 속에서 길을 안내하는 작은 이정표 같습니다. 그러나 문제는, 그 이정표가 흐릿하거나 때로는 아예 보이지 않는다는 데 있었습니다. "에러났어요!"라는 메시지를 보는 순간, 우리는 익숙한 길 위로 다시 돌아가게 됩니다. 로그를 찾고, 읽고, 해석하고, 대책을 마련하는 긴 여정을 반복하면서 말이죠. 마치 어딘가로 떠나는 길 위에서 되풀이되는 지루한 습관처럼.
</p></div>
<figure>
    <img src="http://thefarmersfront.github.io/post-img/2025-delivery-jarvis-story/jarvis_01.png" alt="에러 메세지">
    <figcaption>© 2025. Kurly. All rights reserved.</figcaption>
</figure>


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

<div><p>그래서 우리는 문득 생각했습니다.
</p><p>


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


그렇게 해서 우리는 에러 분석을 도와줄 작고 현명한 비서를 만들기로 했습니다. 그 비서에게는 특별한 이름을 붙였죠. 아이언맨의 현명한 조수에서 영감을 받아, <strong>“Jarvis”</strong> 라는 이름을 말입니다.
</p></div>
<figure>
    <img src="http://thefarmersfront.github.io/post-img/2025-delivery-jarvis-story/jarvis_02.png" alt="아이언맨의 자비스">
    <figcaption>이미지 출처: https://enterprise.kt.com/bt/dxstory/1057.do</figcaption>
</figure>


<div><p>목표는 간단했습니다. 에러가 발생하면 자동으로 로그를 분석하고, 신속히 해결 방안을 안내하는 것이었죠.
</p></div>
<h2 id="에러-로그-분석-자동화-우리는-이렇게-구성했습니다">에러 로그 분석 자동화, 우리는 이렇게 구성했습니다.</h2>
<p><br>
비서에게 역할과 이름을 정해준 다음, 우리는 분석 자동화를 어떻게 구현할지 고민하기 시작했습니다. 가장 쉬운 방법은 구글이나 Stack Overflow에서 찾아 결과를 전달하는 것이었지만, 그 방법에는 몇 가지 문제가 있었습니다.</p>

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

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

<div><p>이러한 기대를 가지고 만든 에러 분석 자동화 시스템, <strong>Jarvis</strong> 는 다음과 같은 핵심 기능을 수행합니다.
</p></div>
<ol>
  <li>
    <p><strong>알림 수신</strong>: Slack 으로부터 에러 알림을 받습니다.
<br></p>
  </li>
  <li>
    <p><strong>에러 분석</strong>: Gemini와 같은 생성형 AI를 통해 첨부된 에러 메세지의 원인을 유추합니다.
<br></p>
  </li>
  <li>
    <div><p><strong>조치 가이드 제공</strong>: 분석 결과를 바탕으로 적절한 대응 방법을 제안합니다.
</p></div>
  </li>
</ol>

<div><p><strong>Jarvis</strong> 는 Slack 으로부터 받은 에러 알림의 내용을 바탕으로 Gemini 에게 분석을 요청하고, 분석 내용을 다시 Slack 으로 전달하는 흐름을 가지고 있습니다. 이를 위해 우리는 Slack의 Event Subscriptions 와 Gemini 연동을 위한 LangChain 등의 기술을 도입했고, 그 구조는 간략히 다음과 같습니다.
</p></div>
<figure>
    <img src="http://thefarmersfront.github.io/post-img/2025-delivery-jarvis-story/jarvis_03.png" alt="프로세스 흐름도">
    <figcaption>© 2025. Kurly. All rights reserved.</figcaption>
</figure>

<h3 id="llm-응답-품질을-높이기-위한-반복-실험">LLM 응답 품질을 높이기 위한 반복 실험</h3>
<div><p>
처음에는 그저 <strong>Jarvis</strong> 에게 "이 에러를 분석해 해결 방법을 알려줘"라고만 요청했습니다. 그러나 결과는 기대와는 거리가 멀었습니다. 요약은 부정확했고, 중요한 키워드를 놓치거나, 때로는 "요청을 이해할 수 없습니다"라는 건조한 답변만 돌아왔죠.
</p></div>
<figure>
    <img src="http://thefarmersfront.github.io/post-img/2025-delivery-jarvis-story/jarvis_04.png" alt="자비스의 잘못된 대답">
    <figcaption>© 2025. Kurly. All rights reserved.</figcaption>
</figure>


<div><p>그래서 우리는 프롬프트 자체를 다시 생각하기 시작했습니다. <strong>Jarvis</strong> 에게 너무 모호한 질문을 던지고 있던 것은 아닐까 하는 생각이 들었죠. 누군가에게 부탁할 때처럼 구체적으로 요청하기 위해 우리는 다섯 가지의 규칙을 정했습니다.
</p></div>
<ol>
  <li>
    <p>구체적이고 명확하게 작성할 것.
<br></p>
  </li>
  <li>
    <p>목표 대상과 환경을 명확히 할 것.
<br></p>
  </li>
  <li>
    <p>AI가 맥락을 이해할 수 있도록 문맥을 제공할 것.
<br></p>
  </li>
  <li>
    <p>구체적인 예시를 활용할 것.
<br></p>
  </li>
  <li>
    
  </li>
</ol>

<div><p>이러한 규칙을 기반으로 우리는 프롬프트를 재구성했습니다. "역할 정의", "에러 확인", "중요도 평가", "발생 원인", "조치 방안" 등의 명확한 카테고리를 설정해, <strong>Jarvis</strong> 가 원하는 답을 정확히 할 수 있도록 다듬었습니다.
</p></div>
<figure>
    <img src="http://thefarmersfront.github.io/post-img/2025-delivery-jarvis-story/jarvis_05.png" alt="수정된 자비스의 대답">
    <figcaption>© 2025. Kurly. All rights reserved.</figcaption>
</figure>


<div><p>몇 번의 시행착오 끝에, <strong>Jarvis</strong> 는 점점 숙련된 '시니어 개발자'처럼 대답하기 시작했습니다. 여전히 완벽하진 않지만, 에러 메시지의 원인과 해결 방안을 자신만의 언어로 설명할 수 있게 되었습니다.
</p></div>
<h3 id="mcp란-무엇인가-우리는-왜-jarvis-를-투명인간-취급하였을까">MCP란 무엇인가? 우리는 왜 <strong>Jarvis</strong> 를 투명인간 취급하였을까</h3>
<p><br>
<strong>Jarvis</strong> 를 실무에 적용한 지 시간이 지나면서, 우리는 어느 순간부터 <strong>Jarvis</strong> 의 제안을 잘 참고하지 않는다는 것을 깨달았습니다. 이토록 열심히 만들었음에도 왜 <strong>Jarvis</strong> 를 마치 존재하지 않는 사람처럼 취급했을까 하는 생각에 우리는 다시 리서치를 진행했습니다.</p>


<ul>
  <li>
    <p>제공된 정보의 부족으로 기초적인 해결 방안만 제시됨.
<br></p>
  </li>
  <li>
    <div><p>제시된 해결 방안이 실제 업무에 적합하지 않음.
</p></div>
  </li>
</ul>

<div><p>어찌보면 지극히 당연한 내용이었지만, 피부에 와닿기엔 너무나 가려져있던 진실이었습니다. 한마디로 <strong>Jarvis</strong> 는 필요한 정보를 충분히 받지 못하고 있었습니다. 에러 메시지만 가지고서는 실제 코드나 비즈니스 로직을 파악하기 어려웠던 것입니다. 이제 <strong>Jarvis</strong> 가 무엇을 더 원하는지 알게 되었으니 <strong>Jarvis</strong> 는 더이상 투명이간이 아닌 팀원으로써 같이 일하는 개발자로 변모하기 시작할 겁니다. 
</p></div>
<ol>
  <li>
    <p><strong>전체적인 에러 메세지</strong>: Datadog 에 적재된 에러 메세지 전체를 전달.
<br></p>
  </li>
  <li>
    <div><p><strong>관련 비지니스 로직</strong>: Git 저장소의 관련 소스 코드 일부를 전달.
</p></div>
  </li>
</ol>

<div><p>에러가 발생하면 전체적인 에러 메세지와 관련된 소스 코드를 보고 원인을 분석하는 것처럼 <strong>Jarvis</strong> 에게 관련 정보를 추가로 전달하기 위해 <strong>MCP(Model Context Protocol)</strong> 를 도입하기로 하였습니다.
</p></div>
<figure>
    <img src="http://thefarmersfront.github.io/post-img/2025-delivery-jarvis-story/jarvis_06.png" alt="MCP 연결">
    <figcaption>© 2025. Kurly. All rights reserved.</figcaption>
</figure>


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

<div><p>물론 <strong>MCP</strong> 라는 강력한 무기를 쥐어주기 전에, 우리는 <strong>Jarvis</strong> 가 필요로 하는 에러 메시지 형식을 수정하고, 추가적인 속성과 코드 주석을 정비하는 작업도 함께 진행했습니다. 이 모든 준비를 마친 후, 이제 <strong>Jarvis</strong> 에게 다시 한번 분석을 요청할 수 있게 되었습니다. 이렇게 하여 <strong>Jarvis</strong> 는 단순히 알림만 전달하는 존재에서 벗어나 팀원들과 함께 고민하고 해결 방안을 논의하는 진정한 개발자의 모습을 갖추게 되었습니다.
</p></div>
<figure>
    <img src="http://thefarmersfront.github.io/post-img/2025-delivery-jarvis-story/jarvis_07.png" alt="보다 정확한 자비스의 대답">
    <figcaption>© 2025. Kurly. All rights reserved.</figcaption>
</figure>


<div><p>이러한 준비를 마치고 며칠이 지난 어느 날, 실제 운영 환경에서 문제가 발생했습니다. <strong>Jarvis</strong> 는 우리보다 한발 앞서 이를 분석하여 정확한 진단과 해결 방안을 우리에게 제시했습니다.
</p></div>
<figure>
    <img src="http://thefarmersfront.github.io/post-img/2025-delivery-jarvis-story/jarvis_08.png" alt="실제 발생한 에러를 분석한 결과">
    <figcaption>© 2025. Kurly. All rights reserved.</figcaption>
</figure>


<div><p>덕분에 우리는 더욱 빠르게 대응할 수 있었고, 이 일을 계기로 <strong>Jarvis</strong> 의 진정한 가치를 다시 한번 확인하게 되었습니다.
</p></div>
<figure>
    <img src="http://thefarmersfront.github.io/post-img/2025-delivery-jarvis-story/jarvis_09.png" alt="자비스의 의견대로 원인이 확인됨">
    <figcaption>© 2025. Kurly. All rights reserved.</figcaption>
</figure>

<h2 id="다음-목표는-지나간-해결-방법-학습과-미지의-영역">다음 목표는? 지나간 해결 방법 학습과 미지의 영역</h2>
<p><br>
<strong>Jarvis</strong> 는 이제 충분한 정보를 가지고 보다 나은 분석을 할 수 있게 되었습니다. 하지만 여기서 멈출 생각은 없습니다. <strong>Jarvis</strong> 는 무한한 가능성을 가진 존재이기 때문입니다. 그 가능성을 제대로 키우고 성장시키는 일은 오롯이 우리의 책임이죠.</p>

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

<div><p>그 다음 단계는 아직 생각해보지 않았습니다. 미지의 영역이란 늘 우리 앞에 남겨져 있는 법이니까요. 그곳엔 아직 보지 못한 새로운 가능성이 숨어있을지도 모르겠다는 생각을 하며, 조금 더 천천히 고민해 보기로 합니다.
</p></div>
<h2 id="자동-분석이-만든-변화">자동 분석이 만든 변화</h2>
<p><br>
처음 <strong>Jarvis</strong> 를 만들었을 때는 단지 호기심에 의한 실험 정도로 생각했습니다. 하지만 실제 팀에 적용해본 한 달 동안 많은 변화가 있었습니다.</p>

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

<div><p>물론 <strong>Jarvis</strong> 가 모든 질문에 완벽히 대답할 수 있는 것은 아닙니다. 과거의 에러 대응 이력이나 로그 데이터가 아직 충분히 축적되지 않았기 때문입니다. 하지만 우리는 <strong>Jarvis</strong> 가 점점 더 현명한 비서가 될 수 있도록 데이터를 축적하고 학습시키는 중입니다. 언젠가는 아이언맨의 <strong>Jarvis</strong> 처럼 더 정확하고 믿음직스러운 비서가 되어줄 것을 기대하면서 말이죠.
</p></div>
<h2 id="이-글을-마치며">이 글을 마치며</h2>
<p><br>
개발이라는 것은 언제나 예상하지 못한 문제를 우리에게 던져줍니다. 그 문제를 해결하는 과정에서 배운 지식과 경험도 소중하지만, 함께 고민하고 아이디어를 공유해준 팀원들이 없었더라면 결코 이만큼의 성과를 얻지 못했을 것이기에 진심으로 감사의 말을 전하며. 시간을 내어 읽어주신 분들도 감사합니다.</p>

                </div></div>

컬리 기술 블로그

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

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

댓글