AI 생성 설명 기능에서 단 하나의 세이프티 게이트(safety-gate) 지표가 하루 전체의 장애를 숨기고 있었다는 사실을 발견했습니다. "게이트 거부(gate rejection)"와 "모델 로드 실패(model load failure)"를 동일한 것으로 취급함으로써, 해당 지표는 시스템이 정상이라는 잘못된 안도감을 주었습니다. 로그에는 4건의 거부와 0건의 성공이 기록되었지만, 실제로는 해당 기간 동안 모델이 전혀 실행되지 않았습니다. 이는 운영자가 고장 난 시스템을 인지하지 못하게 만들 수 있는 실수였습니다.
혼란이 발생한 이유
이 기능은 로컬 언어 모델을 사용하여 가공되지 않은 머신 로직을 사람이 읽을 수 있는 문장으로 변환합니다. 다운스트림의 세이프티 게이트는 사전 정의된 규칙을 위반하는 모든 출력을 차단합니다. 프로덕션 환경에서 저는 게이트가 문장을 거부할 때마다 증가하는 단일 카운터를 노출했습니다. 드론이 4개의 AI 설명을 기록했을 때, 카운터는 4건의 거부와 성공적인 출력 0건을 보고했습니다. 저는 이를 기능이 중단된 것이 아니라 게이트가 제 역할을 수행하고 있는 것으로 판단했습니다.
카운터가 가리고 있었던 것은 다음과 같은 2단계 장애였습니다:
- 모델 미실행 – 모델은 시스템의 나머지 부분과 머신을 공유합니다. 메모리를 절약하기 위해 호스트는 비활성 상태가 되면 모델을 언로드(unload)합니다.
- 재로드 시 타임아웃 발생 – 새로운 위협이 나타났을 때, 시스템은 약 2GB의 모델 데이터를 재로드하려고 시도했습니다. 재로드 과정이 30초 응답 타임아웃을 초과했고, 그 결과 요청이 타임아웃되어 빈 응답이 반환되었습니다.
카운터가 게이트 거부와 타임아웃으로 인한 빈 응답을 동일한 이벤트로 처리했기 때문에, 대시보드에는 "세이프티 게이트 작동 중"이라고 표시되었지만 AI 기능은 사실상 마비된 상태였습니다.
이것이 중요한 이유
AI 기반 제품에서 세이프티 게이트는 유해하거나 터무니없는 출력을 차단합니다. 운영자는 게이트의 발생 빈도(fire rate)를 상태 신호로 모니터링합니다. 이 신호가 관련 없는 장애 모드와 결합되면, 지표는 "침묵의 거짓말"이 됩니다. 서비스가 불가능한 상태임에도 불구하고 시스템이 정상인 것처럼 안심시키기 때문입니다.
가시성을 회복한 해결책
저는 세 가지 실질적인 변경을 수행했습니다:
- 모델 상주 유지 – 호스트가 모델을 메모리에 유지하도록 조정하여 재로드 지연을 제거했습니다.
- 타임아웃 연장 – 간헐적인 느린 로드를 처리할 수 있도록 응답 시간을 늘렸습니다.
- 카운터 분리 – 단일 "게이트 거부(rejected by gate)" 지표를 수락(accepted), 거부(rejected), 빈 응답(empty response), *응답 없음(no answer)*의 네 가지 별도 카운터로 교체했습니다.
세 번째 단계가 결정적이었습니다. 어떻게든 해석될 수 있는 단일 숫자 대신, 네 부분으로 나뉜 상세 내역을 통해 세이프티 게이트가 활성화되어 있는지, 모델이 응답하고 있는지, 아니면 요청이 모델에 도달조차 하지 않았는지를 보여줍니다.
트레이드오프 및 반론
다음에 주의 깊게 살펴볼 것
AI 컴포넌트를 배포하는 개발자는 세이프티 체크와 시스템 수준의 장애를 혼합하여 집계하는 모든 카운터를 점검해야 합니다. 모델 로드 시작, 게이트 평가, 최종 결과 등 각 요청의 경로를 기록하는 상세 이력 로그를 구축하면 숨겨진 문제를 찾아내는 데 필요한 포렌식 데이터를 확보할 수 있습니다.
요약: 단일 "게이트 거부" 지표는 중단된 AI 서비스를 은폐할 수 있습니다. 해당 지표를 구성 요소별 이벤트로 분리하면 진실이 드러나며, 실제로 작동하지 않는 시스템에 대해 잘못된 확신을 갖는 것을 방지할 수 있습니다.