문제점: 눈가림식 AI 요청의 높은 비용
표준 CRUD 애플리케이션을 구축할 때 성능 병목 현상은 예측 가능합니다. 거의 항상 누락된 데이터베이스 인덱스나 무거운 페이로드 때문입니다. 하지만 AI 에이전트와 LLM(거대 언어 모델)의 경우, 성능은 매우 예측 불가능합니다.

단일 사용자 프롬프트가 여러 API 호출, 프롬프트 포맷팅, 벡터 데이터베이스 조회(RAG), 스트리밍 응답을 유발할 수 있습니다. 만약 사용자가 앱이 느리다고 불평한다면, 단순히 서버 CPU 사용량을 확인할 수는 없습니다. 다음 사항들을 알아야 합니다:

• 어떤 특정 LLM 호출이 가장 오래 걸렸는가?
• 벡터 데이터베이스 검색이 컨텍스트 검색을 늦추었는가?
• 해당 요청이 몇 개의 토큰을 소비했는지 (그래서 우리가 파산하지 않도록)?

이를 해결하기 위해, 저는 OpenTelemetry를 사용하여 Python 기반의 AI 에이전트 백엔드를 계측하고 이를 SigNoz에 연결했습니다. 정확한 방법은 다음과 같습니다.

작업 보여주기: 설정 및 계측
단순히 HTTP 요청이 발생했다는 것만 알려주는 일반적인 자동 계측에 의존하는 대신, 우리는 명시적이고 의미론적인 인라인 트레이싱을 작성할 것입니다. 이는 토큰 수나 모델 이름 같은 깊고 도메인 특화된 통찰력을 우리의 텔레메트리 내부에 제공합니다.

1. OpenTelemetry 초기화 스크립트
   먼저, 트레이서 프로바이더를 구성하여 데이터를 SigNoz 컬렉터로 직접 전송하도록 합니다. tracing.py라는 파일을 생성하세요:

Python

from opentelemetry import trace
from opentelemetry.sdk.trace import TracerProvider
from opentelemetry.sdk.trace.export import BatchSpanProcessor, ConsoleSpanExporter
from opentelemetry.exporter.otlp.proto.grpc.trace_exporter import OTLPSpanExporter
from opentelemetry.sdk.resources import Resource

def init_tracer(service_name="ai-agent-service"):
# 애플리케이션 메타데이터 정의
resource = Resource.create(attributes={"service.name": service_name})
provider = TracerProvider(resource=resource)

SigNoz를 가리키도록 OTLP 익스포터를 구성합니다 (기본 gRPC 포트는 4317)

otlp_exporter = OTLPSpanExporter(endpoint="http://localhost:4317", insecure=True)

...

tracer = init_tracer()

1. AI 에이전트 로직 계측하기 (Wrapping the AI Agent Logic)
이제 핵심 애플리케이션 코드를 살펴보겠습니다. 커스텀 트레이서(tracer)를 사용하여 전체 에이전트 실행을 위한 부모 스팬(parent span)을 생성하고, 데이터베이스 조회 및 실제 외부 AI API 호출에 대해서는 개별적인 중첩 자식 스팬(nested child spans)을 만듭니다.

Python  
import time  
from tracing import tracer  
from opentelemetry.trace import StatusCode

def fake_vector_db_search(query):
    with tracer.start_as_current_span("vector_db_search") as span:
        span.set_attribute("db.system", "chromadb")  
        span.set_attribute("db.query", query)

    # 벡터 임베딩 검색 지연 시간 시뮬레이션
    time.sleep(0.4) 
    return "Context: OpenTelemetry is an open-source observability framework."

def call_llm_agent(user_prompt):
    # 최상위 부모 트레이스 시작  
    with tracer.start_as_current_span("ai_agent_pipeline") as parent_span:
        parent_span.set_attribute("user.prompt_length", len(user_prompt))

        # 단계 1: 컨텍스트 검색 (자식 스팬 1)
        context = fake_vector_db_search(user_prompt)

        # ... (생략된 코드)

if __name__ == "main":  
    print("계측된 AI 에이전트 실행 중...")  
    call_llm_agent("How do I properly monitor my pipeline?")

커스텀 토큰 및 비용 대시보드 생성

`llm.total_tokens`나 `llm.model_name`과 같은 속성(attributes)을 스팬(spans)에 직접 첨부했기 때문에, 단순히 네트워크 속도 차트만 얻는 것이 아니라 비즈니스 핵심 기능을 담은 대시보드를 구축할 수 있습니다.

SigNoz에서는 스팬의 속성을 기반으로 ClickHouse 쿼리를 사용하여 커스텀 패널을 만들 수 있습니다:

SQL  
`SELECT   sum(attributes_number_value[indexOf(attributes_string_key, 'llm.total_tokens')]) as total_tokens_consumed,   attributes_string_value[indexOf(attributes_string_key, 'llm.model_name')] as model   FROM signoz_traces.spans   WHERE attributes_string_key = 'llm.model_name'   GROUP BY model   `  
이 쿼리는 원시적인 엔지니어링 트레이스 계측 데이터(telemetry)를 실제 AI 모델별 실시간 토큰 지출을 보여주는 임원급 대시보드로 변환합니다.

주요 주의사항 및 배운 점

이번 구현 과정에서 일반적인 설정 가이드에서는 완전히 건너뛰는 몇 가지 중요한 엔지니어링 세부 사항들을 발견했습니다:

📌 비동기 스트림(Async Streams)을 과도하게 추적하지 마세요: 응답을 토큰 단위로 스트리밍하는 경우(OpenAI/LangChain에서 `stream=True` 사용), 전체 루프를 감싸면 클라이언트의 네트워크 읽기 속도가 포함되어 생성 지연 시간(generation latency) 측정치가 인위적으로 부풀려집니다. 대신, 정확한 Time-To-First-Token (TTFT)을 계산하기 위해 초기 요청부터 첫 바이트 수신까지의 시간을 명시적으로 측정해야 합니다.

📌 배치 프로세서(Batch Processor)를 염두에 두세요: 스테이징 및 프로덕션 환경에서는 항상 `BatchSpanProcessor`를 사용하세요. 동기식인 `SimpleSpanProcessor`를 사용하면 백엔드 애플리케이션이 사용자에게 응답하기 전에 SigNoz 컬렉터가 데이터 수신을 확인(acknowledge)할 때까지 기다리게 되어, 애플리케이션 성능이 완전히 저하됩니다.

결론

관측 가능성(Observability)은 서버 컨테이너의 상태를 확인하는 것에서 멈춰서는 안 됩니다. OpenTelemetry 커스텀 스팬을 AI 파이프라인에 직접 매핑함으로써, 외부 공급업체 API의 지연 속도를 격리하고, 정확한 토큰 리소스 소비량을 추적하며, 어떠한 추측도 없이 복잡한 에이전트 아키텍처를 디버깅할 수 있습니다.

AI 아키텍처를 위한 OpenTelemetry 시맨틱 컨벤션에 대해 더 자세히 알아보고 싶다면, 공식 OpenTelemetry 문서를 확인해 보세요.

자체 관측 가능성 스택(observability stack)을 로컬에 배포하려면, SigNoz GitHub 저장소를 클론하세요.