SRE 봇 도입으로 반복 작업 OUT! 생산성 UP!
LINE Home DevOps 팀은 반복적인 수동 작업으로 인한 시간 낭비를 해결하기 위해 SRE 봇 프로젝트를 시작함
Slack 워크플로 기반의 자동화 시스템을 구축하여 배포 요청 처리 시간 1/30로 단축 및 일반 문의 대응 효율을 높임
Redis와 헥사고날 아키텍처(Hexagonal Architecture)를 활용하여 데이터 일관성(Data Consistency) 확보 및 시스템 확장성을 확보함
Central Dogma 설정 핫 리로드 문제, 동시 요청 처리 시 Redis 데이터 불일치 등 예상치 못한 기술적 난관에 직면했으나, 해결책을 찾아냄
향후 지능형 자동화를 목표로, 노드 기반 업무 자동화 플랫폼 통합, 쿠버네티스 MCP 서버 통합 등을 계획 중
Slack 워크플로 기반 자동화 아키텍처
본문에서는 SRE 봇의 핵심 아키텍처로 Slack 워크플로(Slack Workflow)를 선택한 이유를 설명한다. 슬래시(/) 명령어 방식보다 사용 편의성을 높여 사용자 참여율(User Engagement)을 극대화했다.
Single Point of Truth: 모든 요청을 Slack에서 시작하고 관리
Zero Manual Work: 복사-붙여넣기 등 수작업 100% 자동화
Instant Visibility: 요청 상태를 Slack에서 실시간 확인
Permission Control: SRE 팀원만 작업 수행 가능
이러한 설계 철학을 바탕으로, 1단계 기본 자동화, 2단계 인텔리전스 추가, 3단계 상호작용 단계를 거쳐 기능을 고도화했다.
기술적 의사 결정: 동기 vs 비동기, 상태 저장 전략
SRE 봇 개발 과정에서 Slack API 응답 시간 제약을 해결하기 위해 비동기 처리 방식을 채택했다. 외부 API 호출은 백그라운드에서 처리하고, Slack에는 즉시 응답하여 사용자 경험(User Experience)을 개선했다.
비동기 처리: Slack 타임아웃 에러 방지 및 처리 과정 투명성 확보
상태 저장: Redis(Redis)를 활용하여 빠른 조회와 영구적인 데이터 저장, TTL(Time to Live) 설정
동시성 제어: Redis Transaction(WATCH/MULTI/EXEC)을 통해 데이터 일관성(Data Consistency) 보장
이러한 기술적 선택은 시스템의 안정성과 확장성을 확보하는 데 기여했다.
헥사고날 아키텍처(Hexagonal Architecture) 적용
SRE 봇은 Slack, Jira, Confluence, Redis 등 여러 외부 시스템과 통합되므로, 헥사고날 아키텍처(Hexagonal Architecture)를 적용하여 시스템의 유연성을 확보했다. 인터페이스(Interface)를 통한 외부 환경과의 격리를 설계 원칙으로 삼아, 외부 서비스 변경에 유연하게 대응할 수 있도록 했다.
인바운드 어댑터(Slack 이벤트) → 비즈니스 로직(유스케이스) → 아웃바운드 어댑터(Jira, Confluence, Redis) 구조
외부 시스템과의 결합도(Coupling) 감소: API 변경에 따른 내부 로직 수정 최소화
테스트 용이성(Testability) 향상: 각 컴포넌트의 독립적인 테스트 가능
이러한 아키텍처는 SRE 봇의 지속적인 기능 추가 및 유지보수(Maintenance)를 용이하게 한다.
SRE 봇 도입 전후 시나리오 비교 분석
SRE 봇 도입 전후의 시나리오 비교를 통해 자동화의 효과를 정량적으로 보여준다. 배포 요청 처리 시간은 30분에서 1분 이내로, 일반 요청 처리 시간은 10분 이상에서 5분 이내로 단축되었다. 또한, 긴급 요청 처리 시 업무 혼선 가능성을 제거하고, 이전 배포 정보를 10초 만에 확인할 수 있게 되었다.
배포 요청: 30분 → 1분 이내 (시간 단축)
긴급 요청: 업무 혼선 감소, 신속한 대응
일반 SRE 요청: 10분 이상 → 5분 이내 (시간 단축)
이전 배포 참고: 5분 이상 → 10초 (시간 단축)
이러한 변화는 SRE 팀의 생산성 향상(Productivity Improvement)과 업무 만족도(Job Satisfaction) 증진에 기여했다.
예상치 못한 도전과 해결: Central Dogma, Redis 데이터 불일치
SRE 봇 개발 과정에서 발생한 기술적 문제와 해결 과정을 상세히 설명한다. Central Dogma 설정 핫 리로드 문제와 Redis 데이터 불일치 문제를 겪었으며, 각각의 문제에 대한 해결책을 제시한다.
Central Dogma 설정 핫 리로드: 의존성 주입 컨테이너(Dependency Injection Container)의 설정 갱신 문제 해결
Redis 데이터 불일치: Redis Transaction(WATCH, MULTI, EXEC)을 사용한 낙관적 락(Optimistic Locking) 적용
이러한 문제 해결 경험은 SRE 팀의 기술적 역량 강화(Technical Skill Enhancement)에 기여했으며, 시스템의 안정성을 높이는 데 중요한 역할을 했다.
