AI 에이전트 추적은 일반 API 추적과 무엇이 다른가

일반 HTTP API는 요청 하나가 몇 개의 서비스 span으로 끝나는 경우가 많다. AI 에이전트는 한 요청 안에서 모델이 계획을 세우고, 여러 도구를 호출하고, 결과가 부족하면 모델을 다시 부르는 반복 구조를 가진다. 최종 응답은 성공했어도 중간 검색이 세 번 실패했거나 불필요한 모델 재호출로 비용이 커졌을 수 있다.

OpenAI Agents SDK 공식 문서는 기본 trace가 runner, task, turn, agent, generation, function tool, guardrail, handoff span을 포함한다고 설명한다. 특정 SDK를 쓰지 않더라도 이 계층은 실무 설계의 좋은 기준이 된다. 핵심은 로그 줄을 시간순으로 모으는 것이 아니라 어떤 단계가 어떤 부모 작업에서 파생됐는지 보존하는 데 있다.

먼저 정할 최소 span 구조

처음부터 모든 이벤트를 수집하면 비용과 개인정보 위험만 커진다. 아래 다섯 단계로 시작하면 대부분의 운영 질문에 답할 수 있다. 에이전트가 검색을 쓰지 않으면 retrieval span은 생략하고, 여러 도구를 병렬 실행한다면 같은 부모 아래에 형제 span으로 둔다.

W3C Trace Context의 traceparent를 서비스 경계에서 전달하면 웹 API, 작업 큐, 도구 서버가 같은 분산 trace에 참여할 수 있다. 다만 대화 전체를 하나의 무한히 긴 trace로 만들기보다 사용자 요청 단위 trace와 별도의 가명 session key를 함께 쓰는 편이 조회와 보존에 유리하다.

속성은 표준·조직·민감정보로 나눠 관리한다

OpenTelemetry 공식 사이트의 GenAI 의미 규약 페이지는 2026년 8월 현재 관련 규약이 별도 semantic-conventions-genai 저장소로 이동했다고 안내한다. 새 저장소에는 agent, inference, tool, retrieval 등 span 문서와 참조 시나리오가 있다. 아직 변할 수 있는 이름을 애플리케이션 곳곳에 직접 쓰면 업그레이드 비용이 커진다.

Langfuse 공식 OpenTelemetry 문서도 GenAI 속성 규약이 진화 중이며 수신 OTel trace를 자체 데이터 모델로 매핑한다고 밝힌다. 또한 baggage는 서비스와 외부 API 경계를 따라 전파되므로 비밀번호, API 키, 개인정보를 넣지 말라고 경고한다. 검색 필터 편의를 위해 민감값을 baggage에 넣는 설계는 피해야 한다.

Python에서 최소 추적을 붙이는 순서

다음 코드는 특정 LLM 프레임워크 자동 계측에 기대지 않고 구조를 이해하기 위한 최소 예시다. OpenTelemetry Python 공식 문서의 TracerProvider, BatchSpanProcessor, current span 구조를 따른다. app.* 속성은 이 글의 조직 예시이며 공식 GenAI 속성으로 오해하면 안 된다.

from opentelemetry import trace
from opentelemetry.sdk.trace import TracerProvider
from opentelemetry.sdk.trace.export import BatchSpanProcessor
from opentelemetry.exporter.otlp.proto.http.trace_exporter import OTLPSpanExporter

provider = TracerProvider()
provider.add_span_processor(
    BatchSpanProcessor(OTLPSpanExporter())
)
trace.set_tracer_provider(provider)
tracer = trace.get_tracer("agent-service")

with tracer.start_as_current_span("agent.request") as root:
    root.set_attribute("app.route", "support-agent")

    with tracer.start_as_current_span("agent.model_call") as model_span:
        model_span.set_attribute("app.model", selected_model)
        result = call_model(messages)
        model_span.set_attribute("app.input_tokens", result.input_tokens)
        model_span.set_attribute("app.output_tokens", result.output_tokens)

    with tracer.start_as_current_span("agent.tool_call") as tool_span:
        tool_span.set_attribute("app.tool", "knowledge_search")
        docs = search_knowledge(result.query)

1. 개발 환경에서 console exporter로 구조를 먼저 확인한다. 부모·자식 관계가 끊기지 않는지 본다.
2. OTLP exporter를 Collector 또는 관측 백엔드에 연결한다. 애플리케이션이 각 제품의 전용 전송 코드를 직접 갖지 않게 한다.
3. 모델·도구 wrapper 한 곳에서 속성을 정규화한다. 프레임워크가 바뀌어도 대시보드 키를 유지한다.
4. 오류와 재시도를 이벤트 또는 span 상태로 남긴다. 최종 성공만 기록하면 숨은 실패 비용을 놓친다.
5. 샘플링과 보존 기간을 부하 테스트로 결정한다. trace 자체가 서비스 병목이 되지 않는지 확인한다.

운영 대시보드는 다섯 지표부터 만든다

대시보드에 모든 속성을 올리기보다 장애와 비용 결정을 직접 바꾸는 지표를 먼저 둔다. 아래 경보선은 제품 공식값이 아니라 초기 운영을 위한 예시다. 서비스의 정상 기준선을 수집한 뒤 조정해야 한다.

토큰 단가를 연결할 때는 모델과 컨텍스트 구간, 캐시 읽기·쓰기, Batch 여부에 따라 가격표가 달라질 수 있다. 따라서 span에는 계산된 비용만 남기기보다 provider, model, 입력·출력·캐시 토큰을 보존하고 비용 계산기를 별도 버전으로 관리하는 편이 감사와 재계산에 유리하다.

개인정보와 비용 때문에 실패하는 지점

• 프롬프트 원문 기본 수집: 고객 정보, 소스코드, API 키가 trace 백엔드로 복제될 수 있다. 메타데이터 우선 원칙을 적용한다.
• 모든 span 100% 장기 보존: 트래픽과 도구 호출 수가 늘면 저장·인덱싱 비용이 빠르게 커진다. 정상 요청은 head sampling, 오류·고지연은 tail sampling을 검토한다.
• 비동기 경계의 context 손실: 큐 worker와 병렬 도구 실행에서 부모 context를 전달하지 않으면 trace가 여러 조각으로 갈라진다.
• 속성의 무제한 cardinality: 원문 URL, 사용자 ID, 임의 오류 메시지를 인덱스 필드로 쓰면 조회 비용이 커진다. 정규화한 코드와 제한된 분류를 쓴다.
• 관측 백엔드 실패의 서비스 전파: exporter는 batch와 짧은 timeout을 쓰고, 추적 전송 실패 때문에 사용자 요청까지 실패하지 않게 분리한다.

OpenAI Agents SDK 문서는 추적이 기본 활성화될 수 있고, 전역 환경변수·코드·개별 실행 설정으로 끌 수 있다고 안내한다. 또한 Zero Data Retention 정책을 쓰는 조직에는 해당 trace 기능을 사용할 수 없다고 명시한다. 사용하는 SDK의 기본값과 데이터 정책을 배포 전에 반드시 확인해야 한다.

도입 단계별 체크리스트

이미 개념과 제품 선택부터 정리해야 한다면 AI 에이전트 관측성 가이드와 Langfuse·LangSmith·Phoenix·OpenTelemetry 비교를 먼저 보는 편이 낫다. 비용 분석까지 확장하려면 AI 에이전트 비용 추적 가이드를 함께 연결하면 된다.

FAQ

로그와 trace를 둘 다 남겨야 하나

둘의 역할이 다르다. trace는 요청의 단계와 부모·자식 관계, 지연을 보여주고 로그는 상세 사건과 디버그 문맥을 제공한다. 로그에 trace_id와 span_id를 넣어 상호 이동할 수 있게 만드는 구성이 실용적이다.

프롬프트와 응답을 저장하지 않으면 디버깅이 불가능하지 않나

대부분의 운영 장애는 모델명, 지연, 토큰, 도구 입력의 분류, 상태, 오류 코드만으로도 1차 진단이 가능하다. 원문이 꼭 필요한 평가 환경은 별도 동의, 마스킹, 접근 제어, 짧은 보존 기간을 적용해 분리한다.

OpenTelemetry만 설치하면 AI 비용도 자동으로 계산되나

그렇지 않다. OpenTelemetry는 신호와 context를 수집·전송하는 기반이다. 모델별 단가와 캐시·컨텍스트 구간을 반영한 비용 계산 로직 또는 이를 지원하는 백엔드가 별도로 필요하다.

trace는 요청마다 하나가 좋은가, 대화마다 하나가 좋은가

일반적으로 사용자 요청마다 trace를 만들고 가명 session 또는 thread 키로 여러 trace를 묶는 편이 낫다. 대화 전체를 하나의 장기 trace로 만들면 크기, 시간 제한, 조회가 복잡해진다.

가장 먼저 경보로 만들 지표는 무엇인가

오류율과 요청 p95 지연을 먼저 두고, 모델 호출 횟수와 요청당 토큰을 추가하는 순서가 현실적이다. 도구가 핵심인 서비스라면 도구별 오류·재시도율도 첫 단계에 포함한다.

참고 자료

• OpenTelemetry GenAI Semantic Conventions 저장소
• OpenTelemetry GenAI Agent Spans
• OpenTelemetry Python Instrumentation
• OpenAI Agents SDK Tracing
• Langfuse OpenTelemetry 문서
• W3C Trace Context

문서 확인 기준일은 2026년 8월 24일이다. OpenTelemetry GenAI 의미 규약은 진화 중이므로 실제 적용 전 저장소의 최신 상태와 사용하는 SDK·백엔드의 지원 범위를 다시 확인해야 한다.

The post AI 에이전트 추적 실무: OpenTelemetry로 지연·토큰·도구 호출 연결하기 appeared first on .

RAG 평가는 검색과 답변을 따로 봐야 한다

RAG는 질문, 검색, 컨텍스트 조립, 답변 생성의 연쇄 시스템이다. 정답이 틀렸다는 결과만 기록하면 어느 단계가 고장 났는지 알 수 없다. 검색 결과에 정답 문서가 없었다면 생성 모델을 바꿔도 해결되지 않는다. 반대로 정답 문서가 들어왔는데 답변이 근거를 벗어났다면 검색 튜닝보다 프롬프트·모델·출력 검증을 손봐야 한다.

테스트셋은 정답보다 실패 조건부터 설계한다

처음부터 수천 건을 만들 필요는 없다. 도입 초기는 핵심 업무 질문 50~100건으로 시작하되 질문 유형을 의도적으로 나누는 편이 실용적이다. 단순 사실 조회만 넣으면 실제 서비스의 긴 질문, 모호한 표현, 문서에 답이 없는 질문을 놓친다. 이후 운영 로그에서 실패 사례를 골라 테스트셋을 늘린다.

1. 정답이 한 문서에 있는 질문: 기본 검색 성능을 확인한다.
2. 여러 문서를 조합해야 하는 질문: 다중 근거 회수와 합성을 확인한다.
3. 문서에 답이 없는 질문: 근거 없는 생성 대신 모른다고 답하는지 본다.
4. 날짜·버전이 충돌하는 질문: 최신 문서 우선순위와 메타데이터 필터를 본다.
5. 오탈자·약어·한국어와 영어가 섞인 질문: 실제 입력 변형에 견디는지 본다.
6. 권한 밖 문서를 묻는 질문: 검색 단계에서 접근 제어가 지켜지는지 본다.

각 행에는 질문, 기대 답변, 관련 문서 ID, 반드시 포함할 사실, 허용 가능한 변형, 중요도, 실패 유형을 저장한다. 정답 문서 라벨이 없으면 검색 Recall을 계산할 수 없으므로 최소한 핵심 질문에는 관련 문서 ID를 사람이 붙이는 것이 좋다.

{
  "question": "환불 요청 가능 기간은?",
  "reference_answer": "수령 후 7일 이내",
  "relevant_doc_ids": ["policy-2026-08"],
  "must_include": ["7일"],
  "risk": "high",
  "expected_behavior": "answer_with_citation"
}

검색 품질은 Recall@K 하나로 끝나지 않는다

검색 평가는 관련 문서 라벨이 있을 때 가장 명확하다. Pinecone의 정보검색 평가 설명처럼 Recall@K는 관련 문서를 얼마나 놓치지 않았는지, MRR은 첫 관련 결과가 얼마나 위에 있는지, nDCG는 여러 결과의 관련도와 순서를 함께 본다. 서비스 목적에 따라 우선순위가 달라진다.

실무에서는 Recall@K를 먼저 확보한 뒤 Precision과 지연·토큰 비용을 함께 줄이는 순서가 안전하다. 정답 문서를 못 가져오는 상태에서 컨텍스트를 짧게 만드는 것은 품질 개선이 아니라 근거 삭제가 될 수 있다. 검색 구조 자체를 설계하는 단계라면 GraphRAG와 벡터 검색의 차이도 함께 확인할 수 있다.

답변 평가는 근거성·관련성·정확성을 분리한다

LangSmith 공식 RAG 평가 튜토리얼은 답변과 정답의 정확성, 답변과 질문의 관련성, 답변과 검색 문서의 근거성, 검색 문서와 질문의 관련성을 서로 다른 비교로 정의한다. 이 분리가 중요하다. 근거에는 충실하지만 질문에 답하지 않는 문장도 있고, 그럴듯하고 유용하지만 문서에 없는 사실을 덧붙인 답변도 있기 때문이다.

평가 항목	비교 대상	판정 질문
정확성	생성 답변 기준 답변	필수 사실이 맞고 충돌하는 내용이 없는가
답변 관련성	생성 답변 사용자 질문	질문을 직접 해결하며 불필요하게 벗어나지 않는가
근거성	생성 답변 검색 문서	답변의 주장마다 검색 문서에서 근거를 찾을 수 있는가
검색 관련성	검색 문서 사용자 질문	가져온 문서가 질문 해결에 실제로 필요한가
거절 품질	답변 문서 부재·정책	근거가 없거나 권한이 없을 때 안전하게 중단하는가

Ragas도 Context Precision·Context Recall·Response Relevancy·Faithfulness 같은 RAG 전용 지표를 제공한다. 다만 도구가 내놓은 0~1 점수를 절대적인 품질로 해석하면 안 된다. OpenAI 평가 가이드도 자동 지표를 사람 판단으로 보정하고, 실제 분포를 반영한 과업별 평가를 만들며, 변경 때마다 지속 평가할 것을 권한다.

최소 운영 절차는 7단계면 충분하다

1. 성공 기준을 먼저 쓴다. 예를 들어 핵심 정책 질문은 관련 문서가 상위 5개 안에 있어야 하고, 답변은 문서에 없는 숫자를 만들면 실패로 정의한다.
2. 실제 질문을 유형별로 모은다. 정상·경계·적대·답 없음 질문을 섞는다.
3. 관련 문서와 기준 답변을 라벨링한다. 위험도가 높은 질문부터 사람이 검수한다.
4. 검색기를 단독 실행한다. 답변 모델을 호출하기 전에 Recall@K·MRR·지연을 저장한다.
5. 생성기를 고정된 검색 결과로 평가한다. 검색 변동과 답변 변동을 분리한다.
6. 자동 심사와 사람 판정을 맞춘다. 불일치 사례를 보고 루브릭과 예시를 보완한다.
7. 모든 변경에서 회귀 테스트한다. 임베딩, 청킹, 프롬프트, 모델, 재랭커 변경 전후를 같은 데이터셋으로 비교한다.

평가 결과를 실행 단위 trace와 연결하면 원인 분석이 빨라진다. 검색 결과, 프롬프트 버전, 모델, 토큰, 지연, 평가 점수를 함께 남기는 방법은 AI 에이전트 관측 도구 비교와 AI 에이전트 비용 추적 가이드에서 이어서 볼 수 있다.

점수 조합으로 실패 원인을 좁힌다

비용과 보안도 평가 설계에 포함한다

LLM 심사기를 모든 운영 요청에 붙이면 품질 점검 비용과 지연이 커진다. 배포 전에는 전체 회귀 세트를 돌리고, 운영 중에는 위험도 기반 표본 추출과 실패 감지 후 재평가를 섞는 방식이 현실적이다. 규칙으로 판정 가능한 인용 유무·JSON 스키마·금칙어·문서 ID 일치 여부는 코드 평가기로 처리하고, 의미 판단이 필요한 항목만 LLM 심사기에 맡긴다.

외부 평가 서비스나 심사 모델로 질문·검색 문서·답변을 보내면 개인정보와 사내 문서가 함께 반출될 수 있다. 운영 전 데이터 보존 정책, 학습 사용 여부, 리전, 암호화, 접근 제어를 확인해야 한다. 테스트셋에는 고객 식별자를 가명 처리하고, 권한 필터가 적용된 문서만 평가 파이프라인에 전달한다.

FAQ

정답 데이터가 없어도 RAG 평가를 시작할 수 있나?

가능하다. 질문과 답변의 관련성, 답변과 검색 문서의 근거성, 질문과 검색 문서의 관련성은 기준 답변 없이도 LLM 심사나 사람 검토로 볼 수 있다. 다만 검색 Recall과 최종 정확성을 신뢰성 있게 측정하려면 핵심 질문부터 관련 문서와 기준 답변을 붙여야 한다.

Ragas와 LangSmith 중 무엇을 써야 하나?

Ragas는 코드 중심으로 RAG 지표를 조합하고 자체 파이프라인에 넣을 때 편하다. LangSmith는 데이터셋, 실험 비교, trace와 평가를 관리형 워크플로로 묶고 싶을 때 유리하다. 도구보다 먼저 평가 데이터 스키마와 합격 기준을 정해야 나중에 교체하기 쉽다.

RAG 품질의 합격 점수는 몇 점으로 잡아야 하나?

모든 서비스에 통하는 단일 점수는 없다. 현재 시스템의 기준선을 같은 테스트셋에서 측정하고, 핵심 질문의 실패 허용치와 안전 관련 실패 0건 같은 운영 기준을 먼저 둔다. 평균점수 상승보다 기존 정상 사례를 깨뜨리지 않았는지와 고위험 질문 실패가 줄었는지를 우선한다.

참고자료

• Ragas 공식 문서: RAG 평가 지표 목록
• Ragas 공식 문서: Context Precision
• Ragas 공식 문서: Faithfulness
• LangSmith 공식 문서: Evaluate a RAG application
• OpenAI 공식 문서: Evaluation best practices
• Pinecone: Evaluation Measures in Information Retrieval

자료와 문서 경로는 2026년 8월 19일 확인했다.

The post RAG 평가 실무 가이드: 검색 품질과 답변 품질을 분리하는 법 appeared first on .

핵심 요약: 최상위 trace는 사용자 작업 1건으로 잡고, 그 아래 LLM 호출과 도구 호출을 span으로 기록한다. 모든 trace에 팀·사용자·프로젝트·환경 태그를 붙인다. 비용은 입력·출력·cache read·cache write·reasoning 토큰을 분리해 계산하고, 외부 API와 재시도 비용까지 더한다. 대시보드는 총비용보다 실행당 비용, 성공 실행당 비용, 실패 비용, 캐시 적중률을 먼저 보여줘야 한다.

요청당 비용이 아니라 실행당 총원가를 봐야 한다

일반 챗봇은 사용자 메시지 한 번과 모델 호출 한 번이 비교적 가깝다. AI 에이전트는 한 작업 안에서 계획을 만들고, 여러 모델을 호출하고, 검색·브라우저·데이터베이스·코드 실행 도구를 사용하고, 실패하면 다시 시도한다. 한 번의 사용자 요청이 10개의 LLM 호출과 20개의 도구 호출로 늘어날 수 있다.

따라서 비용의 기본 단위를 HTTP 요청이나 모델 호출로 잡으면 업무 원가를 계산하기 어렵다. 가장 실용적인 단위는 다음 세 단계다.

기존 AI 에이전트 관측성 가이드가 trace 설계와 운영 안전성을 설명했다면, 이 글은 trace에 비용 데이터를 붙여 원가와 예산을 통제하는 방법에 집중한다.

AI 에이전트 총비용 계산식

에이전트 실행 1건의 총비용은 다음 네 항목을 합쳐 계산한다.

실행 총비용 = LLM 비용 + 도구·검색 비용 + 재시도·낭비 비용 + 인프라·관측 비용

1. LLM 비용

LLM 비용도 단순히 전체 입력 토큰에 입력 단가를 곱하면 안 된다.

• 일반 입력 토큰
• cache read 입력 토큰
• cache write 또는 cache creation 토큰
• 출력 토큰
• reasoning 출력 토큰
• 이미지·오디오·영상 입력
• Batch·Priority·Long context 같은 별도 요율

제공자마다 캐시 분류와 과금 방식이 다르므로 input_tokens 하나로 합쳐 저장하면 나중에 정확한 재계산이 어렵다. 모델별 최신 단가와 캐시 차이는 2026년 하반기 LLM 비교에서 확인할 수 있다.

2. 도구·검색 비용

에이전트가 호출하는 외부 도구도 원가에 포함한다.

• 웹 검색 API와 크롤링 서비스
• 지도·번역·OCR·음성 API
• 벡터 데이터베이스 검색·저장
• 브라우저 실행과 샌드박스 컴퓨팅
• 코드 인터프리터·GPU 작업
• 문자·메일·결제·업무 SaaS API

도구가 무료 티어에 들어가더라도 호출 횟수와 사용량은 기록해야 한다. 무료 한도를 넘는 순간 비용 구조가 바뀌고, 공급자가 요금제를 변경했을 때 과거 사용량으로 영향을 계산해야 하기 때문이다.

3. 재시도와 낭비 비용

실패 후 같은 프롬프트를 다시 호출한 비용, 잘못된 도구 인자로 반복 실행한 비용, 종료 조건 없이 루프를 돈 비용은 모델 청구서에는 정상 사용량으로 표시된다. 운영 관점에서는 별도 낭비 비용이다.

다음 값을 구분한다.

• 최초 시도 비용
• 자동 재시도 비용
• 오류 복구 비용
• 사용자 취소 이후 발생한 비용
• 실패로 끝난 실행의 전체 비용
• 평가·검증 모델의 추가 비용

4. 인프라와 관측 비용

자체 호스팅 모델의 GPU 비용뿐 아니라 trace 저장소, 로그, 객체 스토리지, 데이터 웨어하우스와 대시보드 비용도 포함한다. SaaS 관측성 도구가 이벤트 수나 보존 기간에 따라 과금된다면 에이전트 실행 원가에 배부해야 한다.

월 44,000회 실행 비용 계산 예시

다음은 특정 모델 추천이 아니라 계산 구조를 설명하기 위한 가상 단가 예시다.

캐시가 없으면 실행당 LLM 비용은 $0.06, 월 $2,640이다. 입력의 절반이 cache hit라면 실행당 $0.042, 월 $1,848로 내려가 $792, 30%를 절감한다.

하지만 최종 원가는 여기서 끝나지 않는다.

완료 실행 1건당 총원가는 약 $0.054다. 모델 호출비 외 항목은 $529.84로 전체의 약 22.3%다. 모델 공급자 대시보드만 봤다면 이 비용을 제품 원가에서 놓치게 된다.

반드시 기록해야 할 비용 필드

OpenTelemetry의 GenAI semantic conventions는 2026년 7월 기준 별도 semantic-conventions-genai 저장소로 이동했으며 상태가 Development다. 속성명은 바뀔 수 있으므로 버전을 고정하고 변경 이력을 확인해야 한다.

tenant_id, team_id, 가격과 비용 필드는 조직별 custom attribute로 설계할 수 있다. OpenTelemetry 표준 속성과 자체 속성을 구분하고 접두어 규칙을 정해야 한다.

프롬프트·응답 전문을 저장하지 않아도 비용 추적은 가능하다. 개인정보와 소스코드 유출이 우려되면 본문은 마스킹하거나 저장하지 않고 토큰 수, 모델, 도구명, 상태와 비용만 남긴다.

가격표는 호출 시점에 버전으로 저장한다

비용을 조회할 때 현재 가격표를 과거 토큰에 곱하면 안 된다. 모델 가격, 캐시 할인, Long context 기준과 공급자 티어는 바뀐다. 호출 시점에 다음 정보를 함께 저장하는 편이 안전하다.

• 적용한 모델 가격표 버전과 유효일
• 요청 모델과 공급자가 반환한 실제 모델
• Standard·Batch·Priority 같은 요금 티어
• Short·Long context 구간
• cache read·cache write 단가
• 통화와 환율 기준일
• 추정 비용인지 공급자 확정 비용인지

실시간 대시보드는 추정 비용으로 빠르게 보여주고, 하루 한 번 공급자 usage·청구 데이터와 대조해 확정 비용을 보정할 수 있다. 둘 사이 차이는 반올림, 지연 집계, 공유 캐시, 무료 크레딧, 약정 할인과 공급자별 토큰 분류에서 발생한다.

팀·사용자·프로젝트별 비용 배부

배부 태그는 Gateway나 에이전트 진입점에서 강제로 붙여야 한다. 개발자가 각 모델 호출마다 직접 넣게 하면 누락이 생긴다.

권장 배부 계층

1. Tenant 또는 고객사: B2B 서비스의 고객별 원가와 마진
2. Team: 부서·개발팀별 예산
3. Project 또는 기능: 코드 리뷰, 문서 생성, 고객지원 같은 기능별 원가
4. User: 과도한 사용과 교육 필요 사용자 식별
5. Agent·Workflow·Version: 버전 변경 전후 비용 비교
6. Environment: production, staging, eval 비용 분리

예를 들어 같은 고객지원 에이전트라도 refund-agent:v3가 v2보다 성공률은 2% 높지만 실행당 비용이 40% 늘었다면 품질 개선과 원가 상승을 함께 판단할 수 있다. 총 토큰만 보면 이 의사결정이 불가능하다.

AI Gateway를 통과하도록 구성하면 모델 키, 라우팅, 공통 태그와 비용 제한을 한 지점에서 적용하기 쉽다.

도구별 역할: 하나로 모두 해결하려 하지 않는다

선택은 “가장 많은 기능”보다 통제 위치에 따라 달라진다.

• 모델 호출 전에 예산을 막아야 한다면 LiteLLM·Cloudflare 같은 Gateway 계층이 필요하다.
• 실행 원인과 품질을 분석하려면 Langfuse·LangSmith·Phoenix 같은 trace backend가 필요하다.
• 제품 종속을 줄이고 여러 backend로 보내려면 OpenTelemetry Collector를 중간에 둔다.
• 작은 팀은 Gateway 1개와 관측성 backend 1개로 시작하는 편이 운영 부담이 낮다.

비용 대시보드에 넣을 10개 패널

월간 총비용만 크게 표시한 대시보드는 원인을 알려주지 않는다. 최소한 다음 패널이 필요하다.

1. 총비용과 전일·전주 대비 증감
2. 성공 실행당 평균·P50·P95 비용
3. 실패 실행과 취소 실행의 비용
4. 팀·고객·프로젝트별 비용
5. 모델·공급자·요금 티어별 비용
6. 일반 입력·cache read·cache write·출력 토큰 비중
7. Cache hit 비율과 절감 추정액
8. 도구별 호출 수·성공률·외부 API 비용
9. 에이전트 iteration·retry 분포
10. 품질 점수 대비 비용

평균만 보면 소수의 폭주 실행을 놓칠 수 있다. P95 실행 비용, 하루 최대 실행 비용과 상위 20개 비싼 trace를 바로 열 수 있어야 한다.

예산 알림과 무한 루프 차단 기준

비용 통제는 월말 보고서보다 실행 중 제한이 중요하다.

숫자는 서비스 위험도와 마진에 맞춰 정해야 한다. 결제·배포·데이터 삭제 같은 중요한 작업을 예산 때문에 중간에 강제 종료하면 더 큰 장애가 날 수 있다. hard cap은 안전하게 재개할 수 있는 작업에 적용하고, 중요한 작업은 승인·fallback·grace budget을 둔다.

최소 비용 추적 도입 순서

1단계: 공통 식별자와 토큰 기록

사용자 작업 하나에 trace_id와 run_id를 만들고 모든 LLM·도구 호출에 전파한다. provider, request model, response model, 입력·출력·캐시 토큰을 기록한다.

2단계: 가격 계산기와 버전 추가

모델별 가격표를 코드에 흩어놓지 않고 중앙 cost map으로 관리한다. 가격 버전, 통화, 요금 티어와 estimated cost를 span에 붙인다.

3단계: 조직 배부 태그 강제

Gateway나 공통 SDK에서 tenant, team, user, project, environment, agent version을 필수화한다. 태그가 없으면 production 호출을 거부하거나 unallocated 비용으로 따로 집계한다.

4단계: 도구·재시도 비용 연결

외부 API 호출 span에 단가와 사용량을 붙인다. retry count, iteration, error type과 termination reason을 기록해 실패 비용을 분리한다.

5단계: 대시보드와 알림

총비용, 성공 실행당 비용, 실패 비용, cache hit, P95 비용과 상위 고비용 trace를 먼저 만든다. 이후 팀 예산과 실행당 상한을 적용한다.

6단계: 공급자 청구서와 대조

매일 provider usage와 내부 추정 비용을 비교한다. 차이가 일정 수준을 넘으면 가격표·모델 매핑·캐시 분류·시간대 기준을 점검한다.

운영 체크리스트

• 사용자 목표 1건을 하나의 trace로 묶었는가
• 모든 모델·도구 호출에 같은 run ID가 전파되는가
• request model과 response model을 분리했는가
• 일반 입력·cache read·cache creation·출력을 구분했는가
• reasoning·이미지·오디오 사용량을 별도로 기록하는가
• 외부 검색·브라우저·DB·GPU 비용을 포함했는가
• retry·iteration·실패 비용을 분리했는가
• 팀·사용자·프로젝트·환경 태그가 필수인가
• 가격표 버전과 요금 티어를 저장하는가
• 실시간 추정액을 공급자 청구 데이터와 대조하는가
• 프롬프트 전문 없이도 비용 분석이 가능한가
• 실행당 budget과 무한 루프 제한이 있는가

FAQ

AI 에이전트 비용 추적과 일반 LLM 비용 추적은 무엇이 다른가?

일반 LLM 비용 추적은 모델 호출별 토큰과 금액을 본다. AI 에이전트 비용 추적은 하나의 사용자 목표 아래 여러 LLM 호출, 도구 실행, 재시도, 평가와 인프라 비용을 합쳐 실행 총원가를 계산한다.

OpenTelemetry만 도입하면 비용 계산이 끝나나?

아니다. OpenTelemetry는 trace와 GenAI 속성을 표준화하지만 제품별 가격표, 조직 배부, 외부 도구 단가와 예산 차단은 별도로 구현하거나 관측성·Gateway 제품을 연결해야 한다. GenAI semantic conventions도 2026년 7월 기준 Development 상태다.

Langfuse와 LiteLLM 중 무엇을 써야 하나?

역할이 다르다. Langfuse는 trace·평가·비용 분석 backend에 가깝고 LiteLLM은 모델 Gateway와 key·user·team 예산 통제에 강하다. 비용 차단과 원인 분석이 모두 필요하면 함께 사용할 수 있다.

프롬프트와 응답을 저장해야 비용을 계산할 수 있나?

필수는 아니다. 모델, 토큰 유형별 사용량, 도구명, 상태, 재시도와 가격 버전만으로 비용을 계산할 수 있다. 민감한 프롬프트는 마스킹하거나 저장하지 않는 편이 안전하다.

캐시 적중률이 높으면 비용도 같은 비율로 줄어드나?

아니다. 캐시 할인은 캐시된 입력 부분에만 적용된다. 출력, reasoning, cache write, 도구 API와 관측 비용은 그대로 남는다. 전체 절감률은 입력 비중과 cache read 단가에 따라 달라진다.

공급자 대시보드 금액과 내부 계산이 다른 이유는 무엇인가?

시간대, 집계 지연, 반올림, 무료 크레딧, 약정 할인, 실제 응답 모델, 캐시 분류와 가격표 버전 차이 때문이다. 내부 값은 실시간 통제를 위한 추정액으로 사용하고 공급자 usage·청구 데이터로 정기 보정해야 한다.

참고 자료

• OpenTelemetry GenAI Semantic Conventions Repository — GenAI span·agent·tool·token 속성 표준
• Langfuse Token & Cost Tracking — usage 유형과 모델 가격 기반 비용 계산
• LangSmith Cost Tracking — LLM·tool·retrieval custom cost와 대시보드
• Arize Phoenix Cost Tracking — span·trace·session·project 비용 롤업
• LiteLLM Spend Tracking — key·user·team별 spend 추적
• LiteLLM Budgets and Rate Limits — 개인·팀·에이전트 예산과 실행 제한
• Cloudflare AI Gateway Analytics — 요청·토큰·캐시·오류·비용 분석

*제품 기능과 문서 상태는 2026년 7월 29일 확인 기준이며 이후 변경될 수 있다.*

The post AI 에이전트 비용 추적 가이드: 토큰·캐시·도구 호출 비용을 팀별로 관리하는 법 appeared first on .

AI Gateway가 필요한 시점은 기능 개수가 아니라 운영 경계로 판단한다

앱 한 개가 모델 한 개를 호출하는 단계라면 별도 Gateway가 오히려 장애 지점만 늘릴 수 있다. 반대로 여러 서비스가 같은 제공자 키를 공유하거나, 모델 장애가 곧 전체 장애로 이어지거나, 팀별 비용을 사후 집계하고 있다면 공통 계층을 둘 이유가 생긴다.

핵심은 “Gateway가 있으면 안정적이다”가 아니다. Gateway 자체의 장애와 설정 오류를 감당할 운영 주체가 있는지 먼저 확인해야 한다.

Cloudflare AI Gateway와 LiteLLM 비교표

Cloudflare 공식 가격 문서는 현재 핵심 기능인 대시보드 분석·캐시·rate limiting을 무료로 제공한다고 설명한다. 다만 2026년 9월 24일부터 로그 요금 정책이 첫 Gateway 생성 시점 기준으로 나뉜다. 이날 이후 첫 Gateway를 만드는 신규 고객은 Workers Logs 요금·보존 정책을 따르고, 이전에 Gateway를 만든 기존 고객은 종전 Legacy Logs를 유지한다. Legacy Logs의 저장 한도는 Workers Free에서 전체 Gateway 합계 10만 건, Workers Paid에서 Gateway당 1천만 건이다. 신규 고객에게 적용되는 Workers Logs는 Free에서 하루 20만 로그 이벤트·3일 보존, Paid에서 월 2천만 로그 이벤트 포함 후 추가 100만건당 $0.60·7일 보존이다. 즉 신규 도입 검토라면 “무료” 안내만 보고 로그 비용을 0으로 잡으면 안 된다. 향후 일부 기능이 유료화될 수 있다는 안내도 있으므로 “영구 무료”로 해석하면 안 된다.

LiteLLM 공식 문서는 100개 이상 LLM을 OpenAI 형식으로 호출하고 Router의 retry·fallback, Proxy의 virtual key·비용 추적·관리자 UI를 제공한다고 밝힌다. 확인 시점(2026년 9월 30일)의 최신 안정 버전은 v1.103.1이며, 9월 초 v1.99.x 이후 약 한 달 동안 v1.100.0부터 v1.103.1까지 17개 안정 버전이 나왔다. 지금은 Docker 이미지와 PyPI 패키지가 모두 v1.103.1로 일치하지만, v1.99.1처럼 Docker에만 배포되고 PyPI가 한 버전 뒤처지는 구간이 반복되어 왔으므로 배포 방식별 버전을 매번 확인해야 한다. 이 기간의 변경은 신규 정책 엔진의 스트리밍 응답 post_call 가드레일, 제공자 키가 오류 traceback에 노출되지 않도록 하는 수정, spend_logs 조회 안정화 등 운영에 영향 주는 항목 위주다. 운영 환경에서는 latest 태그를 따라가기보다 이미지 digest와 버전을 고정하고 변경 내역·DB 마이그레이션을 검토해야 한다.

선택 흐름: 관리형 우선인가, 통제권 우선인가

Cloudflare AI Gateway가 맞는 경우

• 전담 플랫폼 팀 없이 로그·분석·캐시·rate limit을 빠르게 붙여야 한다.
• Cloudflare 계정과 Workers 운영 체계가 이미 있고 관리 지점을 늘리고 싶지 않다.
• 초기에는 단순한 제공자 전환과 관측이 핵심이며 복잡한 조직별 권한 모델은 아직 필요하지 않다.
• Gateway 서버와 DB의 고가용성을 직접 운영할 여력이 없다.

LiteLLM Proxy가 맞는 경우

• 모델별 배포군을 묶어 load balancing하고 오류 유형별 fallback을 세밀하게 제어해야 한다.
• 가상 키를 발급하고 팀·사용자·에이전트별 예산과 TPM/RPM을 중앙에서 강제해야 한다.
• 요청·응답 데이터가 외부 관리형 Gateway를 통과하면 안 되는 보안 요구가 있다.
• PostgreSQL, 시크릿 관리, 모니터링, 무중단 업그레이드를 책임질 운영 역량이 있다.

두 제품을 함께 쓰는 경우

혼합 구조도 가능하다. 예를 들어 외부 트래픽은 Cloudflare에서 인증·DLP·rate limit·관측을 처리하고, 내부에서는 LiteLLM이 모델 배포군과 팀별 예산을 관리할 수 있다. 다만 retry와 rate limit을 양쪽에 중복 적용하면 지연과 증폭 재시도가 생긴다. 각 계층의 책임을 문서로 나누고 timeout 합계가 사용자 요청 제한을 넘지 않게 설계해야 한다.

실무 도입 순서: 한 번에 모든 기능을 켜지 않는다

1. 기준선을 측정한다. 현재 모델별 요청 수, p50·p95 지연, 429·5xx 비율, 토큰 비용을 최소 1주 기록한다.
2. 관측만 연결한다. 라우팅을 바꾸기 전에 로그 필드, 사용자 식별자, 민감정보 마스킹과 보존 기간을 검증한다.
3. rate limit을 shadow 기준으로 계산한다. 정상 피크를 차단하지 않도록 경고 단계부터 시작한다.
4. timeout과 retry 예산을 정한다. 앱·Gateway·제공자 SDK가 각각 재시도하지 않도록 소유 계층을 하나로 정한다.
5. 동일 품질의 fallback부터 시험한다. 컨텍스트 길이, 도구 호출, 구조화 출력이 호환되지 않는 모델을 무조건 대체 모델로 두지 않는다.
6. 장애 주입 테스트를 한다. 429, 500, timeout, 잘못된 키, DB 단절, 로그 저장 실패를 재현하고 복구 경로를 확인한다.
7. 점진적으로 트래픽을 전환한다. 내부 사용자와 낮은 위험 요청부터 시작해 오류율과 비용 변화를 비교한다.

운영에서 자주 실패하는 다섯 가지 조건

비용과 보안에서 반드시 확인할 체크리스트

• Gateway 사용료뿐 아니라 로그 저장소, DB, 캐시, egress, 모니터링 비용을 합산한다. Cloudflare는 2026년 9월 24일 이후 첫 Gateway를 만들면 Workers Logs 요금(월 2천만 로그 이벤트 초과분 100만건당 $0.60)이 적용되므로 신규 도입 시 로그 단가를 먼저 계산한다.
• 제공자 키는 앱에 남기지 않고 Gateway의 시크릿 저장소 또는 외부 secret manager로 이동한다.
• 사용자·팀·서비스 계정을 구분하고 공유 키를 피한다.
• 프롬프트와 응답 본문을 꼭 저장해야 하는지 검토하고, 기본값은 최소 수집으로 둔다.
• 캐시는 동일 요청에만 적용되는지, 사용자별 데이터가 잘못 공유될 가능성이 없는지 확인한다. Cloudflare 캐시는 공식 문서상 동일 요청의 텍스트·이미지 응답에 적용된다.
• 비용 한도 도달 시 차단할지, 저가 모델로 내릴지, 관리자 승인을 요구할지 정책을 미리 정한다.
• LiteLLM 예산 기능은 공식 문서상 DB의 지출 기록을 기준으로 강제되므로 DB 없는 배포에서 동일한 통제를 기대하면 안 된다.
• LiteLLM은 Docker 이미지와 PyPI의 최신 버전이 다를 수 있다(예: v1.99.1은 Docker에만 배포). 배포 방식을 먼저 정하고 이미지 태그·패키지 버전·서명(cosign) 검증 절차를 각각 고정한다.

관련 글

• AI 에이전트 비용 추적 가이드 — Gateway에 넣을 비용 태그와 팀별 관리 기준을 정리했다.
• AI 에이전트 관측 도구 비교 — Gateway 로그 이후 trace·평가 계층을 선택할 때 참고할 수 있다.
• RAG 평가 실무 가이드 — fallback이나 라우팅 변경 전 품질 회귀를 검증하는 방법을 다룬다.

FAQ

AI Gateway는 트래픽이 적어도 필요한가?

단일 앱·단일 모델이고 키 관리와 장애 대응이 단순하다면 바로 도입할 필요는 없다. 다만 여러 서비스가 키를 공유하거나 비용 귀속이 불분명해지는 시점부터 중앙 계층의 가치가 커진다.

Cloudflare AI Gateway와 LiteLLM 중 어느 쪽이 더 저렴한가?

Cloudflare는 핵심 기능이 현재 무료지만 로그 비용을 먼저 확인해야 한다. 2026년 9월 24일 이후 첫 Gateway를 만들면 Workers Logs 요금제가 적용되어 월 2천만 로그 이벤트를 넘을 때 100만건당 $0.60이 부과된다. LiteLLM은 오픈소스여도 서버·DB·관측·업그레이드 인력이 비용이다. 월 요청 수보다 운영 인력과 데이터 보존 요구를 포함한 총소유비용으로 비교해야 한다.

fallback에 더 저렴한 모델을 넣으면 비용이 항상 줄어드는가?

그렇지 않다. 출력 형식이나 도구 호출 호환성이 낮으면 재시도와 품질 회귀가 늘 수 있다. 같은 평가셋과 실패 조건을 통과한 모델만 그룹에 넣고, 비용과 성공률을 함께 봐야 한다.

참고 자료

• Cloudflare AI Gateway 공식 문서 (확인: 2026-09-30)
• Cloudflare AI Gateway Pricing — 9월 24일 로그 요금 정책 변경 (확인: 2026-09-30)
• Cloudflare Workers Logs 요금·보존 정책 (확인: 2026-09-30)
• Cloudflare AI Gateway Caching (확인: 2026-09-30)
• Cloudflare Unified API (OpenAI 호환) (확인: 2026-09-30)
• LiteLLM 공식 문서
• LiteLLM Fallbacks 공식 문서
• LiteLLM Budgets·Rate Limits 공식 문서
• LiteLLM v1.103.1 릴리스 (2026-09-30)

The post AI Gateway 비교 2026: Cloudflare vs LiteLLM, 운영 기준 7가지 appeared first on .

왜 AI 에이전트에는 별도 관측성이 필요한가

전통적인 웹 서비스 관측성은 요청, 응답 시간, 오류율, CPU, 메모리, 데이터베이스 쿼리를 중심으로 설계됐다. 그러나 AI 에이전트는 여기에 새로운 실행 단계를 추가한다. 사용자의 자연어 요청을 해석하고, 모델을 호출하고, 필요한 도구를 고르고, 파일이나 API를 조작하고, 실패하면 다시 시도한다. 같은 “요청 1건” 안에 여러 번의 LLM 호출과 여러 개의 도구 실행이 들어갈 수 있다.

문제는 실패 지점이 훨씬 다양해진다는 점이다. 모델이 요구사항을 잘못 이해했을 수도 있고, 도구 인자가 틀렸을 수도 있고, 권한 승인이 거절됐을 수도 있고, API rate limit에 걸렸을 수도 있고, 테스트 실패 후 복구 전략을 잘못 선택했을 수도 있다. 단순히 “500 오류가 났다”는 로그만으로는 원인을 설명하기 어렵다.

일반 서버 로그와 AI 에이전트 관측성의 차이

반드시 추적해야 할 9가지 항목

1. 작업 목표: 사용자가 무엇을 요청했는지, 에이전트가 어떤 목표로 해석했는지 기록한다.
2. 모델명과 버전: 같은 프롬프트라도 모델과 버전에 따라 결과가 달라진다.
3. 토큰 사용량과 비용: 입력 토큰, 출력 토큰, 캐시 사용량, 모델별 단가를 추적한다.
4. 도구 호출 이력: 파일 읽기, 파일 수정, 터미널 실행, 브라우저 조작, API 호출을 span 단위로 남긴다.
5. 도구 인자와 결과: 어떤 명령이나 API 파라미터가 실행됐고 어떤 결과가 돌아왔는지 확인 가능해야 한다.
6. 사용자 승인 이력: 위험한 명령, 외부 전송, 배포, 결제성 작업은 승인 여부와 시점을 남긴다.
7. 재시도와 복구 경로: 실패 후 같은 방식을 반복했는지, 다른 전략으로 전환했는지 확인한다.
8. 최종 산출물: 생성된 PR, 파일, 문서, 배포 URL, 테스트 결과를 trace와 연결한다.
9. 민감정보 처리 상태: 프롬프트와 응답에 개인정보, API 키, 내부 문서가 포함됐는지 마스킹 여부를 남긴다.

AI 에이전트 trace는 어떻게 설계해야 하나

가장 실용적인 방식은 사용자 요청 하나를 최상위 trace로 보고, 그 아래에 LLM 호출과 도구 실행을 span으로 나누는 구조다. OpenTelemetry는 trace, metric, log를 함께 다루는 관측성 표준이며, 최근에는 Generative AI semantic conventions를 통해 모델명, 토큰 사용량, 프롬프트 관련 이벤트, 응답 관련 속성을 표현하는 방향을 제시한다.

이 구조를 쓰면 “작업이 실패했다”가 아니라 “테스트 실행 span에서 실패했고, 이후 모델이 원인을 잘못 추론해 같은 명령을 반복했다”처럼 설명할 수 있다. 운영자는 모델 품질 문제, 도구 문제, 권한 문제, 외부 API 문제를 분리해 볼 수 있다.

비용 관측성은 별도 대시보드로 봐야 한다

AI 에이전트 비용은 사용자가 체감하기 전에 급격히 늘 수 있다. 특히 장기 작업, 대용량 컨텍스트, 반복 테스트, 멀티 에이전트 작업에서는 요청 1건이 여러 모델 호출로 쪼개진다. 그래서 단순 월별 API 청구액보다 작업 단위 비용을 보는 것이 중요하다.

보안 관측성: 무엇을 남기고 무엇을 지울 것인가

AI 에이전트 관측성에서 가장 위험한 함정은 “모든 프롬프트와 응답을 그대로 저장하면 디버깅이 쉬워진다”는 생각이다. 실제 운영 환경에서는 프롬프트 안에 고객 정보, 내부 코드, API 키, 장애 로그, 사내 문서가 섞일 수 있다. 관측성은 감사 가능성을 높여야 하지만, 동시에 새로운 정보 유출 경로가 되면 안 된다.

• API 키, 토큰, 비밀번호 패턴은 저장 전에 마스킹한다.
• 원문 프롬프트 저장은 기본값이 아니라 옵션으로 둔다.
• 고위험 도구 호출은 인자 전체보다 요약과 해시를 저장하는 방식을 검토한다.
• trace 접근 권한은 개발자 전체가 아니라 운영상 필요한 인원으로 제한한다.
• 보관 기간을 정하고 오래된 원문 로그는 삭제하거나 비식별화한다.

운영 성숙도별 도입 순서

개인 AI 에이전트 서버에도 필요한 이유

개인 맥미니나 홈서버에서 OpenClaw 같은 AI 에이전트 서버를 운영할 때도 관측성은 필요하다. 개인 환경에서는 대규모 SRE 조직이 없기 때문에 오히려 기록이 더 중요하다. 언제 어떤 모델이 어떤 파일을 읽고 수정했는지, 어떤 명령이 실패했는지, 비용이 어느 작업에서 늘었는지 알 수 없으면 문제를 재현하기 어렵다.

처음부터 복잡한 대시보드를 만들 필요는 없다. 작업 ID, 모델명, 토큰, 도구 호출, 오류, 최종 산출물 링크만 JSON 로그로 남겨도 출발점으로 충분하다. 이후 필요해지면 OpenTelemetry collector, Grafana, LangSmith, 자체 대시보드 같은 도구로 확장할 수 있다.

AI 에이전트 관측성 체크리스트

• 사용자 요청 하나에 고유한 작업 ID가 붙는가
• LLM 호출마다 모델명, 입력/출력 토큰, 비용이 남는가
• 도구 호출 인자와 결과가 trace 안에 연결되는가
• 파일 수정, 터미널 실행, 외부 API 호출은 별도 span으로 남는가
• 사용자 승인 여부와 승인 시점이 기록되는가
• 프롬프트와 응답 원문 저장 정책이 정해져 있는가
• 민감정보 마스킹이 저장 전에 적용되는가
• 실패 후 재시도 횟수와 복구 전략을 볼 수 있는가
• 최종 산출물과 테스트 결과가 작업 기록에 연결되는가

FAQ

AI 에이전트 관측성이 일반 로그와 다른 점은 무엇인가?

일반 로그가 서버 요청과 오류를 남기는 데 초점을 둔다면 AI 에이전트 관측성은 LLM 호출, 프롬프트, 도구 실행, 권한 승인, 비용, 재시도, 최종 산출물을 하나의 작업 흐름으로 연결해 추적한다.

AI 에이전트 운영에서 반드시 기록해야 할 지표는 무엇인가?

최소한 모델명, 토큰 사용량, 비용, 지연 시간, 도구 호출 성공률, 재시도 횟수, 사용자 승인 이력, 오류 원인, 최종 산출물 링크를 기록해야 한다.

프롬프트와 응답을 모두 저장해도 되는가?

항상 저장하면 위험하다. 개인정보, API 키, 내부 문서, 고객 데이터가 포함될 수 있으므로 마스킹, 샘플링, 보관 기간, 접근 권한을 먼저 정해야 한다.

OpenTelemetry만 쓰면 AI 에이전트 관측성이 완성되는가?

아니다. OpenTelemetry는 공통 추적 포맷과 파이프라인을 제공하지만, 어떤 이벤트를 남기고 어떤 실패를 경보로 볼지는 서비스 정책과 평가 기준으로 별도 설계해야 한다.

개인 AI 에이전트 서버에도 관측성이 필요한가?

필요하다. 개인 서버라도 모델 비용, 파일 수정 이력, 도구 호출 실패, 장기 작업 중단 원인을 확인할 수 없으면 운영과 디버깅이 어려워진다.

참고 자료

• OpenTelemetry Observability Primer
• OpenTelemetry Generative AI Semantic Conventions
• OpenAI Agents SDK Tracing
• Anthropic Claude Code Monitoring Usage
• LangSmith Observability

The post AI 에이전트 관측성 가이드: 로그만으로는 부족한 이유 appeared first on .