운영 서버 교체 전, 안드로이드·아이폰 앱에서 새 서버 테스트하기 (Hosts 파일 없이 안전하게!)

목차

뭐, 엄밀히 말하면 신기술은 아닙니다. 다만, 예전에는 이런 방법을 몰라서 핸드폰이 벽돌된 사례가 많아 뒤늦게 공유합니다.
배포 직전 서버 마이그레이션을 앞두고 있는데, 새로운 서버로의 전환이 잘 될지 불안하신가요? 실제 운영 도메인은 동일한데 백엔드 서버 IP만 변경되는 상황이라면, DNS를 아직 변경하지 않은 상태에서 앱은 여전히 옛 서버를 바라보게 됩니다. 이때 모바일 앱에서 새로운 서버를 테스트할 방법이 마땅치 않아 고민하게 됩니다. 일부 개발자는 앱 코드를 수정하거나 기기 hosts 파일을 바꾸는 방식을 떠올리지만, 이는 루팅이나 탈옥 없이는 불가능하거나 위험한 방법입니다. 다행히도 Fiddler 프록시를 활용하면 앱을 수정하지 않고도 DNS 변경 없이 새 서버로 트래픽을 우회시킬 수 있습니다. 이번 글에서는 안드로이드와 iOS 앱을 위한 프록시 테스트 기법을 소개하며, 초보 개발자도 따라할 수 있도록 단계별 가이드를 제공합니다.
 

Fiddler(Proxy기능)을 통한 도메인 우회

 

문제 상황: DNS 변경 전 새 서버 테스트의 어려움

서버 교체(마이그레이션)를 진행할 때 도메인은 그대로 유지되지만 IP가 변경되는 경우, 일반적인 환경에서는 앱이 새 서버에 접속할 수 없습니다. 운영 환경의 앱은 보통 운영 DNS를 조회해 기존 서버로 통신하기 때문입니다. 예를 들어 api.example.com이라는 도메인이 기존 서버(AS-IS)를 가리키고 있고, 동일한 도메인으로 새로운 서버(TO-BE)를 구축했다면, DNS를 바꾸기 전까지 앱은 계속 구서버로만 요청을 보내게 됩니다. 테스트를 위해 코드에 임시로 새 서버 주소를 넣고 빌드하는 방법도 있지만, 실수로 그 상태로 출시하면 큰 참사를 불러올 수 있습니다 (실제로 개발 서버 주소가 하드코딩된 앱을 스토어에 올려버리는 실수가 발생하기도 합니다). 안드로이드 hosts 파일 수정 또한 생각해볼 수 있으나, 시스템 파티션에 위치한 hosts를 바꾸려면 루팅이 필요하고 제조사에서 막아놓은 경우가 많아 현실적으로 어렵습니다. iOS 기기는 탈옥 없이 hosts 수정이 불가능하며, 운영체제 보안상 시스템 설정을 임의로 바꾸는 것은 위험합니다.
그렇다면 어떻게 해야 할까요? 모바일 앱 개발자 사이에서 널리 쓰이는 방법은 프록시(proxy) 툴을 활용하는 것입니다. PC에서 동작하는 프록시 툴을 이용해, 모바일 앱의 모든 트래픽을 로컬 PC로 가로챈 후, 특정 도메인에 대한 요청만 새로운 서버 IP로 우회시키는 것입니다. 이렇게 하면 앱은 배포된 동일한 앱(소스 수정 없음)인데도, 마치 hosts 파일을 편집한 것처럼 새로운 서버를 가리켜볼 수 있습니다. 이하에서 대표적인 프록시 툴인 Fiddler를 사용하여 안드로이드 및 아이폰 앱에서 DNS 변경 없이 새 서버를 테스트하는 방법을 단계별로 살펴보겠습니다.
 

Fiddler 설치 (2가지 Version = 후자 선택 권장) 

설치 방법은 2가지 존재합니다.
첫번째는 SSO를 통한 회원가입 후 다운로드(최신버전)
두번째는 Local PC에서 사용 가능한 비회원 다운로드(Classic버전)
모두 가이드 드리니 편한 선택을 하시되, 개인정보 보호를 위해 후자를 권장합니다.
 
1) 피들러 다운로드▶ 다음 싸이트에서 다운로드 하는 방법 (회원가입 필요)
- url : http://www.telerik.com/fiddler

Version : Fiddler v7.1.0

Fiddler 설치 과정

 
2) Compute에 바로 사용 (Classic Version)
- url : https://www.telerik.com/download/fiddler

Fiddler Classic Version Download - Version : v5.0.20253

 

Fiddler Install Success

설치과정은 간단합니다.

 

Fiddler 프록시로 테스트 환경 구축하기

Fiddler는 Telerik사에서 제공하는 강력한 웹 디버깅 프록시 도구입니다. Windows 사용자는 Fiddler Classic을, Mac/Linux 사용자는 Fiddler Everywhere를 사용할 수 있습니다 (Charles 나 mitmproxy 등의 대안도 있지만 여기서는 Fiddler를 기준으로 설명합니다). 우선 PC에 Fiddler를 설치했다면, 몇 가지 초기 설정이 필요합니다:

• 원격 접속 허용: Fiddler를 실행하고 상단 메뉴에서 Tools > Options > Connections로 이동합니다. "Allow remote computers to connect" 옵션을 체크하여 모바일 기기가 이 PC에 프록시로 접속할 수 있게 합니다. 기본 리스닝 포트는 8888이므로 그대로 두거나 필요에 따라 변경합니다.

Allow remote computers to connect

• HTTPS 트래픽 복호화: 앱이 HTTPS를 사용한다면 Fiddler가 해당 트래픽을 볼 수 있도록 Decrypt HTTPS 옵션을 켜야 합니다. Tools > Options > HTTPS 탭에서 "Decrypt HTTPS traffic"를 체크하면 Fiddler가 자체 생성한 루트 인증서를 통해 HTTPS를 해석할 수 있습니다. (Fiddler Classic의 경우 이 과정에서 Windows에 Fiddler 인증서가 설치됩니다. Fiddler Everywhere도 비슷한 설정을 제공합니다.)

• 인증서 설치 (모바일): 모바일 기기에 Fiddler의 루트 인증서를 설치해야 HTTPS 통신이 원활합니다. 이는 각 플랫폼별로 아래에서 자세히 다룹니다. (HTTP만 사용하는 테스트라면 인증서 설치 없이도 도메인 우회가 가능하지만, 대부분 앱은 HTTPS이므로 권장합니다.)

이제 PC 쪽 준비가 되었으므로, 모바일 기기 설정과 Fiddler의 도메인 요청 우회(Hosts 대체) 설정 방법을 알아보겠습니다.

안드로이드 앱 테스트: Fiddler 프록시 설정

안드로이드 기기를 통해 새 서버를 테스트하려면, 해당 기기의 네트워크 트래픽이 PC의 Fiddler를 거치도록 설정해야 합니다. 단계는 다음과 같습니다:

Wifi 수동 Proxy 설정

1. 동일한 네트워크 연결: 안드로이드 스마트폰과 Fiddler가 실행된 PC를 같은 Wi-Fi 네트워크에 연결합니다. (예: 둘 다 같은 공유기의 Wi-Fi에 접속)
2. 안드로이드에서 프록시 설정: 휴대폰의 Wi-Fi 설정에서 현재 연결 중인 네트워크의 세부 설정을 엽니다. 고급 옵션에서 프록시를 "수동"으로 변경하고, 프록시 서버 주소에는 PC의 로컬 IP 주소(예: 192.168.0.x)를 입력합니다. 프록시 포트에는 앞서 Fiddler에서 확인한 포트 번호 (기본 8888)를 입력하고 저장합니다. 프록시 우회 대상은 특별히 필요한 경우가 아니면 비워둡니다. 이렇게 하면 안드로이드의 모든 웹 트래픽이 PC로 전달됩니다.
3. Fiddler 인증서 설치: 안드로이드에서 HTTPS 통신을 분석하려면 기기에 Fiddler 인증서를 설치해야 합니다. 모바일 Chrome 등 브라우저를 열고 주소창에 http://ipv4.fiddler:8888을 입력합니다. Fiddler가 제공하는 인증서 설치 페이지가 열리면 "FiddlerRoot 인증서 다운로드"를 선택합니다. 다운로드된 인증서를 터치하면 설치 화면이 나타나며, 기기 PIN이나 잠금 패턴을 묻는다면 입력하고 신뢰할 수 있는 인증서로 추가합니다. 인증서 이름은 임의로 지정해도 무방합니다. (안드로이드 7.0 Nougat 이상에서는 사용자 인증서를 시스템 앱에서 신뢰하지 않으므로, 만약 앱이 네트워크 보안 구성(Network Security Configuration)으로 사용자 인증서를 허용하지 않는다면 HTTPS 프록시가 제한될 수 있습니다. 대부분 테스트 목적의 앱은 문제가 없지만 이 점도 참고해야 합니다.)
4. 동작 확인: 이제 Fiddler를 실행한 PC에서 안드로이드 기기로 어떤 앱이나 브라우저에서 웹 요청을 보내보세요. Fiddler의 로그 창에 안드로이드 기기의 HTTP/HTTPS 요청들이 나타나면 프록시 연결 성공입니다. 예를 들어, 안드로이드 웹브라우저로 https://www.naver.com 을 열었다면 Fiddler에 해당 요청 리스트가 뜨고, 상태 200 응답까지 보이면 세팅이 완료된 것입니다.

이 단계까지는 단순히 PC를 거쳐 트래픽을 모니터링하는 구성입니다. 이제 핵심 목표인 특정 도메인 요청을 새 서버로 우회하는 설정만 남았습니다. (다음 섹션에서 Fiddler의 Hosts 기능을 사용한 우회 설정 방법을 소개합니다.)

Tip: 테스트가 끝난 후에는 안드로이드 기기의 Wi-Fi 프록시 설정을 *"None(없음)"*으로 되돌려야 합니다. 프록시 설정이 남아 있으면 PC에 Fiddler가 실행되지 않은 경우 인터넷 접속이 되지 않을 수 있으니 유의하세요.

아이폰(iOS) 앱 테스트: Fiddler 프록시 설정

iOS 기기(아이폰, 아이패드)에서도 안드로이드와 유사한 방법으로 프록시를 설정할 수 있습니다. iOS는 HTTP 프록시 설정과 인증서 설치/신뢰 과정이 필요하며, 순서는 다음과 같습니다:

1. 동일한 네트워크 연결: 아이폰과 Fiddler PC를 동일한 Wi-Fi에 연결합니다. (유선 연결된 PC라면 같은 공유기의 Wi-Fi를 사용하면 됩니다.)
2. 아이폰에서 프록시 설정: iOS에서 설정 > Wi-Fi로 들어가 현재 연결된 네트워크의 상세 정보를 확인합니다. 화면 하단의 HTTP 프록시 항목을 "수동"으로 선택한 뒤, 서버란에는 PC의 IP 주소를 입력하고 포트란에는 Fiddler의 포트 (8888)를 입력합니다. 입력을 마친 후 상단 왼쪽 Wi-Fi 버튼을 눌러 설정을 빠져나오면 프록시 설정이 저장됩니다.
3. Fiddler 인증서 설치 및 신뢰: 아이폰 사파리(Safari)를 열고 주소창에 http://ipv4.fiddler:8888를 입력합니다. Fiddler 인증서 다운로드 페이지가 나타나면 FiddlerRoot 인증서를 다운로드하세요. 다운로드 후 설정 > 일반 > VPN 및 기기 관리(또는 프로파일) 메뉴에서 다운로드된 프로파일로 표시된 Fiddler 인증서를 선택하고 설치합니다. 설치가 완료되면 설정 > 일반 > 정보 > 인증서 신뢰 설정으로 이동하여 FiddlerRoot 루트 인증서에 대해 신뢰(사용)를 활성화합니다. 이 과정을 거쳐야 iOS가 Fiddler 프록시의 HTTPS 트래픽을 신뢰하도록 허용하게 됩니다.
4. 동작 확인: 아이폰에서 사파리 등으로 웹사이트를 열거나, 테스트하려는 앱을 구동해 네트워크 통신을 시도합니다. Fiddler 쪽에서 아이폰의 요청이 잡히는지 확인합니다. 만약 Fiddler에 요청이 뜨지 않으면, 아이폰의 프록시 설정 주소/포트가 올바른지, PC와 같은 네트워크인지, Fiddler의 원격 연결 허용이 체크되어 있는지 다시 점검합니다. 모든 설정이 맞다면 아이폰도 프록시 연결 성공이며, 이제 앱 트래픽을 제어할 준비가 된 것입니다.

Note: iOS 기기는 인증서 설치 후 신뢰 설정을 별도로 해야 하는 것을 잊지 마세요. 신뢰하지 않은 프록시 인증서는 설치만 해두면 아무 효과가 없고, HTTPS 통신이 차단될 수 있습니다. 또한 테스트 완료 후에는 프로파일에서 해당 인증서를 삭제하거나 신뢰 설정을 해제해 두는 것이 보안상 안전합니다.

Fiddler 사용법: 특정 도메인 요청 새 서버로 우회시키기

이제 본격적으로 Fiddler를 통한 도메인 요청 우회 설정을 해보겠습니다. 이는 마치 hosts 파일을 수정하는 것과 동일한 효과를 내지만, 변경 사항이 PC의 Fiddler 내에만 적용되므로 실제 디바이스의 시스템에는 영향을 주지 않습니다. Fiddler에서는 Hosts 기능 또는 AutoResponder 기능으로 요청을 다른 대상으로 보낼 수 있는데, 여기서는 더 간편한 Hosts 리맵(remap) 기능을 활용하겠습니다.
1. Fiddler Hosts 기능 활성화: Fiddler 상단 메뉴에서 Tools > HOSTS...를 클릭하면 Hosts 설정 창이 열립니다. 상단의 "Enable Hosts Remapping" 혹은 유사한 체크박스를 체크하여 기능을 활성화합니다. 이제 이 창에 우리가 지정하고 싶은 도메인→IP 매핑 규칙을 추가할 수 있습니다.
2. 새 서버 IP로 도메인 매핑: Hosts 설정 창의 입력란에 IP주소 도메인 형태로 내용을 추가합니다. 예를 들어, 운영에서 사용 중인 api.example.com 도메인을 새 서버 IP 10.0.0.5로 테스트하고 싶다면 아래와 같이 입력합니다:

10.0.0.5 api.example.com
or
10.0.0.5:8443 api.example.com //만약 새 서버가 기본이 아닌 특정 포트(예: 8443)로 통신한다면 포트까지 함께 지정할 수 있습니다:

 
위와 같이 입력하고 Save 또는 닫기 버튼을 누르면 설정이 적용됩니다. 이후 해당 도메인(api.example.com)으로 나가는 요청은 모두 Fiddler가 지정된 IP(10.0.0.5)로 전달합니다. 쉽게 말해, Fiddler가 DNS를 속여서 특정 도메인을 가리키는 IP 주소를 우리가 정한 대로 바꿔치기해주는 것입니다.
Fiddler의 Hosts 리맵 설정 화면 – hosts 파일과 동일한 형식으로 도메인과 IP를 매핑해주면 된다. 활성화 후 해당 요청들은 Fiddler 창에서 파란색 배경으로 표시되며, 정상적으로 새로운 IP로 우회된 것을 확인할 수 있다.
설정이 제대로 되었다면, Fiddler 로그 창에 “Hosts” 관련 메시지가 나타나고 이후 해당 도메인으로의 요청 항목들이 하늘색 배경으로 강조 표시될 것입니다. 이는 현재 Fiddler의 hosts 리맵이 적용되고 있음을 나타내며, 이러한 요청들은 모두 우리가 지정한 새 서버로 향하고 있음을 의미합니다. 이제 안드로이드나 아이폰에서 api.example.com으로 API 호출을 할 때 실제로는 10.0.0.5 서버와 통신하게 됩니다. 앱 입장에서는 도메인명이 같으므로 아무런 변화도 인지하지 못한 채 새로운 서버로부터 응답을 받아오게 되죠.
3. 동작 검증: 마지막으로, 실제로 앱에서 기능 테스트를 수행하여 새 서버가 잘 동작하는지 확인합니다. 예를 들어 로그인이나 데이터 조회와 같은 기능을 실행했을 때, Fiddler를 통해 해당 요청이 새 서버 IP로 전달되고 응답도 정상적으로 돌아온다면 성공입니다. 이때 Fiddler의 Inspectors 탭을 보면 요청/응답 내용을 확인할 수 있고, 예상한 데이터가 오가는지 검증할 수 있습니다. 문제가 발견되면 즉시 Fiddler 로그와 응답 내용을 분석해 원인을 파악할 수 있습니다.
4. 테스트 종료 및 정리: 새 서버로의 테스트가 끝났다면 Fiddler의 Hosts 설정에서 해당 매핑을 비활성화하거나 삭제하고, 앞서 설정했던 모바일 기기의 프록시 설정도 원복해야 합니다. Fiddler 상에서 Hosts 리맵 기능을 끄면 즉시 원래대로 (기존 DNS) 요청이 이루어지며, 모바일 기기도 프록시를 해제하면 다시 운영 DNS를 통해 운영 서버와 통신하게 됩니다.
 

Hosts 파일 직접 수정 vs 프록시 우회 (왜 이 방법을 쓰는가?)

앞서 Fiddler를 활용한 프록시 우회 테스트 방법을 사용한 이유는, 직접 기기의 hosts 파일을 수정하는 방식에 비해 안전하고 간편하기 때문입니다. 몇 가지 비교를 통해 이 접근의 장점을 정리해보겠습니다:

• 시스템 권한 문제: 안드로이드의 /system/etc/hosts 파일을 수정하려면 root 권한이 필요한데, 일반적인 기기는 루팅이 막혀 있고 이를 무리하게 풀 경우 보안상 위험이 있습니다. iOS도 마찬가지로 탈옥 없이는 hosts 편집이 불가능합니다. 반면 프록시 방식은 운영체제의 기본 설정(와이파이 프록시 기능)을 사용하므로 루팅/탈옥이 필요 없고, 기기 보안에 영향을 주지 않습니다.
• 시스템 안정성: hosts 파일을 잘못 건드리면 기기의 네트워크 동작에 예기치 않은 문제가 생길 수 있습니다. 특히 모바일 기기에서는 hosts를 수정하는 행위 자체가 비정상적이어서, 운영체제 업데이트나 보안 앱(안티바이러스) 등이 이를 탐지해 차단하거나 경고를 발생시킬 수 있습니다. 프록시 테스트는 이러한 시스템 파일 변경 없이 일시적으로 설정했다가 원복할 수 있으므로 안전한 테스트가 가능합니다.
• 편의성과 신속성: hosts 파일을 수정하려면 일일이 기기 파일시스템에 접근해 편집하고 재부팅하는 과정이 필요할 수 있지만, Fiddler Hosts 리맵은 GUI 상에서 실시간으로 적용이 가능합니다. 필요할 때 켜고 끄기가 쉬워 테스트 환경 전환을 빠르게 할 수 있습니다. 예를 들어, 개발 서버와 운영 서버를 오가며 테스트해야 할 경우 Fiddler의 체크박스 하나로 손쉽게 전환할 수 있습니다.
• 가시성과 디버깅: Fiddler를 사용하면 트래픽을 우회할 뿐만 아니라 요청과 응답을 모두 모니터링할 수 있다는 장점이 있습니다. 요청 헤더나 응답 데이터, 에러 내용 등을 Fiddler 창에서 즉시 확인할 수 있어 문제를 디버깅하기에 용이합니다. 단순 hosts 파일 변경만으로는 패킷 내용을 들여다볼 수 없지만, 프록시 도구는 모니터링 + 우회 두 가지를 모두 충족합니다.
• HTTPS 인증 이슈: 새로운 서버가 운영 도메인과 동일한 SSL 인증서를 사용한다면 hosts 방식이든 프록시 방식이든 큰 문제없이 통신이 가능합니다. 다만, 만약 새 서버가 별도의 self-signed 인증서 등을 쓰는 경우 hosts 파일만 바꿀 경우 앱에서 SSL 오류가 발생할 수 있습니다. 이때 Fiddler를 사용하면 자체 인증서로 MITM(Man-in-the-Middle) 처리를 해주거나, 인증서를 설치하여 우회하는 등 대처가 가능합니다. 요컨대 복잡한 SSL 이슈 해결에도 프록시 방법이 더 유연합니다.

이러한 이유들로 실무 현장에서는 hosts 파일을 직접 수정하지 않고 프록시 툴을 활용하는 방식을 권장합니다. 특히 사내 보안 정책상 루팅이나 탈옥이 금지된 테스트 기기에서도 활용 가능하기 때문에, 안드로이드 앱 테스트와 아이폰 앱 테스트 모두에 통용되는 안전한 서버 교체 테스트 방법입니다.

Hosts 파일 등록하기

실제 사례: 안전하게 새 서버로 전환하기

필자의 경우에도 최근 모바일 앱 서버 마이그레이션 작업을 진행하면서 위 방법으로 사전 테스트를 수행했습니다. 운영 중인 앱이 example.com 도메인의 API 서버에 연결 중이었고, 새로운 스테이징 서버를 같은 도메인으로 구축한 상황이었습니다. DNS를 변경하기 전, Fiddler 프록시와 위의 Hosts 리맵 설정을 통해 앱을 실행해보니, 아무 코드 수정 없이도 앱이 새 서버(스테이징)에서 데이터를 잘 가져오는 것을 확인할 수 있었습니다. 덕분에 실제 DNS 전환 전에 숨겨진 버그를 발견하여 수정했고, 최종 배포 시 서비스 중단 없이 원활하게 서버를 교체할 수 있었죠.
이렇듯, Fiddler를 활용한 프록시 테스트는 개발/스테이징 서버 검증 단계에서 매우 유용한 도구입니다. QA 팀이나 운영팀에서도 별도의 앱 빌드 없이 현재 버전 앱으로 새 백엔드 검증 테스트를 수행할 수 있어, 배포 안정성을 크게 높일 수 있습니다.

마무리: 요약 및 다음 단계

정리하면, DNS 변경 전에 모바일 앱을 새 서버로 테스트하려면 Fiddler와 같은 프록시 툴을 사용하여 트래픽 가로채기 및 도메인 매핑을 설정하면 됩니다. 안드로이드와 아이폰 기기 모두 Wi-Fi 프록시 설정 기능을 제공하므로, 이를 활용해 PC의 Fiddler로 트래픽을 보내고, Hosts 리맵 기능으로 원하는 IP로 우회시켰습니다. 이 방법을 통해 hosts 파일 수정 없이도 앱을 새로운 서버에 연결해볼 수 있었고, 문제점도 사전에 발견할 수 있었습니다.
이제 배포 전에 남은 불안을 어느 정도 해소하고, 자신 있게 서버 마이그레이션을 진행해보세요. 🙂 Fiddler 외에도 Charles Proxy, mitmproxy 등 유사한 툴로 동일한 테스트를 할 수 있으며, 고급 사용자라면 개인 DNS 서버(dnsmasq)를 구성해 네트워크 단계에서 우회하는 방법도 있습니다. 중요한 것은, 어떠한 방법이든 사용자에게 영향 없이 미리 새 환경을 검증하는 과정이 꼭 필요하다는 점입니다.
마지막으로, 테스트를 마쳤다면 변경했던 설정(프록시, 인증서 등)을 원상복구하고 깔끔하게 정리하는 습관을 가지세요. 이제 안전한 배포를 위한 준비는 모두 끝났습니다!
여러분도 비슷한 상황에서 이 방법을 활용해 보셨나요? 혹은 궁금한 점이나 공유할 경험이 있다면 아래 댓글로 자유롭게 남겨주세요. 이 글이 도움이 되었다면 ❤ 공감(좋아요)도 부탁드립니다. 안전한 배포와 성공적인 테스트가 되시길 바랍니다! 🚀

---

자주 묻는 질문 (FAQ)

Q1. 꼭 Fiddler만 사용해야 하나요? 다른 툴은 없나요?
A1. Fiddler는 Windows 환경에서 무료로 쓰기 좋아 많이 언급했지만, Mac 사용자의 경우 Charles Proxy가 인기 있고 사용법도 유사합니다. Charles도 모든 HTTP/HTTPS 트래픽을 중간에서 가로채어 수정/조작할 수 있으며, 도메인별로 요청을 다른 서버로 포워딩하는 기능을 제공합니다. 이 밖에도 mitmproxy(오픈소스 콘솔 기반), Burp Suite(보안 테스트용 프로킷) 등 다양한 프록시 툴이 있습니다. 핵심 원리는 모두 같으며, 본문에 나온 개념(프록시 설정, 인증서 설치, hosts 리맵 등)을 이해했다면 어떤 툴이든 응용할 수 있습니다.
Q2. hosts 파일을 직접 고쳐서 테스트하면 안 되나요?
A2. 앞서 설명한 대로 안드로이드 hosts 파일 수정은 루팅이 필요하고 굉장히 번거롭습니다. iOS도 탈옥 없이는 hosts 접근이 불가능하죠. 이론적으로 기기를 루팅/탈옥해서 hosts를 수정하면 동일한 효과를 얻을 수 있지만, 테스트 한 번을 위해 기기의 보안을 희생하는 것은 매우 위험합니다. 또한 hosts를 잘못 건드리면 시스템 앱들의 동작에 예상치 못한 부작용이 생길 수 있습니다. 그러니 hosts 파일 대신 프록시를 통한 우회를 택하는 것이 훨씬 안전하고 권장됩니다. PC에서는 hosts 파일 수정이 흔하지만, 모바일에서는 hosts 대신 프록시를 쓰는 것이 표준적인 테스트 방법입니다.
Q3. HTTPS 연결에서도 이 방법이 통할까요? 암호화된 트래픽은 우회 못 시키는 것 아닌가요?
A3. 문제없습니다. Fiddler와 같은 프록시 툴은 HTTPS도 중간에서 처리할 수 있도록 설계되었습니다. 단, 이를 위해서는 앞서 설명한 대로 기기에 프록시 인증서(FiddlerRoot)를 설치하여 신뢰시켜야 합니다. 그러면 Fiddler가 앱과 서버 사이에 MITM으로 작동하면서 암호화된 데이터를 복호화해볼 수 있고, 필요하면 요청의 목적지도 바꿀 수 있습니다. 만약 인증서 설치를 원하지 않거나 못하는 상황이라면, Fiddler가 CONNECT 터널링 방식으로 도메인만 새 IP로 연결해 줄 수도 있습니다. 이때 새 서버가 원래 도메인의 SSL 인증서를 가지고 있어야 정상적인 통신이 이뤄집니다. 요약하면, 대부분의 경우 인증서 설정만 제대로 하면 HTTPS도 평소처럼 잘 통신되므로 새 서버 우회에 지장 없습니다.
Q4. 만약 앱에서 SSL Pinning(인증서 고정)을 하고 있다면 어떻게 하나요?
A4. SSL 핀닝이 되어 있는 앱은 특정 인증서나 공개키만 신뢰하도록 짜여 있기 때문에, 프록시로 중간에 끼어들 경우 통신이 실패합니다. 이런 경우 우회 테스트가 쉽지 않은데요, 가장 현실적인 대안은 테스트용으로 핀닝이 없는 앱 빌드를 별도로 만드는 것입니다. 또는 서버 쪽에 임시로 핀닝 예외를 두거나 (가능한 경우에 한해) 앱의 핀닝 설정을 동적으로 끄는 방법도 있지만 일반적이지 않습니다. 결론적으로, 핀ning된 앱은 보안상 중간자 개입을 막으므로, 프록시 우회 테스트가 불가능할 수 있다는 점을 인지해야 합니다. 다행히 핀닝을 사용하는 앱은 일부에 불과하며, 일반적인 앱 개발 단계에서는 필요시에만 핀닝을 적용하므로 대부분의 앱은 Fiddler 테스트가 가능합니다.
Q5. 테스트 후 원래대로 돌리는 것을 깜빡해서 문제된 경우도 있나요?
A5. 가끔 개발자들이 프록시 설정을 켜 둔 것을 잊고 있다가 네트워크 연결 문제를 겪는 일이 있습니다. 예를 들어, 모바일 기기에 프록시를 계속 켜 둔 채 외부에 나가면 인터넷이 되지 않습니다. 또 Fiddler Hosts 설정을 끈다는 것을 깜빡하고 그대로 두면 PC에서 브라우저 접속 시 엉뚱한 서버를 가리킬 수도 있습니다. 이러한 실수를 방지하려면, 테스트 완료 후 체크리스트를 만들어 프록시 해제, 인증서 삭제 여부 등을 확인하는 습관이 필요합니다. 다행히 설정만 원복하면 금방 정상 상태로 돌아오므로 큰 문제로 이어지진 않지만, 항상 테스트가 끝나면 환경을 정리하는 것을 생활화하세요.
Q6. 이 방법이 실제 서비스에는 영향 없나요?
A6. 네, 전혀 영향 없습니다. 여기서의 모든 설정은 테스터 본인 환경에서만 적용되는 것입니다. 프록시 설정은 내 기기가 특정 PC를 바라보도록 한 것이고, Hosts 리맵은 그 PC의 Fiddler 내에서만 이루어진 변경입니다. DNS 기록이나 실제 서버 구성은 손대지 않았으므로, 다른 사용자나 운영 서비스에는 아무 변화가 없습니다. 심지어 동일한 네트워크에 있는 다른 동료의 기기에도 영향을 주지 않습니다. 오직 프록시를 설정한 기기만 지정한 새 서버로 통신하고 있으니, 안심하고 테스트하셔도 됩니다. (물론 회사 내부망 등에서 테스트할 경우 다른 QA 팀원들에게도 방법을 공유하면 좋겠죠!)
위와 같이 Fiddler를 활용하면 DNS를 바꾸지 않고도 모바일 앱 서버 교체 테스트를 손쉽게 할 수 있습니다. 혹시 추가로 궁금한 점이 있다면 앞서 언급한 내용을 참고하시거나 질문해 주세요. 모두들 안전한 테스트로 완벽한 배포를 이루시길 바랍니다! 😃