Agent 운영과 Observability

일반 API는 요청 하나가 성공하거나 명시적인 오류로 끝나는 경우가 많지만 agent는 여러 tool 중 일부만 성공한 뒤 중단될 수 있습니다. Ticket은 생성됐는데 사용자 알림이 실패하거나, 환불은 처리됐는데 model이 실패로 판단해 다시 요청할 수 있습니다. Task state machine과 operation identity가 없으면 대화 transcript만으로 실제 업무 결과를 복구하기 어렵습니다.

Model response, retrieval, policy와 tool revision은 독립적으로 바뀌므로 실행마다 이 조합을 기록해야 합니다. 같은 prompt인데 결과가 달라졌다는 보고만으로는 원인을 좁힐 수 없습니다. 부분 성공, approval 거절, budget 종료와 human handoff를 서로 다른 terminal state로 정의하고 사용자에게 다음 조치를 보여 주는 것이 production agent의 기본 오류 계약입니다.

Trace는 한 run에서 model call과 tool이 어떤 순서로 얼마나 걸렸는지 보여 주고, metric은 많은 run의 성공률과 latency 분포를 비교하며, log는 특정 policy decision의 상세 이유를 담습니다. 세 signal은 대체 관계가 아닙니다. 공통 run ID와 revision attribute가 있어야 metric의 이상 구간에서 representative trace와 관련 log로 내려갈 수 있습니다.

모든 prompt와 tool output을 attribute에 넣으면 high cardinality와 개인정보 노출이 동시에 발생합니다. Operation 이름과 model, policy version처럼 bounded value는 telemetry에 두고 큰 원문은 접근 통제된 evidence store에 별도 보관하며 hash로 연결합니다. Sampling 정책도 오류와 고위험 행동은 보존하고 정상 대량 요청은 비율로 줄이는 식으로 질문에 맞게 설계합니다.

Agent의 총 latency는 model 한 번의 응답 시간이 아니라 retrieval, 여러 tool, retry와 approval 대기를 합친 결과입니다. Token 가격이 낮은 model도 잘못된 tool을 반복해 성공률이 낮으면 성공 한 건당 비용이 더 클 수 있습니다. Task 유형별 성공률, step 수, input과 output token, 외부 API 비용과 P95 시간을 같은 run에서 계산해야 합니다.

최적화는 먼저 불필요한 context와 중복 tool output을 줄이고, 독립 호출을 안전하게 병렬화하며, 반복되는 안정적 결과만 cache하는 순서로 검토할 수 있습니다. Cache에는 source revision과 권한을 key로 포함해야 합니다. Budget을 넘겼을 때는 답을 꾸며내지 않고 작은 model로 degrade할지, 일부 기능을 생략할지, 사람에게 넘길지 제품 계약에 따라 결정합니다.

Offline eval set은 실제 사용자 분포의 정상 case만 모으지 않고 경계 입력, 권한 거절, prompt injection, tool timeout과 recovery를 포함해야 합니다. 각 case에는 기대 업무 state와 citation, 허용하지 않을 행동을 적고 deterministic check와 rubric을 조합합니다. Dataset revision을 고정해야 release 후보를 같은 조건에서 비교할 수 있습니다.

LLM judge는 많은 답을 빠르게 평가할 수 있지만 표현 선호, model family와 rubric 해석에 bias가 있습니다. 전문가가 합의한 pass와 fail 표본으로 judge를 calibration하고 disagreement를 사람이 검토해야 합니다. Online에서는 correction, escalation과 policy violation을 slice별로 보며 안전-critical 실패는 평균 점수가 높아도 release를 막는 hard gate로 둡니다.

감사 event는 자연어 대화 전체보다 실행의 책임 사슬을 구조화해야 합니다. Actor, tenant, tool과 policy revision, approval, target의 비식별 identity, idempotency key와 결과를 연결하면 누가 어떤 권한으로 어떤 state를 바꿨는지 재구성할 수 있습니다. Event 자체의 수정과 삭제 권한도 제한하고 보존 기간을 data 목적에 맞춰야 합니다.

사고 대응에는 model 호출을 멈추는 것뿐 아니라 특정 tool이나 tenant capability를 즉시 차단하는 kill switch, credential revoke와 영향 operation 검색이 필요합니다. 이미 성공한 행동은 rollback이 불가능할 수 있으므로 compensating action과 사용자 통지를 준비합니다. 복구 뒤 같은 abuse case와 대표 task를 실행해 기능과 안전 경계가 함께 돌아왔는지 확인해야 종료할 수 있습니다.

교육용 요약 작업은 접수 뒤 대기열에서 기다리고 모델 호출 후 파일을 저장합니다. 첫 작업자가 파일 저장 뒤 확인 응답 전에 종료되면 메시지가 다시 전달될 수 있습니다. 두 번째 작업의 trace만 보면 사용자가 새 요청을 보낸 것으로 오해할 수 있습니다. 접수 기록과 두 시도의 입력 해시를 대조하면 동일 업무의 재전달인지 다른 요청인지 구분합니다.

업무 식별자 하나에 첫 시도와 재시도를 연결하고 파일 확정 상태를 조회합니다. 이미 확정됐다면 새 모델 호출 없이 기존 결과를 반환하는 경로를 기록합니다. 이렇게 해야 재시도 비용 감소가 결과 누락을 숨긴 것은 아닌지 설명할 수 있습니다. 기존 파일의 존재만 확인하지 말고 해당 업무의 입력과 연결된 확정 결과인지 함께 확인합니다.

반례는 모든 시도가 같은 span 식별자를 재사용하는 구현입니다. 서로 다른 실행 시간이 한 작업처럼 섞여 순서와 중복을 구분하기 어렵습니다. 상관관계는 공유하되 각 시도의 시작·종료·실패는 별도 사건으로 남깁니다. 시도별 오류와 최종 업무 상태를 함께 보아야 첫 실패 뒤 성공한 재처리를 원래 성공과 구분합니다.

검증에서는 파일 확정 직후 종료를 주입하고 재전달 경로를 추적합니다. 한 업무에 시도 두 개가 보이되 사용자 결과는 하나여야 합니다. 큐 대기와 모델 호출 시간을 분리해 어느 구간이 전체 지연을 늘렸는지도 확인합니다. 비용 집계에는 첫 시도의 모델 호출도 포함해 사용자 결과 하나에 실제 사용한 자원을 누락하지 않습니다.

교육용 비교에서 이전 후보는 시작 100건 중 성공 90건과 실패 10건입니다. 새 후보는 성공 90건과 대기 10건인데 완료된 90건만 집계하면 성공률이 100%처럼 보입니다. 시작 집단을 기준으로 보면 즉시 확인된 성공은 두 후보 모두 90건입니다. 새 후보가 더 좋다는 판단은 대기 작업의 결과와 지연 조건을 확인하기 전에는 보류해야 합니다.

대기 10건의 상태는 정해 둔 관찰 시점에 다시 확인합니다. 완료 시간 약속을 넘겼다면 나중에 성공해도 지연 위반 기록은 유지합니다. 사용자에게 늦게 전달된 결과를 즉시 성공과 같은 경험으로 취급하지 않습니다. 확정 성공 집계와 제시간 성공 집계를 분리하면 뒤늦은 성공이 시간 약속 위반을 지우지 않습니다.

반례는 취소를 모두 실패로 처리해 취소 기능 자체를 나쁜 성능으로 보는 지표입니다. 사용자가 자발적으로 중단한 작업과 시스템이 포기로 몰아간 작업은 다를 수 있습니다. 취소 이유를 구분할 근거가 없으면 미확인으로 남기고 원인을 추정하지 않습니다. 취소 발생 시각과 직전 대기 상태는 추측 없이 추가로 수집할 수 있는 진단 자료입니다.

검증 표에서 시작 수가 각 상태의 합과 맞는지 확인합니다. 누락된 식별자는 로그 누락인지 집계 오류인지 조사합니다. 동일한 집단 정의와 관찰 시간을 적용한 뒤에만 두 후보의 성공률과 비용을 비교합니다. 집계에서 제외한 항목이 있다면 이유와 건수를 남겨 분모가 바뀐 사실을 검토자가 확인하게 합니다.

교육용 일정 보조자가 검토만 요청받은 초안을 실제 초대로 발송했다고 가정합니다. 재현 환경에서는 초대 도구를 발송하지 않는 기록용 대역으로 바꿉니다. 제안된 수신자와 실행 여부를 보존하면 실제 메일 없이도 잘못된 경계를 관찰할 수 있습니다. 기록용 대역이 네트워크 발송을 하지 않는지는 환경 설정뿐 아니라 실제 실행 기록으로 확인합니다.

수정 후보는 검토 요청을 초안 결과로 끝내고 발송 승인이 없으면 도구 실행을 거절해야 합니다. 같은 입력에서 제안이 달라졌는지와 실행이 차단됐는지를 따로 기록합니다. 모델 문구가 좋아진 것과 서버가 상태 변경을 막은 것은 다른 증거입니다. 제안이 다시 잘못 나와도 서버가 차단한다면 모델 수정과 별개로 실행 방어가 작동한 것입니다.

반례는 과거 관리자 토큰을 넣어야 완전한 재현이라는 주장입니다. 조사에 필요한 권한 판정은 제한된 시험 신원으로 재구성할 수 있습니다. 실제 자격증명이 필요한 연결 검증이 있다면 원인 재현과 분리된 범위로 관리합니다. 시험 신원의 권한 목록과 거절 사유를 남기면 실제 비밀 없이도 어느 판정 조건을 재현했는지 설명합니다.

최종 기록에는 재현 성공 여부와 실제 외부 변경 0건을 별도 항목으로 남깁니다. 새 정책이 정상 승인 발송까지 막았다면 복구가 끝나지 않은 것입니다. 허용·거절 두 경로의 결과를 확인한 뒤 운영 복귀를 판단합니다. 정상 경로의 발송도 시험용 대상에만 기록해 거절과 허용을 비교하는 동안 외부 영향이 없게 합니다.