PoC에서는 보이지 않는 온프레미스 AI 운영의 진짜 문제들. 15초 응답 지연, K8s 클러스터 장애, PII 마스킹 아키텍처까지 — 현장 엔지니어링 팀이 해결한 방법을 공유합니다. 엔터프라이즈 AI 도입 전 반드시 확인할 6가지 검증 영역.
— PoC에서는 보이지 않는 것들, 그리고 현장에서 해결한 방법
국내 대규모 공기업 A에 RAG 기반 AI 에이전트를 납품했다. 사내 문서를 검색하고 질문에 답하는 대화형 앱인데, PoC까지는 문제가 없었다.
운영 환경에 올린 뒤부터 이상했다. 앱을 열 때마다 "준비중" 화면이 길게 떴다. 측정해보니 첫 응답까지 매번 15초쯤 걸렸다.
15초. NN/g(Nielsen Norman Group)의 응답시간 연구 기준으로, 10초를 넘기면 사용자가 주의를 유지하기 어려워진다(Jakob Nielsen, "Response Times: The 3 Important Limits"). 그 한계의 1.5배다. 이건 UX 불편 수준이 아니고, 현업 담당자가 "이 앱 안 쓸래요"라고 말할 수 있는 수준이다.
원인을 찾아야 하는데, 이 고객사는 폐쇄망이었다. 클라우드 기반 모니터링 도구를 쓸 수 없는 환경이었고, 분산 추적 인프라도 제한적이었다.
코드에 수동으로 구간별 로그를 찍고 어디서 시간을 잡아먹는지 직접 보는 수밖에 없었다. 결과: bind_tools(), LLM에 도구를 연결하는 구간. 여기서 15초가 나왔다.
이걸 사내 제품팀 채널에 올렸더니, 분위기가 좀 묘했다.
"저 코드에서 느려진다고 믿어지지 않는데... 왜 그렇게 생각하셨어요?"
시니어 엔지니어는 회의적이었다. 다른 엔지니어는 "나도 느림을 느꼈는데, bind_tools가 아니라 그래프 진입 전 단계"라고 봤다.
그때 세 번째 엔지니어가 끼어들었다.
"에이전트 앱을 만들거나 들어갈 때 병목 없나요? 의심되는 게 있어서요."
파보니까 bind_tools 자체가 문제가 아니었다. 에이전트 도구를 관리하는 중앙 허브 컴포넌트와의 연결이 실패하고 있었다. 연결이 안 되니까 타임아웃이 끝날 때까지 15초를 그냥 기다린 거다.
[WARN] internal-hub connection timeout after 15000ms — falling back to default tool registry
제품팀 시니어가 한 마디로 정리해줬다.
"항상 동일한 지연 시간이 발생한다면, 어딘가와의 연결이 있고 그게 타임아웃된 뒤에야 동작하는 것일 수 있어요."
클라우드였으면 모니터링 대시보드에서 바로 잡혔을 것이다. 폐쇄망이라 그걸 못 했고, 현장 엔지니어가 로그를 수동으로 심고 제품팀과 채널에서 핑퐁하면서 좁혀야 했다.
해결 방향은 Helm values에서 timeoutSeconds, backoffSeconds, initOnStart를 손보는 것. 지금 적용 검증 중이다.
재밌는 건, bind_tools에서 15초가 걸린다는 관측 자체는 틀리지 않았다는 점이다. 측정은 맞았는데 해석이 달랐다. 그 15초는 bind_tools의 성능 문제가 아니라, MCP Hub 연결 실패의 부산물이었다.
이걸 알아내려고 현장-제품-인프라 세 팀이 채널에서 한참을 들여다봤다.
McKinsey 연례 조사(The state of AI in 2025, 2025년 6~7월 실시)에 따르면 응답 조직의 88%가 AI를 최소 1개 기능에 도입했다고 답했다. 전년 78%에서 10%p 올랐다.
그런데 조직 전반으로 확장 중이라는 답은 3분의 1에 그쳤다. Gartner는 2025년 말까지 생성형 AI 프로젝트의 30% 이상이 PoC 이후 중단될 것으로 전망했다(Gartner Data & Analytics Summit, 2024). 도입 자체는 쉬워졌다. 운영은 아직이다.
아래는 온프레미스 AI를 구축하면서 엔지니어링 팀이 현장에서 부딪힌 것들이다.
(이하 사례들은 실제 운영 환경에서 반복되는 패턴을 기반으로 구성했고, 고객사명과 담당자명은 익명이다. 기술적 원인 분석은 당사 엔지니어링 팀의 내부 장애 보고서에 근거하며, 수치와 환경 조건은 해당 고객사에 한정된 관측치다.)
공공기관 B. 소규모 Kubernetes 클러스터를 HA 구성으로 운영하고 있었다.
어느 날 오후에 보안 점검 결과대로 설정을 적용하고 리부트했다. 관리형 Kubernetes라면 컨트롤 플레인 운영 부담이 벤더 쪽으로 넘어가지만, 온프레미스에서는 그 부담이 고스란히 구축 팀한테 남는다.
리부트하고 나니 API 서버가 응답을 안 했다.
포스트모템을 뜯어보니, dqlite라는 MicroK8S 내장 분산 합의 데이터베이스의 리더 선출 과정에서 문제가 생겼다.
리부트 직후 시간 동기화가 틀어졌거나, 방금 적용한 보안 설정이 NTP 경로를 막아버렸을 가능성이 높았다. 보안을 강화하려고 건드린 건데, 그 때문에 인프라가 멈춰버린 거다. 엔지니어 입장에서는 좀 허탈한 상황이었을 것이다.
오후 3시 35분, 현장 선임 엔지니어가 장애를 보고했다. 원격 지원팀이 보안 설정을 하나씩 풀어보면서 좁혀갔는데, 원격으로는 한계가 왔다. 결국 엔지니어 한 명이 현장으로 직접 갔다.
복구는 이런 순서였다:
이후 트러블슈팅 리포트를 쓰고 Helm chart 개선안을 뽑았다. 이 보안 설정 문서는 나중에 다른 고객사에도 기본으로 적용됐다.
이건 좀 짧게 쓴다. 패턴이 깔끔하게 떨어지는 사례라서.
금융 계열사 A그룹, 산하 복수 계열사가 각자의 폐쇄망에서 같은 AI 시스템을 쓰고 있었다. 배포는 중앙에서 한꺼번에 밀어넣는 구조. 전 망에 동일 이미지를 배포했는데, 일부 망에서 문서 파싱 엔진이 안 떴다.
처음엔 GPU 쪽을 봤다. NVIDIA 드라이버, CUDA, 컨테이너 런타임. 온프레미스 GPU 환경에서 흔한 문제들이라 자연스러운 의심이었다.
그런데 원인은 엉뚱하게도 프론트엔드 업데이트 후 API 호출 경로의 버전 불일치였다. 같은 이미지를 넣었지만 각 망의 기존 프론트엔드 버전이 달랐기 때문에 일부에서만 터졌다. Configuration Drift, 망별로 환경 설정이 조금씩 벌어져 있던 게 원인이었다.
전날 밤부터 엔지니어가 원격 디버깅을 시작했다. 정상인 1개 망과 장애 난 2개 망의 설정을 대조하고, staging 환경에서 curl 테스트를 돌리면서 범위를 좁혔다. 롤백, 재배포, 순차 정상화.
카나리 배포나 블루-그린 배포가 답이긴 한데, 폐쇄망에서는 쉽지 않다. 망 분리가 빡빡하고 검증 환경을 따로 만들 여유도 부족하다. 그리고 이건 새벽이었다.
여기까지가 인프라와 배포다.
문제 1에서 클러스터가 멈췄던 공공기관 B. 이번에는 보안 쪽에서 두 건이 동시에 터졌다.
먼저 네트워크. 웹 취약점 진단에서 복수 망이 도메인 하나를 공유하는 구조가 걸렸다. 인증 체계는 그대로 두고 도메인만 쪼개는 방향으로 고객사랑 협의해서 넘겼다. 이건 비교적 깔끔하게 해결됐다.
문제는 그 다음이었다. AI 에이전트가 Tool을 호출할 때 개인정보가 input/output을 통해 의도치 않게 전달될 수 있는 잠재 경로를 사전 점검에서 식별했다.
금융보안원의 「금융분야 AI 보안 가이드라인」(2023)이나 개인정보보호법 제29조를 생각하면, "마스킹 기능 켜세요"로 끝날 문제가 아니다.
엔지니어링 팀이 세 겹으로 설계했다:
그림 1. PII 마스킹 3-Layer 아키텍처 — Ingress, Tool 경계, 추론 레이어에서 각각 다른 방식으로 개인정보를 처리한다.
세 번째가 핵심이다. LLM 가드레일을 모든 요청에 걸면 안전하긴 한데, 매번 LLM을 한 번 더 돌려야 하니까 응답이 느려진다.
얼마나 느려지냐면 — 이 환경에서 측정했을 때, 일반 요청은 10ms 미만으로 통과하는 반면 LLM 가드레일이 붙으면 요청당 1~2초가 추가됐다. GPU 하나에 8B 모델을 돌리는 환경이니까, 요청이 몰리면 병목이 확 커진다.
그래서 이 고객사는 정규식으로 1차 필터를 세게 걸고, LLM 검사는 고위험 요청에만 한정하는 쪽을 택했다.
다만 이렇게 하면 자유서술형 개인정보나 패턴이 없는 민감정보는 정규식이 못 잡는다. 그래서 정기 샘플링 점검을 같이 돌리고 있는데, 솔직히 이 부분은 아직 완벽하다고 보기 어렵다. 폐쇄망에서 LLM 가드레일의 커버리지를 어디까지 넓힐 수 있느냐는 GPU 리소스와 직결되기 때문이다.
이 결정은 보안팀, 제품팀, 인프라팀이 같이 내렸다. 어느 한 팀이 혼자 정할 수 있는 게 아니다. 클라우드라면 GPU를 늘리면 되지만, 온프레미스에서는 그 GPU가 고정이고 증설 비용이 크다. 선택한 뒤에 되돌리기가 쉽지 않다.
세 가지 사례를 쓰면서 공통적으로 떠오르는 게 있었다.
인프라 쪽에서는 — 노드를 리부트했을 때 자동으로 돌아오는지, 분산 합의가 깨졌을 때 복구 절차가 문서로 있기는 한 건지, 보안 패치를 적용하기 전에 인프라 영향을 미리 볼 수 있는 환경이 있는지.
공공기관 B 사례를 겪고 나서 우리 팀은 리부트·롤백·노드 재합류 시나리오를 정기적으로 돌려보기 시작했다. 그전에는 안 했다.
배포 쪽에서는 — 이미지 하나를 바꿨을 때 전체에 영향이 가지 않는 구조인지, 망별로 설정이 벌어지는 걸 정기적으로 잡고 있는지.
A그룹 사례에서 본 것처럼, 같은 이미지를 넣었는데 결과가 다르면 문제는 이미지가 아니라 환경 편차다. 새벽에 터졌을 때 감지-대응이 돌아가는지도 한 번 터져봐야 신경 쓰게 되는 부분이다.
보안 쪽에서는 — PII 마스킹이 정확히 어느 레이어에서 동작하는지, 마스킹이 실패했을 때 시스템이 어떻게 반응하는지, 보안을 강화했을 때 성능이 얼마나 떨어지는지 수치로 알고 있는지.
그리고 에이전트가 뜰 때 외부 서비스 연결이 실패하면 전체가 멈추는지, 타임아웃을 명시적으로 관리하고 있는지. 15초 사례가 정확히 이거였다.
한 고객사에서 터진 걸 다른 고객사에도 반영하는 구조가 있는지, 장애 감지 시간(MTTD)과 복구 시간(MTTR)을 실제로 재고 있는지, 폐쇄망에서도 분산 추적이 가능한지.
그림 2. 온프레미스 AI 구축 사전 검증 6대 영역 — 인프라, 배포, 보안, 모니터링, 복구, 확산 관리.
결국 기능이 있냐 없냐의 문제가 아니다. 앞에서 봤듯이, 터졌을 때 감지가 되는지, 복구가 되는지. 그 차이가 크다.
이건 피할 수 없다. 모든 요청에 LLM 검사를 붙이면 안전해지지만, 요청마다 추론 비용과 지연이 붙는다. 검사를 줄이면 빨라지는 대신 구멍이 생긴다.
방식보안 수준성능 영향구현 복잡도LLM 가드레일 (모든 요청 검사)높음요청당 +1~2초중간정규식 패턴 매칭중간 (패턴 없는 건 못 잡음)< 10ms낮음하이브리드 (정규식 + 고위험만 가드레일)중상일반 < 10ms · 고위험 +1~2초높음
※ 단일 GPU 노드, 8B급 모델, 평균 500토큰 요청 기준의 관측치. 모델 크기, 토큰량, 하드웨어, 동시 요청 수에 따라 달라진다.
그림 3. PII 마스킹 방식별 보안 × 성능 비교 — 보안 강도를 높이면 응답 지연이 증가하는 트레이드오프.
공공기관 B는 세 번째를 골랐다. 앞서 말한 대로 정규식으로 1차에 걸러내고, LLM 가드레일은 고위험 요청에만 거는 방식이다. 클라우드에서도 이 트레이드오프는 똑같이 존재하지만, 온프레미스는 GPU를 추가로 꽂기가 쉽지 않으니까 한 번의 선택이 오래 간다.
AI를 도입하려는 기업이라면, 벤더에게든 내부 팀에게든 한 가지만 물어봐도 좋다.
"PoC 환경과 운영 환경이 어떻게 다릅니까?"
여기에 구체적으로 답이 나온다면, 클러스터가 멈췄을 때 어떻게 복구하는지, 컴포넌트 업데이트가 다른 컴포넌트를 깨뜨리는지 사전에 아는지, PII 마스킹이 실패했을 때 시스템이 어떻게 반응하는지도 이야기가 된다.
우리는 이 질문들에 답할 수 있는 쪽에 있고 싶어서 이 글을 쓰고 있다.
온프레미스 AI 구축, 어디서부터 시작해야 할지 고민이신가요?
Allganize는 금융·공공·제조 등 다양한 산업에서 폐쇄망 AI 플랫폼을 구축하고 운영한 경험을 보유하고 있습니다. PoC부터 운영까지, 이 글에서 다룬 문제들을 함께 해결합니다.
→ 도입 상담 요청하기
다음 편에서는 PII 마스킹 트레이드오프를 더 깊이 들어간다. 아키텍처, 레이어, 비용. GPU 리소스와 보안이 부딪힐 때 어떻게 풀었는지, 보안 점검이 왜 한 번으로 안 끝나는지.
이 글의 사례들은 온프레미스 AI 구축 엔지니어링 팀의 운영 경험에서 추출했습니다. 고객사명과 담당자명은 모두 익명입니다.
출처
