네트워크 품질 저하 테스트

학습 목표

이 모듈 한 줄 요약 — "잘 터지는 곳에서만 쓰는 게 아니다". 개발자 책상과 사무실 와이파이는 늘 빠르다. 실제 사용자는 지하철·엘리베이터· 지하 주차장·해외 로밍에서 같은 앱을 쓴다. 느리고 끊기는 상황을 일부러 만들어 놓고 시험하는 법을 다룬다 — 그런 조건에서야 드러나는 결함이 따로 있다.

모듈 16에서 성능 테스트를, 모듈 17에서 모바일 고유의 검증 포인트를 다뤘다. 이 모듈은 그 둘이 만나는 지점을 파고든다 — 네트워크가 나빠졌을 때 제품이 어떻게 행동하는가.

핵심 전환은 문장 하나다. 네트워크 테스트는 "느려지는지"를 보는 것이 아니라 "느려졌을 때 제품이 어떻게 행동하는지" 를 보는 것이다. 대역폭 수치를 재는 일은 준비 작업일 뿐이고, 본론은 그 상태에서 타임아웃 정책·재시도·부분 로딩·중복 처리가 설계대로 동작하는지 확인하는 데 있다.

이 모듈을 마치면 네트워크 상태를 팀이 같은 기준으로 부를 수 있게 정의하고, 실기기에서 그 상태를 재현하고, 재현됐음을 증명하고, 그 위에서 제품의 행동을 검증해 재현 가능한 결함 리포트로 남길 수 있다.

완료 후 할 수 있는 것

• 네트워크 상태를 정상·저하·Limited Service·단절 네 단계로 정의하고, 대역폭·지연·지터·손실 4축으로 수치화할 수 있다
• '연결은 되었으나 사용 불가'를 단절과 구분해 별도 상태로 다루고, 각각에 맞는 검증 항목을 설계할 수 있다
• PC 기반 도구가 스마트폰 트래픽에 닿지 않는 구조적 이유를 설명하고, 그 상황에서 대안을 고를 수 있다
• '설정했다'와 '적용되었다'를 구분하고, 조건 적용을 측정으로 증명하는 절차를 수행할 수 있다
• iOS 네트워크 링크 컨디셔너·Android 개발자 옵션·프록시 스로틀링·리눅스 AP + tc netem·에뮬레이터를 상황에 맞게 선택할 수 있다
• Mbps·KB/s·바이트/초·비율과 퍼센트를 도구별로 정확히 환산해 입력할 수 있다
• Limited Service를 네 가지 원인별(극단 저속·DNS 실패·상위망 차단·완전 손실)로 재현하고, 원인마다 다른 기대 화면을 판정할 수 있다
• 저하 상태에서 타임아웃·재시도·중복 처리·부분 로딩·회선 전환·자원 소모를 체계적으로 점검할 수 있다
• 지수 백오프·지터·멱등키·재시도 예산이 왜 필요한지 설명하고, 클라이언트 재시도 정책을 검증할 수 있다
• 조건 매트릭스를 기대 결과와 판정 기준이 있는 실행 가능한 테스트 케이스로 재설계할 수 있다
• Playwright CDP·adb emu·클라우드 디바이스 팜으로 네트워크 조건을 자동화에 넣을 수 있다

채용시장에서의 위치

네트워크 저하 테스트는 모바일 QA 채용에서 실력을 가르는 대표적인 질문 소재 다. "네트워크가 느릴 때 어떻게 테스트하나요"라는 질문에 "비행기 모드를 켜봅니다"로 답하는 사람과, 상태 정의부터 도구 선택, 적용 확인, 체크포인트까지 설명하는 사람은 같은 경력이어도 다르게 평가된다.

이 능력의 값어치는 결함 재현율 에서 나온다. "가끔 로딩이 안 돼요"라는 CS 문의를 조건명과 측정값이 붙은 재현 절차로 바꿔주면 개발이 바로 고칠 수 있다. 반대로 조건 없이 "느릴 때 문제가 있다"고만 올린 결함은 대부분 재현 불가로 닫힌다.

핀테크·커머스·배달·스트리밍처럼 지하철·엘리베이터·지하주차장에서 쓰이는 앱 을 만드는 회사에서 특히 직접적으로 요구된다. 결제 중복, 주문 유실, 업로드 중단 후 상태 불일치가 전부 이 영역에서 나오는 사고다.

도구를 많이 아는 것보다 팀이 반복해서 쓸 수 있는 조건 하나를 표준으로 정착시킨 경험 이 더 높게 평가된다. 조건별 스크립트를 만들어 회귀에 붙이고, 결함 리포트 양식에 조건명을 넣게 만든 사람이 그렇게 한 사람이다.