AI agent가 tool을 호출했는지 확인하려고 trace나 digest를 본다.
로그에 없으면 이렇게 말하기 쉽다.
“이 tool은 호출되지 않았다.”
하지만 이 문장은 관측 시스템이 완전하다는 전제를 깔고 있다.
실제로는 호출됐지만 현재 instrumentation이 기록하지 않았을 가능성이 있다.
1. Observability도 필터다
어떤 telemetry는 모든 event를 기록하지 않는다.
특정 metadata가 있어야 기록하거나, 특정 tool category만 수집할 수 있다.
그렇다면 다음 두 문장은 완전히 다르다.
Tool was not executed.
Tool was not observed.첫 번째는 실행 사실에 대한 주장이고, 두 번째는 계측 범위에 대한 주장이다.
2. 하나의 trace를 절대 진실로 취급하지 않는다
AI agent pipeline은 대략 여러 계층을 가진다.
LLM decision
tool registry
tool invocation
transport
server log
business result
telemetry
UI event한 계층이 비어 있어도 다른 계층에는 흔적이 남아 있을 수 있다. 그래서 어느 한 곳에 기록이 없다는 것만으로 실행 자체가 없었다고 결론내리면 위험하다. 최소 두 개 이상의 독립된 관측 지점을 교차 확인하고 나서 판단한다.
3. Instrumentation 자체에 control을 둔다
좋은 방법은 known invocation 하나를 만드는 것이다.
반드시 호출될 test tool 실행
↓
telemetry에 기록되는지 확인이 known control이 잡히지 않으면 현재 telemetry는 신뢰할 수 없다.
그 상태에서 다른 tool의 “미호출”을 주장하면 안 된다.
4. 장애 분석 문장도 바꿔야 한다
나쁜 표현:
Tool A가 호출되지 않았다.
더 정확한 표현:
현재 telemetry에서는 Tool A 호출을 관측하지 못했다.
이 차이는 작아 보이지만 이후 디버깅 방향을 크게 바꾼다.
Correlation ID가 중요한 이유
Agent가 여러 tool을 연속 호출하면 로그를 시간순으로만 맞추기 어려워진다. 가능하면 session id, request id, tool call id 같은 correlation key를 남겨야 한다.
session_id
request_id
tool_call_id
parent_call_id이 정보가 있으면 LLM의 결정부터 backend 결과까지 하나의 흐름으로 묶을 수 있다.
관측 누락의 흔한 원인
metadata filter
category filter
sampling
async event delay
UI rendering omission
schema mismatch
trace truncation따라서 “로그에 없다”는 사실만으로 실행 자체가 없었다고 주장하지 않는다.
실무 체크리스트
[ ] telemetry 대상 event 정의
[ ] known invocation control 준비
[ ] agent trace와 server log 교차 확인
[ ] correlation id 사용
[ ] not observed / not executed 표현 구분
[ ] instrumentation failure 상태 별도 기록결론
Observability는 시스템 자체가 아니라 시스템을 보는 렌즈다.
렌즈에 blind spot이 있다면 실제로 일어난 일을 “없었다”고 판단할 수 있다.
그래서 장애 분석에서는 항상 한 번 더 물어야 한다.
이벤트가 없었던 것인가, 아니면 내 계측기가 기록하지 않는 것인가?