블로그

에이전트 로그가 곧 통제다

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

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

읽기 →

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

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

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

읽기 →

출력은 약속이 아니라 계약이다

스키마·검증·수정 루프가 운영을 만든다

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

읽기 →

에러 복구가 에이전트를 가른다

재시도보다 먼저 실패 경로를 설계해야 한다

에이전트는 실패하지 않는 시스템이 아니다. 좋은 에이전트는 실패를 숨기지 않고, 재시도·폴백·서킷브레이커로 업무 피해가 커지기 전에 멈추고 우회한다.

읽기 →

첫 에이전트는 운영에서 깨졌다

배포보다 어려운 것은 책임 설계였다

첫 사내 에이전트 배포 90일 뒤, 우리가 틀린 지점은 모델 선택이 아니었다. 권한, 예외, 로그, 사람의 개입 지점을 운영 구조로 만들지 않은 것이 문제였다.

읽기 →

신입의 첫 일은 사라지지 않는다

반복 업무가 아니라 판단 훈련을 다시 설계해야 한다

에이전트가 신입의 반복 업무를 가져가면 온보딩은 짧아지지 않는다. 오히려 관찰, 위임, 검증, 회고를 명시한 성장 경로가 필요하다.

읽기 →

에이전트 보안은 이사회 의제다

권한을 가진 AI는 시스템이 아니라 내부 행위자다

2026년의 핵심 질문은 AI를 쓸 것인가가 아니다. 에이전트가 어떤 권한으로, 누구의 책임 아래, 어떤 증거를 남기며 움직이는가다.

읽기 →

에이전트 ROI는 시간표가 아니다

절감 시간보다 흐름 손실을 먼저 본다

에이전트 ROI를 ‘몇 시간을 줄였나’로 읽으면 거의 반드시 과대평가된다. 진짜 측정 단위는 개인 생산성이 아니라 승인된 산출물, 재작업, 예외 처리, 운영비가 반영된 업무 흐름이다.

읽기 →

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

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

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

읽기 →

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

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

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

읽기 →

골든셋은 테스트가 아니다

회귀를 막는 운영 자산이다

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

읽기 →

에이전트는 중간에 멈춘다

승인 버튼보다 멈춤 지점이 먼저다

Human-in-the-loop는 마지막 승인 버튼이 아니다. 에이전트가 언제 멈추고, 누구에게 무엇을 물으며, 어떤 근거로 다시 실행할지 정하는 운영 계약이다.

읽기 →