최근 Anthropic의 블로그 게시물에 본문의 핵심과는 거리가 먼 짧은 단락이 있었는데, 그것을 읽고 나서부터 계속 머릿속을 맴돌았습니다:
새로운 수준의 운영 우수성(operational excellence)이 가능합니다. 저희 팀은 Claude Tag를 많이 사용하는데, 이것이 시스템의 각 구성 요소를 모니터링하는 데 도움이 되었습니다. 예를 들어, 우리는 Slack 채널을 만들고 Claude에게 단일 구성 요소의 상태에 집착적으로 집중하도록 임무를 부여했습니다. 우리는 이 클로드들을 “슈퍼팬(superfans)”이라고 부릅니다. 저희는 scion-daemon 슈퍼팬, scion-cache 슈퍼팬, Antique 병합 큐 슈퍼팬 등을 가지고 있습니다. 이들은 우리의 원격 측정 데이터(telemetry)와 로그에 접근할 수 있으며, 차트를 새로고침하고 이상한 점을 찾아보는 것 외에는 할 일이 없는 숙련된 엔지니어처럼 행동합니다. 저희는 모든 시스템에 대한 전통적인 알림(alerts)도 가지고 있지만, 슈퍼팬들은 미묘하고 새로운 문제들을 감지해내어 이러한 알림들이 비교했을 때 일차원적으로 보이게 만듭니다.
이것이야말로 소프트웨어 시스템 운영의 너무나 명백한 미래 경로입니다. 저는 지난 몇 주 동안 에이전트를 이용한 모니터링에 대해 생각해 왔고, 이 단락이 그 생각들을 응축시켜주었습니다.
현대 소프트웨어 시스템은 그것을 작성하는 LLM처럼 ‘설계된(designed)’ 것보다 더 ‘성장된(grown)’ 경향을 보이고 있습니다. 네, 인간 엔지니어들이 여전히 시스템에 높은 수준의 설계와 형태를 부여하는 경우가 많고, 또한 소프트웨어 시스템은 (현재로서는) 코드를 앉아서 읽어볼 수 있기 때문에 LLM보다 훨씬 해석 가능합니다. 하지만 작성되고 배포되는 코드의 양이 기하급수적으로 증가함에 따라, 시스템을 운영하는 어떤 인간 작업자가 가진 실제 코드 직접 확인 지식(eyes-on-code knowledge)은 감소하고 있습니다.
시스템 모니터링은 결코 쉽지 않습니다. Sentry, Datadog, Splunk, Honeycomb 등 수많은 관측 가능성(observability) SaaS 기업들이 존재합니다. 관측 가능성은 비용이 많이 듭니다.¹ 이를 잘 수행하려면 전문적인 인간의 기술 세트가 필요하며, 대규모 실제 시스템을 운영하는 경험에 의존합니다. 이러한 기술은 산업 현장에서 일해야만 진정으로 개발할 수 있습니다. 이는 주니어 엔지니어를 교육하는 데 몇 년이 걸리는 영역입니다.
2026년 소프트웨어 업계의 모든 것과 마찬가지로, 시스템 모니터링은 에이전트(agents) 덕분에 큰 변화를 앞두고 있습니다. 저는 특히 현재 '에이전트 열풍(agent frenzy)' 속에서 이 주제에 대해 더 많은 사람들이 글을 쓰지 않은 것이 놀랍습니다. 그것은 우리 모두 앞에 놓여 있고, 작동합니다. 'AI SRE'를 시도하려는 스타트업들이 많이 있었지만, 실무자들의 글은 매우 적었습니다.
하지만 운영 우수성(operational excellence)을 개선하기 위해 반드시 완전한 'AI SRE'가 필요하거나 구축된 SaaS 제품이 필요한 것은 아닙니다. Opus 5.5 / Astra급 모델만으로도 약간의 주의를 기울이면,
이것은 어려운 문제입니다. 저는 2023년부터 어떤 형태로든 이 문제에 대해 작업해 왔지만, 성과를 내기가 어려웠습니다. 업계 전반의 사람들과 이야기하면서, '변화점 모니터링(change-point monitoring)'을 제대로 수행할 방법들이 있다는 것을 알게 되었지만, 이러한 방법들은 대체로 여전히 사람이 올바른 일을 하도록 의존합니다 (예: 메트릭/알림 태그를 성실하게 지정하고, 정확한 신호를 정의하는 등) 그리고 상당한 조직적 투자가 필요합니다.
더 구체적으로 말하면, 변화점 모니터링을 플랫폼 엔지니어링의 한 부분으로서 '도약(takeoff)'시키는 것은 어렵습니다. 왜냐하면:
- 첫 번째 본능은 이미 좋은 운영 환경(ops posture)을 갖춘 동기 부여가 높은 사용자들을 목표로 하는 것일 수 있습니다. 하지만 이러한 팀들의 배포는 이미 대부분 안전하며, 실제로 운영 수준(ops waterline)을 크게 끌어올리지 못합니다. 여기서 판매하는 것은 *노동 감소(toil reduction)*인데, 이는 '있으면 좋은' 기능이지 그 자체로 1차적인 안정성 개선은 아닙니다. 정밀도(Precision)는 동기 부여가 높은 팀들에게 더 쉽게 달성되지만, 이는 변화점 시스템이 전통적인 알림과 '재현율(recall)' 및 지연 시간(latency) 측면에서 경쟁해야 함을 의미합니다. - 대안으로 서비스 전반의 광범위한 집단을 목표로 할 수 있습니다. 즉, 선택된 보편적 건강 메트릭의 하위 집합에 대해 '모든 서비스'를 옵트인하는 것입니다. 실제로는 이러한 일반적인 건강 메트릭 대부분이 근본적으로 노이즈가 심합니다. 이 노이즈는 낮은 정밀도와 알림 피로(alert fatigue)를 초래합니다.
- LLM 이전에도 명확한 정밀도/지연 시간 트레이드오프가 있었습니다. 이 스펙트럼에는 구조화된 로그(정밀함, 느림), 메트릭(거침, 빠름), 그리고 알림(훨씬 거칠고, 재현율이 꽤 나쁘고 정밀도도 꽤 나쁘지만, '적어도 무언가는 있다')이 있습니다.
놀랍게도, 에이전트들은 이 문제를 대개 '그냥' 해결합니다. 에이전트들은 방대한 쿼리를 실행하는 것을 좋아하고, 변경 사항별(per-change) 쿼리를 즉석에서 작성할 수 있으며, 로그를 지겹도록 스캔합니다. 그 결과, 저렴한 비용으로 높은 정밀도(precision)와 재현율(recall)을 모두 얻을 수 있습니다. 이 설정의 기본 버전에서는 코드베이스(예: 구성 소비에 대해 추론하기 위해)와 관측 가능성 스택(observability stack)(예: 실시간 프로덕션 상태를 보거나 모니터링하기 위해)을 에이전트에 연결할 수 있는 능력만 있으면 됩니다.
저는 정확히 이러한 것을 담은 프로토타입을 개발했습니다. 즉, 서비스 코드를 기반으로 모니터링 계획을 제안하는 에이전트, 그 계획을 실행하는 스캐폴드(scaffold), 그리고 트리거된 모니터를 조사하고 인간에게 에스컬레이션 경로를 제공하는 또 다른 에이전트입니다. 이 초기 프로토타입에서도 저는 제가 전혀 이해하지 못하는 시스템의 회귀(regression)를 1년 전에는 불가능했을 정밀도와 지연 시간으로 감지할 수 있었습니다.
이 패턴을 개선하면서, 순수한 에이전트 루프가 에이전트 모니터링에 최적의 형태는 아니라는 것을 알게 되었습니다. 오히려, 에이전트가 어떻게 모니터링할지에 대한 명세(spec)를 작성하도록 허용하는 하네스(harness)와 그 명세를 실행하기 위한 결정론적 시스템을 갖추는 것이 훨씬 더 깨끗한 신호(signal)를 생성하고 토큰 사용량을 극적으로 낮춥니다. 이 패턴의 '비밀 소스'가 존재한다면, 그것은 노이즈 감소 휴리스틱(noise-reduction heuristics), 에이전트가 좋은 명세를 작성하도록 유도하는 프롬프트, 그리고 추가적인 조정(tweak)을 검증할 만큼 충분히 큰 레이블링된 평가 세트(labeled eval set)에 있습니다.2
에이전트는 구조적으로 모니터링에 적합하다
이 패턴이 성공하려면 두 가지 사고방식의 변화가 필요합니다:
- 에이전트들이 실제로 인간보다 훨씬 더 나은 모니터링 작업을 수행할 수 있다.
- 모니터링 에이전트 역시, 소프트웨어 개발 생명주기(SDLC)의 나머지 부분이 코딩 에이전트를 위해 적응해야 했던 것과 마찬가지로 스캐폴딩이 필요하다. 아직 모니터링에 대한 'Claude Code 순간'은 오지 않았다.
이러한 변화가 이루어지면, 모니터링 에이전트는 인간 운영자들보다 몇 가지 '불공정한 이점(unfair advantages)'을 갖게 됩니다:
-
24시간 연중무휴 모든 것을 추적할 수 있는 능력입니다. 토큰 비용이 저렴하다면, 관심 있는 지표의 어떤 회귀(regression)나 의심스러운 로그 라인이라도 조사할 수 있습니다. 더 이상 이전에 '인간 주의 한계선(human attention cutline)'을 넘었던 이벤트에만 국한되지 않습니다. 에이전트는 '태양을 따라 움직일' 필요가 없습니다.
-
생산성 문제를 해결하기 위해 여러 경로를 확장하여 조사할 수 있는 능력입니다. 에이전트는 여러 가지 문제가 동시에 발생했을 때 조사를 병렬화하고 신속하게 조정할 수 있습니다. 이것은 이미 제가 사건 분류(incident triage)에 사용하는 핵심 방법입니다. 저는 잠재적인 스레드나 이론화된 사고 원인을 조사하기 위해 한 무리의 에이전트를 실행합니다. 현재는 사람이 주도하지만, 미래에는 에이전트가 시작하는 것이 전혀 불가능하지 않습니다. 사건 대응팀(incident responder)의 규모를 탄력적으로 확장할 수 있습니다.
-
이미 이것이 보안 사고에 매우 중요해지고 있음을 목격하고 있습니다. 공격적인 사이버 공격을 위해 팀/군단/스웜(swarm) 형태의 에이전트가 사용되고 있으며, 방어자들 역시 유사한 방어 능력을 구축하기 시작하고 있습니다 (예: OpenAI의 Daybreak Blue, Anthropic의 Project Glasswing, Google의 Fairwind).
-
인간보다 더 빠르게 문제에 대응할 수 있는 능력입니다. 에이전트는 인간보다 코드를 더 빨리 읽을 수 있습니다. 또한 에이전트는 지표(metrics)와 로그 신호(log signals)를 훨씬 더 빠르게 쿼리하고 소화할 수 있습니다. 이러한 속도가 항상 더 빠른 사건 탐지 시간으로 이어지는 것은 아닙니다. 시스템에 대한 깊은 이해를 가진 인간이 여전히 올바른 신호를 찾고 근본 원인을 직관적으로 파악하는 데 더 빠를 수 있기 때문입니다. 그러나 암묵적 지식(tacit knowledge)을 기록하여 에이전트가 사용할 수 있게 하는 한, 에이전트는 결국 속도 면에서 인간을 능가할 것입니다.
-
나아가, 인간 운영자가 깊은 경험을 갖지 못한 시스템의 경우, '이해에 걸리는 시간(time to understanding)'이 에이전트에게는 더 짧아질 것입니다.
“새로운 수준의 운영 우수성(operational excellence)이 가능합니다.”
더욱 세심하게 모니터링하기: 서비스의 모든 Git 커밋을 살펴보고, 모니터링할 항목을 골라내고, 해당 변경 사항에 대해서만 특별한 단기 빠른 트리거 알림을 설정하는 일을 전일제 소프트웨어 엔지니어에게 맡길 수는 없을 겁니다. 하지만 이제는 백만 토큰당 몇 센트의 비용으로 가능하며, 이는 업계 표준이 될 것입니다.
성능 지속적으로 개선하기: 에이전트는 성능을 모니터링하고, 힙 덤프(heap dumps)와 스택 트레이스(stack traces), CPU 프로파일 등을 살펴본 후 발견한 패턴을 바탕으로 최적화 방안을 제안할 수 있습니다. 필요한 경우 제안된 개선 사항을 A/B 테스트를 거쳐 적용하고, 서비스의 다른 변경 사항처럼 모니터링할 수 있습니다.
한 사례에서, 저는 Astra/Opus 조사 세션 몇 번만으로도 인간이 이미 상당한 노력을 들여 최적화했던 일반적인 핫 패스(hot-path) 라이브러리에서 힙 사용량 50% 절감과 지연 시간 30% 감소를 발견했습니다. 충분히 강력한 LLM에 가상 머신(VM)과 벤치마크를 실행할 수 있게 해주면, 현세대 LLM의 '언덕 오르기(hill-climbing)' 능력은 놀랍습니다.
조치를 취하기: 지금까지 저는 주로 '읽기 전용(read-only)' 모니터링 시스템에 대해 논해왔습니다. 물론 에이전트가 반드시 읽기 전용일 필요는 없습니다. 적절한 하니스(harness)와 가드레일(guardrails)만 갖춰진다면, 에이전트가 인시던트를 해결하기 위해 최전선에서 조치를 취할 수 있는 미래가 분명히 존재합니다. 이는 인스턴스 크기 조정이나 컴퓨팅 풀 로테이션과 같은 잘 정의된 운영 작업부터, 설정 변경이나 바이너리 롤백 같은 결정론적(deterministic) 행동, 그리고 버그의 근본 원인 분석(root-causing), 수정 제안, 온디바이스 재배포와 같은 개방형(open-ended) 작업까지 다양할 수 있습니다. 당연히 에이전트에게 더 많은 통제권을 넘겨줄수록 위험도 커지지만, 지난 12개월 동안 에이전트 기능이 얼마나 확장되었는지 고려하면, 책임감 있게 에이전트에게 위임할 수 있는 쓰기 경로(write-path) 작업의 양은 증가할 수밖에 없습니다. 진정으로 자가 치유 시스템(self-healing systems)이라는 약속은 흥미진진합니다.
비용은 더 이상 제약이 아닙니다. Luna/Haiku급 모델 3은 이제 유능한 그래프 분석가(graph-starer)입니다. 적당히 규모가 큰 기술 기업이라면 하루에 약 100달러 수준으로 전체 플릿을 모니터링할 수 있을 것입니다. 스타트업 규모의 플릿은 그보다 훨씬 적은 비용이 들 것입니다. 인간 노동력이나 관측 가능성(observability)을 실행하는 인프라 비용과 비교하면 이는 사소한 문제입니다.
선순환 고리(virtuous cycle)를 만드세요: 에이전트 기반 모니터링(agentic monitoring)은 잘 수행될 경우 긍정적인 피드백 루프를 생성합니다. 코딩 에이전트는 더 많은 배포를 가능하게 하고, 모니터링 에이전트는 더 많은 시스템을 지원할 수 있게 하며, 이는 다시 인간의 시간을 확보하여 더 많은 것을 배포하도록 지시하는 데 사용됩니다. 인간은 점점 "공장을 건설하거나" 또는 "정원을 가꾸는" 데 시간을 보내게 됩니다.
에이전트 기반 모니터링에는 투자할 가치가 있습니다. 곧 에이전트를 사용하여 시스템을 모니터링하지 않는 것은 무모한 일이 될 것입니다. 업계의 나머지 부분이 따라잡기 전까지 지금 시작하는 것은 불공평한 이점을 제공합니다.
최근 저희 팀이 완료한 일련의 최적화 작업으로 연간 관측 가능성 비용에서 수백만 달러를 절약했으며... 이는 저희 팀이 관측 가능성에 지출하는 금액에 비하면 극히 일부였습니다. ↩︎ -
에이전트 기반 모니터링 하니스(harnesses)의 설계에 대해서는 훨씬 더 많은 내용을 쓸 수 있습니다. 이것은 제가 오랫동안 느껴보지 못했던 가장 명확한 "우리가 너무 이른 시점에 있다"라는 느낌 중 하나입니다. Anthropic의 "Claude Tag"와 같은 일반적인 하니스는 원래 게시물에서 보았듯이 에이전트 기반 모니터링에 대해 이미 좋은 역할을 하는 것이 분명합니다. 하지만 제가 본 바로는, 모니터링 전용 하니스 엔지니어링만으로도 많은 쉬운 과제(low-hanging fruit)를 해결할 수 있습니다. ↩︎
여기서 GPT-6-Luna와 Claude Haiku 5.5를 의미합니다. ↩︎
