AX LABS
← 블로그 AX Ops 방법론

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

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

AX LABS 7분 읽기

데모는 통과했는데 운영 회의에서 멈춘다. 현업은 빨리 열자고 하고, IT는 일부만 열자고 하고, 리스크 조직은 먼저 지켜보자고 한다. 세 의견 모두 맞다. 문제는 누가 보수적인가가 아니다. 아직 어떤 위험을 줄이려는지 합의하지 않았다는 점이다.

롤아웃 방식은 기술이 아니라 책임 배분이다

rolling release, canary, shadow deployment는 배포 도구의 옵션명이 아니다. 실패했을 때 누구에게 영향이 가고, 누가 중단 권한을 갖고, 어떤 신호를 성공으로 볼지 정하는 운영 계약이다.

방식 에이전트가 하는 일 확인하는 위험 맞는 상황
shadow deployment 기존 업무 옆에서 같은 입력을 받아 결과만 남긴다 판단 품질, 정책 위반, 누락 행동 권한을 주기 전
canary 일부 사용자나 일부 트래픽에서 실제 행동한다 실제 사용자 반응, 예외 처리 rollback 경로가 명확할 때
rolling release 조직·업무·지역 단위로 점진 확대한다 운영 부하, 교육, SLA 업무 프로세스까지 바뀔 때

shadow는 안전한 실험실이 아니다. 운영 데이터의 그림자를 따라가며 에이전트의 판단을 기록하는 방식이다. canary는 작은 출시가 아니다. 실제 책임을 제한된 범위에 먼저 부여하는 방식이다. rolling은 느린 배포가 아니다. 조직이 새 일하는 방식을 흡수하는 속도를 조절하는 방식이다.

에이전트 롤아웃의 핵심은 얼마나 빨리 켜느냐가 아니라, 무엇을 보면 멈출지 먼저 정하는 일이다.

에이전트는 배포보다 회수가 어렵다

일반 소프트웨어는 잘못된 화면이나 API 오류로 드러난다. 에이전트는 더 넓게 움직인다. 검색하고, 파일을 읽고, 툴을 호출하고, 사람에게 메시지를 보낸다. 2025년 5월 OpenAI는 Responses API에 remote MCP 서버, 이미지 생성, Code Interpreter, file search 개선, background mode 등을 추가했다. 에이전트가 더 많은 시스템에 붙는 방향은 이미 제품 레벨에서 진행 중이다. (openai.com)

그래서 롤아웃 기준도 바뀐다. 모델 응답 품질만 보면 부족하다. tool call 실패, 권한 초과, 지연, 비용, human handoff, 감사 로그까지 한 묶음으로 봐야 한다. Microsoft도 2025년 Copilot Studio 업데이트에서 에이전트 평가는 출시 전후 생애주기의 일부라고 명시했다. 수동 테스트와 직관만으로는 고위험 시나리오를 검증하기 어렵다는 현실을 전제로 한 설명이다. (microsoft.com)

선택 순서는 shadow 다음 canary가 아니다

현장에서 자주 보는 오해가 있다. shadow를 하고, canary를 하고, rolling을 하면 된다는 순서형 사고다. 틀렸다. 세 방식은 성숙도 단계가 아니라 불확실성의 종류에 대응한다.

정책 판단이 불확실하면 shadow를 고른다. 예를 들어 고객 응대 문구, 승인 추천, 계약 검토 보조처럼 틀린 행동을 바로 고객이나 거래에 반영하면 안 되는 업무다. 이때 성공 기준은 사용자 만족이 아니라 기존 처리와의 차이, 누락, 금지 행동 발생 여부다.

사용자 반응이 불확실하면 canary를 고른다. 상담원이 실제로 제안을 채택하는지, 영업 조직이 추천 다음 행동을 신뢰하는지, 내부 포털 사용자가 에이전트 답을 업무에 반영하는지 봐야 한다. Google Cloud Deploy 문서도 canary를 기존 버전과 새 버전 사이에서 트래픽을 나누고 안정성을 확인한 뒤 100%로 전진하는 방식으로 설명한다. (cloud.google.com)

조직 흡수력이 불확실하면 rolling release를 고른다. 센터별, 공장별, 법인별로 업무 리듬이 다르면 한 번에 켜는 순간 지원 조직이 먼저 무너진다. Azure Well-Architected Framework도 안전한 배포에서 점진 노출, health check, 문제 발견 시 중단과 복구를 핵심 원칙으로 둔다. (learn.microsoft.com)

참고: 결정표는 운영회의에서 닫아야 한다

AX Ops에서 롤아웃 설계는 개발 막판 체크리스트가 아니다. 킥오프 때부터 배포 단위, 관측 지표, 중단 조건, 책임자를 정한다. 그래야 PoC가 끝난 뒤 운영 조직이 다시 원점에서 싸우지 않는다.

참고 자료:

다음 에이전트 롤아웃 회의에서는 어떤 방식이 멋져 보이는지 묻지 말고, 어떤 위험을 먼저 줄일지 한 문장으로 쓰면 된다. 그 문장이 나오면 shadow, canary, rolling 중 하나는 자연스럽게 탈락한다. AX LABS는 그 결정을 운영 설계로 고정한다. 더 구체적인 적용 방식은 AX Ops 방법론 →에서 확인할 수 있다.