경험 중심 1인칭 답변
장애 RCA를 진행한 경험은 팀 프로젝트에서 배포 후 특정 조건에서만 API 오류가 발생하는 상황을 분석한 것입니다. 처음에는 코드 변경이 원인이라고 가정했는데, 로그를 시간순으로 정렬해 오류가 발생한 패턴을 추적하자 특정 입력값 조합에서만 재현된다는 것을 확인했습니다.
5 Whys 방식으로 원인을 파고들자 표면적 원인(코드 오류)보다 입력 유효성 검증 누락이 근본 원인이라는 것이 드러났습니다. 수정 후에는 같은 유형의 입력 케이스를 테스트에 추가해 재발을 방지했고, 팀 내에서 유사 패턴의 다른 엔드포인트도 점검하는 절차를 만들었습니다. RCA에서 중요한 것은 증상을 고치는 것이 아니라 같은 원인이 다른 곳에서도 생길 수 있는지를 확인하는 것이라고 생각합니다. 앞으로도 장애 분석을 할 때 증상이 아니라 원인의 원인까지 파고드는 5-why 접근을 유지하겠습니다.
RCA는 재발 방지를 위한 것이지 책임 추궁이 아닙니다. 장애 이후의 회고가 다음 설계를 바꿉니다. 같은 장애는 두 번 나면 안 됩니다.