당신은 실제로 무엇을 측정하고 있습니까? 에이전트 관측 가능성 (Agent Observability)을 위한 프레임워크.

"우리는 에이전트를 보유하고 있다"에서 "우리는 프로덕션(production)에서 에이전트를 실행하고 있다"로 넘어가는 팀들로부터 제가 받는 질문은 대개 다음과 같습니다: "이것이 잘 작동하고 있는지 어떻게 알 수 있나요?"

이것은 보기보다 어려운 질문입니다. 에이전트는 전통적인 소프트웨어가 실패하는 방식과는 다르게 실패합니다. 에이전트는 충돌(crash)하지 않습니다. 에러 코드(error codes)를 반환하지도 않습니다. 대신 잘못된 방식으로 성공하거나, 검증하기 어려운 방식으로 성공하거나, 혹은 너무 느리게 성공하여 유용하지 않게 됩니다.

다음은 제가 에이전트 관측 가능성 (Agent Observability)을 생각하기 위해 정립한 프레임워크입니다.

세 가지 실패 모드 (The Three Failure Modes)

무엇인가를 측정하기 전에, 당신이 실제로 무엇을 지켜보고 있는지 정의하십시오. 에이전트는 세 가지 뚜렷한 방식으로 실패합니다:

1. 능력 실패 (Capability failure) — 에이전트가 해당 일을 할 수 없는 경우입니다. 작업을 완료하기 위한 지식, 도구 접근 권한(tool access), 또는 추론 능력(reasoning capacity)이 부족합니다. 이는 다음과 같은 형태로 나타납니다: 에이전트가 포기하거나, 도움을 요청하거나, 혹은 스스로 확신하는 듯한 잘못된 출력(output)을 생성합니다.

2. 신뢰성 실패 (Reliability failure) — 에이전트가 그 일을 할 수는 있지만, 일관되게 수행하지 못하는 경우입니다. 80%의 확률로는 작동하지만, 나머지 20%에서는 "약간 틀린" 것부터 "완전히 틀린" 것에 이르는 출력을 생성합니다. 이것이 프로덕션 환경에서 에이전트를 신뢰하기 어렵게 만드는 실패 모드입니다.

3. 지연 실패 (Latency failure) — 에이전트가 일을 정확하게 수행할 수는 있지만, 시간이 너무 오래 걸려 출력이 더 이상 유용하지 않은 경우입니다. 이는 하나의 느린 도구 호출(tool call)이 전체 워크플로(workflow)의 하한선을 결정해 버리는 멀티 도구 워크플로(multi-tool workflows)에서 특히 흔하게 발생합니다.

실제로 측정해야 할 것

각 실패 모드에 대해 제가 추적하는 항목은 다음과 같습니다:

능력 (Capability):

• 작업 유형별 작업 완료율 (Task completion rate)
• "도와드릴 수 없습니다"라는 응답 대 확신에 찬 오답의 빈도
• 도구 호출 성공률 (에이전트가 접근 권한을 가진 도구들을 성공적으로 호출하는가?)

신뢰성 (Reliability):

• 동일한 반복 작업에 대한 출력 일관성 (Output consistency) — 동일한 프롬프트가 동일한 출력을 생성하는가?
• 워크플로 단계별 오류율 (Error rate) — 워크플로의 어느 단계에서 가장 빈번하게 실패하는가?
• 세션 간 문맥 유지 (Context retention) — 에이전트가 이전 세션의 관련 문맥을 기억하는가?

지연 시간 (Latency):

• 첫 번째 도구 호출 시간 (Time to first tool call, TTFC) — 에이전트가 얼마나 빨리 행동을 시작하는가?
• 도구 호출 그래프 지속 시간 (Tool call graph duration) — 워크플로 내 모든 도구 호출에 소요되는 총 시간
• 작업 유형별 엔드 투 엔드 (End-to-end) 작업 지속 시간

내가 실제로 확인하는 실질적인 지표

내가 발견한 가장 유용한 단일 지표는 바로 문맥 복잡도(Context complexity)별 작업 완료율입니다.

이를 그래프로 그려보면 에이전트의 신뢰할 수 있는 능력의 경계선을 찾을 수 있습니다. 복잡도가 X 미만인 작업은 Y%의 비율로 완료됩니다. 복잡도가 X를 초과하면 완료율이 Z%로 떨어집니다.

그 경계선은 어디에 문맥을 추가해야 할지, 어디에서 워크플로를 분리해야 할지, 그리고 어디에서 에이전트에게 인간의 검토가 필요함을 그냥 받아들여야 할지를 알려줍니다.

OpenClaw 전용 관측 가능성 스택 (Observability Stack)

특히 OpenClaw의 경우, 저는 다음을 사용합니다:

# 작업 완료 패턴을 확인하기 위해 세션 기록을 체크합니다
openclaw sessions history --limit 50 --format json | jq '.[] | {task: .summary, outcome: .outcome, duration: .duration}'

...

크론(cron) 실행 로그는 과소평가되어 있습니다. 이 로그는 자동화를 구동하는 격리된 에이전트 실행이 성공하고 있는지, 실패하고 있는지, 그리고 그 이유가 무엇인지를 알려줍니다.

인간의 검토를 추가해야 하는 시점

관측 가능성 데이터는 인간의 검토가 필요한 지점을 알려줍니다. 제가 사용하는 규칙은 다음과 같습니다: 특정 작업 유형에 대한 에이전트의 오류율이 5%를 초과하면 인간의 검토 단계를 추가합니다. 오류율이 1% 미만이면 사람이 개입하지 않고 실행하도록 둡니다.

1~5% 사이의 경우에는 샘플링을 추가합니다. 출력물의 10%를 무작위로 검토하고, 샘플 내 오류율이 3%를 넘으면 알람을 울립니다.

에이전트 관측 가능성(Agent observability)은 대시보드에 관한 것이 아닙니다. 에이전트가 정확히 어느 부분에서 신뢰할 수 있고, 어느 부분에서 지원이 필요한지를 아는 것에 관한 것입니다.