3.4대규모 관측성 설계

일반적인 서비스의 관측성은 오류율과 지연시간을 봅니다. 에이전트 시스템에서는 이 두 지표가 모두 정상인데 결과가 틀린 상황이 흔합니다. 모델은 오류를 던지지 않고 그럴듯한 답을 내놓기 때문입니다.

따라서 에이전트 관측성은 세 축을 함께 봐야 합니다.

축	지표	무엇을 잡는가
시스템 건강	오류율, 지연시간, 처리량	전통적인 장애
자원 소비	토큰, 캐시 적중, 툴 호출 수, 왕복 수	비용 폭주와 비효율
결과 품질	작업 완료율, 검증 통과율, 에스컬레이션율, 사용자 재질의율	조용한 실패

세 번째 축이 에이전트 특유의 영역이고, 가장 자주 빠져 있는 부분입니다. 특히 유용한 대리 지표가 사용자 재질의율입니다. 같은 사용자가 같은 주제로 곧바로 다시 물으면 첫 답이 쓸모없었다는 신호입니다. 정답 레이블이 없어도 측정할 수 있어 실무에서 값이 큽니다.

툴 호출 수와 왕복 수도 품질 신호를 겸합니다. 같은 유형의 작업인데 평소 3회 왕복하던 것이 갑자기 12회로 늘었다면, 모델이 헤매고 있다는 뜻입니다. 이런 분포 변화는 오류율에는 전혀 나타나지 않습니다.

사후에 "왜 이런 답이 나왔지"를 답하려면 그 답을 만든 입력 전체가 남아 있어야 합니다. 최종 응답만 남기면 재구성이 불가능합니다.

세션 하나의 추적에 최소한 담겨야 하는 것:

• 각 모델 호출의 입력 구성 — 시스템 프롬프트 버전, 툴 목록, 컨텍스트에 들어간 문서 ID
• 각 호출의 토큰 사용량 — 입력·출력·캐시 생성·캐시 읽기를 구분해서
• 각 툴 호출의 인자와 결과
• 모델 식별자와 주요 설정 — 등급, 사고 강도
• 컨텍스트 편집이나 압축이 일어났다면 그 사실과 시점

마지막 항목이 특히 중요합니다. 긴 세션에서 앞부분이 요약되거나 오래된 툴 결과가 정리되면, 모델이 실제로 본 내용은 원래 이력과 달라집니다. 이 사실을 기록하지 않으면 나중에 이력을 그대로 재생해도 같은 결과가 나오지 않아 원인 추적이 막힙니다.

전체 프롬프트를 그대로 저장할지는 판단이 필요합니다. 재현성은 최고지만 비용과 개인정보 위험이 큽니다. 실무 절충은 프롬프트 자체 대신 구성 요소의 식별자와 해시를 남기는 것입니다. 시스템 프롬프트는 버전 번호로, 검색된 문서는 ID와 청크 인덱스로 기록하면, 원본이 남아 있는 한 재구성이 가능하면서 저장량과 노출 위험이 크게 줄어듭니다.

추적 레코드 예시 (한 번의 모델 호출)
  session_id, turn_index
  system_prompt_version: "v14"
  retrieved_chunks: ["doc-812#3", "doc-990#7"]
  tools_loaded: ["search", "read_ticket"]
  model: "<등급>", effort: "medium"
  usage: {input, output, cache_creation, cache_read}
  tool_calls: [{name, args_hash, latency_ms, is_error}]
  context_edited: false

개인정보가 섞이는 필드는 저장 전에 처리해야 합니다. 툴 인자에 고객 정보가 들어간다면 원문 대신 해시나 마스킹된 형태로 남기고, 보관 기간을 정해둡니다.

세션 하나를 완전히 기록하는 것은 쉽습니다. 하루 백만 세션이 되면 같은 방식이 무너집니다.

1. 저장량. 에이전트 세션은 요청 하나가 수십 번의 모델 호출과 툴 호출로 이뤄지므로, 트래픽 대비 로그량이 일반 서비스보다 훨씬 큽니다. 전량 보존은 곧 비용 문제가 됩니다.

2. 카디널리티. 이것이 대규모에서 가장 자주 터지는 함정입니다. 메트릭에 세션 ID나 사용자 ID를 라벨로 붙이면 시계열 개수가 사용자 수만큼 늘어나 모니터링 시스템이 감당하지 못합니다. 높은 카디널리티 값은 메트릭 라벨이 아니라 추적 속성으로 넣어야 합니다.

넣을 곳	무엇을
메트릭 라벨	유형·모델 등급·경로처럼 값의 종류가 적은 것
추적 속성	세션 ID·사용자 ID·문서 ID처럼 값이 무한한 것

3. 샘플링. 전량 보존이 불가능하면 표본을 남깁니다. 균등 표본만 두면 드물게 일어나는 실패를 놓치므로, 실무에서는 결과 기반 표본을 씁니다. 성공한 평범한 세션은 낮은 비율로, 실패·에스컬레이션·비정상적으로 긴 세션은 전량 보존합니다.

def should_retain(trace):
    if trace.had_error or trace.escalated:
        return True                      # 실패는 전량 보존
    if trace.turn_count > P95_TURNS:
        return True                      # 이상하게 긴 세션도 전량
    return hash(trace.session_id) % 100 < 2   # 나머지는 2% 표본

4. 비용 귀속. 규모가 커지면 "누가 얼마를 쓰는가"가 관측성의 일부가 됩니다. 토큰 사용량을 테넌트·기능·경로 단위로 집계할 수 있어야 어디를 최적화할지 정할 수 있습니다. 이를 위해 추적 레코드에 귀속 키를 처음부터 넣어둬야 하고, 나중에 붙이려면 과거 데이터를 잃습니다.

기록이 많아도 아무도 보지 않으면 소용이 없습니다. 경보는 사람이 즉시 행동할 수 있는 것만 걸어야 하고, 그 외는 대시보드에 둡니다.

에이전트 시스템에서 실제로 유용한 경보는 대개 분포 변화입니다. 절대값 임계보다 평소 대비 변화가 신호를 더 잘 잡습니다.

경보 후보	왜 유용한가
세션당 평균 왕복 수의 급증	모델이 헤매기 시작한 신호
캐시 적중률의 급락	프리픽스를 깨는 변경이 배포된 신호
에스컬레이션율 급증	처리 못 하는 유형이 유입된 신호
특정 툴의 오류율 급증	외부 의존성 장애
테넌트별 토큰 사용량 급증	비용 사고 또는 오남용

두 번째 줄이 실무에서 특히 값집니다. 캐시 적중률은 코드 변경에 민감하게 반응하는데, 배포 후 조용히 떨어져도 기능은 정상 동작하기 때문에 비용 청구서가 오기 전까지 아무도 모릅니다.

경보를 걸 때 흔한 실수는 모델 응답 품질에 직접 임계를 거는 것입니다. 품질은 표본 평가로 주기적으로 측정하는 대상이지 실시간 경보 대상이 아닌 경우가 많습니다. 대신 위 표처럼 품질과 상관이 높은 운영 지표에 경보를 걸고, 경보가 울리면 표본을 꺼내 사람이 확인하는 흐름이 현실적입니다.