이 문서를 통해 아래 질문들에 답할 수 있게 됩니다.
- 백엔드 개발자는 인프라/DBA와 어떤 언어로 소통해야 하는가?
- DB 관련 요청을 할 때 어떤 정보를 함께 전달해야 하는가?
- 인프라/DBA 입장에서 개발자의 어떤 행동이 가장 힘든가?
개요
DB는 백엔드와 인프라의 접점이다. 백엔드 개발자는 SQL과 트랜잭션을 만들고, 인프라/DBA는 DB 서버, 복제, 백업, 장애 복구, 모니터링을 책임진다. 둘 중 하나만 잘해도 충분하지 않다.
좋은 협업은 추상적인 불평이 아니라 재현 가능한 정보와 선택지를 공유하는 데서 시작한다.
원리
인프라/DBA 협업의 원리는 서로의 책임을 넘기는 것이 아니라 서로에게 없는 맥락을 제공하는 것이다. 백엔드는 비즈니스 흐름, 코드 변경, 트랜잭션 경계를 알고 있고, 인프라/DBA는 DB 내부 wait, 복제, 백업, 용량, 장애 복구 제약을 알고 있다.
좋은 협업은 “DB가 느려요”가 아니라 “이 시간대에 이 API의 이 SQL이 이런 계획으로 실행되고, 이 변경 이후 이런 지표가 변했으니 이 선택지를 함께 판단하자”에 가깝다.
상황
나쁜 요청은 다음과 같다.
DB가 느린 것 같습니다. 확인 부탁드립니다.좋은 요청은 다음에 가깝다.
오늘 14:10부터 GET /api/posts?boardId=3 p95가 250ms에서 2.8s로 증가했습니다.
주요 SQL은 board_id 조건 + created_at desc 정렬 + limit 20입니다.
현재 실행 계획에서 rows가 약 120만이고 Sort가 발생합니다.
13:55에 게시글 검색 기능 배포가 있었습니다.
후보 인덱스는 (board_id, created_at desc, id desc)입니다.
운영 테이블이 8천만 건이라 온라인 생성 가능 여부를 같이 확인하고 싶습니다.이 요청은 문제, 시간, SQL, 증거, 변경 이력, 원하는 협업 지점을 모두 담고 있다.
DB 요청별 필요한 정보
인덱스 추가 요청:
- 대상 SQL
- 현재 실행 계획
- 호출 빈도와 지연 시간
- 후보 인덱스
- 테이블 크기
- 배포 희망 시간
- 쓰기 부하 영향
장애 분석 요청:
- 시간대
- 영향 API
- 에러율과 지연 지표
- 애플리케이션 배포 이력
- batch와 migration 이력
- pool 지표
- 사용자 영향
마이그레이션 요청:
- DDL 내용
- 대상 테이블 크기
- lock 예상
- backfill 계획
- 롤백 또는 forward fix 계획
- 검증 쿼리
스펙 증설 요청:
- 병목 지표
- 상위 쿼리
- CPU/I/O/memory 추이
- 최적화로 해결 가능한 부분
- 예상 트래픽 증가
요청은 다음 형식으로 보내면 좋다.
요청 종류: 인덱스 생성 검토
문제: GET /api/posts p95 300ms -> 2.5s
시간대: 2026-07-01 14:10~현재
SQL: board_id 조건, created_at desc 정렬, limit 20
현재 계획: rows 120만, Sort 발생
후보: (board_id, created_at desc, id desc)
테이블: posts 약 8천만 row, write QPS 500
우려: online index 가능 여부, replica lag, 쓰기 지연
원하는 결정: 오늘 야간 생성 가능 여부와 중단 기준이 정도의 정보가 있으면 인프라/DBA는 바로 위험 평가를 시작할 수 있다.
백엔드가 이해해야 할 인프라 고충
인프라/DBA는 다음 부담을 가진다.
- DB는 상태를 가진 시스템이라 재시작과 롤백이 쉽지 않다.
- 대형 DDL은 테이블 락, 복제 지연, 백업 영향이 있다.
- max connections를 넘으면 운영자 접속도 어려울 수 있다.
- 장애 중 query kill은 롤백 비용과 데이터 영향이 있다.
- 백업은 용량, 비용, 복구 시간, 데이터 손실 범위가 함께 묶인다.
- 개발팀의 배포와 배치가 DB 부하를 갑자기 바꾼다.
개발자가 이 고충을 이해하면 “왜 바로 못 해주나요?” 대신 “어떤 위험을 줄이면 실행 가능할까요?”라고 묻게 된다.
특히 인프라/DBA는 “성공하면 티가 덜 나고 실패하면 크게 보이는” 일을 많이 한다. 백업, replication, connection 예산, DDL lock 회피, 용량 계획은 평소에는 조용하지만 한 번 실패하면 서비스 전체 장애가 된다. 이 점을 이해하면 요청의 톤도 달라진다.
백엔드가 제공해야 할 맥락
DBA는 SQL과 서버 상태는 볼 수 있지만, 비즈니스 의미는 개발자보다 덜 알 수 있다.
- 이 상태값은 얼마나 중요한가?
- 이 테이블은 사용자-facing인가?
- 이 작업은 중단해도 되는가?
- 중복 처리가 가능한가?
- 재처리 가능한 이벤트인가?
- 이 API는 캐시해도 되는가?
이 정보가 있어야 운영 판단을 할 수 있다.
하지 말아야 할 대응
- 운영 DB에서 임의로 대량 UPDATE를 실행한다.
- 실행 계획 없이 인덱스 생성을 요청한다.
- DB 장애를 인프라 문제로만 몰아간다.
- 스키마 변경을 배포 직전에 갑자기 요청한다.
- pool size 변경을 애플리케이션 팀만 결정한다.
- 장애 후 회고에 DB 지표를 남기지 않는다.
실전 팁
- 요청에는 시간대, endpoint, SQL, 실행 계획, 지표, 배포 이력을 함께 담는다.
- 인덱스나 DDL 요청은 테이블 크기와 lock 위험을 함께 논의한다.
- pool 변경은 전체 인스턴스 수와 DB max connections 기준으로 이야기한다.
- 장애 중에는 비즈니스 영향과 중단 가능한 작업을 개발자가 명확히 알려준다.
- 회고에는 DBA가 제공한 DB 내부 증거와 개발팀의 코드 맥락을 함께 남긴다.
- 요청에는 원하는 답을 정해 보내기보다 선택지와 제약을 같이 제시한다.
- 장애 중에는 DBA가 DB 내부를 볼 시간을 벌 수 있도록 비핵심 트래픽과 batch를 줄이는 결정을 빠르게 돕는다.
- 회고에서는 “누가 잘못했는가”보다 “어떤 관측과 제한이 없어서 늦었는가”를 남긴다.
주니어 팁
인프라/DBA에게 질문할 때는 “확인 부탁드립니다” 대신 “제가 확인한 사실”과 “제가 모르는 부분”을 나눠 말한다.
확인한 것: 특정 API와 SQL, 실행 계획, 배포 시간
모르는 것: DB 내부 lock wait와 replica lag 여부
요청: 해당 시간대 wait event와 blocking query 확인시니어 팁
시니어는 협업 요청을 의사결정 문서로 만든다.
- 선택지 A: 인덱스 추가
- 선택지 B: 쿼리 변경
- 선택지 C: 임시 캐시
- 선택지 D: 기능 제한
각 선택지의 장단점, 위험, 롤백 가능성을 비교하면 인프라/DBA와 훨씬 빠르게 합의할 수 있다.
Guru급 팁
좋은 백엔드 개발자는 DBA의 일을 대신하지 않는다. 대신 DBA가 더 좋은 판단을 할 수 있게 애플리케이션 맥락을 제공한다. 좋은 DBA도 백엔드 코드를 대신 고치지 않는다. 대신 DB 내부에서 실제로 무슨 일이 일어나는지 증거를 제공한다. 이 접점이 성숙한 팀의 운영 품질을 만든다.
위험 신호!
- “DB가 느려요”만 전달하고 SQL과 시간대를 주지 않는다.
- 운영 DB 직접 변경을 개인 판단으로 실행한다.
- 인덱스 추가의 쓰기 비용과 DDL 위험을 무시한다.
- 장애 후 개발팀과 인프라팀 회고가 분리된다.
- DB 연결 총량을 아무도 소유하지 않는다.
- 스펙 증설을 요청하면서 상위 SQL, 호출량, 최적화 대안은 제시하지 않는다.
- DBA가 묻는 비즈니스 영향 질문을 기술 질문이 아니라고 가볍게 본다.
확인 질문
- 인덱스 추가 요청에 반드시 포함해야 할 정보는 무엇인가?
- 대상 SQL, 실행 계획, 호출 빈도, 지연 시간, 후보 인덱스, 테이블 크기, 배포 위험이다.
- DBA가 비즈니스 맥락을 필요로 하는 이유는 무엇인가?
- 어떤 작업을 중단하거나 지연해도 되는지, 어떤 데이터가 반드시 정합해야 하는지 알아야 운영 판단을 할 수 있기 때문이다.
- 백엔드 개발자가 인프라 고충을 이해해야 하는 이유는 무엇인가?
- DB 변경은 복제, 백업, 락, 연결 수, 장애 복구에 영향을 주므로 코드 변경보다 더 넓은 운영 리스크를 갖기 때문이다.
- 좋은 DB 협업 요청의 기본 구조는 무엇인가?
- 요청 종류, 문제 시간대, 영향 API, 실제 SQL, 실행 계획, 지표 변화, 최근 변경, 후보 선택지, 원하는 결정 사항을 담는 것이다.