에이전트가 느리거나 잘못된 행동을 했는데 최종 답변 로그만 남아 있습니다. 어떤 trace와 지표가 필요한가요?

사용자 목표에서 모델 호출·도구 실행·승인·외부 작업·결과 검증까지 연결되는 실행 이력이 필요합니다. 최종 답변만 있으면 잘못된 계획인지 도구 실패인지 관찰 오해인지 구분하기 어렵습니다. 작업 ID와 호출 ID, 상태 전이, 버전·지연·사용량·정책 결정을 기록하되 민감한 프롬프트 원문과 내부 추론을 무제한 수집하지 않겠습니다.

지연과 실패를 구간별로 나눕니다

모델 응답 대기, 도구 검색, 네트워크 호출, 승인 대기, sandbox 시작, 실제 계산·검증을 구간으로 분리합니다. 하위 에이전트를 사용하면 부모·자식 작업을 연결해 가장 느린 경로와 중복 조사를 찾습니다. HTTP 성공이나 모델 응답 완료가 전체 과제 성공은 아니므로 최종 outcome과 검증 결과도 연결해야 합니다. 재시도는 논리 작업과 물리 시도를 나눠야 실제 비용과 중복 효과를 해석할 수 있습니다.

도구별 인자 오류·권한 거절·timeout·불확정 결과와 모델의 다음 행동을 기록합니다. 안전 정책이 차단한 것을 모델의 무능력으로만 세거나, 도구 실패를 모두 모델 실패에서 제외하면 배포 품질을 왜곡할 수 있습니다. 원인 분류와 사용자에게 미친 결과를 별도 축으로 둡니다. 버전 변경 전후 비교에는 모델·프롬프트·도구 스키마·harness 설정이 필요합니다.

감사와 개인정보의 균형

원문을 전부 남기면 토큰·비밀번호·개인정보·사내 문서가 관측 저장소로 복제됩니다. 기본 로그는 메타데이터와 최소 결과 요약을 사용하고, 상세 원문 수집은 목적·접근권한·보관기간·마스킹을 정합니다. 내부 추론 전문을 요구하기보다 호출 인자·관찰·정책 판단과 간결한 결정 요약을 기록하면 실행을 추적할 수 있습니다. 인자 자체도 민감할 수 있으므로 필드별 비노출이 필요합니다.

지표 라벨에 사용자 ID·전체 프롬프트·작업 ID를 모두 넣으면 카디널리티가 폭증합니다. 집계에는 과제 유형·도구·오류 클래스·버전처럼 제한된 값을 쓰고 개별 추적은 로그·trace로 연결합니다. 샘플링 때문에 드문 안전 위반을 놓치지 않도록 중요 이벤트는 별도 보존 정책을 둡니다. 평가에서는 로그로 실패를 재현할 수 있는지와 로그가 새로운 유출·지연 원인이 되지 않는지를 함께 확인하겠습니다.

실행 사례로 확인합니다

승인 대기가 10분인 작업과 모델 추론이 10분 걸린 작업은 같은 지연 개선 대상이 아닙니다. 사용자 대기와 계산 시간을 나누고, 승인 후 실제 실행까지의 지연도 별도로 봅니다. 이벤트 시간은 분산 서버의 벽시계만으로 정렬하지 않고 부모·자식 ID와 단계 순서를 함께 사용합니다. trace가 일부 유실되면 없는 사건을 미실행으로 단정하지 않고 관측 공백을 표시합니다. 로그 sink 장애가 실행을 막지 않도록 일반 진단과 필수 감사 기록의 내구성 정책을 분리합니다. 최종 결과를 실제 저장소와 대조할 수 있는 식별자는 유지하되 민감한 내용은 최소화하는 것이 재현성과 개인정보 보호를 함께 만족시키는 방향입니다.