FactStack

AI 에이전트 관측 가능성AI Agent Observability

engineering

한마디로

AI 에이전트가 어떤 입력을 받아 어떤 도구를 불러 어떤 결과를 냈는지 기록해 되짚어 볼 수 있게 하는 일이에요. 기록이 있어야 사고가 났을 때 원인 조사를 시작할 수 있어서, 일을 맡기기 전에 먼저 갖출 안전장치예요

관측 가능성(observability)은 원래 서버와 앱 운영에서 로그, 지표, 추적(trace) 세 가지로 시스템 안을 들여다보는 개념이에요. AI 에이전트에 오면 볼 것이 늘어납니다. 어떤 프롬프트와 문맥이 들어갔는지, 어떤 도구(검색, 데이터 조회, 광고 API)를 어떤 인자로 불렀는지, 몇 번 다시 시도했는지, 토큰과 비용이 얼마였는지, 그리고 최종 답이 어떤 순서로 나왔는지까지 한 줄로 이어 볼 수 있어야 해요. 다만 이 기록은 입력과 출력과 도구 호출을 남기는 것이지 모델 안의 추론을 복원해 주지는 않아서, 원인 조사를 돕지만 원인 규명을 보장하지는 않아요. MIT 테크놀로지 리뷰는 2026년 10월 29일 글에서 지금은 이런 도구를 사실상 눈을 가린 채 배포하고 있다며, 에이전트가 무엇을 했고 왜 그랬는지 알 수 있도록 실시간 모니터링과 관측 가능성 확보가 시급하다고 썼어요.

표준화도 진행 중입니다. OpenTelemetry는 생성형 AI 시맨틱 컨벤션(GenAI semantic conventions)에서 에이전트 전용 작업 이름(create_agent, invoke_agent, execute_tool 같은 스팬)과 평가 결과를 붙이는 이벤트를 정의하고 있어요. 이 규약은 2026년 11월 8일 확인 기준으로 아직 개발(Development) 단계이고, 프롬프트와 응답 본문을 기록할지는 옵트인(opt-in)으로 두었어요. 무엇을 저장하고 얼마나 보관하고 누가 볼 수 있게 할지는 표준이 아니라 운영자의 데이터 거버넌스 결정이라는 뜻이에요. 참고: GenAI 규약은 2026년 들어 별도 저장소(github.com/open-telemetry/semantic-conventions-genai)로 옮겨 갔으니 그 저장소의 docs/gen-ai에서 최신 상태를 확인하세요.

마케터에게는 두 가지 쓸모가 있어요. 첫째, 광고 운영이나 리포트 작성을 에이전트에 맡길 때 비용 상한과 실패 알림의 근거가 되는 것이 이 기록입니다. 예산을 넘긴 캠페인이 있으면 어떤 호출에서 넘겼는지 추적 기록으로 찾을 수 있어야 하고, 그게 안 되면 맡기지 않는 편이 안전해요. 둘째, 벤더가 '에이전트 관측 가능성을 지원한다'고 할 때 무엇을 뜻하는지 물어볼 수 있어요. 도구 호출 기록이 남는지, 비용이 작업 단위로 집계되는지, 기록을 우리 쪽 저장소로 내보낼 수 있는지가 확인 질문이에요.

헷갈리는 용어 구분

태그

관련 용어

공유