AI 에이전트를 배포하는 것은 새로운 인간 고객 지원 에이전트를 채용하는 것과 크게 다르지 않습니다. 맥락(Context)을 파악하게 하고, 지식 전수(Knowledge transfer)를 처리하며, 교육을 시킨 뒤 - 준비가 되었다고 판단되면 - 고객을 상대하도록 투입합니다.

아마도 그들은 일을 잘 해낼 것입니다.

하지만 그렇지 않은 순간이 오기 전까지 말이죠.

AI 에이전트가 행방불명(MIA)될 때

어느 날, 당신의 AI 에이전트가 알맹이 없는 답변(Fluff)을 내놓아 화가 난 고객을 마주하게 됩니다. 당신은 근본 원인(Root cause)을 찾기 위해 개입합니다.

이 지점에서 분산 트레이싱 (Distributed tracing)이 등장합니다.

근본 원인을 찾았다고 생각하시나요? 다시 생각해보세요.

AI 에이전트의 비결정론적 동작 (Non-deterministic behavior)을 고려할 때, 이상적인 관측성 (Observability)은 LLM 프롬프트 (Prompts), 토큰 수 (Token counts), 모델 호출 (Model calls)을 훨씬 넘어서야 합니다. 트레이스 (Traces)는 도구, 서비스, 그리고 핵심 인프라까지 깊숙이 침투해야 합니다. 즉, 오염된 데이터나 상태 실패 (State failures)가 발생하여 에이전트의 추론을 오염시키고 오류가 프로덕션 표면으로 터져 나오게 만드는 대수층 (Aquifer)까지 파고들어야 합니다. (힌트: 대수층까지 내려가 보세요 - 세부 사항은 필요 없습니다)

데이터 레이크 (Data lakes)가 등장할 차례입니다.

데이터 레이크: 이기종 데이터, 더 나은 분산 트레이싱

AI 에이전트 텔레메트리 (Telemetry)는 세 가지 계층에서 옵니다. 첫 번째는 프론트 스택 (Front stack, 고객이 마주하는 것), 두 번째는 미들 스택 (Middle stack, AI 모델, LLM 프롬프트, 토큰, 심지어 다른 서비스들), 마지막은 바텀 스택 (Bottom stack, 인프라)입니다. 계측 (Instrumentation)을 통해 이러한 각 계층에 로그 (Logs), 메트릭 (Metrics), 트레이스 (Traces)라는 세 가지 관측성 기둥 (Observability pillars)을 부여합니다.

문제는 AI 에이전트의 경우 텔레메트리 양이 엄청나게 급증한다는 점입니다. 이 부피에 계층과 기둥을 더하면, 서로 다른 데이터 유형이 기하급수적으로 폭발하며 거대하게 뒤섞인 혼합물 (Potpourri)이 됩니다.

Exploding telemetry volume

관측성의 골칫거리: 높은 데이터 세분화, 낮은 데이터 보존율

시중에 나와 있는 많은 관측성 (Observability) 도구들은 데이터 수집 (Data ingestion) 단계에서 기본적으로 핵심 요소(Pillars)만을 포착하여, 이를 컴파일한 뒤 사일로 (Siloes) 형태로 저장합니다. 로그 (Logs)는 로그 형식 그대로 문서 저장소 검색 인덱스 스키마 (Document-store search index schema)를 가진 하나의 데이터베이스에 저장됩니다. 메트릭 (Metrics)은 집계되어 TSDB 스키마를 가진 시계열 데이터베이스 (Time-series database)에 저장됩니다. 트레이스 (Traces)는 부모-자식 인덱스 스키마 (Parent-child index schema)를 가진 그래프 데이터베이스 (Graph database)로 들어갑니다.

문제는 텔레메트리 사일로화 (Telemetry-siloing)에서 끝나지 않습니다. 데이터베이스를 저장소로 사용하는 전통적인 관측성 도구들은 세 가지 레이어 모두에서 텔레메트리를 캡처하지 못합니다. 하나의 레이어만 캡처하거나, 최대 두 개까지만 캡처합니다. 두 개의 레이어만 캡처할 경우 추가적인 이중 사일로 문제 (Double-silo trouble)가 발생합니다. 즉, 텔레메트리 유형별(로그 vs 메트릭 vs 트레이스)로 수평적 분리가 일어나고, 아키텍처 레이어별(프론트엔드 vs 미들웨어 vs 인프라스트럭처)로 수직적 분리가 일어납니다.

데이터가 분할되어 세분화된 데이터베이스 사일로에 저장될 때, 빠른 검색 쿼리를 가능하게 하기 위해 무거운 인덱스 부하 (Index baggage)가 수반됩니다. 데이터 볼륨이 급증하면 필요한 저장 공간도 급증하며, 비용 또한 함께 상승합니다.

(소위 말하는) 해결책:

저장 비용의 상승은 텔레메트리 볼륨의 상승에 비례하므로, 대부분의 관측성 플랫폼은 사용자 유지율 (User retention)을 높이기 위해 시간이 지남에 따라 데이터 보존 기간 (Data retention)을 단축하는 방식을 택합니다. 텔레메트리 보존율은 일반적으로 90일로 제한되며, 이는 새로운 텔레메트리가 유입될 수 있도록 저장 공간을 확보하기 위함입니다.

이 소위 말하는 해결책이 또 다른 골칫거리인 이유:

결국 모든 것은 분산 트레이싱 (Distributed tracing)으로 귀결됩니다. 이전 섹션에서 우리는 근본 원인 분석 (RCA)을 위해 하부 인프라스트럭처까지 깊이 트레이싱하는 것이 얼마나 중요한지 논의했습니다. 스택을 깊게 파고드는 것이 디버깅에 더 많은 공간적 맥락 (Spatial context)을 더해주는 것처럼, 시간을 깊게 거슬러 올라가는 것은 더 많은 시간적 맥락 (Temporal context)을 제공합니다.

텔레메트리를 더 오랜 기간 보존하면 트레이싱을 통해 과거로 거슬러 올라가 이전의 실행 기록을 다시 살펴볼 수 있으며, 운영 환경의 장애로 나타나기 전 조용히 축적되었던 단서들을 찾아낼 수 있습니다.

관측성 (Observability) 플랫폼이 저장 비용을 줄이기 위해 과거의 텔레메트리 (Telemetry) 데이터를 삭제할 때, 그들은 오늘 발생한 장애를 설명하는 데 필요한 컨텍스트 (Context) 또한 삭제하게 됩니다. 그러한 과거의 컨텍스트가 없다면, 분산 트레이싱 (Distributed tracing)은 하나의 이야기가 아닌 단편적인 스냅샷이 되어 버리며, 이는 근본 원인 분석 (Root cause analysis)을 더 느리고 신뢰할 수 없게 만듭니다.

Trace - snapshot vs story

Parseable이 데이터 레이크 (Data lakes)를 통해 고컨텍스트, 저비용 관측성을 달성하는 방법:

관측성에 있어서 Parseable의 철학은 다음과 같습니다: 빠른 텔레메트리 상관관계 분석, 더 빠른 근본 원인 식별, 더 빠른 디버깅. 그리고 낮은 관측성 비용.

이제 이 철학을 앞서 언급한 AI 에이전트 관측성 문제와 Parseable이 제공하는 솔루션을 연결하여 확장해 보겠습니다.

간략한 요약:

잘 정의된 RCA를 위한 이상적인 관측성 솔루션:

1. AI 에이전트 관측성 계층을 거쳐 하부 인프라까지 침투
2. 고도로 컨텍스트가 풍부한 분산 트레이싱을 위해 로그 (Logs), 메트릭 (Metrics), 트레이스 (Traces)를 상관 분석
3. 저장 비용의 급증을 방지하면서, 과거의 단서를 발견하기 위해 장기 보관된 텔레메트리를 추적

관측성 솔루션의 장애물:

전통적인 관측성 플랫폼이 사용하는 사일로화된 고구조화 DB 저장소는 신호 간 상관관계 쿼리 (Cross-signal correlation query)를 매우 느리게 만들고, 비효율적인 "연합 조인 (Federated join)"을 수행하게 하여, 지연이 발생하고 부분적으로만 효과적인 트레이스 대시보드를 초래합니다. 대시보드는 세 가지 계층의 텔레메트리 신호조차 모두 캡처되지 못했다는 사실(S3 호환성 문제 때문)로 인해 더욱 악화될 수 있습니다.

저장 비용이 급증하는 것을 방지하기 위해, 전통적인 관측성 (Observability) 플랫폼들이 취하는 방식은 보관 기간 (Retention time)을 단축하는 것입니다. 이제 분산 트레이싱 (Distributed tracing) 대시보드는 단순히 지연되거나 부분적으로만 효과적인 것에 그치지 않고, 불완전해집니다. 즉, 근본 원인에 도달하기 훨씬 전(몇 분 전)에 트레이싱이 끊겨버리는 것입니다.

그 결과는 어떠할까요? 근본 원인 분석 (RCA)을 5분 만에 수행하는 대신, AI 에이전트가 프로덕션 환경에서 계속 자원을 소모하는 동안 끊기고 연결되지 않은 트레이스 (Traces)를 수동으로 다시 추적하며 45분을 허비하게 됩니다.

하나의 파이프라인, 하나의 쿼리, 하나의 인터페이스.

이것이 Parseable이 이상적인 관측성 솔루션을 제공하는 방식입니다.

Parseable은 저장을 위해 S3 호환 데이터 레이크 (Data lake) 아키텍처를 사용하여 텔레메트리 (Telemetry)를 분산시키고 격리되지 않게 유지합니다. 세 가지 계층과 기둥 (Pillars) 모두에서 발생하는 모든 유형의 데이터가 단일 파이프라인을 통해 흐르므로, 서로 맞지 않는 독점적 SDK, 계층별로 격리된 도구, 그리고 단절된 대시보드가 필요하지 않습니다.

풀스택 텔레메트리가 단일 저장소에 방해받지 않고 존재함에 따라, 모든 분산 트레이스 스팬 (Distributed trace span)은 에이전트의 프론트엔드, 미들웨어, 인프라 계층을 손쉽게 연결합니다. 단일 쿼리만으로 사용자의 초기 상호작용부터 여러 서비스에 걸친 API 호출 및 LLM 토큰 사용량, 그리고 저수준의 CPU/GPU 사용률과 인프라 비용에 이르기까지의 실행 경로를 추적할 수 있습니다. 상관관계 (Correlation)는 자동으로 발생하여, 단일 화면에서 트레이스를 관련 로그 및 메트릭 (Metrics)과 즉시 연결합니다. 그 결과 고도로 맥락화된 트레이스를 얻을 수 있으며, 이를 통해 AI 에이전트의 프로덕션 장애에 대한 정확한 근본 원인을 단 몇 초 만에 찾아낼 수 있습니다.

컬럼형 설계 (Columnar design). 최대 90%의 데이터 압축. 저장 비용의 극히 일부만으로 높은 보관 기간 유지.

데이터 레이크 (Data lakes)는 본질적으로 더 저렴합니다. AI 에이전트가 생성하는 데이터 볼륨이 기하급수적으로 증가함에 따라 폭증하는 데이터베이스 저장과 관련된 "인덱스 세금 (index tax)"을 제거함으로써, 데이터 레이크는 필요한 저장 공간과 관련 비용을 극적으로 낮춰줍니다. Parseable은 매 60초마다 Apache Parquet를 활용하여 수집된 데이터를 열 기반으로 구성하고 90%까지 압축함으로써 저장 비용을 훨씬 더 저렴하게 만듭니다.

믿을 수 없을 정도로 낮은 비용으로 낮은 저장 용량을 요구한다는 것은 오래된 텔레메트리 (telemetry)를 더 오랜 기간 유지할 수 있음을 의미하며, 이는 오래된 텔레메트리가 분산 트레이싱 (distributed tracing)에 효과적으로 기여할 수 있는 길을 열어줍니다. 더 넓은 시간적 문맥 (temporal context)이 더 높은 공간적 문맥 (spatial context)과 결합됨에 따라, 이제 근본 원인 (root cause)에 대한 정밀한 가시성을 확보하고 신속하게 디버깅할 수 있습니다.

결정적으로, 더 빠른 디버깅은 대규모 LLM 토큰 비용 절감으로 직결됩니다. 실패 지점을 즉각적으로 찾아냄으로써, 오류가 발생하여 루프에 빠진 AI 에이전트가 운영 환경에서 막대한 양의 비싸고 불필요한 토큰을 소모하는 것을 방지할 수 있습니다.

The Parseable approach

결론 (Bottomline)

AI 에이전트 관측성 (AI agent observability) 측면에서 Parseable의 데이터 레이크 아키텍처가 주는 이점은 두 가지입니다. 첫째는 저장 비용의 감소이고, 둘째는 LLM 토큰 사용 비용의 감소입니다. 높은 수준의 관점에서 바라보면, 이 두 가지 비용 절감 곡선은 하나로 수렴하여 "거의 비용이 들지 않는 통합 관측성 (Unified Observability That Costs a Dot)"으로 귀결됩니다.

비용 절감액을 계산해 보세요. 확신이 선다면, Parseable의 데이터 레이크를 살펴보세요.