Semantic Kernel에서 관측 가능성

Semantic Kernel에서 관측 가능성 (Observability)

AI 솔루션을 만들다 보면 '내 서비스가 실제로 어떻게 동작하고 있을까'를 들여다보고 싶어져요. 관측 가능성(observability)은 분산 시스템 안에 있는 컴포넌트의 내부 상태를 모니터링하고 분석하는 능력을 뜻하는데, 엔터프라이즈급 AI 솔루션을 만들 때 핵심 요건이에요. 디버깅이 '한 번 보고 고치는 것'이라면, 관측 가능성은 시스템의 건강 상태와 성능을 지속적으로 파악하게 해 주는 개념이죠.

출처: 공식문서

관측 가능성을 이루는 세 기둥

관측 가능성은 보통 로깅(logging)·메트릭(metrics)·트레이싱(tracing) 세 가지로 구현돼요. 이 셋을 '관측 가능성의 세 기둥(three pillars)'이라 부르죠. 이 세 기둥이 모은 데이터를 가리켜 텔레메트리(telemetry) 라고도 해요.

더 읽어보면 좋은 자료가 있어요.

• Cloud Native Computing Foundation의 관측 가능성 정의
• 분산 트레이싱
• .NET의 관측 가능성
• OpenTelemetry

Semantic Kernel의 관측 가능성

Semantic Kernel은 처음부터 관측 가능하도록 설계됐어요. OpenTelemetry 표준과 호환되는 로그·메트릭·트레이스를 내보내기 때문에, 자신이 즐겨 쓰는 관측 도구를 그대로 가져다 Semantic Kernel 기반 서비스를 모니터링하고 분석할 수 있죠.

구체적으로 Semantic Kernel이 제공하는 관측 기능은 이렇습니다.

• 로깅: 커넬·커넬 플러그인·함수, 그리고 AI 커넥터에서 의미 있는 이벤트와 오류를 기록해요.
  • 주의할 점이 하나 있어요. Application Insights의 Traces나 OpenTelemetry의 span 이벤트는 전통적인 로그 항목을 나타내지, '분산 트레이스'와는 다른 개념이라는 걸 헷갈리지 마세요.
• 메트릭: 커넬 함수와 AI 커넥터에서 메트릭을 내보내요. 커넬 함수의 실행 시간, AI 커넥터의 토큰 소비량 같은 지표를 모니터링할 수 있어요.
• 트레이싱: 분산 트레이싱을 지원해요. 서로 다른 서비스 사이를 가로지르는 활동과 Semantic Kernel 내부의 활동을 함께 추적할 수 있죠.

언어별 텔레메트리 비교

C# 기준으로 보면:

Python 기준으로 보면:

• Log: 커넬 전체에 걸쳐 로그가 기록되며, 커넬 함수 인자나 결과 같은 민감한 데이터는 debug 레벨로 기록돼요.
• Span: 자동 함수 호출 루프, 커넬 함수 실행, AI 모델 호출 각각이 span으로 기록됩니다.
• Metric: semantic_kernel.function.invocation.duration과 semantic_kernel.function.streaming.duration(둘 다 Histogram, 초 단위)을 수집해요.

Java 기준: 아직 Semantic Kernel 관측 가능성을 지원하지 않아요.

OpenTelemetry 시맨틱 컨벤션

Semantic Kernel은 관측 가능성에 대해 OpenTelemetry 시맨틱 컨벤션(Semantic Convention) 을 따릅니다. 즉 내보내는 로그·메트릭·트레이스가 구조화되어 공통 스키마를 따르기 때문에, Semantic Kernel이 만든 텔레메트리 데이터를 더 효과적으로 분석할 수 있어요.

참고로 Generative AI를 위한 시맨틱 컨벤션은 아직 실험(experimental) 상태예요. Semantic Kernel은 OpenTelemetry 시맨틱 컨벤션을 최대한 가깝게 따라가려고 하며, AI 솔루션에 일관되고 의미 있는 관측 경험을 제공하려 해요.

다음 단계

이제 기본기를 잡았으니, 텔레메트리 데이터를 콘솔로 출력하거나 APM 도구로 시각화·분석하는 방법을 알아보면 돼요.

더 알아보기 (Learn more)

• Console로 텔레메트리 출력하기
• Application Insights