장애 발생 시, 복구 시간을 단축하기 위해, 내부 기술 문서와 장애 정보, 로그 정보 등의 내부 데이터를 RAG 학습하고 파이프라인에 어떻게 연동하는 사례가 있을까요?
3 Likes
질문하신 의도랑 조금 거리는 있는것 같지만, 이런 글도 도움이 되실까요 ?
https://medium.com/@b0ld8/automated-incident-response-workflows-with-n8n-and-prometheus-0fbffdabc92f
개인적으로는 모델에 많은 정보를 다 먹여? 주기보다는, “생각과 판단 그리고 플래닝이 필요한 부분을 agent로”, ”실시간으로 시스템 확인이 필요한 부분을 mcp로” 적절히 구분해서 나에게 맞는 워크플로우를 구성하는 것이 맞지 않을까 정도로 생각하고 있습니다. RAG는 아무래도 레이턴시가 있을 수 있으니…. (참.. 저도 요즘 이 주제로 고민을 하고 있긴 합니다. 
)
2 Likes
질문을 보니 10월에 클라우드브로 행사에서 봤던 장애 처리 SRE LLM 파이프라인 구축 사례가 떠오르네요~
1 Like
요즘 “RAG로 MTTR을 줄인다”는 이야기는 많지만, 실제로 현장에서 써보면 기대와 다르게 흘러가는 경우도 많아서, 이걸 어떻게 바라보는 게 현실적인지 정리해 드리는 게 더 도움이 될 것 같았습니다.
먼저 한 가지를 분명히 하고 가는 게 좋겠습니다.
장애 대응에서 RAG는 해결사라기보다는, 잘 훈련된 당직 보조 인력에 가깝습니다. 버튼 하나 누르면 복구까지 해주는 경우는 거의 없고, 대신 사람이 판단하기까지 걸리는 시간을 확실히 줄여 주는 쪽에서 효과가 납니다.
실제로 장애가 났을 때 시간을 가장 많이 잡아먹는 건, 조치 자체보다도
“이거 예전에 있었던 문제인가?”,
“관련 문서가 어디 있었지?”,
“비슷한 증상에서 누가 뭘 했더라?”
같은 기억을 복원하는 과정입니다.
RAG가 잘 작동하는 지점은 정확히 여기입니다.
그래서 현업에서 성공적으로 돌아가는 사례들을 보면, RAG를 “로그까지 다 학습한 만능 AI”처럼 쓰지 않습니다. 오히려 굉장히 보수적으로 씁니다.
데이터부터 보면, 처음부터 로그 전체를 벡터화하는 경우는 거의 없습니다. 로그는 양도 많고, 노이즈도 많아서 오히려 방해가 되는 경우가 많습니다. 대신 과거 장애 리포트나 포스트모템 문서처럼, 사람이 이미 한 번 생각을 정리해 둔 자료를 가장 중요한 데이터로 둡니다. 이때도 그냥 문서 덩어리로 넣기보다는, “현상 – 원인 – 조치 – 재발 방지”처럼 일정한 형태로 정리된 문서가 특히 잘 먹힙니다.
실시간 데이터는 보조 역할에 가깝습니다. 장애가 발생하면 최근 몇 분간의 핵심 에러 로그나 눈에 띄는 메트릭만 뽑아서, RAG 질의에 함께 붙여 줍니다. 이건 학습 데이터라기보다는, “지금 무슨 일이 벌어지고 있는지”를 설명하는 컨텍스트로 쓰입니다.
흐름은 대체로 이렇습니다.
알람이 울리면, 파이프라인이 자동으로 돌아갑니다.
현재 발생한 에러 메시지와 주요 증상을 짧게 요약하고, 그걸 검색 질의로 씁니다. 이때 LLM에게 장황한 분석을 시키지 않습니다. “지금 상황을 한두 줄로 정리해 달라” 정도가 적당합니다.
그 다음이 핵심인데, 이 요약과 에러 키워드를 가지고 과거 사례를 찾습니다. 이때 단순 벡터 검색만 쓰는 경우는 드뭅니다. 에러 코드나 서비스 이름처럼 정확히 맞아야 하는 값들은 키워드 검색을 같이 섞는 경우가 많습니다. 그래야 “비슷해 보이지만 전혀 다른 장애”가 상단에 뜨는 일을 줄일 수 있습니다.
이 과정을 거치고 나면, RAG는 보통 이런 결과를 내놓습니다.
“이런 장애가 과거에 몇 번 있었고, 당시에는 이런 조치를 했다.”
혹은
“이 증상은 이 문서의 이 부분을 먼저 보는 게 좋다.”
중요한 건, 여기서 끝입니다.
이걸 바로 실행하거나 자동 복구로 이어가는 경우는 거의 없습니다. 대신 슬랙이나 티켓에 참고 자료 형태로 붙여 줍니다. 당직 엔지니어 입장에서는 “어디부터 볼지”를 고민할 시간이 줄어들고, 그게 곧 MTTR 단축으로 이어집니다.
이런 시스템이 잘 안착한 팀들의 공통점도 꽤 분명합니다.
문서가 이미 어느 정도는 정리돼 있었고, 장애가 끝나면 리포트를 쓰는 문화가 있습니다. RAG는 그 문화를 증폭시키는 도구지, 없는 문화를 대신 만들어 주지는 않습니다. 문서가 부실하면, AI도 그 부실함을 그대로 증폭시킬 뿐입니다.
또 하나 중요한 포인트는 신뢰입니다.
RAG가 찾아온 결과가 계속 엉뚱하면, 엔지니어들은 금방 안 보게 됩니다. 그래서 실제 사례에서는 검색 결과를 한 번 더 걸러 주거나, 도움이 됐는지 간단히 피드백을 남기게 해서 점점 품질을 끌어올리는 식으로 운영합니다.
정리하면,
장애 대응을 위한 RAG는 “AI로 장애를 해결한다”기보다
**“사람이 판단하기까지의 첫 10~15분을 없애는 장치”**에 가깝습니다.
그 목적에 맞게 데이터도, 파이프라인도, 기대치도 낮춰 두는 쪽이 오히려 성공 확률이 높습니다.
지금 이걸 고민하고 계시다면,
“우리는 RAG로 뭘 자동화하고 싶은가?”보다
“장애 났을 때 사람들이 제일 먼저 찾는 정보가 뭐였지?”를 적어보는 것부터 시작해 보셔도 좋을 것 같습니다.
그 질문에 답이 보이면, RAG 설계도 자연스럽게 따라옵니다.
1 Like
완전 좋아요. 감사해용!
전제적으로 RAG에 대한 생각이 정리가 돼요. 말씀 주신 내용에서 너무 공감합니다. 감사해용!