n8n과 함께한 모바일팀 온콜 자동화 여정기 Part 1: 분석은 AI에게

모바일팀 온콜은 매일 Crashlytics, Datadog, 앱 리뷰, VoC를 확인하고 원인을 분석해 대응하는 구조였고, 이 반복 작업만으로도 하루 30분 이상이 고정적으로 소모됐다. Slack, Firebase, Jira, Source Code, GitHub를 오가며 컨텍스트를 전환해야 했고, 사람의 판단이 필요한 일과 AI가 맡아도 되는 작업이 섞여 있다는 점이 핵심 문제였다.

먼저 로컬에서 실험 가능한 Claude Skills로 크래시와 앱 리뷰 분석 흐름을 만들었다. 진입점은 Slack으로 통일했고, /crash-analytics, /app-review-comment 같은 명령으로 메시지를 읽어 분석한 뒤 스레드에 결과를 남기도록 설계했다. 크래시는 Firebase 알림을 받아 Firebase Plugin과 소스코드를 바탕으로 기기 정보, 발생 건수, 영향 범위, 스택트레이스를 해석하고 원인과 수정 제안까지 정리했다.

앱 리뷰는 리뷰 내용을 요약하고 유사도 기반으로 카테고리를 분류했다. 카테고리는 운영 정책 확인 필요, 모바일팀 확인 필요, FE팀 확인 필요, BE팀 확인 필요, 사용성 개선, 성능 이슈로 나눠 n8n Data Table에서 관리했고, 장문 리뷰나 다수 리뷰도 AI 요약으로 빠르게 검토할 수 있게 만들었다.

이후 사람이 트리거해야 하는 한계를 넘기 위해 n8n으로 자동화를 옮겼다. 셀프호스팅이면 무료로 쓸 수 있고, 워크플로우 가시성이 높으며, Slack·Jira·GitHub·AI 같은 기존 도구와의 통합이 쉬웠다. 다만 도입 과정에서는 사내 방화벽, Firebase Crashlytics 접근 권한, Slack 봇의 Event Subscription URL 제한 같은 문제가 있었고, 스케줄링 우회, Firebase MCP 오픈소스 분석을 통한 HTTP 호출 구성, Router 워크플로우 분리로 해결했다.

운영 방식도 무조건 자동 분석이 아니라 중요한 것만 걸러내도록 설계했다.

• 크래시는 발생 건수, 앱 버전, 디바이스 정보 등 기준에 따라 선별
• 불필요한 메시지에는 팀 지정 이모지를 남겨 토큰 낭비를 줄임
• 분석이 필요한 경우에만 API로 소스코드를 가져와 요약
• 결과는 크래시 원인, 영향도, 수정 제안, 추가 조치, 사용자 환경 요약으로 정리

앞으로는 GitHub 호출을 줄이기 위한 캐싱, 리뷰 카테고리 정확도 보정, 다른 회사 앱 리뷰 탐색, Datadog과 장애 티켓의 연관성 추적까지 확장할 계획이다. 궁극적으로는 크래시, 앱 리뷰, 앱 성능을 입체적으로 연결해 MTTD와 MTTR을 줄이고, 사람은 판단이 필요한 영역에 더 집중하는 방향으로 온콜을 진화시키려 한다.