가설 기반 원인 분석
약 75초
증상에서 가능한 원인 가설을 세우고 데이터로 하나씩 검증하는 방법
학부 캡스톤 프로젝트에서 서비스 응답 시간이 특정 시간대에 느려지는 원인을 찾아야 했습니다. 처음에는 여러 가능성을 동시에 수정하려다가 어떤 변경이 효과가 있었는지 알 수 없게 됐습니다. 그래서 트래픽 급증, 데이터베이스 쿼리, 외부 API 호출 세 가지 가설을 세우고 각각 로그 데이터로 하나씩 확인했더니 데이터베이스 쿼리에서 원인이 발견됐습니다. 현장 운영자에게 설명할 때는 가설-검증 과정 전체보다 결론과 그 근거만 간단히 전달하는 게 더 효과적이라는 것도 그때 배웠습니다.
이 결의 특징
여러 가능성을 동시에 고치다 무엇이 효과였는지 잃은 실패 뒤, 트래픽·쿼리·외부 호출 세 가설을 세워 하나씩 로그로 확인해 쿼리에서 원인을 찾은 흔적이 있습니다. 운영자에겐 과정 전체보다 결론과 근거만 전한다는 전달 감각까지 더했습니다.
이 결이 통하는 자리
원인 분석을 '가설을 세워 하나씩 검증'이라는 절차로 풀 때 통합니다. 동시 수정의 실패와 가설 분리의 대비가 한 일화로 살아 있는 자리에서, 면접관의 꼬리질문이 줄어드는 결이 보입니다.