증거 기반(Evidence-Based) Exchange Online 트러블슈팅 워크플로우
"무엇이 고장났는가"를 넘어 "왜 그런가"를 증명하는 진단 — 스코핑부터 트레이스 분석, 에스컬레이션까지
Exchange Online 케이스의 난도는 "증상을 재현할 수 있느냐"에서 갈립니다. 사용자 환경에서만 발생하고 우리 테넌트에서는 멀쩡한 이슈일수록, 추측이 아니라 아티팩트(artifact)로 원인을 좁히는 역량이 결정적입니다. 이 글에서는 한 건의 서비스 요청(SR)을 받았을 때 따라가는 진단 흐름을 단계별로 정리합니다.
1. 시작은 항상 '스코핑'
도구를 꺼내기 전에 문제의 경계를 먼저 정의해야 합니다. 잘못 스코핑된 케이스는 아무리 좋은 트레이스를 떠도 엉뚱한 곳을 봅니다.
- 영향 범위: 단일 사용자인가, 전체 사용자인가? 전체 사용자가 영향을 받는다면 사서함이 아니라 도메인·DNS 레코드(MX, Autodiscover, SPF/DKIM 등)를 먼저 의심합니다.
- 클라이언트 격리: Outlook on the web(OWA)나 새 Outlook에서는 정상인데 클래식 Outlook에서만 문제라면 — 서버 측이 아니라 클라이언트 동기화 이슈일 가능성이 높습니다.
- 한 SR = 한 이슈: 케이스 정보를 충분히 검토한 뒤, 고객과 "이번에 해결할 단 하나의 문제"를 합의하고 지원 경계를 명확히 합니다.
2. 재현이 안 되면, 증거를 수집한다
엔지니어가 오류를 직접 관찰할 수 없을 때, 다음 세 가지 증거가 진단의 출발점이 됩니다.
화면 녹화
증상이 시각적이거나 재현 절차가 모호할 때 가장 빠른 수단입니다. Windows에서는 Snipping Tool(녹화 기능)·Steps Recorder, Mac에서는 PowerPoint 녹화나 macOS 기본 녹화 도구를 안내합니다.
네트워크 트레이스 (HAR)
브라우저 기반 이슈(OWA, 관리 포털)는 개발자 도구의 Network 탭에서 HAR 파일을 캡처합니다. 핵심은 "문제를 재현하면서" 캡처하는 것 — 빈 트레이스만큼 무의미한 게 없습니다.
데스크톱 트레이스 (Fiddler)
권한이 정상으로 보이는데도 오류가 나는 클래식 Outlook이나 Exchange Online PowerShell 이슈는 Fiddler로 잡습니다. HTTPS 트래픽을 보려면 HTTPS 복호화(decrypt)를 반드시 활성화해야 하며, 재현 후 세션을 .saz 파일로 저장해 공유합니다. 외부에서 받은 HAR 파일도 Fiddler로 import해 동일하게 분석할 수 있습니다.
3. 트레이스 읽기 — HTTP 응답 코드로 원인 좁히기
Fiddler/HAR 트레이스의 핵심은 결국 HTTP 응답 코드입니다. 코드 하나로 "내 영역인지, 에스컬레이션할 영역인지"의 1차 판단이 섭니다.
| 코드 | 의미 | 전형적 원인 / 다음 액션 |
|---|---|---|
| 401 | Unauthorized (인증 실패) | 토큰·자격 증명·인증 흐름 문제. 인증 헤더와 redirect 흐름 확인 |
| 403 | Forbidden (권한 거부) | 인증은 됐으나 권한 부족. EAC 권한 진단으로 교차 확인 |
| 404 | Not Found | 잘못된 엔드포인트·리소스 미존재. URL·Autodiscover 경로 점검 |
| 407 | Proxy Auth Required | 고객 측 프록시/네트워크 구성 이슈. 환경 문제로 분리 |
| 5XX | Server Error | 서비스 측 오류 가능성. 재현·범위 확인 후 제품 엔지니어링 에스컬레이션 검토 |
예를 들어 권한이 "정상으로 보이는데" 접근이 막힌다면, 트레이스의 403을 근거로 EAC 권한 진단을 돌리고, 정상 사용자와 권한을 비교(diff)해 차이를 특정합니다.
4. 진단 도구 박스
증상별로 손에 익혀두면 좋은 도구들입니다. 상당수가 "자동으로 고치거나, 최소한 다음 단서를 주는" 셀프 헬프 성격을 가집니다.
📬 사서함·권한 (Exchange admin center)
- 권한 진단: 특정 사용자가 올바른 권한을 갖는지 확인하고, 두 사용자 권한을 비교해 불일치를 찾음
- 사서함 프로비저닝 진단: 라이선스를 할당했는데 사서함이 생성되지 않을 때, 이메일·UPN·object ID로 진단 실행
- 셀프 헬프 진단: 일부 이슈를 자동 완화하거나 "잠시 후 재시도" 안내를 제공
🖥️ 클라이언트 (클래식 Outlook)
- MFCMapi: 누락된 기본 폴더 복원·숨김 해제 등 MAPI 레벨 데이터 이슈 처리
- Get Help 앱: 기존 SaRA(Support and Recovery Assistant)를 잇는 도구로, Outlook 프로필 스캔·고급 진단 리포트 생성
- Event Viewer: Outlook·Office 앱의 크래시·무응답 원인 분석
🔐 인증·로그 수집
- MSOID 로그: 인증·Office 앱 이슈와 관련된 여러 로그를 한 번에 수집
- ETL 로그: 클래식 Outlook의 상세 진단 로그. 이슈 발생 시점의 정확한 타임스탬프 캡처가 분석 품질을 좌우 (수집된 ETL은 내부 분석 도구로 해석)
5. 에스컬레이션 — 아티팩트와 함께
모든 케이스가 1선에서 끝나지는 않습니다. 에스컬레이션의 품질은 결국 "얼마나 잘 정리된 증거를 넘기느냐"입니다.
- 문제 재현 + 정확한 타임스탬프 확보
- Fiddler 세션을 .saz로 저장, ETL·MSOID 등 관련 로그 일괄 수집
- HTTP 코드 기준 1차 원인 판단 — 5XX 등 서비스 측 정황이면 에스컬레이션 후보
- 지정된 내부 업로드 경로로 로그를 공유하고, 재현 절차·범위·이미 시도한 조치를 함께 전달
마무리: 진단은 추측이 아니라 증명
좋은 Exchange Online 엔지니어와 그렇지 않은 엔지니어의 차이는 도구를 아느냐가 아닙니다. 스코핑으로 문제를 한 점으로 좁히고, 트레이스와 로그로 원인을 증명하며, 올바른 아티팩트를 갖춘 채로만 에스컬레이션하는 절제된 흐름을 가졌느냐입니다.
다음 케이스를 받으면 도구부터 열지 말고, 딱 한 줄을 먼저 물어보세요 — "이게 한 명의 문제인가요, 모두의 문제인가요?" 진단의 절반은 거기서 끝납니다.