에이전트 관측성 (Agent Observability)

에이전트 관측성(Agent Observability)은 AI 에이전트의 모델 호출, 검색, 도구 실행과 그 결과를 기록해 작업이 어떻게 진행됐는지 파악하는 능력입니다. 최종 답변만으로 알기 어려운 지연, 반복 호출, 실패 지점을 찾아 운영과 개선에 필요한 근거를 제공합니다.

최종 답변 뒤의 실행 과정을 본다

일반 챗봇의 응답 시간도 중요하지만, 여러 도구를 사용하는 에이전트에서는 시간이 걸린 이유가 더 다양합니다. 모델이 오래 응답했을 수도 있고, 검색 서버가 느렸거나 실패한 도구를 반복 호출했을 수도 있습니다. 최종 답변과 전체 소요 시간만 저장하면 이 차이를 구분하기 어렵습니다. 에이전트 하네스가 관리하는 실행 단계마다 시작과 종료, 호출 대상, 성공 여부를 남겨야 어느 부분을 고칠지 판단할 수 있습니다.

예를 들어 고객 질문 하나를 처리하는 데 30초가 걸렸다고 가정해 보겠습니다. 그중 모델 응답이 5초이고 자료 검색이 25초였다면 검색 경로부터 살펴볼 근거가 생깁니다. 반대로 검색은 빠르지만 같은 질문을 다시 보내는 과정이 길었다면 반복 조건과 도구 응답을 확인해야 합니다. 이 수치는 설명을 위한 예시이며 특정 제품의 측정 결과는 아닙니다. 중요한 것은 총시간을 실제 작업 단계와 연결해 보는 것입니다.

실행 추적인 트레이스는 한 요청에서 이어진 작업의 흐름을 보여줍니다. 그 안의 개별 작업 구간을 스팬이라고 부르며, 모델 호출이나 도구 실행 하나가 스팬에 해당할 수 있습니다. 로그는 특정 시점에 일어난 사건을 기록하고, 메트릭은 요청 수나 지연 시간처럼 여러 실행을 집계한 수치를 보여줍니다. OpenTelemetry의 생성형 AI 관측 안내도 모델 호출과 도구 실행을 연결해 보고 토큰 사용량과 지연을 살펴보는 방식을 설명합니다.

검색, 모델 호출, 외부 서비스가 서로 다른 프로그램에서 실행되면 각자의 로그만으로는 같은 요청인지 알기 어려울 수 있습니다. OpenTelemetry의 컨텍스트 전파 설명은 추적 식별자를 서비스 사이에 전달해 관련 작업을 연결하는 방식을 다룹니다. 여기서 컨텍스트는 관측 데이터를 연결하기 위한 정보입니다. 언어 모델에 넣는 문맥이나 컨텍스트 윈도우와는 의미가 다르므로, 모델에 넣는 입력과 구분해 읽어야 합니다.

실행 성공과 답변 품질을 구분한다

모델 이름, 도구 이름, 호출 순서, 소요 시간, 오류 종류를 알면 많은 운영 문제의 범위를 좁힐 수 있습니다. 토큰 사용량은 비용 변화를 살피는 단서가 됩니다. 다만 같은 토큰 수라도 모델과 입력·출력 구분, 캐시 적용, 과금 조건에 따라 금액이 달라질 수 있으므로 토큰 수를 고정 단가와 무조건 곱해서 실제 청구액으로 취급하면 안 됩니다. 기록한 사용량과 제공자의 청구 내역을 구분해 읽어야 합니다.

검색 증강 생성에서는 어떤 자료를 검색했고 그 자료가 최종 응답에 어떻게 연결됐는지도 중요합니다. 자료가 없어 답하지 못한 것인지, 자료는 찾았는데 잘못 해석한 것인지에 따라 수정할 부분이 달라집니다. 내용을 전부 저장하기 어렵다면 문서 식별자나 버전, 검색 결과 수처럼 필요한 단서부터 남기는 방법을 검토할 수 있습니다. 이때 기록의 상세 수준은 해결하려는 문제와 데이터의 성격에 맞춰 정합니다.

모든 도구 호출이 정상 종료됐다는 기록만으로 답변의 정확성을 보장할 수는 없습니다. 잘못된 문서를 검색하고도 기술적으로는 성공한 요청으로 남을 수 있기 때문입니다. Anthropic의 에이전트 평가 안내는 실행 과정과 최종 결과를 함께 평가하는 관점을 설명합니다. 관측 데이터가 문제의 위치를 찾는 재료라면, 평가는 결과가 과제의 성공 기준을 만족했는지 판단하는 과정입니다. 둘은 함께 쓰일 때 도움이 됩니다.

관측 기록이 모델 내부의 사고 과정을 그대로 보여주는 것도 아닙니다. 기록 가능한 도구 호출과 반환값, 공개된 출력 등을 보고 실행을 재구성하는 것입니다. 모델이 남긴 설명은 실제 도구 결과와 다를 수 있고, 일부 구간이 기록되지 않았다면 원인을 확정하기 어려울 수 있습니다. 특히 실패한 사례 몇 개만 보고 전체 실패율을 계산하거나, 수집이 빠진 구간을 문제가 없었던 구간으로 처리하지 않도록 주의해야 합니다.

필요한 정보부터 수집한다

대화와 도구 인자를 모두 저장하면 디버깅에 도움이 될 때도 있지만, 그 안에 고객 정보나 인증 값이 섞일 수 있습니다. OpenTelemetry의 민감 정보 처리 안내는 관측 목적에 필요한 데이터만 수집하고 불필요한 개인 정보를 피하도록 권합니다. 자동 계측 기능을 켰다면 해당 라이브러리가 실제로 어떤 항목을 내보내는지도 확인해야 합니다. 수집 도구가 업무상의 민감도를 자동으로 판단해 주지는 않습니다.

처음에는 모델과 도구의 이름, 지연, 오류, 사용량처럼 대화 본문을 담지 않는 정보부터 수집할 수 있습니다. 문제가 재현되지 않아 상세 내용이 필요할 때 수집 범위를 넓히고, 외부로 보내기 전에 인증 값과 불필요한 본문을 제거하는 방식을 검토합니다. OpenTelemetry의 생성형 AI 안내에서도 프롬프트와 도구 인자 같은 내용 수집은 별도 선택 항목으로 다룹니다. 보관 기간과 열람 범위도 기록의 목적에 맞춰 정하는 편이 좋습니다.

관측성을 갖춘 시스템에서는 “에이전트가 느리다”는 인상을 어느 단계가 얼마나 오래 걸렸는지에 대한 질문으로 바꿀 수 있습니다. 모델을 바꾸기 전에 검색 오류를 고치거나, 반복 호출의 원인을 찾거나, 답변 품질을 평가할 실패 사례를 고르는 데 도움이 됩니다. 수집 항목이 많다는 사실보다, 실제 문제를 설명할 만큼 연결된 기록을 남겼는지가 관측성의 쓸모를 결정합니다.