새벽 2시 디버깅: 진짜 도움이 되는 것들

새벽 2시야. PagerDuty 알림에 폰이 울렸어. 프로덕션에서 뭔가 터졌어. 뇌는 40% 정도밖에 안 돌아가는 중이야.

지금은 기발한 디버깅을 할 때가 아니야. 반쯤 잠든 상태에서도 작동하는 체계적이고, 지루하고, 확실한 기법을 쓸 때야.

수많은 야간 장애에서 배운 것들을 정리해볼게.

1단계: 뭐가 바뀌었어?

프로덕션 버그의 90%는 최근에 뭔가 바뀌어서 생겨. 배포. 설정 업데이트. 데이터베이스 마이그레이션. 만료된 인증서.

코드를 읽기 전에, 마지막으로 작동했을 때랑 뭐가 다른지 파악해.

현재 설정을 마지막으로 정상이었던 것과 비교해봐. 텍스트 비교 도구를 쓰면 두 파일을 나란히 놓고 눈 찡그리는 대신 10초면 끝나.

진짜야. 한번은 "미스터리한" API 장애를 45분 동안 디버깅했는데, 알고 보니 JSON 설정에서 콤마 하나 잘못 넣은 거였어. diff였으면 몇 초 만에 잡았을 텐데.

2단계: 실제 에러를 읽어

당연한 소리 같지? 근데 아니야.

피곤하면 에러 메시지를 보고 바로 가설을 세워. "아 아마 데이터베이스 연결이겠지." 20분 동안 데이터베이스를 확인해. 에러 메시지는 TypeError: Cannot read property 'name' of undefined이었어. 데이터베이스랑 아무 상관없었어.

에러를 읽어. 다시 읽어. 스택 트레이스를 읽어. 정확한 코드 라인까지 따라가.

3단계: 에러를 읽을 수 있게 만들어

프로덕션 로그는 지저분해. 다 한 줄에 있고, JSON 객체는 포맷 안 돼 있고, 타임스탬프는 유닉스 에포크 포맷이야.

그 JSON 덩어리를 복사해서 JSON 포맷터에 붙여넣으면 갑자기 에러 응답을 읽을 수 있어.

포맷터 탭을 항상 열어놔. 장애 중에 API 응답, 로그 항목, 설정 파일을 이해하려고 몇 분마다 써.

4단계: 추측하지 말고 격리해

피곤한 뇌는 추측을 좋아해. "아마 이거일 거야. 저거 바꿔볼까."

참아. 무작위로 바꿀 때마다 불확실성이 늘어나. 이제 원래 문제가 고쳐진 건지 아니면 네 수정이 새 문제를 만든 건지 모르게 돼.

대신: 가능한 가장 작은 입력으로 에러를 재현해. 필요 없는 건 다 빼. 중요한 변수 하나를 찾아.

5단계: 지루한 것들 확인해

코드에 뛰어들기 전에 확인할 것:

• DNS: 제대로 리졸빙 되고 있어?
• 인증서: 만료된 거 있어?
• 디스크 공간: 서버가 꽉 찼어?
• 메모리: 뭔가 리크하고 있어?
• 의존성: 외부 API가 죽었어?

모니터에 이 다섯 항목을 포스트잇으로 붙여놨어. 장애 나면 이것부터 확인해. 실제 코드 버그보다 이것들이 근본 원인인 적이 더 많았어.

새벽 2시 디버깅 툴킷

알림에 깨면 여는 브라우저 탭들:

1. 텍스트 비교 — 설정, 환경 변수, 배포 파일 비교용
2. JSON 포맷터 — API 응답이랑 로그 항목 읽기용
3. 정규식 테스터 — 패턴으로 로그 검색용
4. 일반 텍스트 편집기 — 뭘 시도했는지 메모용

마지막 거는 생각보다 중요해. 새벽 2시에 단기 기억은 쓰레기야. 뭘 시도했고 결과가 어땠는지 적어놔. 미래의 내가 과거의 나한테 고마워할 거야.

장애가 끝난 후

불은 꺼졌어. 그냥 다시 자러 가지 마. 5분 써서 적어둬:

• 뭐가 터졌는지
• 왜 터졌는지
• 뭘로 고쳤는지
• 다음에 어떻게 방지할지

내일이면 기억 못 해. 지금 적어놔.

---

최고의 새벽 2시 디버깅은 똑똑한 게 아니라 체계적인 거야. 설정 비교해. 에러 읽어. 로그 포맷해. 지루한 것들 확인해. 적어놔. 이게 전부야.