AX LABS
← 블로그 AX Ops 방법론

AgentOps는 MLOps가 아니다

모델 운영에서 업무 실행 운영으로 넘어가라

AX LABS 6분 읽기

PoC까지는 잘 된다. 모델을 붙이고, RAG를 얹고, 데모 화면에서 답이 나오면 회의실 분위기가 좋아진다. 문제는 그다음이다. 운영 환경에 올리는 순간 질문이 바뀐다. 이 에이전트가 어떤 권한으로 어느 시스템을 건드렸는가. 실패했을 때 누가 멈추는가. 비용이 튀면 어디서 끊는가. MLOps 방식으로는 이 질문에 답이 부족하다.

OpenAI는 Responses API를 에이전트형 애플리케이션의 새 기본 인터페이스로 밀고 있고, 도구 호출·상태·멀티모달·remote MCP를 한 흐름에 넣었다. Assistants API는 2025년 8월 26일 deprecate 되었고 2026년 8월 26일 sunset 예정이다. 이 변화는 특정 벤더 이슈가 아니다. 운영 단위가 “모델”에서 “행동하는 실행체”로 옮겨갔다는 신호다. (platform.openai.com)

AgentOps의 대상은 모델이 아니라 실행 경로다

MLOps는 여전히 필요하다. 모델 품질, 데이터 드리프트, 배포 파이프라인, 롤백은 사라지지 않는다. 다만 에이전트 운영에서는 그것이 전부가 아니다.

구분 MLOps AgentOps
운영 대상 모델·피처·데이터 파이프라인 에이전트·도구·권한·메모리·handoff
실패 형태 예측 품질 저하, 드리프트 잘못된 도구 호출, 무한 루프, 권한 오남용
관측 단위 요청·응답·지표 trace, tool call, context 변경, 승인 이벤트
릴리스 기준 모델 성능·재현성 업무 성공률, 안전 경계, 비용·시간 한도

Anthropic의 Claude Agent SDK도 subagents, hooks, MCP servers, custom commands를 하나의 애플리케이션 구성 요소로 다룬다. Google ADK와 A2A 역시 에이전트 간 연결과 배포를 전제로 움직인다. 운영 프레임은 모델별이 아니라 실행 경로별로 짜야 한다. (anthropic.com)

AgentOps의 핵심은 “답변 품질 관리”가 아니라 “업무 실행 통제”다.

6단계 전환은 통제면을 넓히는 순서다

첫째, 에이전트 인벤토리를 만든다. 챗봇, 사내 Copilot, 코드 에이전트, 리포트 자동화, 운영 자동화 봇을 같은 장부에 올린다. 모델명이 아니라 목적, 소유자, 권한, 연결 시스템, 실패 시 영향으로 분류한다.

둘째, harness를 표준화한다. prompt만 표준화하면 부족하다. context 주입, memory 보존, tool orchestration, retry, fallback, handoff 규칙을 템플릿으로 묶는다. 이 레이어가 흔들리면 모델을 바꿔도 운영 품질은 좋아지지 않는다.

셋째, 도구와 권한을 registry로 관리한다. MCP는 LLM 애플리케이션과 외부 데이터·도구를 연결하는 표준 프로토콜로 자리 잡았다. 그래서 더 위험하다. 어떤 MCP server를 누가 등록했고, 어떤 scope로 호출하며, credential은 어디서 회전되는지 운영 체계가 먼저 있어야 한다. (modelcontextprotocol.io)

넷째, trace와 평가를 배포 전제조건으로 둔다. OpenAI Agents SDK는 agent run에서 LLM generation, tool call, handoff, guardrail 이벤트를 trace 대상으로 본다. OpenTelemetry도 GenAI agent·framework span을 별도 영역으로 다룬다. 로그를 남기는 수준이 아니라 실패 재현이 가능한 실행 기록을 남겨야 한다. (openai.github.io)

다섯째, human-in-the-loop를 예외가 아니라 설계값으로 둔다. 결재, 외부 발송, 데이터 삭제, 고객 영향이 있는 조치는 승인 이벤트를 요구한다. 에이전트가 멈춰야 하는 조건도 명시한다. 시간 한도, 비용 한도, 반복 호출 한도, 권한 상승 요청은 런타임 정책으로 걸어야 한다.

여섯째, 운영 리듬을 만든다. AgentOps board를 두고 신규 에이전트 등록, 릴리스 승인, 사고 리뷰, 평가셋 갱신, 도구 폐기를 정기 안건으로 다룬다. MLOps 팀만의 일이 아니다. 현업 프로세스 오너, 보안, IT 운영, 데이터 조직이 같이 봐야 한다.

로드맵은 PoC 종료 시점이 아니라 시작 전에 깔아야 한다

현장에서 가장 자주 보는 실패는 순서가 뒤집힌 경우다. 먼저 에이전트를 만들고, 나중에 관측과 권한을 붙인다. 그러면 운영 전환 시점에 다시 만든다. AgentOps는 후속 정비가 아니라 설계 전제다.

AX Ops에서는 첫 킥오프에서 세 가지 산출물을 먼저 만든다. 에이전트 인벤토리, 실행 경로 표준안, 운영 게이트다. 그다음 PoC를 한다. 그래야 PoC 결과가 데모가 아니라 운영 자산으로 남는다.

얕은 결론은 이렇다. MLOps 위에 AgentOps를 얹지 말고, MLOps를 포함하는 실행 운영 체계로 재설계해야 한다. 에이전트가 업무를 대신 수행하는 순간, 운영의 단위도 업무 실행으로 바뀐다. 전환의 첫 설계는 AX Ops 방법론 →에서 시작하면 된다.

참고