도입 후 꼭 확인해야 할 5가지 운영 체크리스트

“AI 에이전트를 하나 만들어봤는데, 이제 실제 업무에 써도 될까요?”

데모에서는 생각보다 잘 작동합니다. 사내 문서를 찾아 요약하고, 이메일 초안을 작성하고, 필요한 데이터를 분석해 다음 업무까지 제안합니다. 여기까지만 보면 이제 사람 대신 알아서 일하도록 맡겨도 될 것 같습니다.

하지만 실제 기업 환경에서는 이야기가 조금 달라집니다.

사용자가 늘어나고 연결되는 데이터와 시스템이 많아질수록 예상하지 못했던 문제가 하나둘 나타납니다. 어제까지 잘하던 답변의 품질이 갑자기 떨어지기도 하고, 생각보다 많은 토큰을 사용해 비용이 늘어나기도 합니다. 업무 자동화를 위해 여러 시스템에 접근 권한을 열어줬더니 이번에는 보안과 관리 문제가 생깁니다.

특히 실제 업무 환경에서는 AI 모델 하나만 잘 선택한다고 문제가 해결되지 않습니다. AI가 참고할 데이터는 제대로 관리되고 있는지, 답변 품질은 어떤 기준으로 검증할 것인지, 문제가 발생했을 때 원인을 찾을 수 있는지, 사용자들이 실제 업무에서 AI를 제대로 활용하고 있는지까지 함께 살펴봐야 합니다.

결국 AI 에이전트의 진짜 시작은 만드는 순간이 아니라 운영 환경에 들어간 순간부터입니다.

그렇다면 기업이 AI 에이전트를 실제 업무에서 안정적으로 운영하기 위해서는 무엇을 확인해야 할까요?

1. 처음과 같은 답변 품질을 계속 유지하고 있나요?

AI 서비스는 일반적인 소프트웨어와 조금 다릅니다.

정해진 입력에 항상 같은 결과를 반환하는 것이 아니라, 질문과 맥락, 사용되는 데이터, 모델에 따라 답변이 달라질 수 있습니다.

예를 들어 사내 규정 검색 에이전트가 있다고 가정해보겠습니다.

처음 테스트했을 때는 정확하게 답했던 질문도 새로운 규정 문서가 추가되거나 기존 문서가 업데이트되면서 결과가 달라질 수 있습니다. 사용자가 예상하지 못한 방식으로 질문했을 때 엉뚱한 문서를 참고할 수도 있습니다.

따라서 출시 전에 정확도를 한 번 확인하는 것만으로는 충분하지 않습니다.

• 답변 정확도가 일정 수준 이상 유지되고 있나요?
• 답변이 실제 사내 문서를 근거로 작성됐나요?
• 이전보다 할루시네이션이 늘어나지는 않았나요?
• 새로운 문서가 추가된 이후 품질이 달라지지는 않았나요?
• 모델이나 프롬프트를 변경해도 기존 수준의 품질을 유지하나요?

특히 중요한 것은 ‘잘 답했는가’를 사람의 느낌으로만 판단하지 않는 것입니다.

실제 한 금융권 AI 업무지원 프로젝트에서는 다양한 현업 사용자가 직접 테스트에 참여했습니다. 사전에 약 200개의 질문과 모범 답변으로 ‘골든셋’을 만든 뒤 실제 AI 답변과 비교하고, 기능 테스트뿐 아니라 대화 시나리오와 자유 질의까지 함께 확인했습니다. 품질에 문제가 발생한 경우에는 원인을 기술, 데이터, 프롬프트 영역으로 구분해 개선하는 방식으로 검증을 반복했습니다.

여기서 한 가지 더 중요한 사실이 드러납니다.

좋은 답변은 좋은 모델만으로 만들어지지 않습니다. 

AI가 참고하는 문서가 오래됐거나 같은 내용이 여러 문서에 중복돼 있고, 표나 도식이 AI가 이해하기 어려운 형태로 작성돼 있다면 아무리 좋은 모델을 사용해도 답변 품질은 흔들릴 수 있습니다

실제 프로젝트에서도 RAG에 어떤 문서를 적재할지 결정하는 기준뿐 아니라 중복 데이터 처리, 전처리 방식, 표·별첨·도식 작성법 등 AI가 문서를 제대로 이해할 수 있도록 하는 별도의 데이터 관리 기준을 마련했습니다.

문서가 새로 작성되거나 수정될 때 RAG 적재 여부까지 관리하도록 운영 절차를 정립했습니다.

‍

결국 AI 품질 관리는 모델을 평가하는 것에서 끝나는 것이 아니라 모델이 읽는 데이터까지 함께 관리하는 과정입니다.

‍

‍2. AI가 어디에서 얼마나 많은 비용을 쓰고 있나요?

AI를 파일럿 단계에서 사용할 때는 비용이 크게 체감되지 않을 수 있습니다.

하지만 사용자가 수십 명에서 수백 명으로 늘어나고, 하나의 질문을 처리하기 위해 여러 에이전트와 LLM이 동시에 움직이기 시작하면 이야기가 달라집니다.

사용자의 질문 하나를 처리하기 위해 검색 에이전트가 사내 문서를 찾고, 분석 에이전트가 내용을 정리한 뒤 또 다른 모델이 최종 답변을 생성할 수도 있습니다.

사용자에게는 한 번의 질문처럼 보이지만 내부에서는 여러 번의 모델 호출이 발생합니다.

따라서 단순히 “이번 달 LLM 비용이 얼마인가?”만 확인해서는 부족합니다. 어느 부서에서 가장 많은 비용을 사용하고 있는지, 어떤 에이전트가 많은 토큰을 소비하는지, 고성능 모델이 필요하지 않은 업무에도 상대적으로 비용이 높은 모델이 사용되고 있지는 않은지까지 확인할 수 있어야 합니다.

다만 비용만을 기준으로 모델을 선택해서도 안 됩니다.

실제 금융권 프로젝트에서도 초기에는 오픈소스 LLM을 검토했지만, 한국어 질의와 문서에 대한 이해도, 업무 매뉴얼의 이미지와 플로차트, 리포트의 표와 차트 등을 실제 데이터로 검증한 뒤 상용 LLM으로 방향을 변경했습니다. 특히 복잡한 기업 문서는 단순 텍스트 벤치마크만으로 모델의 적합성을 판단하기 어렵다는 점을 확인할 수 있었습니다.

결국 AI 운영에서는 가장 저렴하거나 가장 성능이 좋은 모델 하나를 고르는 것보다 업무의 난이도와 데이터 특성에 맞는 모델을 적절하게 사용하는 것이 중요합니다.

‍

3. 에이전트에게 어디까지 권한을 줘야 할까요?

단순한 챗봇과 AI 에이전트의 가장 큰 차이 중 하나는 ‘행동’입니다.

챗봇이 질문에 답하는 데 그쳤다면 에이전트는 기업 내부 시스템과 연결해 데이터를 조회하고, 문서를 작성하거나 실제 업무를 실행할 수 있습니다.

문제는 권한이 커질수록 잘못된 행동이 가져올 영향도 함께 커진다는 점입니다.

사내 문서를 읽기만 하는 에이전트와 고객에게 이메일을 직접 발송할 수 있는 에이전트에 같은 수준의 통제를 적용할 수는 없습니다.

예를 들어 문서를 검색하고 요약하는 에이전트라면 필요한 데이터에 대한 읽기 권한과 사용 기록을 관리하는 것으로 충분할 수 있습니다.

반면 고객 정보를 수정하거나 외부로 메시지를 발송할 수 있는 에이전트라면 이야기가 달라집니다.

실행 전에 사람이 승인하도록 할 것인지, 특정 범위를 넘어서는 업무는 자동 실행하지 못하도록 제한할 것인지, 문제가 발생하면 즉시 동작을 중단할 수 있는지도 함께 설계해야 합니다.

특히 금융이나 공공처럼 규제가 강한 환경에서는 서비스가 정상적으로 작동하는 것만으로 운영 준비가 끝나지 않습니다. 정보보호 검토와 보안 요건을 확인하고, 서비스 관리와 시스템 운영의 담당자를 정한 뒤 관련 매뉴얼과 운영 역할까지 명확하게 이관하는 과정이 필요합니다. 실제 금융권 프로젝트에서도 정식 서비스 전 이러한 규제 대응과 운영 이관 절차가 함께 진행됐습니다.

중요한 것은 AI에게 모든 권한을 주거나 모든 기능을 막는 것이 아닙니다.

업무의 위험 수준에 맞는 만큼만 권한을 주고, 누가 운영 책임을 맡을지도 함께 정하는 것이 핵심입니다.

‍

4. 문제가 생겼을 때 “왜 그랬는지” 찾을 수 있나요?

AI 에이전트가 이상한 답변을 생성했다고 가정해보겠습니다.

“답변이 틀렸습니다”만으로는 문제를 해결할 수 없습니다.

어떤 문서를 검색했는지, 어떤 프롬프트가 전달됐는지, 어떤 모델을 사용했는지, 중간 단계에서 어떤 판단을 했는지를 확인해야 원인을 찾을 수 있습니다.

특히 여러 에이전트가 연결된 멀티 에이전트 환경에서는 더욱 복잡해집니다.

사용자의 요청 하나가 검색 에이전트 → 분석 에이전트 → 실행 에이전트로 이어졌다면 어느 단계에서 문제가 발생했는지를 추적할 수 있어야 합니다.

이때 필요한 것이 AI Observability입니다.

AI의 응답 속도나 시스템 장애 여부만 살펴보는 것이 아니라 입력부터 최종 결과까지 전체 동작 과정을 관찰하는 것입니다.

• 어떤 모델을 호출했나요?
• 어떤 데이터를 참고했나요?
• 응답에는 얼마나 시간이 걸렸나요?
• 어느 단계에서 실패했나요?
• 사용한 토큰과 비용은 얼마인가요?
• 사용자가 받은 최종 답변은 무엇인가요?

여기서 중요한 것은 로그를 ‘남기는 것’ 자체가 아닙니다.

‍

실제 운영에서는 문제가 발생했을 때 이를 기술 문제인지, 데이터 문제인지, 프롬프트 문제인지 빠르게 구분할 수 있어야 합니다. 앞서 소개한 금융권 프로젝트에서도 사용자 테스트에서 품질이 낮게 나온 답변의 원인을 유형별로 구분하고, 즉시 개선할 수 있는 항목부터 조치하는 방식으로 품질을 높였습니다.

기존 IT 시스템에서 로그가 중요했던 것처럼, AI 에이전트 시대에는 단순한 기록을 넘어 AI의 행동을 설명하고 개선으로 연결할 수 있는 기록이 필요합니다.

‍

5. 에이전트가 늘어나도 하나의 체계에서 관리할 수 있나요?

처음에는 에이전트가 몇 개 되지 않습니다.

마케팅팀은 콘텐츠 작성 에이전트, 영업팀은 고객 분석 에이전트, HR팀은 사내 규정 검색 에이전트를 하나씩 사용합니다.

문제는 이후입니다.

‍

각 부서에서 서로 다른 플랫폼과 모델을 도입하고 비슷한 에이전트를 따로 만들기 시작하면 어느 순간 회사 안에 어떤 AI가 운영되고 있는지 파악하기 어려워집니다.

누가 만들었는지 모르는 에이전트가 남아 있거나, 동일한 기능을 하는 에이전트가 부서마다 따로 존재할 수도 있습니다. 사용하지 않는 에이전트가 여전히 중요한 데이터에 접근하고 있을 가능성도 있습니다.

따라서 기업은 최소한 다음 질문에 답할 수 있어야 합니다.

“우리 회사에는 지금 몇 개의 에이전트가 운영되고 있나요?”

“각 에이전트의 담당자는 누구인가요?”

“어떤 모델과 데이터에 접근하고 있나요?”

“실제로 사용되고 있나요?”

“더 이상 사용하지 않는 에이전트는 무엇인가요?”

하지만 하나의 체계에서 관리한다는 것은 기술적인 관리 화면만을 의미하지 않습니다.

사람이 실제로 AI를 사용할 수 있는 운영 문화와 기준을 만드는 것도 함께 필요합니다.

실제 금융권 AI 프로젝트에서는 서비스를 구축하는 것과 동시에 현업을 대상으로 반복적인 AI 활용 교육을 진행하고, 사용자 교육과 내부 홍보, 개선 의견을 받을 수 있는 전용 채널을 함께 운영했습니다. 사내 AI 사용 경험이 부족하거나 LLM의 특성을 충분히 이해하지 못하면 기술적으로 완성된 서비스라도 초기 활용이 저조할 수 있기 때문입니다.

AI 운영은 결국 기술, 데이터, 사람의 세 가지가 함께 움직이는 일입니다.

에이전트가 수십 개, 수백 개로 늘어난 뒤에 관리 체계를 만드는 것보다 처음부터 공통된 운영 기준과 데이터 관리 기준, 사용자 활용 체계를 함께 마련하는 편이 훨씬 수월합니다.

‍

마치며… AI 에이전트의 경쟁력은 결국 ‘운영’에서 결정됩니다

AI 에이전트를 만드는 방법은 빠르게 쉬워지고 있습니다.

자연어로 원하는 업무를 설명하거나, 준비된 템플릿을 선택하는 것만으로도 에이전트를 구성할 수 있는 환경이 만들어지고 있습니다.

하지만 쉽게 만들 수 있다는 것과 안정적으로 운영할 수 있다는 것은 다른 문제입니다.

실제 기업 프로젝트를 들여다보면 좋은 AI 서비스를 만드는 데 필요한 요소도 생각보다 다양합니다.

모델의 성능만 높다고 충분하지 않습니다.

AI가 참고하는 문서를 지속적으로 관리해야 하고, 현업 사용자가 참여하는 평가 기준을 만들어야 합니다.

‍

문제가 생기면 기술, 데이터, 프롬프트 가운데 어디에서 문제가 시작됐는지 찾아야 하며, 서비스가 완성된 뒤에는 실제 운영 담당자에게 안정적으로 이관해야 합니다.

현업이 AI를 제대로 활용할 수 있도록 교육하고 사용 경험을 축적하는 과정도 필요합니다.

‍

실제 금융권 구축 사례에서도 양질의 RAG 데이터, 적합한 LLM, 현업의 활용 역량을 함께 갖추는 것이 핵심 요소로 다뤄졌습니다.

결국 기업에서 중요한 것은 ‘AI 에이전트를 몇 개 만들었는가’가 아닙니다.

‍

이 에이전트들을 얼마나 믿고 실제 업무에 맡길 수 있는가에 더 가깝습니다.

스켈터랩스 역시 다양한 RAG 기반 기업 AI 구축 경험을 바탕으로, MAIP aOS (agent Operating System)에서 에이전트 구축뿐 아니라 운영 이후의 데이터, 모델, 거버넌스와 평가까지 하나의 흐름으로 관리할 수 있는 환경을 확장하고 있습니다.

AI 에이전트를 도입하고 있다면 이제는 “무엇을 만들 것인가?”에서 한 걸음 더 나아가 볼 때입니다.

“만든 AI를 우리는 어떻게 운영할 것인가?”

앞으로 기업 AI 활용의 성패를 가르는 질문은 오히려 여기에 있을지도 모릅니다.

‍