1%가 겪은 버그 고쳐야할까요?
Summary
소수 1%가 겪은 앱 버그, 핫픽스 할까 말까? 토스가 정의한 의사결정 프레임워크
점진 배포의 양날의 검을 통제하고 효율적으로 품질을 지켜내는 토스 QA 팀의 핫픽스 제어 여정
대규모 트래픽을 감당하는 토스 팀에서는 단 1%의 장애라 할지라도 큰 파급효과를 불러올 수 있으며, 무리한 핫픽스는 오히려 나머지 99% 사용자에게 새로운 리스크를 제공하기도 합니다. 토스 QA Platform 팀은 단순한 심각도 분류를 극복하고 '릴리즈/QA 마스터의 상호 합의제'와 AI 기반의 'crash-path' 자동화 도구를 결합하여 안정적인 배포 체계를 만들었습니다. 이 글은 더 이상 감정에 의존하지 않고 안전하고 스마트하게 앱 핫픽스를 판단하고 기록하는 구체적인 실무 노하우를 전달합니다.
- 01심각도 중심에서 결정 중심으로: Critical/Major 분류 대신 '지금 고칠 것'과 '다음 배포로 넘길 것'의 확실한 체크리스트 기반 구조 도입
- 02상호 합의를 통한 릴리즈 마스터와 QA 마스터의 이중 결재 체계 설계
- 03플랫폼별 데이터 파편화 극복: Bugsnag 및 Firebase Crashlytics URL 판단을 자동화하여 유저 행동 순서와 환경을 단 1장에 요약해 주는 AI 'crash-path' 구현
- 04실패했던 사후 기록 강제화 폐기 및 슬랙 맥락 기반 AI 초안 채우기로 기록 활성화
- 05말뿐인 대책 금지: 토션 플랫폼과 연동해 재발 방지 작업 완료 상태를 시스템이 강제 검증하도록 자동화
RECOMMENDATION
점진적 배포 프로세스 하에서 잦은 핫픽스로 피로도를 겪고 있는 모바일 제품군 담당 엔지니어, 배포 매니저 및 QA 담당자에게 추천합니다. 단순 문서화 실패 사례부터 AI 자동 완성 및 사후 완료 증적 강제화까지 생생한 품질 개선 방법론을 벤치마킹할 수 있습니다.
The Problem
토스 앱 배포 과정에서 1%의 소수 사용자에게만 발생하는 버그가 발견되었을 때, 단순 심각도 기준(Critical, Major, Minor)만으로는 즉각적인 핫픽스 여부를 객관적으로 결정하기 어려웠습니다. 또한 점진 배포 방식을 적용하면서 1%의 신호가 전체 대다수를 위협하는 잠재적 리스크인지 판단하는 데 혼선이 있었고, 모바일 플랫폼별로 핫픽스 기록이 파편화되어 사후 분석이 원활하지 못했습니다.
The Solution
핫픽스의 우선순위 규칙을 없애고 즉시 진행할 기능과 다음 정기 배포로 넘길 기능으로 명확히 구분했으며, 릴리즈 마스터와 큐에이 마스터의 상호 합의제를 도입했습니다. 더불어 Claude API 기반의 AI 봇인 'crash-path'를 구축해 크래시 로그 분석 및 재현 단계를 자동화하고, QA 플랫폼 '토션'에 핫픽스 사후 기록을 AI가 자동 완성하고 재발 방지 액션 이행 상태를 추적하도록 만들었습니다.
The Result
프로세스를 정립하고 지능형 도구를 통해 관리를 시스템화한 결과, 토스 앱의 핫픽스 빈도는 점진적으로 감소하고 있습니다. 핫픽스를 보류했던 결정 사유와 실제 처리 이행 여부까지 투명하게 추적 및 통계화함으로써 정량적 수치 기반의 실무 예방 프로세스를 구축했습니다.
Trade-off
핫픽스 결정 직후 2~4시간의 완충 시간을 두고 다른 이슈를 추가 검토하는 안을 시도했으나 급박한 수정 목적과 충돌하여 이를 폐기해야 했습니다. 또한 핫픽스 발생을 억제하기 위해 사후 기록을 일부러 까다롭게 만드는 허들을 설계했다가 오히려 기록 내용이 부실해지는 부작용을 마주하여, 프로세스를 강제하는 대신 AI로 자동 채우는 방향으로 선회했습니다.
