Agent observability

Agent observability는 AI agent가 실제 업무를 수행할 때 무슨 입력을 받았고, 어떤 도구를 호출했고, 어디서 실패했고, 비용과 지연 시간이 어디서 발생했는지 볼 수 있게 만드는 운영 능력이다. 모델이 똑똑해지는 것과 별개로, agent를 기업 시스템에 넣으려면 관찰 가능성이 제품의 핵심 기능이 된다.

한 줄로 말하면

Agent observability는 AI agent의 실행 과정, 도구 호출, 권한 실패, 로그, 지연 시간, 비용, 오류를 추적해 운영자가 문제를 발견하고 고칠 수 있게 만드는 능력이다.

비유로 이해하기

사람 직원이 일을 하면 결과물만 보는 것으로는 부족할 때가 있다. 어떤 자료를 보고 판단했는지, 누구에게 승인받았는지, 어떤 시스템에 접속했는지, 어디서 막혔는지를 알아야 문제가 생겼을 때 바로 고칠 수 있다.

AI agent도 비슷하다. “답이 맞다/틀리다”만 보면 원인을 찾기 어렵다. agent가 잘못된 문서를 읽었는지, 권한이 없어서 실패했는지, 외부 API가 늦었는지, tool call을 반복했는지, 오래된 memory를 확정 사실처럼 썼는지 볼 수 있어야 한다.

비유의 한계도 있다. 사람의 업무 기록은 대개 문서와 승인 흐름에 남지만, AI agent는 모델 호출, tool call, sandbox 실행, retrieval, memory, external API, policy check가 빠르게 섞인다. 그래서 agent observability는 일반 로그보다 더 구조적인 trace가 필요하다.

정확한 정의

Agent observability는 장기 실행 AI agent의 내부 실행 상태와 외부 부작용을 추적하는 운영 체계다. 일반적인 소프트웨어 관찰 가능성처럼 logs, metrics, traces를 쓰지만, AI agent에서는 다음 항목이 특히 중요하다.

항목	무엇을 보나
입력과 context	사용자 요청, 검색 결과, memory, 참조 문서
tool call trace	어떤 도구를 어떤 순서로 호출했는지
권한과 승인	어떤 credential, sandbox, policy boundary가 적용됐는지
오류와 재시도	실패 원인, retry, timeout, fallback
비용과 지연 시간	모델 호출, 도구 호출, session 처리량, 대기 시간
출력 근거	최종 답이 어떤 문서와 실행 결과에 근거했는지

이 개념은 AI 시스템의 감사 가능성과 가깝지만 완전히 같지는 않다. Observability는 “지금 시스템이 어떻게 움직이는가”를 보는 운영 능력이고, auditability는 “나중에 책임 있게 재구성하고 설명할 수 있는가”까지 포함한다.

왜 중요한가

1. Agent는 일반 API 호출보다 실패 경로가 많다

짧은 채팅 답변은 실패해도 다시 물어보면 끝날 수 있다. 하지만 agent가 파일을 수정하고, 고객 티켓을 처리하고, ERP·CRM·클라우드 도구를 호출하면 실패 경로가 훨씬 많아진다.

권한이 부족해서 실패할 수도 있고, 잘못된 tool을 호출할 수도 있고, 같은 작업을 중복 실행할 수도 있고, 외부 API rate limit에 걸릴 수도 있다. 이런 실패를 보지 못하면 agent는 데모 단계에서 멈춘다.

2. 기업 도입에서는 운영팀과 보안팀이 납득해야 한다

기업 고객은 “모델이 대체로 잘한다”만으로 핵심 업무를 맡기기 어렵다. 장애가 났을 때 누가 알림을 받고, 어떤 로그를 보고, 어떤 권한을 회수하고, 어떤 답변을 고객에게 설명할 수 있는지 알아야 한다.

AWS AgentCore와 Assurance Assistant source watch에서 CloudWatch 로그 쿼리 기반 alarm과 compliance citation 기능을 함께 본 이유가 여기에 있다. agent runtime이 커질수록 운영·보안·감사 기능이 주변 기능이 아니라 채택 조건이 된다.

3. 비용과 scale도 관찰해야 한다

Agent observability는 안전만의 문제가 아니다. 동시 session, 초당 interaction, tool call latency, retry 횟수, context 크기, token 비용을 보지 못하면 서비스를 경제적으로 운영하기 어렵다.

Managed agents 구조에서 session, sandbox, credential, tool interface를 나누는 것도 관찰 가능성과 연결된다. 무엇이 어디서 실행되는지 분리되어 있어야 지연 시간과 실패 원인을 나눠 볼 수 있기 때문이다.

실제 예시

기업용 agent가 보안 문서를 읽고 고객사의 vendor questionnaire에 답한다고 해보자.

관찰 가능성이 약한 시스템에서는 최종 답만 남는다. 답이 틀렸을 때 어떤 SOC report를 봤는지, 오래된 ISO 문서를 썼는지, 사용자가 업로드한 질문 파일을 제대로 파싱했는지 알기 어렵다.

관찰 가능성이 있는 시스템에서는 다음을 볼 수 있다.

1. 어떤 질문 파일이 입력됐는지.
2. 어떤 compliance documentation을 검색했는지.
3. 어떤 citation을 근거로 답변했는지.
4. 어느 질문에서 confidence가 낮았는지.
5. 어떤 권한으로 문서에 접근했는지.
6. 처리 시간과 실패율이 어느 단계에서 높았는지.

이 정보가 있어야 보안팀은 답변을 검토할 수 있고, 제품팀은 병목을 고칠 수 있으며, 고객사는 AI가 만든 답을 무조건 믿지 않고 확인할 수 있다.

헷갈리지 말아야 할 점

• Agent observability는 로그를 많이 쌓는 것과 다르다. 필요한 사건을 나중에 이해할 수 있는 구조로 남겨야 한다.
• Observability가 있다고 해서 agent가 안전하다는 뜻은 아니다. 관찰은 통제의 재료이고, 권한 제한과 승인 경계는 별도 설계가 필요하다.
• Auditability와도 다르다. 관찰 가능성은 운영 상태를 보는 능력이고, 감사 가능성은 책임·근거·재검증까지 포함한다.
• 모델 benchmark가 높아도 observability가 약하면 기업 환경에서는 adoption이 느려질 수 있다.

관련 문서

• AWS AgentCore와 Assurance Assistant로 보는 기업용 AI agent 운영 신호
• Managed agents
• Agent containment
• Cost per token
• AI 시스템의 감사 가능성
• AI agent runtime과 AI capex cycle의 차이