SRE가 AI 에이전트에게 전하는 메시지: 운영 환경에 접근하기 전에 실력을 증명하라

다운타임(downtime)에 대한 사용자 불만을 요약하는 데 AI 에이전트를 신뢰하는 것과, 아무런 감독 없이 문제를 해결하도록 신뢰하는 것은 완전히 별개의 문제입니다.

2026년 4월 The Register가 NeuBird AI와 함께 실시한 696명의 전문가 대상 설문조사에 따르면, 73%는 AIOps를 전혀 사용하지 않고 있으며, 19%는 파일럿(pilot) 단계에 있고, 단 8%만이 실제 운영 환경(production)에서 사용하고 있는 것으로 나타났습니다.

무엇이 발목을 잡고 있는지 묻는 질문에 응답자의 60%가 신뢰 부족을 가장 큰 문제로 꼽았으며, ROI(투자 대비 효율), 보안, 데이터 품질에 대한 우려가 각각 약 12%에서 13%를 기록했습니다.

NeuBird AI의 Production Ops Agent는 이러한 신뢰 결핍을 해소하도록 설계되었습니다. 이 에이전트는 단순히 경고(alert) 대기열을 요약하는 대신, 메트릭(metrics), 로그(logs), 트레이스(traces), 인프라 텔레메트리(infrastructure telemetry), 배포 활동 및 의존성 관계를 지속적으로 상관 분석(correlates)합니다. 그런 다음 결합된 전체 그림을 바탕으로 조사를 수행하여 가능한 근본 원인(root causes)과 다음 조치 사항을 제안합니다. 또한 이 에이전트는 상류(upstream) 단계에서도 작동합니다. 소음이 많은 경고 대기열에 더 빠른 응답기를 덧붙이는 대신, NeuBird AI는 에이전트 기반 계측(agentic instrumentation)을 통해 소스 단계에서 관측성(observability)을 해결합니다. 이를 통해 적절한 신호를 생성하므로 경고 자체가 설계 단계부터 고신호(high-signal)를 갖게 됩니다. Martel이 언급했듯이, 핵심은 출력을 패치하는 것이 아니라 소스에서 관측성을 해결하는 것입니다. "기존 대기열에 자체 제작한 에이전트를 투입하는 것은 문제를 해결하지 못합니다. 소음(noise)에 대해 DIY(직접 제작)를 하는 것은 여전히 소음일 뿐이기 때문입니다."

현장 최고 기술 책임자(Field CTO)인 Francois Martel은 The Register와 만나 설문조사 결과와 왜 AIOps의 다음 단계가 엔지니어들이 지난 10년 동안 바라봐 온 대시보드와 전혀 다른 모습일 것인지에 대해 논의했습니다. 그는 또한 SRE 팀이 에이전트를 운영 시스템 근처에 허용하기 전에 무엇이 변해야 하는지에 대한 견해를 밝혔습니다.

많은 관심, 매우 적은 배포

데이터는 Martel이 현장에서 이미 듣고 있던 내용을 확인해 주었습니다. "관심은 많지만, 실제 행동으로 이어지는 경우는 많지 않습니다."라고 그는 말합니다. 이러한 패턴은 에이전트 워크로드 (agentic workloads) 전반에서 익숙하게 나타납니다. 코딩 에이전트 (coding agents)나 콘텐츠 생성 (content generation)과 같이 명확한 인간 참여 (human in the loop)와 명확한 검증 경로가 동반되는 카테고리들은 급성장했습니다. 반면 운영 (Operations)은 더 어렵습니다. 왜냐하면 작업이 실행 중인 환경 내부에서 발생하며, 엔지니어가 아직 보지 못한 데이터를 대상으로 하고, 그 결과가 고객 대면 시스템 (customer-facing systems)에 직접적으로 나타나기 때문입니다.

그는 NeuBird에 합류하기 훨씬 전부터 기업 내부에서 동일한 격차를 목격했습니다. 300개의 AI 수정 후보군이 쌓여 있고 초기 열기가 가득하지만, 첫 번째 수정 사항이 배포되기까지 1년 동안의 고된 과정이 뒤따르는 모습이었습니다.

그러한 지연의 일부는 시장 발전 속도 때문이기도 합니다. 도구가 사용자의 기대치에 맞춰질 때까지 6개월을 기다리는 것이 때로는 올바른 결정일 수 있기 때문입니다.

또 다른 이유는 도구 카테고리를 잘못 선택했기 때문입니다. 범용 에이전트 (general-purpose agents)는 SRE 문제에 적합하지 않습니다.

"훨씬 더 나은 작업을 수행할 수 있는 특화된 에이전트들이 있으며," Martel은 말합니다. "이들은 안전성 (safety), 보안 (security), 가드레일 (guardrails), 그리고 환각 (hallucinations)과 같은 우려 사항 중 일부를 해결할 수 있습니다." 또한 도구는 팀의 기존 워크플로 (workflows)에 부합해야 합니다.

신뢰는 선언하는 것이 아니라 구축하는 것

Martel은 설문 조사에서 드러난 신뢰 중심의 우려 사항들에 대해 논쟁하려 하지 않습니다. "AI와 함께 일하는 것은 신뢰를 구축하는 과정이며, AI는 신뢰를 얻기 위해 학습해야 합니다."라고 그는 말합니다. "저는 그것이 AI 에이전트의 일종의 킬러 기능 (killer feature)이라고 말하고 싶습니다. 당신이 학습하고 개선되고 있다는 것을 보여줄 수 있다면, 신뢰를 얻을 수 있습니다."

그렇기 때문에 설명 가능성 (explainability)은 보안 검토를 위해 사후에 덧붙여진 것이 아니라, NeuBird AI 설계의 중심에 자리 잡고 있습니다. 이 플랫폼은 모든 결정 뒤에 숨겨진 추론 과정을 기록하므로, 엔지니어는 동료의 장애 보고서(incident report)를 심문하듯 이를 심문할 수 있습니다. "에이전트가 있다면, 내려진 결정들을 감사(audit)할 수 있어야 하고 그 결정 뒤에 있는 추론을 이해할 수 있어야 합니다."라고 Martel은 말합니다. 내부적으로 NeuBird AI는 Langfuse를 통해 모든 추론 단계를 캡처합니다. 설명 가능성은 절반에 불과합니다. 이 플랫폼은 SOC 2 Type II 인증을 받았으며, 읽기 전용(read-only)이고 아무것도 저장하지 않으므로, 신뢰는 단순히 추론뿐만 아니라 아키텍처 자체에 내장되어 있습니다. 외부적으로 더 어려운 문제는 표현 방식입니다. 시스템의 초기 버전은 너무 많은 세부 정보를 노출하여 사용자들이 이를 '텍스트의 벽'이라고 묘사하기도 했습니다. 해결책은 추론 내용을 단순히 쏟아내는 것이 아니라 심문 가능한(interrogable) 형태로 만드는 것이었습니다. 이를 통해 엔지니어들은 더 선임인 팀원에게 질문하듯 시스템의 메모리와 대화할 수 있습니다.

맥락(Context)이 답변의 신뢰성을 만든다

동일한 설문 조사에 따르면, 응답자의 59%는 도입 전 거의 완벽한 정확도를 요구하는 반면, 10명 중 3명은 약 80%의 정확도는 용인할 것이라고 답했습니다. 이 기준은 매우 엄격하며, Martel은 이것이 더 큰 모델이 아닌 더 나은 맥락 엔지니어링 (context engineering)을 통해서만 통과될 수 있다고 주장합니다.

"정확도의 핵심은 놓치는 것이 없도록 하는 '충분한 맥락'과 그 '맥락의 발견 가능성 (discoverability)' 사이의 최적의 지점(sweet spot)을 찾는 것입니다."라고 그는 말합니다. "물론 맥락이 너무 많아서도 안 됩니다." 그는 데스크톱에 코딩 에이전트(coding agent) 하나만 가지고 있는 사람이라면 누구나 도달할 수 있는 범위를 넘어선 균형을 갖춘 솔루션을 만드는 것이라고 주장합니다.

NeuBird AI의 주장은 대부분의 장애(outage)가 단일 대시보드나 서비스 내부에서는 추론될 수 없다는 사실에 근거합니다. SRE 팀이 필요할 만큼 규모가 큰 모든 기업은 스토리지와 네트워킹부터 운영 플랫폼과 애플리케이션에 이르기까지, 특히 마이크로서비스 (microservices)가 자산을 파편화한 이후 기술 스택 전반에 걸쳐 사일로 (silos)가 존재합니다.

조사는 단 한 명의 인간도 전체를 완전히 파악할 수 없는 경계를 가로질러야 합니다. NeuBird는 사고가 발생하기 전에 의존성 매핑 (dependency mapping)을 수행함으로써 이 문제를 해결하며, 이를 통해 조사가 시작될 때 시스템은 이미 어디를 살펴봐야 하는지, 그리고 각 요소가 어떻게 연결되어 있는지를 알고 있게 됩니다.

지금은 코파일럿 (Co-Pilot), 자율성은 나중에 – 어쩌면

이번 연구에서 가장 명확한 신호이자 Martel이 가장 놀랍지 않게 받아들인 부분은 코파일럿 (co-pilot) 모델에 대한 선호도입니다. 응답자의 62%가 AI가 자신을 대체하기보다는 보조하기를 원한다고 답했습니다.

그는 코딩 에이전트 (coding agents)를 다루는 자신의 작업에서도 이러한 단계를 인지하고 있지만, 동시에 진화하는 궤적 또한 인정합니다. 1년 전만 해도 그는 코딩 에이전트에게 단 1분도 자리를 비울 수 없었지만, 이제는 위험 모드 (dangerous mode)로 전환하여 에이전트가 스스로 실행하게 만들고 싶은 유혹을 느낍니다. 하지만 그는 여전히 모든 것을 확인하고 설계합니다. 그는 "제 책임을 완전히 포기하지는 않을 것입니다"라고 말합니다.

그가 설명하는 운영 (operations)을 위한 실용적인 경로도 이와 유사해 보입니다. NeuBirdAI는 Ansible의 모델 컨텍스트 프로토콜 (Model Context Protocol, MCP) 서버를 통해 자동화를 연결하기 시작했으며, 특정 플레이북 (playbooks)은 운영 환경에서 자동화해도 안전한 것으로 표시하고 나머지는 인간의 승인을 거치도록 제한하고 있습니다.

알려진 한계치까지 포드 (pod)에 메모리를 추가하는 것은 에이전트가 처리할 수 있는 일이지만, 그보다 위험한 작업은 사람을 기다려야 합니다. Martel은 엔지니어가 업무를 얼마나 위임할지는 그들의 위험 감수 성향과 도구와 함께 작업하며 쌓아온 경험에 달려 있다고 말합니다.

5분의 시계와 워룸 (War Room)의 종말

응답 시간은 AIOps 브리프의 핵심입니다. 설문 응답자의 절반 이상이 5분 이내에 운영 관련 해답을 얻기를 기대하며, 75%는 10분 이내를 원합니다. 이는 이러한 속도에 맞춰 설계되지 않은 워크플로 (workflows)에 엄청난 압박을 가합니다. 6명의 전문가를 숙지시키고 그들을 워룸 (war-room) 컨퍼런스 브리지로 불러 모으는 데는 SLA (Service Level Agreement)가 수용할 수 없는 시간이 소요됩니다.

Martel의 주장은 시간이 흐르기 전에 온콜 (on-call) 경험이 먼저 변해야 한다는 것입니다. "당신은 다른 20개 팀과 함께 콜(call)에 참여하고 있지 않은 상황에 도달하기를 원할 것입니다. 대신, 무슨 일이 일어나고 있는지에 대한 설명이 요약된 문서 앞에 서서, 그 문서가 해결책을 제시하거나 혹은 누가 개입해야 하는지를 알려주는 상황 말입니다."라고 그는 말합니다.

에이전트 (Agent)가 엔지니어가 로그인하기 전에 사전 작업을 수행하므로, 엔지니어가 도착할 때쯤이면 초기 분류 (triage) 질문들은 이미 답변된 상태이며 오직 흥미로운 결정들만이 남아 있게 됩니다.

이것이 관측성 (Observability) 비용에 의미하는 바

적어도 기존의 관측성 (Observability) 벤더들에게 가장 도발적인 조사 결과는, AI 기반의 통찰 (insights)이 어떤 백엔드 (back-end)에서도 작동한다면 응답자의 52%가 텔레메트리 (telemetry) 도구를 교체하는 것을 고려할 것이라는 점입니다.

이것이 어디로 향할 것인지에 대한 질문에 Martel은 확신을 가지고 답합니다. "미래의 관측성 (observability)은 Grafana, Elasticsearch 또는 OpenSearch와 같이 비용 효율적인 저장소 인덱싱 (storage indexing) 기술을 사용하는 오픈 소스 (open source)가 지배할 것입니다."

그러한 시나리오에서 전략적 자산은 가장 많은 텔레메트리 (telemetry)를 독점하는 쪽에서, 그것을 가장 지능적으로 조사할 수 있는 쪽으로 이동합니다. 이는 가장 저렴한 저장소 계층 (storage layer) 위에 위치하는 컨텍스트 엔진 (context engine)을 의미합니다.

이는 관측성 (observability) 계약 갱신을 앞둔 구매자들에게 유용한 관점입니다. 왜냐하면 그들이 거액을 지불한 대시보드 (dashboards)는 점점 더 머신 리더 (machine readers)를 갖추어 가는 시스템의 인간 가독성 계층 (human-readable layer)이기 때문입니다.

다음 단계는?

이 설문조사는 운영 (operations) 분야에서 AI를 간절히 원하면서도, 증거 없이 결과를 약속하는 벤더들을 의심하는 법을 배운 시장을 묘사하고 있습니다.

Martel의 주장은 향후 2년 동안 살아남을 플랫폼은 기존의 변경 관리 (change-management) 체계를 재작성하라고 요구하는 대신, 자신들의 작업 과정을 보여주고 기존 체계에 녹아드는 플랫폼이 될 것이라는 점입니다. 승자는 운영 컨텍스트 (operational context)를 단순히 프롬프트 채우기 (prompt-stuffing) 연습이 아닌, 일급 엔지니어링 문제 (first-class engineering problem)로 취급할 것입니다.

Martel은 자신의 팀이 뒤처져 있는지 여전히 궁금해하는 SRE 리더들에게 직설적인 답변을 내놓았습니다.

"그는 '평탄한 운영 예산(flat operational budgets)으로 계속해서 증가하는 운영 자산(production estate)을 유지하는 측면에서 이점을 얻을 수 있을 것입니다'라고 말합니다. '만약 이를 채택하지 않는다면, 당신은 무엇을 할 수 있겠습니까? 결국 고전하게 될 것입니다.'"