관측 가능성과 AgentOps 운영

실패를 개선 가능한 사건으로 만들기

에이전트 운영에서 가장 위험한 실패는 큰 실패가 아니다. 기록되지 않은 실패다. 사용자는 "이상한 답을 받았다"고 말하지만, 시스템에는 최종 응답 문자열만 남아 있다. 어떤 모델을 썼는지, 어떤 프롬프트 버전이었는지, 어떤 문서를 검색했는지, 어떤 도구를 호출했는지 알 수 없다. 이런 실패는 재현할 수 없고, 재현할 수 없는 실패는 고칠 수 없다.

반대로 모든 것을 원문 그대로 저장하는 것도 답이 아니다. 사용자 입력, 검색 문서, 도구 결과, 모델 응답에는 개인정보, 인증 정보, 내부 정책, 고객 데이터가 섞일 수 있다. 디버깅을 위해 남긴 로그가 나중에 가장 큰 보안 사고가 될 수 있다.

관측 가능성의 목표는 "많이 저장하기"가 아니다. 한 번의 실행을 나중에 다시 설명할 수 있을 만큼 충분히 기록하되, 저장하면 안 되는 정보는 애초에 남기지 않는 것이다. AgentOps는 이 원칙을 에이전트 운영에 적용한 실천 영역이다. 에이전트의 실행, 비용, 지연시간, 도구 호출, 실패 패턴, 가드레일 차단을 운영 지표로 다루고, 문제를 프롬프트·도구·정책·평가 개선으로 되돌린다.

실행 하나를 하나의 궤적으로 묶기

에이전트의 한 번 실행은 단일 함수 호출보다 복잡하다. 사용자 요청을 받고, 계획을 세우고, 검색을 하고, 모델을 여러 번 호출하고, 도구를 실행하고, 검증기를 통과한 뒤 최종 응답을 만든다. 중간에 권한 거부, 재시도, 컨텍스트 초과, 검증 실패가 발생할 수 있다.

따라서 모든 실행에는 상관관계 식별자가 필요하다.

run_id      : 에이전트 실행 1회를 식별
session_id  : 같은 사용자 흐름 또는 대화 묶음
user_id     : 사용자 단위 분석과 권한 확인
tenant_id   : 조직·고객사 단위 격리와 비용 집계
trace_id    : 실행 궤적 전체를 묶는 추적 ID

이 식별자들은 로그, 트레이스, 메트릭, 감사 기록에 함께 들어가야 한다. 그래야 "지난 릴리스 이후 특정 테넌트에서 RAG 검색 실패가 늘었다", "프롬프트 v18에서만 재시도가 급증했다", "특정 도구의 p95 지연시간이 전체 응답 지연을 만들었다" 같은 질문에 답할 수 있다.

한 실행 궤적에는 최소한 다음 정보가 연결되어야 한다.

• 사용자 요청의 분류와 안전 처리된 요약

• 모델 이름, 모델 버전, 추론 파라미터

• 프롬프트 버전, 하네스 버전, 정책 버전

• 컨텍스트 구성 방식: 검색 쿼리, 문서 ID, 메모리 조각 ID

• 도구 호출 이름, 입력 스키마, 출력 요약, 상태 코드

• 검증기와 가드레일 결과

• 재시도 횟수와 재시도 이유

• 토큰 사용량, 비용, 지연시간

• 최종 응답 상태: 성공, 실패, 차단, 인간 승인 대기

중요한 점은 "원문 전체"가 아니라 "원인 분석에 필요한 구조"를 남기는 것이다. 예를 들어 검색된 문서 전문을 매번 저장하기보다 문서 ID, 버전, 청크 ID, 점수, 짧은 요약을 저장할 수 있다. 필요할 때 권한 있는 사람이 원본 저장소에서 확인하면 된다.

Trace, Span, Event, Metric으로 나누기

OpenTelemetry식 관측 모델은 에이전트 워크플로에도 잘 맞는다. Microsoft Foundry 문서도 트레이스는 요청이나 워크플로의 여정을 기록하고, 스팬은 그 안의 단일 작업 단위이며, 속성은 분석을 위한 메타데이터라고 설명한다.¹ 이 구조를 에이전트에 적용하면 실행이 평평한 로그 목록이 아니라 읽을 수 있는 트리로 바뀐다.

예를 들어 고객 지원 에이전트의 실행은 다음처럼 나눌 수 있다.

trace: agent.run
├─ span: request.receive
├─ span: plan.create
├─ span: rag.search
├─ span: llm.answer_draft
├─ span: tool.lookup_order
├─ span: guardrail.check
├─ span: llm.finalize
└─ span: response.send

각 span은 시작 시간, 종료 시간, 상태, 주요 속성을 가진다. rag.search span에는 검색 쿼리, 인덱스 버전, top-k, 검색 지연시간이 들어간다. tool.lookup_order span에는 도구 이름, 입력 필드, 권한 범위, 상태 코드가 들어간다. llm.answer_draft span에는 모델명, 프롬프트 버전, 입력 토큰, 출력 토큰, 비용이 들어간다.

사건(event)은 span 안에서 발생한 중요한 순간이다.

• permission.denied: 허용되지 않은 도구 호출

• context.limit_exceeded: 컨텍스트 예산 초과

• validation.failed: JSON 스키마 또는 정책 검증 실패

• retry.started: 재시도 시작

• guardrail.blocked: 안전 정책으로 응답 차단

• human_approval.requested: 인간 승인 요청

metric은 운영자가 지속적으로 보는 숫자다.

• 실행 성공률과 실패율

• 도구별 오류율

• 모델·프롬프트 버전별 성공률

• 평균 비용과 p95 비용

• 평균 지연시간과 p95 지연시간

• 입력·출력 토큰 사용량

• 재시도율

• 권한 거부율

• 가드레일 차단율

평균만 보면 위험하다. 평균 지연시간은 안정적인데 p95가 급증하면 일부 사용자는 이미 심각한 지연을 겪고 있다. 평균 비용은 정상인데 특정 워크플로의 비용만 튀면 장시간 루프나 반복 재시도가 숨어 있을 수 있다.

무엇을 저장하지 않을지 먼저 정하기

프롬프트와 응답 전문 저장은 강력한 디버깅 도구다. 실제로 AgentOps류 도구들은 LLM 호출, 도구 사용, 토큰, 비용, 세션 재생을 추적하는 기능을 제공한다.² 하지만 전문 저장은 항상 위험을 동반한다. 사용자가 주민등록번호, API 키, 계약서 내용, 의료 정보, 내부 장애 보고서를 입력할 수 있기 때문이다.

그래서 관측 설계는 저장 필드 목록보다 저장 금지 기준에서 출발해야 한다.

첫째, 민감정보 탐지와 마스킹을 수집 전에 수행한다. 이메일, 전화번호, 계좌번호, 토큰, 비밀번호 패턴은 원문 로그에 들어가기 전에 제거하거나 해시 처리한다. "나중에 배치 작업으로 지우겠다"는 방식은 이미 늦다.

둘째, 필드 단위 저장 정책을 둔다. 모든 필드를 같은 보존 등급으로 보지 않는다.

저장 가능        : run_id, span_id, 모델명, 버전, 상태 코드, 비용
요약 저장        : 사용자 요청 요약, 도구 출력 요약, 검색 결과 요약
조건부 저장      : 프롬프트 전문, 응답 전문, 검색 청크 전문
저장 금지        : 비밀번호, API 키, 결제 정보, 원본 개인정보

셋째, 샘플링을 적용한다. 모든 성공 실행의 전문을 저장할 필요는 없다. 실패, 차단, 재시도, 고비용 실행은 높은 비율로 저장하고, 정상 실행은 낮은 비율로 샘플링한다. 단, 비용·지연시간·성공 여부 같은 집계 지표는 샘플링 없이 남겨야 운영 상태를 왜곡하지 않는다.

넷째, 접근권한과 감사 로그를 둔다. 트레이스 조회는 운영 권한이 아니라 데이터 접근 권한이다. 누가 어떤 run을 열람했는지 남기고, 테넌트 간 접근은 기본적으로 차단한다.

다섯째, 보존 기간과 삭제 요청 처리를 정한다. 디버깅 로그는 영구 보관물이 아니다. 예를 들어 원문 페이로드는 7일, 마스킹된 trace는 90일, 집계 metric은 1년처럼 목적별 기간을 다르게 둔다. 사용자의 삭제 요청이 들어왔을 때 어떤 저장소에서 어떤 식별자로 삭제할지도 미리 정해야 한다.

AgentOps 대시보드가 보여줘야 할 것

좋은 대시보드는 예쁜 그래프가 아니라 빠른 판단을 돕는 화면이다. AgentOps 대시보드는 최소한 네 가지 질문에 답해야 한다.

첫째, 지금 장애인가? 전체 실패율, p95 지연시간, 도구별 오류율, 가드레일 차단율을 보여준다. 실패율이 2%에서 12%로 뛰었다면 즉시 원인을 좁혀야 한다.

둘째, 무엇이 바뀌었는가? 에이전트 시스템의 배포 단위는 코드만이 아니다. 모델, 프롬프트, 도구 스키마, 권한 정책, 검색 인덱스, 평가 데이터셋이 함께 바뀐다. 대시보드는 릴리스 전후 비교를 제공해야 한다. prompt_v21 배포 이후 특정 intent에서 실패가 늘었는지, model_b 전환 이후 비용이 줄었지만 재시도가 늘었는지 볼 수 있어야 한다.

셋째, 어디서 비용이 발생하는가? 에이전트 비용은 최종 모델 호출에서만 생기지 않는다. 계획 수립, 검색, 재랭킹, 검증용 judge, reflection, 재시도가 모두 비용을 만든다. span 단위 비용 분해가 있어야 줄일 수 있다.

넷째, 어떤 실패가 반복되는가? 컨텍스트 길이 초과, 같은 도구 반복 호출, JSON 형식 오류, 권한 거부, 특정 API 타임아웃, 가드레일 차단 증가를 묶어서 보여줘야 한다. 반복되는 실패는 운영자가 매번 처리할 일이 아니라 하네스가 흡수해야 할 설계 결함이다.

알림도 신중해야 한다. 모든 이상에 호출 알림을 걸면 운영자는 곧 알림을 무시하게 된다. 호출 알림은 사용자 영향이 크고 즉시 조치가 필요한 신호로 제한한다.

호출 알림 대상
- 실패율이 기준선의 2배 이상이고 절대값 5% 초과
- p95 지연시간이 기준선의 3배 초과
- 건당 비용이 기준선의 5배 초과
- 결제·삭제·권한 변경 같은 고위험 도구 오류 증가

리포트 알림 대상
- 특정 프롬프트 버전의 성능 저하
- 가드레일 차단율 완만한 증가
- 컨텍스트 사용량 증가 추세
- 특정 도구의 경미한 오류율 상승

관측에서 하네스 진화로

관측 가능성은 장애 분석으로 끝나면 절반만 한 것이다. 좋은 하네스는 관측 결과를 다음 개선으로 바꾼다.

AHE 연구는 하네스 성능을 개선하기 위해 관측 가능성을 핵심 기둥으로 삼는다. 구성 요소를 명시적으로 편집 가능하게 만들고, 방대한 실행 궤적에서 유용한 증거를 추출하며, 각 변경의 예측과 실제 결과를 연결하는 방식이다.³ 중요한 통찰은 단순하다. 하네스 변경은 감으로 하는 튜닝이 아니라 검증 가능한 계약이어야 한다.

운영에서도 같은 루프를 만들 수 있다.

1. trace에서 반복 실패 패턴 발견
2. 실패 원인을 span 단위로 분류
3. 프롬프트, 도구 스키마, 권한 정책, 컨텍스트 구성 중 수정 지점 선택
4. 실패 사례를 평가 데이터셋에 추가
5. 수정 버전을 제한된 트래픽에 배포
6. 이전 버전과 성공률·비용·지연시간·차단율 비교
7. 개선되면 확대, 악화되면 롤백

예를 들어 tool.call.arguments 검증 실패가 반복된다면 모델을 탓하기 전에 도구 인터페이스를 봐야 한다. 인자 이름이 모호한지, 필수 필드가 너무 많은지, enum 값이 설명 없이 노출되어 있는지 확인한다. 개선은 프롬프트 문장 추가가 아니라 도구 스키마 단순화일 수 있다.

context.limit_exceeded가 늘어난다면 검색 top-k를 줄이거나, 청크 요약을 도입하거나, 오래된 메모리를 압축해야 한다. permission.denied가 늘어난다면 권한 정책이 너무 엄격한 것인지, 에이전트가 불필요하게 위험한 도구를 선택하는 것인지 나눠 봐야 한다.

핵심은 trace를 "사후 기록"이 아니라 "다음 하네스 변경의 근거"로 쓰는 것이다.

운영 체크리스트

• 모든 실행에 run_id, session_id, user_id, tenant_id, trace_id를 부여한다.

• 사용자 요청부터 최종 응답까지 모델 호출, 검색, 도구 실행, 검증, 재시도를 span으로 연결한다.

• 권한 거부, 컨텍스트 초과, 검증 실패, 가드레일 차단, 재시도는 event로 남긴다.

• 성공률, 실패율, 비용, 토큰, p95 지연시간, 도구별 오류율을 metric으로 관리한다.

• 프롬프트와 응답 전문 저장은 기본값이 아니라 예외로 둔다.

• 민감정보 탐지, 마스킹, 암호화, 접근권한, 감사 로그, 보존 기간을 함께 설계한다.

• 대시보드는 릴리스 전후 비교와 버전별 성능 저하를 보여줘야 한다.

• 반복 실패는 평가 케이스, 가드레일, 도구 스키마, 프롬프트, 정책 개선으로 되돌린다.

관측 가능성은 에이전트를 감시하기 위한 부가 기능이 아니다. 운영 가능한 하네스의 신경계다. 기록되지 않은 실패는 개선할 수 없고, 과하게 기록한 데이터는 사고가 된다. 좋은 AgentOps는 이 두 위험 사이에서 필요한 만큼만 정확히 보고, 본 것을 다음 설계 개선으로 연결한다.

참고

¹Trace and observe AI agents in Microsoft Foundry

²AgentOps Quickstart

³Agentic Harness Engineering: Observability-Driven Automatic Evolution of Coding-Agent Harnesses