AI 에이전트의 인시던트 대응 모드 설계: 초동, 판단, 조작을 구분하는 방법

인시던트를 대응하는 과정에서 필요한 정보는 평소 기술 조사와는 조금 다릅니다. 상세한 원인 설명도 필요하지만, 그보다 먼저 현재 영향이 지속되고 있는지, 무엇을 파악했는지, 다음에 어떤 대응을 할 수 있는지를 알고 싶어 합니다. AI 에이전트를 운영 지원에 사용할 때도 이 순서를 고려해야 합니다.

저는 일상적인 기술 지원에서 사용하는 AI 에이전트에게 인시던트 발생 시 조사 및 응답의 방침을 갖게 했습니다. 로그나 상태를 확인하고 대응 방안을 정리하는 역할을 맡긴 것입니다. 그 설계 과정에서 중점을 둔 것은, 초동으로 전달할 정보의 순서와 실제 조작(Operation)으로 진행할 조건을 분리하는 것이었습니다.

이러한 고민을 하게 된 계기 중 하나는 의존 패키지 문제에 대한 복구 상담이었습니다. 상세한 조사나 보고서 준비가 먼저 진행되면서, 대응을 위해 필요한 정보가 사용자에게 전달되기까지 시간이 걸렸습니다. 또한, 처리가 이미 접수되었더라도 그 상태나 승인처 안내가 지연되면, 사용자 입장에서는 작업이 진행되고 있다는 느낌을 받기 어렵습니다.

조사의 질을 유지하면서도 현재 대응에 필요한 정보를 먼저 제공합니다. 조작(Operation)을 할 때는 대상과 권한을 다시 한번 확인합니다. 이 두 가지를 양립시키기 위해 임시 대응용 방침을 정리했습니다. 여기서는 개별 시스템명이나 설정값은 생략하고, 그 과정에서 생각했던 점들을 작성하겠습니다.

인시던트 대응에서는 조사의 우선순위를 변경해야 한다

동일한 상태 조회나 로그 검색이라도 사용자가 원하는 결과에 따라 활용 방법이 달라집니다. 현재 상태를 알고 싶을 때와 실패 이유를 자세히 조사하고 싶을 때, 영향이 지속되어 복구를 진행하고 싶을 때는 조사 마무리 방식 자체가 다릅니다.

예를 들어, 상세 원인 조사를 진행하던 중 사용자로부터

빠른 응답을 중시하면, 가장 먼저 발견된 오류를 원인으로 설명하려는 경향이 있습니다. 하지만 인시던트 대응에서는 그 설명이 다음 조치로 이어집니다. 무엇을 원인이라고 부르느냐에 따라 재실행, 설정 변경, 복구의 대상이 달라지기 때문입니다.

한 릴리스 처리 조사에서 먼저 리소스 경합(resource conflict)이 발견되었고, 이후 전체 처리가 취소 상태가 되어 있었습니다. 조사를 진행해 보니, 취소를 직접 발생시킨 것은 외부 실행 관리 시스템에 의한 타임아웃이었습니다. 업무 처리를 먼저 중단시킨 이유와 취소 상태로 이동한 이유가 달랐던 것입니다.

이 예시에서 경합만 해소한다고 해서 이미 취소된 처리가 그대로 재개된다는 보장이 없습니다. 현재의 경합이 사라졌다고 해도, 과거에 취소가 발생했던 이유를 바꾸지는 못합니다. 복구를 생각하려면, 원래 실행으로 무엇이 완료되었는지, 그리고 지금 어떤 상태인지 확인해야 합니다.

이 경험을 통해, 직접적인 실패 원인을 제시할 때는 적어도 대상과 시간대를 일치시키고, 구체적인 단계에서 무엇이 발생했고 그로 인해 필요한 결과가 얻어지지 않았음을 설명할 수 있도록 하고 있습니다. 또한, 이미 복구되었는지, 후속 처리가 성공했는지, 다른 오류가 동시에 발생하고 있는지 등의 정보가 대응 방향을 바꾸지 않는지 확인합니다.

여러 애플리케이션이나 실행이 실패한 경우에는 대표적인 대상을 조사하기도 합니다. 하지만 한 건을 조사한 결과를 전체 원인으로 확대할 수는 없습니다. 같은 시간대, 같은 단계, 같은 오류 등 어떤 조건이 공통적인지를 봅니다. 다른 실패가 섞여 있다면 개별적으로 다룹니다.

현재 모니터링이 정상이라 하더라도 과거 시간대에 장애가 없었다고는 할 수 없습니다. 반대로, 과거에 실패한 실행 기록이 남아있다고 해도 현재 사용자에게 영향이 지속되고 있다고는 할 수 없습니다. 발생했던 일과 지금 일어나고 있는 일을 분리하면, 원인 설명도 복구 판단도 처리하기 쉬워집니다.

응급 대응(Emergency response)에서는 현재 조치에 부족한 부분까지 인과관계를 보여줍니다. 깊은 구현상의 원인이나 영구적인 대책은 그 후에 조사할 수 있습니다. 직접적인 원인을 제시한 후에도 새로운 증거가 대응 방향을 바꾼다면, 조사와 설명을 업데이트합니다.

초동(Initial response)을 짧게 하더라도, 조작 권한을 넓히지는 않는다

로그를 읽는 것, 대응 방안을 제시하는 것, 실제로 상태를 변경하는 것은 각각 다른 조건을 가집니다. 응급 대응 모드에 진입했다는 이유로 에이전트의 조작 권한이 확장되도록 설계하지 않았습니다.

원인과 대응 방향은 미리 반환할 수 있습니다. 실제로 조치(operation)를 진행하기 전에는 현재 대상, 상태, 영향 범위를 확인합니다. 조사 시작 시점에는 적절했던 방안이라도, 그 후에 다른 처리가 시작되었거나 담당자가 복구했을 수도 있기 때문입니다.

대응 방안에는 무엇을 변경할지, 그 변경이 어디에 영향을 미칠지, 무엇을 확인하고 종료할지가 포함되어야 합니다. 버전이나 대상을 유일하게 결정할 수 없다면 사용자에게 선택을 요청합니다. 필요한 확인 절차를 에이전트의 추측으로 대신 완료할 수는 없습니다.

예를 들어, 문제가 있는 의존 패키지에서 되돌릴 경우, 대상, 현재 사용 중인 버전, 되돌릴 위치(rollback target), 영향 범위를 정리합니다. 사용자가 확인한 내용과 실제로 요청하는 내용을 연결하고, 기존 업무 시스템이 가진 인증이나 승인을 사용합니다.

이때, 확인이나 승인을 늘리면 안전해진다고도 할 수 없습니다. 같은 목적을 위한 인증이나 승인이 이미 있다면, 그 메커니즘을 사용하는 것이 책임 소재와 처리 상황을 추적하기 더 쉽습니다. 다른 종류의 상태 변경에는 해당 조치에 필요한 권한을 적용합니다. 어떤 변경에 어떤 메커니즘을 사용할지 명확히 하는 것이 중요합니다.

응답이 타임아웃된 경우에도, 먼저 원래 요청을 조사합니다. 응답을 받지 못했을 뿐이라도 처리는 시작되었을 수 있기 때문입니다. 같은 변경을 다시 요청하면 중복 작업이나 다른 대응과의 경합(conflict)을 일으킬 수 있습니다.

이러한 상황에서는 상태를 유지하는 것, 동일 조작의 반복을 멈추는 것, 기존 처리가 끝날 때까지 기다리는 것도 대응 방향이 될 수 있습니다. 안전하게 실행할 수 있는 조치가 아직 결정되지 않았다면, 필요한 조사를 계속합니다. 에이전트가 조치하지 않았다는 이유만으로 조사까지 완료되었다고 취급하는 것도 피하고 있습니다.

완료는 원래 문제가 회복된 것으로 판단한다

응급 대응을 진행하면 여러 개의 '완료'가 발생합니다. 요청을 접수했다, 승인되었다, 처리가 성공했다, 사용자에게 영향이 없어졌다. 각각은 별개의 사실입니다.

한편, 승인이나 실행의 성공만으로는 복구를 선언할 수 없습니다. 의존 관계가 변경된 경우라면, 대상 작업이 실제로 통과하는지 확인합니다. 사용자 대상 장애라면, 원래 문제로 확인했던 관점에서 회복을 점검합니다. 다른 모니터링 지표가 정상화되었다는 것을 그대로 원래 문제의 해소에 대체하지 않도록 합니다.

대응이 실패하거나 승인이 취소된 경우에는 그 상태를 전달합니다. 사용자가 대응을 마쳤다고 결정할 때까지, 남아있는 영향에 대해 필요한 판단을 계속 진행합니다. 다만, 명시적으로 작업을 중단하라는 요청이 있으면 거기서 멈춥니다.

복구 확인 단계로 진전된 후에, 상세한 원인, 판단 경위, 대응 결과를 보고서로 정리합니다. 임시 대응 중에 확보한 증거, 확인한 입력값, 실행 결과는 인계되므로, 보고를 위해 같은 조사를 처음부터 반복할 필요가 없습니다.

원인이 아직 파악되지 않았더라도, 원래 문제와 동일한 관점에서 현재의 영향을 확인하고 해소되었다고 판단할 수 있는 경우가 있습니다. 그 경우에는 현재의 임시 대응과 과거의 원인 조사를 분리하여 다룹니다. 복구된 것을 이유로, 과거의 원인까지 알게 된 것은 아닙니다.

임시 대응 모드에서 바꾸고 싶었던 것

이 설계에서 바꾸고 싶었던 것은 조사량과 그 가치 인식 방식입니다. 많은 로그를 읽고 상세한 보고서를 제공하더라도, 사용자가 지금 필요한 판단으로 나아가지 못하면 초동 지원으로는 부족합니다.

에이전트에게 요구되는 것은 대상과 시점을 확인하고, 현재의 판단을 바꿀 증거를 선택하여 알려진 범위 내에서 전달하는 것입니다. 그 위에 대응 방안과 실제 조작을 분리하고, 필요한 권한과 확인 절차를 유지합니다. 처리가 끝난 후에는 원래 문제로 돌아가 결과를 확인합니다.

평가할 때도 첫 응답이 빨랐기만으로는 판단할 수 없습니다. 실제로 판단에 사용할 수 있는 사실이 반환되었는지, 다른 대상의 정보를 섞지 않았는지, 대응 범위를 설명할 수 있었는지, 복구 확인으로 이어졌는지를 살펴봅니다. 조사 속도와 판단 및 조작의 적절성을 함께 확인할 필요가 있습니다.

AI를 임시 대응에 투입하면 정보 수집 능력이 증가합니다. 동시에, 그 정보로부터 무엇을 말할 수 있는지, 어디까지 조작할 수 있는지를 더 명확하게 할 필요가 있습니다. 저는 그 분담을 정돈함으로써 평소의 기술 지원 경험을 인시던트 중에도 활용하기 쉽게 만들 수 있다고 생각합니다.

Discussion