블로그
AI 전환(AX), 에이전트 도입, AX Ops 방법론에 대한 현장 기록.
-

비용 초과는 장애다
에이전트 예산은 사후 정산이 아니라 런타임 통제다
에이전트 비용이 예산을 넘긴 날, 우리는 모델을 바꾸기 전에 운영 회로부터 끊었다. 원인은 비싼 모델이 아니라 무제한 반복, 긴 context, 도구 호출의 무감시였다.
읽기 → -

MCP 첫 연결은 끝이 아니었다
붙이는 일보다 운영 경계가 먼저다
사내 첫 MCP 서버를 붙이면 기대는 빠르게 올라간다. 그러나 실제 과제는 연결이 아니라 권한, 승인, 로그, 장애 대응을 운영 체계로 묶는 일이다.
읽기 → -

AI 거부감은 운영 신호다
저항을 분류해야 현장이 움직인다
AI 도입 저항은 태도 문제가 아니다. 생계 불안, 역량 노출, 효용 의심, 윤리·보안 우려, 업무 관성은 각각 다른 운영 처방을 요구한다.
읽기 → -

에이전트 팀의 KPI는 판단이다
산출물 개수보다 판단 품질을 봐야 한다
에이전트가 초안·분석·정리를 맡는 팀에서 사람의 성과를 산출물 수로 재면 엉뚱한 행동을 보상한다. 이제 KPI는 더 많이 만든 사람이 아니라 더 정확히 판단한 사람을 드러내야 한다.
읽기 → -

첫 자동화 업무는 따로 있다
에이전트 우선순위는 효과가 아니라 운영 가능성으로 정한다
에이전트 도입의 첫 대상은 ‘큰 업무’가 아니다. 반복되고, 되돌릴 수 있고, 검수 책임자가 있는 닫힌 루프 업무부터 자동화해야 운영으로 넘어간다.
읽기 → -

락인은 런타임에서 온다
모델 교체보다 실행층 분리가 먼저다
에이전트 락인은 특정 모델을 쓰는 순간이 아니라, 도구 호출·메모리·권한·관측 로직이 한 벤더 런타임에 붙는 순간 발생한다. AX 전략은 모델 선택이 아니라 실행 경계 설계에서 시작해야 한다.
읽기 → -

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

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

출력은 약속이 아니라 계약이다
스키마·검증·수정 루프가 운영을 만든다
구조화 출력은 프롬프트 문구가 아니라 운영 계약이다. 스키마로 경계를 정하고, 검증으로 실패를 분리하고, 자기수정 루프로 복구 가능한 오류만 되돌려야 한다.
읽기 → -

에러 복구가 에이전트를 가른다
재시도보다 먼저 실패 경로를 설계해야 한다
에이전트는 실패하지 않는 시스템이 아니다. 좋은 에이전트는 실패를 숨기지 않고, 재시도·폴백·서킷브레이커로 업무 피해가 커지기 전에 멈추고 우회한다.
읽기 → -

첫 에이전트는 운영에서 깨졌다
배포보다 어려운 것은 책임 설계였다
첫 사내 에이전트 배포 90일 뒤, 우리가 틀린 지점은 모델 선택이 아니었다. 권한, 예외, 로그, 사람의 개입 지점을 운영 구조로 만들지 않은 것이 문제였다.
읽기 → -

신입의 첫 일은 사라지지 않는다
반복 업무가 아니라 판단 훈련을 다시 설계해야 한다
에이전트가 신입의 반복 업무를 가져가면 온보딩은 짧아지지 않는다. 오히려 관찰, 위임, 검증, 회고를 명시한 성장 경로가 필요하다.
읽기 →