이번 작업은 “멋진 자동화"를 만들자는 의도보다는,
장애 대응할 때 매번 끊기던 흐름을 줄여보자는 데서 시작했습니다.
Crashlytics 웹훅이 Slack으로 메시지를 보내주면 알림은 빨리 보는데,
그다음부터는 사람 손을 많이 타고 맥락이 자주 흩어졌습니다.
그래서 슬랙 링크 1개만 주면 분석, 공유, 다음 액션 결정까지 이어주는$crashlytics-slack-triage 스킬을 만들었습니다. 🔧
😵 문제 상황: 왜 자꾸 대응이 늦어졌나#
평소 흐름은 대략 이랬습니다.
- Slack 알림 확인
- Crashlytics에서 이슈/스택 확인
- 코드에서 원인 후보 검증
- 다시 Slack으로 돌아와 결과 정리
단계 자체는 평범하지만, 실제로는 아래에서 자주 막혔습니다.
- 스레드 맥락이 중간에 끊겨서 “왜 이렇게 판단했는지” 남지 않음
- 처음부터 깊게 파다가 초기 대응 속도가 떨어짐
- 분석은 했는데 댓글이 늦어져 팀이 현재 상태를 모름
- 분석과 코드 반영 결정이 분리되어 후속 조치가 밀림
정리하면, 문제는 “분석을 못해서"가 아니라
분석 이후 동작이 한 흐름으로 이어지지 않는 것이었습니다.
🧭 접근 방식: 복잡하게 안 가고, 끊김부터 줄이기#
1) 입력은 Slack 링크로 고정#
사용자 입력을 복잡하게 받지 않고 permalink 하나로 제한했습니다.
- Slack 링크에 접근해 메시지 내용과 Firebase MCP를 활용하여 원인을 분석하고 해결 방안까지 제안하는 댓글을 작성(by. Slack Bot)
- 선택적으로 로컬 저장소의 코드를 권장 방안에 따라 수정 처리
즉, “Slack 링크만 던져주면 알아서 맥락을 모은다"는 방향입니다.
2) 분석은 단계적으로#
항상 Firebase까지 깊게 들어가면 느려집니다.
그래서 기본은 Slack 맥락 중심, 필요할 때만 Firebase MCP를 붙였습니다.
- 1차: Slack 메시지/스레드 기반 빠른 판단
- 2차: 확신이 낮거나 요청이 있을 때 Crashlytics 심화 조회
이렇게 하니 초반 대응 속도가 꽤 안정됐습니다. ⚖️
3) 댓글 포맷을 고정#
분석 결과는 사람이 읽고 바로 판단할 수 있어야 해서,
Slack 댓글 구조를 고정했습니다.
- 한 줄 요약
- 영향 범위
- 원인(추정/확정 구분)
- 근거
- 권장 대응
결론만 던지기보다 “근거를 남기는 습관"에 가까운 방식입니다.
4) 마지막 질문을 반드시 남김#
분석이 끝나면 항상 아래 질문으로 닫습니다.
본 프로젝트 기준으로 권장 수정사항까지 바로 반영할까요?
이 질문 하나가 실제로 중요했습니다.
보고서로 끝나는지, 코드 수정으로 이어지는지가 여기서 갈립니다. ✅
🧪 실제 적용 사례#
이번에는 실제 Android 앱 크래시 알림 1건에 이 방식을 적용했습니다.
아래는 Slack 스레드에 원인 분석과 조치 결과를 남긴 실제 공유 예시입니다.
흐름은 짧게 요약하면 아래와 같습니다.
- 스킬 생성 및 워크플로우 고정
- Slack 링크 기반 맥락 수집
- 필요 구간만 Crashlytics 확인
- 스레드에 RCA 댓글 작성
- 코드 반영 여부 확인 후 수정 진행
- 빌드 확인 + 이슈/커밋 연결
🧷 확인된 원인#
앱의 설정 파일(매니페스트)에
현재 코드 기준으로는 더 이상 필요하지 않은 화면 선언이 남아 있었습니다.
- 조치: 불필요한 잔존 선언 제거
- 검증: 매니페스트 병합/빌드 단계 정상 통과
핵심은 “크래시를 크게 포장한 근본 원인"이 아니라,
작지만 명확한 잔존 설정 이슈를 빨리 정리한 케이스였습니다.
📈 시퀀스 다이어그램#
아래 이미지는 Mermaid를 SVG로 내보낸 버전입니다.
이미지를 클릭하면 원본 크기로 크게 볼 수 있습니다.
📌 적용 후 체감한 변화#
- “누가 지금 어디까지 봤는지"가 스레드만 보면 파악됨
- 대응 중간에 맥락 설명을 다시 하지 않아도 됨
- 분석 이후 수정까지 이어지는 비율이 올라감
- 회고할 때 이슈, 댓글, 커밋이 연결되어 추적이 쉬움
작게 보면 댓글 자동화지만,
운영 관점에서는 “대응의 끊김"을 줄이는 효과가 가장 컸습니다. 🙌
✍️ 마무리#
이번 작업은 대단한 알고리즘을 넣은 프로젝트는 아닙니다.
대신 실무에서 자주 끊기는 지점을 정확히 줄이는 데 집중했습니다.
앞으로도 방향은 비슷합니다.
- 입력은 가볍게
- 판단은 근거 중심으로
- 마지막은 실행 여부까지 닫기
이 세 가지만 지켜도, 장애 대응 품질은 꽤 안정적으로 올라간다고 느꼈습니다.