안녕하세요 HN — 저희는 Jeffrey, Coleman, Wilson이며, Kubernetes를 다루는 온콜(on-call) 엔지니어를 위한 AI SRE 코파일럿(copilot)인 Parity(https://tryparity.com)를 만들고 있습니다. 여러분이 노트북을 열기도 전에, Parity는 이슈를 분류(triage)하고, 근본 원인(root cause)을 파악하며, 해결책(remediation)을 제안하기 위한 조사를 이미 마친 상태입니다. Parity의 빠른 데모는 여기서 확인하실 수 있습니다:

https://tryparity.com/demo

저희는 클라우드 제공업체인 Crusoe에서 엔지니어로 함께 일하며 만났고, 항상 온콜(on-call) 근무를 두려워했습니다. 온콜이란 하루 중 어느 시간대에 발생할지 모르는 이슈를 해결하기 위해, 일주일 동안 우리의 삶과 프로젝트를 중단하고 대비해야 함을 의미했습니다. 저희는 PagerDuty 알림에 잠에서 깨어난 뒤 런북(runbook)을 찾아 실행하느라 잠 못 이루는 밤을 경험했습니다. k8s 클러스터의 다운타임(downtime) 근본 원인을 찾기 위해 대시보드와 로그를 뒤지느라 계획했던 일정들을 취소하기도 했습니다.

다른 개발자 및 SRE들과 대화해 본 결과, 저희만 그런 것이 아니라는 점을 깨달았습니다. 모든 팀이 더 나은 모니터링 시스템이나 더 탄력적인(resilient) 설계를 원하지만, 현실적으로 이러한 투자를 하기에는 시간과 자원이 너무 제한적인 경우가 많습니다.

저희는 이 문제를 해결하기 위해 Parity를 만들고 있습니다. 저희는 AI 에이전트(agents)가 런북(runbooks)을 실행하고 근본 원인 분석(root cause analysis)을 수행하게 함으로써, Kubernetes를 다루는 엔지니어들이 온콜(on-call) 업무를 더 쉽게 처리할 수 있도록 지원합니다. 대량의 데이터를 빠르게 처리하고 해석하는 능력을 고려할 때 LLM(Large Language Models)이 도움이 될 수 있다는 점은 알고 있었습니다. 하지만 LLM만으로는 충분한 능력을 갖추기 어렵다는 것을 발견했기에, 근본 원인 분석과 같은 더 복잡한 작업을 수행할 수 있는 에이전트(agents)를 구축했습니다. 온콜(on-call) 엔지니어들이 이러한 작업을 더 쉽게 처리할 수 있게 하고, 궁극적으로는 이러한 책임으로부터 그들을 해방시킴으로써, 그들이 더 복잡하고 가치 있는 엔지니어링 투자에 집중할 수 있는 시간을 더 많이 만들어주고자 합니다.

우리는 사람이 수행하는 것과 동일한 단계를 따라 Kubernetes의 문제를 조사하는 에이전트 (Agent)를 구축했습니다. 즉, 가능한 근본 원인 (Root cause)을 도출하고, 로그 (Logs)와 메트릭 (Metrics)을 통해 이를 검증하며, 충분한 근거가 뒷받침되는 근본 원인이 발견될 때까지 반복하는 과정을 거칩니다. 예를 들어 “503 에러가 급증하고 있다”와 같은 증상이 주어지면, 우리 에이전트는 nginx 설정 오류나 애플리케이션 포드 (Pods)의 리소스 부족 등 왜 이런 현상이 발생하는지에 대한 가설을 세웁니다. 그런 다음, 해당 가설을 뒷받침하거나 배제하기 위해 클러스터 (Cluster)에서 필요한 정보를 수집합니다. 이러한 결과는 요약 및 각 가설이 포함된 보고서 형태로 엔지니어에게 제공됩니다. 보고서에는 에이전트가 결론에 도달할 때 고려한 모든 증거가 포함되어 있어, 엔지니어가 결과를 빠르게 검토하고 검증할 수 있습니다. 조사 결과를 바탕으로 온콜 (On-call) 엔지니어는 문제 해결 (Fix)을 구현하는 데 집중할 수 있습니다.

또한, 알람 (Alert)이 트리거되었을 때 런북 (Runbook)을 자동으로 실행하는 추가 에이전트를 구축했습니다. 이 에이전트는 LLM (Large Language Model) 단독 모델보다 런북의 단계를 더 엄격하게 준수하며, Temporal과 같은 워크플로 자동화 (Workflow automation) 도구보다 더 높은 유연성을 제공합니다. 이 에이전트는 런북의 각 단계를 개별적으로 담당하는 독립적인 LLM 에이전트들의 조합으로 구성됩니다. 각 런북 단계 에이전트는 “503 에러를 설명할 수 있는 nginx 로그를 찾아라”와 같은 임의의 지침을 실행합니다. 별도의 LLM이 결과를 평가하여 단계 에이전트가 지침을 제대로 따랐는지 확인하고, 런북의 다음 단계 중 무엇을 실행할지 결정합니다. 이를 통해 루프 (Cycles), 재시도 (Retries), 그리고 복잡한 분기 조건 (Branching conditions)이 포함된 런북을 실행할 수 있습니다.

이러한 도구들을 통해 우리는 엔지니어의 온콜 업무 중 “무엇이 잘못되었는가”에 해당하는 부분을 처리하는 것을 목표로 합니다. 하지만 실제 문제 해결은 잠재적으로 위험하거나 되돌릴 수 없는 명령어를 필요로 할 수 있으므로, 최종적인 해결은 여전히 엔지니어를 신뢰하고 맡기는 것이 가장 타당하다고 믿습니다. 그러한 이유로, 우리의 에이전트들은 오직 읽기 전용 (Read-only) 명령어만을 실행합니다.

이 서비스가 유용할 것 같다고 느껴지신다면, 꼭 한번 제품을 사용해 보시길 바랍니다! 저희 서비스는 Helm 리포지토리 (Helm repo)를 통해 단 몇 분 만에 여러분의 클러스터 (cluster)에 설치할 수 있습니다. 이번 HN 런칭을 기념하여 신규 계정에 대한 결제 요구 사항을 제거하였으므로, 여러분의 클러스터에서 무료로 테스트해 보실 수 있습니다.

댓글을 통해 여러분의 피드백을 들려주시면 감사하겠습니다!