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

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

안녕하세요. 요기요 모바일팀에서 Android 앱을 개발하는 이원종입니다.

플랫폼 서비스를 운영하는 조직이라면 장애나 이슈를 빠르게 감지하고 즉시 대응하기 위해 온콜(On-Call) 제도를 운용하고 있을 겁니다. 요기요 모바일팀의 온콜 담당자는 매일 크래시와 성능 지표를 확인하고, 앱 리뷰나 고객 피드백 같은 VoC 를 살피며 분석합니다.

그러나 온콜 담당자는 반복적인 온콜 업무로 일평균 30분 이상 고정적인 시간이 소비되어 본래 업무 생산성이 떨어질 수 밖에 없는 구조입니다. 모바일팀에서는 이를 해결하기 위해 반복되는 온콜 담당자의 루틴을 AI 에게 위임해 보기로 했고 이를 어떻게 지능화하고 자동화하여 온콜 담당자의 생산성을 90% 이상 향상시킬 수 있었는지 소개해 드리겠습니다.

• Part 1: 분석은 AI에게
• Part 2: 판단은 사람이

배경

모바일팀은 최고의 사용자 경험을 위해 3가지 지표를 정기적으로 확인하고 있습니다.

1. Firebase Crashlytics 와 Datadog 을 사용한 크래시 분석
2. 리포팅 채널과 App Review 를 통한 VoC 분석
3. Datadog 을 사용한 성능지표 분석

온콜 담당자는 Slack 에 연결된 Firebase 알림을 확인하고 크래시 발생 건수와 중요도에 따라 원인을 분석하여 Jira 티켓을 생성하고 수정하였습니다. 또한 Slack 에 연결된 VoC 창구를 통해 사용자의 의견을 분석하고, 좋은 의견은 최고의 사용자 경험을 위해 배포에 반영하기도 합니다. 모바일팀은 정기적인 미팅을 통해 Datadog 의 성능지표를 분석하고 SLI 가 목표를 달성하지 못한다면 원인을 분석하여 수정합니다.

이와 같은 기존 온콜 업무 프로세스에서 3가지 문제를 발견했습니다.

1. 반복적입니다. 매일 같은 채널을 확인하고 같은 패턴으로 분석하여 판단을 내립니다. 온콜 담당자는 시간을 반복적으로 소모하는 문제가 있습니다.
2. 컨텍스트의 전환이 큽니다. 크래시 하나를 확인하려면 Slack, Firebase, Jira, Source Code, Github 등 여러 도구를 오가며 정보를 조합해야 하므로 생산성이 떨어집니다.
3. 사람의 판단과 AI가 해도 되는 작업이 섞여 있습니다. 코드 기반으로 크래시의 원인을 분석하고, VoC 를 요약하고 정리하는 역할은 AI 가 잘하는 영역입니다. 긴급도를 판단하고 대응방향을 설정하는 것은 사람이 해야 할 영역입니다.

온콜 담당자의 시간을 본래 업무와 중요한 판단에 집중시키기 위해 Part 1 에서는 반복되는 분석 업무를 AI 에게 위임하고 자동화 하기로 했습니다. Part 1 에서는 크래시와 앱 리뷰 자동 분석 기능을 만든 여정을 소개드리겠습니다.

Skills

첫 번째는 Claude Skills 부터 시작했습니다. 온콜 담당자가 직접 컨텍스트를 전환하지 않고 로컬에서 간단한 명령어로 크래시와 앱 리뷰를 분석하게 하고 싶었고, 다음과 같은 장점을 얻을 수 있기 때문입니다.

1. 스킬 파일 자체가 문서가 됩니다. 자연어로 작성된 스킬은 누구나 쉽게 로직의 흐름을 이해할 수 있고, 이후 AI 를 사용하여 파일 기반의 로직을 이관할 때 용이합니다.
2. 빠르게 실험하고 검증할 수 있습니다. 이 작업을 AI 가 잘 할 수 있는지 로컬에서 빠르게 확인 가능합니다. 안되면 프롬프트를 고치면 되므로 실패 비용이 거의 없습니다.

스킬로 크래시, 앱 리뷰를 분석시킬 도구는 Slack 으로 통일했습니다. 이는 기존 문제였던 도구의 컨텍스트 전환 비용을 줄이기 위해 진입점을 통일하기 위함이고, 분석 결과물이 팀의 히스토리가 될 수 있기 때문입니다.

Skill Design

스킬의 설계는 그림과 같이 봇을 통해 슬랙의 메시지를 읽어 정보를 가져오고 분석하여 스레드에 결과를 남깁니다.

/crash-analytics 어제 크래시 내용 분석해 줘
/crash-analytics 오늘 발생한 Android 크래시 분석해 줘
/crash-analytics 최근 3일간 iOS 크래시 분석해 줘/app-review-comment 이번 주 월요일 앱 리뷰 내용 분석해 줘
/app-review-comment 지난 주 월요일부터 지난주 금요일까지 앱 리뷰 내용 분석해 줘
/app-review-comment 어제 앱 리뷰 분석해 줘

사용자가 /crash-analytics 명령어를 입력하면, Slack 에 연결된 Firebase Crashlytics 채널의 메시지를 읽어와 크래시 정보를 수집합니다. 수집된 크래시 로그를 기반으로 AI가 Firebase Plugin 을 사용하여 기기정보, 발생 건수, 영향 범위, 스택트레이스를 분석하고, 발생한 크래시의 앱 버전에 맞는 소스코드 기반으로 원인을 분석하여 해당 Slack 스레드에 답글로 남깁니다.

/crash-analytics

사용자가 /app-review-comment 명령어를 입력하면, Slack 앱 리뷰 채널의 메시지를 읽어와 리뷰 내용을 수집합니다. AI 가 각 리뷰를 분석하고 카테고리별로 분류하여 해당 스레드에 답글로 요약을 남깁니다. 기존 운영정책 확인이 필요하다면 위키에서 관련 정책문서를 탐색하며 모바일팀 문제 발생 시 관련 크래시를 찾기도 합니다.

n8n

그러나 스킬은 여전히 사람이 트리거를 해야 하는 불편함이 있기에 모바일팀은 다음과 같이 이 문제를 n8n 을 사용하여 해결했습니다.

1. n8n 은 Zapier, Make 와 다르게 셀프호스팅을 구축하면 무료로 사용할 수 있습니다. 모바일팀에서는 UI Test 를 위한 머신이 있었기 때문에 Docker 컨테이너로 n8n 을 실행하여 무료로 사용할 수 있었습니다.
2. 워크플로우의 가시성이 뛰어납니다. 데이터의 흐름을 한 눈에 파악 가능하고 디버깅할 때 각 노드별로 입출력을 확인할 수 있어 커뮤니케이션 비용이 낮습니다. 워크플로우 자체로 누구나 로직의 흐름을 이해할 수 있습니다.
3. 풍부한 통합을 지원합니다. Slack, Jira, Github, AI 등 이미 회사에서 사용하고 있는 도구의 노드가 이미 존재합니다. 또한 HTTP 노드로 api 만 있다면 어떤 도구든지 연결 할 수 있습니다.

n8n 구축에는 모바일팀 외에도 IT 팀과 Security 실의 도움이 필요했습니다. 서버 세팅, 권한 요청, 사내망 외부 연동 검토 등 인프라 측면의 허들이 있었지만 ,스킬을 통해 이미 기능을 충분히 검증한 상태였기에 “이 자동화가 가치가 있다” 라는 확신을 가지고 진행할 수 있었습니다.

크래시 분석

모바일팀에서는 모든 크래시를 분석하지 않습니다. 발생 건수와 앱버전, 디바이스 정보 등 크래시의 중요도에 따라 분석하고 수정하는 기준이 있는데요, n8n도 동일한 기준을 적용했습니다. 만약 모든 크래시를 분석한다면 토큰의 비용이 낭비되므로 지정된 필터링 로직을 통해 분석이 필요 없는 메시지에는 팀에서 지정한 이모지를 남기고 있습니다.

만약 분석이 필요한 크래시라면 Firebase 의 api 를 호출하여 앱 버전에 맞는 소스코드 정보를 github api 를 통해 가져와 스레드에 분석 내용을 다음과 같이 요약합니다.

1. 크래시 원인 분석
2. 영향도 평가
3. 소스코드 수정 제안
4. 추가 조치 필요 내용
5. 크래시 사용자 환경 요약

앱 리뷰 분석

앱 리뷰는 스킬처럼 키워드의 유사도를 분석하여 카테고리를 분류합니다. 최근 n개월의 리뷰를 바탕으로 카테고리를 다음과 같이 분류하여 n8n Data Table 에서 관리하도록 설계했습니다.

1. 운영 정책 확인 필요
2. 모바일팀 확인 필요
3. FE팀 확인 필요
4. BE팀 확인 필요
5. 사용성 개선
6. 성능 이슈

앱 리뷰를 카테고리별로 자동으로 분류하니 여러개의 리뷰와 장문의 리뷰도 사람이 아닌 AI 의 요약으로 사용자의 목소리를 빠르게 검토하고 분석할 수 있는 환경이 구축되었습니다.

겪었던 문제와 해결

첫 번째로 초기 설계는 Slack 에 크래시 알림이 올라오면 n8n 이 이벤트를 받아 자동으로 분석하는 구조였습니다. 그러나 사내 방화벽 정책으로 인해 Slack 에서 n8n 서버로의 이벤트 전달이 불가능했습니다. 방화벽 작업을 요청하여 이후 해결되었지만 작업 당시에는 사용할 수 없었던 문제가 있었기에 메시지 트리거가 아닌 스케줄링 작업을 통해 잠시 문제를 해소했던 시기가 있었습니다.

두 번째로 n8n 에서 Firebase Crashlytics 접근이 불가능했습니다. 스킬에서는 Claude Code 의 Firebase MCP 를 통해 Firebase 에 접근이 가능했습니다. 그러나 n8n 에서는 MCP 를 사용할 수 없었고, Firebase Crashlytics 에 접근하려면 별도의 인증과 권한이 필요했습니다. 이 문제는 Firebase MCP 의 오픈소스 코드를 AI와 함께 직접 분석하여 해결했습니다. Crashlytics API의 호출 방식과 필요한 인증값을 파악한 뒤 n8n 의 HTTP 요청 노드에 인증 정보를 세팅하여 크래시 데이터를 직접 가져올 수 있게 되었습니다.

마지막으로 첫 번째 문제가 해소된 뒤 하나의 슬랙 봇은 하나의 Event Subscription URL 만 등록할 수 있었습니다. 기능별로 봇을 분리할 수도 있었지만 이는 별도의 Router 워크플로우를 구축하여 채널과 메시지 발신자 정보를 필터링하여 기존 분석 워크플로우를 호출하도록 구조를 일부 수정했습니다.

개선하기

첫 번째는 크래시를 분석할 때 github api 를 통해 크래시가 발생한 버전을 기반으로 파일을 가져와 분석하고 있습니다. 이를 매번 github 을 호출하지 않고 한 번 분석한 코드는 캐싱해 api 호출을 줄이려고 합니다.

두 번째는 앱 리뷰를 키워드 기반으로 카테고리를 분류하고 있습니다. 정확도를 높이기 위해 일정 주기마다 AI 가 놓친 리뷰를 보정하는 작업을 추가 할 예정입니다.

세 번째는 다른 회사의 앱 리뷰도 함께 분석하여 좋은 아이디어의 리뷰가 올라온다면 요기요 앱에도 실험하고 개선할 수 있도록 서비스의 사용성을 높이고 싶습니다.

마지막으로 Datadog 이나 장애티켓과의 연관성을 분석해서 외부요인을 함께 추적하려 합니다. 앱 리뷰나 크래시를 평면적으로 바라보지 않고 입체적으로 연관성을 추적하여 근본적인 원인을 해결할 수 있을 것입니다.

Part 2 로 확장하기

모바일팀에서는 오늘 소개해 드린 크래시와 앱 리뷰 분석 외에도 생산성 향상을 위해 AI 를 통한 지능화, 자동화 작업들을 시도하고 있습니다.

Datadog 데일리 리포트(예시)

Datadog 비상 알림(예시)

오늘 소개드린 온콜 업무 분석 자동화는 현재 Datadog 리포트와 연계하여 다음과 같은 시스템을 디자인하고 있는데요, 궁극적으로는 크래시, 앱 리뷰, 앱 성능을 분석하여 사용자에게 최고의 사용자 경험을 제공하기 위해 온콜 업무를 위임하여 MTTD 와 MTTR 을 줄이려 합니다.

Part 2 에서는 코드 수정까지의 과정을 왜 AI 에게 모두 위임하여 완전 자동화를 하지 않고 사람의 판단이 필요한지에 대한 경험을 공유해 드리도록 하겠습니다.

끝으로

이번 글에서는 요기요 모바일팀에서 AI 를 활용하여 온콜 업무를 자동화하는 여정을 소개해 드렸습니다. 모든 자동화에 AI 를 활용하지는 않지만, 맥락을 이해하고 판단할 때 AI 는 강력한 도구임을 느낄 수 있었습니다. 요즘 개발자의 역할은 AI 의 등장 이후 빠르게 확장되고 있는데요, 이 글이 업무에서 AI 를 자동화하며 활용하고 싶으신 분들에게 도움이 되었길 바랍니다.

Part 2 에서는 왜 모바일팀에서 품질에 관한 판단을 AI 에게 모두 위임하지 않고 왜 사람에게 분배하였는지와 앞으로 어떻게 엔지니어의 역할을 확장하려 하는지에 대한 생각들을 공유해 드리도록 하겠습니다.

감사합니다.

---

n8n과 함께하는 모바일팀 온콜 자동화 여정기 — Part 1: 분석은 AI에게 was originally published in YOGIYO Tech Blog - 요기요 기술블로그 on Medium, where people are continuing the conversation by highlighting and responding to this story.