인증 헬스체크의 캐시 의존을 실시간 핑으로 교체해 감지 사각지대 제거

인증 상태를 캐시에 의존해 판정하던 스크립트를 실제 1회 핑 방식으로 바꿨다. 거짓 정상 상태가 감지되지 않던 사각지대를 제거한 작업이다.

캐시 기반 체크의 위험성

우리 인증 체크 스크립트(claude-auth-check.sh, codex-auth-check.sh)는 원래 이전 실행 결과나 시스템 상태 캐시를 읽어서 "지금 인증이 정상입니다"라고 판정했다. 빠르고 경량이라는 장점이 있었다. 그런데 여기에 함정이 있다.

캐시는 시간이 지나면서 현실과 맞지 않기 시작한다. 예를 들어:
- 토큰이 만료되었는데 캐시엔 아직 유효한 상태로 기록돼 있다
- 네트워크 단절이나 API 서버 장애가 발생했는데, 지난번 성공한 결과가 캐시에 남아있다
- 인증 서비스가 부분적으로 장애 난 상황(한두 테넌트만 문제)을 감지하지 못한다

이런 상황에서 모니터링은 "모든 게 정상입니다"라고 거짓 신호를 보낸다. 온콜이 평화로울 때 실제로는 사용자들이 인증 에러를 마주치고 있고, 우린 그걸 인지하지 못한다. 내가 마지막에 발견한 사건도 이렇게 시작됐다.

실시간 핑으로 뒤집기

변경 내용은 간단하다.

# before: 캐시 파일 확인
if [ -f "$CACHE_FILE" ]; then
    CACHED_AT=$(stat -f %m "$CACHE_FILE" 2>/dev/null)
    if [ $((NOW - CACHED_AT)) -lt 300 ]; then
        # 5분 내 캐시면 OK
        exit 0
    fi
fi

# after: 실제 요청 한 번
RESPONSE=$(curl -s -o /dev/null -w "%{http_code}" \
    -H "Authorization: Bearer $TOKEN" \
    "$AUTH_ENDPOINT/ping")
if [ "$RESPONSE" = "200" ]; then
    exit 0
else
    exit 1
fi

실제로 인증 엔드포인트에 핑을 날려본다. 200이 돌아오면 진짜 정상이다. 그게 안 돌아오면, 그 시점에 문제가 있다는 뜻이다. 캐시의 시차 문제를 완전히 제거한다.

우린 정확도를 택했다.

팀과 온콜에 미친 영향

이 변경의 진짜 의미는 모니터링 신뢰도다.

예전엔 "체크 스크린이 초록불인데 왜 사용자가 로그인 못 한대?"라는 불협화음이 생겼다. 운영팀 입장에서 혼란스럽고, 우리 개발팀도 "스크립트가 뭔가 놓친 건가"라며 매번 디버깅했다. 이제 스크립트가 빨간불을 켜면, 실제로 문제가 있다는 뜻이다. 신호의 신뢰도가 높아졌다.

또한 이런 작은 수정이 쌓이면서:
- 온콜 담당자의 대응 속도가 빨라진다 (가양성이 줄어든다)
- 장애 추적과 분석이 더 정확해진다 (캐시 문제로 인한 혼선이 없다)
- 다음 엔지니어가 이 코드를 읽을 때 의도가 명확하다 (캐시의 복잡함 vs 핑의 직관성)

배운 점: 모니터링과 캐시의 거리

헬스체크나 모니터링 스크립트를 짤 때 자주 마주치는 실수다. 성능 때문에 캐시를 도입하면, 그 캐시가 버그 하나가 되기 쉽다. 특히 인증이나 상태 확인처럼 정확성이 중요한 부분에선 더욱 그렇다.

실시간 핑은 추가 네트워크 비용이 있지만:
- 헬스체크는 보통 5분~10분 간격으로 돈다 (충분히 spacing 가능)
- 장애를 놓치는 비용 >> 핑 한 번의 네트워크 비용
- 거짓 정상 하나가 온콜의 신뢰를 깎아먹는다

다음.

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

• 모니터암 쿠팡에서 보기 →
• 인체공학의자 쿠팡에서 보기 →
• 기계식키보드 쿠팡에서 보기 →

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