에이전틱 AI 이해하기: 오픈소스 기반의 프로덕션 레디 AIOps 구축법

대부분의 경우 인시던트 대응 자동화에 에이전틱 AI를 사용한다는 것은 인프라 로그를 프론티어 AI 모델에 전송하는 것을 의미합니다. 호스트 이름, IP 주소, 시스템 토폴리지가 포함된 모든 작업 실패 로그는 대규모 언어 모델(LLM) 엔드포인트에 도달하는 순간 인프라 외부로 전송되며, 이는 금융 서비스 및 의료와 같이 규제가 엄격한 산업의 컴플라이언스 팀에 심각한 위험 신호가 됩니다.

대안으로 이러한 조직은 자체 인프라에서 호스팅되는 오픈소스 모델을 사용하여 데이터 레지던시 및 컴플라이언스 문제를 해결할 수 있습니다. 하지만 오픈소스 AI 모델이 구조화된 운영 태스크에서 대규모 프론티어 모델을 대체할 만큼 뛰어난 성능을 발휘할 수 있을까요? 충분히 가능하다고 판단됩니다. 오픈소스 모델을 적합한 아키텍처 패턴(에이전틱 하네스, 특화된 스킬, 컨텍스트 격리)과 결합하면 훨씬 적은 비용으로 프론티어 모델 수준의 분석을 제공할 수 있습니다.

오픈소스 모델을 사용하여 프로덕션 환경에 적합한 에이전틱 AIOps를 구축하고 확장하는 방법을 구체적으로 살펴보는 3부작 시리즈의 1부를 시작합니다. 오픈소스가 이러한 과제를 해결할 준비가 된 이유, Red Hat OpenShift AI가 일상적인 운영을 간소화하는 방법, 스킬 기반 아키텍처를 통해 번거로운 모델 재학습의 필요성을 없애는 방법을 자세히 설명합니다.

과제: 팀보다 운영 규모가 더 빠르게 확장될 때

솔루션을 논의하기에 앞서, 조직이 AI 증강 인시던트 대응을 도입하게 만드는 운영상의 현실을 살펴보겠습니다.

비즈니스 문제

이번 예시 활용 사례에서는 하이브리드 인프라를 운영하는 영국의 한 금융 서비스 기업을 살펴보겠습니다. 온프레미스 Red Hat Enterprise Linux(RHEL) 가상 머신(VM) 140대와 Red Hat OpenShift 클러스터 3개 규모입니다. 이 기업은 프로비저닝, 패치, 컴플라이언스 스캐닝, 구성 드리프트 수정을 위해 매주 600개 이상의 Red Hat Ansible Automation Platform 작업을 실행합니다.

작업이 실패하면 티켓팅 시스템에 티켓이 생성되고 ChatOps 채널로 알림이 전송됩니다. 얼핏 감당할 수 있는 수준처럼 보이지만, 실제로는 매주 약 40건의 실패 티켓을 처리하고 있습니다. 각 티켓마다 수동 분류, 조사, 그리고 문제 해결이나 에스컬레이션 작업이 필요합니다.

소요 시간 비용: 복잡성에 따라 티켓당 사이트 신뢰성 엔지니어(SRE)의 작업 시간이 45~90분 소요됩니다.

확장 과제: 이를 팀 전체로 확대하고 야간 장애와 온콜 로테이션까지 고려하면 전반적인 시스템 운영상의 문제가 발생합니다. 기업은 인력을 10배 늘리지 않고도 현재 인프라의 10배에 달하는 규모를 처리하기를 원합니다.

규제 압박: 금융 서비스 기업으로서 엄격한 변경 관리 및 인시던트 대응 요구 사항에 따라 운영되어야 합니다. 계획되지 않은 모든 서비스 장애나 구성 드리프트는 정의된 서비스 수준 계약(SLA) 기한 내에 근본 원인, 문제 해결 단계, 담당자 등을 문서화해야 합니다. 이 기한을 지키지 못하면 규제 처벌을 받게 됩니다.

규제 기관은 1분기에 3건의 SLA 위반 사항을 지적했습니다. 각 위반 사항은 조치되지 않고 너무 오래 방치된 Ansible Automation Platform 작업 실패로 거슬러 올라갑니다. 지침은 명확했습니다. "조치 주기를 더 빠르게 단축해야 하며, 이를 준수하고 있다는 감사 증거가 필요합니다."

현재 겪고 있는 문제점:

• 알림 피로도: 매주 40건의 실패 티켓이 발생하며, 대부분 알려진 패턴이 반복됩니다. 온콜 팀의 업무 부담이 가중되어 응답 시간이 지연됩니다.
• 지식 파편화: 런북과 도메인 지식이 Confluence와 개별 담당자에게 흩어져 있습니다. 문제 해결 품질이 일관되지 않습니다.
• 감사 오버헤드: 컴플라이언스를 위한 수동 인시던트 보고서 작성에는 주요 인시던트당 2~3시간이 소요되며, 대부분 사후에 기억과 채팅 로그에 의존해 작성됩니다.
• 에스컬레이션 격차: 단계적이고 유연한 대응 메커니즘 없이 '직접 해결'과 '담당자 호출' 사이의 이분법적 선택만 가능합니다.
• 확장성 한계: 현재 팀 구성으로는 향후 예상되는 성장세를 감당할 수 없습니다. SRE를 추가 채용하는 것은 경제적으로 타당하지 않으며 지식 파편화 문제도 해결하지 못합니다.

기회 요인: 에이전틱 AI는 전체 감사 추적을 남기며 선별, 조사, 조치를 수행하는 동시에 고위험 변경 작업에 대해서는 담당자가 적절히 개입할 수 있도록 지원합니다.

성공 시 예상 결과:

• 평균 해결 시간(MTTR) 단축: 알려진 장애 패턴의 경우 평균 45분에서 목표치인 12분으로 단축됩니다.
• 감사 효율성 향상: 인시던트 보고서가 자동 생성되어 컴플라이언스 팀이 처음부터 작성할 필요 없이 검토만 진행하면 됩니다.
• 확장성: 인력을 비례적으로 늘리지 않고도 10배 늘어난 티켓 볼륨을 처리할 수 있습니다.
• 지식 자산화: 에이전트 패턴을 통해 런북 지식을 지속적으로 개선되는 운영 지식 기반으로 정제합니다.
• 비용 관리: 자체 보유 인프라의 오픈소스 모델 활용 대 외부 제공업체의 토큰당 과금 비교

SRE를 위한 기술적 과제

SRE 관점에서 핵심 과제는 운영 속도와 운영 안전성 간의 균형입니다.

볼륨 및 다양성: 장애는 다양한 도메인에 걸쳐 발생합니다. Ansible Playbook 오류, Linux 패키지 관리 문제, OpenShift 포드 라이프사이클 문제, 네트워킹 DNS/SSH 장애 등이 여기에 해당합니다. 단일 에이전트가 모든 영역의 전문가가 될 수는 없습니다.

컨텍스트 요구 사항: 정확한 인시던트 분석을 위해서는 조직 내부의 지식이 필요합니다. 패키지 설치 실패 시 "No package python3.14 available"이라는 메시지가 표시되면, 일반적인 답변은 "리포지토리 구성을 확인하세요" 수준에 그칩니다. 반면 조직에 특화된 답변은 다음 사항을 참조합니다.

• 조직의 Satellite 서버 토폴리지(기본, 재해 복구, 동기화 일정)
• 팀별 콘텐츠 뷰 모델(어느 팀이 어떤 리포지토리를 사용하는지)
• 에스컬레이션 프로세스(표준 운영 절차(SOP) 참조, 신속 대응 Slack 채널)
• 해당 운영 체제(OS) 버전에 맞는 패키지가 실제로 존재하는지 여부

일반적인 수준의 트러블슈팅은 시간을 낭비하게 만듭니다. 컨텍스트를 인지하는 분석을 통해 문제를 훨씬 빠르게 해결할 수 있습니다.

컴플라이언스 제약 조건: 규제가 적용되는 환경에서는 모든 작업 내역을 추적할 수 있어야 합니다. 로깅 없이 작동하는 AI 에이전트는 컴플라이언스 리스크가 됩니다. 모든 항목(분류 근거, 전문가 분석, 신뢰도 점수, 검토자 판정)을 기록하는 에이전트는 컴플라이언스 자산이 됩니다.

영국 금융행위감독청(Financial Conduct Authority) 감사관은 변경 관리 및 인시던트 대응 기록을 정기적으로 검토합니다. SLA 기한을 넘기는 것은 단순한 조치 지연에 그치지 않고 규제 처벌과 필수 문제 해결 보고서 제출로 이어집니다. 현재 이러한 보고서는 수동으로 작성되며, 주요 인시던트당 2~3시간이 소요되고 사후에 재구성되는 경우가 많습니다.

데이터 주권 요구 사항: 프론티어 모델로의 모든 API 호출은 데이터를 외부로 전송합니다.

{
  "job_id": "3847",
  "host": "rhel-node-01.meridian.internal",
  "error": "fatal: [rhel-node-01]: FAILED! => {\"msg\": \"No package python3.14 available\"}",
  "playbook": "/var/lib/awx/projects/ansible-plays/install-python.yml",
  "credential": "meridian-satellite-sync"
}

이 페이로드는 다음 정보를 외부에 노출합니다.

• 내부 DNS 토폴리지(meridian.internal)
• 인프라 명명 규칙
• 자격 증명 식별자(meridian-satellite-sync)
• 시스템 구성 세부 정보

일반 개인정보 보호 규정(GDPR, 국제 데이터 전송에 관한 제44-49조) 및 DORA(디지털 운영 복원력법)의 규제를 받는 환경에서는 이것이 실질적인 데이터 레지던시 위험을 초래합니다.

운영 요구 사항: 시스템은 다음 조건을 충족해야 합니다.

• 장애를 정확하게 선별 및 분류(적합한 전문가에게 전달)
• 도메인별 근본 원인 분석 수행(일반적인 트러블슈팅 지양)
• 감사 대비가 가능한 인시던트 보고서 생성(컴플라이언스 친화적 결과물)
• 단계적 자율성 지원(고위험 작업의 경우 Human-in-loop, 일상적인 작업의 경우 Human-out-of-loop)
• 성능 저하 없이 10배 늘어난 볼륨을 처리할 수 있는 확장성
• 모델 재학습 없이도 신속한 지식 업데이트(신규 SOP, 인프라 변경 사항) 지원

데이터 주권 문제

EMEA 전역 대기업의 63%가 데이터 주권에 대한 우려를 클라우드 도입의 가장 큰 걸림돌로 꼽았습니다. 운영 데이터를 처리하는 AI 워크로드의 경우 위험 부담이 훨씬 더 큽니다.

Red Hat은 오픈소스가 소버린 AI의 기반이라고 확신합니다. Red Hat OpenShift AI에서 실행되는 오픈 모델을 통해 직접적인 제어 권한을 확보할 수 있습니다. 추론이 실행되는 위치를 직접 선택할 수 있고, 데이터가 플랫폼 외부로 유출되지 않으며, AI 공급망에 대한 완전한 감사 가능성을 유지할 수 있습니다.

이는 일부 기업에 국한된 특수한 우려가 아닙니다. EMEA 기업의 3분의 2 이상이 향후 18개월 동안 데이터 주권을 최우선 IT 과제로 꼽았습니다. 금융 서비스 기업의 경우, 작업 결과물을 외부 LLM 제공업체에 전송하면 컴플라이언스 팀이 용인할 수 없는 규제 노출 리스크가 발생합니다.

기능 격차의 해소

2년 전만 해도 오픈소스 모델을 선택한다는 것은 상당한 기능 격차를 감수해야 함을 의미했습니다. 7B 파라미터 오픈 모델은 환각 현상을 보였습니다. 70B 모델은 복잡한 추론에 어려움을 겪었습니다. 프로덕션 환경에서는 프론티어 모델만이 유일하게 실행 가능한 선택지였습니다.

현재는 훨씬 더 큰 규모의 오픈소스 모델(230B 이상)을 활용할 수 있으므로 이는 더 이상 사실이 아닙니다.

에이전틱 혁명이 판도를 바꾸었습니다

에이전틱 AI(LangChain의 Deep Agents, Anthropic의 Claude Agent SDK, 맞춤형 하네스와 같은 프레임워크)의 등장은 모델 역량에 대한 인식을 완전히 바꾸어 놓았습니다. 에이전틱 하네스는 단순히 프롬프트를 전송하고 기대하는 데 그치지 않고 다음과 같은 작업을 수행합니다.

• 컨텍스트 창을 관리하여 필요한 정보에만 집중하도록 유지합니다.
• 전문가에게 위임하여 특정 도메인에 특화된 하위 에이전트를 생성합니다.
• 마크다운 문서로 로드된 참조 지식과 구조화된 스킬을 제공합니다.
• 출력을 파싱 및 검증하여 체계적이고 실행 가능한 결과를 제공합니다.

이러한 구조화된 접근 방식은 오픈소스 모델과 프론티어 모델 간의 기능 격차를 좁히는 데 기여할 수 있습니다. 잘 설계된 하네스를 갖추면 중간 규모의 오픈소스 모델도 당면한 태스크를 매우 훌륭하게 수행할 수 있습니다.

예시: 패키지 관리 장애 분석

다음은 실제 프로덕션 AIOps 파이프라인에서 도출된 비교 결과입니다. 동일한 장애에 대한 서로 다른 두 모델의 분석 결과입니다.

프론티어 모델(claude-sonnet-4-6):

Root Cause: DNF package manager reports "No package python3.14 available"
Recommended Action: 
1. Verify package name is correct
2. Check repository configuration
3. Consider using EPEL or enabling additional repos
Confidence: 85%

오픈소스 모델(qwen3-235b, MaaS에서 실행):

Root Cause: DNF package manager reports "No package python3.14 available" 
Analysis: Python 3.14 requires CRB (CodeReady Builder) and EPEL repositories.
Target host group indicates AI/ML team workload.
Recommended Action:
1. Submit Content View Request per SOP v2.3
2. Request CRB + EPEL enablement for aiml-workloads content view
3. Escalate via #platform-satellite fast-track (2-hour SLA)
Confidence: 92%

오픈소스 모델은 조직의 Satellite 인프라, 콘텐츠 뷰 모델, 에스컬레이션 경로에 대한 사내 지식이 담긴 마크다운 문서 형태의 AI 스킬을 활용하여 훨씬 더 뛰어난 응답을 생성했습니다. 모델이 학습 데이터를 통해 이를 사전에 학습해 둘 필요는 없었습니다. 컨텍스트 형태로 필요한 정답을 직접 제공했기 때문입니다.

스킬이 핵심적인 역할을 수행합니다

해당 스킬의 구성은 다음과 같습니다.

---

name: analyze-package-management-failure

description: 조직 내 지식(institutional knowledge)을 활용한 패키지 관리 실패 원인 분석

---
# Analyze Package Management Failure
## Institutional Knowledge: Satellite Infrastructure
**Content View Model (per-team):**
- base-rhel9: All RHEL servers, core OS packages only
- ops-tooling: SRE team, monitoring, diagnostic tools
- aiml-workloads: AI/ML team, Python 3.11+, CUDA, data science libs (CRB + EPEL enabled)
**Escalation Path:**
- Standard: Content View Request SOP v2.3
- Fast-track: #platform-satellite channel (2-hour SLA for AI/ML workloads)

모델은 추론 엔진 역할을 수행했습니다. 스킬은 사내 지식을 제공했습니다. 조직의 구체적인 운영 컨텍스트를 인코딩해 두었기에, 이 두 요소가 결합하여 프론티어 모델의 품질을 뛰어넘는 분석 결과를 제공할 수 있었습니다.

비용 방정식

운영 환경에서 프론티어 모델의 가격 부담은 빠르게 누적됩니다.

• 토큰당 과금: 모든 인시던트 분석에는 분류, 전문가 추론, 검토 등 여러 차례의 LLM 호출이 수반됩니다.
• 볼륨 확장: 주당 40건 이상의 장애가 발생하는 환경에서는 토큰 비용이 상당한 지출 항목이 됩니다.
• 비용 상한선 부재: 인시던트 발생 시 사용량이 급증하면 비용을 예측하기 어렵습니다.

자체 인프라에서 실행되는 오픈소스 모델은 고정 컴퓨팅 비용을 유지합니다.

Frontier Model Cost Model:
- $15 per million input tokens
- $75 per million output tokens
- Average incident: ~50K tokens (classification + analysis + review)
- 40 incidents/week × 52 weeks = 2,080 incidents/year
- Annual cost: ~$7,800 in LLM API fees alone
Open Source Model Cost Model:
- Fixed GPU infrastructure (Nvidia A100 or H100)
- Red Hat OpenShift AI subscription
- No per-token billing
- Predictable annual cost regardless of incident volume

매주 수백 건의 인시던트를 처리해야 하는 환경에서는 오픈소스 모델이 경제적인 측면에서 결정적으로 유리해집니다.

Red Hat OpenShift AI 서비스형 모델(MaaS)

Red Hat OpenShift AI는 다양한 GPU 전반에서 vLLM 추론 가속화를 통해 OpenShift에서 실행되는 오픈소스 모델 포트폴리오인 서비스형 모델(MaaS)을 제공합니다.

MaaS에서 제공하는 대표적인 모델은 다음과 같습니다.

프로덕션 환경에서는 단 하나의 모델만 사용하지 않습니다. 에이전트별로 모델을 적절히 혼합하여 활용할 수 있습니다.

• ops_manager(오케스트레이터): qwen3-235b(강력한 분류 및 위임 기능 필요)
• sre_linux(전문가): gpt-oss-120b(특화 도메인, 구조화된 출력)
• reviewer(검증자): gpt-oss-20b(단순 일관성 검증)

이러한 계층화된 접근 방식은 품질을 유지하면서 비용을 최적화합니다. 로그에 "No package X available" 문구가 포함되어 있는지 확인하는 선별 에이전트에는 235B 파라미터 모델까지 필요하지 않습니다.

아키텍처: 2세대 에이전트

복잡한 운영 태스크에서 오픈소스 모델이 원활하게 작동하도록 만드는 핵심은 LLM을 감독 없이 실행하지 않고 적절히 감싸서 구동하는 프레임워크인 하네스입니다.

1세대 에이전트와 2세대 에이전트 비교

1세대 에이전트(기존 ReAct 패턴)는 다단계 작업 수행 시 다음과 같은 한계를 보입니다.

• 대화 기록으로 제한되는 컨텍스트
• 약 50회의 툴 호출 이후 성능 저하("무반응 구간")
• 대화 외부에 영속적인 상태가 유지되지 않음
• 모든 태스크가 단일 컨텍스트 창 공유

2세대 에이전트(Deep Agents, Claude Agent SDK)는 네 가지 핵심 아키텍처 요소를 활용합니다.

1. 명시적 계획 수립(영속적인 컨텍스트 앵커 역할을 하는 할 일 목록)
2. 영속적 파일 시스템(메모 및 구조화된 아티팩트를 위한 가상 작업 공간)
3. 하위 에이전트 생성(독립된 컨텍스트를 갖춘 전문가에게 작업 위임)
4. 컨텍스트 격리(각 전문가는 필요한 정보만 확인)

예시: 인시던트 대응 파이프라인

AIOps 파이프라인은 Deep Agents 패턴을 사용합니다.

ops_manager (long-running Deep Agent)
  ├── Receives AAP2 job failure webhook
  ├── Classifies failure domain (ansible/linux/openshift/networking)
  ├── Spawns specialist subagent (ephemeral)
  │   └── sre_linux (fresh context)
  │       ├── Loads skills: analyze-linux-failure, create-ticket, common
  │       ├── Analyzes incident data
  │       └── Returns structured TicketPayload
  ├── Spawns reviewer subagent (ephemeral)
  │   └── reviewer (validates ticket coherence)
  └── Submits ticket to Kira + notifies Rocket.Chat

각 sre_* 하위 에이전트는 필요에 따라 생성되고 사용 후 삭제되는 임시(ephemeral) 에이전트입니다. 이는 다음과 같은 이점을 제공합니다.

• 컨텍스트 격리: 패키지 오류가 SSH 장애의 컨텍스트를 오염시키지 않음
• 특화된 전문성: 각 에이전트는 해당 도메인에 특화된 스킬만 로드함
• 깨끗한 상태 유지: 누적된 이전 기록 없이 매 분석이 새로 시작됨

235B 파라미터의 오픈소스 모델은 이전 인시던트 50개를 일일이 "기억"할 필요가 없으므로 당면한 태스크를 원활하게 수행합니다. 적합한 스킬이 로드된 상태에서 눈앞의 문제만 집중적으로 추론하면 되기 때문입니다.

데이터 주권 + 비용 + 품질 = 프로덕션 지원 준비 완료

오픈소스 모델을 에이전틱 워크로드의 프로덕션 환경에 즉시 적용할 수 있도록 만드는 3가지 핵심 요소는 다음과 같습니다.

1. 데이터 주권: 로그가 자체 인프라 내에 유지됨(GDPR/DORA 위반 위험 없음)
2. 비용: 예측 불가능한 토큰당 과금 대신 고정 인프라 비용 적용
3. 품질: 에이전틱 하네스와 스킬의 결합으로 프론티어 모델 수준의 결과 제공

실제 프로덕션 환경에서 6개월간 이 시스템을 운영하며 매주 40건 이상의 인프라 인시던트를 처리하고 있습니다. 알려진 장애 패턴의 경우 평균 해결 시간(MTTR)이 45분에서 12분으로 단축되었습니다. 컴플라이언스 팀 역시 감사 추적 결과에 만족하고 있습니다. 인프라 비용도 예측 가능합니다.

오픈소스 모델은 다음과 같은 문제를 효과적으로 처리합니다.

• Ansible Playbook 오류 및 자격 증명 문제
• Linux 패키지 관리 및 systemd 오류
• OpenShift 포드 라이프사이클 및 역할 기반 액세스 제어(RBAC) 문제
• 네트워킹 DNS 및 연결 문제

파이프라인은 동일합니다. 스킬도 동일합니다. 프롬프트도 동일합니다. 모델만 다를 뿐입니다. 그리고 기대한 대로 완벽히 작동합니다.

직접 체험하기

오픈소스 모델 기반의 에이전틱 AIOps 파이프라인 구축을 직접 경험해 보고 싶으신가요? Red Hat 담당자에게 문의하여 전체 워크숍을 체험해 보세요.

리소스

• Red Hat OpenShift AI
• LangChain Deep Agents
• 소버린 AI의 기반으로서의 오픈소스
• EMEA 기업의 데이터 주권 과제

문서 소개: 이 글은 Red Hat 현장 시연을 위해 마련된 핸즈온 워크숍을 바탕으로 작성되었습니다. 여기에 설명된 기술은 실제 인프라 인시던트를 처리하는 프로덕션 SRE 환경에서 활발히 구동되고 있습니다. 전체 실습 랩을 체험해 보려면 Red Hat 담당자에게 문의하세요.