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

프로세스 오너가 에이전트를 맡아야 한다
AI-Native 조직은 역할표부터 다시 짠다
AI 에이전트는 도구가 아니라 위임받은 일의 실행 단위다. 프로세스 오너는 업무 설명자가 아니라 Agent Product Owner가 되어 backlog, 권한, 평가, RACI를 운영해야 한다.
읽기 → -

제품 기능은 버튼이 아니라 계약이다
agent가 호출할 수 없으면 기능은 잠긴다
AI-Native 제품의 표면은 화면이 아니라 action contract다. UI는 그 계약을 사람이 쓰는 방식이고, agent는 같은 계약을 기계가 호출하는 방식이다.
읽기 → -

로그인 에이전트는 가둬야 쓴다
권한보다 격리가 먼저인 브라우저 설계
SaaS를 조작하는 에이전트의 핵심 리스크는 모델이 아니라 로그인된 세션이다. 브라우저 VM, 세션별 egress allowlist, credential shadowing을 기본 구조로 잡아야 운영에 올릴 수 있다.
읽기 → -

Subagent는 큐로 다뤄야 한다
위임보다 중요한 것은 join과 cancel이다
Supervisor가 subagent를 호출하고 기다리는 구조는 운영에서 막힌다. 원격 subagent는 task ID로 위임하고, 필요할 때 join·update·cancel하는 비동기 큐로 설계해야 한다.
읽기 → -

추론은 저장이 아니라 재생이다
tool call마다 reasoning span을 다르게 다룬다
에이전트가 tool call을 여러 번 거치면 실패는 모델보다 컨텍스트 재생에서 먼저 난다. reasoning span은 로그가 아니라 실행 상태다. 보존·마스킹·재주입 정책을 tool call 단위로 설계해야 한다.
읽기 → -

Skill도 검증돼야 쓴다
출처와 권한이 없는 Skill은 운영 자산이 아니다
Skill과 MCP bundle은 문서가 아니라 실행 가능한 운영 자산이다. provenance, SBOM, 권한 manifest, tamper check가 붙어야 배포·승인·폐기가 가능해진다.
읽기 → -

도구 호출 직전이 통제점이다
unsafe-success는 성공이 아니라 운영 사고다
에이전트는 답변보다 행동에서 사고를 낸다. tool call 직전에 risk verdict를 만들고 차단·승인·축소 실행을 결정하는 loop가 운영 안전의 기준선이다.
읽기 → -

Agent Gateway가 검문소다
정책은 프롬프트가 아니라 호출 경로에 둔다
에이전트가 SaaS와 다른 에이전트를 호출하는 순간 위험은 답변 품질 문제가 아니다. Agent Gateway는 모든 호출을 한 프록시에서 검문하는 policy data plane이다.
읽기 → -

툴 카탈로그가 캐시를 깬다
MCP 운영의 첫 계약은 순서와 버전이다
에이전트 비용과 지연은 모델 선택만으로 줄지 않는다. MCP tool catalog의 순서, 버전, prefix가 흔들리면 prompt cache는 매번 새로 써진다.
읽기 → -

압축은 멈춤이 아니라 배치다
장기 실행 에이전트는 히스토리를 병렬로 줄인다
장기 실행 에이전트의 실패는 모델 성능보다 히스토리 운영에서 먼저 온다. 압축을 단일 요약 호출로 두면 지연과 손실이 동시에 생긴다. 블록 단위 병렬 압축과 merge verifier가 운영 설계의 기준선이다.
읽기 → -

좌석 수는 운영 지표가 아니다
AI-Native는 사용자가 아니라 위임된 일을 본다
AI 도입 성과를 라이선스 좌석 수로 재면 조직은 사용량만 늘린다. AI-Native 운영 모델은 위임된 업무의 깊이, 도구 실행 강도, 선도 팀의 확산률을 본다.
읽기 → -

도구 결과는 명령이 아니다
스키마와 출처가 권한 경계를 만든다
에이전트가 망가지는 지점은 도구 호출 자체가 아니라 도구 결과를 명령처럼 읽는 순간이다. Tool-use integrity boundary는 결과의 형식, 출처, 권한을 분리해 운영 사고를 줄이는 설계다.
읽기 →