SRE 팀의 반복 작업을 10분의 1로 줄인 SRE 봇 개발기

Context

Flava 클라우드 인프라 도입 후 개발자 문의가 급증했고, SRE 팀은 Slack → Confluence → Jira를 오가는 수동 처리에 주간 15시간(팀원당 반나절)을 소비하고 있었다. 배포 요청 한 건당 평균 1시간이 소요되었으며, 복사-붙여넣기 과정에서 Fix Version 누락, Epic 링크 미연결, 체크리스트 항목 누락 등의 실수가 반복되었다.

Technical Solution

• Slack 워크플로 기반 입력: 슬래시 명령어 대신 Slack 워크플로를 선택해 필수 항목을 UI 단에서 검증하고 사용자 진입 장벽 제거
• 비동기 처리 아키텍처: Slack 3초 타임아웃 제약을 우회하기 위해 이벤트 즉시 응답 후 백그라운드에서 Jira/Confluence/Redis 작업 병렬 처리
• Redis 기반 상태 관리: Slack 스레드와 Jira 티켓 매핑을 Redis(TTL 30일)에 저장하고 WATCH/MULTI/EXEC로 동시성 제어
• 헥사고날 아키텍처 도입: 포트 & 어댑터 패턴으로 Slack/Jira/Confluence API 변경 시 비즈니스 로직 수정 최소화
• 이모지 기반 상태 관리: 👀 클릭으로 할당, ✅로 완료, 🔄로 재오픈 처리하며 Slack 내 전체 워크플로 완결
• 배포 정보 자동 연결: Confluence 릴리스 체크리스트 자동 반영, 배포 매뉴얼 자동 검색, 이전 배포 티켓 자동 링크

Impact

• 배포 요청 처리 시간: 약 1시간 → 1분 이내(60배 감소)
• 배포 요청 SRE 작업: 약 30분 → 1분 이내
• 일반 요청 처리 시간: 약 20분 → 5분 이내
• 주간 SRE 업무량: 약 15시간 → 약 2.5시간(팀원당 반나절 → 30분)
• 배포 요청 처리 중 실수 가능성: 높음 → 거의 없음(모든 규칙 자동 적용)
• 이전 배포 참고 시간: 5분 이상 → 10초(30배 감소)

Key Takeaway

반복적인 수동 작업의 자동화는 단순히 실행 시간 단축을 넘어, Slack을 Single Point of Truth로 삼고 Zero Manual Work를 설계 원칙으로 할 때 최대 가치를 발휘한다. 동기/비동기 처리 방식, 상태 저장소 선택, 아키텍처 패턴은 사용자 경험과 장기 유지보수성을 동시에 확보하는 핵심 의사 결정이다.