문제를 먼저 찾는 개발자라고 하셨는데, 실제로 병목을 발견한 사례를 공유해 주실 수 있나요?

병목을 한 번 발견한 뒤 같은 유형의 문제가 다른 곳에서 또 생겼습니다. 매번 처음부터 원인을 찾는 것이 비효율적이라고 느꼈습니다. 병목 유형별 진단 체크리스트를 만들었습니다. 느린 쿼리는 EXPLAIN ANALYZE, 메모리 누수는 힙 스냅샷, 응답 시간 증가는 이벤트 루프 지연과 미들웨어 타이밍 로그를 확인하는 순서로 정리했습니다.

이 체크리스트를 팀에 공유했더니 다른 팀원도 비슷한 문제를 만났을 때 직접 원인을 찾아오는 경우가 늘었습니다. 병목은 한 번 찾으면 끝이 아니라 유사 패턴이 반복될 수 있어서, 발견 절차를 재사용 가능한 형태로 남기는 것이 팀 전체 생산성을 높이는 결이었습니다. 문제를 잘 푸는 것과 그 풀이를 절차로 남기는 것은 다른 결이라는 것을 이 경험에서 배웠습니다.