Cowork 실습 · Step 4

Step 4 — 장애 대응, Teams 채널 한 줄에서 원인 찾기

장애 원인은 문서 어디에도 없고 Teams 워룸 대화 한 줄에만 있습니다. 3개 소스를 교차 조회해야만 답이 나옵니다.

Copilot Cowork 장애 대응 교차 조회 문서 생성 실습

게시일 2026-09-05

▶ 배우는 것 — 실습 전체에서 가장 중요한 단계입니다. 답을 찾으려면 Teams 채널·메일·SharePoint 세 곳을 모두 읽어야 합니다. 하나라도 빠지면 답이 안 나옵니다.

6일 전 새벽, Meridian Bank 운영망에서 Aurora Sentinel 알림이 4시간 12분 지연됐습니다. 설비 412대 영향, 지연 알림 1,148건, 유실 0건. 복구는 끝났습니다.

그런데 사후 보고서를 아직 못 냈습니다. 오늘 QBR에서 고객이 물어볼 것이 확실합니다.

왜 이게 어려운 일인가

장애 정보가 세 곳에 쪼개져 있고, 가장 중요한 사실이 가장 안 보이는 곳에 있습니다.

소스	무엇이 있나	무엇이 없나
📄 SharePoint 엔지니어링 노트	타임라인, 증상, 조치	근본 원인 — “조사 중” 으로 끝남
📊 SharePoint 지표 워크북	큐 깊이, 컨슈머 수 추이	숫자만 있고 해석이 없음
📧 메일 5통	고객 통보 이력	원인 언급 없음
💬 Teams 워룸 18건	⭐ 근본 원인 한 줄	—

지표 워크북에는 컨슈머 수가 계속 8에 붙어 있다가 05:31에 32로 뛰는 게 보이지만, “왜 8이었는지” 설명이 없습니다. 그 답은 오직 Teams 워룸 메시지 한 줄에 있습니다.

실제 장애 대응이 이렇게 흘러갑니다. 진짜 원인은 새벽 3시 채팅에서 튀어나오고, 문서에는 며칠 뒤에야 반영됩니다.

4-1. 원인과 타임라인 먼저 확정

시나리오 9 · 최대 하이라이트

📌 어떤 상황인가

사후 대응 문서를 쓰기 전에 사실관계부터 맞춰야 합니다. 여기서 원인이 틀리면 뒤가 전부 틀립니다.

🎯 기대 산출물: 채팅 안의 근본 원인 한 줄 + 타임라인 + 영향 숫자
💡 효율화 포인트: 사람이 하면 워룸 18건을 스크롤해 원인을 찾고 문서에서 타임라인을 옮겨 적습니다. 더 큰 문제는 급할수록 워룸을 안 본다는 것 — 그러면 원인이 빠진 보고서가 나갑니다.
⚠️ 확인할 것: "컨슈머 스케일아웃 임계값이 8로 고정" 이라는 원인이 나오는지 보세요. 이게 실습 전체의 정답입니다.

메일·보고서·Excel을 한 번에 요구하지 않는 이유 — 세 벌을 동시에 쓰면 가장 오래 걸리고, 원인을 잘못 잡았을 때 세 벌을 다시 써야 합니다. 사실 확인 → 산출물 순서가 결과적으로 빠릅니다.

INC-4471 장애의 근본 원인을 Teams war-room 대화에서 찾아줘.
원인 한 줄, 타임라인 4줄, 영향 숫자 3개만 채팅으로 알려줘. 문서는 만들지 마.

✅ 결과 확인 — 이 실습의 정답

답변에 이런 취지의 문장이 있어야 합니다.

“큐 컨슈머의 스케일아웃 임계값이 8로 고정되어 있어, 부하가 늘어도 컨슈머가 증가하지 못했습니다.”

이 문장이 나왔다면 Teams 채널을 실제로 읽었다는 증거입니다.

❌ 엔지니어링 노트에 없음 (일부러 뺐습니다)
❌ 지표 워크북에 없음 (숫자 8만 있고 설명이 없습니다)
❌ 메일에 없음
✅ Teams INC-4471 War Room 메시지 딱 한 건에만 있음

항목	기대값
타임라인	02:10 탐지 → 03:05 고객 통보 → 05:31 완화 → 06:22 복구
영향	설비 412대, 지연 알림 1,148건, 유실 0건
최대 지연	4시간 12분

원인이 안 나왔다면 — 둘 중 하나입니다.

Teams 시드 데이터가 없다 — Step 0의 5번이 덜 된 경우입니다. INC-4471 War Room 채널에 대화 18건이 있는지 확인하세요.
채널을 안 봤다 — “워룸 채널 대화를 다시 확인해서 근본 원인 가설을 찾아줘.”

두 번째가 오히려 좋은 시연 소재입니다. “소스를 지목해주면 훨씬 정확하고 빨라집니다” 라고 설명할 수 있습니다.

4-2. 고객용 메일 초안

시나리오 10

📌 어떤 상황인가

원인이 확정됐으니 이제 고객에게 보낼 글을 씁니다. 톤이 관건입니다.

🎯 기대 산출물: Meridian Bank용 메일 초안 1건 (발송 전)
💡 효율화 포인트: 앞 단계의 사실관계를 그대로 이어받습니다. 다시 조사하지 않으므로 초안 생성이 빠릅니다.
⚠️ 확인할 것: 기술 용어가 고객 눈높이로 풀렸는지, 그리고 발송되지 않았는지 보세요.

방금 내용으로 Meridian Bank에 보낼 메일 초안을 만들어줘.
사과 → 원인 → 조치 → 재발방지 순서, 기술 용어 최소화, 200자 이내. 발송은 하지 마.

✅ 결과 확인

네 단락 순서가 지켜졌는가
임계값·컨슈머 같은 용어가 쉬운 말로 풀렸는가
초안 상태이고 발송되지 않았는가

나머지 산출물은 필요할 때만 — “같은 내용을 경영진용 숫자 중심 3줄로.” / “시정조치를 담당자·기한 컬럼의 액션 레지스터 Excel로.”

4-3. 비어 있는 RCA 문서 채우기 (선택)

시나리오 11 · 선택

📌 어떤 상황인가

OneDrive에 Meridian_RCA_outline.docx가 있습니다. 제목과 목차만 있고 내용이 텅 비어 있습니다.

🎯 기대 산출물: 다섯 섹션이 채워진 RCA 문서
💡 효율화 포인트: 공유 문서와 내 초안을 구분해 다룹니다. SharePoint 공식 문서는 읽기만 하고, 내 OneDrive 초안은 직접 채웁니다.
⚠️ 확인할 것: "근본 원인" 섹션에 임계값 8이 들어갔는지 보세요.

내 OneDrive의 Cowork-demo/OneDrive_Ava 폴더에 있는 Meridian_RCA_outline.docx를
방금 정리한 INC-4471 내용으로 채워줘. 섹션당 3줄 이내, 새 파일 말고 기존 파일에 써줘.

✅ 결과 확인

다섯 섹션(Summary / Timeline / Root cause / Impact / Corrective actions)이 채워졌는가
Root cause에 임계값 8 서술이 있는가
새 파일이 아니라 기존 파일이 수정되었는가

이 단계가 증명하는 것

“3개 소스를 다 읽었다”를 어떻게 증명하나 — 보통은 증명할 수 없습니다. 요약이 그럴듯하면 다 읽은 것처럼 보이니까요.

그래서 이 실습은 각 사실을 한 곳에만 심었습니다. 타임라인은 문서에만, 숫자 8은 워크북에만, 그 8이 설정된 상한이었다는 해석은 채널에만. 우연히 맞출 수 없는 구조입니다.

이 단계에서 확인한 것

✅ Teams 대화를 문서와 동등한 정보원으로 다룬다
✅ 문서에 없는 사실을 채널에서 건져와 반영한다
✅ 같은 사건을 수신자별 다른 톤으로 쓴다
✅ 내 OneDrive의 빈 초안을 찾아 채운다
✅ 사실 확인 → 산출물 순서가 다시 쓰기를 줄인다

Step 5 — 금요일, 일정 정리와 신규 입사자 로 이동하세요.