software

블록/구스를 AI SRE 에이전트로 전환하기

발행: (2026년 1월 14일 오전 10:25 GMT+9)
8 분 소요
원문: Dev.to

Source: Dev.to

Cristian Angulo

바로 그 때문에 저는 block/goose를 AI 기반 SRE 에이전트로 실험하기 시작했습니다.

이 글에서는 제가 Goose를 실제 SRE처럼 동작하도록 설정한 방법을 설명합니다: AWS CloudWatch를 쿼리하고, 사고를 분석하며, 완전히 재현 가능한 Nix 환경 안에서 운영하는 과정입니다.

block/goose란?

block/goose는 LLM과 외부 도구를 활용해 워크플로우를 실행하도록 설계된 자율 에이전트 프레임워크입니다. 이를 CLI‑네이티브 AI 운영자라고 생각하면 됩니다. 이 운영자는 다음을 수행할 수 있습니다:

  • 도구 호출 (API, CLI, MCP 서버 등)
  • 세션 컨텍스트 유지
  • 다단계 추론 루프 실행

Goose가 SRE에게 흥미로운 이유는 도구를 대체하려는 것이 아니라 그 오케스트레이션을 담당한다는 점입니다.

왜 AI SRE 에이전트인가?

실제 SRE는 대부분의 시간을 다음과 같은 작업에 할애합니다:

  • 로그, 메트릭, 알람을 통한 조사
  • 동일한 진단 단계를 반복
  • 인프라 상태를 최근 변경 사항과 교차 검증
  • 운영 토일 감소

이 레포는 Goose를 다음을 수행할 수 있는 에이전트로 전환합니다:

  • CloudWatch 로그, 메트릭, 알람 조회
  • AWS 인프라 건강 상태에 대한 추론
  • 구조화된 사고 대응 워크플로우 수행
  • 최초 대응 조사자 역할 수행

이는 ChatOps 같은 겉핥기가 아니라, 실제 운영 보조 도구입니다.

아키텍처 개요

설정은 세 가지 기둥으로 구성됩니다:

  • Goose를 추론 엔진으로 사용
  • MCP 서버를 도구 제공자로 사용
  • Nix Flakes를 환경 오케스트레이터로 사용
Goose (LLM Agent)
   ├── CloudWatch MCP Server
   ├── AWS CLI
   ├── GitHub MCP (optional)
   └── Local tooling (jq, httpie, docker, task)

모든 것이 재현 가능한 개발 셸 안에서 실행됩니다.

재현 가능한 환경 (Nix)

다른 모든 프로젝트와 마찬가지로, 이 프로젝트도 flake.nix에 의해 구동됩니다.

왜? SRE 도구는 쉽게 깨지기 때문입니다:

  • AWS CLI 버전
  • Node와 Python 도구의 차이
  • uvx 또는 npx를 통한 MCP 서버

Nix는 이러한 모든 편차를 없애줍니다. 쉘에 들어가면 이미 다음을 사용할 수 있습니다:

  • AWS 자격 증명
  • Goose CLI
  • CloudWatch 도구
  • JSON 처리 도구

README 의식이 필요 없습니다. “먼저 이것을 설치하세요” 같은 안내도 없습니다.

Goose를 SRE 에이전트로 구성하기

Provider & Model

NIXPKGS_ALLOW_UNFREE=1
GOOGLE_GEMINI_MODEL_NAME=gemini-2.5-flash
GITHUB_PERSONAL_ACCESS_TOKEN=
SENTRY_ACCESS_TOKEN=

빠르고 저렴하며 도구 오케스트레이션에 강함 — SRE 작업에 최적입니다.

CloudWatch를 일등 도구로 활용

CloudWatch MCP Extension

GOOSE_PROVIDER: google
GOOSE_MODEL: gemini-2.5-flash
extensions:
  cloudwatch:
    enabled: true
    type: stdio
    name: cloudwatch
    description: AWS CloudWatch Observability (metrics/logs/alarms) via awslabs.cloudwatch-mcp-server
    cmd: uvx
    args:
      - awslabs.cloudwatch-mcp-server@latest
    envs:
      region: us-east-1
      profile: default
      FASTMCP_LOG_LEVEL: ERROR
    env_keys: []
    timeout: 30000
    bundled: null
    available_tools: []
  github:
    enabled: true
    type: stdio
    name: github
    description: GitHub MCP Server
    cmd: npx
    args:
      - -y
      - "@modelcontextprotocol/server-github"
    timeout: 30000
  sentry:
    enabled: true
    type: stdio
    name: sentry
    description: Sentry MCP Server
    cmd: npx
    args:
      - -y
      - mcp-remote@latest
      - https://mcp.sentry.dev/mcp
    timeout: 30000

이를 통해 에이전트는 다음을 수행할 수 있습니다:

  • 메트릭 가져오기
  • 로그 조회
  • 알람 검사
  • 시계열 데이터에 대한 추론

이는 SRE가 수동으로 검토하는 동일한 데이터이며, 훨씬 빠르게 처리됩니다.

Goose가 SRE처럼 행동하는 방법

일반적인 질문으로 Goose에 프롬프트를 주는 대신, 저는 그것을 팀원처럼 대합니다.

예시

  • “지난 30분 동안 발생한 5xx 오류 증가를 조사해 주세요.”
  • “지연 시간이 배포와 연관되는지 확인해 주세요.”
  • “이 서비스에 대한 CloudWatch 알람을 요약해 주세요.”

Goose:

  1. 적절한 도구를 선택합니다.
  2. CloudWatch에 쿼리를 실행합니다.
  3. 결과를 해석합니다.
  4. 사람이 읽기 쉬운 진단을 제공합니다.

대시보드 없음. 클릭도 없음. 답변만 제공합니다.

왜 이렇게 작동하는가

  1. 툴, 플러그인이 아니라 – Goose는 메트릭을 헛소리하지 않고 실제 AWS API를 조회합니다.
  2. 재현성 – 누구나 레포를 복제하고 동일한 SRE 에이전트를 얻을 수 있습니다.
  3. 조합성 – 다음을 추가할 수 있습니다:
    • GitHub MCP (PR 연관성을 위해)
    • PagerDuty
    • Terraform 상태 검사
    • 맞춤형 런북

에이전트는 인프라와 함께 진화합니다.

환경 진입

nix --extra-experimental-features 'nix-command flakes' develop --impure

왜 --impure인가?

  • AWS 자격 증명
  • Docker 소켓
  • 로컬 MCP 바이너리

이는 의도된 것이며 제어되고 있습니다.

이것이 아닌 것

  • ❌ 온콜 엔지니어를 대체하는 것
  • ❌ 마법 같은 “프로덕션 고치기” 봇
  • ❌ 또 다른 ChatOps 장난감

이것은 다:

  • 첫 번째 응답 조사관
  • 상황 수집 기계
  • SRE를 위한 힘 증폭기

결론

SRE 작업은 패턴 기반이며, 반복적이고, 높은 가시성을 가지고 있습니다. LLM‑기반 에이전트를 실제 재현 가능한 도구와 결합함으로써, 엔지니어만이 제공할 수 있는 미묘한 의사결정을 위해 인간을 루프에 남겨두면서도 사고 대응의 시끄럽고 반복적인 부분을 자동화할 수 있습니다. block/goose 로 구동되는 Goose는 신뢰할 수 있고 확장 가능한 AI‑보강 SRE를 향한 실용적인 경로를 보여줍니다.

절차적.

이는 AI 에이전트에게 완벽합니다 — 단, 다음 조건을 만족한다면:

  • 실제 도구 사용
  • 실제 환경에서 실행
  • 운영 경계를 준수

block/goose, MCP 서버, 그리고 Nix를 사용하면 바로 그 조건을 충족합니다.

실제로 운영을 수행하는 AI 에이전트에 관심이 있다면, 여기서 시작하는 것이 좋습니다.

Back to Blog

관련 글

더 보기 »