<aside> 📌

Part 2 · Ch04 — CI/CD 파이프라인 통합 에이전트 (Project 4)

Ch01~03에서 FinSight를 빌드 → 리뷰 → 스케일까지 끌어올렸다. 마지막 한 층은 **운영(operations)**이다. CI가 깨지고 prod 에러가 터지는 순간, 사람이 시키지 않아도 스스로 깨어나 1차 대응하는 운영 에이전트를 같은 코드베이스 위에 세운다.

한 줄 요약: 이벤트 기반으로 깨어나 CI 실패 → 자동 PR, 유저 질의 응답, alert 노이즈/신호 판정 → escalation까지. 핵심 사상은 Alert as Code — 사람용 클릭에서 에이전트용 코드로.

</aside>

1. 정체성 — 개인 에이전트 vs 운영 에이전트

🛡️ 1-1. 두 종(種)을 가르는 네 축

<aside> 🛡️

이 챕터의 oncall 에이전트는 Part 4의 24/7 Hermes와 형제이자 뿌리지만 전혀 다른 일을 한다. Hermes는 나만 부르는 개인 비서, oncall은 건물 1층에 앉은 24시간 당직 경비다. 책임 대상도, 깨어나는 이유도 다르다.

</aside>

축	개인 에이전트 (Hermes · Part 4)	운영 에이전트 (지금 만드는 oncall)
대상	나 한 사람	팀 · 서비스 · 유저 (공유 자산)
트리거	내가 말을 건다	CI 실패 · prod alert · 유저 질문 (시스템 이벤트)
응답	나에게 답하면 끝	유저에게 답 + escalation으로 사람을 깨운다
리스크	개인 작업 → 낮음	프로덕션 → 높음 → 엄격한 게이트

<aside> ⚠️

Hermes와 헷갈리지 말 것. "24/7 대화형 에이전트"라고 다 같은 게 아니다. 대상·트리거·응답·리스크 네 축이 설계를 완전히 바꾼다. Hermes는 요청(request) 처리, oncall은 사고(incident) 대응이다.

</aside>

🔒 1-2. 프로덕션 = 엄격한 게이트 세 개

<aside> 🔒

원칙: 자율성은 입력에서 받되, 권한은 출구에서 조인다. 트리거는 넓게 열고, 쓰기 권한은 좁게 닫는다.

</aside>

[게이트 ①] read-only      prod 직접 안 건드림. Supabase MCP ?read_only=true
                          읽어서 분석 → 바꿀 건 PR(사람 게이트)로만
[게이트 ②] noise filter   모든 이벤트에 반응 = 알람 공해. 신호/소음 먼저 가른다 (§4)
[게이트 ③] escalation     "이건 내 선을 넘는다"고 인정하고 사람을 부른다
                          못 깨우면 위험, 아무때나 깨우면 신뢰 상실 → 이 경계가 품질

<aside> 💡

권한은 좁게, 판단은 깊게. 읽기는 마음껏, 쓰기는 PR로, 못 끝낼 일은 사람에게. 자율 에이전트를 프로덕션에 붙일 때 첫 질문은 *"무엇을 시킬까"*가 아니라 **"무엇을 못 하게 막을까"**다.

</aside>

2. 입구 — 트리거 3종을 코드/API로

🚪 2-1. git에 박힌 세 개의 입구

<aside> 🚪

에이전트가 운영을 "다루려면", 그 일은 사람용 GUI가 아니라 코드/API 인터페이스로 존재해야 한다. 트리거 3종을 FinSight repo 안에 코드로 박는다 — 클릭 설정이 아니라 git에 들어가고 PR로 리뷰되는 인터페이스로. (이 한 문장이 §6 Alert as Code에서 정점이 된다.)

</aside>

트리거	구현	다룬 곳
① CI 실패	GitHub Actions 워크플로우 — 빌드가 빨갛게 깨지면 깨운다	§3
② prod alert	PostHog error tracking webhook (Ch03에서 깐 그것)	§5
③ 유저 질문	대화형 입구 — always-on 인프라 필요	§4 컨셉, 셋업은 Part 4

<aside> ♻️

하네스 재사용. 빌드·리뷰에 쓰던 하네스(CLAUDE.md · skills · rules)를 운영 하네스가 그대로 재사용한다. "같은 에이전트로 빌드·리뷰·운영" — 새 도구를 배우는 비용이 0. 이게 단일 스택 end-to-end의 실체다.

</aside>