대규모 언어 모델에 의존하는 시스템의 운영은 시스템을 사용 가능하게 만들거나 초기 정확도를 개선하는 데서 끝나지 않는다. 시스템이 완전히 가동 중인 상태에서도 잘못된 결정을 조용히 승인하거나, 예산을 빠르게 소진하거나, 장애가 발생했을 때 품질이 검증되지 않은 모델로 전환할 수 있다. 따라서 Running LLM systems in production 시리즈의 다섯 번째 글은 시스템을 관찰하고 제어하고 중지하고 복구할 수 있게 만드는 계층인 일상적인 운영 가능성에 초점을 맞춘다.
서비스만이 아니라 결정을 모니터링하라
요청률, 오류, 응답 시간, CPU 사용량과 같은 전통적인 서비스 지표만으로는 에이전트가 올바른 결정을 내리고 있는지 알 수 없다. 글에서는 결정량, 자동 실행 비율, 복합 신뢰도 분포, 각 노드의 소요 시간, 안전 제어 차단 상태, 토큰 및 비용 사용량, 사람의 개입률, 프로덕션 트래픽 샘플에 대한 비공개 평가 결과를 포함하는 결정 전용 모니터링 계층을 추가할 것을 제안한다.
글은 신호를 결정, 안전, 비용 및 성능, 품질이라는 네 가지 계열로 구분한다. 모든 것을 측정할 수 없다면 자동 실행 비율, 안전 제어 차단, 전체 모델 비용, 시스템 결정에 대한 사람의 재정의율을 우선해야 한다.
또한 로그를 세 계층으로 나눌 것을 권장한다. 대용량 운영 데이터, 신뢰 범위 내의 결정 메타데이터, 암호화 및 엄격한 접근 제어의 대상이 되는 원시 또는 구조화 데이터다. 각 결정에는 decision_id라는 고정 식별자가 있어야 하며, 이를 통해 지표, 로그, 트레이스, 감사 기록을 연결할 수 있어야 한다. 그러면 하나의 결정을 시작부터 끝까지 조사할 수 있다.
비용을 측정하고 제한 가능하게 만들어라
모델 호출을 코드베이스의 여러 부분에 분산해서는 안 된다. 그렇게 하면 비용을 귀속하고 제어하기 어려워진다. 대신 글에서는 모든 호출이 통과하는 단일 게이트웨이를 제안한다. 이 게이트웨이는 테넌트, 기능, 모델별 토큰과 비용을 계산하고, 속도 제한과 예산을 적용한다.
비용 절감 도구의 우선순위는 다음과 같다. 결정적 규칙으로 충분할 때 모델을 호출하지 않고, 항목을 하나의 호출로 묶고, 결정적 결과를 캐시하며, 단순한 작업에는 더 작은 모델을 선택한 다음, 불필요한 컨텍스트와 지침을 줄이는 것이다. 또한 모든 요청을 하나의 단위로 계산하지 말고 호출 전에 예상 토큰을 산정해야 하며, 플랫폼 전체 상한과 재시도 횟수 제한 및 무제한 도구 루프 제한을 설정해야 한다.
라우팅, 폴백, 중지 키
실제로 모든 작업에 하나의 모델만 사용할 수는 없다. 저위험·고용량 작업은 더 작은 모델로 라우팅하고, 모호하거나 민감한 사례는 더 강력한 모델에 할당할 수 있다. 모델이 동일한 취약점을 공유하지 않도록 판단 모델에는 다른 모델 계열을 사용할 수도 있다. 라우팅 또는 폴백 경로에 있는 모든 모델은 평가해야 한다. 대체 모델로 전환하면 품질이 달라질 수 있기 때문이다.
제공업체가 중단된 동안에는 하나의 전체 시간 제한을 적용하는 명확한 폴백 체계를 사용해야 한다. 장애가 알려진 제공업체의 호출을 막는 회로 차단기와, 호출이 실제로 성공한 뒤 시간 초과가 발생했을 때 결정이 두 번 처리되는 것을 방지하는 멱등성 키도 필요하다. 대체 경로가 허용되지 않을 때는 성능 저하를 숨기지 말고 결정을 사람에게 넘겨야 한다.
중지 키에 대해 글에서는 이를 모든 사용자에게 적용하거나 특정 테넌트 또는 기능에만 적용할 수 있는 공유 운영 상태로 작동하게 할 것을 제안한다. 상태에는 정상 운영, 자동 실행을 중지하되 사람을 위한 제안은 유지하는 HUMAN_ONLY, 의사결정을 완전히 중지하는 HALTED가 포함된다. 키에 접근할 수 없는 경우 안전한 동작은 정상 운영을 계속하는 것이 아니라 사람의 검토 모드로 전환하는 것이다.
혼란을 방지하는 아키텍처
글은 어댑터 인터페이스와 게이트를 통해 도메인 로직을 모델 제공업체의 패키지와 분리하는 6방향 아키텍처에 운영 가능성을 연결한다. 이렇게 하면 비즈니스 로직을 다시 작성하지 않고도 제공업체를 교체할 수 있으며, 네트워크나 비용 없이 모의 모델을 사용해 도메인을 테스트할 수 있다.
기본 아키텍처에는 상태 비저장 에이전트 서비스, 모델 게이트웨이, 추가 전용 감사 저장소, 한도와 중지 키를 위한 공유 저장소, 비밀 저장소, 입력 및 민감한 데이터를 위한 객체 저장소가 포함된다. 또한 글은 각 서비스에 독립적인 ID와 최소 권한을 부여하고, 모든 홉에서 테넌트 ID가 요청과 일치하는지 검증해야 한다고 강조한다. 특히 지연된 작업에 단기 위임 권한을 사용할 때 중요하다.
이 소식이 중요한 이유
여기서 실질적인 가치는 새로운 구성 요소를 추가하는 데 있지 않다. 핵심 제어 지점을 하나의 진입점으로 모으는 데 있다. 모델 교체를 가능하게 하는 게이트웨이는 동시에 비용을 측정하고, 한도를 적용하며, 라우팅과 폴백을 관리하고, 중지를 활성화한다. 다만 이 접근 방식의 성공 여부는 모델 제공업체 중단, 중지 키 활성화, 갑작스러운 부하, 실행 중인 결정 중 노드 재시작과 같은 장애 시나리오를 실제로 테스트하는 데 달려 있다. 이러한 테스트가 없으면 복구 메커니즘은 검증되지 않은 가정에 머문다.