온콜(On-call) 교대 근무는 예전에는 제 저녁 시간을 통째로 잡아먹곤 했습니다. 가장 최악이었던 것은 새벽 2시에 울리는 호출(page)이 아니었습니다. 그 이후에 장애 보고서(incident report)를 작성하고, 런북(runbook)을 업데이트하며, 경영진에게 상황을 패닉에 빠진 것처럼 보이지 않게 설명하는 과정이었습니다.

지난 1년 동안 저는 DevOps 및 SRE 업무를 위해 특별히 설계된 소규모 AI 프롬프트 라이브러리를 구축했습니다. 이것들은 단순히 "상태 업데이트를 작성해줘"와 같은 의미 없는 내용이 아닙니다. 각 프롬프트는 구체적인 운영 문제를 해결합니다. 즉, 엉망인 장애 타임라인을 사후 분석(postmortem) 보고서로 변환하거나, Slack 스레드로부터 런북을 생성하거나, 다음 담당자가 실제로 따라 할 수 있는 온콜 인수인계(handoff)를 작성하는 식입니다.

여기 제가 정기적으로 사용하는 10가지 프롬프트가 있으며, 각 프롬프트의 구조와 좋은 결과물이 무엇인지 확인할 수 있도록 실제 출력 예시를 함께 제공합니다.

제가 모든 프롬프트에 사용하는 구조

아래의 모든 프롬프트는 네 가지 부분을 따릅니다:

1. 역할 (Role) — AI가 연기할 대상
2. 맥락 (Context) — 상황 및 제약 조건
3. 제약 사항 (Constraints) — 어겨서는 안 되는 규칙
4. 출력 (Output) — 정확한 형식

어느 한 부분이라도 생략하면 출력 결과는 일반적이고 무의미한 소음으로 변합니다. 저는 이를 고통스러운 경험을 통해 배웠습니다.

1. 장애 타임라인 → 구조화된 타임라인

당신은 사후 분석(postmortem)을 위해 장애 타임라인을 작성하는 SRE입니다.
여기 Slack, 대시보드, pager 메시지에서 순서 없이 복사해 온 가공되지 않은 타임라인이 있습니다: [PASTE].
깔끔한 연대순 타임라인을 생성하세요. 각 항목에는 타임스탬프(UTC), 이벤트, 출처(어떤 도구/사람), 심각도(info/warning/critical)를 포함해야 합니다. 중복된 이벤트는 병합하세요. 5분 이상의 공백이 있는 경우 "[GAP — 조사 필요]"로 표시하세요. 소스에 없는 이벤트를 임의로 만들어내지 마세요.

효과적인 이유: SRE들은 타임라인을 재구성하는 과정에서 순서가 뒤섞인 채로 붙여넣게 됩니다. 이 프롬프트는 AI가 중복을 제거하고, 타임스탬프를 정규화하며, 공백을 명시적으로 표시하도록 강제합니다. 그 공백이야말로 대개 진짜 사건이 일어난 지점이기 때문입니다.

2. 비난 없는 사후 분석(Blameless postmortem) 초안

당신은 비난 없는 사후 분석(Blameless postmortem)을 작성하는 SRE입니다.
장애: [SHORT DESCRIPTION]. 타임라인: [PASTE]. 근본 원인 (알려진 경우): [DESCRIBE].
다음 섹션들을 포함하여 사후 분석을 작성하세요: 요약 (3문장), 영향 (지속 시간, 영향을 받은 사용자, 알려진 경우 매출), 타임라인, 근본 원인 (Root Cause), 기여 요인 (Contributing Factors), 잘된 점, 잘못된 점, 조치 사항 (Action Items).
규칙: 모든 조치 사항(Action Item)에는 담당자, 마감일, 우선순위(P0/P1/P2)가 있어야 합니다. 결코 개인에게 잘못을 돌리지 마세요. 항상 시스템, 프로세스 또는 누락된 안전장치(Safeguard)의 문제로 돌리세요. "인적 오류 (human error)"라는 문구 사용을 금지합니다. 대신 이를 방지할 수 있었던 구체적인 누락된 안전장치로 대체하세요. 근본 원인을 모를 경우, 추측하지 말고 "조사 중 (Under investigation)"이라고 작성하세요.

작동 원리: "인적 오류 금지" 제약 조건이 가장 중요한 핵심입니다. 이 조건은 AI가 온콜(On-call) 엔지니어를 비난하는 대신, 실제 안전장치의 공백(알림 부재, 런북 단계 누락, 속도 제한 미비 등)을 드러내도록 강제합니다.

3. Slack 스레드를 활용한 런북(Runbook) 생성

당신은 엔지니어들이 문제를 디버깅한 느슨한 Slack 스레드를 바탕으로 런북(Runbook)을 작성하는 SRE입니다.
스레드 내용: [PASTE].
번호가 매겨진 런북을 생성하세요. 각 단계는 5분 이내에 완료할 수 있어야 합니다. 각 단계는 동작 동사(확인, 재시작, 검증, 롤백, 스케일링)로 시작하세요. 스레드에서 나타난 잘못된 시도들을 보존하여 "하지 말아야 할 것 (What NOT to do)" 섹션을 추가하세요. 이러한 잘못된 시도들이 진짜 교훈입니다. "사전 요구 사항 (Prerequisites)" 섹션(필요한 액세스 권한, 도구, 권한 등)을 추가하세요.

작동 원리: 잘못된 시도들은 올바른 단계보다 더 가치가 있습니다. 대부분의 AI 생성 런북은 이를 삭제해 버립니다. 이 프롬프트는 잘못된 시도들을 "하지 말아야 할 것" 섹션으로 생존시켜, 다음 온콜 엔지니어가 실제로 배울 수 있게 만듭니다.

4. 온콜(On-call) 인수인계 문서

당신은 교대 근무를 이어받을 엔지니어를 위해 온콜(On-call) 인수인계 문서를 작성하는 SRE입니다.
다음은 현재 해결되지 않은 이슈, 진행 중인 완화 조치(mitigations), 그리고 모니터링 항목입니다: [PASTE].
다음 세 가지 섹션으로 구성된 인수인계 문서를 작성하세요: (1) 활성 장애 (Active Incidents) — 상태, 현재 완화 조치, 다음 확인 시간; (2) 모니터링 항목 (Watch Items) — 아직 장애는 아니지만 악화될 수 있는 사항과 장애로 간주될 임계값(threshold); (3) 주의 사항 (Heads Up) — 내 근무 시간 중 발생한 특이 사항 중 다음 담당자가 알아야 할 내용. 200단어 이내로 작성하세요. 첫 줄은 반드시 "Nothing active — quiet shift" 또는 "X active incidents" 중 하나여야 하며, 이를 통해 다음 담당자가 1초 만에 심각도를 파악할 수 있게 하세요.

효과적인 이유: 강제된 첫 줄("Nothing active" 대 "X active incidents") 덕분에, 교대 들어오는 온콜 엔지니어는 다른 내용을 읽기 전에 상황의 중대성을 즉시 알 수 있습니다. 대부분의 인수인계 문서는 핵심 내용을 뒤에 숨기곤 합니다.

5. 용량 계획 메모 (Capacity planning memo)

당신은 경영진을 위해 용량 계획(Capacity planning) 메모를 작성하는 SRE입니다.
서비스: [NAME]. 현재 상태: [QPS/CPU/MEM/DISK]. 성장률: [월간 %]. 여유 공간 임계값 (Headroom threshold): [%]. 예산: [$ 또는 "미지정"].
우리가 여유 공간 임계값에 도달하는 시점을 예측하세요 (계산 과정을 보여줄 것). 비용에 따라 순위를 매긴 3가지 옵션을 추천하세요: (1) 가장 저렴한 단기 방안, (2) 균형 잡힌 방안, (3) 장기적인 아키텍처 변경 방안. 각 옵션에 대해 비용 추정치, 구현 시간, 리스크, 그리고 아무 조치도 취하지 않았을 때 발생하는 문제점을 포함하세요. 경영진 요약(Executive summary)에는 전문 용어를 사용하지 마세요 — 독자가 이 서비스에 대해 전혀 모른다고 가정합니다.

효과적인 이유: "계산 과정을 보여줄 것(show the math)"이라는 제약 조건은 AI가 대충 얼버무리는 경향을 차단합니다. 순위가 매겨진 세 가지 옵션은 "상황을 모니터링해야 합니다"와 같은 모호한 답변 대신 실제적인 의사결정을 유도합니다.

6. 알람 중복 제거 검토 (Alert deduplication review)

당신은 알람 피로 (Alert fatigue)를 검토하는 SRE입니다. 다음은 지난 7일 동안 발생한 모든 알람 목록과 빈도입니다: [PASTE].
동일한 근본 원인 (Root cause)을 가졌을 가능성이 높은 알람들을 그룹화하세요. 각 그룹에 대해: 해당 알람들을 나열하고, 이로 인해 발생한 페이지 (Page) 횟수를 추정하며, 다음 중 하나를 권장하세요: 그대로 유지, 멀티 알람으로 변경 (15분 단위 그룹화), 정보 전용 (Info-only)으로 변경, 또는 완전히 삭제. 신호 (Signal)를 잃지 않으면서 페이지 발생을 줄이는 것을 우선순위로 두세요. 10회 이상 발생한 알람은 런북 (Runbook) 또는 자동 복구 (Auto-remediation) 후보로 표시하세요.

작동 원리: 알람 피로 (Alert fatigue)는 온콜 (On-call) 엔지니어의 삶의 질을 떨어뜨리는 가장 큰 문제입니다. 이 프롬프트는 알람을 클러스터링 (Clustering) 문제로 취급하며, 모호하게 "조정 검토"라고 말하는 대신 그룹당 구체적인 권장 사항을 강제합니다.

7. 변경 로그를 위한 변경 실패 요약 (Change failure summary for the changelog)

당신은 공개 변경 로그 (Public changelog) 및 내부 회고 (Internal retro)를 위해 실패한 배포를 요약하는 SRE입니다.
배포 내용: [DESCRIBE]. 발생 상황: [PASTE]. 롤백 (Rollback): [YES/NO, 방법].
두 가지 버전을 작성하세요: (1) 외부용 — 2문장 이내, 고객 대상, 내부 서비스 명칭 제외, 영향도와 수정 사항 명시. (2) 내부용 — 실제 서비스 명칭, 롤백 메커니즘, 그리고 다음번에 이를 잡아낼 수 있는 하나의 프로세스 변경 사항을 포함한 동일한 내용. 두 버전 모두 영향에 대해 정직해야 합니다 — 축소하지 마세요.

작동 원리: 외부용 버전을 작성함으로써 내부 정보를 노출하지 않으면서도 정직함을 유지하게 하며, 내부용 버전은 프로세스 변경을 강제합니다. "축소하지 마세요"라는 제약 조건은 상황을 경시하려는 기업 특유의 반사 작용을 방지합니다.

8. 상태 확인 → 알람 규칙 (Health check → alerting rule)

8. 상태 확인 → 알람 규칙 (Health check → alerting rule)

당신은 수동 상태 확인을 자동화된 알람 규칙으로 전환하는 SRE입니다.
수동 확인: [무엇을 하는지 설명 — 예: "/health를 curl하고 db_latency 필드가 100ms 미만인지 확인"]를 작성하세요.
Prometheus 스타일의 알람 규칙(또는 [다른 시스템])을 생성하세요. 다음 사항을 명시해야 합니다: 메트릭 이름, 임계값, 지속 시간, 심각도, 그리고 첨부할 런북 링크. 임계값 선택 이유를 한 문장으로 설명하세요. 이 규칙이 놓치는 실패 모드를 포착하는 관련 알람 하나를 제안하세요.

작동 원리: "이 규칙이 놓치는 실패 모드를 포착하는 관련 알람 하나를 제안하라"는 부분이 핵심입니다. 이는 AI가 단일 알람으로는 파악할 수 없는 것들에 대해 생각하도록 강제하기 때문입니다.

9. 재해 복구 워크스루 스크립트 (Disaster recovery walkthrough script)

당신은 팀이 분기별로 실행할 DR(재해 복구) 테스트 워크스루를 작성하는 SRE입니다.
서비스: [이름]. RTO: [X분]. RPO: [Y분]. 백업 메커니즘: [설명]을 작성하세요.
단계별 DR 테스트 스크립트를 작성하세요. 각 단계는 다음을 포함해야 합니다: 조치, 예상 결과, 그리고 결과가 다를 경우 무엇을 할지(롤백? 에스컬레이션?). 모든 단계 후에는 "시간 확인"을 포함하세요 — RTO를 초과했다면 멈추고 현재 위치를 문서화하세요. 주관적이지 않고 이진적인 (binary) 통과/실패 기준 섹션으로 마무리하세요.

작동 원리: DR 테스트는 기준이 모호할 때("기본적으로 작동함") 조용히 실패합니다. 이진적인 통과/실패와 단계별 시간 확인은 테스트를 정직하게 만듭니다. "RTO 초과 시 중단" 규칙은 복구 목표 시간을 넘긴 후에도 마치 성공한 것처럼 꾸미는 흔한 실수를 방지해 줍니다.

10. 비용 이상 징후 조사 시작점 (Cost anomaly investigation starter)

당신은 클라우드 비용 급증을 조사하는 SRE입니다.
청구 요약: [붙여넣기 — 서비스, 금액, 기간]. 정상 기준선: [$].
이 정도 규모의 급증에 대한 가장 가능성 높은 원인 5가지를 확률 순으로 [AWS/GCP/Azure]를 기준으로 나열하세요. 각 항목에 대해 다음을 포함해야 합니다: 어떻게 확인할지(확인해야 할 정확한 메트릭 또는 보고서), 그리고 어떻게 수정할지. 일반적인 조언은 목록에 넣지 마세요 — 모든 항목은 10분 이내에 검증 가능해야 합니다.

작동 원리: 비용 급증(Cost spikes)은 시급한 문제이며, AI의 기본 응답은