운영 DB 직접 쿼리 — 허용할 것과 막을 것

왜 막지 않았나

팀이 작을 때 운영 DB 직접 쿼리는 생산성이었다. 장애 중에 슬로우 쿼리 잡고, 고객 민원에 즉시 row 확인하고. 전면 차단하면 오히려 우회 경로가 생겼다. 그래서 방향을 바꿨다. 막는 것보다 기준을 세우는 것.

지금 쓰는 기준

허용

• SELECT 전용 계정으로만 접속 (쓰기 권한 물리적으로 없음)
• 접속 전 Slack #db-access 에 목적 한 줄 기록
• 쿼리 실행 전 EXPLAIN 확인 — rows 추정 10만 초과면 팀장 동의
• 세션 타임아웃 10분. 장시간 점유 금지

금지

• UPDATE / DELETE 직접 실행 — 반드시 마이그레이션 스크립트 경로
• 프로덕션 replica 아닌 primary 에 분석용 쿼리
• 접속 기록 없이 진행 (감사 로그는 어차피 남지만, 사전 기록이 핵심)

사고가 났던 패턴

• WHERE 절 빠진 UPDATE → row 전체 덮어씀. 이후 DDL/DML 은 별도 승인 플로우로 분리
• 분석 쿼리가 primary 를 잡아서 서비스 레이턴시 급등. replica 라우팅 강제 이후 0건

다음 한 가지

접속 기록을 Slack 수동 입력 대신 접속 게이트웨이 로그로 자동화 — 사람 손을 거치는 감사 기록은 결국 빠진다.

---

🛒 이 글과 어울리는 추천 상품

• 모니터암 쿠팡에서 보기 →
• 사무용의자 쿠팡에서 보기 →
• 노트북 쿠팡에서 보기 →

위 링크는 쿠팡파트너스 활동의 일환이며, 일정액의 수수료를 제공받을 수 있습니다.