AI 장애 진단은 네 번에 한 번 틀린다?

서버에 장애가 나면 제일 먼저 하는 일은 로그를 여는 것이고, 그 로그를 AI에게 읽혀 원인을 짚게 하는 시도는 이제 혼자 서버를 굴리는 사람도 해볼 수 있을 만큼 흔해졌다. 문제는 틀린 원인을 자신 있게 말하는 진단이 아무 진단도 없는 상태보다 나쁘다는 데 있다. 로그와 추적 기록을 사람이 뒤지는 기존 원인 분석은 손이 많이 가고 틀리기 쉽고 당직 엔지니어에게 부담이라고 Microsoft 연구진의 RCACopilot 논문도 적어 두었다. 시스템이 복잡해질수록 사람 손으로는 버티기 어려워지니 장애 관리에 AI를 쓰는 방식은 이미 널리 쓰이고 있다. 그러니 물어야 할 것은 AI가 원인을 말할 수 있냐가 아니라 그 말을 어디까지 믿을 수 있냐다. 운영 현장에 들어간 AI 진단 시스템 가운데는 정답을 1순위로 집어낸 비율이 아니라 후보 셋 안에 들었는지로 성적을 내놓은 쪽이 있다. 그러니 믿을 만한 쓰임새는 AI가 원인을 결론으로 선언하는 쪽이 아니다. 근거가 된 로그와 함께 후보를 좁혀 주고 사람이 1분 안에 확인하는 구조다.

로그 200만 줄은 애초에 안 들어간다

30분 동안 이어진 장애 한 건이 만드는 로그가 얼마나 되는지부터 보면 이야기가 달라진다. Huawei 연구진이 Log-Insight 논문에서 밝힌 수는 로그 200만 줄이 넘고 글자로는 약 12억이다. 30분짜리 장애 하나가 그렇다. 이 분량 때문에 로그를 AI에 그대로 넣는 방식은 애초에 불가능하다고 같은 팀이 적었다. 모델이 똑똑하지 않아서 막히는 것이 아니라 분량이 들어가지 않아서 막히는 것이라 여기서 걸리면 뒤에 무슨 모델을 붙여도 달라지지 않는다.

여기서 뜻을 풀어야 할 말이 두 개다. 하나는 맥락 창인데 모델이 한 번에 읽어들일 수 있는 글의 분량을 말한다. 사람이 책상에 한꺼번에 펼쳐 놓을 수 있는 종이 장수가 정해져 있는 것과 비슷하게 모델도 한 번에 받을 수 있는 글자 수에 끝이 있어서 12억 글자는 그 끝을 한참 넘는다. 다른 하나는 없는 내용을 지어내는 현상이다. 모델이 모르는 것을 모른다고 하지 않고 그럴듯한 문장을 만들어 채우는 것을 말하는데 Huawei 팀은 AI에 원시 데이터를 그대로 주면 분량이 넘칠 뿐 아니라 바로 이 지어내기가 나온다고 짚었다. 원시 로그를 그냥 들이붓는 쪽은 분량이 넘치는 문제와 없는 내용을 지어내는 문제를 한꺼번에 겪는다.

그래서 Huawei 팀이 택한 것은 로그를 AI에 넘기기 전에 줄이는 일이다. 여섯 단계를 거쳐 원시 기록을 1,000배에서 7,000배까지 줄이면서 통계적으로 의미 있는 장애 신호는 남겼다고 한다. 몇 배가 아니라 몇천 배다. 다시 말해 이 시스템에서 AI가 들여다본 것은 200만 줄이 아니라 그만큼 압축된 묶음이었다. 200만 줄이 그만큼 줄어든 다음에야 AI에게 넘길 수 있었다는 뜻이니 로그를 통째로 붙여 넣고 원인을 물어보는 방식은 시작점부터 다른 일을 하고 있는 셈이다.

정확도 0.766이 어느 정도인가

그렇게 줄여서 넣으면 AI가 원인을 얼마나 맞히나. Microsoft 연구진이 만든 RCACopilot은 알림 종류에 따라 담당 처리기를 고르고 진단 정보를 모은 다음 원인 범주를 예측하고 설명을 붙이는 시스템이다. 원인 범주는 원인 하나를 콕 집어내는 것이 아니라 비슷한 원인들을 묶어 놓은 갈래를 말한다. 이 팀은 실험실용으로 만든 자료가 아니라 Microsoft에서 1년간 실제로 난 장애 데이터셋으로 평가했고 원인 분석 정확도가 최대 0.766이었다고 보고했다. 정확도 0.766은 원인 하나가 아니라 이 범주를 맞힌 성적이다.

0.766은 백 건 중 일흔여섯 건 남짓을 맞혔다는 뜻이다. 숫자만 보면 나쁘지 않은데 뒤집으면 넷 중 하나 가까이는 맞히지 못했다는 말이 된다. 혼자 서버를 굴리는 사람 입장에서 이게 무슨 의미인지 생각해 보면, 새벽에 알림을 받고 AI가 짚어 준 원인을 그대로 믿고 손을 대는 경우 네 번 중 한 번은 엉뚱한 곳을 고치고 있게 된다. 틀린 쪽에 쓴 시간만 날아가는 것이 아니라 그 사이에 진짜 원인은 그대로 돌아가고 있다. Microsoft에서 1년간 실제로 난 장애로 잰 수가 이 정도니 혼자 굴리는 서버에서 더 잘 나올 이유는 없다.

같은 논문에 더 눈여겨볼 대목이 있다. RCACopilot에서 Microsoft가 4년 넘게 실제로 써 온 부분은 원인을 판정하는 쪽이 아니라 진단 정보를 모으는 쪽이다. 알림을 받아 어떤 기록을 긁어와야 하는지 알고 그것을 모아 한자리에 놓아 주는 일이 먼저 현장에 자리를 잡았고 그 정보로 원인을 맞히는 부분을 두고 논문이 내놓은 것은 최대 0.766이라는 정확도다. 4년을 버틴 쪽은 사람이 하던 수집을 대신하는 일이고 숫자로만 보고된 쪽은 사람이 하던 판단을 대신하는 일이라서 둘이 갈린다. 현장에서 먼저 신뢰를 얻은 것은 판단이 아니라 수집이었다.

정답 하나가 아니라 후보 셋과 근거

Huawei 팀이 Log-Insight의 성적을 보고한 방식을 보면 이 차이가 더 분명해진다. 과거 운영 장애 11건을 110회 실행해 운영자가 확인한 정답과 맞춰 보니 90퍼센트 넘는 실행에서 정답 원인이 상위 3개 가설 안에 들었고 걸린 시간은 1분 미만이었다. 같이 적은 MRR 0.790은 정답이 후보 목록에서 몇 번째에 놓였는지를 평균해 매긴 점수다. 핵심은 이 팀이 ‘1위로 맞혔다’가 아니라 ‘상위 3개 안에 들었다’를 성적으로 내놓았다는 데 있다. 정답을 단 하나 집어내는 기계로 소개하지 않고 후보 셋을 좁혀 주는 기계로 소개한 것이다.

더 흥미로운 것은 운영자들이 이 시스템을 받아들인 이유다. Huawei 팀은 어떤 로그를 근거로 삼았는지 보여 주는 부분이 있어서 운영자들이 이 시스템을 받아들였다고 적었다. 속을 알 수 없는 판정 기계가 아니라 조사를 돕는 쪽으로 역할이 바뀌었다는 것이다. 맞힌 비율이 올라가서가 아니다. 근거 줄이 없으면 결론을 믿거나 버리는 두 선택만 남는데 근거가 붙으면 열어서 확인하는 셋째 길이 생긴다. 출력에 근거 줄이 같이 붙어 나오니 운영자가 그 줄을 열어 1분 안에 맞는지 틀렸는지 판정할 수 있었다. 이 시스템을 믿게 만든 것은 모델 성능이 아니라 출력 형식이다.

그 아래 설계도 같은 생각을 따른다. Huawei 팀은 숙련된 운영자가 손으로 하던 순서를 그대로 자동화하는 것을 원칙으로 세웠다. 표본 뽑기와 구조 파악과 묶기와 이상 순위 매기기가 그 순서다. AI에게 넘기는 것도 로그 전체가 아니라 미리 순위를 매겨 압축한 증거 묶음뿐이고 AI는 그것으로 가설 보고서를 쓴다. 손으로 하던 순서를 그대로 옮겼으니 결과를 받는 사람도 기계가 어느 대목을 대신했는지 알고 본다. 사람이 하던 일을 AI가 대신 하는 구조가 아니라 사람이 하던 순서의 앞부분을 기계가 맡고 마지막 판정은 사람에게 남겨 두는 구조다.

내 서버 알림에 붙여 보는 순서

여기까지가 논문에 적힌 것이고 혼자 서버를 굴리는 사람이 자기 알림에 붙여 보려면 세 가지만 지키면 된다.

• 로그를 미리 줄여서 넘긴다. 장애 알림이 뜬 시각 앞뒤로 잘라낸 로그 꼬리만 보내고 오류와 경고 줄을 먼저 올린다. Huawei 팀이 몇천 배를 줄여서야 AI에 넘겼다는 점을 생각하면 전체 파일을 붙여 넣는 선택지는 없다고 보면 된다.
• 결론 대신 후보와 근거 줄을 요구한다. 원인을 하나 말하라고 하지 않고 원인 후보 세 개와 각 후보를 뒷받침하는 로그 줄을 함께 내놓으라고 시킨다. 근거 줄이 같이 와야 사람이 그 줄을 열어 몇십 초 안에 걸러낼 수 있고, 후보 셋이라는 수도 Log-Insight가 상위 3개로 성적을 낸 모양과 같다.
• 대응 동작은 사람이 실행한다. 재시작이든 설정 변경이든 서비스에 손을 대는 일은 후보를 확인한 다음 직접 한다. 정확도 0.766이라는 수가 가리키는 것은 자동 실행을 맡길 단계가 아니라는 쪽이다.

어떤 모델을 쓸지도 생각해 볼 만하다. Kim Hammar와 Tansu Alpcan, Emil C. Lupu가 쓴 대응 계획 논문은 큰 상용 모델에 프롬프트만 잘 써서 쓰는 방식이 비용이 들고 없는 내용을 지어내기 쉽다는 데서 출발한다. 이들은 대응 계획을 세우는 방법을 미세조정과 정보 검색과 앞을 내다보는 계획의 세 단계로 나눴다. 미세조정은 모델에 그 일에 맞는 자료를 더 학습시키는 것을 말한다. 정보 검색은 답을 만들기 전에 관련 기록을 찾아와 같이 읽히는 것이다. 앞을 내다보는 계획은 동작을 바로 내놓지 않고 그 다음에 올 수를 미리 따져 보는 것이다. 이 팀은 지어낼 확률에 상한이 있음을 증명했고 계획에 시간을 더 쓰면 그 확률을 얼마든지 낮출 수 있다고 적었다.

문헌에 보고된 장애들의 로그로 방법을 비교해 보니 이들이 만든 쪽이 최상위 상용 모델보다 복구 시간이 최대 22퍼센트 짧았다. 장애 종류와 대응 동작이 여러 가지로 바뀌어도 같은 방법이 통했다. 작고 가벼운 모델 쪽이 복구 시간에서 큰 모델보다 나았다는 뜻이다. 특별한 장비 없이 흔한 하드웨어에서 돌아간다는 점까지 보면 가장 큰 모델에 프롬프트만 던지는 방식이 유일한 길도 아니고 제일 나은 길도 아니다. 비용이 걸림돌이었던 출발점을 생각하면 흔한 장비에서 돌아간다는 것은 덤이 아니라 조건에 가깝다. 장애 관리에 AI를 쓰는 방식을 모아 정리한 AIOps 조사 논문을 보면 이미 쓰이는 방법이 한둘이 아니니 큰 모델 하나에 매달릴 일은 아니다.

다음 장애가 났을 때 에이전트에게 줄인 로그를 주고 후보 셋과 근거 줄을 받아 당시 확인된 원인과 대조해 보면, 이 구조가 내 서버에서도 쓸 만한지는 그 대조표 한 장으로 판가름난다.