AI 에이전트를 당직 근무에 투입하기: Switch와 Wispr Flow를 이용해 Slack에서 자율적인 SRE 상황실을 구축한 방법

Flip the Switch Hackathon (WeMakeDevs × DevTools Academy × Switch)을 위한 심층 튜토리얼 및 아키텍처 워크스루.

새벽 2시의 문제: 왜 고립된 코딩 코파일럿은 장애 상황에서 실패하는가

모든 소프트웨어 엔지니어는 한밤중에 발생하는 중요한 프로덕션(production) 서비스 중단 사태의 절망적인 느낌을 알고 있습니다.

PagerDuty가 경보음을 울립니다. Datadog에서 에러율 그래프가 빨간색으로 치솟습니다. Zendesk에 고객 티켓이 쏟아집니다. Slack에서는 엔지니어들이 혼란스러운 #incident-emergency 채널로 몰려들어가 다음과 같은 다급한 질문들을 주고받습니다:

“09:40 UTC 배포에서 어떤 커밋(commit)이 나갔나요?”

“cart-service가 데이터베이스 마이그레이션 때문인가요, 아니면 쿠폰 파서(coupon parser) 때문인가요? 500 에러를 발생시키고 있나요?”

“누군가 로컬에서 실패를 테스트할 간단한 스크립트를 작성해 줄 수 있나요?”

“v2.13.2로 롤백(rollback)을 실행할 권한이 있는 사람이 있나요?”

지난 2년 동안 Claude Code, GitHub Copilot, Codex, Cursor와 같은 AI 코딩 어시스턴트들은 우리가 소프트웨어를 작성하는 방식을 혁신했습니다. 하지만 주목해야 할 점은 이들이 어디에 존재하는지입니다: 단일 개발자의 IDE나 터미널 내에 고립되어 있습니다.

수백만 달러 규모의 프로덕션 시스템이 다운될 때, 당신의 회사에게 필요한 것은 누군가의 로컬 에디터에서 조용히 타이핑하는 고립된 어시스턴트가 아닙니다. 당신의 회사가 필요로 하는 것은 장애 상황실에 있는 활동적인 팀원입니다.

본 심층 분석에서는 우리가 어떻게 OpsSwitch를 구축했는지 설명합니다. OpsSwitch는 Slack과 Discord 내부에서 실행되는 자율적인 SRE(Site Reliability Engineering) 인시던트 대응 분대입니다. **Switch**에 의해 구동되는 OpsSwitch는 장애 알림을 가로채고, 문제가 된 커밋을 찾아내며, 로컬 재현 스크립트를 실행하고, 인간의 승인(human-in-the-loop sign-off)을 거쳐 안전한 롤백을 준비합니다. 이 모든 과정은 Wispr Flow 음성 받아쓰기를 사용하여 손대지 않고 오케스트레이션됩니다.

1. Switch 소개: AI 팀원을 위한 오픈 소스 인프라

구축에 앞서 우리는 질문했습니다: LLM API에 연결된 간단한 Slack 웹훅(webhook) 봇을 만들 수 없는가?

정답은 단호하게 '아니요'입니다. 단순한 웹훅 봇(webhook bot)은 세 가지 치명적인 아키텍처 결함을 안고 있습니다:

1. 공유 시간 흐름 부재 (No Shared Chronology): 기존의 봇은 상태 비저장형(stateless)이어서, 여러 엔지니어와 동료 에이전트들 사이에서 몇 시간에 걸쳐 진화하는 공유 컨텍스트를 관찰할 수 없습니다.
2. 알림 피로 및 채널 오염 (Alert Fatigue & Channel Pollution): 수백 줄의 원본 스택 트레이스 라인, 터미널 로그, git diff 등을 공개 Slack 채널에 쏟아붓는 행위는 인간의 협업을 압도해버립니다.
3. 심각한 자격 증명 위험 (Severe Credential Risk): GitHub 토큰, AWS 키 또는 Datadog 자격 증명을 LLM의 시스템 프롬프트(system prompt)에 직접 주입하는 것은 치명적인 프롬프트 주입 취약점(prompt-injection vulnerabilities)을 만듭니다.

바로 이 지점에서 **Switch**가 패러다임을 바꿉니다. Switch는 AI 에이전트를 팀 채팅(Slack, Microsoft Teams, Discord, Telegram, Mattermost 등)에 직접 통합하도록 설계된 오픈 소스 인프라입니다.

   인간 엔지니어 (Slack / Discord) ──┐
                                       ├─► [Switch Room] ◄─► [Agent Host] ◄─► [LLM Harness]
   AI 팀원 (Claude / Codex / SRE) ──┘   (공유 로그)      (보안 브로커)  (Claude / OpenAI)

Switch의 특징:

• 모든 채널이 방(Room)입니다: 에이전트들은 자신만의 고유한 아바타, 이름, 시스템 프롬프트 및 기능을 가지고 등장합니다.
• 방 간 연결 가능: 양방향 링크(intake ↔ war-room)를 통해 컨텍스트가 깔끔하게 흐르며, 공개 채널의 노이즈를 방지합니다.
• 누출 방지 자격 증명 브로커 (Zero-leakage credential broker): 에이전트는 원본 API 토큰을 절대 만지지 않습니다. 도구(GitHub, Sentry, Datadog)는 루프백 MCP 프록시(loopback MCP proxies)를 통해 실행되며, Switch의 세션 호스트가 자격 증명을 안전하게 적용합니다.
• 언어에 구애받지 않는 프로토콜 (Language-agnostic protocol): Agent Protocol을 사용하는 모든 에이전트(SSE(Server-Sent Events) 입력, HTTP 출력)는 해당 방에서 협업할 수 있습니다.

2. 시스템 아키텍처: 다중 룸 인시던트 스쿼드 (The Multi-Room Incident Squad)

OpsSwitch는 인시던트 라이프사이클을 두 개의 연결된 방과 세 가지 전문 AI 팀원에 걸쳐 구조화합니다:

graph LR
subgraph Intake_Channel ["#sre-incident-intake (Public)"]
Alert["Incoming Webhook / Human Alert"]
...

세 명의 AI 팀원들:

1. ops-triager (인테이크 및 분류)

#sre-incident-intake 채널에서 청취합니다. 증상과 오류율을 분석하고, SEV-1(치명적인 수익 중단)부터 SEV-4(사소한 외관상의 불일치)까지 심각도를 분류하며, 고위험 사고를 비공개 #sre-incident-war-room으로 에스컬레이션합니다.

2. ops-investigator (원격 측정 및 근본 원인 진단)

#sre-incident-war-room에 상주합니다. 에스컬레이션이 발생하면, Switch GitHub와 Sentry 커넥터를 쿼리하고 배포 기간(deployment window) 동안의 최근 커밋들을 분석하여 의심되는 커밋을 식별한 후, 로컬 샌드박스 내부에 최소 4줄 분량의 재현 스크립트(repro.py)를 생성합니다. 이 재현 스크립트를 실행하고 검증된 트레이스백 출력(traceback output)을 보고합니다.

3. ops-remediator (완화 및 거버넌스 게이트키퍼)

롤백 PR 또는 패치 브랜치를 작성합니다. 워룸에 상호작용 가능한 **승인 카드(Authorization Card)**를 게시하고 엄격한 인간의 검증 단계를 강제합니다: 명시적인 승인이 없는 한, 인증된 온콜 리드로부터 직접적인 확인을 받지 못하면 프로덕션 환경에 접근하는 것을 거부합니다. 승인되면 PR을 병합하고, 헬스체크 엔드포인트가 다시 200 OK로 돌아올 때까지 폴링(polling)하며, 인테이크 채널에 전체 사후 분석 보고서(post-mortem)를 게시합니다.

3. 단계별 설정: 15분 만에 실행까지

OpsSwitch를 직접 배포하는 방법은 다음과 같습니다:

1단계: Switch 콘솔 및 종속성 설치

Switch 저장소를 클론하고 지원 서비스를 시작합니다:

# 1. 저장소 클론
git clone https://github.com/sandbox-quantum/switch.git
cd switch
...

플랫폼에 맞는 Switch 콘솔(Switch Console) 데스크톱 애플리케이션을 다운로드하여 실행합니다(GitHub Releases). 로컬 서버(http://localhost:8000)를 가리키도록 설정합니다.

2단계: Switch 템플릿 정의

Switch 콘솔에서 템플릿(Templates) → **사용자 지정 템플릿 가져오기(Import Custom Template)**를 클릭하고 OpsSwitch 사양을 로드합니다:

version: 1

params:
...

'Launch Group'을 클릭합니다. Switch가 자동으로 연결된 Slack 채널을 생성하고 격리된 로컬 작업 디렉터리에 에이전트를 배포합니다!

4. 음성으로 구축하기: Wispr Flow 경험

이번 구축에서 가장 혁신적인 요소 중 하나는 Code with Wispr 트랙에 참여한 것이었습니다. 수천 줄의 프롬프트 지침, 아키텍처 스키마 및 문서를 직접 타이핑하는 대신, 우리는 모든 것을 구술하기 위해 Wispr Flow Pro를 사용했습니다.

[Spoken Voice Stream]
│
▼
...

구술이 에이전트 개발을 가속화하는 이유:

1. 자연스러운 대화적 뉘앙스: AI 에이전트를 위한 시스템 프롬프트를 작성할 때, 당신은 인간의 행동을 설명하는 것입니다("경고가 결제 실패처럼 보이면, 즉시 한 줄로 다시 설명하고 워룸에 알림"). 자연스럽게 말하는 것이 간결하게 타이핑된 글머리 기호보다 훨씬 풍부하고 미묘한 에이전트 지침을 생성합니다.
2. 마찰 없는 컨텍스트 포착: 라이브 디버깅 중, 우리는 재현 스크립트 요구 사항을 터미널에 직접 구술하여 손목의 부담 없이 플로우 상태를 유지할 수 있었습니다.
3. 점수표 검증: 구축이 끝날 무렵, Wispr Flow의 인사이트 대시보드는 계획 및 에이전트 지침 전반에 걸쳐 6,500단어 이상 구술되었음을 기록했으며, 개발 주기를 거의 40% 단축했습니다.

5. 실시간 SEV-1 장애 시뮬레이션: 8분 만의 해결

OpsSwitch를 현실적인 조건에서 테스트하기 위해, 결제 시 빈 쿠폰 코드가 전달될 때마다 처리되지 않은 NullPointerException이 발생하는 목업 마이크로서비스(cart-service)에 의도적인 장애를 만들었습니다.

Slack에서 전개된 내용은 다음과 같습니다:

T + 00:30 (접수 채널)

결제 서비스 장애 발생 및 롤백을 통한 복구 과정

Farhan (On-Call Lead):
"@sre-triager checkout service가 09:40 UTC 배포 이후 HTTP 500 오류를 발생시키고 있습니다. 사용자들이 구매를 완료할 수 없습니다."

@sre-triager:
"🚨 인지했습니다. /checkout에서 수익 영향이 감지되었습니다. SEV-1로 분류하고, 인시던트(incident)를 #sre-incident-war-room으로 에스컬레이션합니다."

T + 01:15 (War Room 채널)

@sre-triager:
"인테이크(intake)로부터의 에스컬레이션: 09:40 UTC에 checkout에서 500 오류가 보고되었습니다. @sre-investigator님, 진단 감사를 시작해 주십시오."

@sre-investigator:
"배포 커밋을 검토 중입니다. 09:38 UTC에 병합된 git 커밋 f3c8a91 ('feat: coupon code parser')를 조사하고 있습니다. 로컬 샌드박스(sandbox)에서 최소 재현 스크립트(test_repro.py)를 생성 중입니다..."

# test_repro.py generated by ops-investigator
import requests
response = requests.post("http://localhost:5000/checkout", json={"cart_id": 102, "coupon": None})
...

@sre-investigator:
"재현 확인되었습니다: 종료 코드 1. 142번째 줄에서 java.lang.NullPointerException: coupon이 null이기 때문에 String.trim()을 호출할 수 없습니다 오류가 발생했습니다. @sre-remediator님께 롤백(rollback) 준비를 위해 태그합니다."

T + 03:00 (인간 승인 게이트)

@sre-remediator:
"⚠️ **승인 필요_: 안정적인 v2.13.2로 복원하기 위한 롤백 PR #412를 준비했습니다.
**위험 수준(Risk Level):* 낮음 (데이터베이스 마이그레이션 영향 없음).
@farhan님, 실행을 위해 'Approved. Roll it back.'으로 회신해 주십시오."

Farhan (On-Call Lead):
"승인합니다. 롤백하세요."

T + 04:30 (실행 및 검증)

@sre-remediator:
"승인 확인되었습니다. PR #412를 main에 병합했습니다. 자동 배포(automated deployment)를 트리거했습니다.
헬스체크 엔드포인트(/healthz) 폴링 중...
[200 OK] 검증 완료. 시스템 오류율이 0.00%로 돌아왔습니다. 인시던트 해결되었습니다. @sre-triager님께 업무를 인계합니다."

T + 05:00 (인테이크에서의 임원 사후 분석(Post-Mortem))

@sre-triager:

_"✅ 사건 해결됨(INCIDENT RESOLVED): 결제 서비스가 100% 정상화되었습니다.

근본 원인(Root Cause): 커밋 f3c8a91에서 null 쿠폰 코드 처리 중 발생한 NPE (NullPointerException).

해결책(Remediation): PR #412를 통해 롤백되었습니다.

총 복구 시간(Total Time to Restore, TTR): 8분."_

6. 핵심 학습 내용 및 시사점 (Key Learnings & Takeaways)

OpsSwitch를 구축하면서 다중 에이전트 엔지니어링의 미래에 대한 몇 가지 중요한 교훈을 얻었습니다:

1. 모델 크기보다 토폴로지가 더 중요하다(Topology Matters More Than Model Size): 단일 거대 LLM 프롬프트에 트리아지, 조사 및 git 작업을 처리하도록 강요하는 것은 환각(hallucinations)과 채널 노이즈를 초래했습니다. 세 개의 작고 집중된 에이전트에게 각자의 공간과 명시적인 책임을 부여하는 것이 거의 결정론적(near-deterministic)인 신뢰성을 만들어냈습니다.
2. 인간의 거버넌스는 필수적이다(Human Governance Is Non-Negotiable): 자율 에이전트는 증거 수집 및 솔루션 준비와 같은 중노동을 수행해야 하지만, 프로덕션 쓰기 접근 권한(production write access)은 항상 인증된 인간의 의도에 의해 보호되어야 합니다.
3. 오픈 표준이 승리한다(Open Standards Win): Switch의 깔끔한 Server-Sent Events 아키텍처 덕분에 맞춤형 Python 진단 도구 통합이 수월했습니다. Switch가 독점 플랫폼에 묶이지 않기 때문에, 우리의 인시던트 룸은 자체 쿠버네티스(Kubernetes) 클러스터에서 완전한 데이터 주권(data sovereignty)을 가지고 셀프 호스팅으로 실행될 수 있습니다.

직접 사용해 보세요!(Try It Yourself!)

• GitHub 저장소:
  • OpsSwitch 플래그십 쇼케이스: https://github.com/farhanmallik05/OpsSwitch
  • Switch 코어 기여 포크(Core Contributions Fork): https://github.com/farhanmallik05/switch