보이지 않는 품질, 데이터: 로그가 틀리면 고객도 틀린다

모바일 앱은 배포 주기가 정해져 있어, 로그 이슈를 출시 후에 발견하면 수정이 늦고 영향도 오래 남는다. 잘못된 이벤트는 운영 로그에 누적되고, 추천·랭킹·실험 결과까지 흔들어 결국 고객 경험에 직접 영향을 준다.

이를 막기 위해 최종 R/T(Regression Test) 단계에 로그 검수를 넣었다. Appium 기반 UI 테스트가 실제 사용자 행동을 자동화하고, 특정 액션 전후의 타임스탬프를 기록한 뒤, 그 구간에서 발생한 로그만 골라 검증한다.

로그 수집은 GA4와 내부 이벤트 수집 시스템인 Heathrow를 각각 활용했다. GA4는 BigQuery 쿼리 결과를 시간 기준으로 필터링하고, Heathrow는 Charles 패킷 파싱 결과를 시간 기준으로 필터링해 이벤트를 찾는다.

검수는 event_name, landing_url, path로 이벤트를 식별한 뒤 payload의 파라미터를 확인하는 방식이다. 공통 파라미터는 스펙(Spec)으로 관리해 케이스별 조건만 선언하면 동일한 검증을 재사용할 수 있게 만들었다.

예를 들어 공통 필수 값으로 ga_session_id, device_os, device_type, channel_type을 검사하고, Heathrow의 브랜드숍 진입은 click_content와 /brand/ 포함 여부를 함께 봐서 판별한다. 검증 결과는 성공·실패를 Slack으로 자동 알림하고 리포트로 저장한다.

가장 큰 효과는 검증 품질의 균일화와 QA 리소스 절감이다. 수동 검수로는 누락되기 쉬운 이벤트와 조건을 자동으로 확인하면서, Android 비회원 사용자 속성 누락, iOS의 device_os 오수집, 특정 브랜드의 브랜드숍 로그 누락 같은 이슈를 배포 전에 잡아냈다.

자동화 과정에서 iOS에서는 driver.terminate_app()로 앱을 강제 종료하면 GA 로그가 flush되지 않아 유실되는 문제도 발견했다. 이를 해결하기 위해 테스트 종료 시 즉시 종료하지 않고 백그라운드 전환 후 종료하도록 시나리오를 바꿨다.

이후 구조는 Snowplow → Databricks → S3 기반으로 전환됐지만, 핵심 원칙은 그대로였다. 로그를 자동으로 수집하고, 정의된 기준으로, 앱 배포 전 최종 단계에서 검증하는 것 자체가 릴리스 리스크를 줄이는 QE 전략이라는 점을 확인했다.