Sentrix: AI SRE Copilot이 자신의 스케일링 결정에 대해 토론한다
Source: Dev.to
모든 SRE 팀이 겪는 악몽은 동일합니다. 새벽 3시, 트래픽이 급증하고, 아무도 이를 예측하지 못했을 때. CloudWatch 알림이 울릴 때쯤이면 고객은 이미 불만을 품고 있고, 매출 손실이 발생합니다.
저는 Sentrix를 만들었습니다 — 인프라 문제를 사전에 예측하고 자동으로 클라우드 리소스를 확장하는 AI 기반 SRE 코파일럿입니다. 차별점은 단순 예측이 아니라 논쟁입니다.
Three Agents, One Decision
단일 AI가 결정을 내리는 대신, 세 개의 Bedrock Claude 에이전트가 모든 확장 호출에 대해 토론합니다:
- AGENT_SRE는 신뢰성을 위해 싸웁니다: “지금 확장해야 합니다, 다운타임 위험을 감수할 수 없습니다.”
- AGENT_FINANCE는 비용을 억제합니다: “복제본이 5배가 되었습니다 — 정말 모두 필요합니까?”
- AGENT_ARBITER는 두 입장을 종합합니다: “지금 3배로 확장하고, 5분 동안 모니터링한 뒤 재평가합니다.”
그 결과 신뢰성과 비용을 균형 있게 맞춘 결정이 나오며, 모든 결정은 Step Functions 피드백 루프를 통해 5분 후에 점수가 매겨집니다. 이 점수는 thought signatures가 되어 향후 분석에 반영되어, AI가 여러분의 인프라에 맞는 최적의 방식을 학습하게 됩니다.
What It Looks Like in Practice
저는 Sentrix를 전체 사고 수명 주기에서 테스트했습니다:
- 트래픽 급증 →
- 비용 최적화 →
- 지역 장애 →
- 연쇄적인 AWS 장애 →
- 크로스‑클라우드 GCP 장애 복구 →
- 자동 복구.
4 536 % 트래픽 급증 상황에서, 뇌는 밀리초 단위로 급증을 감지하고 EKS를 2개 팟에서 10개 팟으로 확장했습니다 — 인간 개입이 전혀 필요 없었습니다. 트래픽이 정상화되면 Finance 에이전트가 다운스케일을 주장하고, 시스템은 10개에서 5개 팟으로 최적화했습니다. AWS 지역이 연쇄적으로 장애가 발생했을 때는 세 에이전트가 만장일치로 GCP 장애 복구를 선택했습니다. 피드백 루프는 해당 결정을 100/100으로 평가했습니다.
전체 시스템은 하나의 AWS CDK 스택으로 구동됩니다 — Lambda, Bedrock, EKS, DynamoDB, Step Functions, EventBridge, CloudFront — 5분 만에 배포됩니다.
Full Write‑up
전체 포스트에는 다음 내용이 포함됩니다:
- 아키텍처 상세
- 심각도 기반 모델 선택 (저심각도에는 Haiku, 치명적 상황에는 Sonnet)
- Thought‑signature 자체 진화 메커니즘
- 단계별 데모 walkthrough와 스크린샷
Read the full write‑up on Build Signals
저는 Sentrix를 AWS 10,000 AIdeas 대회에 제출했습니다. 가장 많이 좋아요를 받은 상위 300개의 글이 다음 라운드로 진출합니다. 이 글이 흥미로우셨다면, 기사에 좋아요를 눌러주시면 정말 큰 도움이 됩니다 — 두 초면 충분합니다.