HyperProbe, 온콜 에이전트가 증거를 잡는 방식

온콜 에이전트의 병목은 추론이 아니라 증거다

HyperProbe는 YC S26 배지를 달고 운영 장애를 대신 조사하는 AI 온콜 에이전트를 내세운다. 제품 설명의 핵심은 코딩 에이전트가 운영 코드의 의심 지점에 읽기 전용 가상 브레이크포인트를 놓고, 재배포 없이 실제 요청이 지나갈 때 변수 상태를 캡처한다는 것이다. 홈페이지는 3~4시간 걸리던 원인 확인을 10분 미만으로 줄이고 재배포 횟수와 조사 인원을 0에 가깝게 만들 수 있다고 주장한다.

이 메시지는 ORCA-bench, 온콜 에이전트의 현실 점수를 공개하다와 맞닿아 있다. 온콜 에이전트가 어려운 이유는 로그가 부족하고, 스택트레이스가 원인이 아니라 결과를 가리키며, 운영 상태를 로컬에서 재현하기 어렵기 때문이다. LLM이 아무리 잘 추론해도 관측 데이터가 비어 있으면 추측만 빠르게 반복한다.

읽기 전용 프로브는 로그 추가와 다르다

HyperProbe 문서는 실행을 멈추거나 소스를 바꾸지 않고 라이브 변수 스냅샷, 로그, 호출 스택을 잡는다고 설명한다. MCP를 통해 코딩 에이전트가 파일과 라인을 찾고, 브로커에 연결하고, 스냅샷 프로브를 주입하고, 텔레메트리 큐에서 실제 요청을 기다리는 흐름도 제시한다. 표준 디버거처럼 프로세스를 멈추는 방식이 아니라 비동기 훅을 짧게 실행하는 방식이라는 설명이다.

이것이 중요한 이유는 장애 대응의 비용 구조 때문이다. 로그를 추가하려면 브랜치, CI, 배포, 재현 대기가 필요하다. 잘못 찍으면 다시 배포해야 한다. 반면 읽기 전용 프로브는 특정 줄의 값과 호출 스택을 한 번 잡고 사라지는 모델을 지향한다. OpenTelemetry가 표준 계측 언어라면 HyperProbe는 계측이 없던 지점에 임시 현미경을 놓는 쪽에 가깝다.

보안 검토는 제품 주장보다 중요하다

HyperProbe는 민감 속성을 컨테이너 안에서 제거하고, 이벤트 루프 지연과 메모리 여유를 감시하며, 프로브에 수명과 히트 제한을 둔다고 설명한다. 홈페이지도 읽기 전용, 감사 로그, 승인 게이트, 자체 인프라 또는 프라이빗 VPC 배포를 강조한다. 그러나 운영 환경에 동적 관측 훅을 넣는 도구는 그 자체로 고권한 시스템이다. 한국 금융, 커머스, 게임사는 이 기능을 생산성 도구가 아니라 보안 시스템으로 평가해야 한다.

NIST AI Risk Management Framework는 위험을 맥락 안에서 관리하라고 말한다. 여기서 맥락은 운영 장애의 긴급성과 개인정보, 결제정보, 영업비밀이다. 에이전트에게 쓰기 권한이 없더라도 읽기 권한만으로 충분히 민감할 수 있다. 차량 관제 해킹, 에이전트 시대 API 보안의 경고가 보여준 것처럼 관측 API도 공격면이다.

온콜 워크플로가 재구성된다

HyperProbe가 성공하려면 PagerDuty, Datadog, Slack, 코드 저장소, 런타임 SDK, 비밀관리, 감사 로그가 하나의 워크플로로 이어져야 한다. PagerDuty나 Datadog 알림을 받는 순간 에이전트는 무엇을 볼 수 있고 무엇을 볼 수 없는지 알아야 한다. 사람이 승인해야 하는 단계와 자동으로 가능한 단계를 분리해야 한다.

한국 개발팀에는 좋은 실험 주제가 있다. 첫째, 읽기 전용 스냅샷을 스테이징과 낮은 위험의 내부 서비스부터 적용한다. 둘째, 캡처 가능한 필드와 금지 필드를 정책으로 만든다. 셋째, 에이전트가 제안한 원인과 실제 수정 PR을 연결해 회고한다. OpenAI 사이버 평가 사고, 샌드박스의 경계가 흔들렸다에서처럼 자동화 경계는 문서가 아니라 실제 통제로 증명되어야 한다.

자주 묻는 질문

Q1: HyperProbe는 자동으로 코드를 고치나요?

A: 핵심은 먼저 운영 증거를 잡는 것이다. 문서는 에이전트가 원인을 찾고 핫픽스를 작성할 수 있다고 설명하지만 배포 권한은 별도 통제해야 한다.

Q2: 읽기 전용이면 안전한가요?

A: 완전히 안전하다는 뜻은 아니다. 읽기 권한만으로도 개인정보와 영업비밀이 노출될 수 있다.

Q3: 기존 APM을 대체하나요?

A: 대체보다는 보완에 가깝다. APM이 흐름을 보여주고, 프로브는 특정 줄의 변수 상태를 잡는다.

Q4: 어떤 팀에 먼저 맞나요?

A: 장애 재현이 어렵고 배포 주기가 긴 백엔드 팀, 결제와 주문처럼 상태 오류가 큰 팀에 맞다.

Q5: 도입 전 확인할 것은 무엇인가요?

A: 자체 호스팅 여부, 감사 로그, 필드 마스킹, 승인 게이트, 프로브 수명, 장애 시 자동 제거 정책을 확인해야 한다.