예배 방송이 끊기거나 소리가 사라진 뒤 “다음에는 조심하자”로 끝내면 같은 문제가 다시 나타나기 쉽습니다. 반대로 한 사람의 실수만 찾으면 장비·절차·업무 인계처럼 사고를 허용한 조건은 남습니다. 사고 회고의 목적은 책임을 피하는 것도, 누군가를 처벌하는 것도 아닙니다. 무슨 일이 언제 일어났고, 시청자에게 어떤 영향이 있었으며, 무엇을 바꾸면 재발 가능성이나 피해를 줄일 수 있는지를 공유 가능한 기록으로 만드는 일입니다.
Google SRE는 postmortem을 사고, 영향, 완화 조치, 기여 원인, 재발 방지 조치를 담는 문서로 설명합니다. 대규모 서비스의 방법을 교회에 그대로 옮길 필요는 없지만, “누가 잘못했는가”보다 “어떤 조건이 실패를 가능하게 했는가”를 묻는 원칙은 소규모 방송팀에도 유용합니다.
회고는 장애가 끝난 뒤 시작되는 두 번째 복구다
첫 번째 복구는 방송을 다시 내보내는 것입니다. 두 번째 복구는 다음 예배에서 같은 고장이 되풀이되지 않게 시스템을 바꾸는 일입니다. 그래서 회고는 사건 직후의 기억만 적는 일지가 아니라, 서로 다른 증거를 하나의 타임라인으로 연결하는 분석입니다.
| 기록 층위 | 답해야 할 질문 | 방송팀이 확보할 증거 |
|---|---|---|
| 현상 | 시청자는 무엇을 경험했나 | VOD, 댓글, 시청자 제보, 무음·정지 구간 |
| 시간 | 언제 시작·탐지·복구됐나 | OBS 로그 시각, YouTube 오류 시각, 담당자 메모 |
| 영향 | 얼마나 오래, 누구에게 영향을 줬나 | 중단 시간, 동시 시청자, watch time, 재접속 여부 |
| 기여 요인 | 어떤 조건들이 함께 작동했나 | 네트워크, 인코더, 오디오 경로, 인수인계, 모니터링 |
| 후속 조치 | 무엇을 바꾸고 어떻게 확인할까 | 담당자, 기한, 완료 조건, 다음 리허설 결과 |
사건 타임라인은 기억보다 시각을 우선한다
회의를 시작하기 전에 자료를 복사해 둡니다. OBS 세션 로그, YouTube Live Control Room 오류, 인터넷 장비 기록, 송출 화면 녹화, 담당자의 실제 조치 시각을 모읍니다. OBS의 공식 문서는 로그가 세션의 설정·장치·오류 정보를 담는다고 설명합니다. YouTube는 Live Control Room에서 오류의 심각도와 발생 시각을 표시합니다. 이 둘을 맞추면 “그때쯤 인터넷이 느렸다” 같은 추측을 관찰 가능한 사건으로 바꿀 수 있습니다.
타임라인에는 최소한 정상 시작, 첫 이상 징후, 탐지, 첫 대응, 상태 변화, 복구, 정상 확인을 적습니다. 시각이 정확하지 않으면 “약 10:24”처럼 불확실성을 표시합니다. 회의에서 뒤늦게 나온 해석을 당시 사실처럼 끼워 넣지 않는 것이 중요합니다.
원인은 하나가 아니라 기여 요인의 연결일 수 있다
OBS는 dropped frames나 간헐적 연결 끊김이 송출 컴퓨터와 원격 ingest server 사이의 네트워크 문제를 가리킨다고 설명합니다. 하지만 “인터넷 문제”라는 한 문장만으로는 다음 행동을 정할 수 없습니다. 업로드 회선의 순간 저하, Wi‑Fi 사용, VPN·보안 소프트웨어, 높은 bitrate, 잘못 선택한 ingest server, 장애 경고를 볼 별도 모니터 부재가 함께 작동했을 수 있습니다.
오디오 사고도 마찬가지입니다. 음소거 버튼을 누른 사람이 직접 계기였더라도, 상태 표시가 눈에 띄지 않았거나 송출 음성을 듣는 별도 기기가 없었거나 담당 교대 때 확인 절차가 없었다면 시스템 요인이 존재합니다. “root cause 하나”를 서둘러 고르는 대신 직접 계기, 기술 조건, 운영 조건, 탐지 지연을 나눠 적으면 조치가 구체화됩니다.
| 관찰된 증거 | 가능한 해석 | 아직 말할 수 없는 것 | 다음 확인 |
|---|---|---|---|
| OBS dropped frames 급증 | ingest 경로가 bitrate를 안정적으로 처리하지 못함 | ISP 자체 장애라고 단정 | 유선/다른 회선·서버에서 재현 비교 |
| YouTube keyframe 경고 | encoder 출력 간격이 플랫폼 요구와 맞지 않음 | 카메라 고장 | OBS output 설정과 경고 시각 대조 |
| OBS meter는 움직이나 공개 영상 무음 | encoder 이후 또는 모니터 경로 문제 가능 | 믹서 출력 정상이라고 단정 | 로컬 녹화·다른 기기 재생 비교 |
| 복구가 늦었음 | 탐지·권한·인수인계 지연 가능 | 특정 담당자 역량 부족 | 알림을 누가 언제 봤는지 타임라인 확인 |
35분 회고 회의의 실제 흐름
처음 5분에는 진행자가 목적과 비난 금지 원칙을 확인합니다. 다음 10분에는 의견보다 타임라인을 맞춥니다. 이어지는 10분에는 시청자 영향과 기여 요인을 구분합니다. 마지막 10분에는 후속 조치를 정합니다. 회의가 길어지면 사실 확인이 필요한 항목을 별도 조사 과제로 남기고, 근거 없는 결론으로 빈칸을 채우지 않습니다.
진행자는 “왜 그 버튼을 눌렀나요?”보다 “그 순간 화면에 무엇이 보였고 어떤 정보로 판단했나요?”라고 묻습니다. 당시 사람이 가진 정보와 환경을 재구성해야 경고 표시, 권한, 체크 방식, 교육 자료 가운데 무엇을 바꿔야 하는지 보입니다.
좋은 후속 조치는 예방과 완화를 구분한다
모든 사고를 완전히 없애는 조치만 찾으면 “장비 전면 교체”처럼 크고 끝나지 않는 과제가 남습니다. Google SRE Workbook은 예방 조치와 영향 완화 조치를 함께 다루고, 측정 가능한 완료 상태를 강조합니다.
예방 조치는 유선 송출 회선 분리, encoder preset 고정, scene collection 백업처럼 발생 가능성을 낮춥니다. 완화 조치는 별도 기기로 공개 음성 감시, backup stream 준비, 즉시 띄울 안내 화면처럼 사고가 나도 탐지와 복구 시간을 줄입니다. “교육 강화”보다 “다음 두 번의 리허설에서 별도 기기 음성 확인 기록이 남는다”가 더 검증 가능합니다.
회고 문서 한 장에 남길 항목
- 사건 제목과 날짜, 영향받은 방송
- 시청자가 겪은 현상과 영향 시간
- 증거 기반 타임라인
- 직접 계기와 기술·운영·탐지 기여 요인
- 잘 작동한 대응과 작동하지 않은 대응
- 예방 조치와 완화 조치
- 각 조치의 담당자, 기한, 확인 가능한 완료 조건
- 개인정보가 포함되지 않은 로그·설정·관련 문서 링크
OBS 로그나 화면 캡처에는 계정명, stream key, 네트워크 주소 등 공개하면 안 되는 값이 들어갈 수 있습니다. 회고 문서는 필요한 팀만 접근하게 하고, 외부 공유본에는 민감정보를 제거합니다.
회고가 끝났다는 기준
문서 작성이 아니라 조치 검증까지 마쳐야 회고가 닫힙니다. 다음 리허설에서 같은 조건을 재현하고, YouTube stream health와 별도 청취 기기로 결과를 확인합니다. YouTube는 실제 방송과 비슷한 오디오·움직임 조건으로 사전 시험하고 방송 중 stream health를 보도록 안내합니다. 조치가 실패하면 사람을 다시 탓하지 않고 가설과 설계를 고칩니다.
공식 자료
- Postmortem Culture: Learning from Failure — Google SRE
- Postmortem Practices for Incident Management — Google SRE
- Stream Connection Troubleshooting — OBS Project
- OBS Log Files — OBS Project
- Live streaming error messages — YouTube Help
- See your live stream’s metrics — YouTube Help
- Choose live encoder settings, bitrates, and resolutions — YouTube Help