장애를 부검하는 AI, Incident Autopsy로 사내 해커톤 대상을 받기까지

들어가며

2026 KB데이타시스템 사내 해커톤에서 팀 End-Gamers로 참가해서 대상을 받았다.

 

Incident Autopsy

- 여러 시스템에 흩어진 장애 로그를 AI가 교차 분석해서 원인부터 재발 방지 권고까지 자동으로 뽑아주는 운영 도구다.

https://github.com/End-Gamers/incident-autopsy-public

GitHub - End-Gamers/incident-autopsy-public: AI를 활용한 장애 보고서 작성 자동화 프로그램

 

 

기술적인 삽질은 이미 [End-Gamers] 시리즈로 썼다. Bedrock 이중 인코딩 버그, 멀티 에이전트 오케스트레이션, Celery·Slack 알림, RAG 조치 이력, EC2 배포까지 - 각 주제는 그 글들에 넘긴다. .

 

이번 글은 6주 209개 커밋이 실제로 어떤 화면으로 완성됐는지 처음부터 끝까지 훑고, 그게 왜 대상으로 이어졌는지를 정리하는 총정리 편이다.

 

 

지금은 해커톤이 끝나서 AWS 인프라를 정리한 상태다.
그래서 이 글의 화면은 로컬에 남아있던 실제 운영 DB(분석 89건)를 그대로 붙여서 다시 띄운 뒤 찍었다.

 

---

1. 무엇을 만들었나 - 장애를 부검(Autopsy)한다는 발상

운영 장애가 터지면 담당자는 Jennifer APM 트랜잭션 로그, Spring Boot REST 로그, KB Framework 앱로그, Log4j를 각각 열어서 눈으로 대조한다. 이름도 형식도 다른 로그를 손으로 짜맞춰 원인을 추론하는 과정 자체가 병목이다.

 

Incident Autopsy는 이 로그들을 한꺼번에 업로드하면 AI가

원인 추론 → 증거 추출 → 영향 범위 분석 → 재발 방지 권고까지 20~60초 안에 구조화해서 돌려준다.

이름을 "부검(Autopsy)"으로 지은 것도 이 지점에서다.

장애가 다 지나간 뒤 로그라는 사체를 해부해서 사인을 밝혀내는 작업이라는 뜻이다.

 

 

장애 대응에서 가장 비싼 자원은 사람이 로그를 눈으로 대조하는 시간이다.
그 시간을 줄이는 게 이 프로젝트의 전부였다.

 

---

2. 화면으로 보는 구조

탭 다섯 개로 앱 전체가 구성된다.

실제로 쌓인 데이터를 붙여서 하나씩 찍었다.

 

로그 분석 - 로그 파일을 올리거나 GUID로 조회해서 AI를 골라 분석을 실행하는 진입 화면. 평균 소요 시간 20~60초를 화면에 그대로 안내한다.

 

 

오류 이력 - 전체 분석 89건, Critical 10건, 성공률 29%가 상단 요약에 뜬다. AI 제공사별 도넛 차트, 30일 추이, 심각도 분포, 에러 유형별 건수까지 한 화면에서 훑을 수 있다.

 

장애 보고서 상세 - 이력에서 "보기"를 누르면 실제 분석 결과가 뜬다. 아래는 뱅킹 코어 시스템 장애 사례로, DB 연결 타임아웃과 네트워크 오류가 겹쳐 15,000명 규모 서비스가 중단된 걸 AI가 원인 근거(에러 메시지, 재시도 로그)까지 짚어낸 결과다.

 

조치 이력 관리 - ChromaDB에 쌓인 RAG 인덱스 현황을 보여준다. 승인된 분석 결과가 여기 쌓이면 다음 분석에서 유사 사례로 자동 참조된다.

 

관리 - 보고서 타입(양식) 등록, AI 3사 API 키, Prometheus 서버 메트릭, Bedrock MFA 임시 자격증명, Grafana 대시보드 등록까지 운영에 필요한 설정이 전부 이 탭 하나에 모여 있다.

 

모니터링 - Grafana 대시보드를 iframe으로 임베드해서 Jennifer APM 실시간 로그 스트림과 에러 추이를 보여주는 탭. 지금은 Grafana 서버가 내려가 있어서 임베드 안내 문구만 뜨지만, 구조는 그대로 남아있다.

 

---

3. 6주, 209개 커밋의 리듬

일정은 v1과 v2로 나뉜다.

• v1 (완료): 로컬 실행, SQLite, 동기 분석, RAG 조치 이력 관리까지 프로토타입 완성
• v2 (완료): 멀티 에이전트 파이프라인, Human-in-the-loop, SSE 실시간 스트리밍, 모니터링 탭(Grafana + Prometheus), 신뢰도 점수, 감사 로그, RCA+Report 통합 에이전트, Bedrock Haiku 4.5 스트리밍, PDF·Word 보고서 KB 스타일 레이아웃까지 확장

 

팀은 네 명이 커밋을 나눠 쳤다.

초반엔 화면 뼈대와 AI 연동을 잡는 데 집중했고,

중반부터 멀티 에이전트·RAG·모니터링이 한꺼번에 붙으면서 커밋 밀도가 확 올라갔다.

이 구간의 디테일은 이미 시리즈로 정리했고, 아직 올라가지 않은 시리즈는 올릴 예정이다.

• [End-Gamers] 1편 - Loki·Prometheus·Grafana로 로그 생성기 구축
• [End-Gamers] 2편 - Bedrock URL 이중 인코딩 버그와 converse API
• [End-Gamers] 3편 - Celery·Redis 비동기 파이프라인과 Slack 알림
• [End-Gamers] 4편 - MCP 서버로 Bedrock Tool Use 연동
• [End-Gamers] 5편 - AI가 docx 보고서를 채우기까지
• [End-Gamers] 6편 - RAG 조치이력 시스템 설계
• [End-Gamers] 7편 - GUID로 멀티소스 로그 꿰뚫는 SSE 채팅
• [End-Gamers] 8편 - 단일 AI에서 멀티 에이전트 오케스트레이션으로
• [End-Gamers] 9편 - Bedrock converse_stream 토큰 스트리밍
• [End-Gamers] 10편 - EC2 배포 자동화와 MFA 세션 자격증명

 

---

4. 결정과 이유

AI 제공사를 세 개나 붙인 이유

Claude, Groq, AWS Bedrock을 Strategy Pattern으로 묶어서 DB_TYPE 환경변수처럼 런타임에 갈아끼울 수 있게 설계했다. 해커톤 기간 중 특정 API가 막히거나 쿼터가 걸리는 상황에 발표가 죽는 걸 피하려는 목적이 컸다. 실제로 이 구조 덕분에 Bedrock 연동이 한동안 불안정할 때도(2편 참고) Claude·Groq로 시연을 이어갈 수 있었다.

 

멀티 에이전트를 굳이 2단계로 합친 이유

처음엔 Triage 에이전트와 RCA 에이전트, Report 에이전트를 따로 뒀는데, API 호출이 세션당 30회까지 뛰었다. 해커톤 데모에서 응답이 느리면 그 자체로 감점이다. RCA와 Report를 하나의 에이전트로 합쳐서 호출 수를 14회로 줄였고, 대신 SSE로 각 노드가 지금 뭘 하고 있는지 실시간으로 화면에 보여줘서 "느린데 뭐 하는지 안 보이는" 문제를 없앴다(8편, 9편 참고).

 

AI 판단에 사람 승인 게이트를 넣은 이유

Human-in-the-loop 승인 단계를 넣은 건 금융권 서비스라는 맥락 때문이다. AI가 뽑은 원인·권고사항을 담당 엔지니어가 검토·승인해야 보고서 생성 단계로 넘어간다. AI 자동화가 편의를 준다고 해서 최종 판단까지 위임할 수 없다는 걸 설계에 그대로 반영한 셈이다. 실제 보고서 하단에도 "최종 판단 및 책임은 담당 엔지니어가 검토 후 결정하십시오"라는 문구를 못 박아 뒀다.

 

Slack 알림을 장애 보고 절차 그대로 흉내 낸 이유

분석 시작·완료·RCA 승인 시점마다 Slack으로 알림이 나간다. 금융권은 장애 발생 시 보고 체계가 규정으로 정해져 있는데, 그 흐름을 도구 안에 그대로 넣어야 실무에서 쓸모가 생긴다고 판단했다(3편 참고).

 

---

5. 잘 된 것

6주 만에 로컬 프로토타입에서 멀티 에이전트 + RAG + 모니터링 + AWS 배포까지,
심사에서 "장난감이 아니라 진짜 쓸 수 있는 도구"로 보이게 만들었다는 것.

 

• Strategy Pattern으로 AI·DB 구현체를 분리해둔 덕분에, Bedrock이 흔들려도 다른 제공사로 시연을 이어갈 수 있었다
• RCA+Report 에이전트 통합으로 API 호출을 절반 이하로 줄이면서도 SSE 시각화로 체감 속도까지 챙겼다
• 승인 게이트·Slack 알림처럼 실무 절차를 그대로 반영해서, "AI가 다 알아서 한다"가 아니라 "AI가 검토를 돕는다"는 포지션을 제품에 정확히 새겼다
• 기술 디테일을 그때그때 시리즈로 기록해둔 덕분에, 지금 이 회고를 쓸 때 "왜 이렇게 했는지"를 다시 추측할 필요가 없었다

 

---

6. 아쉬웠던 것

• v3로 계획했던 Groq 1차 전처리 → Bedrock 2차 정밀 분석(토큰 90% 절감 목표)과 Jira 자동 등록은 해커톤 기간 안에 끝내지 못했다
• Bedrock 연동에만 fix 커밋 다섯 개를 쓴 시간만큼 다른 기능에 쓸 시간이 줄었다. SDK 선택 전에 인코딩·서명 이슈를 먼저 찾아봤다면 더 빨리 갈 수 있었을 것 같다
• ChromaDB RAG는 붙였지만 지연 초기화로 앱 시작 시간을 줄이는 리팩터링이 뒤늦게(v2 후반) 들어갔다. 처음부터 무거운 초기화는 지연시키는 걸 기본값으로 뒀어야 했다

 

---

7. 다음 프로젝트를 위해 바꿀 것

• AI 제공사를 여러 개 쓸 계획이면 Strategy Pattern부터 잡아두기 - 해커톤처럼 발표 중 API 장애 리스크가 있는 환경에서 특히 값어치를 한다
• 도메인 특성(여기서는 금융권 보고 절차)을 기능 목록이 아니라 설계 결정의 근거로 삼기 - 승인 게이트와 Slack 알림은 기능이 아니라 "AI가 최종 판단을 대신하지 않는다"는 원칙이 먼저였다
• 삽질은 끝난 직후 바로 글로 남기기 - 이번엔 그렇게 했더니 몇 주 뒤 회고를 쓸 때도 맥락을 다시 파낼 필요가 없었다

 

로그를 가장 빨리 읽는 방법은 로그를 더 빨리 읽는 게 아니라,
애초에 사람이 읽지 않아도 되는 형태로 미리 부검해두는 것이었다.

 

 

Incident Autopsy - 2026 KB데이타시스템 사내 해커톤 대상, 팀 End-Gamers | GitHub