Molayo

© 2026 Molayo

Dev.to헤드라인2026. 06. 08. 02:03

채팅 앱에서 Ops를 실행하는 AI 에이전트를 오픈소스로 공개합니다

요약

Ops 장애 대응 시 발생하는 컨텍스트 스위칭 문제를 해결하기 위해 채팅 앱 기반의 오픈소스 AI 에이전트 'Ongrid'를 공개합니다. Ongrid는 Slack이나 Telegram 내에서 메트릭, 로그, 트레이스를 분석하여 근본 원인을 찾고 조치를 제안합니다.

핵심 포인트

  • 채팅 앱 내에서 도구 호출을 통해 Ops 업무 수행
  • 메트릭, 로그, 트레이스 등 다양한 데이터 소스 통합 분석
  • 컨텍스트 스위칭 비용을 줄여 장애 대응 시간 단축
  • Apache 2.0 라이선스의 오픈소스 프로젝트

새벽 2시 47분의 문제

지난 분기 새벽 2시 47분에 Prometheus 알람이 울렸습니다. CPU 어쩌구 저쩌구, 디바이스 4 어쩌구 저쩌구 하는 내용이었죠. 무엇이 실제로 고장 났는지는 아직 알 수 없었습니다.

Grafana를 열고, 대시보드를 눈으로 훑고, device_id를 LogQL 쿼리에 복사하여 붙여넣고, connection reset by peer 메시지가 벽처럼 쌓이는 것을 지켜보았습니다. ssh로 접속하여 top을 실행하고, journalctl -u prod-api를 실행하고, 위키(wiki)에서 "connection reset"이 포함된 런북(runbook)을 grep으로 검색했습니다. 위키는 포기했고, 팀 Slack에 물어봤더니 4분 뒤에 누군가 "SNI 관련 사항은 확인해 봤나요?"라고 답했습니다. SNI 관련 사항을 확인했고, 그것이 정답이었습니다.

알람이 울린 시점부터 첫 번째 유용한 조치를 취하기까지 22분이 걸렸습니다. 그중 절반은 실제 조사가 아니라 도구 간의 컨텍스트 스위칭 (context-switching) 때문이었습니다. 나머지 절반은 Grafana 탭이 느렸기 때문입니다.

결과적으로 제가 가졌던 거의 모든 Ops 질문은 동일한 형태를 띠고 있었습니다:

  1. 특정 메트릭 (metric)이 임계값을 초과함.
  2. 해당 타임스탬프 주변의 로그 (logs)와 대조함.
  3. 지연 시간의 꼬리 (latency tail)를 확인하기 위해 트레이스 (trace)를 가져올 수도 있음.
  4. 서비스 그래프 (service graph)를 따라 상류 (upstream)로 한두 단계 이동함.
  5. 최근 변경 사항을 확인함.
  6. 롤백 (roll back)할지, ssh로 접속할지, 아니면 인시던트 (incident)를 오픈할지 결정함.

이것은 고정된 데이터 소스 세트에 대한 일련의 도구 호출 (tool calls) 과정입니다. 이는 정확히 LLM의 도구 사용 (tool-use) 루프가 구축된 목적과 일치합니다. 하지만 제가 시도했던 모든 AIOps 제품들은 제가 그들의 UI 안에서만 머물기를 원했습니다. 하지만 Ops는 실제로 UI에서 일어나지 않습니다. Ops는 Slack이나 Telegram에서 일어납니다. 왜냐하면 온콜 로테이션 (on-call rotation), 런북 (runbooks), 사후 분석 (post-mortems), 그리고 "SNI 관련 사항은 확인해 봤나요?"라는 답변들이 모두 그곳에 있기 때문입니다.

그래서 저는 Ongrid를 만들었습니다. 이것은 오픈 소스이며, Apache 2.0 라이선스이고, docker compose up으로 실행할 수 있습니다. 이 포스트는 이것이 무엇인지, 어떻게 작동하는지, 그리고 아직 작동하지 않는 것이 무엇인지에 대해 다룹니다.

기능

한 문장으로 요약하자면: Ongrid는 팀의 채팅 앱을 통해 구동되며, 시스템을 이해하고, 근본 원인 (root cause)을 찾아내고, 조치를 취하는 AI 에이전트입니다.

작업 세션은 다음과 같은 모습입니다:

@you, Slack 채널에서: device_4에서 왜 5xx 에러가 발생하나요?

Ongrid (90초 후): 지난 30분 동안의 http_requests_total{device_id="4",status=~"5.."}를 확인했습니다. 02:47에 에러율이 0.1%에서 14%로 급증했습니다. Loki 로그를 보면 02:47에서 02:51 사이에 api-gateway 포드(pod)에서 240개의 read: connection reset by peer 항목이 발견되었습니다 (LogQL: {device_id="4",unit="api-gateway.service"} |~ "connection reset"). 02:48에 샘플링된 트레이스(Trace)를 보면 업스트림(upstream)인 auth.internal과의 TLS 핸드셰이크(handshake)에서 4.2초가 소요되었습니다. auth.internal의 최근 변경 이벤트: 02:46에 deployment auth-rotate-2026-Q2에 의해 SNI 호스트네임이 교체되었습니다. 예상되는 근본 원인 (root cause): auth.internal이 우리가 제시하는 SNI와 더 이상 일치하지 않습니다. 권장 조치: auth-rotate-2026-Q2를 롤백(roll back)하거나, 새로운 SNI를 api-gateway에 적용하십시오. 아직 조치를 취하지는 않았습니다.

이것이 전체 루프(loop)입니다: 쿼리(query), 상관관계 분석(correlate), 근거 확인(ground), 제안(propose), 그리고 사람이 실행(go)이라고 말할 때까지 대기하는 과정입니다.

다음은 실제 제품에서 가져온 사례입니다. 근본 원인, 증거 체인, 그리고 정확히 지목된 서비스와 함께 엔드 투 엔드(end to end)로 조사된 알람(alert)입니다:

Ongrid auto-investigating a resolved

아키텍처 (Architecture) (중요한 부분들)

┌─────────────────┐                        ┌─────────────────┐
│   edge agent    │    outbound tunnel     │     manager     │
│   (on host)     │ ─────────────────────▶ │   agent + LLM   │
...

짚고 넘어갈 만한 세 가지 사항입니다:

1. 에지(edge)가 외부로 연결합니다. 호스트는 ongrid-edge를 실행하며, 이는 매니저(manager)로 향하는 아웃바운드 (outbound) 터널을 엽니다. 호스트 외부에서 22, 80 또는 443 포트에 접근할 수 있을 필요가 없습니다. 매니저는 호스트 프로브(probe)를 실행하고 싶을 때 동일한 터널을 타고 다시 돌아옵니다. 결과적으로, NAT 뒤에 있거나 프라이빗 VPC(private VPC)에 있는 운영(ops) 서버들은 특이한 예외 케이스가 아니라 일급 시민(first-class targets)으로서 다뤄집니다.

2. 에이전트는 챗봇이 아니라 그래프입니다. LLM을 대면하는 커널(kernel)은 eino의 그래프 러너(graph runner)이며, 그 위에 저희만의 도구 레지스트리(tool registry)를 구축했습니다. 중요한 두 가지 설계 결정 사항은 다음과 같습니다:

  • 코디네이터(Coordinator) + 전문가(specialists). 코디네이터 에이전트가 개별 인시던트(incident) 작업을 전문가(SRE, 네트워크, 디스크, 운영, 리뷰어)에게 배정합니다. 전문가들은 기본적으로 읽기 전용(read-only)이며, 상태를 변경하는 작업(mutating actions)은 이를 제어하는 별도의 리뷰어 에이전트를 거쳐야 합니다. 타임라인을 통해 어떤 에이전트가 어떤 도구 호출(tool call)을 수행했는지 정확히 확인할 수 있습니다.
  • 클래스별 도구 샌드박싱(Tool sandboxing). 26개 이상의 내장 도구(query_promql, query_logql, query_traceql, expand_topology, find_topology_node, query_change_events, 정책 화이트리스트가 적용된 bash, host_probe_disk/cpu/net/..., 지식 베이스 search 등)가 있으며, 각 도구에는 클래스(safe-read, safe-write, dangerous)가 태그되어 있습니다. 운영자는 역할(role)에 따라 호출 가능한 클래스를 결정합니다.

3. LLM은 교체 가능합니다. 저희는 멀티 프로바이더 라우터(multi-provider router)를 제공하므로 **Anthropic, OpenAI, Zhipu (GLM), Gemini, DeepSeek, Kimi 또는 모든 OpenAI 호환 릴레이(relay)**를 바로 사용할 수 있습니다. 재시작 없이 런타임(runtime)에 기본 모델을 전환할 수 있습니다. 저는 사전 분류(pre-classification) 단계에는 작고 저렴한 모델을 사용하고, 실제 조사 단계에는 더 강력한 모델을 사용합니다. API 키를 보유한 모델이라면 무엇이든 작동합니다.

다음은 에이전트가 실제 작업을 수행하는 모습입니다. 호스트의 디스크 사용량을 조사하고, 발견한 내용을 요약하며 구체적인 정리 계획을 제시합니다:

The agent investigating disk usage on a host

"채팅 네이티브(chat-native)"가 생각보다 더 중요한 이유

제가 본 모든 Ops AI 도구들은 채팅 통합을 단순한 알림 수신함(notification sink)으로 취급합니다. "Slack으로 알림을 보내면, 사용자가 클릭하여 우리의 대시보드로 이동합니다." 이는 핵심을 놓친 것입니다. 대화는 반드시 채팅 클라이언트 내부에서 이루어져야 합니다. 왜냐하면 대화에는 이미 맥락(context)이 포함되어 있기 때문입니다. 누가 당직인지, 마지막 장애(incident)는 무엇이었는지, 6시간 전에 중단된 작업은 무엇인지, 누가 이미 무엇을 시도했는지와 같은 정보 말입니다.

Ongrid는 양방향을 모두 지원합니다:

  • Outbound (아웃바운드): 알림, RCA(Root Cause Analysis, 근본 원인 분석) 요약, 사후 분석(post-mortem) 초안이 채널로 전송됩니다.
  • Inbound (인바운드): 동일한 스레드에서 봇을 @멘션하여 후속 질문을 할 수 있습니다. 에이전트는 스레드 맥락, 원본 알림, 기존 조사 내용, 지식 베이스(knowledge base), 소스 코드(리포지토리를 제공하는 경우)를 모두 파악하고 있습니다. 답변은 동일한 스레드로 스트리밍되어 돌아옵니다.

현재 양방향으로 작동하는 서비스: Slack (socket-mode),
Telegram (getUpdates polling). 아웃바운드 측면에서는 DingTalk과
WeCom을 지원합니다. 이를 깔끔하게 생각하는 방법은 다음과 같습니다: 각 프로바이더(provider)는 동일한 에이전트 런타임(agent runtime)으로 연결되는 얇은 전송 어댑터(transport adapter) 역할을 합니다.

실제로 어려운 점들

모든 오픈소스(OSS) 프로젝트가 하나쯤은 숨기고 있기에, 솔직한 목록을 공개합니다:

  • 네트워크가 Telegram API에 직접 도달할 수 없는 경우 프록시(proxy)가 필요합니다. 아직 install.sh에 --http-proxy 플래그가 없습니다. 저희는 테스트 박스에서 docker-compose.override.yml에 HTTPS_PROXY를 설정하여 우회 해결했습니다. 작동은 하지만 수동 단계가 필요합니다.
  • 일부 프로바이더의 베이스 모델(base models)은 우리의 기본 요청 파라미터(request params)를 거부하며 beta-limitations 스타일의 오류를 발생시키고, 특정 변형(variant)을 선택해야 합니다. 자동으로 감지하고 다운그레이드하는 기능이 필요합니다 — 이슈(issue)를 제기해 주세요.
  • Anthropic 프로바이더의 anthropic_base_url 필드는 사용자가 공식 엔드포인트(endpoint)에 있거나 동일한 형식을 사용하는 릴레이(relay) 뒤에 있다고 가정합니다. 차이점을 자동으로 감지(sniff)하지 못합니다.
  • 아직 SOP / 플레이북(playbook) 실행기가 없습니다. 현재 에이전트는 해결책을 제안할 뿐, 이중 승인 게이팅(double-sign gating)이 포함된 다단계 런북(runbook)을 실행하지는 못합니다. 로드맵에 포함되어 있습니다.

더 많은 문제를 발견하신다면, 이슈 트래커(issue tracker)는 열려 있습니다.

설치

# Ubuntu 22.04+, Debian 12+, RHEL/Rocky 9
wget https://github.com/ongridio/ongrid/releases/download/v0.8.2/ongrid-v0.8.2-linux-amd64.tar.xz
tar -xf ongrid-v0.8.2-linux-amd64.tar.xz && cd ongrid-v0.8.2-linux-amd64
...

이 코드는 manager와 Prom, Loki, Tempo, Grafana, Qdrant, 그리고 Frontier broker를 모두 docker-compose로 구성해 줍니다. Edge 설치는 curl 파이프라인을 사용하며, manager가 UI를 통해 다음 명령어를 제공합니다:

curl -k -sSL https://<manager>/edge/install.sh | bash -s -- \
  --access-key=... --secret-key=... \
  --server-edge-addr=<manager>:40012 \
...

Apache 2.0 라이선스이며, 원격 측정(telemetry)을 위한 전화 홈 기능은 없습니다. 지식 기반 내용은 사용자의 qdrant에 보관되며, 채팅 기록은 MySQL에 보관됩니다.

이 관측 가능성 스택(observability stack)은 기본적으로 연결되어 제공되며, 에이전트가 쿼리를 자체적으로 작성합니다:

Ongrid's built-in monitoring dashboard

어디서 찾을 수 있나요

여러분에게 어떤 부분이 문제가 되는지 알고 싶습니다. 이것을 개선하는 가장 빠른 방법은 저인 제가 아닌 SRE가 직접 설치해보고 무엇이 잘못되었는지 알려주는 것입니다. 그렇게 해주신다면, 이슈를 등록하거나 [Twitter / 어디든지]에서 저에게 메시지를 보내주세요. 하나하나 읽어보겠습니다.

Ongrid는 Apache 2.0 라이선스입니다. 본 게시물에서 언급하는 릴리스는 v0.8.2 (2026-06-04) 버전입니다.

AI 자동 생성 콘텐츠

본 콘텐츠는 Dev.to AI tag의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.

원문 바로가기
0

댓글

0