🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 요약

Kubernetes 상태 읽기와 진단은 자율화하되 모든 변경은 사람이 승인하도록 구조적으로 분리하고, 저비용 감시와 추적·평가 루프를 결합한 자율형 SRE 에이전트 구축 사례다.

📌 핵심 요약

• Kubernetes는 파드 상태, 재시작 횟수, HPA 상태, 노드 조건, 경고 이벤트, 배포 준비 상태 등 방대한 신호를 내보내지만 이를 종합하지 않기 때문에, 인프라 엔지니어가 반복적인 분류와 판단을 직접 수행해야 했다.
• 정기 감시는 Kubernetes Python 클라이언트로 원시 상태를 수집한 뒤 Claude Haiku를 한 번만 호출해 심각도별 구조화 보고서를 Slack에 보내며, 기존 전체 오케스트레이터 실행 대비 검사당 비용을 95~99% 줄였다.
• 문제 진단이 필요하면 파드, 확장, 성능, 로그, 보안, 신뢰성 등을 담당하는 전문 서브에이전트가 병렬로 클러스터를 조사하고, Claude Sonnet 기반 오케스트레이터가 결과를 우선순위 보고서로 통합한다.
• 에이전트는 클러스터 전체를 읽을 수 있지만 스스로 변경할 수 없으며, 모든 쓰기 작업은 별도의 change-executor와 Slack 기반 사람 승인 절차를 거치도록 도구 구조와 클러스터 RBAC 양쪽에서 제한된다.
• LangSmith 추적은 과도한 모델 호출, 도구 무한 반복, 단일 복제본 오탐과 사용률 데이터 누락을 발견하는 근거가 되었고, 사람의 승인·수정·거절 기록은 회귀 평가 데이터와 자동 개선 작업으로 전환됐다.

🧩 주요 포인트

1. Python 기반 무토큰 상태 수집과 단일 Haiku 분석을 결합해 정상 상태 확인에 전체 에이전트를 동원하지 않음으로써, 자주 실행되는 감시의 비용을 크게 낮췄다.
2. 좁은 책임의 전문 에이전트를 병렬 배치하고 최종 종합에만 Sonnet을 사용해, 조사 문맥을 제한하면서도 복잡한 장애 판단에는 더 높은 추론 역량을 집중했다.
3. 쓰기 권한을 단일 실행 에이전트와 읽기 쉬운 승인 단위로 격리하고 RBAC로 같은 경계를 재현해, 자율적 진단이 곧 자율적 운영 변경으로 이어지지 않도록 했다.

🧠 상세 정리

1. 구축 배경과 해결하려는 문제

작성자는 LangChain의 내부 셀프호스팅 Kubernetes 클러스터를 유지하고, 새 기능을 내부 환경에 먼저 적용하며, 고객의 셀프호스팅 환경 구축과 업그레이드도 지원한다. 장애가 발생하면 실시간 클러스터 구조를 이해하고 결함을 찾아 복구해야 하지만, 본업과 함께 이러한 상태를 지속적으로 파악하는 일은 큰 피로를 만든다. Kubernetes는 파드 단계, 재시작 횟수, HPA 상태, 노드 조건, 경고 이벤트, 배포 준비 상태 등 수많은 신호를 여러 네임스페이스에 걸쳐 제공하면서도 종합된 판단은 거의 제공하지 않는다. 당직자는 현재 고장 난 항목, 곧 고장 날 가능성이 있는 항목, 필요한 조치를 직접 판단해야 하며, 여기에는 크래시 루프, OOM 종료, 준비된 엔드포인트 부재, 최대치에 고정된 HPA, 단일 복제본, :latest 이미지 태그 등이 포함된다. 이 작업에는 전문적인 판단이 필요하지만 약 90%는 별문제 없이 끝나는 기계적 분류이므로, 팀은 장애 분류와 복구 시간을 줄이고 인지 부담을 낮추기 위해 SRE 에이전트를 구축했다.

2. 정기 감시와 주문형 조사 방식

정기 감시는 스케줄러가 N분마다 전체 에이전트를 깨우지 않고 클러스터 건강 상태를 확인하는 방식으로 설계됐다. 스케줄러는 Kubernetes Python 클라이언트를 이용해 원시 클러스터 상태를 수집하므로 이 단계에서는 LLM 토큰을 사용하지 않으며, 이후 강제 도구 호출 방식의 Claude Haiku 호출 한 번으로 구조화된 건강 보고서를 생성한다. 보고서는 심각도 순으로 정렬되어 Slack에 전달되기 때문에 팀은 일상적인 정상 상태 확인과 주의가 필요한 신호를 한곳에서 볼 수 있다. 실제 진단이 필요한 문제에는 pod-inspector, scaling-analyzer, performance-analyzer, log-analyzer, security-auditor, reliability-auditor 등의 전문 서브에이전트가 병렬로 투입된다. 각 서브에이전트는 다른 에이전트의 해석에 의존하지 않고 클러스터를 직접 읽으며, 오케스트레이터가 이 결과들을 모아 하나의 우선순위 보고서로 종합한다.

3. 사람 승인을 중심으로 한 안전 모델

에이전트는 클러스터 전체를 자율적으로 읽을 수 있지만 어떤 리소스도 스스로 변경할 수 없도록 제한된다. 배포 확장, 롤아웃 재시작, HPA 패치와 같은 모든 쓰기 작업은 오직 change-executor 서브에이전트 안에만 존재하며, 각 쓰기 도구는 사람 참여형 인터럽트로 차단되어 있다. 에이전트가 복구안을 제안하면 담당자는 Slack 메시지에서 이를 승인하거나 거절하거나 수정할 수 있으므로, 읽기는 자율적이지만 변경은 항상 명시적인 판단을 거친다. 승인자가 실제 영향을 이해할 수 있도록 배포 복제본 수 변경처럼 범위가 좁고 읽기 쉬운 도구만 제공했고, 한 번의 실행으로 수십 개 리소스를 바꿀 수 있는 Helm 업그레이드 같은 고위험 도구는 의도적으로 제외했다. 읽기 도구와 쓰기 도구는 서로 다른 모듈에 배치되어 오케스트레이터가 쓰기 도구에 접근할 수 없으며, 클러스터 내부 RBAC도 전체 읽기와 제한된 쓰기로 동일한 경계를 구현한다. 따라서 안전성은 프롬프트상의 지시가 아니라 에이전트 구성, 도구 접근 경로, 승인 인터럽트, 권한 정책에 걸쳐 구조적으로 강제된다.

4. 프레임워크와 모델을 선택한 기준

구현은 직접 만든 원시 에이전트 반복문 대신 LangGraph 위의 Deep Agents와 create_deep_agent()를 사용한다. 이 선택으로 write_todos 기반 계획 루프, 일급 서브에이전트, 내장된 사람 승인 인터럽트를 활용할 수 있었고, 팀이 같은 기능을 별도로 구축할 필요가 줄었다. 팀이 제시한 원칙은 필요한 워크플로를 방해하지 않는 범위에서 가능한 한 높은 수준의 프레임워크를 선택하는 것이다. 하나의 전지적 프롬프트에 모든 역할을 맡기지 않고 좁은 책임의 전문 에이전트로 나눠 병렬성을 확보했으며, 각 에이전트에 들어가는 문맥을 줄여 환각 가능성을 낮추고 범위가 분명한 작업에는 저렴한 모델을 사용할 수 있게 했다. 최종 판단과 종합을 맡는 오케스트레이터에는 Claude Sonnet을 사용하고, 읽기 전용 서브에이전트와 정기 검사에는 Claude Haiku를 배치했다. 즉 모든 단계에 동일한 모델 비용을 지불하지 않고, 복잡한 판단이 필요한 지점에만 더 높은 추론 역량을 사용했다.

5. 비용 절감과 배포 환경 단순화

초기 스케줄러는 정상 상태를 확인하기 위해서도 전체 오케스트레이터를 실행해 약 20회의 모델 호출을 발생시켰지만, 현재는 Python 수집과 Haiku 한 번의 호출로 전체 에이전트를 우회한다. 이 변경은 문제 포착 능력을 잃지 않으면서 검사당 비용을 95~99% 줄였고, 강력한 조사 경로는 주문형 진단에만 남겨 두었다. Kubernetes 클라이언트는 클러스터 내부 실행과 로컬 실행을 자동으로 감지하며, 컨테이너 이미지에는 kubectl 바이너리가 필요하지 않다. Slack 연동은 외부에서 들어오는 공개 엔드포인트가 아니라 아웃바운드 WebSocket 기반 Socket Mode로 동작해 승인 흐름을 제공하면서도 공개 인그레스를 요구하지 않는다. 컨테이너는 비루트 사용자와 읽기 전용 루트 파일시스템으로 실행되며, 전체 설계는 에이전트 결과를 개선하는 부분에만 토큰, 모델 성능, 네트워크 표면을 추가한다는 단순성과 비용 효율 원칙을 따른다.

6. 추적을 통해 발견한 비용·안전·품질 문제

정기 Haiku 검사, 각 서브에이전트의 조사, 모든 읽기와 제안된 쓰기는 LangSmith 추적으로 기록된다. Deep Agents와 LangGraph 경로는 자동 추적되고, 스케줄러가 Anthropic을 직접 호출하는 부분은 @traceable로 감싸 동일한 관찰 범위에 포함했다. 실행별 비용 분석에서는 정상 판정 하나를 위해 서브에이전트 전반에서 약 20회의 호출이 발생하는 낭비가 드러났고, 이 근거가 단일 Haiku 호출 방식으로 바꾸는 출발점이 됐다. 또 다른 에이전트가 grep과 read_file 도구를 반복 호출하며 약 5달러를 소모한 사례에서는 한 실행 아래 같은 호출이 수십 번 쌓이는 모습이 추적에 명확히 나타났고, 이후 하드 재귀 제한, 모델 호출 제한, 도구별 제한, 프롬프트 캐싱이 추가됐다. scaling-analyzer가 의도적으로 단일 복제본으로 운영되는 서비스를 CRITICAL로 분류한 오탐도 여러 네임스페이스에서 반복되는 패턴으로 확인됐다. 추적에 당시 스냅샷과 판단 과정이 함께 남아 있었기 때문에 팀은 직접적인 증거를 바탕으로 프롬프트를 수정할 수 있었다.

7. 사람의 피드백을 회귀 평가로 전환

Slack에서 이루어진 승인, 수정, 거절은 해당 실행의 피드백으로 추적에 연결된다. 예를 들어 에이전트가 복제본 10개를 제안했지만 사람이 4개로 수정한 기록은 에이전트가 수행하는 가장 중요한 변경 제안에 대한 라벨이 있는 사례가 된다. 잘못 분류된 파드나 놓친 OOM 같은 실패 사례는 올바른 답과 함께 LangSmith 데이터셋으로 승격되며, 이후 프롬프트나 모델을 변경할 때마다 이 데이터셋을 대상으로 다시 평가한다. 평가는 LLM 기반 판정자와 코드 기반 평가기를 함께 사용하고, 기존 동작을 악화시키는 변경은 수치상 실패로 표시되어 병합되지 않는다. 단일 복제본 서비스 오탐처럼 실제 운영에서 발견된 문제는 일회성 프롬프트 수정으로 끝나지 않고 영구적인 회귀 테스트 사례가 되어 같은 오류의 재발을 막는다.

8. LangSmith Engine의 자동 개선 루프

기존 개선 과정은 사람이 바람직하지 않은 동작을 발견하고, 관련 추적을 찾은 뒤 데이터셋에 직접 추가해야 했기 때문에 유지보수자의 시간이 필요했다. LangSmith Engine은 관련 추적을 묶어 우선순위가 있는 문제로 탐지하며, 여러 네임스페이스에서 반복된 동일 오탐을 수십 개의 개별 기록이 아니라 하나의 문제로 정리한다. 이 탐지는 제로 데이터 보존 조건에서 추적을 읽는 방식으로 수행되며, 이어서 실패를 요약하고 프롬프트나 코드 변경을 작성해 설명과 차이가 포함된 GitHub 풀 리퀘스트를 연다. 또한 온라인 평가기와 데이터셋 사례를 제안해 수정된 문제가 다시 발생하지 않도록 예방 단계까지 연결한다. 실제로 Engine은 정기 건강 검사의 수집기가 노드, 파드, 경고 이벤트, HPA, 배포 상태는 조회하면서 CPU와 메모리 사용률은 수집하지 않아 매시간 답할 수 없는 용량 질문을 제기한다는 문제를 발견했다. 저장소에 이미 있던 kubectl_top_pods와 kubectl_top_nodes 기능 및 단위 변환 로직을 정기 수집 경로에 재사용하는 변경이 제안됐고, 수집기 범위에 한정된 풀 리퀘스트는 검토와 데이터셋 평가를 거쳐 병합됐다.

9. 현재 활용 범위와 다음 과제

팀은 이 SRE 에이전트를 내부에서 계속 사용하고 있으며, 일부 기존 LangSmith 고객에게도 배포를 시작했다. Kubernetes 운영뿐 아니라 스택의 다른 영역까지 기능을 확장하기 위한 개발도 진행하고 있다. 다음 개선 과제로는 사람 승인 흐름의 상태를 내구성 있게 유지하는 기능과, 모니터링 루프가 최근 보고된 사고를 기억할 수 있도록 상태 기반으로 전환하는 기능이 명시됐다. 프로젝트는 https://github.com/langchain-samples/sre-agent 에 오픈소스로 공개되어 있으며, 사용자는 구현을 직접 시험하거나 코드에 기여하고 피드백을 제공할 수 있다.

🧾 핵심 주장 / 시사점

• 자율성의 범위를 읽기와 진단에 넓게 부여하면서도 변경 권한은 별도 실행 경로와 사람 승인으로 격리하면, 운영 자동화와 프로덕션 통제를 동시에 유지할 수 있다.
• 모든 정상 검사에 강력한 오케스트레이터를 사용하는 대신 저비용 수집·분석 경로와 주문형 심층 조사 경로를 분리하는 것이 반복 감시의 비용을 줄이는 핵심이었다.
• 추적은 단순한 디버깅 기록을 넘어 비용 낭비, 반복 호출, 오탐, 데이터 누락을 찾아내고 사람의 수정 결과를 회귀 평가와 자동 코드 개선으로 연결하는 운영 자산으로 활용됐다.

✅ 액션 아이템

• 정기 감시는 Python 클라이언트로 원시 상태를 모은 뒤 Haiku 단일 호출로 심각도 보고서를 만들고, 전체 오케스트레이터 기동은 줄인다.
• 진단 시 파드·확장·성능·로그·보안·신뢰성 서브에이전트를 병렬 조사하고, Sonnet 오케스트레이터는 우선순위 통합에만 쓴다.
• 읽기 권한과 변경 실행을 분리하고, 모든 쓰기는 change-executor와 Slack 사람 승인·RBAC 경계를 통과하게 한다.

❓ 열린 질문

• 검사당 비용 95~99% 절감을 유지하려면 감시 주기와 Haiku 단일 호출 범위를 어디에 둘 것인가?
• 서브에이전트 병렬 조사 결과를 통합할 때 우선순위를 가르는 심각도·근거 기준은 무엇인가?
• 승인·수정·거절 기록을 회귀 평가와 자동 개선으로 옮길 때 어떤 실패 유형을 먼저 학습 대상으로 삼을 것인가?