서비스 장애 학습회 — 형식이 바뀌는 이유

결제·정산 팀에서 장애는 숫자가 멈추는 일이다

결제나 정산을 직접 운영해본 팀이라면 안다. 서비스 장애는 추상적인 "서비스 중단"이 아니다. 송금이 중간에 멈추고, 정산 배치가 절반만 돌고, 재시도 로직이 중복 청구를 만들어낸다. HEDVION은 결제 흐름과 정산 자동화를 직접 운영하는 작은 팀이다. 우리에게 장애는 곧 돈이 잘못된 자리에 있는 상태다. 이 상태를 빨리 발견하고, 다시 만들지 않는 것이 팀의 핵심 역량이다.

그래서 장애 복기 방식 — 우리가 "장애 학습회"라고 부르는 형식 — 이 실질적으로 중요하다. 단순히 회의체를 갖는다는 게 아니다. 어떤 형식으로 배우느냐가 실제로 반복을 막는지 여부를 가른다. 우리 팀이 이 형식을 세 번 바꾼 이유는, 매번 이전 형식이 충분히 배우지 못하게 했기 때문이다.

타임라인 중심 형식의 한계: 기록은 됐지만 대화가 멈췄다

초기 형식은 타임라인 정리였다. 09:42 알람 수신, 09:51 원인 파악, 10:14 복구 완료 식으로 정리하는 방식. 여러 명이 각자 다른 화면을 보며 대응했을 때 전체 그림을 맞추는 데는 확실히 효과적이었다. 정산 배치가 새벽 2시에 실패했을 때 여러 사람의 대응 로그를 하나의 타임라인으로 합치면 "3시 12분에 이미 재시도 로직이 작동했는데 왜 3시 29분에야 알람이 왔는가"처럼 갭이 눈에 보인다.

문제는 타임라인이 완성되면 회의가 조용해진다는 점이었다. "그래서 다음엔?"이라는 질문이 자연스럽게 나오지 않았다. 타임라인 작성 자체가 목적이 되어버렸다. 실제로 위에서 언급한 알람 지연 — 배치 실패 감지 후 담당자 알람 도달까지 4분 차이 — 은 타임라인 문서에 기록됐지만 다음 학습회 전까지 아무도 원인을 파지 않았다. 4분은 결제 현장에서 짧지 않다. 그 사이 실패한 정산 건이 수십 건 누적된다.

5-Why의 함정: 근본 원인이 사람으로 귀결됐다

원인 분석을 구조화하기 위해 5-Why를 추가했다. "왜 장애가 났는가?"를 다섯 번 반복해서 근본 원인에 가까워지는 방법이다. 이론적으로는 맞다. 실제로 결제·정산 환경의 장애에는 원인 레이어가 여러 겹이고, 표면적 원인만 건드리면 재발한다. 5-Why가 그 레이어를 벗겨내는 데 도움이 될 것이라고 기대했다.

그런데 실제로 해보니 세 번째 "왜"쯤에서 항상 같은 분기가 나타났다. "확인을 더 철저히 했어야 했다"거나 "배포 전 한 번 더 검토했어야 했다"는 결론이었다. 이건 개선 항목이 아니다. 누군가의 주의력에 의존하는 해결책은 같은 상황에서 같은 실수를 반복하게 만든다. 더 불편한 건 대화의 방향이었다. 5-Why를 파다 보면 어느 순간 특정 사람의 판단이나 행동이 근본 원인처럼 보이기 시작했다. 명시적으로 누군가를 탓하지 않아도 분위기가 그쪽으로 흘렀다. 그러면 다음 학습회에서 공유가 줄어든다. 작은 팀일수록 이 역학은 강하게 작동한다.

시스템 관점으로 전환: 코드와 설정이 바뀌기 시작했다

가장 큰 전환점은 질문을 바꾼 것이다. "누가 실수했나"에서 "어떤 시스템 조건이 이 실수를 가능하게 했나"로. 이 관점 전환은 심리적 안전감 확보만을 위한 게 아니었다. 실질적 이유가 있다. 결제·정산 환경에서 사람의 실수는 거의 항상 시스템이 만든 조건의 산물이다.

구체적인 사례를 들면 이렇다. 우리 팀이 운영하는 자동화 정산 파이프라인에서, 환불 요청이 정산 배치 실행 시점과 5초 이내로 겹칠 때 중복 정산이 발생한 적이 있다. 5-Why 방식으로 접근하면 "배치 실행 전 환불 상태를 확인하지 않았다"는 사람의 행동으로 귀결된다. 시스템 관점으로 접근하면 "배치가 환불 확정 이벤트를 구독하지 않고 스냅샷 기반으로 동작하는 구조"가 문제로 식별된다. 전자는 주의력 강화로 이어지고, 후자는 코드 변경으로 이어진다. 이 관점 전환 이후 학습회에서 나온 개선 항목의 성격이 바뀌었다. "앞으로 더 조심하자" 류의 항목이 줄고, "배치 실행 시 최근 10초 이내 환불 이벤트가 있는 건은 다음 배치로 밀기"처럼 스펙으로 바로 옮길 수 있는 내용이 나오기 시작했다.

현재 형식: 세 가지 질문과 기한 있는 개선 항목

지금 우리가 운영하는 형식은 세 개의 질문으로 구성된다. 첫째, 무슨 일이 있었는가 — 타임라인. 되도록 객관적 사실만, 10분 내에 정리될 수 있어야 한다. 사전에 슬랙 스레드나 로그에서 추출해서 오는 게 원칙이다. 둘째, 이 일을 가능하게 한 시스템의 조건은 무엇이었는가 — 핵심 섹션이다. "만약 다른 사람이 같은 상황에 처했다면 같은 결과가 나왔겠는가?"라는 질문을 기준으로 쓴다. YES라면 시스템 문제다. 셋째, 다음 번에 같은 일이 생기기 어렵게 하려면 무엇을 바꿔야 하는가 — 개선 항목. 여기에는 반드시 담당자와 완료 기한을 붙인다.

이 형식의 트레이드오프도 솔직히 말해야 한다. 회의 시간이 늘어났다. 타임라인만 정리하고 끝내던 30분짜리 회의가 60-90분으로 늘었다. 그러나 개선 항목의 실행률이 눈에 띄게 올라갔다. 기한과 담당자가 붙으니 다음 학습회 시작 전에 "지난번 항목 완료 여부" 체크가 자연스럽게 생겼다. 이 형식 도입 이후 동일 원인 재발 건수가 절반 이하로 줄었다. 샘플이 작아 통계적 의미를 크게 두기는 어렵지만, 방향성은 분명하다.

바로 써먹을 수 있는 시사점

형식을 새로 짜거나 지금 방식이 효과 없다고 느끼는 팀에게, 우리가 실제로 검증한 것만 정리한다.

담당자와 기한 없는 개선 항목은 없는 것과 같다. "다 같이 신경 쓰기"는 아무도 신경 안 쓰는 것과 같다. 결제·정산 환경에서 기한 없는 개선 항목은 다음 장애 전까지 방치된다. 반드시 한 사람의 이름과 날짜가 붙어야 한다.

"만약 다른 사람이 같은 상황이었다면?"을 기준 질문으로 써라. 이 질문 하나가 대화를 사람 탓에서 시스템 탓으로 자연스럽게 옮긴다. 별도의 "심리적 안전 선언"이나 "블레임리스 포스트모템" 선언 없이도 작동한다.

타임라인은 10분 안에 끝내라. 타임라인 정리에 40분을 쓰면 시스템 분석에는 에너지가 남지 않는다. 학습회 시간은 분석과 개선 항목 도출에 써야 한다. 타임라인은 로그와 슬랙 스레드에서 사전에 추출해서 문서로 미리 뿌리는 것이 낫다.

학습회 빈도보다 완료율을 먼저 봐라. 학습회를 자주 하는데 지난 개선 항목이 계속 미완료 상태로 넘어온다면, 형식이 아니라 실행 구조에 문제가 있다. 이 경우 학습회 주기를 늘리더라도 개선 항목 완료 기한을 짧게 잡는 게 낫다. 2주 안에 끝낼 수 없는 개선 항목은 더 작게 쪼개야 한다.

형식은 팀이 실제로 배우는 방식에 맞게 설계되어야 한다. 우리는 세 번 바꿨고 아마 또 바꿀 것이다. 중요한 건 형식이 아니라, 다음 장애가 같은 이유로 나지 않는 것이다.

— by mings