엔터프라이즈 AI 구축, PoC 이후 운영 전에 점검할 것

PoC에서는 보이지 않는 것들, 그리고 운영 전에 점검할 것

PoC 환경에서 빠르던 앱이 운영 환경에서는 느려지고, 보안 설정을 바꾸면 인프라가 흔들리고, 같은 이미지를 배포해도 망마다 결과가 달라진다. 이런 문제는 기능 시연으로는 드러나지 않는다.

McKinsey 연례 조사(The state of AI in 2025)에 따르면 응답 조직의 88%가 AI를 최소 1개 기능에 도입했다고 답했다. 전년 78%에서 10%p 올랐다. 그런데 조직 전반으로 확장 중이라는 답은 3분의 1에 그쳤다[1]. Gartner는 2025년 말까지 생성형 AI 프로젝트의 30% 이상이 PoC 이후 중단될 것으로 전망했다[2]. 도입 자체는 쉬워졌고, 운영이 남은 과제다. 이 글은 온프레미스·폐쇄망 환경에 AI를 올릴 때 PoC 이후에 점검해야 하는 네 가지 영역(응답 지연, 인프라, 배포, 개인정보 보호)과 확인 방법을 정리한다.

응답 지연은 어떻게 확인하나

응답 지연은 구간별 소요 시간과 연결 상태를 측정해 확인한다.

사용자가 체감하는 한계도 기준으로 삼아야 한다. Nielsen Norman Group의 응답시간 연구는 응답이 10초를 넘기면 사용자가 주의를 유지하기 어려워진다고 설명한다[3]. 앱을 열 때마다 10초 넘게 기다리게 한다면 기능이 정확해도 현업에서는 쓰지 않게 된다.

지연 문제는 다음 순서로 확인한다.

1. 부하에 따른 구간별 지연 시간을 측정한다.
2. 외부 컴포넌트의 연결 상태와 타임아웃 설정을 확인한다.
3. 외부 연결 실패 시 시스템의 동작을 시험한다.
4. 폐쇄망에서도 구간별 소요 시간을 남기는 로그나 추적 수단을 미리 준비한다.

보안 설정을 바꾼 뒤에는 인프라에서 무엇을 확인해야 하나

보안 점검 결과를 반영한 뒤에는 노드를 재시작했을 때 클러스터가 스스로 정상 상태로 돌아오는지를 가장 먼저 확인한다. 보안 설정은 네트워크 경로, 포트, 시간 동기화처럼 인프라가 서로를 찾는 데 쓰는 조건을 건드리는 경우가 있고, 영향은 재시작 후에야 나타난다.

관리형 쿠버네티스는 컨트롤 플레인 운영을 서비스 제공자가 맡지만, 온프레미스에서는 이 부담이 구축 팀에 그대로 남는다. 고가용성(HA) 구성이어도 합의 기반 저장소는 노드 간 통신과 시간이 맞아야 정상 동작하므로, 설정 변경 하나가 전체 가용성에 영향을 줄 수 있다. 원격 지원만으로 풀리지 않을 때를 대비해 현장 접근 절차도 정해 두어야 한다.

설정을 적용하기 전과 후에 점검할 항목은 다음과 같다.

• 노드를 재시작했을 때 자동으로 클러스터에 다시 합류하는지 확인한다. 복귀 여부는 운영 환경과 같은 구성의 검증 환경에서도 시험해 본다.
• 분산 합의가 깨졌을 때의 복구 절차가 문서로 있고 실제로 시험해 봤는지 확인한다. 복구 문서와 시험 결과를 함께 보아 운영 담당자가 수행할 수 있는 상태인지 점검한다.
• 보안 설정을 운영 환경에 적용하기 전에 같은 구성의 검증 환경에서 먼저 돌려 볼 수 있는지
• 재시작, 롤백, 노드 재합류 시나리오를 정기적으로 연습하는지
• 변경 시각과 담당자, 원격 지원이 막혔을 때의 현장 대응 경로가 정해져 있는지

같은 이미지를 배포했는데 망마다 결과가 다르면 무엇이 원인인가

망별 구성요소의 버전과 설정을 나란히 놓고 비교한다.

카나리 배포나 블루-그린 배포는 이 위험을 줄이는 표준적인 방법이다. 다만 폐쇄망에서는 망 분리 규칙이 엄격하고 검증 환경을 따로 두기 어려워 적용이 쉽지 않다. 그렇다면 최소한 배포 전에 망별 설정 비교표를 만들고, 한 곳에 먼저 배포한 뒤 순차적으로 확대하는 절차가 필요하다.

배포 단계에서는 다음을 확인한다.

1. 이미지 하나를 바꿨을 때 전체 망에 동시에 영향이 가지 않는 구조인지
2. 망별 구성요소 버전과 설정 차이를 정기적으로 비교하는지
3. 문제가 생겼을 때 롤백 절차가 망마다 시험되어 있는지
4. 야간이나 새벽에 장애가 나도 감지와 대응이 돌아가는지

PII 마스킹은 어느 단계에서 어떻게 걸어야 하나

개인정보 마스킹은 기능을 켜는 것으로 끝나지 않고, 어느 단계에서 동작하며 실패했을 때 어떻게 반응하는지까지 정해야 한다. 에이전트가 도구를 호출하면 입력과 출력을 통해 개인정보가 의도하지 않은 곳으로 전달될 수 있고, 이 경로는 사전 점검에서 별도로 식별해야 한다.

관련 기준도 확인할 필요가 있다. 금융보안원의 「금융분야 AI 보안 가이드라인」(2023)[4]과 개인정보 보호법 제29조(안전조치의무)[5]는 개인정보를 처리하는 시스템에 기술적·관리적 보호조치를 요구한다. 마스킹을 한 단계에만 두면 다른 단계에서 새는 경로가 남는다.

마스킹 방식은 보호 수준과 응답 속도가 서로 맞바꿔지는 관계에 있다. 모든 요청을 LLM으로 한 번 더 검사하면 보호 수준은 높아지지만 요청마다 추론 비용과 지연이 붙는다. 검사를 줄이면 빨라지는 대신 구멍이 생긴다. GPU가 고정된 온프레미스에서는 클라우드처럼 자원을 늘려 해결하기 어렵다.

방식	보호 수준	성능 영향	한계	구현 복잡도
LLM 가드레일 (모든 요청 검사)	높음	요청마다 추가 지연이 크다	GPU 자원 소모가 크다	중간
정규식 패턴 매칭	중간	거의 없다	정해진 패턴이 없는 정보는 걸러내지 못한다	낮음
혼합 (정규식 1차 + 고위험 요청만 가드레일)	중상	일반 요청은 작고, 고위험 요청에만 지연이 붙는다	고위험 판정 기준과 정기 점검이 필요하다	높음

어느 방식을 택하든 확인할 것은 같다.

• 마스킹이 입력 단계, 도구 호출 경계, 모델 추론 단계 가운데 어디에서 동작하는지
• 마스킹이 실패했을 때 요청을 막는지, 그대로 통과시키는지
• 자유 서술형 개인정보처럼 패턴이 없는 정보를 정기 샘플링으로 점검하는지
• 보안을 강화했을 때 응답 시간이 얼마나 늘어나는지 자기 환경에서 직접 재 보았는지 확인한다. 마스킹 적용 전과 후의 응답 시간을 비교하고, 고위험 요청을 검사하는 경로도 측정에 포함한다.
• 보안팀, 제품팀, 인프라팀이 함께 정한 기준이 문서로 남아 있는지 확인한다. 마스킹 실패 시 차단 여부와 성능 영향을 같은 문서에서 검토할 수 있어야 한다.

구축 전에 어떤 영역을 사전 검증해야 하나

사전 검증은 인프라, 배포, 보안, 컴포넌트 의존성, 장애 대응, 운영 가시성의 여섯 영역으로 나누어 본다. 이 점검표는 기능의 유무보다 문제가 생겼을 때 얼마나 빨리 감지하고 복구할 수 있는지를 묻는다.

영역	점검 질문
인프라 복원력	재시작 후 자동으로 복귀하는가? 합의 실패 시 복구 절차가 있는가?
배포 안전성	업데이트 하나가 전체에 영향을 주지 않는가? 설정 편차를 정기적으로 감지하는가?
보안 아키텍처	PII 마스킹이 어느 단계에서 동작하는가? 보안 강화에 따른 성능 영향을 수치로 아는가?
컴포넌트 의존성	외부 연결 실패가 전체를 멈추게 하는가? 타임아웃을 명시적으로 관리하는가?
장애 대응 체계	원격 접근이 막혔을 때 현장 대응이 가능한가? 한 곳에서 겪은 문제를 다른 환경에도 반영하는가?
운영 가시성	장애 감지 시간(MTTD)과 복구 시간(MTTR)을 실제로 재고 있는가? 폐쇄망에서도 분산 추적이 가능한가?

관련해서 RAG 도입 단계의 비교 기준은 엔터프라이즈 RAG 비교 기준에 정리했다.

국내 금융권 온프레미스 구축은 어떤 범위로 공개됐나

공개된 구축 발표를 보면 금융권 온프레미스 AI는 검색·문서 처리에 보안 기능과 운영 도구를 함께 묶는 범위로 추진된다. 앞 절의 점검 항목이 계약 범위 안에 들어 있는지 볼 때 참고할 수 있다.

사례	공개된 구축 범위	보안 관련 공개 내용
한국증권금융(금융)	2026년 6~12월 온프레미스 구축. LLM옵스, RAG, 문서·이미지 인식(OCR), 노코드 AI 비서 빌더[6]	유해·민감 정보를 차단하는 AI 가드레일. AI 기본법, 금융위원회 AI 가이드라인, 금융보안원 AI 보안 안내서 등 반영[6]
우리투자증권(증권)	외부망과 분리된 온프레미스 환경에서 LLM 구동. RAG와 비개발자용 에이전트 빌더[7]	데이터 암호화, 민감 정보 마스킹, 사용자별 접근권한 제어[7]
전원개발(J-POWER, 일본, 에너지)	온프레미스판으로 사내 문의 대응 챗봇 구축. 연말정산 문의를 예년의 약 1/5로 줄임[8]	클라우드 서비스 도입이 어려운 환경에서 온프레미스 대응을 선정 이유로 공개[8]

공개 발표에 PII 마스킹과 접근권한 제어가 구축 범위로 들어 있다면, 앞 절의 질문처럼 그 기능이 어느 단계에서 동작하고 응답 속도에 어떤 영향을 주는지도 함께 확인한다.

도입을 검토할 때 무엇을 물어봐야 하나

벤더에게든 내부 팀에게든 먼저 물어볼 질문은 "PoC 환경과 운영 환경이 어떻게 다릅니까?"이다. 이 질문에 구체적으로 답할 수 있어야 아래 질문들도 이어서 다룰 수 있다.

1. 클러스터가 멈췄을 때 어떻게 복구하는가? 복구 절차가 문서로 있고, 실제로 시험해 보았는지 확인한다.
2. 컴포넌트 하나를 업데이트하면 다른 컴포넌트가 깨지는지 미리 아는가? 호환 관계와 망별 버전 차이를 관리하는지 확인한다.
3. PII 마스킹이 실패하면 시스템은 어떻게 반응하는가? 차단인지 통과인지, 그 기준은 누가 정했는지 확인한다.
4. 외부 연결이 끊겼을 때 앱은 얼마나 기다리는가? 타임아웃 값이 명시적으로 관리되는지 확인한다.
5. 장애를 감지하고 복구하는 데 걸리는 시간을 재고 있는가? MTTD와 MTTR을 기록하는지 확인한다. 장애를 알아차리는 데 걸린 시간과 서비스를 복구하는 데 걸린 시간을 각각 살펴보고, 감지와 대응 절차를 함께 점검한다.

답하지 못한 항목은 운영 전환 전에 확인한다. 다음 글에서는 보안 점검을 체크리스트로만 끝내면 왜 부족한지, 보안 요구와 시스템 자원이 부딪힐 때 무엇을 정해야 하는지 다룬다. 이어지는 글은 AI 보안, 체크리스트만으로는 안 된다이다.

올거나이즈는 금융, 공공, 제조 등 다양한 산업에서 폐쇄망 AI 플랫폼을 구축하고 운영한 경험을 보유하고 있다. PoC부터 운영까지, 이 글에서 다룬 점검을 함께 진행한다. → 도입 상담 요청하기

출처

1. McKinsey, "The state of AI in 2025," 2025. 응답 조직의 88%가 최소 1개 기능에 AI 도입(전년 78%), 조직 전반 확장은 3분의 1
2. Gartner, "30% of GenAI Projects Will Be Abandoned After PoC By End of 2025," Gartner Data & Analytics Summit, 2024
3. Jakob Nielsen, "Response Times: The 3 Important Limits," Nielsen Norman Group
4. 금융보안원, 「금융분야 AI 보안 가이드라인」, 2023
5. 개인정보 보호법 제29조(안전조치의무)
6. 이데일리, "올거나이즈, 한국증권금융 생성형 AI 플랫폼 구축", 2026년 7월 15일. 기사
7. 디일렉, "올거나이즈코리아, 우리투자증권 AX 플랫폼 구축", 2026년 1월 12일. 기사
8. 올거나이즈 재팬, 전원개발(J-POWER) 도입 사례. 사례 페이지