운영 데이터베이스 문제를 빠르게 진단하기

검색해서 들어온 상황이라면 바로 재현 조건부터 잡는 편이 빠르다. DB 쪽 문제는 화면만 보고 판단하면 놓치는 값이 많다.

핵심은 한 단어만 붙잡지 않고 데이터 계층 전체 흐름에서 원인을 좁히는 것이다. 재현 조건, 로그, 응답처럼 눈으로 확인할 수 있는 값을 먼저 모은다.

상황을 간단하게 요약하기

문제가 뭐며, 언제부터 생겼으며, 누가 영향을 받는지 정리한다. 이 요약이 명확하면 다음 수정이 빠르다.

• 증상: 어떤 쿼리가 느린가
• 시점: 언제부터 문제인가
• 영향: 모든 사용자인가 특정 사용자인가

데이터 계층 작업은 로컬과 운영의 차이가 자주 숨어 있다. 환경 차이까지 같이 적어두면 원인 추적이 쉬워진다.

증거를 모으는 것이 먼저

직관으로 추측하지 말고, 실제 증거를 수집한다. 권한, 쿼리 성능, 데이터 량을 확인한다.

• 현재 권한은 뭔가
• 어떤 쿼리가 얼마나 오래 걸리는가
• 데이터가 얼마나 많은가

스키마 확인은 기본

현재 스키마가 뭔지 미리 정해두면 변경 전후 차이를 명확하게 볼 수 있다.

npx prisma validate
npx prisma migrate status

이 명령으로 스키마의 일관성을 확인하고, 적용되지 않은 마이그레이션이 있는지 본다.

가능한 원인들을 좁혀나가기

원인이 뭔지 모르면 가능한 경우들을 하나씩 제거해간다.

• DATABASE_URL이 맞는가
• 권한이 충분한가
• 마이그레이션이 모두 적용됐는가
• 인덱스가 필요한가

각 단계에서 결과를 기록한다.

가장 작은 실험부터 시작하기

운영 환경에서는 큰 변경을 피한다. 한 가지 설정만 수정하고 결과를 본다.

1. 한 가지 설정 수정
2. 백업 먼저 확인
3. 작은 변경 실행
4. 결과 확인
5. 기록 남기기

백업이 통과 기준

변경 전에 반드시 백업을 한다. 백업이 없으면 변경을 시작할 수 없다. 백업이 정상인지 확인하는 것도 중요하다.

배운 점을 남겨두기

같은 문제가 또 나올 수 있다. 이번에 뭐가 문제였고 어떻게 해결했는지 명확하게 기록한다.

• 뭘 바꿨는가
• 왜 바꿨는가
• 어떤 증거로 판단했는가
• 결과가 뭐였는가

이 정보들이 정리되어 있으면 나중에 비슷한 상황이 생겼을 때 훨씬 빠르게 대응할 수 있다. 작은 확인을 남겨두면 다음 문제를 훨씬 짧게 처리할 수 있다.