URL: https://clickhouse.com/blog/llm-observability-challenge

오늘날 LLM이 온콜 SRE를 대체할 수 있을까?

AI 기반 관측 가능성(observability)이 곧 사이트 신뢰성 엔지니어(SRE)의 역할을 줄이거나 심지어 대체할 것이라는 믿음이 커지고 있습니다. 대담한 주장이고, ClickHouse에서는 실제로 우리가 어디까지 와 있는지 궁금했습니다.

이를 위해 SRE가 하는 일(다른 수많은 일들 중 하나) 가운데 근본 원인 분석(Root Cause Analysis, RCA) 이라는 특정 작업을 골라, 모델이 스스로 이 일을 얼마나 잘하는지 실험을 진행했습니다.

실험을 어떻게 설계하고 실행했는지, 그리고 더 중요한 것은 그 과정에서 무엇을 배웠는지 계속 읽어보세요.

TL;DR 자율 RCA는 아직 이르다. 생산(production) 이슈를 더 빠르고 더 낮은 비용으로 찾게 해준다는 LLM의 약속은 이번 평가에서 기대에 못 미쳤고, GPT-5조차도 다른 모델들을 뛰어넘지 못했다.

LLM은 조사(investigation)를 보조 하는 용도로—조사 결과 요약, 업데이트 초안 작성, 다음 단계 제안—활용하되, 엔지니어가 빠르고 검색 가능한 관측 가능성 스택 위에서 주도권을 쥐고 있어야 한다.

실험: 순진한(naive) 프롬프트로 LLM이 RCA를 처리하게 하기

실험은 간단합니다. 모델에게 라이브 애플리케이션의 관측 가능성 데이터를 접근할 수 있게 해주고, 순진한 프롬프트만으로 사용자 보고 이상(anomaly)의 근본 원인을 찾아보라고 했습니다.

실험을 위해 먼저 경쟁자(contenders)가 필요했기에, 5개의 모델을 골랐습니다. 일부는 유명하고, 일부는 덜 알려졌지만 유망한 모델입니다:

• Claude Sonnet 4: Claude는 구조화된 추론과 상세한 답변으로 알려져 있습니다. 복잡한 이슈를 시스템 전반에 걸쳐 추적할 때 도움이 될 수 있는, 논리적인 단계 전개에 강한 편입니다.

• OpenAI GPT-o3: 속도와 멀티모달 입력을 위해 설계된 OpenAI의 더 진보된 모델입니다. 빠른 응답 시간과 성능 사이의 균형을 노립니다.

• OpenAI GPT-4.1: 일반적인 추론과 언어 이해 면에서 여전히 강력하지만, GPT-o3보다 느리고 덜 날카로운 편입니다. 비교를 위한 좋은 기준선(baseline)입니다.

• Gemini 2.5 Pro: 구글의 최신 Pro 모델로, 자사 생태계와 통합되어 있습니다. 다단계 추론에 강하고 코드 및 트러블슈팅 과제에서 좋은 성능을 보여왔습니다.

모든 모델을 다 테스트하진 않았습니다. 첫째로 그건 불가능한 과제이고, 대신 우리가 쉽게 접근할 수 있고 작업에 적합해 보이는 모델들을 선택했습니다. 목표는 승자를 가리는 것이 아니라, 각 모델이 현실의 실제 인시던트 데이터를 어떻게 다루는지 보는 것입니다.

다음으로, 문제를 포함하는 라이브 애플리케이션의 관측 가능성 데이터가 필요합니다. 우리는 OpenTelemetry 데모 애플리케이션을 실행해, 고유한 이상을 담은 4개의 데이터셋을 생성했습니다.

아래 아키텍처 다이어그램에서 볼 수 있듯, OpenTelemetry 데모 애플리케이션은 꽤 복잡하고 다양한 서비스, 사용자가 상호작용할 수 있는 프런트엔드, 그리고 로드 생성기(load generator)를 포함합니다. 간단히 말해 현실 세계 애플리케이션을 잘 대표합니다. 또한 데모 앱에는 feature flag로 켜고 끌 수 있는 사전 준비된 이상(anomaly)이 기본 제공됩니다.

이 애플리케이션을 사용해, 각각 서로 다른 이상을 포함하고 1시간 분량의 데이터를 담은 새 데이터셋 3개를 만들었습니다. 네 번째 테스트는 48시간을 커버하는 기존 ClickStack 공개 데모 데이터셋을 사용했습니다.

아래 표는 4개 데이터셋 요약과 각각에 사용된 feature flag를 정리한 것입니다.

데이터셋을 캡처하기 위해 다음 방법론을 사용했습니다.

먼저 OpenTelemetry 데모 애플리케이션을 배포하고, Kubernetes에서 ClickStack으로 계측(instrument)합니다. 이 리포지토리에는 그 방법이 담겨 있습니다.

애플리케이션이 실행되고 텔레메트리 데이터가 ClickHouse로 들어오기 시작하면, 부하를 1000 사용자까지 올립니다. 사용자 수가 목표에 도달한 후 feature flag를 켜고 약 40분간 실행합니다. 마지막으로 feature flag를 끄고 10분 더 실행합니다. 이렇게 캡처된 전체 데이터셋은 약 1시간 분량의 데이터를 포함합니다.

sql
SELECT
    min(TimestampTime),
    max(TimestampTime)
FROM otel_anomaly_3.otel_logs

text
┌──min(TimestampTime)─┬──max(TimestampTime)─┐
│ 2025-07-22 08:25:40 │ 2025-07-22 09:36:01 │  
└─────────────────────┴─────────────────────┘

이제 데이터셋이 준비됐으니, 먼저 수동 조사(manual investigation)로 문제를 파악한 뒤, 다양한 모델을 테스트해 어느 모델이 빛나는지 보겠습니다.

LLM에게 문제를 찾게 하기 전에, 우리도 실제 근본 원인을 알아야 합니다. 즉, 각 이상(anomaly)에 대해 SRE가 하듯이 제대로 수동 조사를 수행해야 합니다. 이로써 기준선(baseline)이 생깁니다. 모델이 맞히면 알 수 있고, 틀리거나 다른 방향으로 가면 개입해 안내할 수 있습니다.

이 단계에서는 ClickHouse 위에 구축된 관측 가능성 스택인 ClickStack을 사용합니다.

각 이슈를 수동으로 살펴보고, 무엇이 잘못됐는지 확인한 뒤, 우리가 밟은 경로를 문서화합니다. 이것이 모델의 행동을 비교하기 위한 기준점이 됩니다.

그다음은 모델 차례입니다.

각 LLM은 LibreChat을 사용해 동일한 시나리오로 실행했습니다. LibreChat은 ClickHouse MCP 서버와 연결되어 있어 모델이 실제 관측 가능성 데이터를 쿼리하고 스스로 원인을 찾아보도록 할 수 있습니다.

우리는 LibreChat과 ClickHouse MCP 서버를 계측해 토큰 사용량을 추적했습니다. 텔레메트리 데이터가 ClickHouse에 저장되어 있으므로, 다음 쿼리로 조사 전체에서 사용된 토큰 수를 얻을 수 있습니다.

sql
SELECT
    LogAttributes['conversationId'] AS conversationId,
    sum(toUInt32OrZero(LogAttributes['completionTokens'])) AS completionTokens,
    sum(toUInt32OrZero(LogAttributes['tokenCount'])) AS tokenCount,
    sum(toUInt32OrZero(LogAttributes['promptTokens'])) AS promptTokens,
    anyIf(LogAttributes['text'], (LogAttributes['text']) != '') AS prompt,
    min(Timestamp) AS start_time,
    max(Timestamp) AS end_time
FROM otel_logs
WHERE conversationId = 
GROUP BY conversationId

각 테스트는 동일한 순진한 프롬프트로 시작했습니다:

"너는 관측 가능성 에이전트이며 데모 애플리케이션의 OpenTelemetry 데이터에 접근할 수 있다. 사용자가 애플리케이션 사용 중 문제를 보고했는데, 문제가 무엇인지, 근본 원인이 무엇인지 식별하고 가능한 해결책을 제안해줄 수 있나?"

모델이 첫 프롬프트만으로 맞히면 좋습니다. 그렇지 않으면, 모델이 제공한 응답에 기반해 후속 질문을 하거나, 완전히 엇나간 경우에는 해결에 도달하도록 추가 맥락을 제공합니다.

각 이상에 대해 다음을 보고합니다:

• 모델이 무엇을 찾아냈는지
• 정확도가 어떤지
• 얼마나 많은 가이던스가 필요한지
• 거기까지 가는 데 토큰을 얼마나 쓰는지
• 조사에 얼마나 시간이 걸리는지

이를 통해 각 모델이 실제 SRE 작업에 투입됐을 때 얼마나 효율적이고 신뢰할 수 있는지 감을 얻을 수 있습니다.

이 섹션에서는 각 이상을 다룹니다. 먼저 수동 조사를 문서화하고, 이어 각 모델에 단순 프롬프트를 던져 모델의 결론을 기록합니다. 모델이 바로 진단에 실패하면, 추가 프롬프트로 유도합니다.

Anomaly 1

사용자들이 체크아웃 과정에서 문제를 보고합니다. 주문 관련 정보를 모두 입력한 뒤 “주문하기(place order)”를 클릭하면 오류가 발생합니다.

ClickStack에서 수동으로 진단하기 쉬운 문제입니다. 먼저 오류가 포함된 클라이언트 세션 하나를 봅니다.

해당 세션에서 trace 뷰를 보면 payment 서비스에서 오류 메시지가 보입니다. 메시지는 로열티 레벨 gold에 대해 토큰이 유효하지 않아 결제 요청이 실패한다고 나타냅니다.

trace explorer 뷰로 이동해 payment 서비스로 대시보드를 필터링합니다.

이로써 확인됩니다. Gold 로열티 상태의 클라이언트 요청을 처리할 때 payment 서비스에 문제가 있습니다.

Claude Sonnet 4

첫 프롬프트 이후 RCA를 찾아냈습니다.

전체 상호작용(요약)을 보려면 아래를 펼치세요.

Claude Sonnet 4 anomaly 1 full interaction

Prompt 1:

You're an Observability agent and have access to OpenTelemetry data from a demo application. Users have reported issues using the application, can you identify what is the issue, the root cause and suggest potential solutions?

LLM response 1 (snippet):

OpenTelemetry Analysis Report Issues Identified 1. Primary Issue: Payment Service Gold Tier Failure - What: Starting at 11:52:35 on July 22, 2025, all payment transactions for users with "gold" loyalty level began failing with "Invalid token" errors - Impact: 50% payment failure rate (13,505 failed transactions out of 27,000 total payment attempts) - Error Message: "Payment request failed. Invalid token. app.loyalty.level=gold"

OpenAI o3

첫 프롬프트 이후 근본 원인과 문서화를 해냈습니다.

전체 상호작용(요약)을 보려면 아래를 펼치세요.

OpenAI o3 anomaly 1 full interaction

Prompt 1:

You're an Observability agent and have access to OpenTelemetry data from a demo application. Users have reported issues using the application, can you identify what is the issue, the root cause and suggest potential solutions?

LLM response 1 (snippet):

Evidence 1. Traces – Payment service: 13,512 error spans, all named "Error: Payment request failed. Invalid token. app.loyalty.level=gold" – Checkout service: 27,024 error spans (same TraceId chain) with gRPC method oteledemo.PaymentService/Charge returning INTERNAL. – Frontend / frontend-proxy: ~29,000 error spans ("Failed to place order"). 2. Logs – 27,010 "failed to charge card: ... Invalid token ... loyalty.level=gold" log records. – Small number (~6,000) of ECONNREFUSED errors, but they are an order of magnitude lower than the “Invalid token” failures. 3. Metrics – No CPU / memory anomalies; latency spikes coincide with spikes in payment errors. – Error rate is almost 100% for PlaceOrder when loyalty.level = gold.

OpenAI GPT-4.1

초기에는 MCP 서버를 통한 ClickHouse 데이터 쿼리를 하지 않았습니다. 후속 프롬프트 후에야 ClickHouse를 쿼리해 분석했지만 근본 원인을 식별하지 못했습니다. 문제의 영향을 받은 trace 상위(parent) span에 집중했고, 실제 원천(source)을 찾지 못했습니다. 우리가 직접 가이던스를 준 뒤에야 근본 원인을 찾았습니다.

전체 상호작용(요약)을 보려면 아래를 펼치세요.

OpenAI GPT4.1 anomaly 1 full interaction

Prompt 1:

You're an Observability agent and have access to OpenTelemetry data from a demo application. Users have reported issues using the application, can you identify what is the issue, the root cause and suggest potential solutions?

LLM response 1 (snippet):

To help you identify the issue, root cause, and suggest solutions, I’ll need to analyze relevant OpenTelemetry data from your demo application. This typically includes traces, metrics, and logs. Here’s how we’ll approach this: 1. Issue Identification: I’ll look for error traces, high latencies, dropped requests, or anomalies. 2. Root Cause Analysis: I’ll analyze the traces to see where bottlenecks, errors, or resource issues might exist (e.g., slow database calls, timeouts, dependency errors). 3. Potential Solutions: Based on findings, I’ll suggest actionable solutions.

Prompt 2:

You have access to the data, can you start analyzing?

LLM response 2 (snippet):

Observed Issue - High average span durations in several services, especially load-generator, frontend-proxy, and frontend. - No explicit errors in logs or trace statuses. - This points toward a potential performance/bottleneck issue rather than a code crash or failure.

Prompt 3:

Users have been reported issues during the payment process

LLM response 3 (snippet):

Impact - Users, particularly with gold loyalty level, cannot complete payment, resulting in user-facing failures and high error rates in backend logs and traces.

Gemini 2.5 Pro

처음에는 MCP 도구를 사용해 데이터베이스를 나열하는 과정에서 여러 오류가 있었습니다. 초기 프롬프트 후에는 문제와 무관한 특정 API의 지연(latency)에 초점을 맞추며 잘못된 방향으로 갔습니다. 결제 프로세스를 보라고 유도하자, gold 상태 이슈를 올바르게 식별했습니다.

전체 상호작용(요약)을 보려면 아래를 펼치세요.

Gemini 2.5 Pro anomaly 1 full interaction

Prompt 1:

You're an Observability agent and have access to OpenTelemetry data from a demo application. Users have reported issues using the application, can you identify what is the issue, the root cause and suggest potential solutions?

LLM response 1 (snippet):

Issue The application is experiencing high latency, with the frontend-proxy service being the most affected. The P95 latency for this service is over 1 second, which is significantly impacting the user experience. ### Root Cause The root cause of the high latency is long-running calls from the frontend-proxy service to the flagd.evaluation.v1.Service/EventStream endpoint of the flagd service. The trace analysis shows that these calls can take over 3 minutes to complete. This is because the EventStream is a streaming endpoint designed to provide real-time updates of feature flags. The frontend-proxy is making a request to this endpoint and holding the connection open, which is causing the long-running spans and, consequently, the high latency. The canceled: "true" attribute on the router flagservice egress span in the frontend-proxy service suggests that the proxy is timing out and canceling the request. However, the flagd service does not seem to be handling this cancellation correctly and continues to process the request, keeping the stream open for an extended period. ### Solution To resolve this issue, the following actions are recommended: * Use a Short-Lived RPC for Feature Flag Evaluation: Instead of using the EventStream endpoint, the frontend-proxy should use a more appropriate, short-lived RPC for fetching feature flags. This will ensure that the connections are not held open for extended periods, reducing the latency of the frontend-proxy service. * Investigate the flagd Service: The flagd service should be investigated to understand why it's not handling client-side cancellations correctly. The developers should ensure that the service gracefully handles canceled requests and closes the streams promptly. * Review the frontend-proxy Configuration: The frontend-proxy's configuration should be reviewed to ensure that it's correctly handling streaming responses and that the timeouts are set to appropriate values. By implementing these solutions, you should be able to significantly reduce the latency of the frontend-proxy service and improve the overall performance and reliability of your application.

Prompt 2:

Users have reported issues during the payment process

LLM response 2 (snippet):

Based on my investigation, I've identified the root cause of the payment issues and have recommendations for a solution. ### Summary of Findings * No Explicit Errors: My initial search for traces and logs with an "ERROR" status for the payment service came up empty. This indicates that the application is not correctly flagging these issues as errors. * Anomalous Span Names: An analysis of the service's trace data revealed a peculiar pattern: spans being created with names that are actually error messages. For example: * Error: Payment request failed. Invalid token. app.loyalty.level=gold * Error: The credit card (ending 1791) expired on 1/2025. * Error Context: By examining these "error spans," I found that the "Invalid token" error consistently occurs for users with the app.loyalty.level attribute set to gold. ### Root Cause The user-reported payment issues are caused by a bug in the payment service that specifically affects customers with a "gold" loyalty status. When these users attempt to make a payment, the service fails with an "Invalid token" error. Furthermore, the application is handling these errors incorrectly from an observability standpoint. Instead of setting the status of the parent span (e.g., the charge or grpc.oteldemo.PaymentService/Charge span) to ERROR, the developers have written code that creates a new, zero-duration span with the error message as its name. This practice hides the errors from standard monitoring dashboards and makes it difficult to track the error rate of the service. ### Recommended Solutions 1. Fix the Payment Logic: * Immediate Priority: The development team must investigate and fix the bug in the payment service that causes token validation to fail for "gold" loyalty members. This is the primary cause of the user-facing issue. 2. Correct the Instrumentation: * Best Practice: The practice of creating new spans to log errors should be stopped. Instead, developers should adhere to OpenTelemetry best practices: * When an error occurs, the StatusCode of the existing span in which the error happened should be set to ERROR. * The error details should be recorded as an Event (also known as a Log) within that span, including attributes for the exception type, message, and stack trace. This ensures that errors are properly tracked, correlated with traces, and can be used to trigger alerts. By addressing both the underlying bug in the payment logic and the incorrect instrumentation, you will resolve the user-reported issues and significantly improve the observability and reliability of your application.

Anomaly 2

Recommendation cache 서비스에 문제가 도입되어 서비스 CPU 사용률이 급증합니다.

조사는 로그에서 시작합니다. 오류 메시지가 증가하는 것을 볼 수 있습니다.

스크롤해도 근본 원인이 바로 보이진 않습니다. ⨯ Error: 14 UNAVAILABLE: No connection established. Last error: connect ECONNREFUSED 34.118.225.39:8080 (2025-07-22T11:05:44.834Z) 같은 연결 문제 메시지의 오류가 여러 건 보입니다.

trace explorer 뷰를 에러 trace만 선택하도록 필터링하고, 많은 노이즈를 만드는 load-generator 서비스를 제외합니다.

Recommendation 서비스 관련 오류가 보입니다. recommendation 서비스 trace만 필터링해 보겠습니다.

실험 중 trace가 감소하는 것으로 보입니다. Services 뷰에서 recommendation 서비스의 요청 처리량(throughput)으로 검증해 보겠습니다.

Recommendation 서비스 처리량은 떨어지고, 지연은 증가했습니다. 즉 서비스가 여전히 응답은 하지만 훨씬 느려져, 타임아웃이나 연결 오류로 이어지는 병목을 만들 가능성이 큽니다.

Traces로 돌아가 Event deltas로 trace들 사이의 공통 패턴을 찾을 수 있는지 확인해보겠습니다.

Event deltas 화면에서 get_product_list 함수로 필터링하면, outliers 속성을 사용해 빠른 요청과 느린 요청을 비교할 수 있습니다.

이 경우 outlier(느린) 요청은 10개 이상의 제품을 반환하는 경향이 있고, recommendation cache가 활성화되어 있습니다.

캐시가 활성화된 요청에서, 제품 수가 많고 캐시 미스가 발생하면 요청 시간이 증가하는 것을 관찰했습니다.

이 문제는 recommendation cache와 선택된 제품 수(볼륨)와 관련이 있습니다.

Claude Sonnet 4

Recommendation 서비스로 근본 원인을 좁히긴 했지만, 처음에는 캐시 이슈를 식별하지 못했습니다.

진행은 제한적이었습니다. resource exhaustion으로 recommendation 서비스가 실패한다고 관찰했고, 서비스가 12번 재시작했다는 점(우리가 수동 조사에서 찾지 못한 부분)을 확인했습니다.

또한 재시작의 원인이 메모리가 아니라 CPU 제한 도달 때문이라고 식별했습니다. 유용한 디테일이지만, 핵심인 캐시 관련 이슈는 놓쳤습니다.

이는 흔한 패턴을 반영합니다. 모델이 하나의 추론 줄기에 고착되고 다른 가능성을 탐색하지 않는 경향이 있습니다.

"왜 pod가 CPU를 100% 쓰는가"를 후속 질문으로 던지자, recommendation 서비스 캐시 동작 문제를 드디어 정확히 집어냈습니다.

(전체 상호작용은 원문 참조)

OpenAI o3

Recommendation 서비스가 접근 불가해졌다는 것은 잡았지만 이유는 설명하지 못했습니다. 질문을 바꿔 재요청하자 pod 크래시를 발견했지만 정확한 원인은 못 찾았습니다. 메모리 이슈 또는 feature flag를 제시했는데, 방향성은 맞았습니다.

메모리 관점을 더 압박하자 cache-enabled 플래그가 유력한 근본 원인이라고 식별했습니다. 다만 해결책으로는 애플리케이션에 존재하지 않는 코드를 제시하는 등 유효하지 않은 수정을 제안했습니다(소스 코드 접근이 없기 때문).

(전체 상호작용은 원문 참조)

OpenAI GPT-4.1

스스로는 잘 못 찾았습니다. 명시적으로 시키기 전까지 MCP 도구로 데이터를 쿼리하지 않았고, 기본적으로 로그에만 집중하며 trace/metric도 보라고 추가 프롬프트가 필요했습니다.

데이터를 확인한 뒤에는 flagd 서비스를 병목으로 지목했는데, 일부는 맞지만 수동 조사가 보여준 주된 이슈는 아니었습니다.

recommendation 서비스를 보라고 지시했으나, 캐시 문제는 우리가 명시적으로 언급했을 때에야 나왔습니다.

(전체 상호작용은 원문 참조)

Gemini 2.5 Pro

초기에 데이터베이스/테이블을 탐색해 traces/logs/metrics가 있음을 확인했지만, 실제 조사는 로그나 메트릭을 전혀 고려하지 않고 trace만으로 진행했습니다. 그 결과 잘못된 문제에 고착되었습니다.

로그도 보라고 프롬프트하자 올바른 방향(추천 서비스 타임아웃)으로 가는 듯했지만, 이유는 찾지 못했습니다. 타임아웃 원인을 캐보라 하자 다시 trace만 사용하며 DNS 문제로 결론 내렸습니다(데이터에 DNS 오류가 있으나 해당 서비스와 무관). 로그를 보라고 재차 요청해도 진전이 없었습니다.

메트릭 테이블을 보라고 하자 pod가 CPU 100%에 도달한다는 사실을 발견했지만, 더 깊게 파지 않았습니다. 왜 100%인지 묻자 루프에 빠졌고, 결국 증거 없는 가상의 원인을 만들기 시작했습니다.

Gemini는 “독(poisoned) product ID”가 원인이라고 확신하고 이를 뒷받침할 것을 찾으려 했지만 실패했고, 최소한 이를 인정하긴 했습니다.

특정 타임아웃 시점의 리소스 사용을 보라고 하자, CPU 100%는 문제가 아니라고 버리고 다시 DNS로 되돌아갔습니다(맞지 않습니다).

(전체 상호작용은 원문 참조)

Anomaly 3

사용자들이 간헐적으로 애플리케이션 사용 중 문제를 보고하는데, 특히 제품 페이지 접근 시 두드러집니다.

Client sessions 화면에서 오류가 있는 세션을 봅니다.

Products API에서 빈번한 오류가 보이고, 이는 사용자에게 빈 제품 페이지를 보여줍니다.

영향 받은 세션의 trace에서 오류는 oteldemo.ProductCatalogService/GetProduct. span에서 나타납니다.

추가 조사로, Traces 뷰를 해당 span name으로 필터링하고 에러 상태인 trace에 집중합니다.

product ID 컬럼을 추가하면, 모든 오류가 동일 제품 OLJCESPC7Z에 묶여 있음을 확인할 수 있습니다. 특정 아이템에 문제가 있을 가능성이 큽니다.

오류 없는 해당 product ID 호출을 보면, 로그 메타데이터에서 제품명을 확인할 수 있습니다.

사용자들은 제품 ID: OLJCESPC7Z(“National Park Foundation Explorascope”) 제품 페이지 접근 시 문제를 겪고 있습니다.

Claude Sonnet 4

처음에는 feature flag와 product catalog 함수 실패 관련이라는 점은 찾았지만, 어떤 제품이 실패를 일으키는지는 특정하지 못했습니다. 후속 프롬프트로 유도하자 해당 제품을 식별했습니다.

OpenAI o3

처음 프롬프트 후에는 feature flag와 product catalog 함수 실패를 찾았지만 특정 제품은 분리하지 못했습니다. 두 번째 프롬프트에서 제품 ID는 맞췄지만, 설득력 있는 방식으로 잘못된 제품명을 반환했습니다.

OpenAI GPT-4.1

처음에는 MCP로 데이터를 쿼리하지 않아 쓸만한 결과가 없었습니다. ClickHouse 데이터에 접근한 이후에도 고수준 서비스 행태에만 머물러 의미 있는 RCA를 내지 못했고, 많은 추가 가이던스가 필요했습니다. 결국 제품 카탈로그 서비스 이슈와 feature flag를 식별했지만, 제품 책임 소재는 바로 못 찾았습니다. 최종적으로 제품 ID는 맞췄으나 제품명은 못 찾았습니다.

Gemini 2.5 Pro

첫 단순 프롬프트에서 바로 정답에 도달했습니다. 주문이 특정 제품 때문에 실패한다는 점을 식별하고 올바른 제품 코드를 공유했습니다.

Demo anomaly

사용자들이 체크아웃 과정에서 문제를 겪고 결제가 진행되지 않습니다.

수동 조사 워크스루는 이미 문서에 설명되어 있습니다.

Claude Sonnet 4

첫 프롬프트에서 문제를 찾았습니다. 결제 서비스 캐시가 꽉 차면 체크아웃에서 문제가 발생한다는 결론입니다.

OpenAI o3

마찬가지로 첫 프롬프트에서 결제 서비스의 “Visa validation cache”가 100,000 항목으로 고정 용량이며 eviction/TTL 없이 가득 차면 “cache full” 예외를 던지는 것이 근본 원인이라고 찾았습니다.

OpenAI GPT-4.1

첫 프롬프트에서는 load-generator/프런트 관련 오류에 집중해 유효한 단서를 못 찾았습니다. 체크아웃 이슈라는 맥락을 주고 결제 서비스로 좁히자, 마지막에 Visa 캐시가 가득 찼다는 근본 원인을 식별했습니다.

Gemini 2.5 Pro

테스트 데이터에는 반복되지만 문제가 아닌 오류(노이즈)가 다수 존재합니다. Gemini는 그 중 하나를 잡고 잘못된 길로 고착되었습니다. 이후 방대한 표를 생성하려 하며 비효율적으로 진행해 중단했습니다.

체크아웃으로 영역을 좁혀주는 추가 프롬프트를 줬더니 데모 feature flag(cartFailure)를 발견하고(이 테스트에서는 꺼져 있었음), 이것이 근본 원인이라며 오히려 플래그를 켜라고 안내했습니다(그러면 새로운 실패 모드를 도입하게 됨).

feature flag에서 벗어나게 유도해도 진전이 거의 없었고, 결국 더 많은 로깅이 필요하다고만 결론 냈습니다.

모델 비교

4가지 유형의 이상으로 모델들을 도전시켰고, 성능은 제각각이었습니다.

다음 점수 기준으로 비교해 보겠습니다:

1. 근본 원인 식별(5점)

• 0 = 근본 원인을 찾지 못함
• 1.5 = 많은 가이던스가 있으면 찾음
• 3 = 약간의 가이던스가 있으면 찾음
• 5 = 독립적으로 찾음(가이던스 없음)

2. MCP 호출 수(1점): 호출이 적을수록 더 효율적인 추론을 의미

• 1 = 10회 이하
• 0.5 = 10~15회
• 0 = 15회 초과

3. 해결 시간(1점)

• 1 = 3분 이하
• 0.5 = 4~6분
• 0 = 6분 초과

4. 비용 효율(1.5점)

• 1.5 = $1 이하
• 0.75 = $1~$3
• 0 = $3 초과

5. 토큰 효율(1.5점): 총 토큰(입력+출력), 낮을수록 좋음

• 1.5 = 200,000 미만
• 0.75 = 200,000~1,000,000
• 0 = 1,000,000 초과

이 점수 체계를 적용한 결과는 다음과 같습니다.

이 점수 기준에서는 o3 모델이 벤치마크에서 가장 높게 랭크되었습니다. 조사 역량은 Claude Sonnet 4와 비슷하지만 더 적은 토큰을 사용합니다.

GPT-4.1은 비용 효율이 가장 좋아 흥미로운 선택지입니다. 하지만 조사 역량은 이번 평가에서 가장 진보한 모델들인 Sonnet 4와 o3에 비해 크게 뒤처졌습니다.

Claude Sonnet 4와 OpenAI o3가 이상 조사와 근본 원인 식별에서 가장 좋은 성능을 보입니다. 흥미롭게도 이들의 추론 능력이 Gemini 2.5 Pro보다 반드시 높다고 볼 수는 없는데도 더 좋은 결과를 냈습니다. 이는 모델의 측정된 “IQ”가 실제 성공률의 강한 지표가 아닐 수 있음을 시사합니다.

조사당 비용을 시각화하면 모델 간 차이와 예측 불가능성을 더 쉽게 비교할 수 있습니다.

OpenAI 모델들, 특히 GPT-4.1은 Claude Sonnet 4와 Gemini 2.5 Pro보다 조사 중 토큰 사용량이 적어 비용이 낮은 경향이 있습니다.

결론: 자율 SRE 에이전트로서의 LLM은 아직 부족하다

이번 실험은 범용(general-purpose) LLM이 완전 자율 SRE 에이전트로 활동하기에는 아직 충분히 신뢰할 수 없다는 것을 보여줍니다.

우리는 4개의 작은 데이터셋(각각 보통 1시간 분량의 텔레메트리, 데모 데이터는 48시간)을 사용했고, 의도적으로 이상을 주입했습니다. 이러한 합성(synthetic) 이상은 관련 없는 배경 노이즈가 적고 비교적 탐지하기 쉽습니다. 이는 현실의 프로덕션 환경 복잡성을 반영하지 않습니다.

이렇게 단순화된 조건에서도, 어떤 모델도 가이던스 없이 항상 근본 원인을 찾지 못했습니다. 4개 시나리오 중 2개에서는 가장 진보한 모델조차도 추가 가이던스가 필요했습니다. 어떤 모델은 상당한 가이던스가 있어도 근본 원인을 전혀 찾지 못했습니다.

다만 우리의 접근은 의도적으로 순진했습니다. 컨텍스트 보강(context enrichment), 프롬프트 엔지니어링, 파인튜닝 같은 고급 기법을 적용하지 않았습니다. 이런 전략은 모델 성능을 크게 올릴 수 있음을 인정합니다.

각 이슈 조사에는 6~27개의 데이터베이스 쿼리가 필요했습니다. 데이터셋이 작았지만, 현실의 텔레메트리 워크로드는 훨씬 큽니다.

관측 가능성 워크플로에 LLM에게 DB 직접 접근을 주면, 쿼리 부하가 크게 늘어납니다. 시스템이 확장될수록 DB는 지연을 해치지 않으면서 추가 부하를 감당해야 합니다. 이런 LLM 통합을 실용적으로 만들려면 빠르고 확장 가능한 DB 성능이 필수입니다.

토큰 사용량은 모델과 시나리오에 따라 수천에서 수백만까지 크게 달랐습니다(모델, 프롬프트 수, 외부 도구 사용(MCP 호출) 횟수 등에 의존).

무엇이 토큰 소비를 주도하는지 항상 명확하지 않습니다. 특정 상황에서 모델이 얼마나 토큰을 쓸지 추정하거나 예측하기가 어렵고, 비용 통제/예측도 어렵게 만듭니다.

이런 예측 불가능성 때문에, 특히 비용이 중요할 때 LLM을 자동화된 관측 가능성 워크플로에 포함시키는 것은 위험할 수 있습니다.

그래도 가치가 있다면: RCA 보고서 작성 자동화

LLM이 완전 자율 SRE 에이전트로 적합하지 않다는 결론에 도달한 후, 더 단순하지만 시간이 많이 드는 작업을 맡기는 보조 역할로서 가치를 줄 수 있는지 확인했습니다.

이를 테스트하기 위해, 수동 조사 결과를 바탕으로 LLM에게 RCA 보고서 작성을 맡기는 실험을 진행했습니다.

예시로 demo anomaly 데이터셋과 Claude Sonnet 4를 사용했습니다. 다음 프롬프트를 주었습니다.

You’re an observability agent, and will help me writing up a RCA report for an issue we investigated recently on our application. You have access to the raw OTel data that you can query using ClickHouse. Users have been reporting issues when checking out their order. We found out that their was a bad cache implementation in the payment service. Please get the data you need from the ClickHouse to write the RCA report.

모델은 로그/트레이스/메트릭을 모두 쿼리해 원인과 시스템 영향을 이해한 뒤, 포괄적인 보고서를 생성했습니다.

Root Cause Analysis Report Payment Service Cache Implementation Issue ⸻ Executive Summary On July 28–29, 2025, our e-commerce platform experienced significant checkout failures due to a poorly implemented cache mechanism in the payment service. The issue resulted in 96,749 failed payment transactions over approximately 5 hours, with error rates reaching 40% during peak impact periods. ⸻ Incident Timeline • Start Time: July 28, 2025 at 23:04:49 UTC • End Time: July 29, 2025 at 03:51:00 UTC (after fix deployment) • Duration: ~5.75 hours • Peak Impact: July 29, 00:00–03:00 UTC ⸻ Impact Assessment User Impact • Failed Checkouts: 96,749 checkout attempts failed • Error Rate: Up to 40% of all payment processing requests • Affected Users: Customers attempting to complete purchases during the incident window • Revenue Impact: Significant loss due to failed transactions ⸻ Performance Metrics • Average Checkout Duration: 233ms for failed transactions • Payment Service Duration: 106ms average for cache errors • Transaction Volume: ~25,000 checkout attempts per hour during incident ⸻ Root Cause Analysis Primary Root Cause The payment service implemented a poorly designed Visa payment cache with the following critical flaws: 1. Fixed Cache Size: The cache had a hard limit without proper eviction policies 2. No Cache Management: No mechanism to remove old or expired entries 3. Blocking Behavior: When full, the cache rejected new payment requests instead of evicting old entries

이 결과는 다양한 모델과 이상 유형에서 일관되게 강했습니다. 두드러지는 점은, 모든 모델이 초기 프롬프트만으로 RCA 보고서의 탄탄한 1차 초안을 만들어냈다는 것입니다. 따라서 이 사용 사례는 SRE 워크플로 내 자동화 후보로 좋습니다.

내부 보고 표준이나 회사 정책에 맞춘 템플릿을 포함하면 더 개선할 수 있습니다.

또 하나의 후보: GPT-5

이 블로그 포스트를 준비하던 중 OpenAI가 GPT-5를 출시했습니다. 우리는 이를 실험에 포함해 봤습니다. 어쩌면 최고의 성능을 내면서 LLM을 자율 관측 가능성 에이전트로 보는 관점을 바꿀지도 모릅니다.

다른 모델 대비 성능은 아래 표로 요약됩니다.

GPT-5는 OpenAI o3와 사실상 박빙입니다. 공정하게 말하면 원시 수치상 토큰을 훨씬 덜 쓰지만, 우리의 점수 체계가 그 미세한 차이를 충분히 반영하진 못합니다. 승자를 선언할 수도 있습니다.

하지만 최신 모델조차도 매번 근본 원인을 찾지는 못합니다. 이는 이번 실험에서 받은 인상—성능이 단순히 IQ에만 묶여 있지 않다—을 뒷받침합니다.

짧은 답: LLM은 스스로 RCA를 수행할 준비가 되어 있지 않다. 하지만 이를 수행하는 사람에게는 유용한 조력자다.

우리의 설정은 의도적으로 단순했습니다. 원시 텔레메트리와 평범한 프롬프트—컨텍스트 보강도, 도구도, 파인튜닝도 없음. 그 조건에서 모든 모델은 때때로 이상을 놓쳤고, 일부는 원인을 환각(hallucinate)했습니다. 최신 프론티어 모델(GPT-5)도 시험했지만, 기존 경쟁자를 압도하지 못했습니다. 병목은 모델 IQ가 아니라, 컨텍스트 결핍, 약한 그라운딩(grounding), 도메인 특화 부족입니다.

많은 회사가 LLM 기반 관측 가능성을 테스트하는 이유는 약속이 매력적이기 때문입니다. 생산 이슈를 더 빠르고 더 낮은 비용으로 찾는 것. 우리도 그렇습니다. 하지만 관측 가능성 데이터에 대한 접근 권한을 LLM에 주고 “이제 끝”이라고 하는 것은 작동하지 않습니다. 컨텍스트 보강, 도메인 튜닝 모델, 관측 가능성 도구로의 함수 호출 같은 고급 접근이 도움이 될 수 있지만, 비용과 운영 오버헤드를 추가하며, 여전히 깨끗하고 잘 인덱싱된 데이터와 명확한 시스템 뷰가 필요합니다.

오늘날 잘 작동하는 것은 엔지니어 + 플랫폼 + 속도(+ LLM) 입니다. 빠른 분석 DB 위에 관측 가능성 인터페이스를 제공해, 엔지니어가 큰 시간 범위에서도 로그/메트릭/트레이스를 몇 초 만에 슬라이스할 수 있게 하세요. 같은 인터페이스에서 LLM은 사람을 루프에 둔 채로 잡무를 처리합니다:

• 노이즈 많은 로그/트레이스 요약
• 상태 업데이트 및 포스트모템 섹션 초안 작성
• 따라야 할 조사 계획 제안
• 조사 데이터 리뷰 및 발견 사항 검증

가치는 LLM 단독이 아니라, 실제 협업을 가능하게 하는 공유 인터페이스에 있습니다.

그렇다면 지금 LLM이 SRE를 대체할 수 있을까요? 아니요.

빠른 관측 가능성 스택과 결합했을 때 인시던트 시간을 줄이고 문서화를 개선할 수 있을까요? 예.

앞으로의 길은 더 나은 컨텍스트와 더 나은 도구이며, 엔지니어가 통제권을 갖는 것입니다.