실전 DB 시나리오와 판단 기준

실전 DB 역량은 개념을 아는 것보다 특정 상황에서 무엇을 먼저 확인하고, 누구와 어떤 언어로 협업하며, 무엇을 하지 않을지 판단하는 능력이다.
신규 기능, 느린 API, 장애, 마이그레이션, 인프라 협업은 백엔드 개발자가 반복해서 마주치는 대표 DB 업무 상황이다.
좋은 대응은 원인 격리, 영향 범위 축소, 재현 가능한 증거 수집, 임시 완화와 근본 해결 분리를 포함한다.

신규 기능 개발에서는 데이터 불변식, 조회 패턴, 인덱스, 트랜잭션 경계, 마이그레이션 순서, 운영 지표를 설계 단계에서 같이 본다.
느린 API 대응은 애플리케이션 로그, 실제 SQL, 실행 계획, DB 지표, 커넥션 풀 지표, 락 대기를 순서 있게 연결하는 일이다.
장애 상황에서는 원인 추측보다 영향 범위와 완화가 먼저다. 어떤 API가 느린지, DB 전체인지 특정 쿼리인지, 읽기와 쓰기 중 어디가 막혔는지 분리한다.
마이그레이션은 코드 배포와 DB 변경의 시간차를 고려한다. 롤링 배포 중 구버전과 신버전이 동시에 작동할 수 있다.
인프라/DBA 협업에서는 “느려요”가 아니라 SQL, 시간대, 호출량, 실행 계획, 트랜잭션 길이, 변경 배포 이력을 가져가야 대화가 빨라진다.
하지 말아야 할 대응은 timeout만 늘리기, pool size만 키우기, 운영 DB에 대형 DDL 즉시 실행, 실행 계획 없이 인덱스 추가, 장애 중 대량 배치 재시작이다.
실전 판단은 “임시 완화”와 “근본 해결”을 분리한다. rate limit, 배치 중지, 캐시 우회 같은 완화와 인덱스/쿼리/스키마/트랜잭션 개선은 서로 다른 작업이다.
좋은 요청 문서는 시간대, 영향 범위, 실제 SQL, 지표, 최근 변경, 원하는 결정 사항을 담는다. 이 형식은 인프라/DBA와의 협업 비용을 크게 줄인다.

장애가 나면 가장 느린 쿼리 하나만 고치면 된다고 생각하기 쉽다. 눈에 띄는 slow query가 원인처럼 보이기 때문이다.
- 핵심은 slow query가 원인일 수도 결과일 수도 있다는 점이다.
- 커넥션 고갈, 락 대기, DB CPU, 배포 변경, 외부 호출 지연을 함께 봐야 한다.
인프라/DBA에게 맡기면 DB 문제는 끝난다고 생각하기 쉽다. DB 서버 권한이 개발자에게 없기 때문이다.
- 핵심은 쿼리와 트랜잭션을 만든 쪽은 백엔드 코드라는 점이다.
- DBA는 서버와 엔진을 보지만, 개발자는 비즈니스 흐름과 코드 변경 맥락을 제공해야 한다.
개인 프로젝트에서는 운영 수준의 절차가 과하다고 느끼기 쉽다. 트래픽이 작기 때문이다.
- 핵심은 작은 서비스도 데이터 손실과 복구 실패가 치명적일 수 있다는 점이다.
- 최소한 migration history, backup, timeout, slow query 확인 루틴은 갖추는 편이 좋다.
장애 중 원인을 바로 고치려는 마음이 앞서기 쉽다. 빠른 해결이 전문성처럼 보이기 때문이다.
- 핵심은 먼저 피해 확산을 멈추고 관측 가능한 증거를 보존해야 한다는 점이다.
- 어떤 조치가 어떤 지표를 개선해야 하는지 정하고 하나씩 적용한다.

느린 API 대응에서 가장 먼저 모아야 할 증거는 무엇인가?
- 느린 시간대, API endpoint, 실제 SQL과 바인딩 값, 호출량, 응답 시간 분포, 실행 계획, 커넥션 풀과 DB 지표다.
장애 중 하지 말아야 할 대표 대응은 무엇인가?
- 원인 확인 없이 pool size나 timeout만 늘리거나, 운영 DB에 대형 DDL과 대량 배치를 즉시 실행하는 것이다.
인프라/DBA와 대화할 때 백엔드 개발자가 가져가야 하는 정보는 무엇인가?
- 코드 배포 이력, 문제 API, SQL, 트랜잭션 경계, 호출량 변화, 에러 로그, 재현 조건, 비즈니스 영향 범위다.
실전 대응에서 임시 완화와 근본 해결을 나누는 이유는 무엇인가?
- 장애 중에는 피해 확산을 먼저 막아야 하고, 구조 개선은 검증과 배포 계획이 필요한 별도 작업이기 때문이다.

동블