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

수동 검수에서 자동화, 그리고 Snowplow 전환까지

안녕하세요. QE팀에서 App/API 자동화를 담당하고 있는 이슬기(Jerry)입니다.

모바일 앱 테스트 자동화와 함께, 기능 관점의 E2E 테스트와 함께 고객 행동 로그의 품질까지 검증하는 구조를 설계·운영하고 있습니다.

이 글에서는

“로그를 앱 릴리스 전에 효과적으로 검증할 방법은 없는가?” 라는 질문에서 출발해, 수동 로그 검수를 자동화로 전환한 과정과 그 결과를 공유합니다.

Intro

왜 App 로그 검수를 자동화했을까?

처음부터 로그 검수를 이렇게 중요하게 보지는 않았습니다. 로그는 운영이나 데이터 분석 영역이라고 생각했습니다.

하지만 웹 서비스는 문제가 생기면 비교적 빠르게 배포해 수정할 수 있지만, 모바일 앱은 배포 주기가 정해져 있고, 한 번 사용자에게 노출되면 다음 배포 전까지 수정이 쉽지 않습니다.

또한, hotfix를 진행하더라도 기존 문제가 발생하는 버전을 설치한 고객이 수정된 버전을 바로 설치해 준다는 보장도 없습니다.

이러한 구조에서 로그 이슈를 최종 테스트 단계에서 놓치면 어떤 문제가 생길까요?

• 잘못된 로그가 운영 환경에 그대로 누적되고
• 그 로그를 기반으로 추천, 랭킹, 실험 결과가 만들어지며
• 결국 잘못된 판단이 고객 경험(CX; Customer Experience)에 영향을 주게 됩니다

이 상황에서 App 자동화를 담당하고 있던 저는 아래와 같은 고민을 하게 되었는데요.

“앱 로그 검수를 자동화된 최종 R/T(Regression Test) 단계에서 자동화하면 릴리즈 리스크를 줄일 수 있지 않을까?”

여기서 말하는 최종 R/T는 배포 전, 핵심 기능과 품질을 최소한으로 검증하는 자동 QE 단계입니다. 이 시점에 로그까지 함께 검증하는 것이 목표였습니다.

이 자동화는 어떤 로그를 검증할까?

현재는 홈 화면인 추천판 메인 화면을 중심으로 검증합니다.

추천판 진입, 배너 클릭, 브랜드숍 진입과 같이 사용자 유입이 많은 시나리오의 이벤트 로그와 주요 파라미터를 빌드 최종 테스트 단계에서 검증하고 있습니다.

본론 1

기존 로그 검수 방식의 한계

기존 앱 로그 검수는 대부분 이런 방식이었습니다.

• 검수자가 직접 앱을 조작한다
• 디버그 뷰나 Charles 같은 프록시 툴을 연다
• 이벤트가 찍혔는지 눈으로 확인한다

이 방식에는 명확한 한계가 있었습니다.

• 이벤트 종류와 조건이 많아질수록 누락 위험 증가
• 대표 이벤트만 확인하게 되어 부분 검증에 그침
• 사람이 직접 확인하므로 시간과 리소스 소모 큼
• 무엇보다 검증 시점이 배포 이후로 밀림

위와 같은 이유로 사람이 직접 수행하는 로그 검수 방식으로는 “릴리즈 전에 로그 이슈를 막는다”는 목표를 달성하기 어렵다고 판단했습니다.

본론 2

해결 전략: 로그 검수를 테스트 자동화에 포함한다.

접근 방식은 단순했습니다.

“사람이 보던걸, 테스트 코드가 보게 하자.”

전체 구조 개요

테스트 실행

• Appium 기반 UI 테스트 (실제 유저가 앱을 조작하는 Action을 자동화한 테스트입니다.)
• 특정 지면의 특정 Action이 수행되기 전후 타임스탬프를 기록합니다.

로그 수집

• GA4: BigQuery 쿼리 응답값 > 타임스탬프 기준 필터링
• Heathrow: Charles 패킷 파싱 > 타임스탬프 기준 필터링 (GA4와, 무신사 내부 이벤트 수집 시스템인 Heathrow는 앱 로그를 수집·적재하는 서로 다른 시스템입니다.)

검수 로직

• event_name, landing_url, path 기준으로 이벤트 식별
• 식별한 이벤트의 payload 데이터 (파라미터값) 검증 (NOT_NULL, NULL, 정확한 값 비교 등)

구조화 방식

• 공통 파라미터 등이 정의된 스펙(Spec)을 참조해 케이스 별로 검수 필요한 조건을 선언

결과 처리

• 성공 실패 여부를 Slack 자동 알림
• 검증 결과 리포트 저장

이 구조를 통해 테스트 실행 = 로그 검증 실행이 되도록 만들었습니다.

효과

수동 로그 검수 → 자동 로그 검수 변화

이 자동화의 핵심 효과는 단순한 편의성이 아닙니다.

검증 품질을 균일하게 유지하고 QA 리소스를 절감해 앱 릴리스의 안정성과 자신감을 높인 것입니다.

다만 현재는 무신사 전체 영역 대상이 아닌, 홈 화면 ‘추천판’ 메인 내 핵심 섹션을 중심으로 적용했습니다.

홈 화면은 사용자 유입과 노출 빈도가 가장 높은 영역으로, 로그 정확도가 서비스 품질과 데이터 신뢰도에 미치는 영향이 크다고 판단했습니다. 또한 실제 사용자 흐름과 가장 밀접한 구간이라 QE 관점에서 자동화 효과를 빠르게 검증하기에 적합합니다.

현재 적용된 구조를 기반으로, 향후에는 다른 화면과 시나리오로 점진적 확장 예정입니다.

🛠️ 구현 예시

공통 파라미터 스펙 관리

@staticmethod
def get_common_required_params_spec():
    # 공통으로 항상 체크해야 하는 기본 파라미터들
    return {
        "ga_session_id": "NOT_NULL",
        "device_os": "iOS" if os.environ["PLATFORM"] == "ios" else "AOS",
        "device_type": "APP",
        "channel_type": "MO",
    }

이렇게 스펙을 정의해두면, 새로운 테스트에서도 조건 선언만으로 동일한 검증을 적용할 수 있습니다.

Heathrow 브랜드숍 진입 판단

if path == "/log/user-event/v2_imp_clk":
    if event_name == "click_content" and "/brand/" in landing_url:
        values.landing_url = landing_url

화면 이동만으로는 판단하기 어려운 사례를 이벤트 + URL 조건으로 명확히 정의했습니다.

⚠️ 겪었던 문제와 해결

iOS 로그 flush 지연 이슈

자동화 과정에서 예상치 못한 이슈를 마주했습니다.

driver.terminate_app()으로 앱을 강제 종료하면 일부 GA 로그가 서버로 전송되지 않고 유실되는 현상이 발생했습니다.

원인을 조사해 보니 다음과 같았습니다.

• GA 로그는 SDK 내부 정책에 따라 전송되며,
• 백그라운드 진입 시 flush 가 트리거 되고,
• 강제 종료는 백그라운드 이벤트를 발생시키지 않아 flush를 유도하지 못한다

이에 따라 테스트 종료 시 앱을 즉시 종료하지 않고 백그라운드 전환 후 종료하는 방식으로 대응했습니다.

이 이슈는 단순한 실패 사례라기보다는, 로그 자동화를 한 단계 더 깊이 이해하는 ‘레벨업 지점’에 가까웠습니다.

자동화 테스트 환경에서 로그 검증을 신뢰할 수 있으려면 테스트 시나리오 자체가 SDK의 전송 정책을 고려해 설계되어야 한다는 사실을 알게 됐습니다.

이번 경험을 통해 로그 자동화는 단순히 검증 코드를 추가하는 문제를 넘어, 앱 실행 흐름과 데이터 전송 구조까지 함께 이해해야 가능한 영역이라는 점을 명확하게 인식했습니다.

자동화라고 해서 모든 걸 단순화할 수는 없다는 걸 다시 한번 느낀 순간입니다.

🔍 실제 검수 사례

GA4

• Android 비회원 상태에서 필수 사용자 속성 누락 → 특정 버전에서 재현, 이후 빌드에서 해결

Heathrow

• iOS 환경에서 device_os 값이 잘못 수집 → 최초 진입 시에만 발생하는 문제로 확인

브랜드숍 로그

• 기획전 탭 진입 시 v2_detail 누락 → 특정 브랜드에서만 발생, 자동화로 조기 감지

이 자동화는 단순히 로그를 확인하는 수준을 넘어, 실제 릴리즈 전에 문제를 끌어당기는 역할을 했습니다.

Android GA4 사용자 속성 누락, iOS Heathrow의 device_os 오수집, 특정 브랜드에서만 발생하던 브랜드숍 로그 누락까지.

모두 QE 단계에서 발견할 수 있었던 이슈였습니다.

🔄 확장

Snowplow 기반 로그 검수로의 전환

이 구조는 이후 Snowplow → Databricks → S3 기반 로그 검수 자동화로 전환했습니다. 로그 수집 방식과 포맷은 달라졌지만, 핵심 원칙은 동일했습니다.

“로그를 자동으로 수집하고, 정의된 기준으로 앱 배포 전 최종 단계에서 검증한다.”

구현 기술은 달라져도 QE 전략은 그대로 이어졌습니다.

Outro

이번 로그 검수 자동화를 통해 QE 단계에서 로그 이슈를 실제로 잡아낼 수 있다는 걸 확인했습니다.

Android 비회원 환경에서의 사용자 속성 누락, iOS 최초 진입 시 잘못 수집되던 device_os 값, 특정 브랜드에서만 발생하던 브랜드숍 로그 누락까지.

이 이슈들은 모두 운영 환경이 아니라, 앱 배포 전 최종 QE 단계에서 발견됐습니다. 로그는 고객을 직접 보이게 만들지는 않지만, 고객을 이해하는 판단의 근거가 됩니다.

그래서 로그 검수는 운영이나 데이터 분석만의 문제가 아니라, 릴리즈 품질을 책임지는 QE가 함께 가져가야 할 영역이라고 생각합니다.

한 줄 요약

로그 자동화는 구현 기술의 문제가 아니라, 릴리즈 리스크를 줄이기 위한 QE 전략입니다.

TEAM MUSINSA CAREER

무신사는 2001년 온라인 커뮤니티로 시작해 2005년 무신사 매거진, 2009년 무신사 스토어를 오픈하며 빠르게 성장하고 있는 국내 대표 온라인 패션 스토어입니다. ‘입점 브랜드와 동반성장’이라는 경영 철학을 바탕으로 브랜드가 안정적으로 사업을 전개할 수 있도록 무신사가 보유한 노하우와 인프라를 지원합니다. 고객에게는 풍성한 패션 콘텐츠와 패션에 특화된 차별화된 서비스로 최상의 온라인 쇼핑 경험을 제공하고 있습니다. 글로벌 №1 패션 기업으로 성장할 무신사와 함께 새로운 도전과 혁신을 만들 인재를 기다립니다.

29CM는 ‘고객의 더 나은 선택을 돕는다’라는 미션으로 출발했습니다. 우리는 우리만의 방식으로 콘텐츠를 제공하며, 브랜드와 고객 모두에게 대체 불가능한 커머스 플랫폼을 만들어가고 있습니다. 이 미션을 이루기 위해 우리는 흥미로우면서도 복잡한 문제들을 해결하고 있습니다. 만약 우리와 함께 이 문제들을 해결해 보고 싶다면, 주저하지 말고 29CM에 합류하세요!

*🚀 팀 무신사 채용 페이지 (무신사/29CM 전체 포지션 확인이 가능해요)*

🚀 팀 무신사 테크 소식을 받아보는 링크드인

🚀 팀 무신사 뉴스룸