팀은 애플리케이션을 한 스프린트 동안 테스트하고 빌드를 릴리스하지만, 일주일 후 지원팀에는 불만이 쏟아집니다: "내 도시에서는 가격이 다릅니다", "푸시 알림이 오지 않았습니다", "카드로 결제할 수 없습니다". 원인은 거의 항상 동일합니다: 모든 테스트가 하나의 기업 IP에서 진행되었고, 실제 사용자들은 다른 지역, 네트워크 및 통신사에서 접속합니다. 이 기사에서는 IP 주소를 변경하지 않고는 물리적으로 확인할 수 없는 7가지 구체적인 QA 시나리오를 살펴보고, 프록시를 사용하여 테스트 인프라를 설정하는 방법을 보여줍니다.
왜 오피스 IP는 QA의 블라인드 존인가
오늘날 대부분의 모바일 애플리케이션은 IP 주소를 기반으로 결정을 내립니다: 사용자의 국가, 인터페이스 언어, 통화, 사용 가능한 결제 방법, 기능 세트 및 심지어 구독 가격을 결정합니다. QA 부서 전체가 하나의 오피스에서 하나의 고정 IP 데이터 센터 또는 기업 네트워크를 통해 테스트할 때, 애플리케이션은 항상 백엔드에서 동일한 응답을 받습니다 — 마치 모든 테스터가 세계의 한 지점에 있는 것처럼요.
그 결과, 지리적 위치, 시간대, 통신사 또는 연결 유형에 따라 달라지는 버그는 테스트 환경에서 재현되지 않습니다. 이들은 오직 프로덕션에서만 나타납니다 — 카자흐스탄의 사용자가 루블로 가격을 보고, 독일 사용자가 그의 네트워크에서 GCM 차단으로 인해 푸시 알림을 받지 못하고, 인도네시아 고객이 그의 지역에 맞는 결제 제공자가 연결되지 않아 카드를 사용할 수 없는 경우입니다. 릴리스 후 이러한 버그를 수정하는 것은 QA 단계에서 잡는 것보다 비용이 몇 배 더 비쌉니다.
해결책은 릴리스 전에 실제 지리적 및 네트워크 다양성을 에뮬레이트하는 것입니다. 이를 위해 QA 엔지니어들은 점점 더 프록시 서버를 사용합니다: 이들은 테스트 장치 또는 에뮬레이터를 실제로 이동하지 않고도 어떤 국가, 도시 또는 통신사로 "이동"할 수 있게 해줍니다.
시나리오 1: 지리적 콘텐츠 및 지역 가격
대부분의 구독 기반 애플리케이션(스트리밍, 피트니스, 교육)은 서로 다른 국가에서 서로 다른 가격을 표시합니다 — 이를 지리적 가격 책정이라고 합니다. QA가 로컬 IP에서만 구독 신청을 확인하면, 터키, 브라질 또는 인도 사용자의 가격이 올바르게 표시되는지, 올바른 통화와 올바른 반올림으로 표시되는지 확인할 수 없습니다.
콘텐츠 카탈로그에도 동일한 문제가 있습니다: 영화, 상품 또는 프로모션 라이브러리는 종종 지역적입니다. 실제 사용자가 보는 동일한 화면을 보기 위해서는 필요한 국가에 물리적으로 "출현"해야 합니다. 이러한 확인을 위해 주거용 프록시를 사용하는 것이 편리합니다 — 이들은 특정 국가의 실제 가정 사용자의 IP를 제공하며, 애플리케이션의 백엔드는 요청을 일반 유기적 트래픽으로 인식합니다.
실용적인 체크: 8-10개의 주요 시장(미국, 독일, 브라질, 인도, 터키, 일본, 나이지리아, UAE)에서 구독 신청 시나리오를 실행하고, 가격 및 통화의 스크린샷을 기록하고, 제품 가격 목록과 비교합니다. 이는 "왜 내 가격이 다르지?"라는 불만의 대부분을 해결합니다.
시나리오 2: 지리적 차단 및 접근 제한
핀테크 애플리케이션, 스트리밍 서비스 및 일부 게임은 법적 또는 라이센스상의 이유로 특정 국가에서의 접근을 차단합니다. QA는 애플리케이션이 작동해야 하는 곳에서 작동하는지 확인할 뿐만 아니라, 작동하지 않아야 하는 곳에서 올바르게(즉, 크래시 없이) 접근을 거부하는지 확인해야 합니다.
일반적인 버그: "이 서비스는 귀하의 지역에서 사용할 수 없습니다"라는 깔끔한 화면 대신 사용자는 흰 화면이나 무한 로더를 보게 됩니다 — 개발자들이 허용된 국가에서만 행복한 경로를 테스트했기 때문입니다. 지리적 차단을 확인하려면 여러 금지된 관할권에서 순차적으로 연결해야 하며, 이는 실제 SIM 카드와 출장으로는 비현실적이며, 프록시를 통해서는 국가당 10-15분이 소요됩니다.
이 시나리오에는 국가뿐만 아니라 도시 수준에서 정확한 지리적 위치를 가진 프록시가 적합합니다 — 라이센스가 국가 내 지역으로 제한된 경우, "독일 전체"가 아닌 특정 주를 확인하는 것이 중요합니다.
시나리오 3: A/B 및 국가별 단계적 롤아웃
기능 플래그와 단계적 롤아웃은 거의 항상 지리적 위치에 따라 설정됩니다: 새로운 기능은 먼저 캐나다에서 활성화되고, 일주일 후에는 호주에서, 그 후에는 전 세계에서 활성화됩니다. QA 팀이 물리적으로 한 국가에 있다면, 플래그가 그들에게 도달하기 전까지는 새로운 버전을 다른 지역보다 먼저 볼 수 없습니다.
글로벌 릴리스 전에 기능을 테스트하려면, 롤아웃의 첫 번째 파동 국가로 지리적 위치를 변경해야 합니다. 이는 프록시와 안티디텍트 브라우저 또는 장치 에뮬레이터와 함께 해결하는 가장 일반적인 작업 중 하나입니다 — 필요한 국가로 IP를 변경하고, 애플리케이션 세션을 재시작하여, 다른 사용자보다 먼저 기능을 보고, 플래그가 100% 청중에게 도달하기 전에 버그를 찾아낼 수 있습니다.
중요한 점: A/B 테스트를 위해서는 테스트 주기 전체에 걸쳐 IP의 안정적인 "주소"가 필요합니다 — 세션은 요청 간에 국가를 변경해서는 안 되며, 그렇지 않으면 백엔드가 실험 조건을 혼동하고 통제 그룹과 테스트 그룹을 번갈아 보여줄 수 있습니다.
시나리오 4: 현지화 및 푸시 알림
푸시 알림의 텍스트, 발송 시간 및 심지어 배달 사실은 종종 장치의 지리적 위치에 따라 다릅니다. 일부 국가에서는 푸시 제공자(Firebase, APNs, 로컬 SMS 게이트)가 지연되거나 대체 경로를 통해 작동합니다 — 모스크바 사무실의 테스트 환경에서 잘 전달되는 것이 인도네시아 사용자에게는 특정 푸시 서버가 로컬 통신사에 의해 차단되어 도달하지 않을 수 있습니다.
또한 인터페이스의 현지화는 종종 시스템 언어뿐만 아니라 IP에 따라 트리거됩니다: 프랑스의 IP를 가진 영어 전화 사용자는 프랑스어 제목과 영어 버튼이 혼합된 인터페이스를 볼 수 있습니다. 이러한 버그는 QA가 하나의 지리적 영역에서만 테스트하는 경우 100% 보이지 않습니다.
권장 프로세스: 제품의 우선 시장에서 5-7개의 로케일을 선택하고, 해당 IP로 프록시를 통해 연결하고, 장치/에뮬레이터의 시스템 언어를 변경하여 애플리케이션이 어떤 텍스트와 날짜/숫자 형식을 표시하는지 기록합니다. IP 국가와 시스템 언어의 불일치는 별도의 필수 케이스로, 종종 잊혀집니다.
시나리오 5: 결제 방법 및 사기 시스템
모바일 애플리케이션에서 사용 가능한 결제 방법은 거의 항상 국가에 따라 다릅니다: 한 지역에서는 카드 및 Apple Pay가 가능하고, 다른 지역에서는 로컬 지갑(Mercado Pago, Boleto, UPI, QIWI)만 가능하며, 또 다른 지역에서는 통신사를 통한 결제가 가능합니다. QA가 필요한 국가에서 연결할 수 없다면, 절반의 결제 시나리오가 프로덕션까지 검증되지 않으며, 여기서 오류의 가격은 잃어버린 수익과 지원 요청입니다.
별도의 문제는 결제 제공자의 사기 방지 시스템입니다. 이들은 IP에 따라 거래의 위험을 평가합니다: 데이터 센터의 IP에서 요청이 오면 거의 확실히 거부되거나 추가 3D-Secure 검사를 받게 되며, 카드가 완전히 유효하더라도 마찬가지입니다. 이는 테스트 결과를 왜곡합니다: QA는 결제 거부를 보고하고 개발자에게 버그를 보고하지만, 문제는 코드가 아니라 테스트 IP가 사기 방지 점검에서 의심스럽게 보이기 때문입니다.
결제 시나리오에는 주거용 프록시 또는 모바일 프록시를 사용하는 것이 좋습니다 — 이들은 일반 사용자의 트래픽처럼 보이며 불필요한 사기 방지 시스템의 작동을 유발하지 않아 결제 흐름의 행동을 보다 정확하게 보여줍니다.
시나리오 6: 통신사 모바일 네트워크에서의 행동
사무실 Wi-Fi에서 200Mbps로 잘 작동하는 애플리케이션이 불안정한 연결, NAT 프록시 및 높은 지연을 가진 3G/4G 모바일 네트워크에서는 전혀 다르게 행동할 수 있습니다. 요청 타임아웃, 재시도, 비디오/오디오 품질 저하, 오프라인 모드 작동 — 모든 것은 모바일 인터넷에 가까운 조건에서 정확하게 확인해야 하며, 안정적인 사무실 네트워크에서만 확인해서는 안 됩니다.
추가적인 복잡성: 일부 통신사는 자체 프록시 및 CGNAT를 적용하여 서버가 사용자의 실제 IP가 아닌 수천 명의 가입자가 동시에 통과하는 통신사의 공용 IP를 보게 됩니다. 이는 속도 제한 및 IP에 따른 지리적 위치에 영향을 미칩니다 — 애플리케이션은 사용자가 실제로 있는 도시와 다른 도시에서 있는 것으로 "생각"할 수 있습니다.
이러한 행동을 재현하기 위해서는 필요한 국가의 실제 SIM 카드를 통해 인터넷에 연결되는 모바일 프록시가 필요합니다 — 이는 일반 데이터 센터 IP에서는 얻을 수 없는 NAT, 지연 및 속도의 정확한 그림을 제공합니다.
시나리오 7: 속도 제한 및 봇 방지
많은 모바일 애플리케이션의 백엔드 API는 하나의 IP에서 요청 수를 제한하고(속도 제한) 캡차나 행동 분석과 유사한 봇 방지 기능을 사용합니다. QA 팀이 하나의 기업 IP에서 자동 테스트를 실행하면, 일정 시간이 지나면 서버가 429 오류로 응답하기 시작하거나 요청을 완전히 차단하게 됩니다 — 이는 애플리케이션의 버그 때문이 아니라 백엔드가 테스트 트래픽을 공격으로 인식했기 때문입니다.
이는 부하 테스트 및 회귀 테스트에 특히 중요합니다. 짧은 시간 안에 수백 개의 동일한 요청(등록, 로그인, 장바구니 추가)을 수행해야 합니다. 프록시 풀을 통해 다양한 IP 간에 요청을 분산시키면 API를 공정하게 부하 테스트할 수 있으며, 사기 방지 보호의 작동으로 인한 결과 왜곡을 피할 수 있습니다.
이러한 대량 자동화 테스트를 위해서는 데이터 센터 프록시를 사용하는 것이 종종 더 유리합니다 — 이는 높은 요청량에 대해 더 빠르고 저렴하며, 이 시나리오에서는 지리적 위치보다 속도와 연결의 안정성이 더 중요합니다.
QA를 위한 도구 및 프록시 설정
에뮬레이터(Android Studio Emulator, Xcode Simulator)에서 수동 QA를 위해 프록시는 에뮬레이터의 시스템 네트워크 설정을 통해 설정됩니다: 프록시 서버의 IP와 포트, 인증이 필요한 경우 로그인 및 비밀번호를 입력합니다. 실제 장치의 경우 유사한 설정이 Wi-Fi 연결의 "고급 설정 → 프록시 → 수동"에서 가능합니다.
애플리케이션과 백엔드 간의 트래픽을 가로채고 분석하기 위해 QA 엔지니어들은 Charles Proxy 또는 Proxyman을 사용합니다 — 두 도구 모두 애플리케이션 트래픽을 외부 프록시를 통해 통과시키고 동시에 모든 HTTP/HTTPS 요청, 지리적 위치 헤더 및 서버 응답을 볼 수 있게 해줍니다. 이는 진단에 유용합니다: 요청 시 백엔드가 어떤 IP와 어떤 국가를 "보고" 있는지 즉시 확인할 수 있습니다.
Appium 또는 Espresso를 통한 자동화 테스트에서는 프록시가 세션의 desired capabilities에 지정되거나 테스트 세트를 실행하기 전에 장치의 시스템 설정을 통해 지정됩니다. 모바일 애플리케이션 테스트를 위한 클라우드 플랫폼(BrowserStack, Sauce Labs)도 사용자 지정 프록시 연결을 지원하여, 각 지점에 물리적 장치 없이도 서로 다른 국가에서 동일한 자동 테스트 시나리오를 실행할 수 있습니다.
팀에 웹 버전의 애플리케이션이 있거나 서로 다른 지리적 위치에서 여러 계정을 동시에 테스트해야 하는 경우, 안티디텍트 브라우저(Dolphin Anty, AdsPower, Multilogin)를 사용하는 것이 편리합니다 — 각 프로필은 개별 프록시에 연결되며, QA 엔지니어는 쿠키 및 캐시의 혼란 없이 동시에 5-10개의 세션을 다른 국가에서 열어둘 수 있습니다.
각 시나리오에 적합한 프록시 유형
| QA 시나리오 | 추천 프록시 유형 | 이유 |
|---|---|---|
| 지리적 가격 및 콘텐츠 | 주거용 | 일반 사용자 트래픽처럼 보이며, 봇 방지 시스템을 유발하지 않음 |
| 지리적 차단 | 주거용 | 도시/지역까지 정확한 지리적 위치 |
| A/B 및 롤아웃 | 주거용 / 데이터 센터 | 테스트 주기 전체에 걸쳐 안정적인 세션 |
| 푸시 알림 및 현지화 | 모바일 | 통신사를 통한 실제 배달 조건 재현 |
| 결제 및 사기 방지 | 주거용 / 모바일 | 사기 방지 시스템의 잘못된 작동 위험이 낮음 |
| 통신사 모바일 네트워크 | 모바일 | 실제 통신사 SIM 카드, NAT 및 지연의 정확한 에뮬레이션 |
| 속도 제한 / 부하 테스트 | 데이터 센터 | 높은 속도 및 대량 요청 시 저렴한 비용 |
릴리스 전 체크리스트
프로덕션에 빌드를 배포하기 전에 지리적 위치 및 네트워크와 관련된 짧은 체크리스트를 확인하세요 — 이는 위에서 설명한 대부분의 버그를 해결합니다:
- 최소 5개의 주요 시장에서 구독 가격 및 통화가 확인되었습니다
- 금지된 국가에서 지리적 차단 화면이 올바르게 표시되는지 확인되었습니다
- 글로벌 릴리스 전에 첫 번째 롤아웃 국가에서 기능 플래그가 테스트되었습니다
- 다양한 국가 조합에서 IP 및 시스템 언어로 푸시 알림이 확인되었습니다
- 각 주요 지역에 대해 사용 가능한 결제 방법이 개별적으로 확인되었습니다
- 사기 방지 시스템의 잘못된 작동 없이 결제 흐름이 테스트되었습니다
- 애플리케이션이 Wi-Fi뿐만 아니라 모바일 네트워크(3G/4G) 조건에서 테스트되었습니다
- 자동 테스트가 하나의 IP에서 병렬 실행 시 속도 제한으로 인해 실패하지 않습니다
결론
모바일 애플리케이션은 동시에 수십 개의 국가, 네트워크 및 결제 생태계에서 운영되며, QA 팀은 물리적으로 하나의 오피스에서 하나의 IP로만 작업합니다. 바로 이러한 테스트 조건과 실제 청중 간의 간극이 프로덕션으로 넘어가는 대부분의 "설명할 수 없는" 버그를 발생시킵니다. 위의 7가지 시나리오 — 지리적 가격, 지리적 차단, A/B 롤아웃, 푸시 알림 및 현지화, 결제, 통신사 모바일 네트워크 및 속도 제한 — 는 이러한 위험의 대부분을 해결합니다.
귀하의 팀이 지역 콘텐츠, 가격 또는 결제와 함께 작동하는 애플리케이션을 테스트하는 경우, 실제 사용자를 에뮬레이트하기 위해 테스트 스택에 주거용 프록시를 연결하고, 모바일 연결 및 푸시 알림 시나리오에는 특정 통신사에 연결된 모바일 프록시를 사용하는 것이 합리적입니다. 이는 QA 단계에서 사용자 불만이 발생하기 전에 중요한 버그를 발견할 수 있게 해줍니다.