운영에 들어간 AI 시스템은 왜 아무도 모르게 멈추나

PoC 이후 운영 전환 단계에서 점검해야 할 인프라 전제, 관측 체계, 운영 지식

운영 전환 직후의 AI 시스템은 대시보드에 에러가 없어도 멈춰 있을 수 있다. 모니터링이 없으면 장애는 사용자가 신고하기 전까지 존재하지 않는 것처럼 보인다. 이 글은 PoC를 마치고 운영으로 넘어갈 때 점검해야 하는 세 가지 조건과 확인 방법을 정리한다.

PoC가 끝나면 무엇이 달라지나

PoC가 끝나면 시스템을 만든 소수의 엔지니어 중심에서 실제 사용자와 운영 조직 중심으로 무게가 옮겨 간다. 운영 전환 초기의 장애는 모델 성능보다 환경 차이, 관측 부재, 문서화 부재에서 시작되는 경우가 많다.

Gartner는 2027년까지 에이전트 기반 AI 프로젝트의 40% 이상이 비용 상승, 불분명한 비즈니스 가치, 부적절한 리스크 통제 등으로 취소될 것으로 예측한다[1]. 비용과 리스크 통제는 운영 단계에서 드러나는 항목이다. 구축을 마쳤다는 사실만으로는 운영 준비가 끝났다고 말할 수 없다.

운영 전환에서 반복해서 점검해야 하는 영역은 셋이다.

1. PoC 환경과 운영 환경의 설정 차이
2. 이상 징후를 자동으로 알려 주는 관측 체계
3. 특정 사람에게만 있는 운영 지식

PoC 환경과 운영 환경은 무엇이 다른가

두 환경은 같아 보여도 시간 동기, 방화벽, 포트, 인증 설정, 스토리지 구조 같은 기반 설정에서 달라진다. 이 차이는 평소에는 드러나지 않다가 서버 재시작, 배포, 인증서 갱신처럼 평범한 작업을 계기로 한꺼번에 나타난다.

모든 노드의 시간 동기 상태와 시간 서버 설정을 확인한다. NTP v4는 IETF RFC 5905에 표준으로 정의되어 있다[2].

운영 전환 전에 두 환경의 설정 차이를 문서로 만든다.

이렇게 확인한다.

• 모든 노드의 시간 동기 상태와 시간 서버 설정이 같은지 본다.
• 방화벽 규칙과 열려 있는 포트 목록을 두 환경에서 뽑아 나란히 비교한다.
• 인증, SSO, 인증서 설정이 스테이징과 운영에서 같은지 본다.
• 스토리지 구조와 네트워크 구성이 달라지는 지점을 적는다.
• 서버 재시작 뒤 서비스가 스스로 올라오는지 점검 시간을 정해 직접 시험한다.

점검 항목	확인 질문	확인 방법
시간 동기	모든 노드가 같은 시간 소스를 쓰는가?	노드별 시간 상태를 조회해 편차를 대조
네트워크	두 환경의 방화벽 규칙과 포트가 같은가?	규칙 목록을 내보내 diff 작성
인증	스테이징과 운영의 인증 설정이 같은가?	설정 항목을 나란히 비교
재시작	재시작 뒤 서비스가 자동으로 복귀하는가?	점검 시간에 재시작 시험

장애가 났다는 것은 누가 가장 먼저 아나

장애를 가장 먼저 아는 쪽이 모니터링 시스템이어야 한다. 사용자가 먼저 알게 되면 이미 늦다. AI 시스템의 이상 징후는 에러 로그로 나타나지 않는 경우가 많다. 응답이 느려지고, 검색 결과가 달라지고, 어떤 기능이 조용히 멈추는 식이다.

배포 상태가 비정상 상태로 일정 시간 지속되면 담당자에게 알림이 전달되는지 확인한다.

GPU도 같다. 응답이 느려졌다는 신고를 받았을 때 GPU 사용률, 메모리, 전력, 온도 지표가 없으면 원인을 추측할 수밖에 없다. 전력 문제인지, 추론 큐 병목인지, VRAM 압박인지 가려낼 근거가 없기 때문이다.

CNCF Observability Whitepaper는 관측성을 시스템의 외부 출력만으로 내부 상태를 추론할 수 있는 능력으로 정의하고, 로그·메트릭·트레이스를 세 가지 신호로 제시한다[3]. AI 시스템에서는 여기에 GPU와 추론 지연시간, 검색 정밀도 같은 도메인 지표를 더해야 한다. RAG와 에이전트 층위의 에러 없는 장애는 에러 없는 장애를 찾는 사일런트 체크리스트에 따로 정리했고, 검색 품질을 어떤 기준으로 비교하는지는 엔터프라이즈 RAG 비교 기준에서 다룬다.

이렇게 확인한다.

• 알람이 없으면 이상이 없다고 가정하고 있지 않은지 본다.
• 임계값을 넘을 때 슬랙이나 호출 도구 같은 알림 채널로 알림이 가는지 시험한다.
• 배포가 완료되지 않은 상태로 일정 시간 이상 머물면 알람이 오는지 본다.
• 알람이 울렸을 때 누가 받고 누가 확인하는지 정해 두었는지 본다.

관측 대상	보는 지표	알람 조건 예시
GPU	사용률, 메모리, 전력, 온도	임계값 초과 시 알림
추론 서버	토큰 처리량, 대기열 길이, 응답 지연	지연이 기준선을 넘으면 알림
배포	동기화·건강도 상태	비정상 상태가 일정 시간 지속되면 알림
검색 품질	평가 질문 세트 결과	기준 점수 아래로 내려가면 알림

배포 뒤 장애에 대비한 복구 절차는 어떻게 검증하나

복구 절차는 배포 단위의 호환성과 서비스 영향을 검토해 사전에 검증한다.

이렇게 확인한다.

• 배포 단위의 호환성과 복구 시 서비스 영향을 확인한다.
• 롤백 순서와 판단 기준이 문서에 있는지 본다.
• 스테이징과 운영의 인증·네트워크 설정이 같은지 본다.
• 롤백 뒤 원인 확정 전에는 다음 배포를 올리지 않는 기준이 있는지 본다.

PoC 기간에는 일단 된다는 사실이 기준이었다. 운영 전환 뒤에는 왜 안 되는지 설명할 수 있는지가 기준이 된다.

PoC에 없던 요구사항은 왜 운영 뒤에 나오나

운영 전환 계획에 변경 요청의 접수·승인·범위 관리 절차를 포함한다.

이렇게 확인한다.

• 운영 전환 뒤 변경 요청을 받을 창구와 우선순위 기준이 있는지 본다.
• 운영 전환 계획서에 안정화 기간과 그 기간의 예비 범위가 들어 있는지 본다.
• 보안·감사 담당자가 PoC 단계에서 한 번이라도 검토에 참여했는지 본다.

한 사람만 아는 절차는 어떻게 찾아내나

각 운영 절차에 대해 이 절차를 나 말고 누가 실행할 수 있는지 물어보면 찾아낼 수 있다. PoC는 소수의 엔지니어가 집중해서 구축하기 때문에 핵심 절차가 담당자 한 사람의 머릿속에만 있는 경우가 많다. 이 위험은 퇴사, 휴가, 인프라 이전처럼 환경이 바뀌는 사건이 오기 전에는 드러나지 않는다.

백업과 복구 절차는 특히 먼저 봐야 한다. 백업을 받는 방법은 알아도 롤백을 해 본 사람은 없는 경우가 있다. 인프라 이전 일정에 여유가 있을 때 먼저 정리하면 검증할 시간을 확보할 수 있다. 일정이 임박한 뒤에 시작하면 검증 없이 넘어가게 된다.

이렇게 확인한다.

1. 핵심 운영 절차를 목록으로 만든다.
2. 절차마다 실행해 본 사람을 두 명 이상 적는다.
3. 한 명뿐인 절차는 백업 실행, 검증, 롤백 시험의 세 단계로 runbook을 쓴다.
4. 이전 환경의 모니터링 임계값과 알림 규칙, 스토리지 구조가 바뀌는지 따로 검토한다.

운영을 넘겨받은 조직은 무엇을 직접 관리하나

공개된 운영 사례를 보면 운영 전환 뒤에는 시스템 기반을 관리하는 부서와 답변 콘텐츠를 관리하는 현업 부서가 나뉜다. 콘텐츠 수정을 개발자 없이 할 수 있는지가 운영 인력 규모를 좌우한다.

사례	운영 구조	공개된 운영 지표
전원개발(J-POWER, 일본, 에너지)	디지털 부서가 온프레미스 시스템 기반을 관리하고, 각 부서가 채팅 흐름과 FAQ 같은 콘텐츠를 직접 운영. FAQ는 엑셀로 일괄 등록[4]	연말정산 문의 전화·메일을 예년의 약 1/5로 줄임[4]
노무라증권(일본, 증권)	노코드로 답변 수정과 추가[5]	챗봇 운영 인원 3명 → 1명. FAQ 질의응답 등록 1시간 이내[5]
엔라이즈(국내, 앱 서비스)	반복 문의를 FAQ로 등록해 앱 안에서 자동 응대. 2019년 10월부터 사용[6]	사용자 문의 70% 자동 해결[6]

운영 전환 문서에는 시스템 기반을 맡는 담당과 콘텐츠를 맡는 담당을 따로 적는다. 앞 절의 한 사람만 아는 절차도 두 영역으로 나눠 찾으면 빠진 부분이 잘 보인다.

운영 전환 전에 물어봐야 할 3가지

CTO나 AI 도입 담당자는 PoC 완료에서 운영 전환으로 넘어가는 시점에 아래 세 가지를 물어본다. 답이 나오지 않으면 전환을 미루는 것이 안전하다.

1. 환경 설정 diff 문서가 있는가? PoC 환경과 운영 환경의 차이를 나열한 문서를 지금 보여 줄 수 있어야 한다. 시간 동기, 방화벽 규칙, 열린 포트가 들어 있지 않으면 재시작이나 배포 같은 평범한 작업이 장애가 된다. 없다면 두 환경을 나란히 놓고 diff를 만드는 작업을 전환의 선행 조건으로 건다.
2. GPU, 추론 지연, 배포 상태가 알람과 연결되어 있는가? 지표를 수집하고 임계값 알람이 알림 채널까지 이어져야 모니터링이 있다고 할 수 있다. 연결되어 있지 않다면 전환 전에 구성한다. 이것은 운영 환경 구성에 들어가는 기본 항목이다.
3. 모든 핵심 운영 절차에 두 번째 실행자가 있는가? 백업 롤백, 클러스터 재합류, 긴급 배포를 혼자서만 할 수 있는 사람이 있는지 물어본다. 있다면 그 절차의 runbook 작성과 교차 훈련을 전환의 선행 조건으로 건다.

운영 파트너를 정할 때도 같은 기준이 쓰인다. 구축한 팀이 운영까지 맡는 구조라면 대응 방법이 그대로 이어진다. 운영 조직이 따로 있다면 대응 이력, runbook, 장애 대응 패턴을 문서와 훈련 형태로 넘기는 것이 출발점이다.

6편을 마치며

구축이 끝난 날이 운영의 시작이다. 운영은 구축보다 조용하고 오래 이어진다. 그래서 눈에 띄는 사건이 없어도 지켜보는 체계가 있어야 한다.

Gartner가 예측한 에이전트 프로젝트 취소[1]의 이유에는 비용과 리스크 통제 문제가 들어 있다. 환경 차이를 문서로 남기고, 지표를 알람에 연결하고, 절차를 두 사람 이상이 실행할 수 있게 만드는 일은 모두 운영 전환 전에 할 수 있다. 지금 운영 중인 AI 시스템을 누가 지켜보고 있는지 먼저 확인해 보기 바란다.

다음 글에서는 문서 형식, DRM 접근권, 파싱 품질을 도입 전에 점검하는 방법을 다룬다.

올거나이즈는 금융, 제조, 공공, IT서비스 등 다양한 산업에서 온프레미스 AI의 도입 검토부터 운영 전환까지 지원해 왔다. 인프라 전제, 관측 체계, 운영 지식을 미리 점검하는 아키텍처 리뷰와 운영 전환 로드맵을 함께 진행한다. → 도입·운영 상담 요청하기

출처

1. Gartner, "Gartner Predicts Over 40% of Agentic AI Projects Will Be Canceled by End of 2027," 공식 보도자료, 2025-06-25. 비용 상승, 불분명한 비즈니스 가치, 부적절한 리스크 통제를 주요 취소 원인으로 제시 (1차 출처: Gartner Newsroom)
2. IETF RFC 5905, "Network Time Protocol Version 4: Protocol and Algorithms Specification," 2010. NTP v4 표준 규격 (1차 출처: IETF)
3. CNCF TAG-Observability, "Cloud Native Observability Whitepaper," 2023. 관측성 정의와 로그·메트릭·트레이스 3대 신호 (1차 출처: CNCF GitHub tag-observability/whitepaper)
4. 올거나이즈 재팬, 전원개발(J-POWER) 도입 사례. 사례 페이지
5. 올거나이즈, 노무라증권 고객 사례(2025년 4월 9일). 사례 페이지
6. 올거나이즈, 엔라이즈 고객 사례. 사례 페이지