Charles Proxy — 정의, 설정 및 HTTPS 트래픽 가로채기

Charles Proxy란?

Charles Proxy는 클라이언트와 서버 간의 중개자 역할을 하는 HTTP 프록시 및 HTTP 모니터입니다. 모든 요청과 응답은 Charles를 통과하므로 내용을 보고, 구조를 분석하고, 실시간으로 데이터를 수정하고, 다양한 네트워크 조건을 시뮬레이션할 수 있습니다. Windows, macOS, Linux에서 사용할 수 있습니다.

역사 및 포지셔닝

Charles Proxy는 2004년 Karl von Randow에 의해 만들어졌으며 네트워크 트래픽 디버깅을 위한 가장 인기 있는 도구 중 하나로 남아 있습니다. 무료 대안과 달리 Charles는 30일 평가판 기간이 있는 유료 라이선스를 제공합니다. 이 도구는 HTTP 통신을 완전히 제어해야 하는 모바일 앱 개발자, 웹 개발자 및 QA 엔지니어를 위한 전문 솔루션으로 자리잡고 있습니다.

플랫폼 호환성

Charles는 컴퓨터에서 시스템 프록시로 작동하며 동일한 네트워크에 있는 모든 기기(Android, iOS, 시뮬레이터, 에뮬레이터, 웹 브라우저, IoT 기기)의 트래픽을 가로챌 수 있습니다. HTTPS를 가로채려면 각 기기에 Charles 루트 인증서를 설치해야 합니다. 트래픽은 HTTP/1.1 및 HTTP/2(부분적으로)에서 지원됩니다. HTTP/3(QUIC)는 가로채기 수준에서 지원되지 않습니다.

Charles Proxy 작동 방식

Charles는 MITM(Man-in-the-Middle) 프록시 원리로 작동합니다. 클라이언트가 Charles를 통해 요청을 보내면 도구가 요청을 가로채서 대상 서버로 전달하고, 응답을 받아 클라이언트에 다시 전달합니다. 모든 트래픽은 Charles를 통과하므로 분석 및 수정이 가능합니다.

프록시 아키텍처

실행 시 Charles는 포트 8888(기본값)에 로컬 HTTP 프록시를 생성합니다. 운영 체제 또는 애플리케이션이 이 프록시를 사용하도록 구성됩니다. 모든 HTTP 요청은 먼저 Charles로 전송되며, Charles는 대상 서버에 대한 완전한 클라이언트 역할을 합니다. HTTPS의 경우 Charles는 자체 SSL 프록시 기술을 사용합니다. 각 도메인에 대해 즉시 인증서를 생성하고 Charles 루트 인증서로 서명합니다. 루트 인증서가 기기에 신뢰할 수 있는 것으로 설치된 경우 Charles는 HTTPS 트래픽을 복호화하여 볼 수 있습니다.

작동 모드

Charles는 두 가지 모드를 지원합니다: Proxy(클래식 프록시 서버) 및 SOCKS Proxy(UDP 및 TCP 트래픽용). 웹 개발에는 표준 HTTP 프록시가 사용됩니다. 모바일 기기의 경우 — Charles가 실행 중인 컴퓨터의 IP 주소를 지정하여 기기에서 WiFi 프록시를 구성합니다. macOS는 iOS 시뮬레이터에 대한 자동 프록시 구성을 지원합니다.

<!-- Charles 지원을 위한 Android용 network_security_config.xml 구성 -->
<?xml version="1.0" encoding="utf-8"?>
<network-security-config>
    <debug-overrides>
        <trust-anchors>
            <!-- Debug 빌드에서 Charles 인증서 신뢰 -->
            <certificates src="user" />
        </trust-anchors>
    </debug-overrides>
</network-security-config>

Charles Proxy의 주요 기능

Charles Proxy는 단순한 요청 가로채기를 훨씬 넘어서는 트래픽 분석 및 수정을 위한 전문 도구 세트를 제공합니다.

Rewrite 및 Breakpoints

Rewrite 도구를 사용하면 요청 또는 응답의 특정 부분(헤더, URL 매개변수, 응답 본문)을 자동으로 변경할 수 있습니다. 예를 들어 User-Agent 헤더를 다른 기기의 값으로 바꾸거나 특정 쿠키를 제거할 수 있습니다. Breakpoints는 디버거처럼 작동합니다. 요청이 선택된 단계(보내기 전 또는 받기 전)에서 중지되고 개발자가 계속 진행하기 전에 내용을 수동으로 변경할 수 있습니다. 이는 오류 응답 또는 비표준 상태 처리를 테스트하는 데 유용합니다.

Map Local 및 Map Remote

Map Local을 사용하면 네트워크 리소스(CSS, JS, JSON)를 디스크의 로컬 파일로 대체할 수 있습니다. 이는 프론트엔드 개발에 필수적입니다. 서버에 배포하지 않고 CSS/JS를 수정하고 즉시 결과를 볼 수 있습니다. Map Remote는 요청을 한 URL에서 다른 URL로 리디렉션합니다(예: 프로덕션 서버에서 스테이징으로 테스트용). 두 도구 모두 와일드카드를 지원하는 URL 패턴으로 작동합니다.

Throttle 및 네트워크 조건 시뮬레이션

Throttle 도구는 사전 설정된 프로필(3G, EDGE, GPRS, DSL, WiFi)을 사용하여 다양한 유형의 네트워크 연결을 시뮬레이션할 수 있습니다. 속도 제한(다운로드/업로드), 지연 시간, 패킷 손실 및 안정성을 구성할 수 있습니다. 이는 느리거나 불안정한 연결에서 앱 동작(적절한 타임아웃 처리, 재시도 로직, 오프라인 모드)을 테스트하는 데 중요합니다.

Auto Save 및 Recording

Charles는 트래픽 세션을 .chls 파일에 자동으로 저장할 수 있어 나중에 분석하거나 동료와 공유할 수 있습니다. Recording Control을 사용하면 저장할 트래픽을 도메인, 콘텐츠 유형 또는 상태 코드별로 유연하게 구성할 수 있습니다. 이는 장기 API 모니터링에 편리합니다.

모바일 기기를 위한 Charles Proxy 설정

모바일 앱 트래픽 디버깅을 위해 Charles는 WiFi 프록시로 구성됩니다. 컴퓨터와 동일한 네트워크에 있는 모든 기기가 Charles를 통해 트래픽을 라우팅할 수 있습니다. 올바른 HTTPS 구성은 모바일 기기에 Charles 인증서를 설치해야 합니다.

Android 설정

Android의 경우: Settings → WiFi → Advanced → Proxy를 열고 Manual을 선택한 다음 포트 8888과 함께 컴퓨터의 IP 주소를 입력합니다. 그런 다음 기기에서 브라우저를 열고 http://chls.pro/ssl로 이동하여 Charles 인증서를 다운로드합니다. Android 7+(API 24+)에서는 Debug 빌드에서 사용자 인증서를 신뢰하도록 network_security_config.xml이 필요합니다. 그렇지 않으면 앱이 Charles를 통해 트래픽을 라우팅하지 않을 수 있습니다.

iOS 설정

iOS의 경우: Settings → WiFi → 프록시 구성에서 IP와 포트 8888을 지정합니다. 그런 다음 Safari → http://chls.pro/ssl → 인증서 프로필을 설치합니다. iOS 10.3+에서는 추가로 인증서 신뢰를 활성화해야 합니다: Settings → General → About → Certificate Trust Settings → Charles Proxy를 켭니다. iOS는 인증서에 대해 더 엄격하며 일부 앱은 SSL Pinning을 사용하여 신뢰할 수 있는 인증서가 있어도 Charles를 통한 트래픽을 차단할 수 있습니다.

SSL Pinning 문제 해결

앱이 SSL Pinning(서버 인증서 고정)을 사용하는 경우 Charles를 통한 표준 프록시가 작동하지 않습니다. 앱이 Charles 인증서를 거부합니다. 해결책: OkHttp 또는 URLSession 설정을 통해 Debug 빌드에서 SSL Pinning을 비활성화하거나, Frida를 사용하여 런타임에 피닝을 우회하거나, 루트 액세스 권한이 있는 Android 에뮬레이터를 사용합니다.

Charles Proxy의 실용적인 사용 사례

Charles Proxy는 특정 개발 및 테스트 작업을 해결합니다. 이 도구가 필수적인 가장 일반적인 시나리오를 살펴보겠습니다.

API 통합 디버깅

가장 일반적인 시나리오는 API 요청의 정확성 확인입니다. Charles는 정확한 요청 URL, 헤더, 본문 및 매개변수를 표시합니다. 서버가 예상치 못한 응답을 반환하면 JSON 구조, 오류 코드, 응답 헤더를 즉시 볼 수 있습니다. 이를 통해 양측의 로그 없이 클라이언트 측 오류와 서버 측 오류를 구분할 수 있습니다.

느린 연결로 테스트

Throttle 프로필을 사용하여 낮은 연결 속도에서 앱이 어떻게 동작하는지 테스트할 수 있습니다. 로딩 표시기가 표시되는지, 타임아웃이 올바르게 처리되는지, 연결 끊김 시 UI가 정지되는지 여부를 확인합니다. 캐싱 테스트는 특히 중요합니다. 데이터가 이미 로드된 경우 앱은 무한 로딩 상태에 빠지지 않고 캐시에서 데이터를 표시해야 합니다.

서버 응답 편집

Breakpoints를 사용하여 앱으로 전송되기 전에 서버 응답을 수정할 수 있습니다. 예를 들어 데이터 대신 빈 배열을 반환하거나, 상태 코드를 500으로 변경하거나, JSON에 새 필드를 추가합니다. 이를 통해 서버 코드를 수정하지 않고도 에지 케이스 처리를 테스트할 수 있습니다. 이는 모바일 개발에서 Charles의 가장 강력한 사용법 중 하나입니다.