온프레미스 AI 배포하면서 겪은 장애 패턴 3가지

PoC에서 잘 돌아간 AI를 운영 환경에 올리면 뭐가 달라지는가. McKinsey 연례 조사(2025.11) 기준 응답 조직 88%가 AI를 최소 1개 기능에 도입했다고 답했는데, 전사 확장 중이라는 답은 1/3에 그쳤다. Gartner는 GenAI 프로젝트 30% 이상이 PoC 이후 중단될 거라고 전망한다. 도입은 쉬워졌다. 운영은 아직이다.

1. 15초짜리 타임아웃 — 폐쇄망에서 원인 추적

에너지 공기업 A사. RAG 기반 AI 에이전트를 납품하고 운영 환경에 올렸더니, 첫 응답까지 매번 15초가 걸렸다. 폐쇄망이라 OpenTelemetry도 Jaeger도 LangSmith도 안 된다. 코드에 수동으로 구간별 로그를 찍어서 bind_tools() 구간에서 15초가 나오는 걸 잡았다.

측정은 맞았는데 해석이 달랐다.온프레미스, AI배포, Kubernetes, 엔터프라이즈AI, 장애패턴

제품팀 시니어는 bind_tools 자체가 느려지는 건 믿기 어렵다고 했고, 다른 엔지니어는 그래프 진입 전 단계를 의심했다. 결국 파보니 MCP Hub 연결이 실패하고 타임아웃(15000ms)이 끝날 때까지 기다리는 거였다.

[WARN] mcp-hub connection timeout after 15000ms — falling back to default tool registry

클라우드였으면 APM 대시보드에서 바로 잡혔을 것이다. 폐쇄망에서는 현장 엔지니어가 로그를 심고 제품팀과 채널에서 핑퐁하면서 좁혀야 했다. 해결 방향은 Helm values에서 timeoutSeconds, backoffSeconds, initOnStart 튜닝.

2. 보안 패치 한 번에 클러스터가 내려감

공공기관 B. MicroK8S 5노드 클러스터, Control Plane 3대 HA. 보안 점검 결과대로 설정 적용 후 리부트했더니 API 서버가 무응답.

원인은 dqlite(MicroK8S 내장 분산 합의 DB)의 리더 선출 문제. 리부트 직후 시간 동기화가 틀어졌거나, 보안 설정이 NTP 경로를 막아버렸을 가능성이 높았다. 보안 강화하려고 건드린 건데 인프라가 멈추는 상황.

원격 지원으로는 한계가 와서 엔지니어가 현장에 직접 갔다. 장애 노드 강제 탈퇴 → dqlite backend 데이터 삭제 → 노드 재합류 → 리더 선출 정상화 → chrony Slew 방식으로 시간 동기화 재설정.

관리형 K8s라면 컨트롤 플레인 부담이 벤더 쪽으로 넘어가지만, 온프레미스에서는 이 부담이 고스란히 구축 팀에 남는다.

3. PII 마스킹 — "기능 켜세요"로 안 끝나는 이유

같은 공공기관 B. AI 에이전트가 Tool 호출 시 주민번호, 여권번호 등이 input/output에 노출될 수 있는 경로가 확인됐다. 엔지니어링 팀이 3계층으로 갔다:

• Ingress: 정규식으로 패턴이 분명한 PII 일괄 치환

• Tool 경계: 마스킹 안 거친 요청은 Tool 실행 자체를 거부

• 추론 레이어: 고위험 요청에 한해 LLM 가드레일 추가

세 번째가 골치 아프다. LLM 가드레일을 모든 요청에 걸면 요청당 +1~2초(단일 GPU, 8B 모델 기준). 정규식만 쓰면 <10ms인데 패턴 없는 민감정보를 못 잡는다. 하이브리드를 택했는데, GPU가 고정인 온프레미스에서는 이 선택을 되돌리기가 쉽지 않다.

기술 분석 전문, PII 3계층 아키텍처 다이어그램, 구축 전 점검 체크리스트 6대 영역, 보안-성능 트레이드오프 비교표는 원문에서.

https://www.allganize.ai/ko/blog-posts-ko/enterprise-ai-real-problems-field-report