블로그

에이전트는 한 번에 켜지 않는다

롤아웃 방식은 위험의 종류로 고른다

에이전트 배포는 기능 배포보다 회수가 어렵다. rolling release, canary, shadow deployment는 성숙도 순서가 아니라 위험의 종류에 따라 고르는 운영 장치다.

읽기 →

에이전트 테스트는 재생이다

운영 전 검증은 trace를 다시 돌리는 일이다

LLM 에이전트는 최종 답변만 맞춰서는 검증되지 않는다. trace를 기록하고, 같은 조건으로 replay하며, 장애 조건을 simulation해야 운영 품질이 보인다.

읽기 →

비용 예산 없이는 에이전트가 샌다

토큰·도구·지연 시간을 같은 장부에 올려야 한다

에이전트 비용은 모델 단가만으로 관리되지 않는다. AX Ops는 토큰, 도구 호출, 지연 시간을 하나의 실행 예산으로 묶고 운영 기준선을 먼저 세운다.

읽기 →

신뢰는 런타임에서 재야 한다

에이전트 평가는 운영 중 제동까지 이어져야 한다

ARS·RGC·ACR·PAAS는 에이전트를 사후 채점하는 장식 지표가 아니다. 운영 중 판단·근거·출처·정책 준수를 측정하고, 자동 실행 권한을 조절하는 제어 신호다.

읽기 →

에이전트는 게이트를 통과해야 한다

평가는 보고서가 아니라 배포 조건이다

에이전트 평가는 출시 전 발표자료가 아니라 배포 파이프라인의 차단 장치다. 프롬프트, 모델, tool, memory가 바뀌면 CI/CD에서 같은 기준으로 막아야 한다.

읽기 →

MCP는 연결보다 경계다

내부 도구 래핑은 권한 절단부터 시작한다

MCP 서버는 내부 API를 AI에 붙이는 얇은 어댑터가 아니다. 도구 정의, 권한, 전송 방식, 관측 체계를 함께 설계해야 운영에서 사고가 나지 않는다.

읽기 →

에이전트는 네 지표로 산다

trace보다 운영 지표가 먼저다

프로덕션 에이전트 observability는 로그 수집이 아니다. 업무 완료, 도구 실행, 컨텍스트 품질, 실행 예산을 한 흐름으로 잡아야 운영 판단이 선다.

읽기 →

AgentOps는 MLOps 이후다

모델 관리에서 행동 관리로 전환한다

AgentOps는 MLOps 도구를 하나 더 붙이는 일이 아니다. 모델 산출물 관리에서 에이전트 행동, 도구 호출, 사람 개입, 실패 복구를 운영하는 체계로 넘어가는 일이다.

읽기 →

팀 설정이 에이전트를 지킨다

settings.json은 개인 취향 파일이 아니라 운영 규약이다

Claude Code를 팀에 풀면 성과보다 먼저 설정 편차가 드러난다. settings.json은 권한, hook, plugin, sandbox를 팀 운영 단위로 고정하는 에이전트 통제면이다.

읽기 →

권한 없는 에이전트는 사고다

도구·데이터·예산은 실행 전에 잘라야 한다

에이전트 실패는 답변 품질 문제가 아니라 권한 경계 문제로 터진다. 운영 에이전트는 도구, 데이터, 예산을 같은 통제면에서 설계해야 한다.

읽기 →

멀티 에이전트는 연결에서 무너진다

역할보다 계약, 검증, 운영 경계가 먼저다

멀티 에이전트 실패는 모델 성능 부족보다 설계 실패에서 시작된다. 병렬화 착각, 느슨한 핸드오프, 검증 없는 종료가 운영을 무너뜨린다.

읽기 →

툴 조율이 에이전트 품질이다

순서보다 실패 경로를 먼저 설계한다

에이전트의 품질은 모델 성능보다 tool orchestration에서 갈린다. 순차·병렬·재시도·파이프라인은 기술 패턴이 아니라 업무 책임을 배치하는 방식이다.

읽기 →