AX Ops 방법론

루프 디버깅은 로그가 아니다

에이전트 운영은 스텝의 의미를 관측해야 끝난다

에이전트 장애는 에러 로그보다 실행 궤적에서 먼저 드러난다. 헛도는 스텝, 무한루프, 조기종료는 각각 다른 관측 지표와 다른 튜닝 처방이 필요하다.

읽기 →

Skill도 검증돼야 쓴다

출처와 권한이 없는 Skill은 운영 자산이 아니다

Skill과 MCP bundle은 문서가 아니라 실행 가능한 운영 자산이다. provenance, SBOM, 권한 manifest, tamper check가 붙어야 배포·승인·폐기가 가능해진다.

읽기 →

툴 카탈로그가 캐시를 깬다

MCP 운영의 첫 계약은 순서와 버전이다

에이전트 비용과 지연은 모델 선택만으로 줄지 않는다. MCP tool catalog의 순서, 버전, prefix가 흔들리면 prompt cache는 매번 새로 써진다.

읽기 →

깊은 생각은 정책으로 켠다

xhigh와 Max는 기본값이 아니라 예외다

test-time compute는 품질 스위치가 아니라 운영 자원이다. 불확실성, 위험도, 예산 상태를 읽는 effort-control policy 엔진이 있어야 xhigh와 Max가 낭비가 아니라 통제가 된다.

읽기 →

MCP RC는 툴 재설계다

세션 제거는 인프라 변경이 아니라 운영 모델 변경이다

MCP 2026-07-28 RC는 사내 에이전트 툴 레이어의 기준선을 바꾼다. stateless core, Tasks, MCP Apps, OAuth 하드닝을 도입 순서가 아니라 운영 위험 순서로 마이그레이션해야 한다.

읽기 →

에이전트는 과제로 배운다

강의보다 운영 과제가 역량을 만든다

에이전트 개발 역량은 프롬프트 문법 암기로 생기지 않는다. 실제 업무를 작게 재현하고, 도구 호출·권한·평가·운영 로그까지 끝까지 다루는 Project Based Learning으로 설계해야 한다.

읽기 →

오염된 기억은 성과를 갉아먹는다

회상 품질은 검색률이 아니라 오염 저항력이다

에이전트 메모리는 잘 기억하는 기능이 아니다. 무엇을 기억하지 말아야 하는지, 언제 낡은 기억을 폐기할지, 실패가 어느 단계에서 시작됐는지 추적하는 운영 체계다.

읽기 →

에이전트 로그가 곧 통제다

PII·보존·감사는 운영 설계다

에이전트 데이터 거버넌스는 보안팀 문서가 아니라 운영 구조다. PII 마스킹, 로그 보존, 감사 추적을 실행 단위로 설계하지 않으면 에이전트는 PoC를 지나 운영에서 멈춘다.

읽기 →

에이전트 A/B는 배포가 아니다

프롬프트 변경은 운영 실험으로 검증한다

에이전트 A/B 테스트는 트래픽을 반으로 나누는 일이 아니다. 같은 업무 입력, 같은 도구 조건, 같은 평가 기준으로 프롬프트·모델 변경의 이득과 손실을 함께 보는 운영 절차다.

읽기 →

런북 없는 에이전트는 장애다

오작동은 모델 문제가 아니라 운영 설계 문제다

에이전트는 대답하는 시스템이 아니라 실행하는 시스템이다. 그래서 장애 대응도 서버 장애처럼 사전에 정의해야 한다. 런북은 사고 후 문서가 아니라 배포 조건이다.

읽기 →

에이전트 변경은 기록돼야 한다

프롬프트만 버전 관리하면 원인을 놓친다

에이전트 장애의 원인은 프롬프트 한 줄이 아니라 도구 스키마, 권한, MCP 서버, 평가셋, 모델 설정의 조합에서 나온다. AX Ops는 이 조합을 릴리스 단위로 묶어 추적한다.

읽기 →

골든셋은 테스트가 아니다

회귀를 막는 운영 자산이다

에이전트 eval 골든셋은 출시 전 점검표가 아니라 운영 중 계속 갱신되는 품질 장부다. 실패 로그를 선별하고, 판정 기준을 고정하고, 배포 게이트와 연결해야 회귀를 막는다.

읽기 →