운영 DB에 직접 쿼리 — 내가 허용하는 범위와 그 이유

운영 DB에 손대는 순간 심박수가 올라간다. 그게 정상이다. 근데 그 긴장감 때문에 SELECT 조차 금기처럼 다루다가 장애 대응이 늦어지는 팀을 꽤 봤다.

허용할 건 허용하고, 막을 건 막아야 한다. 그 기준이 없으면 결국 ‘눈치껏’이 된다.

왜 기준이 필요한가

지난해 결제 팀에서 이런 일이 있었다. 정산 오류 신고가 들어왔고, 원인을 파악하려면 특정 주문의 이벤트 로그를 봐야 했다. 근데 데이터 플랫폼 팀 쿼리 요청 프로세스를 타면 최소 4시간. 그래서 아무도 운영 DB 직접 접근을 건드리지 못하고 있었고, 고객 CS는 7시간째 답을 못 받고 있었다.

막상 접근해서 쿼리한 건 SELECT * FROM orders WHERE id = ? 한 줄이었다. 그 한 줄을 7시간 동안 못 쳤다. 기준이 없으면 이렇게 된다.

읽기와 쓰기는 완전히 다른 문제다

SELECT 는 데이터를 망가뜨리지 않는다. 하지만 락은 걸 수 있다. 그게 함정이다.

조건 없는 SELECT COUNT(*) — 테이블이 3천만 건이면 풀스캔이 돌고, 복제 지연이 생긴다. 실제로 2026년 초 어떤 팀에서 모니터링 쿼리 하나가 replica lag 40초를 만든 사례가 있었다. 프라이머리가 아니라 레플리카에 쐈는데도 그랬다. 인덱스를 안 타는 WHERE 절이 문제였다.
UPDATE / DELETE 는 트랜잭션 래핑이 기본 — BEGIN 없이 날리면 롤백 불가. 이건 규칙이 아니라 생존 본능이다. 한 번 DELETE FROM user_sessions WHERE user_id = ? 를 WHERE 조건 빠진 채로 날린 사람 이야기를 들은 적 있다. 다행히 스테이징이었지만, 운영이었다면 세션 전체가 날아갔다.
DDL 은 원칙상 금지 — 운영 중 ALTER TABLE 은 락 이슈가 예측 불가다. pt-online-schema-change 같은 도구 없이 손으로 치는 건 룰렛이다.

내가 세운 허용 기준 세 줄

기준을 세 줄로 정리하면 이렇다.

첫째, 읽기 전용 레플리카에서 SELECT 만 — 프라이머리는 건드리지 않는다. 레플리카도 실행계획을 EXPLAIN으로 먼저 확인하고, 예상 rows 가 100만을 넘으면 데이터 플랫폼 팀 경로로 넘긴다.

둘째, 쓰기는 BEGIN + 확인 후 COMMIT — UPDATE/DELETE 를 칠 때는 반드시 BEGIN 으로 트랜잭션을 열고, SELECT 로 영향 범위를 먼저 확인한 다음 커밋한다. 이 루틴을 팀 위키에 박아뒀다.

셋째, 슬랙 #db-ops 에 전후 기록 — 쿼리 시작 전에 “뭘 왜 보려는지” 한 줄, 끝나면 결과 요약 한 줄. 사후 감사 로그가 아니라 실시간 가시성이다. 누군가 이상한 쿼리를 치면 바로 보인다.

접근 계정도 구분한다

운영 DB에 접근할 때 DBA 계정을 공용으로 쓰는 팀이 아직도 많다. 그러면 누가 언제 뭘 했는지 추적이 안 된다.

우리는 개인 계정 + 권한 분리를 했다. 읽기 전용 계정은 레플리카 접근만 가능하고, 쓰기 권한 계정은 별도 요청·승인 절차를 거친다. 승인 없이 쓰기 계정 비밀번호를 아는 사람은 현재 두 명뿐이다. 그 두 명이 모두 자리를 비우는 상황을 대비해 Vault에 break-glass 접근을 하나 만들어뒀는데, 쓴 적은 아직 없다. 쓰게 되는 날이 오면 그날 회고를 써야겠다 싶다.

장애 중에는 평상시 기준이 흔들린다

솔직히 말하면, 장애 상황에서 내 기준이 흔들린 적이 있다. 레플리카 지연이 60초를 넘어서 정확한 데이터를 봐야 하는데 프라이머리밖에 답이 없는 순간. 그때 프라이머리에 쿼리를 쳤다.

결과는 괜찮았다. 쿼리 자체가 인덱스를 잘 탔고, 실행 시간은 12ms였다. 하지만 ‘괜찮았다’는 게 ‘옳았다’는 뜻은 아니다. 그때 EXPLAIN을 먼저 돌린 건 맞지만, 장애 중 긴장감 속에서 그 판단이 항상 냉정하리란 보장이 없다.

그래서 추가한 게 하나 있다. 장애 대응 중 프라이머리 직접 쿼리를 쳤을 경우, 장애 회고에 무조건 한 줄 기록한다. 왜 레플리카를 못 썼는지, 실행계획 확인은 했는지, 결과는 어땠는지. 이게 쌓이면 언젠가 패턴이 보인다.

다음 한 가지

팀 위키에 허용 기준을 적어뒀는데, 신규 입사자가 실제로 그걸 보고 따르는지 확인한 적이 한 번도 없다. 다음 분기 온보딩 때 DB 접근 기준 실습을 30분짜리 세션으로 한 번 돌려본다.

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

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