LLM 시스템 운영 성숙도 모델 5단계: 관측성, 비용, 라우팅 및 플랫폼 전략

LLM 시스템 운영의 핵심 변화

LLM 시스템의 프로덕션 운영 성숙도 모델 5단계는 시스템의 일상적인 운영 가능성을 높이는 데 중점을 둔다. 이 단계는 시스템이 내리는 결정을 관측하고, 비용을 제어하며, 공급자 장애에 대비하고, 오작동 시 즉시 중단할 수 있는 능력을 확보하는 것을 목표로 한다. 핵심 아이디어는 모든 모델 트래픽이 단일 병목 지점(chokepoint)을 통과하고, 모든 작업이 `decision_id`로 연결되며, 도메인 로직이 특정 공급자에 종속되지 않도록 하는 것이다.

기존 서비스의 오류가 500 에러로 나타나는 것과 달리, LLM 시스템의 오류는 대규모로 잘못된 행동을 빠르게 유발할 수 있다. 이러한 비대칭성 때문에 LLM 시스템에서는 운영 가능성(operability)이 필수적인 요소로 부각된다. 또한, LLM 비용은 청구서가 발행되기 전까지는 파악하기 어렵고, 토큰 사용량, 호출 빈도, 재시도 횟수 등 예상치 못한 요인에 따라 급증할 수 있다.

성능 문제 역시 모델 자체보다는 데이터 파이프라인의 비효율성(예: O(n²) 루프, 순차적 처리)에서 비롯되는 경우가 많다. 다양한 모델(저렴한 모델, 고성능 모델, 주 모델, 판별 모델)과 여러 공급자를 활용하는 환경에서는 지능적인 라우팅과 장애 조치 전략이 필수적이다. 모델 공급자와 가격이 수시로 변동하므로, 핵심 비즈니스 로직을 리팩토링하지 않고도 모델을 쉽게 교체할 수 있는 아키텍처가 요구된다.

관측성 강화: 결정 중심의 모니터링

LLM 시스템의 운영 가능성을 확보하기 위해, 서비스의 가동 상태뿐만 아니라 에이전트의 '결정' 자체를 측정하고 관측하는 새로운 접근 방식이 제시된다. 이는 기존의 RED(Rate, Errors, Duration) 지표에 더해 LLM 특화 지표를 추가하여 시스템의 행동, 안전성, 비용, 품질을 포괄적으로 모니터링하는 것을 포함한다. 모든 모델 호출을 단일 게이트웨이로 집중시켜 비용을 가시화하고 통제하며, 다양한 모델과 공급자를 유연하게 활용할 수 있는 라우팅 및 장애 조치 체계를 구축한다.

이러한 변화의 중심에는 `decision_id`가 있다. `decision_id`는 모든 관측성 신호, 로깅, 트레이싱, 그리고 최종 결정 기록을 연결하는 고유 식별자로, 특정 결정의 전체 과정을 종단 간(end-to-end)으로 재구성할 수 있게 한다. 또한, 도메인 로직이 특정 모델 공급자의 SDK나 요청 객체에 직접 의존하지 않도록 육각형 아키텍처(Hexagonal Architecture)를 적용하여 공급자 교체 비용을 최소화한다.

LLM 시스템의 관측성은 표준 서비스 지표 외에 AI 특화 지표를 추가하여 강화한다. 주요 지표로는 `agent_decisions_total` (결정량 및 자동/수동 처리 비율), `agent_auto_execution_ratio` (인간 개입 없이 처리된 비율), `llm_cost_usd_total` (모델별 비용), `llm_call_duration_seconds` (모델 지연 시간), `shadow_eval_pass_ratio` (샘플링된 프로덕션 트래픽의 실시간 품질), `human_override_rate` (인간 개입률) 등이 있다. 이 지표들은 `tenant_id`와 `capability` 레이블을 포함하여 세부적인 분석을 가능하게 한다.

로깅은 민감도에 따라 세 가지 계층으로 구조화된다. Tier 1은 운영 관련 정보(타임스탬프, 레벨, `decision_id`, `tenant_id`, `outcome` 등)를 담아 경고 시스템에 활용된다. Tier 2는 결정 메타데이터(모델, 프롬프트 버전, 라우팅 결정, 가드레일 조치 등)를 포함하며 감사 기록에 준하는 역할을 한다. Tier 3은 규제 대상의 민감한 원본 데이터를 암호화하여 접근을 엄격히 통제한다. 모든 계층은 `decision_id`로 연결되어 특정 결정의 전체 흐름을 추적할 수 있다.

트레이싱은 일반적인 HTTP 요청 추적을 넘어, 에이전트의 내부 결정 그래프를 포함하도록 확장된다. 이는 `agent.decision` 스팬 아래에 `entry`, `context_load`, `llm_decision`, `output_guardrail`, `judge`, `routing`, `exit` 등 각 단계를 스팬으로 기록하여, 특정 결정이 실패한 지점이나 각 단계의 소요 시간을 쉽게 파악할 수 있게 한다. 경고는 원인이 아닌 사용자나 비즈니스에 영향을 미치는 증상에 기반하여 설정하며, 결정 가용성(≥ 99.9%), 품질(shadow-eval ≥ 기준치 − 2%), 지연 시간(p95), 비용(1천 결정당 USD ±20%)과 같은 구체적인 서비스 수준 목표(SLO)를 정의한다.

비용 제어 및 성능 최적화 전략

LLM 비용은 청구서가 나오기 전까지 파악하기 어렵고, 토큰 사용량, 호출 횟수, 재시도 등 다양한 요인에 따라 급증할 수 있다. 이를 통제하기 위해 모든 모델 호출을 단일 게이트웨이로 집중시켜 비용을 측정하고 제어한다. 이 게이트웨이에서 `llm_tokens_total` 및 `llm_cost_usd_total`과 같은 지표를 `tenant_id`, `capability`, `model`별로 기록하여 비용 발생 원인을 명확히 파악한다.

비용 절감을 위한 주요 전략은 다음과 같다. 첫째, 쉬운 결정이나 확정적인 경우는 모델 호출 없이 코드로 처리한다. 둘째, 여러 항목에 대한 호출을 일괄 처리(batch)하여 왕복 횟수를 줄인다. 셋째, 확정적인 결과(임베딩, 반복 조회)는 캐싱하여 모델 호출을 생략한다. 넷째, 의사결정의 복잡성에 따라 저렴한 모델과 고성능 모델을 적절히 선택하여 사용한다. 다섯째, 프롬프트에서 불필요한 컨텍스트를 제거하고 간결하게 유지한다.

비용 제어를 위해 테넌트별 예산 및 호출 속도 제한을 설정하며, 이는 복제본 간에 상태를 공유하여 정확하게 적용되어야 한다. 예를 들어, `tokens_per_min` 200,000, `usd_per_day` 50과 같은 제한을 설정하고, 예상 토큰 수를 기준으로 검사한다. 또한, 플랫폼 전체의 총 사용량 상한선을 설정하고, 재시도 폭주나 무한 루프와 같이 비용을 급증시킬 수 있는 요인들을 `llm_retries_total{reason}`과 같은 지표로 모니터링하고 제한한다.

성능 최적화는 품질 저하 없이 이루어져야 하며, 이를 위해 모든 변경 전에 품질 기준선(baseline)을 설정하고, 변경 후에는 반드시 기준선 대비 품질을 재평가한다. 병목 현상을 추측하기보다는 프로파일링 도구를 사용하여 실제 성능 저하의 원인을 정확히 파악하는 것이 중요하다. 일반적인 성능 개선 방안으로는 O(n²) 매칭 루프를 인덱싱이나 해시 조인으로 대체하고, 레코드별 모델/네트워크 왕복을 일괄 처리하며, 직렬 단계를 병렬 처리하고, 확정적인 작업 결과를 캐싱하는 것 등이 있다.

라우팅, 장애 조치 및 킬 스위치

LLM 시스템은 단일 모델이 아닌 여러 모델(저렴한 모델, 고성능 모델, 주 모델, 판별 모델, 여러 공급자 모델)로 구성된 '플릿'을 운영한다. 라우팅 계층은 결정의 필요에 따라 적절한 모델을 선택한다. 예를 들어, 판별(judge) 역할에는 주 모델과 독립적인 모델을 사용하고, 중요도가 낮은 대량 트래픽에는 저렴하고 작은 모델을, 모호하거나 중요도가 높은 결정에는 고성능 모델을 할당한다. 이러한 라우팅 규칙은 단일 게이트웨이에 집중되어 관리 및 테스트 용이성을 높인다.

장애 조치(fallback)는 특정 공급자 모델의 장애 시 시스템이 중단되지 않고 작동하도록 보장한다. 이는 우선순위가 정해진 모델 체인으로 구현되며, 호출 전에 서킷 브레이커(circuit breaker)를 확인하여 이미 장애가 발생한 공급자를 건너뛴다. 모든 실패 시에는 장애를 기록하여 서킷 브레이커가 작동하도록 하고, 전체 작업에 대한 마감 시간(deadline) 내에서 각 시도에 대한 타임아웃을 설정한다. 또한, 타임아웃되었지만 실제로는 완료된 요청의 중복 처리를 방지하기 위해 멱등성(idempotency)을 필수로 적용한다.

시스템은 장애 발생 시 의도적으로 기능을 저하시키도록 설계되어야 한다. 예를 들어, 모든 모델이 사용 불가능할 경우 요청을 인간에게 라우팅하여 처리하도록 한다. 라우팅 경로에 있는 모든 모델(주 모델, 저렴한 모델, 장애 조치 모델)은 품질 평가를 거쳐야 하며, 장애 조치 모델이 조용히 품질을 저하시키는 상황은 피해야 한다. `decision_id`와 함께 어떤 모델이 결정을 내렸는지 기록하여 사후 분석 시 모델별 성능 차이를 파악할 수 있도록 한다.

킬 스위치(kill switch)는 시스템의 오작동 시 몇 초 내에 작동하여 피해를 최소화하는 핵심 기능이다. 이는 모든 노드가 확인하는 런타임 상태로 구현되며, `LIVE` (정상 작동), `HUMAN_ONLY` (자동 실행 중단, 인간에게 제안), `HALTED` (모든 결정 중단)의 세 가지 모드를 제공한다. 빠른 전파(수초 내), 세분화된 제어(테넌트별, 기능별), 중간 단계(`HUMAN_ONLY`), 그리고 안전 지향적 실패(스위치 읽기 실패 시 `HUMAN_ONLY` 모드 가정)가 신뢰할 수 있는 킬 스위치의 설계 원칙이다.

이러한 메커니즘들이 이론적으로만 작동하는 것을 방지하기 위해 카오스 테스트(chaos test)를 통해 실제 장애 상황에서 검증해야 한다. 모델 공급자 중단 시 결정이 인간에게 라우팅되는지, 킬 스위치 작동 시 자동 실행이 빠르게 중단되는지, 과부하 시 시스템이 다운되지 않고 부하를 줄이는지 등을 확인한다. 의도적인 서비스 저하 설계와 카오스 테스트는 시스템이 예측 불가능한 상황에서도 안정적으로 작동함을 보장한다.

견고한 플랫폼 아키텍처 구축

위에 언급된 모든 운영 전략은 견고한 기반 플랫폼 위에서 작동한다. 육각형 아키텍처(Hexagonal Architecture)는 도메인 로직이 모델 공급자 SDK에 직접 의존하지 않도록 하여, 공급자 변경 시 리팩토링 없이 모델을 교체할 수 있게 한다. 도메인은 자체적으로 정의한 인터페이스(포트)에만 의존하고, 모델 공급자나 데이터 저장소와 같은 외부 요소는 이 포트를 구현하는 어댑터 계층에 위치한다. 모든 모델 트래픽이 흐르는 단일 게이트웨이는 이러한 아키텍처의 핵심이며, 비용 측정, 속도 제한, 라우팅, 장애 조치, 킬 스위치 등 모든 횡단 관심사를 통합 관리한다.

인프라 구축 시에는 과도한 프로비저닝이나 부족한 프로비저닝을 피하고, 실제 필요한 구성 요소를 선별적으로 도입한다. 필수 구성 요소로는 자동 확장되는 무상태 에이전트 서비스, 모델 게이트웨이, 불변의 결정 기록을 위한 관계형 데이터베이스 기반 감사 데이터 저장소, 세션 및 속도 제한을 위한 캐시(예: Redis), 모델 키 및 설정 관리를 위한 비밀 저장소, 대규모 입력 및 계층화된 로그를 위한 객체 저장소 등이 있다. 큐, 벡터 저장소, 추가 데이터베이스 등은 구체적인 워크로드 요구사항이 발생할 때만 추가한다.

가장 중요한 인프라 원칙은 최소 권한 IAM(Identity and Access Management)과 암호화이다. 각 서비스에는 필요한 최소한의 권한만 부여하고, 공유되는 정적 키 대신 서비스별 워크로드 신원(workload identity)을 사용한다. 데이터 저장 시점부터 관리형 키를 이용한 데이터 암호화를 적용하고, 감사 기록의 암호화 서명을 위한 전용 서명 키와 테넌트별 키를 설계한다. 이는 인프라를 복잡하게 만드는 대신, 각 자격 증명의 범위를 엄격히 제한하고 감사 저장소와 게이트웨이 병목 지점을 초기부터 구축하는 데 중점을 둔다.