7.3디버깅과 운영 이슈 대응 지원

장애 대응은 몇 단계로 나뉘고, 단계마다 AI 도구의 적합성이 다릅니다.

단계	적합성	이유
증상 정리와 타임라인 구성	높음	여러 로그를 읽어 시간순으로 묶는 작업
가설 생성	높음	놓친 가능성을 넓게 제시
로그·메트릭 요약	높음	대량 텍스트 압축이 강점
재현 절차 작성	중간	초안은 유용하나 검증 필요
변경 실행	낮음	되돌리기 어려운 행동
사후 기록 초안	높음	흩어진 기록 통합

패턴이 보입니다. 읽고 정리하고 제안하는 일에는 적합하고, 프로덕션을 바꾸는 일에는 적합하지 않습니다. 이 구분이 권한 설계로 이어집니다.

여기에 압박이라는 변수가 더해집니다. 장애 중에는 평소라면 하지 않을 판단을 내리기 쉽고, 승인 화면을 읽지 않고 누르게 됩니다. 5.3에서 다룬 승인 피로가 가장 위험한 시점에 가장 심해지는 셈입니다. 따라서 장애 대응용 권한 프로필은 평상시보다 더 좁게 설계해야 합니다. 흔한 직관과 반대라는 점을 기억해 두십시오.

대응용 환경은 별도 권한 프로필로 분리하는 것이 안전합니다.

{
  "permissions": {
    "allow": [
      "Bash(kubectl get *)",
      "Bash(kubectl describe *)",
      "Bash(kubectl logs *)",
      "Read(./runbooks/**)"
    ],
    "deny": [
      "Bash(kubectl delete *)",
      "Bash(kubectl apply *)",
      "Bash(kubectl scale *)"
    ]
  }
}

조회 계열만 허용하고 상태를 바꾸는 명령은 차단합니다. 이렇게 하면 도구가 진단을 도우면서도 변경은 사람의 손을 반드시 거치게 됩니다.

경계를 정할 때 쓰는 기준은 5.1과 같습니다. 되돌릴 수 있는가, 영향 범위가 어디까지인가입니다. 다만 운영 환경에서는 한 가지가 더해집니다. 관측 가능한가입니다. 변경이 즉시 확인되지 않는 작업(비동기 배치, 캐시 무효화, 설정 전파)은 되돌림 가능성과 무관하게 사람이 실행하는 편이 안전합니다. 잘못되었을 때 알아차리는 데 시간이 걸리기 때문입니다.

에이전트가 제안한 명령을 사람이 그대로 붙여 넣는 관행도 주의해야 합니다. 실행 주체는 사람이지만 판단 주체는 도구인 상태라, 권한 분리의 취지가 사라집니다. 제안된 명령에는 무엇을 왜 바꾸는지, 되돌리는 명령은 무엇인지를 함께 요구하는 것이 실무적인 보완입니다.

대응 중 흔한 실수는 로그 전체를 컨텍스트에 밀어 넣는 것입니다. 문제가 세 가지 생깁니다. 비용이 커지고, 지연이 늘고, 정확도가 오히려 떨어집니다. 관련 없는 내용이 많을수록 모델이 신호를 찾기 어려워지기 때문입니다.

선별 기준을 미리 정해 두십시오.

• 시간창 — 증상이 처음 관측된 시각 전후로 좁힙니다.
• 상관 식별자 — 요청 ID나 트레이스 ID로 한 흐름만 따라갑니다.
• 심각도 — 오류와 경고를 먼저 보고, 정보 수준은 필요할 때만 넣습니다.
• 대표 표본 — 같은 형태가 반복되면 전부가 아니라 몇 건과 발생 횟수를 넣습니다.

# 전체를 넣지 않고 시간창과 상관 ID로 좁혀서 전달한다
kubectl logs deploy/api --since=15m \
  | grep -E 'ERROR|WARN' \
  | grep "$TRACE_ID" \
  | head -200 > /tmp/slice.log

마지막 항목인 대표 표본이 특히 효과적입니다. 같은 오류가 4만 건 있을 때 4만 줄을 넣는 것보다 **"이 형태의 오류가 4만 건, 대표 사례 3건"**으로 요약해 넣는 편이 진단에 훨씬 유리합니다. 반복은 정보량을 더하지 않기 때문입니다.

한 가지 더. 운영 로그에는 개인정보와 자격 증명이 섞여 있을 수 있습니다. 대응 중이라도 5.4의 저장 전 처리 원칙은 그대로 적용됩니다. 급하다는 이유로 원본을 그대로 넣으면, 그 내용이 세션 기록과 관측 도구에 남습니다.

대응이 끝나면 기록이 남지만, 대부분의 조직에서 그 기록은 읽히지 않는 문서로 쌓입니다. 아키텍트가 설계할 것은 기록이 다음 대응에 쓰이게 만드는 경로입니다.

효과적인 방법은 사후 기록을 런북과 지식 파일로 환류시키는 것입니다. 사고에서 얻은 판단 기준을 저장소의 규칙 파일이나 런북에 반영해 두면, 다음 대응에서 도구가 그 맥락을 갖고 시작합니다. 사고 보고서 자체보다 이 환류가 실질적인 가치를 만듭니다.

환류할 때 담아야 할 것은 다음과 같습니다.

• 증상에서 원인으로 이어진 경로 — 무엇을 보고 무엇을 의심했는가
• 틀린 가설과 배제 근거 — 다음에 같은 길로 돌지 않게 합니다
• 조회 명령 모음 — 이번에 유용했던 명령을 런북에 남깁니다
• 판단 경계 — 무엇을 사람이 실행해야 했는지

두 번째 항목이 자주 빠집니다. 보고서는 대개 맞았던 가설만 기록하지만, 틀린 가설과 그것을 배제한 근거가 다음 대응의 시간을 더 많이 줄여 줍니다.

마지막으로 사고 기록에 담기는 정보의 민감도를 확인하십시오. 운영 로그 발췌, 내부 시스템 구조, 자격 증명 경로가 포함되기 쉽고, 이 문서는 대개 넓게 공유됩니다. 공유 범위와 보관 기간을 정해 두는 것이 기록 설계의 마지막 항목입니다.