Grafana Cloud로 Gemini 에이전트를 관측할 때 먼저 볼 것들 | DAKER 커뮤니티

에이전트를 다듬는 일은 종종 프롬프트 한 줄을 고치는 데서 시작하지만, 실제 운영에서는 다른 문제가 먼저 드러납니다. 사용자가 늘어나면 응답을 하나씩 읽어 보며 원인을 찾는 방식이 금세 한계에 닿기 때문입니다.

이번 글은 Google Cloud Tech 영상에서 Grafana Labs가 Gemini 에이전트를 Grafana Cloud로 관측하는 방법을 짚고, 같은 날 바로 따라 해 볼 수 있는 최소 실험으로 옮긴 기록입니다. 초점은 프롬프트 수정 습관이 아니라, 프로덕션에서 도구 호출과 품질을 숫자와 기록으로 보는 관측 루프에 있습니다.

하나씩 읽지 않습니다 썸네일

참고 영상은 Google Cloud Tech 채널의 How to monitor & optimize Google Gemini agents with Grafana Cloud입니다. 채널 주소는 @googlecloudtech입니다. yt-dlp 기준 게시일은 2026년 9월 3일입니다. 길이는 442초입니다. oEmbed 기준 제목은 How to monitor & optimize Google Gemini agents with Grafana Cloud입니다. 영상 설명의 Grafana 소개 링크는 g.dev/ai/grafana이고, Gemini 소개 링크는 g.dev/ai/about-gemini입니다. 데모에서 쓰는 프레임워크의 문서 출발점은 Google Agent Development Kit입니다.

야간 관측 책상과 모니터

영상이 짚는 문제는 왜 운영에서 커지는가

영상 진행자는 Grafana Labs의 Shawn Pitts입니다. 자동 자막에는 Sean Pits로도 표기되며, 이 글에서는 영상 자막 표기를 따릅니다. 데모 에이전트는 Google Agent Development Kit 위에서 Gemini로 동작하는 금융 도우미입니다. 사용자가 이번 달 순저축을 물으면, 에이전트가 의도를 나누고 필요한 도구를 호출한 뒤 답을 만듭니다. 진행자는 이것을 전통적인 LLM 워크플로라고 설명합니다.

로컬에서는 프롬프트를 보내고 답을 읽은 뒤 시스템 프롬프트 마크다운을 고쳐 보는 방식이 가능합니다. 하지만 생산 환경에서는 상황이 달라집니다. 수백 명, 수천 명의 사용자가 동시에 요청을 보내면 모든 프롬프트를 하나씩 읽을 수 없다는 점이 영상의 출발점입니다.

프로덕션에서는 에이전트의 도구 호출과 응답 품질을 사람이 하나씩 읽는 대신 기록과 지표로 봐야 합니다.

Sigil 래퍼와 문서의 agento11y

영상은 Grafana Cloud의 AI 관측을 위해 Grafana Sigil SDK로 Gemini 에이전트를 계측하는 흐름을 보여 줍니다. 진행자는 Sigil을 OpenTelemetry 기반 계층이라고 설명하며, 도구 호출과 결정, 응답을 일어나는 대로 남긴다고 말합니다.

Cursor 화면에서 보여 주는 코드는 크게 세 부분입니다. 첫째는 Grafana Cloud 엔드포인트, 인스턴스 ID, API 키를 담은 클라이언트 설정입니다. 둘째는 생성 구간을 감싸 Sigil에 문맥을 주고, 끝나면 추적과 지표를 기록하는 부분입니다. 셋째는 도구를 start_tool_execution으로 감싸 호출 이름, 입력, 출력, 소요 시간을 남기는 부분입니다. 진행자는 에이전트 논리를 바꾸지 않고 가벼운 래퍼만 더했다고 설명합니다.

공식 문서에서는 이 제품군의 이름이 정리되어 있습니다. Grafana의 AI Observability, 별칭 Sigil은 Grafana Agent Observability로 이름이 바뀌고 있습니다. SDK 패키지 이름은 sigil-sdk에서 agento11y로 바뀌며, Gemini 도우미는 agento11y-gemini, Google ADK 연동은 agento11y-google-adk입니다. API 동작은 같고, 이전 이름과 SIGIL_* 환경 변수는 전환 기간에도 동작한다고 문서가 적고 있습니다. 이전 이름 종료 시점은 문서 기준 10월 말입니다.

출처는 What's new 이름 변경 안내, sigil-sdk에서 agento11y로 이전, Instrument Python agents, Configure the Agent Observability SDK, 저장소 grafana/agento11y입니다.

문서가 적는 최소 확인 순서도 분명합니다. Agent Observability가 켜진 Grafana Cloud 스택, 내보내기 엔드포인트, Cloud Access Policy 토큰이 필요합니다. Python 3.10 이상에서 패키지를 설치하고, 생성 한 번을 기록한 뒤, Agent Observability의 Conversations에서 몇 초 안에 보이는지 확인하면 됩니다. 또 TracerProvider와 MeterProvider를 애플리케이션에서 먼저 두지 않으면 추적과 지표가 조용히 사라질 수 있다고 문서가 설명합니다.

Grafana Cloud에서 실제로 무엇을 보게 되는가

Grafana Cloud로 옮긴 뒤 진행자는 Overview 탭을 엽니다. 여기서 요청 수, 평균 지연, 첫 토큰까지의 시간, 사용량, 최근 대화를 바로 볼 수 있다고 말합니다. 이어서 Performance 탭에서는 지연과 긴 대화를 나눠 보고, Errors 탭에서는 시간별 오류와 대화 속 오류를 확인합니다. Usage 탭에서는 토큰 유형별 추이와 토큰을 많이 쓴 대화를 볼 수 있으며, 진행자는 특히 이 목록을 자주 본다고 설명합니다.

가장 실질적으로 유용한 지점으로는 Tools 탭을 꼽습니다. 각 도구 호출에서 무엇을 불렀는지, 입력과 출력이 무엇이었는지, 얼마나 시간이 걸렸는지를 검사할 수 있기 때문입니다. 도구 호출은 대화와 연결되어 있어 특정 도구를 연 뒤 관련 대화로 바로 들어갈 수 있다고 말합니다. 대화 안에서는 사용자 프롬프트, 어시스턴트 응답, 분류가 보입니다.

영상에서는 빨간 표시와 초록 표시가 평가에서 온다고 설명합니다. Grafana Cloud에서 AI 판정자를 두어 응답 품질을 점수 매기고, 나쁜 출력이 나오면 알림을 보낼 수 있다는 내용입니다. 다만 이 평가는 영상 속 데모 설명이며, 이 글에서는 이를 제품의 일반 성공률 수치로 옮기지 않습니다.

운영에서 바로 도움이 되는 화면은 대화 목록보다 도구 호출의 입력, 출력, 소요 시간을 한 번에 이어서 볼 수 있는 지점입니다.

Slack에서 조사하고 개선 루프를 닫는 방식

진행자는 조사를 매번 손으로 하고 싶지 않다고 말합니다. 그래서 채널에 Grafana Slack 앱을 두고, Grafana를 태그해 에이전트를 조사하고 개선점을 제안해 달라고 요청합니다. 영상에서는 어시스턴트가 스킬과 에이전트 문서를 찾고, 인프라에서 에이전트를 찾고, Grafana Cloud로 들어오는 데이터 소스를 모아 상관 분석을 하는 흐름을 보여 줍니다.

돌아온 분석에는 속도 제한 소진, 토큰 팽창, Gemini 2.5 Pro 지연이 예시로 나옵니다. 이 세 항목은 영상 데모 결과이며, 모든 Gemini 에이전트의 공통 수치로 볼 수는 없습니다.

같은 Slack 스레드에서 Claude를 태그하고, 앞선 조사를 바탕으로 구현 계획을 만들어 달라고 요청하는 장면도 이어집니다. 진행자는 이 흐름을 관측, 분석, 개선, 반복이라고 설명합니다. 텔레메트리는 Sigil 계층을 통해 들어가고, Slack의 Grafana 어시스턴트가 조사하며, Claude가 시스템 프롬프트나 에이전트 코드를 고치는 쪽으로 루프를 닫는다는 설명입니다. 다만 Claude 연동의 세부 설정 화면은 영상에 길게 나오지 않으므로, 이 글에서도 없는 설정을 덧붙이지 않습니다.

문서가 적는 지표 이름

SDK 설정 문서는 OpenTelemetry 지표 이름을 구체적으로 적고 있습니다. gen_ai.client.operation.duration은 호출 시간이고, gen_ai.client.token.usage는 토큰 사용량입니다. gen_ai.client.time_to_first_token은 스트리밍에서 첫 토큰까지의 시간이며, gen_ai.client.tool_calls_per_operation은 생성당 도구 호출 수입니다.

마이그레이션 문서는 이 gen_ai.* 지표와 속성은 이름 변경의 영향을 받지 않는다고 설명합니다. 반면 Sigil 전용 라벨과 평가·가드 점수 지표만 agento11y.*로 바꿔야 한다고 적고 있습니다. 출처는 Configure the Agent Observability SDK와 sigil-sdk에서 agento11y로 이전입니다.

ADK 문서는 ADK를 프로덕션 에이전트를 만드는 오픈소스 프레임워크로 소개합니다. Python, TypeScript, Go, Java, Kotlin을 지원한다고 적고 있으며, Google Cloud의 Agent Runtime, Cloud Run, GKE로 배포할 때 관리형 인프라와 Cloud Trace 관측을 받는다고 설명합니다. 다만 오늘 실험의 중심은 ADK 배포 자체가 아니라, 로컬 또는 이미 떠 있는 Gemini 에이전트에 Agent Observability 기록을 붙이는 일입니다. 전체 가이드는 ADK 문서를 따르면 됩니다.

같은 날 해 볼 수 있는 최소 실험

가장 단순한 출발점은 로컬에서 돌리는 Gemini 또는 Google ADK 에이전트 하나를 고르는 일입니다. 금융 도우미일 필요는 없습니다. 도구를 두 개 이상 호출하는 요청 한 건이면 충분합니다.

그다음 문서 기준으로 agento11y와 필요한 제공자 패키지를 설치하면 됩니다. Gemini만 쓰면 agento11y-gemini를, ADK를 쓰면 agento11y-google-adk를 보면 됩니다. 영상 코드가 아직 Sigil 이름을 쓰고 있다면, 마이그레이션 문서의 표대로 패키지 이름만 바꿔 읽으면 됩니다. API 키와 엔드포인트는 로그에 남기지 않는 것이 좋습니다.

이후 생성 구간과 도구 호출에 래퍼를 두고, OpenTelemetry TracerProvider와 MeterProvider를 애플리케이션 시작 시점에 둡니다. 요청 한 번을 보낸 뒤 Grafana Cloud Agent Observability의 Conversations에 기록이 생기는지 확인하면 됩니다.

다음으로 Tools 탭에서 방금 호출한 도구의 입력, 출력, 소요 시간을 열어 봅니다. 평가 규칙을 당장 전부 쓰지 않아도 됩니다. 오늘의 목표는 도구 한 건이 대화와 연결되어 보이는지 확인하는 데 있습니다.

팀이 Slack을 쓴다면 Grafana Slack 앱으로 같은 에이전트를 조사해 달라고 한 번 요청해 볼 수 있습니다. 돌아온 요약을 읽고, 고칠 항목이 있으면 Claude 또는 사용 중인 코딩 에이전트에 구현 계획만 맡기면 됩니다. 배포 전에 사람이 계획을 확인하는 흐름이 적절합니다.

참고 자료

영상 주소는 https://www.youtube.com/watch?v=RJSRBzryPQs입니다. Grafana Agent Observability Python 안내는 https://grafana.com/docs/grafana-cloud/observe-and-act/agent-observability/get-started/python/입니다. Sigil에서 agento11y로 옮기는 안내는 https://grafana.com/docs/grafana-cloud/observe-and-act/agent-observability/guides/migrate-sigil-sdk-to-agento11y/입니다. Google ADK 문서는 https://google.github.io/adk-docs/입니다.

지금 운영 중인 에이전트에서 가장 먼저 관측해 보고 싶은 지점은 응답 자체인가요, 아니면 도구 호출의 흐름인가요?