AI 코드 분석기의 성능 병목, OpenTelemetry로 해결!

FastAPIInstrumentor와 RequestsInstrumentor를 사용한 자동 계측(Auto-Instrumentation)은 HTTP 요청 및 API 호출에 대한 기본적인 가시성을 즉시 제공함. 하지만 LLM 토큰 사용량, 리포지토리별 비용, 처리된 코드 라인 수 등 핵심 비즈니스 로직(Core Business Logic)에 대한 깊이 있는 분석을 위해서는 사용자 정의 메트릭 및 수동 스팬 추가가 필수적이었음. 예를 들어, `gemini.tokens.total` 메트릭에 `repo` 속성을 추가하여 리포지토리별 토큰 소비량 비교(Repository-specific Token Consumption Comparison)가 가능해졌음.

계측 결과, GitHub API 호출은 예상보다 빨랐으며 실제 지연 시간의 주된 원인은 Gemini 모델 추론(Gemini Model Inference)이었음이 밝혀짐. 특히, 프롬프트 크기(Prompt Size)와 배치 처리(Batch Processing)가 토큰 사용량 및 분석 시간에 큰 영향을 미치는 것으로 나타남. 리포지토리 크기만으로는 토큰 비용을 예측하기 어려웠으며, 프롬프트 구조(Prompt Structure)의 최적화가 성능 개선의 핵심임을 확인함. 이는 최적화 노력(Optimization Efforts)을 어디에 집중해야 할지에 대한 명확한 방향을 제시함.

개발 환경과 프로덕션 환경 간의 차이로 인해 두 가지 주요 문제가 발생함. 첫째, 프로덕션 환경에서 OpenTelemetry Collector가 실행되지 않을 때 발생하는 연결 오류 스팸(Connection Error Spam)은 `OTEL_ENABLED` 환경 변수 확인 로직으로 해결함. 둘째, SigNoz의 ClickHouse 초기화 지연으로 인한 데이터 수신 실패(Data Ingestion Failure) 문제는 SigNoz 스택 시작 후 GitIntel 애플리케이션을 재시작하는 순서 조정으로 해결함. 이러한 인프라 문제 해결(Infrastructure Problem Solving) 경험은 안정적인 관측 가능성 시스템 구축의 중요성을 강조함.