서론 (Introduction)

제품을 운영하다 보면 익숙한 장면이 있습니다. Datadog 에러 알림이 Slack에 도착하고, 누군가 스레드에서 첫 번째 대응 조사를 시작합니다 — "이 에러가 무엇인가요?". 로그를 읽고, 트레이스(trace)를 따라가며, 코드를 열어 원인에 대한 가설을 세웁니다. 처음 30분은 대부분 일상적인 작업입니다.

이 글은 Cloudflare Workers + GitHub Actions + Claude Code를 사용하여 이 30분을 자동화하는 AI 에이전트에 관한 것입니다. 아키텍처, 이 스택을 선택한 이유, 그리고 실제 운영 환경에서 한 달간 측정된 비용을 다룹니다.

내가 만든 것: 아키텍처 (What I built: the architecture)

구성 요소는 단 네 가지뿐입니다.

핵심 결정 사항은 Worker는 가벼운 수신기로 유지하고, 무거운 조사는 GitHub Actions에서 실행한다는 점입니다. Slack의 Events API는 3초 이내에 응답할 것을 요구하므로, Worker는 서명(signature)을 검증하고 메시지를 알림으로 분류한 뒤 즉시 repository_dispatch를 실행합니다. 조사 자체는 Actions에서 Claude Code CLI를 헤드리스(headless) 모드로 실행하며(claude -p --model sonnet), 제품 저장소의 얕은 체크아웃(shallow checkout)과 Datadog MCP 서버(읽기 전용 도구만 사용)를 기반으로 작동합니다.

Datadog 웹훅(webhooks)이 Worker를 직접 호출할 수도 있지만, 흐름을 의도적으로 Slack을 거치도록 설계했습니다. 알림, 조사 결과, 그리고 후속 논의를 하나의 스레드에 유지함으로써 Slack 알림 채널을 에러 처리의 아카이브로 만듭니다. Slack 게시물을 트리거로 사용하여, 해당 메시지에 스레드 답글을 다는 것만으로 모든 과정이 완료됩니다.

조사 결과 코드 변경이 필요하다고 결론이 나면, 답글에 '이슈 생성 (Create Issue)' 버튼이 포함됩니다. 만약 우리가 이에 따라 조치를 취하기로 결정하면, 해당 버튼이 GitHub Issue를 생성하고, 로컬 Claude Code 세션이 해당 Issue를 가져와 수정 사항을 담은 풀 리퀘스트 (Pull Request)를 오픈합니다. 에이전트의 역할은 첫 번째 응답 조사와 Issue 초안 작성에서 종료되며, 수정 작업은 인간의 검토가 적용되는 흐름을 통해 진행됩니다.

에이전트는 Slack에 직접 게시물을 올리지 않습니다. 에이전트는 조사 결과를 Markdown 파일에 작성하기만 하며, 이후의 신뢰할 수 있는 단계에서 게시를 수행합니다. 알림 텍스트에는 사용자 입력이 포함될 수 있으므로 공격 표면 (Attack Surface)이 될 수 있습니다. 따라서 페이로드 (Payload)는 항상 데이터로 처리되며, 스킬 디렉토리는 읽기 전용 (Read-only)으로 설정됩니다. 또한, 게시 단계에서는 출력물에 비밀 정보 (Secret)처럼 보이는 내용이 포함되어 있으면 게시를 거부합니다. 이는 프롬프트 인젝션 (Prompt-injection) 방어책의 일환입니다.

이 스택을 선택한 이유

1. 조사가 사용자의 코드베이스 내부까지 도달할 수 있음

Datadog의 내장 AI 기능은 로그 (Logs), 메트릭 (Metrics), 트레이스 (Traces)와 같은 텔레메트리 (Telemetry) 범위 내에 머무릅니다. 첫 번째 응답에서 실제로 원하는 것은 "어느 파일의 몇 번째 줄이며, 대략 어떻게 수정해야 하는가"에 대한 가설입니다. 자체 에이전트를 사용하면 저장소 (Repository)를 체크아웃하여 file:line을 정확히 짚어내고 수정 방안을 스케치하도록 할 수 있습니다. 이것이 기성 제품 (Off-the-shelf) 옵션과의 가장 큰 차이점입니다.

2. 실행당 비용이 명확하게 보이는 완전한 사용량 기반 모델

이 에이전트의 모든 부분은 실행될 때만 비용이 청구됩니다. 유휴 비용 (Idle cost)은 0이며, 알림이 발생하지 않으면 비용을 지불하지 않습니다. SaaS AI 기능은 사용자 수 (Seats)나 더 높은 등급의 SKU에 묶이는 경향이 있으며, 알림 한 건의 조사 비용이 얼마인지 확인할 수 없습니다. 직접 구축하면 기능별로 API 키를 분리하는 것만으로도 아래에 표시된 것과 같이 실행당 비용을 측정할 수 있습니다.

3. Cloudflare를 통해 수신기를 저렴하고 간단하게 실행할 수 있음

Workers는 V8 isolates 위에서 실행되므로 시작 속도가 빠르고 메모리 사용량이 적습니다. 따라서 "3초 이내에 Slack 이벤트를 처리하고 비동기 작업으로 넘겨야 한다"는 요구 사항에 완벽히 부합합니다. 상태 관리를 위해 Worker에서 D1 (SQLite)을 직접 사용할 수 있으며, 중복 제거 (dedup) 테이블 하나만 있으면 충분했습니다. Hono로 작성된 이 Worker는 아주 작은 웹 앱에 불과하며, 무료 티어(free tier)만으로도 이 워크로드를 완전히 감당할 수 있습니다.

조사(investigation) 프로세스 자체는 Workers 대신 GitHub Actions에서 실행됩니다. 왜냐하면 전체 리포지토리를 체크아웃(check out)하고 Claude Code를 실행해야 하기 때문입니다. 파일 시스템 작업이 많고 수 분이 소요되는 워크로드는 CPU 시간과 파일 시스템 제약이 있는 Workers보다 repository_dispatch에 의해 시작되는 Actions 작업에 더 적합합니다. Actions는 코드 바로 옆에 위치하며, 비밀 관리 (secret management) 기능이 내장되어 있고, 이벤트 기반(event-driven)이므로 대기 비용이 발생하지 않습니다.

비용 절감의 핵심: 동일한 에러를 두 번 조사하지 마라

이 메커니즘은 실제 운영 환경에서 가장 중요한 역할을 하는 것으로 나타났습니다.

에러 알림의 현실은 동일한 에러가 반복해서 발생한다는 점입니다. 가장 오랫동안 수정되지 않고 남아 있는 에러들은 실제 영향력이 작은 것들입니다. 수정 사항이 백로그 (backlog)에 머물러 있는 동안 이 에러들은 계속해서 발생합니다. 이러한 반복적인 알림은 알림 피로 (notification fatigue)를 유발하며, 만약 AI가 매번 동일한 조사를 다시 수행한다면 그 낭비는 곧바로 API 비용으로 직결됩니다. "이미 알고 있는 에러가 다시 발생했다"는 상황에 대해 전체 조사를 다시 수행하는 것은 의미가 없습니다.

따라서 Worker는 D1에 조사된 이슈 테이블을 유지하며, Datadog Error Tracking이 할당하는 issue.id를 기반으로 지문 (fingerprint)을 생성합니다.

CREATE TABLE incident_issues (
  issue_id    TEXT PRIMARY KEY,   -- Datadog Error Tracking issue.id
  channel     TEXT NOT NULL,
...

만약 14일 이내에 동일한 issue.id를 가진 알림이 도착하면, Actions는 실행되지 않으며 (= 토큰 소모 제로), 새로운 알림의 스레드에는 다음과 같은 링크만 제공됩니다: "이 에러는 이미 처리 중입니다 — 첫 번째 조사 스레드를 확인하세요."

이 확인(check)은 D1의 INSERT ... ON CONFLICT DO NOTHING을 사용하므로, 동일한 문제에 대한 동시 알림이라도 두 개의 조사가 시작될 수 없습니다.

이 메커니즘의 부수 효과는 조사와 모든 후속 논의가 첫 번째 스레드에 누적된다는 것입니다. 동일한 오류에 대한 중복된 스레드 —

먼저, 분모를 살펴보겠습니다. 이 기간 동안 프로덕션 환경에서만 제품의 에러 모니터가 265회 트리거(Triggered)되었습니다. 실제 조사(GitHub Actions 실행) 횟수는 121회였습니다. 복구됨(Recovered) / 재알림(Re-notified) 게시물을 필터링하고 중복 제거(dedup) 메커니즘을 적용하여 실행 횟수를 알림 볼륨의 절반 미만으로 줄였습니다. 건너뛴 실행은 비용이 정확히 0원입니다.

AI (Anthropic API)

이 기능에 전용된 API 키는 $93.90(초기 설정 중 테스트 실행 포함)를 소비했습니다. 이를 121회의 조사로 나누면, 조사당 약 $0.78입니다. 동일한 첫 번째 응답에 30분을 소비하는 사람과 비교했을 때, 실행당 1달러 미만의 비용은 충분히 가치가 있습니다.

실제로 Datadog의 내장 옵션보다 저렴한가요?

Datadog은 AI Credits를 통해 과금되는 Bits Investigation을 통해 자율 조사를 제공합니다. 이 글을 쓰는 시점 기준으로: **월 500 크레딧당 $500 (연간 계약 기준; 온디맨드(on-demand)는 크레딧당 $1.30)**이며, 한 번의 자율 조사는 약 6.5 크레딧을 소비합니다. 즉, 조사당 대략 $6.5–8.5가 소요됩니다.

실행당 $0.78인 자체 구축 에이전트는 그 비용의 1/8에서 1/10 수준입니다. Bits를 통해 한 달에 121회를 실행하면 대략 $790–1,000가 됩니다. 또한 크레딧 약정은 월 $500부터 시작하지만, 이 스택은 고정 비용이 전혀 없습니다. Bits는 관리형 서비스이며 별도의 설정이 필요 없으므로 엄격한 승패의 비교는 아니지만, 알림 기반의 첫 번째 응답 조사라는 특정 작업에 있어서는 자체 구축 방식이 한 자릿수(an order of magnitude) 더 저렴하게 운영됩니다.

GitHub Actions

ubuntu-latest 작업은 평균적으로 각각 3분이 소요되었으며, 121회의 실행은 한 달 동안 총 약 360분을 기록했습니다. 이는 GitHub 유료 플랜에 포함된 Actions 무료 허용량(Team 플랜은 월 3,000분, Enterprise 플랜은 50,000분) 범위 내에 있으므로, 추가 비용은 0원이었습니다. 설령 허용량이 소진되어 매 분마다 비용이 청구된다 하더라도, Linux 러너(runner)의 비용은 분당 $0.008로 월 $3 미만입니다. 각 작업에 timeout-minutes: 20을 설정하더라도 최악의 경우 2,420분 ≈ $19입니다.

Cloudflare

Worker는 알림 이벤트만 수신하므로, 요청량(request volume)이 무료 티어(일일 10만 건의 요청)에 도달할 일이 전혀 없습니다. D1은 알림당 몇 개의 행(row)을 읽고 쓰는데, 이는 무료 티어와 비교하면 무시해도 될 수준입니다. 사실상 $0입니다 (이미 Workers 유료 플랜을 사용 중이라면 월 $5의 기본 요금만 발생합니다).

Summary

월 $94로 모든 알림에 대해 자동적인 1차 대응 조사가 이루어지며, 그 결과는 스레드(thread)에 축적됩니다. 매번 사람이 이 1차 대응을 수행하는 비용과 비교하면, 이 시스템은 스스로 비용을 충당하고도 남습니다. 또한 청구액의 거의 전부가 Anthropic API 사용료 — 즉 순수 조사 비용 — 이기 때문에, 이 스택은 인프라 고정 비용이 전혀 발생하지 않습니다.

Closing

Datadog 알림을 위한 1차 대응 에이전트는 Cloudflare Workers (수신) + GitHub Actions (실행) + Claude Code (조사)로 구성됩니다. 이 스택의 핵심은 이벤트 기반(event-driven) 구성 요소로만 구축되었기 때문에, 구조적으로 고정 비용이 발생할 수 없다는 점입니다.

실제 운영에 있어서, 그 어떤 조사 능력보다 더 중요했던 메커니즘은 아주 단순한 것이었습니다: 동일한 에러를 두 번 조사하지 않는 것입니다. 에러 알림 운영은 영향력이 낮고 수정되지 않은 에러가 계속해서 발생하는 현실과 마주하며, AI 에이전트를 알림에 단순히 연결하기만 하면 그 현실이 곧바로 API 지출로 직결됩니다. 중복 제거(Dedup)는 비용 제어이자, 알림 피로(notification-fatigue) 제어이며, 동시에 논의를 하나의 스레드로 집중시키는 운영 개선책임이 밝혀졌습니다.

다음 단계로서, 저는 첫 번째 응답의 범위를 확장하고자 합니다. 우선, Actions 측 에이전트가 수정 브랜치(fix branch)를 생성하고 초안 PR(draft PR)을 올리는 단계까지 진행하도록 하는 것입니다 (병합 결정은 여전히 사람이 담당합니다). 그 너머로, Cloudflare가 Sandbox 및 Dynamic Workers와 같은 에이전트 지향적 런타임(agent-oriented runtimes)을 계속 확장하고 있으므로, 조사 및 수정 실행(fix execution)을 GitHub Actions에서 Cloudflare로 옮겨서, 수신부터 수정 PR까지의 모든 과정을 엣지(edge)에서 완료하는 것을 시도해보고 싶습니다.

References

• Cloudflare Workers
• Cloudflare D1
• Datadog MCP Server