서론

프로덕트를 운영하다 보면, Datadog의 에러 알람이 Slack으로 흘러들어오고 누군가가 "이게 무슨 에러지?"라며 스레드에서 1차 조사를 시작하는 광경이 일상적으로 벌어집니다. 로그를 보고, 트레이스 (trace)를 따라가고, 해당 코드를 열어 원인을 짐작하는 이 첫 30분은 정형화된 작업이 많습니다.

이 기사는 이 30분의 정형화된 작업을 Cloudflare Workers + GitHub Actions + Claude Code로 자동화하는 AI 에이전트를 구축한 이야기입니다. 아키텍처와 스택 선정 이유, 약 1개월간 운영하며 측정한 실제 비용감을 정리합니다.

무엇을 만들었는가: 전체 아키텍처

컴포넌트는 4개뿐입니다.

정상 계통의 시퀀스는 이것뿐입니다.

포인트는 Worker는 어디까지나 얇은 수신구 역할에 충실하고, 무거운 조사는 GitHub Actions 측으로 넘겼다는 점입니다. Slack의 Events API는 3초 이내의 응답을 요구하므로, Worker는 서명 검증과 알람 판정만 수행하고 즉시 repository_dispatch를 던집니다. 조사 본체는 Actions 상에서 Claude Code CLI를 헤드리스 실행(claude -p --model sonnet)하고, 대상 프로덕트의 리포지토리를 shallow checkout 한 것과 Datadog MCP 서버(read-only 툴만 허용)를 재료로 사용하여 1차 조사를 수행하게 합니다.

Datadog의 Webhook으로 Worker를 직접 호출할 수도 있지만, 일부러 Slack을 경유합니다. 알람, 조사 결과, 그리고 그 이후의 논의를 동일한 스레드에 남김으로써 Slack의 알람 채널이 그대로 에러 대응의 스톡(stock)이 되기 때문입니다. 트리거를 Slack의 알람 게시로 설정해 두면, 해당 메시지에 대한 스레드 답장만으로 이 형태가 성립됩니다.

조사 결과 "코드 수정이 필요함"이라고 판단된 경우에는 스레드 답장에 Issue 생성 버튼이 붙습니다. 본격적으로 대응하기로 결정하면 이 버튼으로 GitHub Issue를 생성하고, 이후에는 로컬의 Claude Code에 해당 Issue를 읽히게 하여 수정 풀 리퀘스트 (Pull Request)를 올리는 방식으로 운영하고 있습니다. 에이전트의 업무는 어디까지나 1차 조사와 Issue 초안 작성까지이며, 수정은 인간의 리뷰가 개입되는 플로우에 태우는 식의 선긋기입니다.

에이전트는 Slack에 직접 게시하지 않습니다. 조사 결과를 Markdown 파일로 작성하는 것까지가 업무이며, 게시 작업은 후속되는 "신뢰할 수 있는" 단계에서 수행합니다. 알람 본문은 사용자 입력이 섞일 수 있는 공격 가능한 면(attack surface)이므로, 페이로드(payload)를 항상 데이터로 취급한다, 스킬 디렉토리를 read-only로 설정한다, 출력에 시크릿(secret) 같은 문자열이 있으면 게시를 거부한다 등의 프롬프트 인젝션 (Prompt Injection) 대책도 포함되어 있습니다.

왜 이 스택으로 했는가

1. 자사의 코드베이스까지 깊숙이 파고드는 조사가 가능하다

Datadog 표준 AI 기능은 텔레메트리 (telemetry: 로그·메트릭·트레이스)의 세계에서 완결됩니다. 하지만 1차 조사에서 정말로 원하는 것은 "어느 파일의 어느 줄이 원인이며, 어떻게 고치면 좋을지"까지의 짐작입니다. 자체 에이전트라면 대상 리포지토리를 checkout 하여 file:line까지 특정하게 하고, 수정 방향성까지 쓰게 할 수 있습니다. 이 점이 기성 제품과의 가장 큰 차이점이었습니다.

2. 비용이 완전히 종량제이며, 1회당 비용을 확인할 수 있다

이 에이전트의 구성 요소는 모두 "작동한 만큼 과금"됩니다. 유휴 시의 비용은 제로이며, 알람이 울리지 않으면 1원도 들지 않습니다. SaaS의 AI 기능은 시트 과금이나 상위 SKU에 묶이는 경우가 많아 "이 알람 1건의 조사에 얼마가 들었는지"가 보이지 않습니다. 자체 구축 시에는 API 키를 기능별로 나누는 것만으로, 후술할 내용처럼 실제 1회당 비용을 산출할 수 있습니다.

3. Cloudflare라면 수신구를 저렴하고 간단하게 운영할 수 있다

수신구를 Cloudflare Workers로 선택한 것은 yusukebe 님의 "AI 에이전트는 Cloudflare에 걸어라"라는 글의 영향이 큽니다. V8 Isolate 기반의 Workers는 시작 속도가 빠르고 메모리 효율이 좋기 때문에, "Slack 이벤트를 3초 이내에 처리하여 비동기 처리로 넘긴다"라는 이번 수신구의 요구 사항에 딱 들어맞습니다. 상태 관리 또한 D1 (SQLite)을 Worker에서 직접 사용할 수 있어, 중복 체크를 위한 테이블 하나만 만들면 충분했습니다. Hono로 작성하면 Worker 자체는 작은 웹 애플리케이션에 불과하여 인지 부하(Cognitive Load)가 낮다는 점도 장점입니다.

반면, 조사 본체를 Workers가 아닌 GitHub Actions에 둔 이유는 리포지토리 전체를 checkout 하여 Claude Code를 실행한다는 요구 사항 때문입니다. 파일 시스템을 전제로 하며 수 분에서 십수 분이 소요되는 워크로드의 경우, CPU 시간과 파일 시스템의 제약이 있는 Workers보다는 repository_dispatch로 기동하는 Actions의 잡(Job)이 더 적합합니다. Actions는 코드 바로 옆에 위치하며, 시크릿(Secret) 관리 기능도 갖추고 있고, 이벤트 드리븐(Event-driven) 방식이라 대기 비용이 발생하지 않습니다.

비용 측면의 고안: 동일한 에러는 두 번 조사하지 않는다

운영하면서 가장 효과적이었던 것이 바로 이 기구입니다.

에러 알람의 현실은 동일한 에러가 반복해서 울린다는 점입니다. 게다가 "실질적인 피해는 작지만 수정되지 않은 에러"일수록 대응이 뒤로 밀린 채 계속 울려 퍼집니다. 방치된 동일 유형의 알람은 알림 피로(Notification Fatigue)를 유발하며, 그때마다 AI가 동일한 조사를 반복하면 API 비용도 낭비됩니다. 실제 운영에서 흔히 발생하는 "이미 아는 에러가 또 울리는 것"에 매번 전체 조사를 실행할 의미는 없습니다.

그래서 Datadog의 Error Tracking이 발행하는 issue.id를 핑거프린트(Fingerprint)로 삼아, D1에 조사 완료 테이블을 생성했습니다.

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

동일한 issue.id를 가진 알람이 14일 이내에 다시 발생하면, Actions는 기동하지 않고(즉, 토큰 소비 제로), 새로운 알람 스레드에 "이 에러는 대응 중입니다. 첫 번째 대응 스레드는 여기입니다"라며 최초 조사 스레드로의 링크만 반환합니다.

판정은 D1에 대한 INSERT ... ON CONFLICT DO NOTHING으로 수행하므로, 동시에 여러 알람이 들어와도 조사가 중복으로 실행되지 않습니다.

이 기구의 부수적인 효과로, 조사 결과와 그 이후의 논의가 첫 번째 스레드로 집약된다는 점도 은근히 효과적입니다. 동일한 에러의 스레드가 난립하여 "어디서 이야기하고 있었지?"라고 고민하게 되는 문제가 구조적으로 발생하지 않습니다. 14일이 지나 재발한 경우에는 "아직 수정되지 않았거나 상황이 변했을 수도 있다"고 간주하여 재조사를 실행합니다.

세부적인 설계 판단으로서, 중복 판정에 실패했을 때(D1 장애 또는 issue.id를 가져올 수 없는 알람)는 조사를 실행하는 쪽으로 무게를 두도록 하고 있습니다. 드물게 중복 조사가 실행되는 비용보다, 필요한 조사가 누락되는 비용이 더 크기 때문입니다.

이 외에도 비용과 폭주를 억제하기 위한 가드를 몇 가지 추가했습니다.

• 모델은 Sonnet으로 고정하고, 잡(Job)에 timeout-minutes: 20 상한 설정
• 에이전트에게 허용하는 도구는 read-only인 Datadog MCP 도구와 로컬 파일 조작만 허용 (Bash 불허)
• API 키를 기능별로 분리하여 비용을 기능 단위로 측정할 수 있도록 구성

실측 비용 체감

2026/06/21 ~ 07/19 약 1개월간 실제 운영한 실측값입니다.

전제로, 조사 대상 코드베이스는 TypeScript 중심의 모노레포(Monorepo)이며, 소스 코드만 약 4,600개 파일, 디렉토리 약 1,800개, 합계 100만 행이 넘는 규모입니다. 대상 사용자가 천 명 규모인 업무용 애플리케이션으로, 단순한 샘플이 아니라 이 정도 규모의 프로덕션 코드에 대해 다음과 같은 비용 체감으로 운영하고 있습니다.

알람 발생 수와 조사 실행 수

먼저 전제가 되는 모수입니다. 이 기간 동안 대상 프로덕트의 에러 계열 모니터 발보(Triggered)는 운영 환경에서만 265건 있었습니다. 반면, 실제로 조사(GitHub Actions)가 실행된 것은 121회입니다. Recovered / Re-notified 제외 및 중복 에러 스킵 메커니즘을 통해, 발보 건수의 절반 이하로 실행을 좁힐 수 있었습니다. 스킵된 부분은 전부 0원입니다.

AI (Anthropic API)

이 기능 전용 API 키 소비액은 $93.90였습니다(구축 기간의 테스트 실행 포함). 조사 실행 121회로 나누면, 1회 1차 조사당 약 $0.78입니다. 1회 1차 조사에 사람이 30분을 쓴다고 가정하면, 1회당 1달러 미만은 충분히 저렴하다고 느껴집니다.

Datadog 표준 AI와 비교했을 때 저렴한가

Datadog에도 자율 조사 기능인 Bits Investigation이 있으며, 이는 AI Credits로 과금됩니다. 집필 시점 기준으로 **$500/500 크레딧·월(연간 계약 기준, 온디맨드는 $1.30/크레딧)**이며, 자율 조사 1회당 약 6.5 크레딧이 소모되므로, 1회 조사당 약 $6.5~8.5입니다.

자체 구성의 약 $0.78/회는 그 1/8~1/10 수준이며, 월 121회를 Bits로 충당할 경우 단순 계산으로 $790~$1,000 상당이 됩니다. 게다가 크레딧 커밋은 월 $500부터 시작하는 반면, 자체 구성은 고정비가 0원입니다. 물론 Bits는 매니지드(Managed) 서비스로서 셋업이 필요 없다는 별도의 가치가 있으므로 단순한 우열을 가릴 수는 없지만, '알람 기반의 1차 조사'라는 용도에 한해서는 자체 구성이 1자리수만큼 더 저렴하게 운영할 수 있습니다.

GitHub Actions

ubuntu-latest 잡(Job)은 1회당 평균 3분으로, 월 121회의 합계는 약 360분이었습니다. GitHub 유료 플랜에 포함된 Actions 무료 할당량(Team 플랜은 월 3,000분, Enterprise는 월 50,000분) 범위 내에 들어오기 때문에, 추가 비용은 0원이었습니다. 만약 무료 할당량을 다 써서 전액 과금된다 하더라도, Linux 러너(Runner)는 $0.008/분이므로 월 $3 미만입니다. 각 잡에는 timeout-minutes: 20 상한을 설정해 두었으므로, 모든 실행이 상한까지 돌아가는 최악의 경우에도 월 2,420분 ≒ $19 정도로 수렴합니다.

Cloudflare

Workers는 알람 이벤트를 받기만 하므로, 요청 수는 무료 할당량(일 10만 요청)에 훨씬 못 미칩니다. D1 역시 읽기/쓰기가 1개 알람당 몇 줄 수준이라 무료 할당량 오차 범위 내입니다. 실질적으로 $0(Workers Paid를 계약하더라도 월 $5의 기본료만 발생)로 운영할 수 있습니다.

요약하자면

월 $94로 알람이 발생할 때마다 1차 조사가 자동으로 실행되고, 결과가 스레드로 집약됩니다. 온콜(On-call) 1차 대응을 사람이 매번 수행하는 비용과 비교하면, 개인적으로는 완전히 본전을 뽑고도 남는다고 느낍니다. 또한, 비용의 거의 전부가 Anthropic API 비용, 즉 순수한 조사 실행 비용이며 인프라 측면의 고정비가 0원이라는 점이 이 스택의 가장 큰 성과입니다.

마치며

Datadog 알람 기반의 1차 조사 에이전트를 Cloudflare Workers(수신부) + GitHub Actions(조사 실행) + Claude Code(조사 본체)로 구성했습니다. 되돌아보면 이 스택의 본질은 "이벤트 기반(Event-driven) 부품들로만 구성했기에, 구조적으로 고정비가 발생하지 않는다"는 점에 있습니다.

운영 측면에서는 화려한 조사 능력보다 "같은 에러를 두 번 조사하지 않는다"라는 소박한 메커니즘이 가장 효과적이었습니다. 에러 알람 운영에는 "고쳐지지는 않았지만 실질적인 피해가 적은 에러가 계속 울리는" 현실이 존재하며, AI 에이전트를 단순하게 연결하기만 하면 그 현실이 그대로 API 비용으로 전환되어 버립니다. 중복 제거(De-duplication)는 비용 대책인 동시에 알람 피로(Alert fatigue) 대책이며, 논의를 스레드로 집약하는 운영 개선이기도 했습니다.

향후 확장 방안으로 고려하고 있는 것은 1차 조사 그 이후 단계입니다. 우선 현실적인 범위 내에서, Issue 생성 이후의 "수정 브랜치(fix branch)를 생성하여 draft PR을 만드는 단계까지"를 Actions 상의 에이전트에게 맡기는 형태(머지(merge) 판단은 반드시 인간이 수행)를 생각하고 있습니다. 더 나아가 Cloudflare가 Sandboxes나 Dynamic Workers와 같은 에이전트용 실행 환경을 확충하고 있으므로, 현재 GitHub Actions에 두고 있는 조사 및 수정 실행 계통을 Cloudflare 측으로 옮겨, 수신부터 수정 풀 리퀘스트(Pull Request) 생성까지를 에지(Edge) 상에서 완결시키는 구성도 시도해보고 싶습니다.

참고

Discussion