MCP 데이터베이스 서버는 읽기 전용(read-only)이고 범위가 잘 제한되어 있더라도, 여전히 운영 환경(production)을 다운시킬 수 있습니다.

실패 경로는 익숙합니다:

1. 여러 에이전트(agents)가 동시에 도구(tools)를 호출합니다.
2. 각 도구가 데이터베이스 커넥션(database connection)을 빌려옵니다.
3. 몇몇 쿼리(queries)가 예상보다 오래 실행됩니다.
4. 풀(pool)이 가득 찹니다.
5. 호출자들이 대기열(queue)에 쌓입니다.
6. 재시도(retries)가 일시적인 폭증을 지속적인 압박으로 바꿉니다.

풀 크기는 단순한 성능 설정이 아닙니다. 그것은 허가 제어(admission-control) 결정입니다.

애플리케이션, 관리(administration), 마이그레이션(migrations), 모니터링(monitoring), 그리고 장애 상황(incidents)을 위한 용량을 예약한 후, 데이터베이스 예산(database budget)부터 시작하세요. 그런 다음 그 예산을 최대 MCP 서버 복제본(replicas) 수로 나눕니다.

채팅 세션(chat sessions)이 아니라 **도구 실행(tool executions)**으로부터 수요를 측정하세요:

• 피크 동시 도구 실행 수 (peak concurrent tools)
• 도구당 유지되는 커넥션 수 (connections held per tool)
• p50/p95/p99 유지 시간 (hold time)
• 대기열(queue), 타임아웃(timeout), 취소(cancellation), 그리고 재시도율(retry rates)

수요가 데이터베이스 예산을 초과할 때, 해결책은 모든 복제본에 단순히 더 큰 숫자를 복사해 넣는 것이 아니라, 제한된 대기열(bounded queue)과 명확한 과부하 동작(overload behavior)을 갖추는 것입니다.

또한 빠른 메타데이터 도구(metadata tools)와 비용이 많이 드는 분석 도구(analytical tools)를 분리하세요. 하나의 느린 집계(aggregation) 작업이 상태 확인(health checks)과 제한된 조회(bounded lookups)를 불가능하게 만들어서는 안 됩니다.

마지막으로, 운영 환경에서 사용되는 정확한 드라이버(driver), PgBouncer 모드, TLS 경로, 역할(role), 그리고 쿼리 혼합(query mix)을 테스트하세요. 그런 다음 의도적으로 풀을 고갈시키고 데이터베이스를 중단시켜 보십시오.

건강한 시스템은 과도한 작업을 명확하게 거부하고, 취소된 커넥션을 해제하며, 동기화된 재시도(synchronized retries)를 피해야 합니다.

전체 가이드: MCP database connection pool sizing