LOOP Run탐지는 제품이, 서술은 고객의 AI 에이전트가 합니다
WEVE LOOP 의 런타임 절반입니다. 텔레메트리의 주 소비자를 사람이 아니라 AI 에이전트로 두고 설계했습니다. 지금 도는 것은 OpsRadar 이고, 접수 ITS 는 자사에서 운영 중입니다.
세 단계와 교차 하나, 지금 도는 것은 관측입니다
| 단계 | 담당 모듈 | 상태 | 근거 |
|---|---|---|---|
| 관측 | OpsRadar | 운영 | OTel 과 LGTM(Mimir, Loki, Tempo)으로 메트릭과 로그를 수집하고 저장합니다. 조사 화면의 상태를 전부 URL 에 담아 링크로 공유합니다. 토큰이 정한 테넌트만 조회됩니다. opsradar.weveloop.ai 로 접속됩니다. 온톨로지 그래프와 MCP 근거 노출(P2)은 착수 전입니다 |
| 이상탐지 | DriftScan | 계획 | 요일별 베이스라인을 통계와 ML 로 학습해 바운더리 이탈을 감지하도록 계획했습니다. LLM 을 쓰지 않습니다. 최소 2~4주치 데이터가 먼저 있어야 합니다. OpsRadar 로드맵의 P3 이 이 역할입니다 |
| 자동대응 | SelfMend | 계획 | 인시던트를 받아 롤백과 스케일, 재기동을 사람 승인 아래 실행하도록 계획했습니다. 대응 뒤 복구를 확인합니다. OpsRadar 로드맵 P4 의 일부입니다 |
| 런타임 보안 (병렬 교차) | RunGuard | 계획 | 관측과 이상탐지 신호를 교차해 위협과 이상 접근을 탐지하고, 모니터에서 경고, 차단으로 단계를 올려 정책 위반을 막도록 계획했습니다. 순차 단계가 아니라 전 단계와 나란히 도는 방어 계층입니다 |
| 접수 | ITS | 운영 | 개선과 장애 요청을 받아 분류하고 두뇌로 보내는 관문입니다. 7단계 순환의 시작점입니다. 자사 프로덕션 클러스터에서 서비스로 운영 중이며, 제품으로서의 범위는 확정 전입니다 |
지금 도는 것은 OpsRadar 와 ITS 입니다
OpsRadar. 운영 중인 EKS 클러스터에 서비스는 계속 늘었는데 관측 스택이 없었습니다. 그래서 만들었습니다. Grafana 없이 OpsRadar 만으로 클러스터 상태를 파악하는 것이 MVP 기준이었고, 달성했습니다. 다음은 온톨로지 그래프를 만들고, MCP 도구가 그 그래프만 순회하도록 제약하는 단계입니다. 서술과 추론은 고객이 쓰는 AI 클라이언트가 합니다. MCP 도구 4개는 동작 코드로 있고, 이 단계(P2)는 착수 전입니다.
ITS. 자사 프로덕션 클러스터에서 서비스로 운영 중입니다. 요청을 받아 분류하고 두뇌 AgentFlow 로 라우팅하며, 처리를 추적해 되돌려 주는 접수 관문으로 제품화합니다. 운영 신호로 자동 접수하는 것은 권장 기능으로 계획했습니다.
계획한 것
DriftScan 과 SelfMend, RunGuard 는 계획 단계입니다. DriftScan 과 SelfMend 는 OpsRadar 로드맵의 P3 과 P4 로 잡혀 있고, 독립 제품으로 나눌지는 정해지지 않았습니다.
완전 무인 복구는 목표가 아닙니다. 자동대응은 사람 승인 게이트를 거치도록 계획했습니다.
LOOP Run 이 아닌 것
| 아닌 것 | 대신 |
|---|---|
| 내부 LLM 운영이 아닙니다 | GPU 와 vLLM 으로 RCA 를 생성하지 않습니다. 추론은 고객 몫이고, 데이터는 파이프라인 밖으로 나가지 않습니다 |
| 완전 무인 자동복구가 아닙니다 | MCP 는 pull 방식이라 서버가 스스로 세션을 열지 못합니다. 사람이 루프 안에 있는 것이 전제입니다 |
| 대시보드를 바꾸는 것이 목적이 아닙니다 | "왜" 에 답하는 근거 계층을 얹는 것이 핵심입니다 |
| 파드와 컨테이너 단위 실사용 수집은 지금 없습니다 | 비목표로 두고 P2 에서 다시 판단합니다 |
| 빌드타임 기능은 여기 없습니다 | LOOP Build 소관입니다. LOOP Build |
순서
| 단계 | LOOP Run |
|---|---|
| Now | OpsRadar P2(MCP) 착수 |
| Next | DriftScan(P3) 이상탐지, SelfMend(P4) 자동대응 |
| Later | RunGuard, ITS 접수 통합 → WEVE LOOP 전 생명주기 순환 |
궁금한 것들
대시보드 위에 챗봇을 얹은 것 아닙니까?
아닙니다. 대시보드는 무엇이 일어났는지 보여주지만 필요한 답은 "왜" 입니다. 챗봇을 얹은 관측 도구는 모델이 메트릭 이름과 서비스 관계를 추측해 그럴듯하지만 틀린 원인을 만듭니다. OpsRadar 는 온톨로지 그래프를 만들고 MCP 도구가 그 그래프만 순회하도록 제약합니다. 추론은 고객이 쓰는 AI 클라이언트가 합니다. 이 부분(P2)은 아직 착수 전입니다.
원본 텔레메트리가 밖으로 나갑니까?
나가지 않습니다. 제품 안에서 추론하지 않고 GPU 도 쓰지 않습니다. 추론은 고객 계약 안에서 고객의 AI 가 합니다.
AI 클라이언트가 없는 환경이면요?
MCP 는 pull 방식이라 고객 쪽에 AI 클라이언트가 있어야 합니다. 공공과 금융처럼 그것이 어려운 환경을 위해 제품 안에 RCA 를 다시 넣을지는 정해지지 않았습니다.
클러스터 하나로 시작합니다.