가동 여부는 예/아니오로 답할 수 없습니다
어떤 MCP 서버는 동시에 죽어 있고 살아 있습니다. 연결의 3분의 1을 끊어버리는 서버를 찾았습니다. 브라우저에서는 완벽히 정상으로 보입니다.
브라우저에서는 잘 열리는 서버를 왜 도달 불가로 표시했느냐는 질문을 받았습니다. 질문한 분도 옳았고 저희도 옳았습니다. 그 서버는 대부분 응답하고, 나머지에서는 연결을 끊습니다.
한 서버, 두 개의 진실
스물다섯 번 요청을 보냈습니다. 약 3분의 1이 이렇게 돌아왔습니다.
curl: (56) Recv failure: Connection reset by peer타임아웃도 TLS 문제도 아닙니다. 연결이 맺어지고 요청이 나가고, 서버가 응답 도중에 끊습니다. 요청 간격을 3초로 벌려도 달라지지 않았으니 레이트 리밋도 아닙니다. 저희 측정도 같은 말을 합니다. 해당 호스트로 보낸 탐침의 31%가 실패합니다.
한 번의 점검이 거짓말하는 이유
서버가 세 번 중 한 번 실패한다면, 한 번 점검해서는 거의 아무것도 알 수 없습니다. 3분의 2 확률로 "정상", 3분의 1 확률로 "고장"이라고 말하게 되는데 두 답 모두 똑같이 틀렸습니다. 진실은 상태가 아니라 비율이기 때문입니다.
알림에서는 더 나쁩니다. 연속 두 번의 실패는 장애처럼 보입니다. 실패율 31%에서 연속 두 번은 약 9% 확률로 일어납니다. 두 시간마다 점검한다면 하루에 한 번꼴입니다. 그것은 장애가 아니라 산수입니다.
얼마나 흔한가
확실히 살아 있지도, 확실히 죽어 있지도 않은 서버를 카탈로그 전체에서 찾았습니다. 약 180대가 불안정한 중간 지대에 있으며 실패율은 10%에서 90% 사이입니다. 생태계에서는 작은 조각이지만, 혼란에서는 큰 조각입니다.
어떻게 다룰 것인가
- 서버를 고른다면 배지가 아니라 비율을 보세요. 70%짜리 서버는 운영 환경에서 세 번 중 한 번, 조용히 실패합니다.
- 서버를 운영한다면 간헐적인 연결 리셋은 보통 앱 자체가 아니라 앞단의 프록시나 로드 밸런서를 가리킵니다. 애플리케이션 로그는 깨끗해 보일 것입니다.
- 모니터링을 만든다면 절대 한 번의 표본으로 판단하지 마세요. 연속 실패를 조건으로 걸고, 비율을 분명히 밝히세요.