안녕하세요, 와치텍입니다. 이번 글에서는 우리 회사만의 AIOps 구현을 위해 꼭 짚고 넘어가야 할 도구, RAG에 대해 이야기해 보려고 합니다.
1. RAG는 도대체 무엇일까?
검색과 생성형 AI의 만남
RAG는 Retrieval-Augmented Generation의 줄임말로, 직역하면 검색이 더해진 생성이라는 뜻입니다. 이름만 들으면 다소 어렵게 느껴지지만, 한 줄로 정리하면 이렇게 말할 수 있습니다.
" 네 머릿속 기억만 믿지 말고 우리 문서도 같이 찾아보고 대답해줘. "
일반적인 생성형 AI는 이미 학습해 둔 데이터 안에서만 답을 만듭니다. 그래서 상식적인 질문에는 꽤 잘 대답하지만, 우리 회사 내부 매뉴얼이나 특정 고객사만의 운영 특성처럼 외부에 공개되지 않은 정보에 대해서는 대답하기 어렵습니다. 또한, 말은 그럴듯하게 하는데 실제로는 근거가 부족한, 이른바 환각(Hallucination) 현상이 발생할 위험도 있습니다.
RAG는 이런 한계를 줄이기 위해, 사용자의 질문을 먼저 검색 시스템으로 보내 관련 문서, 이력, 매뉴얼, 리포트 등을 찾아냅니다. 그리고 그 검색 결과를 생성형 AI에게 함께 전달해 이 자료들을 참고해서 답을 만들도록 제한합니다. 이렇게 되면 AI가 답을 만들 때 단순히 추측에 의존하는 것이 아니라 실제 사내 지식을 근거로 삼게 되기 때문에, 답변의 정확도와 신뢰도가 함께 높아집니다.
정리하자면 RAG는 완전히 새로운 마법 같은 기술이라기보다는, 검색과 생성형 AI를 똑똑하게 조합한 아키텍처라고 보는 것이 더 가깝습니다.
2. AIOps에서 RAG가 필요한 이유
알람 이후 '그래서 뭐 하지?'를 해결하는 열쇠
이미 수많은 지식이 시스템 곳곳에 쌓여 있는 것이 요즘 운영 환경의 현실입니다. 장비별 운영 매뉴얼, 장애 조치·처리 이력, 과거 장애 발생 내역, 고객사 운영 특성, 패치 내역까지 모두 합치면 사실상 고객사마다 운영 백과사전이 하나씩 있는 셈입니다. 문제는 이 지식들이 파일 서버, 개인 PC 폴더, 메신저 등 여러 곳에 흩어져 있어서, 막상 문제가 발생했을 때 바로 꺼내 쓰기가 쉽지 않다는 점입니다.
AIOps는 지금까지 주로 자동화에 초점이 맞춰져 있었습니다. 로그와 메트릭, 이벤트를 분석해 이상 징후를 감지하고, 알람에서 티켓까지 그 과정을 이어주는 역할을 중심으로 발전해 왔습니다. 이상 상황을 빠르게 발견하고, 중복 알람을 줄여주는 것까지는 AIOps만으로도 어느 정도 해결이 가능합니다.
하지만 정작 운영자 입장에서 가장 궁금한 부분은 그 다음입니다.
" 알람은 떴고, 이상이 있다는 것도 알겠는데, 지금부터 무엇을 해야하지? "
바로 이 지점에서 RAG가 힘을 발휘합니다. AIOps가 어디에서 이상이 났는지 알려준다면, RAG는 그 순간 과거에 비슷한 장애가 있었는지, 그때는 어떻게 해결했는지, 매뉴얼에는 어떤 절차가 적혀 있는지를 대신 찾아줍니다. 그리고 그 내용을 한 번에 정리해 운영자에게 보여줄 수 있습니다.
조금 과장해서 표현하면, AIOps는 이상 징후를 발견하는 눈에 가깝고, RAG는 그 상황에서 어떤 행동을 해야 하는지 알려주는 뇌에 가깝습니다. 두 가지가 함께 움직일 때, 모니터링 알람은 단순한 경고 문구에서 한 단계 더 나아가 실질적인 액션으로 이어지는 가이드가 됩니다.
3. AIOps와 RAG는 어떻게 함께 움직일까
알람에서 조치 제안까지 하나의 흐름으로
통합 모니터링과 AIOps, 그리고 RAG가 함께 했을 때 그 시너지는 훨씬 커집니다. EMS를 통해 각종 장비와 서비스에서 발생하는 로그와 이벤트, 지표를 수집하고, AIOps 엔진이 이를 분석해 이상 징후를 찾아냅니다. 이 단계에서는 어떤 알람들이 서로 연관되어 있는지, 반복해서 나타나는 패턴은 무엇인지, 특정 시점 이후로 급격히 변한 지표는 없는지 등을 중심으로 머신 관점의 분석이 이뤄집니다. 여기까지가 우리가 익숙하게 생각하는 AIOps의 역할입니다.
와치올에서 제공하는 AIOps 내 로그 자동 패턴 분류
그 다음 AIOps가 이상하다고 판단한 이벤트를 넘겨주면, RAG는 그 정보를 토대로 지식 저장소를 검색합니다. 과거에 비슷한 알람이 발생했을 때의 장애 보고서, 해당 장비나 서비스에 대한 운영 매뉴얼, 관련된 변경 이력이나 릴리즈 노트, 고객사별로 정리해 둔 운영 특성까지 함께 찾아볼 수 있습니다. 그리고 그중 지금 상황과 가장 유사한 내용들을 골라 요약하고, 이 유형의 장애는 과거에 어떤 원인으로 자주 발생했는지, 어떤 순서로 조치했을 때 해결된 사례가 많았는지 정리해 운영자에게 보여줍니다.
이렇게 되면 통합 모니터링 화면은 단순히 빨간색 알람만 잔뜩 보여주는 곳이 아니라, 알람 → 분석 → 조치 제안까지 이어지는 일종의 지능형 콘솔이 됩니다. 운영자는 한 화면 안에서 현재 어떤 문제가 생겼는지뿐 아니라, 그 문제를 해결하기 위한 구체적인 힌트와 참고 문서까지 한 번에 확인할 수 있습니다. 더 나아가 이런 흐름이 어느 정도 표준화되면, 일부 장애 유형에 대해서는 반자동 조치나 자동 복구 시나리오까지 연결할 수 있는 기반도 자연스럽게 마련됩니다.
4. RAG와 AIOps 결합이 만들어 내는 변화
적은 데이터로 시작하고, 더 빨리, 더 균일하게
와치올 RAG 아키텍쳐
① 데이터가 많지 않아도 시작할 수 있다
기존 AI 프로젝트는 보통 수만 건의 학습 데이터가 필요하다고 이야기하지만, 실제 현장에서 그렇게까지 데이터를 준비하고 학습시키는 것은 쉽지 않습니다.
반면 RAG는 이미 가지고 있는 운영 매뉴얼, 장애 보고서, 처리 이력, 내부 자료 같은 정보를 그대로 활용합니다. 새롭게 정답 데이터를 만들어서 학습시키기보다, 지금 있는 문서를 잘 정리해서 검색하고, 그걸 AI가 읽고 답하도록 만드는 방식에 가깝기 때문에 초기 진입 장벽이 훨씬 낮습니다.
② 사람에 따라 대응 수준이 크게 달라지지 않는다
그동안은 알람이 떠도 이를 어떻게 해석하고 어떤 순서로 대응할지는 대부분 담당 엔지니어의 경험에 의존했습니다.
하지만 RAG가 과거 사례와 문서를 기반으로 조치 방향을 제안해 주면, 경력이 짧은 운영자라도 화면에 제시된 가이드를 따라가면서 어느 정도 숙련된 엔지니어에 가까운 수준으로 대응할 수 있게 됩니다. 자연스럽게 팀 전체의 평균 대응 수준을 끌어올리는 효과로 이어집니다.
③ 세 번째 장점은 MTTR(평균 복구 시간)의 단축
장애 대응 과정에서 시간을 가장 많이 잡아먹는 부분은 단순히 문제를 인지하는 시간이 아니라, 관련 문서를 찾고 과거 사례를 뒤지는 시간인 경우가 많습니다.
통합 모니터링과 AIOps가 문제를 빠르게 드러내 준 뒤, RAG가 그 순간 필요한 지식들을 모아 보여준다면, 원인 가설을 세우고 조치 방향을 정하는 데 걸리는 시간이 크게 줄어듭니다. 알람을 보고 고민하는 시간이 짧아지는 만큼 실제 복구까지의 전체 리드타임도 자연스럽게 줄어듭니다.
④ 회사 차원에서 지식 자산을 체계적으로 쌓고 재활용하는 구조 제공
개별 엔지니어의 머릿속에만 있던 노하우가 문서와 티켓 형태로 기록되고, RAG가 이를 계속 참조하면서 실제 운영에 활용하게 되면, 시간이 지날수록 회사의 운영 지능이 축적됩니다.
여기에 더해 모든 권고와 조치에는 근거 문서가 함께 남기 때문에, 경영진·고객·감사기관을 향해서도 왜 이런 결정을 했는지 명확하게 설명할 수 있는, 이른바 설명 가능한 자동화를 구현할 수 있습니다. 이는 단순한 기술 도입을 넘어서 회사의 신뢰도와 브랜드에도 긍정적인 영향을 줄 수 있는 부분입니다.
모니터링과 AIOps만으로도 이미 많은 부분이 자동화되고 있고, 알람을 빠르게 인지하고 처리하는 환경은 충분히 만들어져 있습니다. 여기에 RAG를 더하면, 그동안 사람의 경험과 감에 의존하던 부분을 사내 문서와 장애 이력에 기반한 지식으로 채워 넣으면서 운영을 한 단계 더 고도화할 수 있습니다. 적은 데이터로도 시작할 수 있고, 기존에 쌓아 둔 문서를 그대로 활용할 수 있다는 점에서 현실적인 확장 방법이기도 합니다.
와치텍은 통합 모니터링과 AIOps에 RAG를 결합해, 알람 이후의 대응 과정까지 더 똑똑하고 더 설명 가능한 방향으로 확장해 가고 있습니다. 앞으로 실제 적용 사례와 화면까지 차근차근 공유드릴 예정이니, 많은 관심 부탁드립니다.