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