Alibaba & Ant Group LoongSuite GenAI 관측 가능성 시맨틱 규격: 통합 데이터 언어에서 대규모 구현까지

이 기사는 AI 에이전트(AI agents), 스킬(skills), 그리고 토큰 수준 추론(token-level inference)을 위한 강화된 시맨틱(semantics)을 통해 OpenTelemetry (OTel)를 확장하는 통합 관측 가능성(observability) 규격인 LoongSuite GenAI SemConv를 소개합니다.

배경 (Background)
AI, 특히 생성형 AI (GenAI)의 급격한 발전과 함께 모델(models), 프롬프트(prompts), 토큰(tokens), 도구 호출(tool calling), 에이전트(agents), 메모리(memory), 세션(sessions)과 같은 수많은 새로운 핵심 개념들이 AI 에이전트 시스템에서 등장하고 있습니다. 이러한 개념들은 알고리즘 엔지니어, 운영(O&M) 엔지니어, 그리고 관측 가능성 플랫폼 사용자들이 가장 관심을 갖는 관측 대상이 되었습니다. 이들은 전통적인 시스템에서의 HTTP 요청이나 데이터베이스 호출과 마찬가지로 표준화된 방식으로 수집, 표시 및 소비되어야 합니다. 이를 통해 시스템 유지 관리자는 호출 절차를 명확하게 이해하고 문제를 효율적으로 해결할 수 있습니다.

이에 따라 OpenTelemetry (OTel)는 이르면 2024년 초부터 GenAI 시맨틱 규격 구축을 추진하기 시작했습니다. 이는 이러한 새로운 객체들을 위한 통합 데이터 수집 규격인 시맨틱 컨벤션 (Semantic Conventions, SemConv)을 수립하는 것을 목표로 합니다. 이는 관측 가능한 데이터 수집 표준의 부재 및 일관되지 않은 척도(calibers)와 같은 관련 영역의 문제들을 해결하는 것을 목표로 합니다.

SemConv의 위치 및 가치 (SemConv Positioning and Value)
Java, Go, Python과 같은 다양한 언어를 위한 자동 계측(auto instrumentation) 또는 SDK와 같은 관측 가능한 데이터 수집 도구들은 OTel을 처음 접하는 많은 사람들에게 OTel 커뮤니티의 핵심 가치로 간주될 수 있습니다.

하지만 커뮤니티를 깊이 이해하고 나면, SemConv (Semantic Conventions)와 비교했을 때 이러한 수집 기능들은

성능, 비용, 품질 및 보안의 통합 관리 지원

관측 가능성 (Observability) 구축의 목표는 단순히 문제 해결 (Troubleshooting)뿐만 아니라 성능, 효율성, 보안 및 출력 동작에 대한 지속적인 거버넌스 (Governance)를 달성하는 것입니다. 예를 들어, GenAI SemConv 시나리오에서는 SemConv가 모델 파라미터 (Model parameters), 응답 메타데이터 (Response metadata), 토큰 사용량 (Token usage)과 같은 핵심 정보를 통합적으로 표준화한 후에야 팀이 성능, 비용 및 보안 관련 문제를 더 쉽게 추적할 수 있습니다.

대기업의 경우, 이는 다음과 같은 실질적인 요구사항들을 통합 표준을 기반으로 해결할 수 있음을 의미합니다:

● 기술적 문제 해결 (Technical troubleshooting): Trace ID를 통해 에이전트 (Agents) 전반에 걸친 전체 트레이스 (Trace)를 확인할 수 있으며, 특정 비즈니스 모델의 비정상적인 호출 지연 시간 (Invocation latency)과 같은 다양한 문제들을 분 단위로 찾아낼 수 있습니다.

● 비즈니스 분석 (Business analysis): 효과 데이터 (Effect data)를 비즈니스 간에 비교할 수 있으며, 제품 의사 결정에 직접적으로 사용할 수 있습니다. 이는 BI, 제품, 데이터 과학 (Data science) 등의 역할이 교차 비즈니스 분석을 수행할 때 효율성을 크게 향상시킵니다.

● 평가 (Evaluation): 실제 사용자 궤적 (User trajectories)이 지속적으로 축적되어 평가 데이터셋을 자동으로 구축할 수 있으며, 특히 멀티 에이전트 (Multi-agent) 협업 시나리오의 엔드 투 엔드 (End-to-end) 평가에 유용합니다.

● 컴플라이언스 (Compliance): 통합된 감사 트레이스 (Audit trace)는 보안 ICP 등록 (ICP filing)의 엄격한 요구사항을 충족합니다.

만약 통합된 시맨틱 (Semantics)이 없다면, 이러한 문제들은 단일 시스템 내에서 로컬로만 분석될 수 있으며, 그룹 수준의 관리 역량을 형성할 수 없습니다.

접근 비용 절감 및 인프라 재사용 촉진

OpenTelemetry (OTel)의 설계 목표 중 하나는 표준 프로토콜 (standard protocols), 시맨틱 규격 (semantics specifications), SDK, 자동 계측 (automatic instrumentation), 그리고 Collector와 같은 구성 요소를 통해 텔레메트리 데이터 (telemetry data)가 동일한 수집 및 관리 링크를 재사용할 수 있도록 하는 것입니다. 생성형 인공지능 (GenAI) 시나리오에서 통일된 시맨틱 규격의 가치는 여기서 특히 분명하게 드러납니다. 필드 (fields), Span 구조, 이벤트 모델 (event models), 그리고 컨텍스트 전파 (context propagation) 방법이 명확하게 정의되면, 비침습적 계측 (non-intrusive instrumentation), SDK 캡슐화 (encapsulation), 플랫폼 분석 (platform analysis), 대시보드 (Dashboards), 그리고 경고 정책 (alert policies)을 모두 재사용할 수 있습니다.

이는 기업이 매번 "어떤 필드를 수집해야 하는가"에 대해 고민할 필요가 없음을 의미합니다. 대신, 기업은 기존 규격을 기반으로 기능을 직접 통합하여 전체적인 구축 비용을 절감할 수 있습니다.

LoongSuite GenAI SemConv 소개
배경
현재 관측 가능성 (observability) 산업의 사실상 표준 (de facto standard)인 OTel은 빠르면 2024년 초부터 GenAI 시맨틱 규격에 대한 논의와 설계를 시작했습니다. 하지만 초기 인적 자원 투입이 제한적이었고 커뮤니티 표준이 광범위한 적용 가능성과 장기적인 안정성을 강조했기 때문에 전반적인 업데이트 속도는 상대적으로 느린 편입니다. 반면, Alibaba Group은 내부적으로 수많은 대규모 언어 모델 (LLM) 애플리케이션 구현 시나리오를 보유하고 있으며, 실제 시나리오에서 수많은 사례 문제에 직면해 왔습니다. 따라서 Alibaba Group은 관련 문제들을 통일된 표준으로 추상화해야 할 필요성이 있었습니다.

2025년: Alibaba Cloud, Alibaba Holding, 그리고 Ant Group의 관측 가능성 팀은 OTel GenAI 시맨틱을 기반으로 내부 시나리오 중 OTel이 아직 다루지 못한 콘텐츠에 대해 공동으로 시맨틱 모델링을 수행하기 시작했으며, 이를 기반으로 내부 관측 가능성 수집 도구의 구현과 적용을 추진했습니다.

2026년: OTel (OpenTelemetry) 커뮤니티의 GenAI 주요 메인테이너(Maintainers)들과의 협의가 완료된 후, 관련 콘텐츠가 방대하고 반복(Iteration) 속도가 빠르기 때문에 커뮤니티 메인테이너들의 제안에 따라, 해당 결과물은 우선 Alibaba LoongSuite 관측 가능성(Observability) 브랜드 하에 OTel GenAI SemConv를 위한 벤더 확장 표준으로서 오픈 소스로 공개될 예정이며, 이후 적절한 시점에 OTel 업스트림(Upstream)에 점진적으로 기여될 것입니다.

콘텐츠 및 구현
현재 이 규격은 그룹 내 여러 핵심 시나리오에 구현되어, 에이전트(Agent) 계층부터 인프라(Infrastructure) 계층까지 풀스택 관측 가능성(Full-stack Observability) 역량을 형성하고 있습니다. 예를 들어, 다음은 OTel GenAI SemConv와 비교하여 관련 Loongsuite GenAI SemConv에서 강화된 일부 콘텐츠입니다.

새로운 엔트리/스텝 스팬 (New Entry/Step Span)
문제 배경
AI 에이전트(AI Agent)의 실무 절차에서, 에이전트가 장기적인 작업(Jobs)을 수행할 때 에이전트의 실행 로직이 점점 더 복잡해진다는 것을 발견했습니다. 이는 여러 차례의 도구 호출(Tool calling)과 모델 호출(Model invocations)을 포함하게 되어, 단일 트레이스(Trace)가 수백 또는 수천 개의 스팬(Span)을 포함하게 만듭니다. 이러한 스팬들이 동일한 링크 내에 표시될 때 매우 길게 나타나며, 호출 체인(Invocation chain)의 궤적을 명확하게 관찰하기 어렵게 만듭니다. 이 문제를 해결하기 위해, 우리는 다음과 같은 두 가지 핵심 설계를 도입했습니다:

1. Entry Span (진입 Span): Agent 호출의 진입점(entry point)에서 Span이 생성되며, 모델과 사용자(User)의 원래 입력(Input) 및 출력(Output)을 복원하여 대화 이력(History)을 형성하는 데 사용됩니다. 이를 통해 하위 작업(Downstream Tasks)이 실행될 때, 처리된 데이터가 시스템 프롬프트(System Prompt)나 프레임 프롬프트(frame Prompt)에 의해 간섭받지 않도록 보장하며, 가장 원형에 가까운 고객 요청(Customer Requests)을 검색할 수 있습니다.
2. Step Span (단계 Span): Step은 각 ReAct 절차 동안 Agent의 계층적 표현을 나타냅니다. 각 ReAct 절차 동안 Agent는 "성찰(reflection) → 도구 호출(tool calling) → 모델 호출(model invocation)"의 루프를 완료해야 합니다. 문제 해결(troubleshooting) 시에는 일반적으로 Agent의 실행 상태를 파악하기 위해 하향식(Top-down) 접근 방식을 채택합니다. 구체적인 흐름은 다음과 같습니다: 먼저 전체적인 상황을 관찰할 수 있습니다. 예를 들어, Agent가 10라운드의 ReAct를 포함하는 절차를 실행할 때, 먼저 어느 라운드에 문제가 있는지 찾아낸 다음, 해당 라운드의 어떤 특정 단계(step)가 잘못되었는지 심층적으로 분석할 수 있습니다. 이러한 라운드별 Span 구조를 통해 Agent의 다중 라운드 작업, 성찰, 그리고 그에 따른 실행 결과(Results)를 명확하게 표시할 수 있어, 각 루프의 궤적을 한눈에 파악할 수 있습니다. 시맨틱 모델링 (Semantics Modeling) 새로 추가된 Entry 및 Step Span 타입의 정의는 다음과 같습니다:

구현 효과 (Implementation Effect)
현재 이 시맨틱 규격은 OpenClaw, QwenPaw, Hermes Agent를 포함한 여러 Agent 시나리오에 구현되었습니다. 다음은 OpenClaw 시나리오에 시맨틱 규격이 구현 및 통합된 후의 효과입니다:

새로운 스킬 시맨틱스 (New Skill Semantics)
문제 배경
이커머스 쇼핑 어시스턴트와 같은 에이전트 (Agent) 시나리오에서, AI 에이전트가 사용자의 각 지시 의도를 이해한 후에는 실행을 완료하기 위해 해당 지시를 상응하는 스킬 (Skill)로 라우팅합니다. 스킬 (Skill)은 비즈니스 기능의 가장 작은 재사용 가능한 단위로, 내부적으로는 제품 검색, 장바구니 담기, 환불 요청과 같은 특정 작업 (Jobs)을 완료하기 위해 일련의 LLM 호출 및 도구 호출 (Tool calling)을 오케스트레이션 (Orchestration)합니다.

기존의 OpenTelemetry (OTel) 생성형 인공지능 (GenAI) 시맨틱 규격 (Semantics conventions)은 에이전트 (Agent), 대규모 언어 모델 (LLM), 도구 (Tool)와 같은 스팬 (Span) 유형을 다루고 있지만, 스킬 (Skill)이라는 비즈니스 기능 집계 계층에 대한 추상화가 부족합니다. 스킬 (Skill)은 단일 도구 (Tool) 호출도 아니고 완전한 에이전트 (Agent)도 아니며, 그 둘 사이의 오케스트레이션 (Orchestration) 단위입니다. 스킬 (Skill) 차원의 관측 가능성 (Observability)이 부족하다는 것은 성능 변동 (Performance Fluctuation)이 발생했을 때, 수많은 execute_tool 및 inference 스팬 (Span)들만 볼 수 있음을 의미합니다. 스킬 (Skill) 관측 가능성의 부재는 다음과 같은 세 가지 핵심 페인 포인트 (Pain points)로 이어집니다:

● 기능 도메인 (Feature domain) 귀속 불가: 성능 변동 (Performance Fluctuation)이 발생했을 때, 수많은 execute_tool 및 inference 스팬 (Span)들만 볼 수 있을 뿐, 어떤 기능 도메인에 결함이 있는지 빠르게 판단할 수 없습니다.

● 스킬 (Skill) 상태 메트릭 (Metrics) 계산 불가: 스킬 (Skill) 단위의 P99 지연 시간 (Latency), 성공률 (Succeeded rate), 호출 빈도 (Invoke frequency)와 같은 메트릭 (Metrics)이 누락되어 있습니다.

● 여러 스킬 (Skill)이 동시 실행될 때의 트레이스 (Trace) 모호성: 트레이스 (Trace) 트리에서 서로 다른 스킬 (Skill)의 LLM 또는 도구 (Tool) 스팬 (Span) 소유권을 구분할 수 없습니다.