AI를 활용하여 누구나 장애 조사가 가능한 시스템을 구축해 보았습니다

장애가 발생했을 때의 첫 단계는 대개 정해져 있습니다.

로그를 열어 에러가 발생한 부분을 찾고, 해당 버전의 소스 코드와 대조하여 원인을 좁혀 나갑니다. 이 일련의 작업은 로그 읽기와 코드 읽기 두 가지 모두를 아는 사람만이 할 수 있습니다. 이는 초기 대응이 가능한 사람이 제한적이며, 그 사람의 가용 상황이 문제 해결 속도에 직결된다는 것을 의미합니다.

이번 목표는 이 일련의 과정을 누구나 할 수 있도록 만드는 것입니다.

저는 이번에 Slack을 통해 봇으로 사용할 수 있게 만들어 보았습니다.

과거 장애를 바탕으로 테스트 데이터를 생성하여 실제로 검증해 보겠습니다.

아래와 같이 시스템 버전과 증상을 간단히 기입하고, 추가로 로그 파일을 첨부합니다.

スクリーンショット 2026-09-29 17.01.52.png

그러면 약 10분 후에 아래와 같이 즉시 회피 방안과 근본적인 대응책을 제시해 줍니다.

한 번의 비용은 약 0.5~1달러 정도입니다.

이는 LLM API 사용료만이며, AWS 이용료는 별도로 발생합니다.

Slack에 로그를 첨부하여 게시하면 AWS 상에서 조사가 자동으로 진행되고, 결과가 같은 스레드에 반환되는 시스템을 구축했습니다. 접수와 무거운 조사 처리는 분리했습니다. 에이전트 본체에는 Claude Agent SDK를 사용했습니다.

Slack으로의 포스팅은 Lambda가 받아 처리할 작업(job)로 SQS에 넣는 역할만 전담합니다. Slack 응답 3초 제한을 맞추려면 Lambda 처리가 가벼워야 하므로, 실제 조사(git worktree 전개 및 Claude Agent SDK 실행)는 10분 정도 걸리며 Lambda의 제약(메모리/실행 시간)에 맞지 않아 ECS Fargate로 분리했습니다.

로컬에서 Claude나 Cursor 등의 에이전트를 사용할 경우, 로그 파일이나 소스 코드는 에이전트가 볼 수 있는 폴더에 두기만 하면 됩니다. 프롬프트로 주고받을 때도 비용을 크게 신경 쓸 필요는 없습니다.

하지만 LLM API(이번에는 Amazon Bedrock 경유의 Claude)를 사용하는 경우에는 단순하게 생각하면, 로그 파일이나 소스 코드를 요청에 포함하여 전달해야 합니다. 데이터 크기가 커지면 그대로 비용으로 전가됩니다.

실제 장애 로그는 수만 줄에 달하는 경우가 있어, 그대로 전달하면 프롬프트 크기 제한에 맞지 않습니다. 그래서 LLM에 전달하기 전에 다음 규칙으로 로그를 좁히고 있습니다. 이 처리는 AI를 사용하지 않고 Python으로 기계적으로 진행되므로, 좁히는 과정 자체에는 토큰 비용이 들지 않습니다.

• 로그를 HTTP 요청 단위(시작~종료 마커)로 세션 분할
• ERROR/WARN/Exception을 포함하는 세션만 남기기
• 세션 내에 3초 이상의 간격(처리가 멈춘 부분)이 있는 세션도 남기기
• 남긴 세션은 해당 부분의 앞뒤 15줄을 문맥으로 추가하기
• 같은 SQL이 4회 이상 나온 경우, 두 번째부터는 생략하고 횟수만 기록하기
• SQL의 긴 부분을 줄이기(SELECT 컬럼 목록을 “[...]”로 대체하거나 바인드 값을 생략하기)

이를 통해 수만 줄의 로그를 수백 줄까지 압축할 수 있습니다.

처음에는 로그만 전달하여 에이전트에게 조사하게 했지만, 단서가 적어 탐색이 분산되어 최대 턴 수에 도달해도 결론을 내지 못한 채 끝나는 경우도 있었습니다. 조사하고 싶은 증상을 프롬프트에 포함하도록 변경하자, 탐색 범위가 좁혀져 적은 턴 수로 근본 원인에 도달할 수 있게 되었습니다.

첫 번째 조사로 끝나지 않고, 결과에 대해 추가 질문을 하고 싶을 때가 있습니다. 그럴 때마다 처음부터 조사를 다시 하는 것은 비용과 시간 낭비가 됩니다. 그래서 세션 ID와 작업 트리를 연결하여 유지하고, 동일한 세션을 지속할 수 있도록 했습니다. 에이전트는 그때까지 조사했던 내용을 바탕으로 추가 질문에 답변할 수 있습니다. 참고로, 이것은 현재 스크립트 기반의 PoC(Proof of Concept) 단계이며, 실제 Slack 연동에는 포함되어 있지 않습니다.

입력 및 출력 토큰 수를 통해 실제 금액을 계산하고, 조사 결과 보고서에 표시하도록 했습니다. 건별 비용이 보이게 되면서, 로그 필터링 등의 개선 사항이 비용 절감에 얼마나 효과적인지 숫자로 확인하며 개선을 진행할 수 있게 되었습니다.

과거의 장애 패턴을 기반으로 4가지 테스트 케이스를 준비하여 검증했습니다. 결과는 모두 기대한 바와 같았습니다.

장애 조사를 AI로 자동화할 때의 핵심 포인트는 다음과 같습니다.

• 소스 코드를 통째로 전달하지 않고, 에이전트에게 필요한 부분만 읽게 하기
• 거대한 로그는 AI를 사용하지 않고 스크립트로 필요 최소한으로 좁힌 후 전달하기
• 사용하지 않는 시간에는 비용이 발생하지 않도록 구성하기 (접수와 조사를 분리하여 작업(Job)이 없으면 워커(Worker)는 0대로 유지)

이번에는 시스템을 구축하는 단계까지이며, 장기적으로는 제품에 통합하여 사용자 스스로가 트러블슈팅으로 사용할 수 있도록 하고자 합니다.