관측 가능성 설계

앞 장에서 우리는 에이전트를 어떻게 평가할지 이야기했다. 이제 시선을 조금 바꿔 보자. 평가가 시험이라면, 관측 가능성은 현장 카메라에 가깝다. 시험 성적표만으로는 학생이 어디서 헤맸는지 알기 어렵듯, 최종 응답만으로는 에이전트가 왜 실패했는지 알 수 없다.

에이전트는 특히 그렇다. 겉으로는 그럴듯한 답을 내놓았는데 사실은 엉뚱한 도구를 썼을 수 있다. 필요한 검색을 건너뛰었을 수도 있고, 오래된 문서를 읽고도 최신 정보처럼 말했을 수도 있다. 더 무서운 경우는 아예 실패처럼 보이지 않는 실패다. 응답은 매끈한데 실제 작업은 잘못된 방향으로 진행되는 경우다.¹

그래서 운영 환경의 에이전트에는 반드시 눈이 필요하다. 보이지 않는 에이전트는 디버깅할 수도, 신뢰할 수도 없다. 관측 가능성 설계는 바로 그 눈을 만드는 일이다.

왜 전통적인 모니터링만으로는 부족한가

기존 소프트웨어 모니터링은 주로 요청 수, 응답 시간, 에러율, CPU 사용량 같은 것을 본다. 이런 정보는 여전히 중요하다. 서버가 죽었는지, API가 느린지는 알아야 하니까.

하지만 에이전트는 그 위에서 한 층 더 복잡하게 움직인다. HTTP 요청 하나가 들어와도 그 안에서 모델 호출이 여러 번 일어나고, 도구가 몇 개나 불리고, 중간 판단이 바뀌고, 다른 하위 에이전트로 일이 넘어갈 수 있다. 바깥에서 보면 200 OK인데, 안에서는 세 번째 도구 선택이 틀어져서 쓰레기 같은 결론으로 향했을 수도 있다.²

쉽게 말하면, 전통적인 APM이 건물의 전기와 수도를 보는 일이라면, 에이전트 관측 가능성은 그 안에서 사람이 실제로 어떤 순서로 일했는지를 보는 일이다. 불은 켜져 있고 수도도 나오지만, 주방에서 설탕 대신 소금을 넣고 있을 수 있다.

관측 가능성의 목표는 "무슨 일이 있었는가"를 재구성하는 것이다

좋은 관측 가능성은 단순히 로그를 많이 남기는 것이 아니다. 한 번의 요청에 대해 다음 질문에 답할 수 있어야 한다.

• 사용자는 무엇을 요청했는가

• 에이전트는 어떤 계획 또는 경로를 택했는가

• 어떤 모델과 어떤 도구를 어떤 순서로 사용했는가

• 각 단계에서 시간이 얼마나 걸렸고 비용이 얼마나 들었는가

• 어디서 실패했거나 이상 행동이 시작되었는가

• 최종 결과는 어떤 상태를 만들었는가

이 질문에 답할 수 있으면 디버깅이 가능해진다. 답할 수 없으면 에이전트 운영은 점집 운영에 가까워진다. 사용자 신고가 들어오면 모두가 화면을 보며 "이번엔 모델이 좀 이상했나?"라고 추측만 하게 된다.

운영 환경에서는 추측보다 기록이 중요하다. 에이전트는 비결정적이기 때문에 같은 입력을 다시 넣어도 똑같이 재현되지 않을 수 있다. 그래서 문제를 본 순간의 실행 기록, 즉 그 실행 자체의 증거가 특히 중요하다.¹³

로그, 트레이스, 이벤트, 상태 스냅샷은 어떻게 다른가

관측 가능성 설계가 헷갈리는 이유는 비슷한 단어가 많이 나오기 때문이다. 하지만 이 네 가지는 역할이 꽤 다르다.

로그는 단계별 메모다. 어떤 도구를 불렀는지, 어떤 오류가 났는지, 어떤 모델을 썼는지 같은 사실을 구조화해서 남긴다.

트레이스는 한 번의 요청 전체를 꿰는 이야기다. 사용자 입력에서 시작해 모델 호출, 도구 실행, 승인 요청, 최종 응답까지를 한 줄의 흐름으로 묶어 준다. 흔히 부모-자식 관계의 span 구조로 표현한다.¹²

이벤트는 중요 장면의 깃발이다. 예를 들어 tool_selected, guardrail_blocked, approval_requested, handoff_started, retry_exhausted 같은 순간을 따로 표시한다. 이벤트는 검색과 집계에 강하다.

상태 스냅샷은 그 시점의 작업대 사진이다. 현재 컨텍스트, 작업 상태, 선택된 문서, 메모리 읽기 결과, 중간 산출물, 남은 예산 같은 것을 저장한다. 나중에 보면 "왜 여기서 그런 판단을 했는지"를 이해하는 데 큰 도움이 된다.

이 넷은 경쟁 관계가 아니다. 로그는 디테일을, 트레이스는 흐름을, 이벤트는 분기점을, 상태 스냅샷은 맥락을 맡는다. 에이전트를 제대로 보려면 네 가지가 함께 필요하다.

가장 먼저 설계해야 할 것: 한 요청을 하나의 실행 단위로 묶는 방법

관측 가능성의 출발점은 대단한 대시보드가 아니다. 한 번의 사용자 요청을 하나의 실행 단위로 식별하는 것이다. 보통은 trace_id 같은 공통 식별자를 두고, 그 아래에 모든 로그·이벤트·스팬을 연결한다.

이 식별자가 없으면 어떤 일이 벌어질까. 모델 호출 로그는 따로 있고, 툴 서버 로그는 따로 있고, 승인 시스템 로그는 또 따로 있다. 문제 한 건을 보려면 세 군데를 오가며 시간을 맞춰 봐야 한다. 이건 디버깅이 아니라 유물 발굴이다.

반대로 trace가 잘 연결되어 있으면 한 실행을 열었을 때 다음이 한눈에 보여야 한다. 처음 입력, 계획 단계, 검색 단계, 각 도구 호출, 중간 결과, 최종 응답, 그리고 각 단계의 시간·토큰·비용이다.¹ 이것이 관측 가능성의 기본 화면이다.

트레이스는 "어디서 시간이 갔는가"보다 "어디서 판단이 갈렸는가"를 보여줘야 한다

분산 추적은 원래 마이크로서비스 세계에서 많이 쓰였다. 에이전트에서도 매우 유용하지만, 보는 포인트가 조금 다르다. 단순히 어느 함수가 느렸는지만 보면 절반만 본 것이다.

에이전트 트레이스에서 더 중요한 것은 판단 경로다. 어떤 질문에서 바로 답하지 않고 검색을 택했는지, 왜 특정 도구를 골랐는지, 왜 다른 에이전트로 일을 넘겼는지, 왜 재시도했는지가 보여야 한다. 그래야 "성능은 괜찮은데 이상하게 자꾸 틀린다" 같은 문제를 잡을 수 있다.³

실무적으로는 이런 구조가 유용하다.

• 루트 span: 사용자 요청 하나 전체

• 하위 span: 모델 호출, 검색, 도구 실행, 승인 대기, 하위 에이전트 호출

• 각 span 속성: 모델명, 도구명, 입력 크기, 출력 크기, 상태 코드, 토큰 수, 비용, 버전 정보

• 보조 이벤트: 경로 선택, 정책 판정, 재시도, 중단 이유

특히 멀티에이전트에서는 trace 문맥이 에이전트 간에 이어져야 한다. 기획 에이전트가 실행 에이전트에게 일을 넘기고, 실행 에이전트가 다시 검토 에이전트를 부르는 구조라면, 이것이 각각 따로 찍히면 안 된다. 하나의 사용자 요청 트리로 연결되어야 진짜 원인을 따라갈 수 있다.¹⁴

로그는 사람이 읽기 위한 문장이 아니라 기계가 분석할 수 있는 레코드여야 한다

초기에는 print("tool call failed") 같은 로그로도 버틸 수 있다. 하지만 운영 단계에서는 금방 한계가 온다. 로그가 많아질수록, 자유문장 로그는 오히려 찾기 어려운 잡음이 된다.

그래서 에이전트 로그는 가능하면 구조화된 JSON 형태로 설계하는 편이 좋다.⁵ 핵심은 모든 중요한 필드를 명시적으로 남기는 것이다. 예를 들면 이런 식이다.

• 공통 필드: trace_id, span_id, agent_id, agent_version, session_id, user_id, environment

• 모델 호출 필드: model, prompt_hash, tokens_in, tokens_out, latency_ms, decision_type

• 도구 호출 필드: tool_name, tool_args, tool_status, retry_count, latency_ms

• 안전 관련 필드: policy_name, policy_version, approval_required, blocked_reason

• 결과 필드: final_status, cost_usd, steps, handoff_count

이렇게 해 두면 "어제 프로덕션에서 특정 버전의 에이전트가 CRM 쓰기 권한 요청을 몇 번이나 했는가" 같은 질문을 바로 던질 수 있다. 자유문장 로그만 있으면 이런 질문은 사실상 불가능하다.

무엇을 로그로 남기고, 무엇을 남기지 말아야 하는가

많이 남긴다고 무조건 좋은 것은 아니다. 로그는 정보이기도 하지만 위험이기도 하다. 민감한 데이터를 무심코 저장하면 디버깅 도구가 곧 보안 사고 저장소가 된다.

기본 원칙은 단순하다. 원인을 찾는 데 필요한 정보는 남기고, 원문 전체는 가능한 한 줄이거나 가린다. 일부 실무 가이드는 span 속성에는 입력과 출력의 앞부분만 잘라 넣고, 전체 페이로드는 별도 저장소에 제한적으로 보관하라고 권한다.⁵

예를 들어 고객 이메일 본문 전체를 모든 로그에 그대로 남길 필요는 없다. 대신 길이, 해시, 주요 분류 태그, PII 마스킹된 미리보기, 관련 문서 ID 정도면 충분한 경우가 많다. 필요할 때만 원문을 재생할 수 있도록 분리 보관하면 된다.

여기서 중요한 것은 "관측 가능성"과 "무차별 수집"을 같은 말로 착각하지 않는 것이다. 잘 설계된 시스템은 더 적게 저장하면서도 더 많이 설명한다.

이벤트는 운영자가 붙잡아야 할 순간을 드러낸다

모든 것을 트레이스에서만 찾으려 하면 금방 피곤해진다. 그래서 이벤트가 필요하다. 이벤트는 중요한 순간을 따로 표시해 주는 징검다리다.

에이전트 시스템에서 특히 유용한 이벤트는 다음과 같다.

• 사용자 요청 접수

• 계획 수립 완료

• 도구 선택

• 도구 실패 및 재시도

• 권한 상승 요청

• 승인 대기 시작과 종료

• 가드레일 차단

• 하위 에이전트 핸드오프

• 종료 조건 충족

• 시간 초과 또는 강제 중단

이벤트가 잘 설계되면 운영자가 전체 시스템을 거칠게 훑을 수 있다. 예를 들어 "오늘 guardrail_blocked 이벤트가 특정 배포 이후 급증했다"면 보안 규칙이 잘 잡히고 있는지, 아니면 정상 작업까지 과하게 막는지 바로 조사할 수 있다.

이벤트는 일종의 심전도 같다. 모든 세부를 읽지 않아도, 이상 박동이 어디서 시작됐는지는 빨리 보여 준다.

상태 스냅샷은 "그때 에이전트가 무엇을 알고 있었는가"를 보존한다

많은 팀이 로그와 트레이스는 남기지만 상태 스냅샷은 놓친다. 그런데 에이전트의 실제 문제는 종종 이 지점에서 드러난다. 도구 호출 자체는 성공했는데, 그 전에 잘못된 컨텍스트를 들고 있었던 경우가 많기 때문이다.

상태 스냅샷에는 보통 이런 것이 들어간다.

• 현재 작업 목표와 하위 작업 목록

• 최근에 읽은 문서 ID와 선택 이유

• 메모리에서 불러온 항목 요약

• 현재 작업 디렉터리, 관련 파일 목록, 변경 예정 파일

• 남은 토큰 예산, 남은 시간 예산, 남은 재시도 횟수

• 사용자 승인 대기 상태와 이유

이 정보가 있으면 나중에 "왜 그 파일을 수정했나?"라는 질문에 답하기 쉬워진다. 당시 스냅샷을 보면 에이전트가 참조한 파일 목록이 잘못되어 있었는지, 오래된 문서를 최신 문서로 착각했는지, 이미 실패한 계획을 계속 끌고 갔는지가 드러난다.

상태 스냅샷은 특히 긴 작업에서 중요하다. 짧은 대화는 머릿속으로 따라갈 수 있지만, 수십 단계가 넘어가는 작업은 중간 상태가 남지 않으면 사실상 이해가 불가능하다.

무엇을 메트릭으로 올릴 것인가: 한 건의 이야기에서 전체 시스템의 건강으로

트레이스와 로그가 개별 사건의 현미경이라면, 메트릭은 시스템 전체의 체온계다. 운영자는 모든 실행을 하나씩 읽을 수 없기 때문에, 집계된 숫자로 이상 징후를 먼저 봐야 한다.

에이전트에서 특히 기본이 되는 메트릭은 다음과 같다.¹⁵

• 요청 지연 시간: p50, p95, p99

• 요청당 총 토큰 수

• 요청당 총 비용

• 요청당 단계 수

• 도구 성공률과 실패율

• 모델 오류율

• 재시도율

• 승인 대기 시간

• 하위 에이전트 핸드오프 횟수

• 일별 또는 시간별 누적 비용

이 숫자들은 단순해 보이지만 매우 강력하다. 예를 들어 성공률은 그대로인데 p95 지연 시간이 갑자기 늘었다면, 느린 도구나 승인 병목이 생겼을 가능성이 크다. 비용이 뛰었는데 오류율은 그대로라면, 루프가 길어졌거나 컨텍스트가 비대해졌을 수 있다. 단계 수 평균이 올라갔다면 에이전트가 쓸데없이 맴돌고 있을 가능성이 있다.

즉, 메트릭은 "문제가 있다"를 알려 주고, 트레이스는 "문제가 여기 있다"를 알려 준다. 둘 중 하나만 있으면 반쪽짜리다.³

비용, 시간, 토큰은 에이전트 운영의 삼각 계기판이다

에이전트는 일반 서비스보다 비용 변동성이 크다. 같은 기능이라도 어떤 실행은 모델 호출 한 번으로 끝나고, 어떤 실행은 검색 두 번, 요약 한 번, 재시도 세 번을 거쳐 끝난다. 그래서 평균값만 보면 자주 속는다.¹⁶

운영 관점에서는 세 가지를 함께 봐야 한다.

첫째는 시간이다. 사용자는 느린 에이전트를 금방 불신한다.

둘째는 토큰이다. 토큰은 길이이자 복잡도의 신호다. 갑자기 입력 토큰이 급증하면 컨텍스트 패키징이 비대해졌을 수 있다.

셋째는 비용이다. 같은 토큰이라도 모델에 따라 가격이 다르므로, 어떤 모델 경로를 탔는지도 함께 봐야 한다.

특히 중요한 것은 요청 단위의 비용 귀속이다. 전체 월 청구서만 봐서는 아무것도 최적화할 수 없다. 어느 에이전트가, 어느 모델을, 어느 작업에서, 얼마만큼 쓰는지를 요청 단위로 연결해야 한다.⁷ 그래야 "비용이 많이 나간다"가 아니라 "리서치 에이전트의 두 번째 검색 이후 요약 단계가 과도하게 비싸다"처럼 고칠 수 있는 문장으로 바뀐다.

대시보드는 세 종류가 있어야 한다

많은 팀이 대시보드를 하나만 만들고 끝낸다. 하지만 에이전트 운영에서는 보는 사람과 질문이 다르다. 그래서 보통 세 종류의 화면이 필요하다.

첫 번째는 운영 대시보드다. 요청 수, 성공률, p95 시간, 도구 실패율, 비용 추이처럼 지금 시스템이 건강한지 보는 화면이다.

두 번째는 트레이스 탐색 화면이다. 특정 실행 한 건을 열어 단계별 흐름, 입력·출력, 도구 인자, 에러, 상태 스냅샷을 보는 화면이다. 사용자 신고가 들어오면 이 화면으로 내려온다.

세 번째는 비용·효율 대시보드다. 에이전트별 비용, 모델별 비용, 사용자군별 사용량, 단계당 토큰, 캐시 적중률, 승인 대기 시간처럼 최적화와 운영 정책을 위한 화면이다.³⁷

이 셋을 한 화면에 다 우겨 넣으면 결국 아무도 못 본다. 현장에서는 "지금 위험한가", "왜 그랬는가", "어디를 줄일 수 있는가"가 서로 다른 질문이기 때문이다.

경고는 에러만 잡아서는 안 된다

전통적인 시스템은 주로 장애를 경고한다. CPU 급등, 500 에러 급등, DB 연결 실패 같은 것들이다. 에이전트에서는 이것만으로 부족하다. 에이전트의 문제는 종종 품질 저하나 이상 행동의 형태로 나타나기 때문이다.⁶

예를 들어 이런 경고는 꽤 유용하다.

• 특정 도구 실패율이 평소보다 3배 상승

• 평균 단계 수가 기준선보다 급증

• 요청당 토큰이 비정상적으로 증가

• 승인 대기 시간이 임계값 초과

• 가드레일 차단 이벤트가 특정 버전에서 급증

• 단일 요청의 비용이 상한선 초과

• trace 누락 비율이 증가

여기서 핵심은 고정 임계값만 믿지 않는 것이다. 에이전트 시스템은 워낙 변동성이 커서, 평소 패턴에서 벗어나는 이상 탐지가 더 유용한 경우가 많다.⁶ 어제까지 평균 4단계였는데 오늘 갑자기 7단계가 되었다면, 절대값이 허용 범위 안이어도 조사할 가치가 있다.

멀티에이전트에서는 관측 가능성이 곧 아키텍처 문서가 된다

에이전트가 하나일 때도 관측 가능성은 중요하지만, 여러 에이전트가 협업하면 중요성이 급격히 커진다. 문제의 시작점과 겉으로 드러난 증상이 멀리 떨어져 있기 때문이다.

기획 에이전트가 애매한 작업 분해를 해 놓고, 실행 에이전트가 그걸 충실히 따랐고, 마지막 검토 에이전트가 표면상 매끈하게 정리해 버리면, 최종 출력만 보고는 어디서 잘못됐는지 모른다. 이런 구조에서는 핸드오프마다 trace 문맥, 역할, 입력 요약, 출력 요약, 책임 범위를 남겨야 한다.¹⁴

좋은 멀티에이전트 관측 화면은 "누가 무슨 일을 맡았고, 어디서 제어권이 넘어갔는가"를 보여 준다. 이것이 없으면 멀티에이전트는 협업 시스템이 아니라 책임 회피 시스템이 된다.

관측 가능성 데이터에도 이름 규칙이 필요하다

에이전트 시스템이 커질수록 의외로 중요한 것이 이름이다. 같은 뜻의 span과 필드가 팀마다 다르면, 나중에 쿼리도 비교도 어려워진다. 그래서 관측 가능성에도 어휘 통일이 필요하다.

예를 들면 tool_call, tool_execution, invoke_tool를 혼용하지 말고 하나로 정해야 한다. agent_name, agent_id, assistant_id도 마찬가지다. OpenTelemetry 기반 생태계가 점점 중요해지는 이유도 여기에 있다. 모델 호출, 에이전트 실행, 도구 실행을 일정한 의미 체계로 기록하면 프레임워크가 달라도 같은 질문을 던지기 쉬워진다.¹²

이건 사소한 취향 문제가 아니다. 이름이 흔들리면 대시보드가 흔들리고, 대시보드가 흔들리면 운영 판단이 흔들린다.

관측 가능성은 평가와 어떻게 연결되는가

앞 장에서 평가 하네스를 다뤘으니, 여기서는 짧게만 짚자. 평가가 "잘했는가"를 묻는다면, 관측 가능성은 "무슨 일이 있었는가"를 묻는다. 둘은 다르지만, 함께 있을 때 강해진다.

예를 들어 어떤 응답이 낮은 품질 점수를 받았다고 하자. 그 점수만 있으면 아쉽다는 사실만 안다. 하지만 그 점수가 특정 trace와 연결되어 있으면, 검색 문서가 낡았는지, 도구 인자가 틀렸는지, 승인 없이 위험 작업을 시도했는지까지 볼 수 있다.¹⁶

즉, 평가는 성적표이고 관측 가능성은 CCTV다. 성적표만으로는 원인을 못 찾고, CCTV만으로는 전체 성과를 모른다. 제품 수준의 에이전트에는 둘 다 필요하다.

작은 팀은 어디서부터 시작해야 하는가

처음부터 거대한 관측 플랫폼을 깔 필요는 없다. 오히려 너무 크게 시작하면 로그 저장비만 늘고 정작 아무도 보지 않는다. 작은 팀이라면 순서를 이렇게 잡는 편이 현실적이다.

먼저 모든 실행에 trace_id를 붙인다. 그다음 모델 호출과 도구 호출을 구조화 로그로 남긴다. 이어서 요청당 시간, 토큰, 비용, 단계 수를 메트릭으로 올린다. 그 뒤 중요한 이벤트를 정의하고, 마지막으로 상태 스냅샷과 대시보드를 붙인다.

즉, 시작점은 화려한 시각화가 아니라 일관된 식별자와 구조화된 기록이다. 이 두 가지만 제대로 해도 디버깅 난이도가 크게 떨어진다.³⁵

이미 기존 관측 스택이 있다면 OpenTelemetry 같은 표준 경로를 활용해 서비스 관측과 에이전트 관측을 한 파이프라인으로 모으는 것이 좋다.²⁴ 그러면 브라우저 클릭부터 API 요청, 에이전트 실행, 도구 호출, DB 반영까지 한 흐름에서 볼 수 있다. 에이전트만 따로 떼어 보면 오히려 실제 원인을 놓칠 수 있다.

운영 가능한 에이전트 대시보드는 무엇을 보여줘야 하는가

좋은 대시보드는 예쁜 그래프가 아니라 행동을 바꾸는 화면이다. 운영자가 화면을 보고 바로 판단할 수 있어야 한다.

운영 첫 화면에서는 적어도 다음 질문에 답할 수 있으면 좋다.

• 지금 실패가 늘고 있는가

• 어느 도구가 병목인가

• 어느 에이전트가 비용을 가장 많이 쓰는가

• 어떤 배포 이후 이상 징후가 시작됐는가

• 사람 승인 대기는 어디서 길어지는가

• 어떤 사용자군 또는 기능군에서 문제 비율이 높은가

여기에 trace drill-down이 연결되어야 한다. 즉, 그래프에서 튄 점 하나를 눌렀을 때 그 시간대의 실제 실행 목록으로 내려가고, 거기서 다시 개별 trace를 열 수 있어야 한다. 그래야 대시보드가 전광판이 아니라 조종석이 된다.

관측 가능성 없는 자동화는 빠른 실패를 숨기는 자동화다

AI 에이전트의 위험한 점은 실패가 조용할 수 있다는 것이다. 전통적 시스템은 주로 크게 고장 난다. 에러 코드가 뜨고, 요청이 터지고, 모니터링 알람이 울린다.

반면 에이전트는 멀쩡해 보이는 얼굴로 잘못된 일을 할 수 있다. 그래서 관측 가능성은 선택 기능이 아니라 기본 안전장치다. 문제가 생겼을 때 원인을 찾기 위해서만 필요한 것이 아니다. 애초에 신뢰를 형성하기 위해 필요하다.

팀이 에이전트를 믿으려면 "얘가 가끔 잘한다"가 아니라 "얘가 무슨 일을 했는지 항상 추적할 수 있다"는 확신이 있어야 한다. 사용자가 에이전트를 믿으려면 "틀릴 수는 있어도, 틀렸을 때 어디서 잘못됐는지 팀이 알 수 있다"는 운영 능력이 있어야 한다.

좋은 관측 가능성은 에이전트를 더 똑똑하게 만들지는 않는다. 하지만 에이전트를 덜 깜깜하게 만든다. 그리고 운영에서 그 차이는 아주 크다. 깜깜한 천재보다, 보이는 전문가가 더 믿을 만하다.

다음 장에서는 한 걸음 더 나아가, 이렇게 보이게 만든 시스템이 실패했을 때 어떻게 멈추고, 되돌리고, 복구할 것인지 살펴본다. 관측 가능성이 눈이라면, 다음 장의 안전장치와 복구 설계는 브레이크와 소화기에 가깝다.

참고

¹AI Agent Observability: Key Concepts, Challenges & Best Practices

²AI agent observability: The developer's guide to agent monitoring

³AI Agent Observability: Tracing, Testing, and Improving Agents

⁴Operating AI Agents on Azure: Observability with Azure AI Foundry

⁵AI Agent Observability: Tracing, Logging & Debugging in Production (2026 Guide)

⁶AI Agent Observability: Tracing, Logging, and Alerting at Scale

⁷Tracking Every Token: Granular Cost and Usage Metrics for Microsoft Foundry Agents