Postman에서 API 테스트를 위한 프록시 설정: 예제와 함께하는 완벽 가이드

Postman은 전 세계의 개발자, QA 엔지니어 및 백엔드 전문가들이 사용하는 가장 인기 있는 API 테스트 도구 중 하나입니다. 그러나 특정 지역에서만 접근 가능한 API를 테스트해야 하거나 IP 차단을 우회하거나 다양한 위치에서 요청을 확인해야 할 경우에는 어떻게 해야 할까요? 해결책은 Postman에서 프록시 서버를 설정하는 것입니다.

이 가이드에서는 간단한 트래픽 라우팅부터 지리적으로 제한된 엔드포인트 작업 및 기업 프록시 서버를 통한 요청 디버깅까지 다양한 시나리오에 맞게 Postman에서 프록시를 올바르게 설정하는 방법을 알아봅니다. 우리는 글로벌 및 개별 프록시 설정, HTTP 및 SOCKS5 프로토콜 작업, 인증 및 일반적인 문제 해결을 다룰 것입니다.

API 테스트에서 프록시가 필요한 이유

API 테스트 맥락에서 프록시 서버는 Postman의 기본 도구로는 수행할 수 없는 몇 가지 중요한 작업을 해결합니다. 이러한 시나리오를 이해하면 특정 요구에 맞는 프록시 유형을 올바르게 선택하고 설정할 수 있습니다.

지리적으로 제한된 API 테스트. 많은 현대 API는 클라이언트의 지리적 위치에 따라 다른 데이터를 반환합니다. 예를 들어, 날씨 서비스 API, 스트리밍 플랫폼, 금융 애플리케이션 또는 마켓플레이스가 있습니다. 독일, 미국 또는 일본의 사용자에게 애플리케이션이 어떻게 작동하는지 테스트하려면 해당 국가의 IP 주소를 가진 프록시 서버가 필요합니다. 프록시 없이 다른 지역의 사용자에 대한 API 동작을 재현할 수 없습니다.

비율 제한 및 IP 차단 우회. API를 집중적으로 테스트할 때 한 IP 주소에서의 요청 수에 대한 제한에 직면할 수 있습니다. 많은 서비스는 IP 수준에서 비율 제한을 사용합니다. 예를 들어, 한 주소에서 분당 100개 이상의 요청을 허용하지 않습니다. 프록시를 회전시키면 여러 IP 주소 간에 요청을 분산시켜 지연 없이 테스트를 계속할 수 있습니다. 이는 부하 테스트나 자동화된 검증 시 특히 중요합니다.

기업 프록시를 통한 작업. 엄격한 네트워크 정책이 있는 회사에서 근무하는 경우 모든 아웃바운드 트래픽이 기업 프록시 서버를 통해 전달될 수 있습니다. 이 경우 Postman에서 프록시 설정은 선택 사항이 아니라 필수입니다. 올바른 구성이 없으면 요청이 외부 API에 도달하지 않습니다.

트래픽 디버깅 및 모니터링. 프록시 서버는 HTTP/HTTPS 트래픽을 가로채고 분석하는 데 사용할 수 있습니다. Charles Proxy, Fiddler 또는 mitmproxy와 같은 도구를 사용하면 각 요청 및 응답의 세부 정보를 볼 수 있습니다. Postman을 이러한 프록시를 통해 작동하도록 설정하면 복잡한 API 상호작용을 디버깅하는 강력한 도구를 얻을 수 있습니다.

Postman에서의 글로벌 프록시 설정

Postman은 프록시를 설정하는 두 가지 주요 방법을 제공합니다: 글로벌(모든 요청에 적용) 및 개별(특정 컬렉션 또는 요청에 대해). 애플리케이션의 설정 메뉴에 있는 글로벌 설정부터 시작하겠습니다.

프록시 설정에 접근하는 단계별 지침:

1. Postman을 열고 애플리케이션 오른쪽 상단의 기어 아이콘(설정)을 클릭하거나 단축키 Ctrl+, (Windows/Linux) 또는 Cmd+, (macOS)를 사용합니다.
2. 열린 설정 창에서 Proxy 탭으로 이동합니다.
3. 여기에서 아래에서 자세히 살펴볼 프록시 서버 구성 옵션 몇 가지를 볼 수 있습니다.

프록시 설정 섹션에서는 프록시와 함께 사용할 수 있는 세 가지 주요 모드를 찾을 수 있습니다:

• 시스템 프록시 사용 — 운영 체제의 시스템 프록시 설정 사용
• 커스텀 프록시 구성 추가 — 수동으로 자체 프록시 서버 설정
• 글로벌 프록시 구성 — HTTP 및 HTTPS에 대한 서로 다른 프록시를 지정할 수 있는 글로벌 구성

각 모드는 장점이 있으며 다양한 사용 시나리오에 적합합니다. 이제 자세히 살펴보겠습니다.

시스템 프록시 설정 사용

Postman에서 프록시를 설정하는 가장 간단한 방법은 시스템 프록시 설정을 사용하는 것입니다. 이 모드는 운영 체제 수준에서 이미 프록시가 설정된 기업 환경에서 작업할 때 특히 편리합니다. 또는 시스템 프록시를 자동으로 구성하는 VPN 클라이언트를 사용하는 경우에도 유용합니다.

시스템 프록시 사용을 활성화하는 방법:

1. Postman에서 Settings → Proxy를 엽니다.
2. 시스템 프록시 사용 옆의 체크박스를 선택합니다.
3. Postman은 자동으로 운영 체제의 프록시 설정을 감지합니다.
4. 변경 사항을 저장하려면 업데이트 버튼을 클릭합니다.

이 옵션을 활성화하면 Postman은 브라우저나 다른 애플리케이션과 동일한 프록시 설정을 사용합니다. 즉, Windows(설정 → 네트워크 및 인터넷 → 프록시), macOS(시스템 환경설정 → 네트워크 → 고급 → 프록시) 또는 Linux(환경 변수 사용)에서 프록시를 설정한 경우 Postman이 이러한 매개변수를 자동으로 가져옵니다.

커스텀 프록시 서버 설정

커스텀 프록시 설정은 트래픽 라우팅에 대한 완전한 제어를 제공합니다. 특정 프록시 서버, 포트, 프로토콜 유형을 지정하고 HTTP 및 HTTPS 요청에 대해 서로 다른 프록시를 설정할 수 있습니다. 이 방법은 상업용 프록시 서비스나 자체 프록시 인프라를 사용하는 테스트에 적합합니다.

커스텀 프록시 설정 단계:

1. Postman에서 Settings → Proxy를 엽니다.
2. 시스템 프록시 사용 옵션이 비활성화되어 있는지 확인합니다.
3. 커스텀 프록시 구성 추가 옵션을 활성화합니다.
4. 프록시 유형 필드에서 프로토콜을 선택합니다: HTTP, HTTPS 또는 SOCKS5.
5. 프록시 서버 필드에 프록시 서버의 주소를 입력합니다 (예: proxy.example.com 또는 IP 주소 192.168.1.100).
6. 프록시 포트 필드에 포트를 입력합니다 (일반적으로 HTTP는 8080, SOCKS5는 1080이지만 제공업체에 따라 다를 수 있습니다).
7. 프록시가 인증을 요구하는 경우 프록시 인증 옵션을 활성화하고 사용자 이름과 비밀번호를 입력합니다.
8. 설정을 적용하려면 업데이트를 클릭합니다.

설정을 저장한 후 모든 아웃바운드 요청은 지정된 프록시 서버를 통해 전달됩니다. IP 확인 서비스에 테스트 요청을 보내어 설정의 정확성을 확인할 수 있습니다. 예를 들어:

GET https://api.ipify.org?format=json

응답에서 프록시 서버의 IP 주소를 확인해야 하며, 실제 IP 주소가 아닌 프록시의 IP 주소가 표시되어야 합니다. IP가 변경되지 않았다면 입력한 데이터의 정확성을 확인하고 프록시 서버가 작동하는지 확인하세요.

HTTP 및 HTTPS에 대한 서로 다른 프록시 설정

Postman은 HTTP 및 HTTPS 트래픽에 대해 별도의 프록시 서버를 설정할 수 있습니다. 이는 보안 연결에 대해 별도의 SSL 검사 프록시를 사용하는 기업 인프라에서 작업할 때 유용합니다.

분리된 설정을 위해:

1. 프록시 설정 섹션에서 글로벌 프록시 구성을 활성화합니다.
2. 두 개의 개별 블록: HTTP 프록시 및 HTTPS 프록시를 볼 수 있습니다.
3. 각 블록에 대해 서버, 포트 및 인증 정보를 지정합니다.
4. 변경 사항을 저장합니다.

이제 HTTP 요청은 하나의 프록시를 통해, HTTPS 요청은 다른 프록시를 통해 전송됩니다. 이는 하이브리드 인프라에서 테스트할 때 특히 중요합니다.

인증이 필요한 프록시 작업

대부분의 상업용 프록시 서비스와 기업 프록시는 접근을 위해 인증을 요구합니다. Postman은 프록시 서버에 대한 기본 HTTP 인증(Basic Auth)을 지원하여 안전하게 자격 증명을 전달할 수 있습니다.

프록시 인증 설정:

1. 프록시 설정(설정 → 프록시)에서 프록시 인증 옵션을 활성화합니다.
2. 사용자 이름 필드에 프록시 제공업체에서 제공한 사용자 이름을 입력합니다.
3. 비밀번호 필드에 비밀번호를 입력합니다.
4. 저장을 위해 업데이트를 클릭합니다.

Postman은 프록시를 통해 전송되는 각 요청에 Proxy-Authorization 헤더를 자동으로 추가합니다. 자격 증명은 인코딩된 형태(Base64)로 전달되지만, 최대한의 보안을 위해 HTTPS 프록시 또는 암호화된 SOCKS5를 사용하는 것이 좋습니다.

주거용 프록시 설정 예시

예를 들어, 미국과 유럽의 사용자에게 다른 콘텐츠를 반환하는 API 테스트를 위해 주거용 프록시를 사용한다고 가정해 보겠습니다. 프록시 제공업체에서 다음과 같은 정보를 제공했습니다:

• 서버: us.residential.proxy.com
• 포트: 8080
• 사용자 이름: user_12345
• 비밀번호: SecurePass789

Postman에서의 설정은 다음과 같습니다:

• 프록시 유형: HTTP
• 프록시 서버: us.residential.proxy.com
• 프록시 포트: 8080
• 프록시 인증: 활성화됨
• 사용자 이름: user_12345
• 비밀번호: SecurePass789

설정을 적용한 후 모든 요청은 미국의 IP 주소로 전송되어 geo-specific API 동작을 테스트할 수 있습니다.

Postman에서 SOCKS5 프록시 설정

SOCKS5는 HTTP/HTTPS에 비해 더 범용적인 프록시 프로토콜입니다. 네트워크 스택의 더 낮은 수준에서 작동하며 HTTP뿐만 아니라 모든 유형의 트래픽을 프록시할 수 있습니다. SOCKS5는 비표준 프로토콜을 사용하는 API 테스트나 최대한의 익명성이 요구되는 경우에 특히 유용합니다.

API 테스트를 위한 SOCKS5의 장점:

• 모든 프로토콜 지원 (HTTP, HTTPS, WebSocket, FTP 등)
• 요청 헤더를 수정하지 않음 (HTTP 프록시와 다름)
• UDP 트래픽 지원 (일부 실시간 API에 유용)
• 프로토콜 수준에서의 인증 지원
• HTTPS 연결에 대한 더 나은 성능 (이중 SSL 핸드셰이크 없음)

Postman에서 SOCKS5 설정:

1. Settings → Proxy를 엽니다.
2. 커스텀 프록시 구성 추가를 활성화합니다.
3. 프록시 유형 필드에서 SOCKS5를 선택합니다.
4. SOCKS5 서버의 주소와 포트를 입력합니다 (일반적으로 1080이지만 제공업체에 따라 다를 수 있습니다).
5. 인증이 필요한 경우 프록시 인증을 활성화하고 자격 증명을 입력합니다.
6. 설정을 저장합니다.

모든 프록시 제공업체가 SOCKS5를 지원하는 것은 아닙니다. 테스트를 위해 이 프로토콜이 필요한 경우 제공업체에 SOCKS5 엔드포인트의 가용성을 확인하세요. 예를 들어, 모바일 프록시는 종종 최대한의 유연성을 위해 HTTP/HTTPS 외에 SOCKS5를 제공합니다.

프록시 우회 규칙 설정

때때로 요청의 일부는 프록시를 통해 전송하고 일부는 직접 전송해야 할 필요가 있습니다. 예를 들어, 외부 API를 프록시를 통해 테스트하지만 로컬 개발 서버(로컬호스트)와도 작업해야 할 경우가 있습니다. 이러한 시나리오를 위해 Postman은 프록시 우회 규칙(Proxy Bypass) 설정을 제공합니다.

우회 규칙 설정 방법:

1. Settings → Proxy에서 이 호스트 및 도메인에 대해 프록시 우회 섹션을 찾습니다.
2. 프록시를 우회해야 하는 도메인 또는 IP 주소 목록을 입력하고 쉼표로 구분합니다.
3. 마스크를 지원합니다: 예를 들어, *.internal.company.com은 모든 서브도메인을 제외합니다.
4. 변경 사항을 저장합니다.

우회 규칙 예시:

• localhost — 로컬 호스트 우회
• 127.0.0.1 — 루프백 주소 우회
• 192.168.*.* — 전체 로컬 네트워크 우회
• *.dev.company.com — 내부 개발 서버 우회
• api.internal.service — 특정 내부 API 우회

우회 규칙은 외부 API(지리적 타겟팅 또는 제한 우회를 위해 프록시를 통해)와 내부 서비스(속도 및 디버깅의 용이성을 위해 직접) 모두를 테스트하는 하이브리드 환경에서 특히 유용합니다.

Postman에서 프록시 사용의 실제 시나리오

이론은 좋지만, API 테스트에서 프록시를 사용하는 실제 시나리오를 살펴보겠습니다. 이러한 예시는 특정 작업을 해결하기 위해 프록시 설정을 어떻게 적용할 수 있는지 이해하는 데 도움이 될 것입니다.

시나리오 1: 음악 스트리밍 서비스의 지리적으로 제한된 API 테스트

작업: 귀사의 회사는 음악 스트리밍을 위한 모바일 애플리케이션을 개발하고 있습니다. API는 라이센스 제한으로 인해 사용자 국가에 따라 다른 트랙 카탈로그를 반환합니다. 미국, 독일 및 일본의 사용자가 올바른 콘텐츠를 보고 있는지 테스트해야 합니다.

해결책:

1. 미국, 독일, 일본의 주거용 프록시를 확보합니다.
2. Postman에서 "USA Testing", "Germany Testing", "Japan Testing"이라는 세 개의 환경을 생성합니다.
3. 각 환경에서 프록시 설정을 위한 변수를 생성합니다 (비록 Postman이 프록시 설정에서 변수를 직접 지원하지 않지만, 환경 설명에 문서화할 수 있습니다).
4. 각 지역을 테스트하기 전에 Settings → Proxy에서 수동으로 프록시를 전환합니다.
5. API에 요청을 보냅니다: GET https://api.musicservice.com/v1/catalog
6. 결과를 비교합니다: 응답에서 각 국가에 대해 다른 트랙이 반환되어야 합니다.

이 프로세스를 자동화하기 위해 Newman(Postman의 CLI 버전)을 사용하여 프록시 매개변수를 설정하면 CI/CD 파이프라인에서 테스트를 실행할 때 자동으로 프록시를 전환할 수 있습니다.

시나리오 2: 부하 테스트에서 비율 제한 우회

작업: IP당 분당 100개의 요청 제한이 있는 공개 API의 성능을 테스트하고 있습니다. 완전한 부하 테스트를 위해 분당 1000개의 요청을 보내야 합니다.

해결책:

1. 10개 이상의 프록시 서버 풀을 사용하여 회전합니다.
2. 테스트 요청으로 Postman Collection Runner를 설정합니다.
3. Pre-request Script에 프록시 회전 로직을 추가합니다 (참고: Postman은 스크립트에서 프로그래밍 방식으로 프록시를 전환하는 것을 지원하지 않으므로, 이 시나리오는 Newman을 통해 외부 스크립트로 구현하는 것이 좋습니다).
4. 대안: IP 자동 회전을 지원하는 프록시 제공업체를 사용합니다 (짧은 TTL을 가진 스티키 세션).

이러한 시나리오에는 데이터 센터 프록시가 이상적입니다. 이들은 높은 속도를 제공하고 여러 IP 주소 간에 부하를 분산시킬 수 있습니다.

시나리오 3: SSL 검사로 HTTPS API 디버깅

작업: 외부 API와 통합하고 있으며, 500 오류가 반환되지만 오류의 세부 사항은 명시되어 있지 않습니다. 모든 헤더와 본문을 포함하여 HTTPS 요청 및 응답의 전체 내용을 보고 싶습니다.

해결책:

1. HTTPS 트래픽을 가로채는 도구를 설치합니다: Charles Proxy, Fiddler 또는 mitmproxy.
2. 도구를 포트(일반적으로 Charles의 경우 8888, Fiddler의 경우 8888)에서 수신 대기하도록 설정합니다.
3. 시스템에 도구의 SSL 인증서를 설치합니다 (일반적으로 애플리케이션 내에서 지침이 제공됩니다).
4. Postman Settings → Proxy에서 프록시를 localhost:8888로 설정합니다.
5. 테스트 목적으로 Postman에서 SSL 인증을 비활성화합니다 (Settings → General → SSL certificate verification → OFF).
6. Postman에서 문제의 요청을 보냅니다.
7. Charles/Fiddler에서 요청 및 응답의 전체 덤프를 볼 수 있으며, HTTPS 트래픽이 복호화된 상태로 표시됩니다.

이 방법은 API와 관련된 복잡한 문제를 디버깅하는 데 필수적입니다. 특히 문서가 불완전하거나 서버 측에서 오류가 발생하는 경우에 유용합니다.

시나리오 4: 화이트리스트가 있는 기업 프록시를 통한 API 테스트

작업: 모든 아웃바운드 트래픽이 기업 프록시를 통해 전달되는 대기업에서 근무하고 있습니다. 프록시는 화이트리스트 도메인에만 접근을 허용합니다. 화이트리스트에 추가되지 않은 새로운 외부 API를 테스트해야 합니다.

해결책:

1. IT 부서에 API 도메인을 화이트리스트에 추가해 달라고 요청합니다 (며칠 또는 몇 주가 걸릴 수 있습니다).
2. 즉각적인 테스트를 위해 개인 모바일 인터넷을 사용하거나 VPN을 설정합니다.
3. Postman에서 API 도메인을 프록시 우회 규칙에 추가합니다 (이 호스트에 대해 프록시 우회).
4. 대체 네트워크에 연결합니다 (모바일 핫스팟, VPN을 통한 가정용 Wi-Fi).
5. 테스트를 수행합니다.
6. 도메인이 기업 화이트리스트에 추가된 후 우회 규칙을 삭제하고 표준 프록시를 통해 작업합니다.

이 시나리오는 기업 환경에서 프록시 및 우회 규칙의 유연한 설정의 중요성을 보여줍니다.

프록시 작업 시 일반적인 문제 해결

프록시를 올바르게 설정했더라도 문제가 발생할 수 있습니다. 가장 일반적인 오류와 해결 방법을 살펴보겠습니다.

문제 1: "응답을 받을 수 없습니다" 또는 "오류: connect ETIMEDOUT"

원인:

• 프록시 서버에 접근할 수 없거나 주소/포트가 잘못 지정됨
• 프록시가 인증을 요구하지만 자격 증명이 제공되지 않음
• 방화벽이 프록시 연결을 차단함
• 프록시 서버가 과부하 상태이거나 일시적으로 사용할 수 없음

해결 방법:

1. 터미널을 통해 프록시의 가용성을 확인합니다: curl -x http://proxy:port https://api.ipify.org
2. 주소와 포트가 올바르게 지정되었는지 확인합니다 (여분의 공백 없이, 올바른 프로토콜 사용)
3. 인증이 활성화되어 있는지 확인하고 사용자 이름/비밀번호가 올바르게 입력되었는지 확인합니다
4. 프록시 풀에서 다른 프록시 서버를 시도해 봅니다
5. Postman에서 프록시를 일시적으로 비활성화하고 요청이 직접 작동하는지 확인합니다

문제 2: "407 프록시 인증 필요"

원인: 프록시가 인증을 요구하지만 자격 증명이 제공되지 않거나 잘못됨.

해결 방법:

1. Postman 설정에서 프록시 인증을 활성화합니다
2. 사용자 이름과 비밀번호의 정확성을 확인합니다 (대소문자 및 특수 문자에 주의)
3. 귀하의 IP 주소가 프록시 제공업체의 화이트리스트에 포함되어 있는지 확인합니다 (해당되는 경우)
4. 자격 증명의 유효성을 확인합니다 (일부 제공업체는 임시 비밀번호를 생성합니다)

문제 3: HTTPS 프록시 사용 시 SSL/TLS 오류

일반적인 오류: "SSL 인증서 문제", "첫 번째 인증서를 확인할 수 없음", "인증서 체인에 자체 서명된 인증서".

원인:

• 프록시가 SSL 검사를 수행하고 자신의 인증서를 삽입함
• 프록시 인증서가 시스템의 신뢰할 수 있는 인증서 목록에 설치되지 않음
• API 측에서 인증서 체인에 문제가 있음

해결 방법:

1. 테스트 목적으로: Postman에서 SSL 인증을 비활성화합니다 (Settings → General → SSL certificate verification → OFF). 주의: 프로덕션에서는 사용하지 마세요!
2. 프로덕션에서는: 프록시의 루트 인증서를 시스템 및 Postman에 설치합니다 (Settings → Certificates → CA Certificates)
3. SSL 검사가 없는 프록시를 사용합니다 (SOCKS5 또는 SSL 패스스루가 있는 HTTP 프록시)
4. 올바른 인증서를 받기 위해 프록시 관리자에게 문의합니다

문제 4: 프록시를 통한 요청 속도가 느림

원인:

• 프록시 서버가 귀하 또는 대상 API와 지리적으로 멀리 위치해 있음
• 프록시가 과부하 상태임 (특히 무료 또는 저렴한 프록시의 경우)
• 프록시 제공업체의 느린 통신 경로
• 이중 SSL 암호화 (클라이언트 → 프록시 → API)

해결 방법:

1. 대상 API에 더 가까운 프록시 서버를 선택합니다 (API가 미국에 있는 경우, 미국의 프록시를 사용합니다)
2. 프록시 유형을 더 빠른 것으로 전환합니다 (예: 지리적 제약이 없는 경우 주거용에서 데이터 센터로 전환)
3. HTTPS 요청에 대해 SOCKS5를 사용합니다 (오버헤드가 적음)
4. 보장된 대역폭을 제공하는 프리미엄 프록시를 고려합니다
5. 중요하지 않은 요청의 경우 프록시를 일시적으로 비활성화합니다

문제 5: 프록시가 설정되어 있지만 IP 주소가 변경되지 않음

원인:

• 프록시가 설정되었지만 활성화되지 않음 (업데이트 버튼을 클릭하는 것을 잊음)
• API 도메인이 프록시 우회 규칙에 추가됨
• 시스템 프록시가 Postman 설정을 재정의함
• DNS 요청이 직접 전송됨 (DNS 누수)

해결 방법:

1. 프록시가 실제로 활성화되어 있는지 확인합니다: https://api.ipify.org에 요청을 보내고 응답에서 IP를 확인합니다
2. 커스텀 프록시를 사용하는 경우 시스템 프록시 사용이 비활성화되어 있는지 확인합니다
3. 우회 도메인 목록을 확인하고 대상 도메인이 포함되어 있으면 제거합니다
4. 프록시 설정을 변경한 후 Postman을 재시작합니다

결론

Postman에서 프록시 설정은 API 테스트의 가능성을 확장하는 강력한 도구입니다. 시스템 및 커스텀 프록시 서버를 설정하고, HTTP 및 SOCKS5 프로토콜을 작업하며, 인증 및 우회 규칙을 설정하는 방법을 배웠습니다. 이러한 기술은 지리적으로 제한된 API를 효과적으로 테스트하고, 비율 제한을 우회하며, 기업 프록시를 통해 작업하고, 트래픽 가로채기 도구를 사용하여 복잡한 문제를 디버깅하는 데 도움이 될 것입니다.

이 가이드의 주요 내용은 다음과 같습니다: