작년 추석 장애가 올해 추석 2주 전에 점검표로 돌아왔습니다

명절 연휴가 끝나면 장애 회고가 하나 늘어납니다. AI 운영·관제 플랫폼을 만들면서 여러 운영 데이터를 들여다보니, 트래픽이 급증하는 시기는 놀랄 만큼 규칙적이었습니다. 명절, 대형 프로모션, 월말 정산. 해마다 같은 시기에 같은 계열의 장애가 돌아옵니다.

문제는 그 패턴을 기억하는 주체였습니다. "작년 추석에 예약이 몰려서 커넥션 풀이 바닥났었죠" 같은 말은 회의실에서만 존재합니다. 시스템 어디에도 '추석과 이 장애가 관련 있다'는 데이터는 없었습니다. 그 말을 할 수 있는 담당자가 이직하면, 조직은 같은 수업료를 다시 냅니다.

그래서 이벤트 캘린더를 장애 데이터에 연결하는 기능을 만들었습니다. 결과부터 말하면, 작년 추석에 기록된 장애가 올해 추석 2주 전에 AI 사전점검표로 자동으로 돌아왔습니다. 그 과정에서 설계상 갈림길이 몇 개 있었고, 이 글은 그 기록입니다.

시스템은 왜 작년 장애를 기억하지 못할까

인시던트는 보통 날짜로 기록됩니다. '2025-10-06 예약 급증 장애'는 정확한 기록이지만, 검색해야만 나오는 과거입니다. 내년 추석이 다가와도 이 기록이 스스로 걸어 나오는 일은 없습니다. 날짜는 한 번 지나가면 다시 오지 않기 때문입니다.

재발 방지 문서도 마찬가지였습니다. 장애 회고를 잘 써서 위키에 올려도, 다음 명절 전에 그 문서를 꺼내 보는 건 결국 사람의 기억력입니다. 처음엔 회고 문화를 다듬으면 될 문제라고 생각했지만, 파보니 문서의 품질이 아니라 소환의 구조가 없는 게 원인이었습니다. 지식이 있는 게 아니라, 지식이 있는 사람이 있었던 겁니다.

날짜가 아니라 '시리즈'에 연결한다

돌파구는 추석을 날짜가 아니라 반복 개념으로 다루는 것이었습니다. 2025년 추석과 2026년 추석은 다른 날짜지만 같은 '추석'입니다. 그래서 인시던트를 개별 날짜가 아니라 이벤트 시리즈 키에 연결했습니다. '2025-10-06 장애'가 아니라 '추석에 얽힌 장애'가 되는 겁니다.

그래프에는 (인시던트)-[발생시기 {연도, 기간}]→(이벤트 시리즈) 형태의 관계로 투영하고, 이 관계를 온톨로지 스키마에 등록했습니다. 스키마에 올라간 덕분에 채팅과 그래프 질의에서 "추석 관련 장애 보여줘"가 실제로 답이 나오는 질문이 됩니다.

이 연결이 만들어지는 순간, 담당자 머릿속에만 있던 '명절마다 터지는 그 장애'가 조직의 데이터가 됩니다. 사람은 떠나도 그래프의 관계는 남습니다. 의사결정자 관점에서 이 기능의 본질은 장애 관리 도구가 아니라 지식의 소유권 이전입니다.

2주 전, 출처가 달린 점검표가 먼저 도착한다

올해 이벤트가 다가오면 리드타임(예: 2주 전)에 사전점검 알림이 생성됩니다. AI는 같은 시리즈에 연결된 과거 인시던트를 인용해 점검표를 작성합니다. "작년 명절에 트래픽 급증으로 예약 장애 발생 — 올해는 커넥션 풀·큐 용량 사전 점검" 같은 식입니다.

여기서 공들인 부분이 출처 표기입니다. 점검표에는 근거 이벤트의 이름·기간과 근거 인시던트 목록이 달리고, 각 인시던트는 딥링크로 바로 열립니다. 근거 없는 AI 점검표는 그럴듯한 목록일 뿐이지만, 출처가 달린 점검표는 운영자가 하나씩 눌러 검증할 수 있는 문서가 됩니다. 이 차이가 현장에서 점검표를 실제로 쓰게 만드는 요소였습니다.

알림 창과 귀속 창은 다른 물건입니다

설계에서 가장 크게 배운 지점입니다. 이 기능에는 시간 창이 두 개 있습니다. 하나는 사전 알림용 리드타임(2주 전), 다른 하나는 장애를 이벤트에 귀속시키는 창(이벤트 기간 ±3일)입니다.

처음엔 창 하나로 퉁칠 수 있을 것 같았지만, 파보니 전혀 다른 물건이었습니다. 넉넉한 알림 창을 인과 판정에 재사용하면 "이벤트 74일 전에 터진 장애"가 이벤트 탓이 되는 오판이 생깁니다. 알림은 넉넉하게, 인과는 엄격하게. 두 창을 분리하고 나서야 점검표가 깨끗해졌습니다.

검증도 대조로 했습니다. 평일 알람은 이벤트 언급이 0이어야 정상이고, 이벤트 기간 알람은 작년 인시던트를 인용해야 정상입니다. 이 두 케이스를 나란히 돌려 양방향으로 확인했습니다. 한쪽만 확인하면 '이벤트를 과하게 갖다 붙이는' 오류를 놓칩니다.

이력이 쌓일수록 강해지는 자산형 기능

한계도 분명합니다. 이벤트 수가 적고 장애 이력이 짧으면 인용할 과거가 없습니다. 이 기능은 첫날부터 화려한 종류가 아니라, 이력이 쌓일수록 강해지는 자산형입니다. 도입 시점에는 기대치를 그렇게 잡아야 실망이 없습니다.

귀속이 틀리는 경우도 경계해야 합니다. 우연히 그 기간에 터진 무관한 장애가 시리즈에 붙으면 내년 점검표가 오염됩니다. 그래서 귀속 창을 엄격히 잡는 것과 별개로, 최종 연결은 사람이 확정하는 게이트를 뒀습니다. 자동 후보 제시까지가 기계의 일이고, 인과의 확정은 사람의 일입니다.

입구도 품질을 결정합니다. 이벤트 일괄 등록은 엑셀 템플릿으로 받았습니다. 안내 시트를 포함하고, 중복은 건너뛰고, 오류는 행 단위로 리포트합니다. 운영자가 채우는 데이터는 입구가 불편하면 애초에 쌓이지 않습니다.

결국 이 기능도 '무엇을 조직의 재사용 지식으로 남길 것인가'라는 같은 질문 위에 서 있습니다. 같은 도구에서 문서를 지식 베이스에 올릴 때 91개 중 16개만 남긴 선별 과정을 앞선 글에서 다뤘습니다.

반복 장애를 자산으로 바꾸는 체크리스트

반복 이벤트(명절·프로모션·정산일)에 얽힌 장애는 개별 사건이 아니라 시리즈로 묶는다 — '2025-10-06 장애'가 아니라 '추석 장애'여야 내년에 소환된다

재발 방지의 자동화 = 과거 연결 + 리드타임 알림. 사람이 기억을 꺼내는 구조는 담당자와 함께 사라진다

AI가 만든 점검표에는 근거 이벤트·근거 인시던트 딥링크를 출처로 단다

알림용 리드타임과 인과 귀속 창을 분리한다 — 알림은 넉넉히, 귀속은 엄격히

시리즈 귀속의 최종 확정은 사람이 하는 게이트를 둔다 — 오염된 연결은 내년 점검표를 오염시킨다

운영자가 채울 데이터는 입구(템플릿·중복 skip·행 단위 오류 리포트)가 품질을 결정한다

올해 추석 2주 전, 작년 장애를 인용한 점검표가 실데이터로 도착하는 타임라인이 성립했습니다. 담당자의 기억은 담당자와 함께 떠나지만, 시리즈로 연결된 인시던트는 조직에 남습니다. 반복되는 장애가 있다면, 회고 문서를 더 잘 쓰는 것보다 그 장애를 달력에 연결하는 편이 오래갑니다.