AI 자동화 시스템은 배포 후가 진짜입니다

AI 뉴스레터 슬랙봇, 한 달간의 삽질기: 장애 복구부터 비용 99% 절감까지

AI 업무 자동화 시스템을 만들고 "됐다!"고 생각한 순간, 진짜 일이 시작됩니다. 뉴스레터를 AI로 요약해서 Slack에 자동 포스팅하는 봇을 만들었는데, 한 달 뒤 조용히 죽어 있었습니다. 장애를 복구하고, 아키텍처를 갈아엎고, 월 비용을 $65에서 $0.2로 줄인 이야기입니다.

TLDR

• AI 슬랙봇을 배포하고 한 달 뒤, 봇이 조용히 죽어 있었습니다 (로그를 안 보면 모릅니다)
• 원인은 Cloud Run(serverless)과 WebSocket(상시 연결)의 아키텍처 미스매치였습니다
• 장애 복구 과정에서 AI 모델(Gemini)도 망가져 있었다는 걸 발견했습니다
• Socket Mode(WebSocket) → Events API(HTTP)로 전환하여 장애 시나리오 자체를 제거했습니다
• 월 운영 비용을 $65 → $0.2로 99.7% 절감했습니다

1. "잘 돌아가고 있겠지" — 장애 발견

1탄에서 AI 뉴스레터 요약 슬랙봇을 소개했습니다. Lenny's Newsletter가 오면 Gemini가 요약해서 Slack 채널에 자동 포스팅하고, 쓰레드에서 AI에게 질문할 수 있는 시스템이었습니다.

배포 후 한 달간 잘 돌아갔습니다. 문제는 "잘 돌아가고 있겠지"라고 생각하고 로그를 안 봤다는 것입니다.

2월 6일, 쓰레드에서 봇에게 질문을 멘션했는데 무응답. Cloud Run 로그를 열어보니 이런 에러가 무한 반복되고 있었습니다:

BrokenPipeError: [Errno 32] Broken pipe
BrokenPipeError: [Errno 32] Broken pipe
BrokenPipeError: [Errno 32] Broken pipe
...

원인은 Cloud Run의 기본 설정과 Slack 봇의 통신 방식이 충돌한 것이었습니다.

당시 슬랙봇은 Socket Mode(WebSocket)로 동작하고 있었습니다. WebSocket은 서버와 Slack 사이에 연결을 계속 유지해야 합니다. 그런데 Cloud Run은 기본적으로 요청이 없으면 CPU를 꺼버립니다(CPU throttling). CPU가 꺼지면 WebSocket 연결이 끊기고, 끊기면 재연결을 시도하고, 재연결도 CPU가 꺼져서 실패하고... 무한 루프입니다.

한마디로, 서버리스(Cloud Run)에 상시 연결(WebSocket)을 올린 것 자체가 설계 미스였습니다.

2. "임시 방편 vs 근본 수정" — 의사결정

긴급 복구는 간단했습니다. Cloud Run 설정을 바꿔서 CPU를 항상 켜두면 됩니다.

gcloud run services update gmail-intelligence-slackbot \
--no-cpu-throttling \
--min-instances=1

이렇게 하니 10분 만에 봇이 다시 살아났습니다. 하지만 문제가 있었습니다.

월 비용이 ~$65로 뛰었습니다. CPU를 24시간 켜두고, 인스턴스를 항상 1개 유지하는 비용입니다. 하루에 슬랙봇을 쓰는 횟수가 10번도 안 되는데 월 $65는 납득이 안 됐습니다.

여기서 선택지가 두 개였습니다:

B를 선택했습니다. 비용도 비용이지만, A는 근본적으로 "언제든 또 끊길 수 있는" 구조이기 때문입니다.

💡 AI 업무 자동화 시스템을 직접 구축하고 운영하는 게 복잡하게 느껴지시나요? 30분 무료 상담에서 우리 조직에 맞는 자동화 전략을 함께 설계해 드립니다.

3. "모델도 망가져 있었다" — 연쇄 장애

아키텍처를 전환하면서 기존 코드를 점검하다가 두 번째 장애를 발견했습니다.

슬랙봇의 RAG(검색 증강 생성) 기능에 사용하던 Gemini 모델이 gemini-3-flash-preview였는데, 이 모델이 text=None을 반환하고 있었습니다. 질문을 해도 빈 응답만 오는 상태. thinking token만 소비하고 실제 텍스트는 안 주는 것이었습니다.

preview 모델은 말 그대로 미리보기입니다. Google이 언제든 변경하거나 폐기할 수 있습니다. production 시스템에 preview 모델을 쓴 것 자체가 실수였습니다.

모델 변경 후보를 테스트했습니다:

gemini-2.5-flash(stable GA 모델)로 변경했습니다. File Search도 정상 작동하고, 안정적인 GA 모델이라 갑자기 폐기될 위험도 없습니다.

교훈: production 시스템에는 반드시 stable/GA 모델을 사용하세요. Preview, beta, experimental 태그가 붙은 모델은 개인 실험용입니다.

4. 아키텍처 전환: Socket Mode → Events API

전환 작업의 핵심은 Slack과의 통신 방식을 WebSocket에서 HTTP로 바꾸는 것이었습니다.

Before: Socket Mode (WebSocket)

Slack ←→ WebSocket 상시 연결 ←→ Cloud Run (CPU 항상 ON 필수)

• 연결이 끊기면 봇이 죽음
• Cloud Run이 인스턴스를 내리면 연결이 끊김
• CPU always-on 강제 → 비용 증가

After: Events API (HTTP Webhook)

Slack → HTTP POST → Cloud Run (요청 시에만 기동) → 응답

• 연결 유지 불필요 (stateless)
• Cloud Run이 인스턴스를 내려도 다음 요청에 새로 시작
• CPU throttling 가능 → 비용 최소화

실제 변경 범위

코드 변경 자체는 크지 않았습니다. 진짜 어려운 건 "이걸 바꿔야 한다"는 판단을 내리는 것이었습니다. Socket Mode가 익숙하고, 동작하고 있었으니까요 (비싸게 동작하고 있었을 뿐).

5. 결과: 비용 99.7% 절감

전환 전후를 비교하면 이렇습니다.

비용 비교

안정성 비교

장애가 날 수 있는 시나리오 자체를 제거한 것이 핵심입니다. "더 잘 복구한다"가 아니라 "복구할 일이 없다"입니다.

6. 교훈: AI 자동화 시스템 운영의 현실

이번 삽질에서 얻은 교훈 5가지입니다.

교훈 1: "배포 = 완료"가 아닙니다

AI 자동화 시스템은 배포 후가 진짜 시작입니다. 모니터링 없이 한 달을 보냈더니 봇이 죽어 있었습니다. 최소한 정기적인 로그 확인 또는 헬스체크 알림을 설정해야 합니다.

교훈 2: 아키텍처 미스매치를 초기에 잡으세요

WebSocket + Serverless는 태생적으로 맞지 않습니다. 처음 설계할 때 플랫폼의 특성을 이해하고 맞는 통신 방식을 선택하는 것이 중요합니다. 나중에 바꾸는 건 가능하지만, 그 사이 발생하는 장애와 비용은 되돌릴 수 없습니다.

교훈 3: Preview/Beta 모델은 production에 쓰지 마세요

gemini-3-flash-preview가 갑자기 빈 응답을 주기 시작했습니다. Preview는 실험용이고, production에는 stable/GA 모델을 써야 합니다. 새 모델이 나오면 테스트 환경에서 먼저 검증한 후 전환하세요.

교훈 4: 비용은 아키텍처에서 결정됩니다

코드 한 줄 최적화로 비용을 줄인 게 아닙니다. Socket Mode → Events API라는 아키텍처 결정 하나로 월 $65가 $0.2가 됐습니다. 비용이 문제라면 코드보다 아키텍처를 먼저 보세요.

교훈 5: AI 코딩 에이전트가 이 모든 걸 함께 했습니다

장애 진단, 로그 분석, 아키텍처 전환, 코드 수정, Cloud Build, Cloud Run 재배포까지 — 이 전체 과정을 AI 코딩 에이전트(Claude Code)와 함께 했습니다. 비개발자인 제가 Cloud Run 아키텍처를 직접 바꿀 수 있었던 건 AI 덕분입니다.

자주 묻는 질문 (FAQ)

Q. Cloud Run에서 슬랙봇을 운영하면 cold start 때문에 응답이 느리지 않나요?

Events API 모드에서 cold start는 약 2-3초입니다. Slack은 이벤트 응답에 3초 timeout을 두는데, slack-bolt 라이브러리가 즉시 200 응답을 보내고 백그라운드에서 처리하므로 실제로 문제가 되지 않습니다.

Q. Socket Mode와 Events API 중 어떤 걸 선택해야 하나요?

개발 중이거나 로컬 환경에서는 Socket Mode가 편합니다 (URL 노출 없이 테스트 가능). 하지만 Cloud Run, AWS Lambda 같은 서버리스 환경에서 운영한다면 Events API가 맞습니다. 서버리스의 특성(요청 기반 과금, 자동 스케일링)을 살릴 수 있습니다.

Q. Gemini gemini-2.5-flash의 File Search(RAG) 품질은 어떤가요?

실제 뉴스레터 아카이브 기반으로 테스트한 결과, 관련 문서를 잘 찾아오고 grounding 정보도 함께 제공합니다. gemini-3-flash-preview보다 안정적이며, gemini-2.0-flash는 File Search 자체를 지원하지 않으므로 현재로선 gemini-2.5-flash가 최선의 선택입니다.

Q. 비개발자도 이런 시스템을 직접 운영할 수 있나요?

가능합니다, 단 AI 코딩 에이전트의 도움이 필요합니다. 이 글에서 설명한 장애 진단, 아키텍처 전환, 재배포 과정 전체를 Claude Code와 함께 진행했습니다. 중요한 건 "무엇을 해야 하는지" 판단하는 능력이지, 코드를 직접 작성하는 능력이 아닙니다.

다음 단계

직접 시작하기

• 1탄에서 AI 뉴스레터 슬랙봇의 개념과 구조를 확인하세요
• Cloud Run + Slack 봇 운영 시 Events API 모드를 먼저 고려하세요
• AI 모델은 반드시 stable/GA 버전을 사용하세요
• 질문이 있다면 문의하기

전문가와 함께하기

AI 업무 자동화 시스템을 구축하거나, 기존 시스템의 비용/안정성을 개선하고 싶다면:

📅 30분 무료 상담 예약

• 현재 자동화 시스템 진단
• 아키텍처 최적화 방안 제안
• 비용 절감 + 안정성 개선 전략

Retention Inc. - 데이터 기반 스타트업 그로스 컨설팅