AI 로그 트리아지 디버깅 루프

AI가 만든 기능이 운영 환경에서 실패할 때 가장 위험한 대응은 “에러 메시지를 더 많이 찍어 보자”로 시작하는 것입니다. 로그가 많아지면 원인이 더 잘 보일 것 같지만, 실제로는 사용자 영향, 재현 조건, 최근 변경, 외부 의존성, 데이터 상태, 브라우저 콘솔, 서버 로그가 뒤섞여 오히려 판단이 느려집니다. AI 로그 트리아지 디버깅 루프는 장애가 터졌을 때 로그를 무작정 늘리는 방식이 아니라, 먼저 증상을 고정하고, 필요한 증거만 수집하고, 가설을 좁힌 뒤, 수정과 롤백을 숫자 기준으로 결정하는 VIBE 코딩 운영 방식입니다.

초보자는 이 루프를 “로그를 보는 순서”로 이해하면 됩니다. 전문가에게는 더 엄격합니다. 로그 레벨, 상관관계 ID, 사용자 세션 범위, 배포 시각, 요청 경로, 오류율, 지연 시간, 재시도 횟수, 큐 적체, 데이터 변경 이력, 프론트엔드 콘솔 오류를 하나의 타임라인으로 묶고, AI에게 그 타임라인을 기준으로만 원인 후보를 제시하게 합니다. 이렇게 해야 AI가 그럴듯한 추측을 길게 늘어놓는 대신 실제 증거가 있는 가설부터 다루게 됩니다.

핵심 결론

AI 로그 트리아지 디버깅 루프의 핵심은 “로그를 더 찍기”가 아니라 “의사결정 가능한 증거 패킷을 만들기”입니다. 장애 대응자는 먼저 사용자에게 보이는 증상, 영향 범위, 시작 시각, 최근 배포, 재현 경로, 현재 완화 상태를 짧게 고정합니다. 그다음 로그와 메트릭을 같은 시간축에 올려 어떤 요청, 어떤 사용자군, 어떤 데이터 조건에서만 실패하는지 좁힙니다.

AI에게는 전체 로그 덤프를 그대로 던지지 않습니다. 요청 ID, 시간 범위, 에러 유형, 샘플 수, 정상 샘플과 실패 샘플의 차이, 관련 코드 경로, 최근 변경 파일, 이미 배제한 원인을 포함한 요약을 줍니다. 이 패킷을 기준으로 AI가 원인 후보를 3개 이하로 제시하고, 각 후보마다 확인 명령, 예상 관측값, 수정 범위, 롤백 기준을 함께 내게 합니다.

좋은 루프는 세 가지 결정을 빠르게 합니다. 첫째, 지금 롤백해야 하는지 아니면 작은 패치로 충분한지 결정합니다. 둘째, 어떤 로그는 유용하고 어떤 로그는 소음인지 분리합니다. 셋째, 수정 후 같은 장애가 재발하지 않도록 회귀 테스트와 운영 대시보드에 어떤 신호를 남길지 결정합니다.

왜 중요한가

AI는 로그가 많을수록 더 확신 있게 틀릴 수 있다

LLM은 긴 로그를 보면 패턴을 찾아내는 능력이 있지만, 그 패턴이 실제 원인이라는 보장은 없습니다. 특히 같은 오류 문자열이 여러 계층에서 반복되면 AI는 가장 눈에 띄는 메시지를 원인으로 착각하기 쉽습니다. 예를 들어 결제 버튼 클릭 실패의 표면 오류가 timeout처럼 보이더라도 실제 원인은 권한 토큰 만료, 잘못된 캐시, 배포 직후 마이그레이션 지연, 프론트엔드 중복 제출일 수 있습니다. 로그 양이 많아질수록 증거의 순서와 범위를 사람이 정해 주어야 합니다.

로그 트리아지는 AI의 추론 범위를 줄여 줍니다. “어제부터 에러가 납니다”가 아니라 “13:05 UTC 이후 모바일 Safari에서 POST /checkout 요청 중 4.8%가 30초 이상 지연되고, 같은 시간대 서버 배포와 결제 웹훅 재시도 증가가 있었다”라고 주면 AI는 훨씬 좁은 원인 공간에서 일합니다.

운영 로그는 개발자 디버깅과 다르다

로컬 개발에서는 실패를 재현하고 콘솔을 보면 됩니다. 운영에서는 사용자가 이미 실패를 겪고 있고, 모든 데이터를 마음대로 볼 수 없으며, 개인 정보와 민감한 값은 숨겨야 합니다. 따라서 운영 로그는 원인 분석뿐 아니라 책임 있는 정보 취급을 포함해야 합니다. 요청 본문 전체를 저장하거나 외부 인증값을 그대로 남기는 방식은 디버깅을 편하게 만들 수 있지만 장기적으로 더 큰 사고를 만듭니다.

VIBE 코딩에서 AI에게 로그 개선을 맡길 때는 “필요한 맥락은 남기되 민감한 값은 남기지 않는다”는 계약을 먼저 줘야 합니다. 상관관계 ID, 익명화된 사용자 구간, 기능 플래그 이름, 경로, 상태 코드, 처리 시간, 재시도 횟수, 큐 길이 같은 운영 신호는 유용합니다. 반대로 원문 입력값, 외부 서비스 인증값, DB 연결 정보, 개인 식별 정보는 공개 로그나 AI 프롬프트에 들어가면 안 됩니다.

실제 작업 순서

1단계: 증상 잠금

먼저 장애 문장을 한 줄로 고정합니다. 좋은 문장은 “누가, 어디서, 무엇을 하다가, 어떤 결과를 봤는가”를 포함합니다. 예를 들어 “일부 사용자가 새 글 저장 후 목록으로 돌아오면 방금 저장한 글이 보이지 않는다”는 좋은 시작입니다. 반면 “캐시가 이상한 것 같다”는 아직 원인 추측입니다. AI에게는 증상과 원인을 분리하라고 지시해야 합니다.

증상 잠금에는 영향 범위도 포함합니다. 전체 사용자 장애인지, 특정 브라우저인지, 특정 플랜인지, 특정 지역인지, 특정 데이터 크기인지 확인합니다. 이 범위를 정하지 않으면 작은 버그를 전체 장애처럼 대응하거나, 반대로 실제 장애를 단일 사용자 이슈로 과소평가할 수 있습니다.

2단계: 시간축 만들기

운영 디버깅은 시간 싸움입니다. 장애 시작 추정 시각, 마지막 정상 시각, 최근 배포 시각, 설정 변경 시각, 외부 서비스 상태 변화, 데이터 마이그레이션 시각을 UTC 기준으로 나열합니다. 같은 시각대에 오류율, 지연 시간, 재시도, 큐 적체, 브라우저 오류가 어떻게 움직였는지 붙입니다.

AI에게는 “이 타임라인 밖의 원인을 먼저 말하지 말라”고 지시합니다. 근거 없는 일반론을 줄이고, 실제 변화와 증상 사이의 관계를 보게 만들기 위해서입니다. 배포 직후 장애가 시작됐다고 해서 무조건 배포가 원인인 것은 아니지만, 배포와 무관한 오래된 구조 문제를 먼저 고치려 들면 완화가 늦어집니다.

3단계: 증거 패킷 작성

증거 패킷은 AI에게 넘길 최소 단위입니다. 포함할 것은 문제 설명, 영향 범위, 시간 범위, 정상 샘플과 실패 샘플, 요청 경로, 상태 코드, 상관관계 ID, 최근 변경 요약, 관련 로그 10~30줄, 브라우저 콘솔 오류, 이미 시도한 완화 조치입니다. 포함하지 말아야 할 것은 원문 사용자 입력, 실제 인증값, 전체 환경 파일, 원본 개인 정보, 내부 관리 링크입니다.

패킷은 짧을수록 좋지만, 짧다는 말이 빈약하다는 뜻은 아닙니다. 정상 샘플과 실패 샘플을 나란히 주면 AI가 차이를 찾기 쉽습니다. 실패 로그만 주면 AI는 “실패한 이유”보다 “실패 로그에서 흔한 단어”를 따라갈 수 있습니다.

4단계: 가설을 3개 이하로 제한

AI에게 원인 후보를 많이 내게 하면 작업이 퍼집니다. 운영 대응에서는 가장 가능성 높은 가설 3개만 다룹니다. 각 가설은 근거 로그, 반증 방법, 확인 명령, 수정 범위, 위험도, 예상 복구 시간을 가져야 합니다. 가설에 반증 방법이 없다면 그것은 아직 운영 가설이 아니라 추측입니다.

예를 들어 “캐시 무효화 누락”이라는 가설은 목록 API 응답의 생성 시각, 상세 페이지 응답, 캐시 헤더, 재검증 이벤트, 같은 사용자에서 새로고침 후 변화 여부로 확인할 수 있습니다. “서버가 느림”처럼 범위가 큰 말은 지연 시간 분포, 특정 경로, DB 쿼리 시간, 외부 호출 시간으로 쪼개야 합니다.

5단계: 완화와 수정 분리

장애 대응에서 가장 흔한 실수는 근본 수정과 즉시 완화를 섞는 것입니다. 사용자가 계속 실패하고 있다면 먼저 기능 플래그 끄기, 이전 버전 롤백, 캐시 우회, 큐 소비 속도 조정, 문제 경로 임시 차단처럼 되돌릴 수 있는 완화를 고려합니다. 근본 수정은 재현과 테스트가 확보된 뒤 진행합니다.

AI에게는 “사용자 영향이 지속되면 코드 수정 제안보다 완화 옵션을 먼저 제시하라”고 지시할 수 있습니다. 특히 결제, 로그인, 데이터 삭제, 알림 발송처럼 되돌리기 어려운 경로에서는 작은 패치라도 위험할 수 있습니다.

6단계: 검증 후 로그를 줄인다

디버깅 중 임시 로그를 추가했다면 해결 후 반드시 정리합니다. 운영 로그는 계속 쌓이는 비용이고, 불필요한 로그는 다음 장애 때 소음을 만듭니다. 남길 신호는 지표화합니다. 예를 들어 “목록 캐시 재검증 실패”는 단순 문자열 로그보다 카운터, 실패율, 경로별 분포, 알림 임계값으로 남기는 편이 낫습니다.

상황별 예시

예시 A: 저장은 성공했는데 목록에 보이지 않는다

사용자는 글 저장 후 성공 토스트를 봤지만 목록에는 새 글이 없습니다. AI가 처음 제안할 수 있는 일반론은 “목록을 다시 fetch하세요”입니다. 그러나 로그 트리아지 루프에서는 먼저 정상과 실패를 분리합니다. 상세 페이지 직접 접근은 200인지, 목록 API 응답에 새 글이 빠졌는지, 서버 DB에는 row가 있는지, 캐시 재검증 이벤트가 성공했는지 확인합니다.

증거 패킷에는 저장 요청 ID, 저장 응답 시각, 목록 요청 시각, 두 요청의 사용자 구간, 캐시 헤더, 재검증 결과, 최근 배포 변경을 넣습니다. AI에게는 캐시 무효화 누락, 목록 정렬 조건 오류, 권한 필터 누락 중 무엇이 가장 가능성 높은지 근거와 반증 방법을 요구합니다. 승인 기준은 “새 저장 후 10초 안에 목록과 상세가 같은 slug를 보여 주고, 실패율이 0.5% 미만이며, 캐시 우회 없이 반복 재현이 통과한다”처럼 숫자로 둡니다.

예시 B: 배포 후 모바일에서만 버튼이 멈춘다

PC에서는 정상인데 모바일에서만 제출 버튼이 로딩 상태로 멈춥니다. 이때 서버 로그만 보면 아무 요청이 없을 수 있습니다. 브라우저 콘솔, 네트워크 탭, 터치 이벤트, disabled 상태, viewport 조건, 클라이언트 라우팅 오류를 함께 봐야 합니다.

AI에게는 “서버 로그에 요청이 없으니 클라이언트 이벤트 경로를 먼저 의심하라”고 지시합니다. 최근 변경에서 반응형 레이아웃, z-index, form submit handler, optimistic UI, loading state 변경을 찾습니다. 실패 모드는 이중 제출 방지 로직이 실패 후 해제되지 않는 경우, 모바일 overlay가 버튼을 가리는 경우, 클라이언트 예외가 catch되지 않아 상태가 멈추는 경우입니다.

예시 C: 외부 연동 재시도 때문에 큐가 밀린다

AI가 만든 자동화 기능이 외부 연동 실패 때 무제한에 가까운 재시도를 만들면 큐가 밀리고 정상 작업까지 늦어집니다. 로그에는 같은 작업 ID가 반복되고, 지연 시간과 재시도 횟수가 같이 증가합니다. 여기서 중요한 것은 원인 수정 전에 재시도 폭주를 멈추는 것입니다.

중단 기준은 명확해야 합니다. 예를 들어 10분 동안 큐 대기 시간이 5분을 넘거나 같은 작업의 재시도가 5회를 넘으면 해당 연동을 일시 중지합니다. 승인 기준은 재시도 정책이 exponential backoff와 최대 시도 횟수를 지키고, 실패 작업이 dead-letter 상태로 분리되며, 정상 작업 처리 시간이 기준 이하로 돌아오는 것입니다.

실패 모드

실패 모드 1: 로그 원문을 그대로 AI에게 붙여 넣는다

원문 로그에는 생각보다 많은 민감 정보가 섞입니다. 사용자의 입력 문장, 이메일, 내부 경로, 외부 서비스 인증값, 결제 식별자, 관리자 메모가 포함될 수 있습니다. AI에게 넘기기 전에는 식별자를 익명화하고, 값 자체가 아니라 길이, 타입, 성공 여부, 상태 코드, 해시화된 상관관계만 남깁니다. “디버깅이 급하다”는 이유로 원문을 그대로 공유하면 장애 하나를 더 큰 보안 사고로 키울 수 있습니다.

실패 모드 2: 첫 번째 그럴듯한 원인을 바로 고친다

AI가 “캐시 문제로 보입니다”라고 말하면 바로 캐시 코드를 바꾸고 싶어집니다. 그러나 반증 없이 수정하면 원인이 틀렸을 때 새로운 회귀를 만듭니다. 각 가설은 반드시 관측 가능한 확인 방법을 가져야 합니다. 캐시 문제라면 캐시 우회 요청, 재검증 로그, 상세와 목록의 응답 차이를 확인합니다. 확인 전에는 수정이 아니라 조사입니다.

실패 모드 3: 장애 중 기능 개선을 같이 한다

장애 대응 중 AI가 더 나은 구조를 제안할 수 있습니다. 그러나 운영 중에는 작은 수정, 되돌릴 수 있는 수정, 검증 가능한 수정이 우선입니다. 리팩터링, 새 라이브러리 도입, 큰 상태 구조 변경은 장애를 멈춘 뒤 별도 작업으로 분리합니다. 장애 티켓의 목표는 제품 개선이 아니라 사용자 피해 중단과 재발 방지입니다.

실패 모드 4: 해결 후 임시 로그가 남는다

임시 디버그 로그는 처음에는 도움이 되지만 오래 남으면 비용과 소음을 만듭니다. 특히 반복 요청마다 큰 객체를 출력하거나, 성공 케이스까지 상세히 남기는 로그는 다음 장애의 신호를 덮습니다. 해결 후에는 임시 로그를 제거하고, 필요한 신호만 구조화된 이벤트나 지표로 남깁니다.

검증 체크리스트

• 증상 문장이 원인 추측 없이 사용자 관점으로 적혀 있는가.
• 장애 시작 시각, 마지막 정상 시각, 최근 배포 시각이 같은 기준 시간으로 정리됐는가.
• 정상 샘플과 실패 샘플이 최소 1개씩 있는가.
• 요청 ID나 상관관계 ID로 프론트엔드, 서버, 작업 큐 로그를 연결할 수 있는가.
• AI에게 넘기는 패킷에서 원문 개인 정보와 민감한 운영 값이 제거됐는가.
• 원인 가설이 3개 이하이며 각각 근거, 반증 방법, 확인 명령, 예상 관측값을 갖는가.
• 사용자 영향이 계속될 때 즉시 완화 옵션과 근본 수정 옵션이 분리됐는가.
• 수정 후 회귀 테스트, 브라우저 스모크, 운영 지표 확인이 모두 끝났는가.
• 임시 로그가 제거되거나 구조화 지표로 전환됐는가.
• 같은 장애가 다시 나면 어떤 알림이 먼저 울려야 하는지 정의됐는가.

AI에게 줄 지시 예시

트리아지 시작 프롬프트

다음 증거 패킷만 근거로 장애 원인 후보를 3개 이하로 좁혀라. 증상과 원인을 분리하고, 각 후보마다 근거 로그, 반증 방법, 확인할 파일 또는 명령, 예상 관측값, 사용자 영향, 즉시 완화 옵션, 근본 수정 옵션을 표로 제시하라. 원문 개인 정보나 민감한 운영 값이 필요하다고 요구하지 말고, 추가 정보가 필요하면 어떤 집계나 익명화된 신호가 필요한지 말하라.

코드 수정 프롬프트

원인 후보가 확인되기 전에는 코드를 수정하지 말라. 확인이 끝난 후보에 대해서만 최소 변경을 제안하라. 변경 범위는 실패 경로에 한정하고, 기존 정상 경로를 보호하는 회귀 테스트를 먼저 추가하라. 임시 로그가 필요하면 어떤 필드가 왜 필요한지 설명하고, 해결 후 제거하거나 지표로 전환하는 후속 작업을 함께 제시하라.

리뷰 프롬프트

이번 패치가 장애를 멈추는 데 필요한 최소 변경인지 검토하라. 새로운 민감 정보 출력, 과도한 로그, 무제한 재시도, 사용자에게 보이는 내부 상태, 실패 시 복구 불가능한 데이터 변경이 없는지 확인하라. 승인 기준을 만족하지 못하면 배포하지 말고 롤백 또는 기능 플래그 비활성화를 제안하라.

중단/승인 기준

중단 기준

사용자 실패율이 2%를 넘고 10분 이상 유지되거나, 결제·로그인·저장처럼 핵심 경로에서 데이터 손실 가능성이 있거나, 같은 작업의 재시도가 폭주하거나, 원문 민감 정보가 로그에 남는 정황이 보이면 새 기능 개발을 중단합니다. 이때 AI에게는 기능 개선이나 리팩터링 제안을 멈추고 완화와 증거 보존에 집중하라고 지시합니다.

배포 직후 오류율이 기준의 두 배 이상으로 오르면 작은 패치를 계속 쌓지 않습니다. 이전 정상 버전으로 롤백할 수 있는지, 기능 플래그를 끌 수 있는지, 문제 경로를 임시 우회할 수 있는지 먼저 판단합니다.

승인 기준

수정 승인은 감으로 하지 않습니다. 재현 케이스가 실패에서 성공으로 바뀌고, 정상 케이스 회귀 테스트가 통과하며, 대표 브라우저 스모크가 통과하고, 운영 지표가 기준선으로 돌아와야 합니다. 예를 들어 오류율 0.5% 미만, p95 지연 시간 1.5초 이하, 큐 대기 시간 60초 이하, 재시도 폭주 없음처럼 팀이 이해할 수 있는 숫자를 둡니다.

또한 승인에는 로그 정리도 포함됩니다. 임시 로그가 제거됐는지, 남은 로그가 구조화되어 있는지, 민감한 값이 없는지, 다음 장애 때 바로 볼 대시보드나 알림이 있는지 확인합니다. 코드는 고쳤지만 운영 신호가 없으면 같은 문제가 조용히 재발할 수 있습니다.

다음 단계

AI 로그 트리아지 디버깅 루프를 팀에 적용하려면 먼저 장애 템플릿을 하나 만드세요. 템플릿에는 증상, 영향 범위, 시간축, 정상 샘플, 실패 샘플, 최근 변경, 가설, 반증 방법, 완화, 승인 기준, 후속 테스트가 들어갑니다. 중요한 것은 템플릿을 길게 만드는 것이 아니라 장애 때 누구나 같은 순서로 생각하게 만드는 것입니다.

두 번째로 상관관계 ID를 주요 경로에 심습니다. 프론트엔드 이벤트, 서버 요청, 비동기 작업, 외부 연동이 같은 ID로 연결되면 AI에게 넘길 증거 패킷이 훨씬 좋아집니다. ID가 없으면 로그는 많은데 사건의 흐름이 보이지 않습니다.

세 번째로 장애 후 회고에서 AI 프롬프트를 업데이트합니다. 이번 장애에서 AI가 잘못 짚은 원인, 부족했던 로그, 늦게 발견한 지표, 도움이 된 확인 명령을 다음 작업 지시서에 반영합니다. VIBE 코딩의 장점은 반복입니다. 장애를 한 번 해결하고 끝내는 것이 아니라, 다음 AI 작업이 같은 실수를 덜 하도록 운영 지식을 코드와 테스트와 프롬프트에 남기는 것이 진짜 생산성입니다.

팀에 적용하는 운영 루프

장애 템플릿을 작업 지시서로 바꾼다

로그 트리아지 루프는 문서로만 두면 잘 쓰이지 않습니다. AI 작업 지시서와 이슈 템플릿에 같은 순서를 넣어야 합니다. 새 기능을 만들 때부터 “이 기능이 실패하면 어떤 로그로 알 수 있는가”, “어떤 요청 ID로 사용자 행동과 서버 처리를 연결하는가”, “어떤 지표가 기준선을 넘으면 중단하는가”를 묻습니다. 그러면 장애가 난 뒤에 급히 로그를 추가하는 대신, 기능이 태어날 때부터 관측 가능한 구조가 됩니다.

특히 AI 에이전트에게 작업을 맡길 때는 완료 조건에 운영 신호를 포함하세요. 단순히 화면이 보이면 완료가 아니라, 실패 케이스에서 어떤 이벤트가 남는지, 재시도는 몇 번까지인지, 사용자가 중복 클릭했을 때 같은 요청이 어떻게 묶이는지 확인해야 합니다. 이 조건이 없으면 AI는 행복 경로만 완성하고 장애 대응에 필요한 단서를 남기지 않습니다.

로그 레벨을 역할별로 나눈다

모든 로그를 error로 남기면 알림이 피로해지고, 모든 로그를 info로 남기면 진짜 장애를 놓칩니다. 사용자 요청 실패, 데이터 손실 가능성, 권한 경계 위반, 외부 연동 장기 실패는 높은 레벨로 둡니다. 예상 가능한 입력 오류, 사용자가 취소한 흐름, 일시적 재시도는 낮은 레벨이나 집계 지표로 둡니다.

AI에게 로그 레벨 정리를 맡길 때는 “사용자 행동으로 정상적으로 발생할 수 있는 실패와 운영자가 즉시 봐야 하는 실패를 분리하라”고 지시합니다. 또한 로그 메시지는 사람이 읽는 문장보다 검색 가능한 필드가 중요합니다. 기능 이름, 단계, 결과, 지연 시간, 재시도 횟수, 익명화된 사용자 구간, 상관관계 ID가 있어야 장애 때 필터링할 수 있습니다.

회귀 방지를 테스트와 알림으로 나눈다

수정이 끝나면 같은 장애가 테스트에서 잡히는지와 운영에서 빨리 발견되는지를 따로 봅니다. 테스트는 이미 아는 실패를 막습니다. 알림은 아직 모르는 변형을 빨리 보게 합니다. 예를 들어 목록 캐시 문제를 고쳤다면 저장 후 목록 반영 테스트가 필요하고, 동시에 목록 반영 지연이 기준을 넘을 때 알림이 필요합니다. 둘 중 하나만 있으면 부족합니다.

AI에게는 “이번 장애의 재발 방지를 테스트 1개와 운영 신호 1개로 나누어 제안하라”고 요구하세요. 테스트는 코드 변경의 안전망이고, 운영 신호는 배포 후 현실의 안전망입니다. 좋은 VIBE 코딩 루프는 두 안전망을 같이 남깁니다.

의사결정 표본

빠른 완화를 선택해야 하는 경우

핵심 기능의 실패율이 계속 오르거나, 사용자가 같은 작업을 반복해 중복 데이터가 생기거나, 재시도 때문에 다른 정상 작업까지 늦어진다면 원인 분석을 계속하기보다 완화를 먼저 선택합니다. 기능 플래그를 끄거나, 이전 안정 경로로 우회하거나, 문제 작업을 큐에서 분리하는 방식이 여기에 해당합니다. 이때 AI의 역할은 새로운 구조를 설계하는 것이 아니라 가장 작고 되돌릴 수 있는 조치를 찾는 것입니다.

코드 패치를 선택해도 되는 경우

영향 범위가 좁고, 원인 가설이 로그와 재현으로 확인됐고, 패치가 작은 파일 범위에 머물며, 회귀 테스트를 즉시 추가할 수 있다면 코드 패치를 선택할 수 있습니다. 그래도 승인 기준은 필요합니다. 패치 후 같은 요청 ID 흐름에서 실패가 사라졌는지, 정상 샘플이 유지되는지, 지표가 기준선으로 돌아오는지 확인해야 합니다.

후속 개선으로 넘겨야 하는 경우

장애 원인은 해결했지만 구조가 마음에 들지 않는 경우가 많습니다. 로그 라이브러리 교체, 전체 상태 관리 재설계, 큰 데이터 모델 정리, 관측성 플랫폼 이전은 후속 개선으로 넘깁니다. 장애 대응 중에는 사용자를 안정시키는 것이 목표입니다. 개선 욕심을 장애 패치에 섞으면 검증 범위가 커지고 롤백도 어려워집니다.