AI 에이전트 운영 점검: readiness 계약으로 배포 후 드리프트를 잡는 법

배포 직후 테스트가 통과한 에이전트도 다음 주에는 다른 시스템일 수 있다. 모델 버전과 가격 정책이 바뀌고, MCP 도구의 응답 스키마가 달라지고, 토큰 권한이 만료되고, 검색 인덱스나 외부 API가 조용히 갱신되기 때문이다. 나는 이 문제를 단순 장애 모니터링보다 readiness 계약을 계속 증명하는 운영 문제로 본다. 7월 23일 공개된 연구는 시민 개발자가 만든 조직용 에이전트가 모델·도구·검색 소스·권한·스케줄 같은 변화하는 의존성에 묶여 있어, 사용자가 수정하지 않아도 시간이 지나며 성능이 저하될 수 있다고 지적했다. 제안한 continuous assurance의 중심은 의존성 맵, readiness 계약, 예약 점검, 진단, 수명주기 거버넌스다. 이 글의 결론은 간단하다. 에이전트는 배포 시점에 한 번 승인하는 소프트웨어가 아니라, 지금도 필요한 연결과 경계를 지키는지 반복 확인해야 하는 운영 주체다.

배포 검증과 운영 readiness는 다른 질문이다

배포 전 검증은 코드와 설정이 그 순간의 요구사항을 만족하는지 묻는다. 테스트, 린트, 권한 검토, 산출물 probe는 여기에 속한다. 이는 반드시 필요하다. 하지만 에이전트는 정적 바이너리보다 연결된 작업 흐름에 가깝다. 실행 때마다 모델, 검색, 데이터베이스, MCP 서버, 인증 토큰, 스케줄러, 외부 API를 통과한다.

그래서 운영 중에는 질문이 달라진다.

• 이 모델 ID와 도구 버전은 승인했을 때와 같은가?
• 필수 도구가 같은 입력·권한으로 아직 응답하는가?
• 읽기 전용이어야 할 작업이 쓰기 권한을 얻지는 않았는가?
• 검색 결과와 정책 문서가 갱신됐을 때, 에이전트는 근거와 시각을 남기는가?
• 실패한 점검은 사람이 처리할 수 있는 증거를 남겼는가?

이 목록은 “에이전트가 오늘 성공했는가”와 다르다. 성공한 한 건은 우연히 정상 경로를 탔다는 뜻일 수 있다. readiness는 다음 작업이 시작되기 전에 필요한 의존성과 제약이 여전히 유효한지 확인하는 상태다.

readiness 계약은 긴 체크리스트보다 작은 불변식 묶음이다

처음부터 거대한 거버넌스 시스템을 만들 필요는 없다. 실제로 점검할 수 있는 계약을 작업 단위로 적는 편이 낫다. 예를 들어 “매일 블로그 초안을 만드는 리서치 에이전트”라면 결과 문장의 품질을 자동 판정하려 하기보다, 실행 가능한 전제부터 점검한다. 허용된 공개 소스만 읽었는지, 최소 두 개의 원문 링크가 남았는지, 외부 발신 권한이 없는지, 산출물 경로가 존재하는지 같은 조건이다.

아래 YAML은 특정 프레임워크 문법이 아니라 운영자가 리뷰할 수 있는 계약 예시다. 값과 경로는 각 팀의 실제 환경으로 바꿔야 한다.

agent_readiness:
  dependencies:
    required_tools: ["research-fetch", "markdown-writer"]
    allowed_domains: ["arxiv.org", "docs.github.com"]
  permissions:
    external_send: false
    write_scope: "content-drafts/"
  freshness:
    source_max_age_hours: 72
  evidence:
    required_source_links: 2
    require_run_log: true
  recovery:
    on_check_failure: "block_and_notify_operator"

계약의 핵심은 모든 것을 감시하는 데 있지 않다. 실패했을 때 위험해지는 조건을 명시하는 데 있다. required_tools는 도구가 사라졌는지 잡고, allowed_domains는 예상 밖의 데이터 경로를 좁힌다. write_scope는 산출물의 폭발 반경을 제한하고, source_max_age_hours와 링크 수는 오래된 근거를 그대로 재활용하는 문제를 드러낸다. 마지막의 복구 조건은 점검 실패를 재시도 폭주로 바꾸지 않는다.

여기서 중요한 구분이 하나 있다. readiness 계약은 프롬프트 안의 “조심해서 해”가 아니다. 버전 관리·리뷰·변경 이력이 가능한 별도 설정이나 문서여야 한다. 그래야 어떤 점검이 어떤 정책 위반을 발견했는지 설명할 수 있다.

정기 점검은 헬스체크가 아니라 변화 탐지다

정기 실행 자체는 어려운 기능이 아니다. GitHub Actions 공식 문서는 특정 GitHub 활동뿐 아니라 예약 시각에도 워크플로를 실행할 수 있다고 설명한다. 하지만 cron을 추가했다고 continuous assurance가 되는 것은 아니다. 매일 같은 HTTP 200만 보는 점검은, 도구가 다른 데이터를 반환하거나 권한 범위가 넓어져도 놓칠 수 있다.

좋은 점검은 세 층으로 나눈다.

1. 도달성: 인증, DNS, API 상태, 파일 경로처럼 실행을 시작할 수 있는지 확인한다.
2. 계약성: 도구 출력에 필요한 필드가 남아 있는지, 금지된 권한이나 경로가 새로 열리지 않았는지 확인한다.
3. 업무성: 작은 고정 입력으로 실제 에이전트 경로를 한 번 통과시켜, 예상한 산출물과 증거가 생성되는지 확인한다.

GitHub Actions에서 예약 점검을 시작하는 최소 예시는 다음처럼 작을 수 있다. 이 코드는 워크플로 파일에 넣기 전 YAML 파서로 문법을 검증해야 하며, 실제 비밀값을 출력해서는 안 된다.

name: agent-readiness
on:
  schedule:
    - cron: "17 2 * * *"
  workflow_dispatch:
jobs:
  check:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: python3 scripts/check_agent_readiness.py

점검 스크립트의 성공 조건은 “응답이 왔다”보다 좁아야 한다. 예를 들어 도구 정의의 예상 버전, 읽기 전용 권한, 출력 JSON의 필수 키, 최근 증거 링크를 각각 검사한다. 그리고 실패하면 자동으로 권한을 넓히거나 강한 모델로 폴백하지 말고, 어느 계약 조항이 깨졌는지 남긴 뒤 작업을 막는 편이 안전하다.

점검 결과는 알람 한 줄이 아니라 복구 가능한 증거여야 한다

알람이 “agent check failed” 한 줄이면 운영자는 다시 조사해야 한다. continuous assurance가 실제로 비용을 줄이려면 실패 기록이 다음 행동을 바로 좁혀야 한다. GitHub Actions는 각 job의 로그를 보고, 검색하고, 내려받을 수 있으며 실패한 step의 로그와 실행 시간을 확인할 수 있다고 문서화한다. 이런 실행 기록을 에이전트 점검에도 같은 방식으로 다뤄야 한다.

나는 최소한 다섯 개의 필드를 남기는 쪽을 권한다.

• 점검한 계약 ID와 정책 버전
• 모델·도구·스키마의 실제 관찰 버전
• 실패한 probe와 재현 가능한 최소 입력
• 영향받는 작업과 현재 차단 상태
• 사람이 확인해야 할 다음 조치와 재점검 조건

예를 들어 “MCP 서버 오류”보다 contract=research-v3; tool=search; expected_field=canonical_url; observed=missing; writes_blocked=true가 훨씬 낫다. 전자는 알림이고, 후자는 진단의 시작점이다. 비밀값, 사용자 원문, 인증 헤더는 이 기록에 넣지 않는다는 경계도 같이 지켜야 한다.

내 의견: 운영의 목표는 완벽한 감시가 아니라 조용한 퇴화를 빨리 멈추는 것이다

내 의견은 분명하다. 에이전트가 배포 뒤에도 같은 시스템이라고 가정하는 순간 운영자는 가장 위험한 장애를 놓친다. 모델·도구·문서·권한은 각자 다른 속도로 변하고, 이 변화는 대개 오류 화면보다 그럴듯하지만 조금 틀린 결과로 먼저 나타난다. 가벼운 반론도 있다. 작은 팀에 readiness 계약과 예약 점검까지 붙이면 자동화 자체보다 관리 부담이 커 보일 수 있다. 맞다. 일회성 스크립트나 읽기 전용 실험에는 과하다. 하지만 정기 실행, 외부 도구, 쓰기 권한, 고객·공개 산출물 중 둘 이상이 결합되는 순간에는 조용한 퇴화를 나중에 알아내는 비용이 훨씬 크다. 필요한 것은 대형 플랫폼이 아니라, 작은 계약과 작은 probe를 계속 실행하는 습관이다.

김덕환 운영자 관점

김덕환 운영자 관점에서는 에이전트를 더 많이 연결하기 전에 각 자동화에 “오늘도 실행 가능한가”라는 짧은 질문을 붙이는 편이 낫다. 모델 이름, 도구 상태, 권한 범위, 데이터 freshness, 증거 경로 중 세 가지부터 계약으로 만들자. 예약 점검이 실패하면 결과를 억지로 만들지 말고 작업을 차단하고 이유를 남긴다. 그러면 운영자는 장애가 난 뒤 로그를 뒤지는 대신, 변화가 결과물로 번지기 전에 어떤 경계가 깨졌는지 볼 수 있다.

참고 자료

• Toward Continuous Assurance for the Democratization of AI Agent Creation in Industry — arXiv:2607.21495, 2026-07-23
• GitHub Docs — Events that trigger workflows: schedule
• GitHub Docs — Using workflow run logs