SHIFTONE
실전 노트11분 읽기SHIFTONE Team

파일럿은 통과했는데 운영에서 멈춘다 — AI 에이전트 프로덕션 전환에서 무너지는 네 지점

파일럿에서 잘 돌던 AI 에이전트가 운영에서 멈추는 이유는 모델이 아니라 구조예요. 비결정성 검증, 스팬 기반 관측, GPU 자원 선언, 최소 권한까지 프로덕션 전환에서 반복해 무너지는 네 지점을 엔지니어 관점에서 정리했어요.

계기와 스위치가 빼곡히 늘어선 선박 기관 제어실 — 파일럿이 아니라 상시 운전되는 운영 환경

파일럿에서 잘 돌던 AI 에이전트가 운영에 올라가면 조용히 멈춰요. 데모에서는 열 번 다 맞혔는데, 운영에서는 같은 질문에 다른 답이 나오고 어디서 틀렸는지 로그를 봐도 알 수가 없어요.

가트너는 2025년 6월, 에이전틱 AI 프로젝트의 40% 이상이 2027년 말까지 취소될 것으로 전망했어요. 이유로 든 건 모델 성능이 아니라 비용 급증, 불분명한 사업 가치, 미흡한 리스크 통제였고요. 실패는 대개 에이전트가 똑똑하지 않아서가 아니라 운영 구조가 없어서 생깁니다. 도입 단계는 기업용 AI Agent 도입 6단계 가이드 2편에서 다뤘으니, 여기서는 그다음 — 파일럿과 프로덕션 사이에서 반복해 무너지는 네 지점을 볼게요.

파일럿 구성과 운영 구성은 다른 그림이에요

파일럿 사람 → 에이전트 → 모델노트북 · 개인 API 키 · 임시 프롬프트 확인은 눈으로"몇 번 해보니 잘 되더라" 권한은 넉넉하게읽기 · 쓰기 전부 열어두고 시작 프로덕션 평가 게이트골든셋 회귀 · 배포 전 자동 채점 스팬 기반 관측invoke_agent · chat · execute_tool 자원 선언GPU를 속성으로 요청 · 스케줄러가 배치 최소 권한 계정에이전트별 분리 · 쓰기 작업은 승인 경유 파일럿에서 생략한 네 칸이 운영에서 그대로 장애 지점이 된다 전환 비용은 모델 교체가 아니라 이 네 칸을 만드는 비용이다

1. 비결정성 — "되더라"는 증거가 아니에요

같은 입력에 같은 출력이 나오지 않는 시스템은 기존 QA 방식으로 검증되지 않아요. 열 번 해보고 통과시킨 에이전트는 열한 번째에 무너져도 이상하지 않거든요.

필요한 건 골든셋(golden set) 이에요. 실제 업무에서 나온 질문·문서·기대 답변을 수십 건 고정해 두고, 프롬프트나 모델을 바꿀 때마다 자동으로 채점해서 기준선 아래면 배포를 막아요. 회귀 테스트와 목적이 같고, 채점 기준이 이진값이 아니라 정확도·근거 인용률·거부율이라는 점만 달라요.

볼 것은 절대 점수가 아니라 기준선 대비 변화예요. 85점이 좋은지는 아무도 모르지만, 어제 85점이 오늘 71점이면 명백한 신호니까요.

2. 관측 — 로그가 아니라 스팬이 필요해요

에이전트는 한 번의 요청 안에서 모델을 여러 번 호출하고 도구를 불러요. 애플리케이션 로그로는 "느렸다"까지만 알 수 있고 어느 단계가 느렸는지는 알 수 없어요.

OpenTelemetry의 GenAI 시맨틱 컨벤션은 이 구조를 트레이스로 표준화하고 있어요. 최상위에 invoke_agent 스팬을 두고 그 아래 모델 호출(chat)과 도구 실행(execute_tool)을 자식 스팬으로 붙이고, 토큰 사용량과 종료 사유를 속성으로 남기는 식이에요.

다만 확정된 표준은 아니에요. GenAI 규약은 본 저장소에서 분리돼 별도 저장소로 옮겨졌고 지금도 바뀌고 있어요. 그래서 속성 이름을 코드 곳곳에 박지 말고 래퍼를 한 겹 두는 편이 안전해요.

3. 자원 — GPU를 하드코딩하지 않아요

자체 모델을 서빙한다면 GPU 배치가 곧 비용이에요. 파일럿에서는 "이 노드의 이 GPU"를 지정하고 시작하지만, 운영에서는 워크로드가 오르내리고 카드 종류가 섞이면서 그 방식이 병목이 돼요.

쿠버네티스는 이 지점을 Dynamic Resource Allocation(DRA)으로 정리했어요. v1.34에서 resource.k8s.io 핵심 API가 GA로 승격되고 기본 활성화됐고요. 디바이스 플러그인이 kubelet에서 장치를 직접 할당했다면, DRA는 워크로드가 필요한 장치의 속성을 선언하고 배치는 스케줄러가 정해요. 노드에 묶여 있던 추론 파드를 클러스터 단위로 풀 수 있다는 뜻이에요. 관련 구축 역량은 SHIFTONE 서비스 역량에 정리해 뒀어요.

4. 권한 — 에이전트 계정의 권한이 곧 사고 반경이에요

에이전트는 API를 호출하고 파일을 쓰고 메일을 보내요. 파일럿에서 넉넉하게 열어둔 권한을 그대로 올리면 잘못된 판단 한 번이 운영 데이터에 반영돼요.

에이전트마다 별도 계정을 쓰고, 읽기와 쓰기를 분리하고, 되돌릴 수 없는 작업(결제·삭제·외부 발송)에는 사람 승인을 끼워요. 감사 로그에는 무엇을 했는지만이 아니라 어떤 근거로 그 도구를 골랐는지를 남겨야 나중에 재구성이 돼요. 에이전트가 여러 개면 문제는 통신 구간으로 번지는데, 그 지형은 MCP 옆에 A2A가 앉았다에서 다뤘어요.

정리

네 항목 중 어느 것도 모델을 바꿔서 해결되지 않아요. 여기에 실패 처리 — 재시도 한도, 폴백 경로, 사람 에스컬레이션 — 를 더하면 운영 전환 점검표가 돼요. 오히려 이 구조가 갖춰지면 모델 교체는 쉬운 작업이 됩니다. 평가 게이트가 있으니 바꿔 보고 점수를 비교하면 되니까요.

자주 묻는 질문

Q. 파일럿에서 프로덕션까지 보통 얼마나 걸리나요? A. 기간보다 범위가 변수예요. 위 네 항목 중 몇 개를 새로 만드는지에 달렸어요. 사내 인증·로그·쿠버네티스 기반이 이미 있으면 평가 게이트와 계측을 얹는 작업만 남아요.

Q. 골든셋은 몇 건이나 만들어야 하나요? A. 실제 사용자 질문 수십 건으로 시작해서, 운영 중 틀린 사례가 나올 때마다 추가하면 돼요. 크기보다 바뀔 때마다 자동으로 돌아가는지가 중요해요.

Q. 관측 규약이 계속 바뀌는데 지금 도입해도 되나요? A. 스팬 계층 구조(에이전트 → 모델 호출 → 도구 실행)는 규약과 무관하게 유효하고, 속성 이름만 감싸 두면 규약 변경은 국소적 수정으로 끝나요. 계측을 미루는 쪽이 비용이 더 커요.

Sources