DevOps 엔지니어가 AI를 사용하여 운영 장애(Production Incidents)를 더 빠르게 분류(Triage)하는 방법

새벽 02:14에 호출(Pager)이 울립니다. 체크아웃 지연 시간(Latency)은 상승하고, 에러율(Error rate)은 치솟고 있으며, 당신에게는 세 개의 대시보드, 로그의 벽, 그리고 반쯤 잠든 뇌가 있을 뿐입니다. 무엇이 잘못되었는지 알게 된 후의 해결(Fix)은 보통 빠릅니다. 비용이 많이 드는 부분은 분류(Triage) 단계, 즉 "실제로 무엇이 고장 났으며, 무엇이 변했는가?"를 파악하는 첫 15분입니다.

그 분류 시간(Triage window)이야말로 AI가 가장 큰 도움을 줄 수 있는 지점이자, AI에게 명령어를 실행하도록 허용했을 때 가장 위험해질 수 있는 지점입니다. 여기서는 운영 환경(Production)의 열쇠를 넘겨주지 않으면서도 AI를 사용하여 속도를 높이는 방법을 소개합니다.

장애 발생 시 AI를 안전하게 사용하는 규칙

AI는 읽고 추론합니다. 인간은 명령어를 실행합니다.

장애가 진행 중인 동안 당신은 수면 부족 상태이며 시간 압박을 받습니다. 이는 당신이 완전히 이해하지 못하는 명령어를 붙여넣기에 최악의 상태입니다. 따라서 명확한 선을 그으십시오. AI는 증거를 살펴보고 계획을 제안하는 것까지만 허용됩니다. 어떤 것도 실행하는 것은 절대 허용되지 않습니다. AI가 제안하는 모든 명령어는 당신의 눈과 손을 거쳐야 합니다.

실제로 이는 모델을 당신 옆에 앉아 있는, 매우 빠르고 박학다식한 주니어 SRE(Site Reliability Engineer)처럼 대한다는 것을 의미합니다. AI는 요약, 상관관계 분석(Correlate), 가설 설정(Hypothesize), 명령어 초안 작성(Draft commands)을 할 수 있지만, 키보드를 잡고 있는 것은 당신이며, 실행하기 전에 각 명령어를 읽어야 합니다.

이 글에서 단 한 가지만 얻어간다면, 바로 이것을 가져가십시오.

1단계: 쏟아지는 정보(Firehose)를 요약본으로 전환하기

AI가 진정으로 뛰어난 첫 번째 능력은 새벽 2시에 당신이 읽을 수 있는 것보다 더 많은 텍스트를 읽는 것입니다. 가공되지 않은 자료(Raw material)를 붙여넣고 정답이 아닌 구조(Structure)를 요청하십시오:

• 발생 중인 알람 (이름, 심각도(Severity), 레이블(Labels), 지속 시간)
• 에러 로그(Error logs)의 대표적인 샘플
• 최근 배포(Deploy) / 변경(Change) 이력
• 관련 대시보드 수치 (p99 latency, 에러율, 포화도(Saturation))

그런 다음 의도적으로 다음과 같이 프롬프트(Prompt)를 작성하십시오:

"여기에 현재 발생 중인 운영 장애에 대한 알람, 로그 및 최근 변경 사항이 있습니다. 현재 상황을 5개의 불렛 포인트로 요약하고, 가능성이 높은 순서대로 상위 3가지 가설을 나열하십시오. 그리고 각 가설에 대해 이를 확인하거나 배제할 수 있는 단 하나의 읽기 전용(Read-only) 명령어를 제공하십시오. 상태를 변경하는(Changes state) 명령어는 제안하지 마십시오."

그 마지막 문장이 중요합니다. 제약 조건이 없다면, 모델들은 첫 번째 단계로 kubectl rollout restart를 제안하는 것을 매우 좋아합니다. 여러분이 먼저 원하는 것은 진단(Diagnostics)입니다.

2단계: 명령어를 영향 범위(Blast Radius)에 따라 정렬하기

훌륭한 장애 대응 AI 프롬프트는 제안된 모든 명령어에 대해 위험 분류(Risk Classification)를 강제합니다. 각 명령어에 다음과 같은 라벨을 붙이도록 요청하십시오:

• safe (안전) — 순수 읽기 전용(Read-only): kubectl get, journalctl, ss, ip, cat, grep, promtool query
• caution (주의) — 셸(Shell)에 접속하거나 작은 변경을 수행: kubectl exec, docker exec, 비운영(Non-prod) 설정 편집
• destructive (파괴적) — 재시작, 삭제, 스케일 인(Scale-to-zero), 방화벽 변경, 마이그레이션(Migrations), 복구(Restores)

그다음, 모델은 가장 안전한 것부터 순서대로 정렬해야 합니다. 여러분은 위에서 아래로 작업을 진행하며, 진단이 내려지는 즉시 작업을 중단합니다. 원인을 확인하기도 전에 파괴적인 "해결책"을 시도했다가 상황이 더 악화되는 장애의 수는 우울할 정도로 높습니다. 강제된 '가장 안전한 순서 우선(Safest-first)' 정렬은 이를 방지하기 위한 저렴한 가드레일(Guardrail)입니다.

팁: 표준 장애 대응 프롬프트를 스니펫 관리자(Snippet manager)나 프롬프트 라이브러리에 보관하여, 새벽 2시에 직접 작성하는 일이 없도록 하십시오. 저희는 정확히 이 용도로 AI 장애 대응 프롬프트(AI incident-response prompts) 세트를 유지하고 있습니다.

3단계: "무엇이 변했는지" 자동으로 상관관계 분석하기

대부분의 장애는 변경 사항(Change)에 의해 발생합니다. 모델에게 원시 입력값(Raw inputs), 즉 알람 시작 시간, 최근 몇 번의 배포(Deploys), 설정 변경(Config changes), 인프라 이벤트(Infra events)를 제공하면 타임라인을 맞추는 데 매우 능숙합니다. 다음과 같이 질문하십시오:

"지연 시간 급증(Latency spike)이 02:09 UTC에 시작되었습니다. 여기 지난 6시간 동안의 배포 로그와 설정 변경 이력이 있습니다. 02:09에 가장 근접하게 변경된 사항은 무엇이며, 그것이 어떤 메커니즘을 통해 이러한 증상을 유발할 수 있습니까?"

이 지점이 AI가 지친 인간을 일상적으로 이기는 부분입니다. AI는 여러분이 문제라고 생각하는 서비스에만 매몰되는 터널 시야(Tunnel vision) 현상을 겪지 않습니다. AI는 keepalived VIP 변경, 커넥션 풀(Connection-pool) 조정, 또는 교체된 인증서(Cert) 등을 포착할 것입니다. 즉, 여러분이 20분 후에나 발견했을 법한 하위 3계층의 지루한 변경 사항을 찾아냅니다.

4단계: 조사하는 동안 커뮤니케이션 초안 작성하기

장애 커뮤니케이션 (Incident comms)은 여러분이 가질 여유조차 없는 주의력을 대가로 지불해야 하는 세금과 같습니다. 이를 모델에게 맡기세요:

"결제 기능 저하 (degraded-checkout) 장애에 대해 고객 대상 상태 페이지 (status-page) 업데이트 문구를 작성해줘. 내부 전문 용어는 제외하고, 근본 원인 (root cause)에 대한 추측은 하지 말 것. 약 3문장 정도로 작성해줘. 그다음, 현재 심각도 (severity)와 우리가 확인 중인 사항을 포함하여 장애 채널 (incident channel)에 올릴 한 줄짜리 내부 업데이트 문구도 작성해줘."

단 몇 초 만에 적절한 어조로 작성된 고객용 업데이트와 내부용 업데이트를 모두 얻을 수 있습니다. 여러분은 내용을 훑어보고 단어 하나를 수정한 뒤 게시하면 됩니다. 조사를 위해 글을 쓰느라 흐름을 끊을 필요가 없습니다.

5단계: 타임라인을 바탕으로 사후 분석 보고서 (Postmortem) 초안 작성하기

장애가 해결되었을 때가 타임라인이 가장 생생하며, 실제로 기록을 남길 가능성도 가장 높습니다. 장애 채널의 스크롤 백 (scrollback) 기록과 명령어 히스토리 (command history)를 붙여넣고, 비난 없는 사후 분석 (blameless postmortem) 초안을 요청하세요. 요약, 타임라인, 근본 원인 (root cause), 영향 (impact), 잘된 점, 개선할 점, 그리고 조치 사항 (action items)을 포함하도록 합니다. 여러분은 백지 상태와 마주하는 대신 초안을 편집하게 됩니다. 이것이 사후 분석 보고서가 작성되느냐, 아니면 작성되지 못하느냐를 결정짓는 차이입니다.

주의해야 할 사항 (What NOT to do)

언급할 가치가 있는 몇 가지 실패 사례는 다음과 같습니다:

• 비밀 정보를 붙여넣지 마세요. 모델에 입력하기 전에 토큰 (tokens), 비밀번호, 내부 호스트 이름 (internal hostnames), 고객 데이터를 반드시 삭제하세요. 프롬프트 (prompt)를 실수로 공개 채널에 게시할 수도 있는 스크린샷처럼 취급하십시오.
• 지표 (metrics)를 지어내게 하지 마세요. 만약 여러분이 실제 지표 이름을 제공하지 않은 채 PromQL을 요청한다면, 모델은 아주 자신 있게 가짜 이름을 만들어낼 것입니다. 실제 지표 이름을 제공하거나, 명확하게 표시된 플레이스홀더 (placeholders)를 사용하도록 지시하세요.
• 자신감 넘치는 명령어를 신뢰하지 마세요. 언어 모델에서 "자신감"과 "정확성"은 무관합니다. '안전 우선' 순서가 존재하는 이유는 틀렸지만 자신만만하게 제안하는 명령어가 읽기 전용 (read-only) 상태로 유지되도록 하기 위함입니다.
• "명백한" 수정 사항이라고 해서 인간의 검토를 건너뛰지 마세요. 새벽 2시에 보이는 명백한 해결책이 오히려 장애를 재발시키는 원인이 되기도 합니다.

워크플로우에서의 위치

시작하기 위해 별도의 플랫폼이 필요하지는 않습니다. 저장된 프롬프트(Prompt)와 메모장(Scratch buffer)만 있어도 오늘 밤 대부분의 가치를 얻을 수 있습니다. 중요한 것은 구조입니다. 쏟아지는 정보(Firehose)를 요약하고, 읽기 전용 확인(Read-only confirmations)을 통해 가설을 세우며, 타임라인을 상관 분석(Correlate)하고, 커뮤니케이션 초안을 작성하되, 모든 명령은 사람이 실행하도록 하는 것입니다.

만약 이 흐름의 구조화된 버전을 원한다면 — 증상과 로그를 붙여넣기만 하면 위험도가 분류된 계획, 안전을 최우선으로 하는 실행 계획, 그리고 사후 분석(Postmortem) 초안을 얻을 수 있는 방식 — 그것이 바로 우리가 AI Incident Response Assistant를 만든 이유입니다. 하지만 이 기법 자체로도 충분한 가치가 있습니다. 프롬프트를 가져다 쓰고, 사람은 키보드 앞에 머물며, 장애 발생 후 첫 15분을 되찾으십시오.

생성된 장애 대응 계획과 명령은 보조적인 수단이며, 권위적인 결정이 아닙니다. 운영 환경(Production)에서 무엇인가를 실행하기 전에 항상 자신의 시스템을 바탕으로 권장 사항을 검증하십시오.

이 기사는 원래 DevOps AI ToolKit — 클라우드 엔지니어를 위한 실무적인 AI 워크플로우 — 에 게시되었습니다.