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

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

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

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

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

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

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

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

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

에이전트 보안은 이사회 의제다
권한을 가진 AI는 시스템이 아니라 내부 행위자다
2026년의 핵심 질문은 AI를 쓸 것인가가 아니다. 에이전트가 어떤 권한으로, 누구의 책임 아래, 어떤 증거를 남기며 움직이는가다.
읽기 → -

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

런북 없는 에이전트는 장애다
오작동은 모델 문제가 아니라 운영 설계 문제다
에이전트는 대답하는 시스템이 아니라 실행하는 시스템이다. 그래서 장애 대응도 서버 장애처럼 사전에 정의해야 한다. 런북은 사고 후 문서가 아니라 배포 조건이다.
읽기 → -

에이전트 변경은 기록돼야 한다
프롬프트만 버전 관리하면 원인을 놓친다
에이전트 장애의 원인은 프롬프트 한 줄이 아니라 도구 스키마, 권한, MCP 서버, 평가셋, 모델 설정의 조합에서 나온다. AX Ops는 이 조합을 릴리스 단위로 묶어 추적한다.
읽기 →