엔지니어 학습을 향상시키는 비난 없는 사고 검토를 운영하는 방법

새벽 2시 10분에 경고가 발생합니다. 엔지니어가 구성 변경을 푸시하고, 체크아웃 서비스에서 오류가 발생하기 시작하며, 당직 책임자는 40분 후에 변경 사항을 롤백합니다. 검토 회의에서 첫 번째 질문은 "누가 변경을 푸시했습니까?"입니다. 몇 분 만에 대화는 새벽 02시에 한 사람이 내린 판단에 대한 이야기로 바뀌고, 아무도 왜 카나리 배포 없이 변경 사항이 프로덕션 환경에 배포될 수 있었는지, 왜 경고가 울리는 데 그렇게 오랜 시간이 걸렸는지, 또는 왜 운영 매뉴얼이 최신 버전이 아니었는지에 대해 묻지 않습니다.

이것은 고객 사례가 아니라 예시적인 시나리오입니다. 흔히 발생하는 상황이기 때문에 누구나 알아볼 수 있습니다. 마지막으로 조치를 취한 사람에게만 초점을 맞춘 사건 검토는 깔끔한 사례만 만들어낼 뿐, 실질적인 교훈은 거의 제공하지 못합니다.

이 가이드는 사고 증거 분석 능력 향상과 테스트 가능한 개선 방안 도출을 지원하고자 하는 엔지니어링 관리자 및 지원 책임자를 위한 것입니다. 기술 격차와 그 배경을 파악하는 방법, 실습 설계 방법, 사후 검토 방법, 그리고 검토의 효과를 측정하는 방법을 다룹니다.

"무죄"라는 말의 의미와 의미가 아닌 것

구글의 사이트 신뢰성 엔지니어링(Site Reliability Engineering) 책에서는 사후 분석이 진정으로 비난받을 여지가 없도록 하려면, 특정 개인이나 팀의 잘못이나 부적절한 행동을 비난하지 않고 사건의 원인을 파악하는 데 집중해야 한다고 명확히 밝히고 있습니다. 또한, 관련된 모든 사람이 선의를 가지고 있었고 가지고 있던 정보를 바탕으로 올바른 조치를 취했다는 전제가 깔려 있다고 설명합니다.구글 SRE 책, "사후 분석 문화: 실패로부터 배우기".)

비난할 여지가 없다고 해서 결과가 없다는 뜻은 아닙니다. 같은 장에서는 사후 분석이 우선순위와 담당자가 지정된 실행 항목으로 마무리되어야 한다고 강조합니다. 비난 없는 조사에서도 책임 소재는 여전히 중요하지만, 그 책임은 "누가 이런 일을 일으켰는가"에서 "누가 언제까지 시스템을 더 안전하게 만들 것인가"로 바뀝니다. 만약 사후 분석에서 이 후반부를 건너뛴다면, 그저 즐거운 대화에 그칠 뿐, 진정한 학습 과정이 되지 못할 것입니다.

1. 행동과 그 맥락을 파악합니다.

바꾸고 싶은 구체적인 행동부터 시작하세요. "사건 검토 시 마지막 조치를 취한 사람에게 초점을 맞춘다"는 관찰 가능한 행동이지만, "우리 회사의 문화는 비난 위주다"는 관찰 불가능한 행동입니다.

그렇다면 이것이 정말 기술적인 문제인지 자문해 보세요. 훈련은 저조한 성과의 원인 중 일부만 해결할 수 있습니다. 무엇을 만들기 전에 다음 세 가지 가능성을 구분해 보세요.

1. 부족한 기술. 검토자들은 타임라인을 구성하는 방법, 유발 요인과 기여 요인을 구분하는 방법, 또는 "당시에 이 행동이 합리적으로 보였던 이유는 무엇인가?"라는 질문을 던지는 방법을 모릅니다.
2. 인센티브. 리뷰는 성과 관련 논의에 영향을 미치기 때문에 사람들은 자신을 보호하기 위해 계정 내용을 수정합니다.
3. 권위의 단계적 변화와 과거의 대응. 지난 분기에 우려 사항을 제기했다가 부정적인 말을 그만하라는 말을 들었던 신입 엔지니어는 아무리 훈련을 잘 받았더라도 이번 회의에서는 그런 문제를 제기하지 않을 것입니다.

첫 번째 문제만 훈련 문제이고, 나머지 두 가지는 환경적 요인입니다. 기술만 훈련시키고 환경을 개선하지 않으면, 사람들은 직장에서 불이익을 주는 행동을 반복하게 될 것입니다. 현재 가지고 있는 원인에 대한 견해를 가설로 삼고, 엔지니어들과 몇 차례 대화를 나누고 최근 검토 문서를 살펴본 후 프로그램에 착수하십시오.

2. 실습을 위한 운영 환경을 설정하십시오.

실제 업무 환경에서 연습이 효과를 발휘하려면 직장 환경이 그에 부합해야 합니다. 연습을 시작하기 전에 평가를 담당하는 사람들과 다음 사항들을 반드시 협의하십시오.

• 승인된 책임 사항. 누가 진행을 맡고, 누가 일정을 작성하며, 누가 후속 조치를 담당하는가? 진행자가 임의로 권한을 행사하지 않도록 역할을 명확히 해야 합니다.
• 지도자들이 우려 사항을 어떻게 받아들이는가. 엔지니어가 "배포 도구에서 카나리 배포를 건너뛸 수 있었어요"라고 말하면, 책임자는 다음에 무엇을 해야 할까요? 예를 들어 감사를 표하고, 해당 사항을 원인으로 기록하고, 조치를 할당하는 등의 답변을 미리 정해 두세요.
• 상사의 답변. 직원 교육에는 그에 걸맞은 관리자의 대응이 필요합니다. 엔지니어들에게 리뷰에서 적극적으로 의견을 제시하도록 교육했는데도 관리자들이 여전히 "누구 잘못이야?"라고 묻는다면, 교육은 무용지물이 될 것입니다.

관리자를 위한 평가 프로세스에 대한 간략한 브리핑은 참가자 교육만큼이나 중요합니다. 평가 문서가 성과 관리에서 어떻게 사용되고 어떻게 사용되지 않는지에 대한 명확한 설명을 포함하십시오.

3. 행동 기반 학습 여정을 설계하세요

카네기 멜론 에벌리 센터의 학습 목표 지침은 목표, 평가 및 교수 전략이 서로 일치해야 한다는 유용한 점을 지적합니다.에벌리 센터, 학습 목표이는 특정 도구나 결과에 대한 증거가 아니라 설계 지침이지만, 이 프로그램을 검증하는 데에는 좋은 기준이 됩니다. 목표가 증거를 분석하고 검증 가능한 개선 사항에 합의하는 것이라면, 단순히 기억력 관련 질문만으로는 평가가 될 수 없습니다.

블룸의 분류법은 분석, 평가, 창조라는 과제의 인지적 요구 단계를 설명하는 데 도움이 됩니다. 이는 과제가 개인에게 요구하는 바를 설명하는 것이지, 왜 그 과제를 하거나 하지 않는지를 설명하는 것은 아니므로 동기를 진단하는 데 사용해서는 안 됩니다.

효과적인 여정은 세 단계로 이루어집니다.

실제와 유사한 사례를 만들고 경험이 풍부한 엔지니어에게 검증을 받으세요. 기술적으로 잘못된 사례는 검토자들이 해당 연습을 신뢰하지 않도록 만듭니다.

4. 시나리오를 진행하고 결과를 검토합니다.

다음은 02:10 시나리오를 사용한 연습 세션의 예시입니다. 증거 자료에는 배포 로그, 알림 타임라인, 페이징 정책, 풀 리퀘스트 및 런북이 포함되어 있으며, 모두 가상의 자료입니다.

참가자에게 안내 메시지를 보내세요. "엔지니어가 왜 그 시점에 변경을 추진했는지 설명하십시오. 사용한 증거를 제시하십시오. 확신을 갖기 위해 어떤 추가 정보나 지원이 필요한지 알려주십시오."

미온적인 답변은 "엔지니어가 스테이징 환경을 확인했어야 했습니다."와 같습니다. 특정 인물을 지목하지만, 구체적인 근거는 제시하지 않고, 개선 방안도 제시하지 않습니다.

좀 더 강력한 답변은 다음과 같습니다. "배포 로그를 보면 카나리 테스트 단계가 도구에서 선택 사항이기 때문에 변경 사항이 바로 배포된 것을 알 수 있습니다. 풀 리퀘스트는 한 명의 검토자가 20분 후에 승인했습니다. 알림 임계값이 5분 평균으로 설정되어 있었기 때문에 오류가 발생하기 시작한 후 18분 후에 페이지가 표시되었습니다. 이번 달에 카나리 테스트를 건너뛴 다른 변경 사항이 몇 건이나 되는지, 그리고 온콜 엔지니어에게 해당 단계를 건너뛸 수 있다는 사실이 알려졌는지 알고 싶습니다. 제안 사항: 이 서비스 계층에 대해 카나리 테스트를 필수로 설정, 담당자: 플랫폼 팀, 확인: 스테이징 환경에서 카나리 테스트를 건너뛴 배포를 시도하고 차단되는지 확인; 알림 시간 간격 단축, 담당자: 온콜 리더, 확인: 지난주 오류를 새로운 임계값과 비교하여 검토."

무엇이 이 방식을 더 좋게 만드는지 주목해 보세요. 이 방식은 증거를 활용하고, 제약 조건과 불확실성을 명시하며, 검증 가능한 행동으로 마무리됩니다.

이제 사후 분석을 해봅시다. 단순히 점수만 매기지 말고, 다음과 같은 질문을 해보세요.

1. 증거는 무엇을 뒷받침했고, 당신은 무엇을 가정했습니까?
2. 팀이 실제로 결정할 권한을 가진 행동은 무엇일까요?
3. 다음번 실제 평가에서 이러한 행동을 반복하기 쉽게 만드는 방법은 무엇일까요? 반대로 어렵게 만드는 방법은 무엇일까요?

세 번째 질문이 가장 중요합니다. 이 질문은 2절에서 언급된 조건들을 드러냅니다. 만약 세 명의 참가자가 "상사가 누가 그랬는지 물어볼 거예요"라고 말한다면, 교육으로는 제거할 수 없는 제약 조건을 발견한 것입니다.

5. 행동을 측정하고 후속 조치를 취하십시오.

핵심 질문은 학습자가 사건 증거를 분석하고 검증 가능한 개선 사항에 합의할 수 있음을 보여주는 증거가 무엇인가 하는 것입니다. 다음은 시작점으로 활용할 수 있는 평가 기준표입니다. 이는 검증된 준비 표준이 아니라, 경험이 풍부한 엔지니어와 협의하여 수정할 수 있는 제안입니다.

중대한 오류는 별도로 정의해야 합니다. 예를 들어, 오류의 원인을 특정하거나 책임자를 지정하지 않은 조치를 제안할 수 있습니다. 높은 총점이 중대한 오류를 가리는 일이 절대 있어서는 안 됩니다.

측정 자체에 관해서는 다음과 같습니다.

• 기여 요인 분석의 질. 프로그램 시작 전 작성된 리뷰와 프로그램 종료 후 작성된 리뷰를 비교하고, 어떤 리뷰가 프로그램 시작 전 작성되었는지 모르는 사람이 동일한 평가 기준표를 사용하여 점수를 매깁니다. 실제 사례뿐 아니라 이전에 공개되지 않은 후속 사례도 활용합니다.
• 끝까지 따르기. 제기된 모든 실행 항목 중에서 담당자가 지정되고, 테스트가 진행되었으며, 완료된 항목의 비율을 계산하십시오. 분모와 기간(기간)을 명시하십시오.
• 관찰 내용과 프로세스 변화를 연관시키세요. 실제 검토 회의에 참여해 보세요. 회의 후 실행 항목들이 어떻게 진행되었는지 확인해 보세요.

보고량에 주의해야 합니다. 프로그램 이후 우려 사항이나 아차 사고 기록이 증가했다고 해서 반드시 안전성이 개선된 것은 아닙니다. 신뢰도가 향상되었거나, 새로운 도구 덕분에 기록이 더 쉬워졌다는 의미일 수도 있습니다. 반대로 보고량이 적었다 하더라도 문제가 줄어들었거나, 직원들이 말하기를 꺼려하는 것일 수 있습니다. 교육의 효과를 단정하기 전에 같은 기간 동안 어떤 변화가 있었는지 살펴보고, 측정하지 않은 효과 크기를 주장하는 것은 피해야 합니다.

위의 에벌리 지침은 조직 정렬의 중요성을 강조하는 것이며, 이러한 접근 방식이 사건 발생률을 감소시킨다는 증거는 아닙니다. 자체적인 기준선 및 후속 데이터를 보관하고 이를 지역적 증거로 활용하십시오.

기술이 향상된 후에도 어떤 제약 조건이 남아 있을 수 있을까요?

이러한 사항들을 스폰서에게 솔직하게 이야기하세요:

1. 검토 문서는 여전히 성과 결정에 영향을 미칠 수 있습니다.
2. 마감 기한 압박을 받는 팀은 비용이 많이 들지만 합리적인 조치를 건너뛸 수 있습니다.
3. 팀 간 협업은 경계에 대한 책임자가 없기 때문에 지연될 수 있습니다.
4. 선임 엔지니어들이 여전히 논의를 주도할 가능성이 높습니다.

더 나은 분석만으로는 이러한 문제를 해결할 수 없습니다. 이러한 문제에 대해서는 별도의 프로세스 변경 계획을 수립하십시오.

AhaSlides를 활용하여 실천해 보기

AhaSlides는 적응형 학습, 상호작용형 학습, 그리고 실시간 학습과 자기 주도 학습 간의 전환을 지원합니다. 이러한 학습 과정에는 자기 주도 학습을 통한 사전 준비 단계, 모든 참가자가 분석에 참여하도록 유도하는 개방형 질문으로 구성된 실시간 또는 진행자가 이끄는 사례 세션, 그리고 세션 후 후속 과제가 포함될 수 있습니다. 특정 작성, 채점 및 보고 기능은 실제 사례를 기반으로 한 데모를 통해 검증한 후 사용해야 하며, AI, 시뮬레이터 또는 사고 처리 도구와의 통합과 관련된 모든 기능은 시연 전까지는 외부 기능으로 간주해야 합니다.

다음 단계: 위의 평가 기준을 참고하여 선임 엔지니어와 상의 후, 사용할 사례를 만들어 보세요. 이 과정을 실시간으로, 스스로 속도를 조절하며 진행하는 방법을 알고 싶으시다면, AhaSlides 워크플로우 데모를 예약하세요 사례와 평가 기준표 초안 작성이 완료되면,