HTTP Toolkit 사용법: 브라우저·터미널·안드로이드 요청을 가로채 디버깅하는 법 (무료 vs Pro, 2026)
앱을 만들다 보면 “분명히 요청을 보냈는데 서버는 못 받았다고 한다”거나 “로컬에서는 되는데 배포하면 결제 웹훅만 실패한다” 같은 순간이 꼭 옵니다. 이럴 때 코드에 로그를 열 줄씩 박는 것보다 빠른 방법이 실제로 오가는 HTTP 요청을 눈으로 보는 것입니다. 제가 그럴 때 꺼내는 도구가 HTTP Toolkit입니다.
이 주소에는 원래 짧은 HTTP Toolkit 소개 글이 있었는데, 검색으로 들어오시는 분들이 주로 “HTTP Toolkit 사용법”을 찾고 계셔서 소개 대신 사용법 위주로 처음부터 다시 썼습니다. 2026년 10월 기준으로 공식 문서와 GitHub 릴리스를 확인해서 정리했고, 최신 데스크톱 버전은 9월 중순에 나온 v1.27.2입니다. 버전이나 요금은 바뀔 수 있으니 설치 전에 공식 사이트를 한 번 더 보시면 좋습니다.
HTTP Toolkit이 뭔가요?
HTTP Toolkit은 내 컴퓨터에서 나가고 들어오는 HTTP·HTTPS 통신을 중간에서 잡아 보여 주는 디버깅 프록시입니다. 브라우저 개발자 도구의 네트워크 탭과 비슷해 보이지만 범위가 다릅니다. 네트워크 탭은 그 브라우저 안의 요청만 보여 주지만, HTTP Toolkit은 터미널에서 돌린 Node.js·Python 스크립트, 도커 컨테이너, 안드로이드 앱, 데스크톱 앱이 보내는 요청까지 한 화면에서 봅니다. 그리고 보기만 하는 게 아니라 요청을 중간에 멈추고 고치거나, 가짜 응답을 돌려주거나, 일부러 에러를 내게 할 수 있습니다.
비슷한 도구로 Charles, Fiddler, mitmproxy, Proxyman이 있습니다. HTTP Toolkit의 장점은 “버튼 한 번으로 가로채기”입니다. 프록시 주소를 직접 넣고 인증서를 설치하는 귀찮은 과정을 대상별로 자동으로 해 줍니다. 핵심 기능은 오픈소스로 공개돼 있고, 맥·윈도우·리눅스를 모두 지원합니다.
설치하고 처음 켜면 보이는 화면
httptoolkit.com에서 운영체제에 맞는 설치 파일을 받아 설치하면 됩니다. 처음 켜면 Intercept 화면이 나오고, 가로챌 수 있는 대상이 카드 형태로 쭉 보입니다. Chrome, Firefox 같은 브라우저, Fresh Terminal, Android 기기, Docker 컨테이너, 그리고 수동 설정용인 Anything 같은 항목입니다. 내 컴퓨터에 해당 프로그램이 없으면 카드가 비활성화돼 있고, 일부는 앞으로 나올 기능 자리라 눌리지 않는 것도 있습니다.
가로챈 요청은 View 화면에 쌓입니다. 왼쪽에 보낸 순서대로 목록이 나오고, 하나를 누르면 오른쪽에 요청 헤더, 본문, 응답 상태 코드, 응답 본문이 펼쳐집니다. 여기까지가 무료로 되는 기본 흐름입니다.
HTTP Toolkit 사용법 1: 브라우저 요청 가로채기
가장 쉬운 시작은 Chrome 카드입니다. 누르면 새 크롬 창이 하나 뜨는데, 이건 내가 평소 쓰는 크롬과 분리된 깨끗한 프로필입니다. 확장 프로그램도, 로그인 기록도 없는 상태라 평소 브라우저는 그대로 두고 이 창에서만 테스트하면 됩니다. 창이 열리면 처음에 amiusing.httptoolkit.tech 페이지가 보이는데, 여기서 “가로채지고 있다”는 문구가 나오면 성공입니다.
이제 개발 중인 사이트를 이 창에서 열면 모든 요청이 HTTP Toolkit에 찍힙니다. 저는 주로 이런 걸 확인합니다.
- 로그인 후 API 요청에 인증 헤더가 제대로 붙는지
- 프런트에서 보내는 JSON 필드 이름이 백엔드가 기대하는 것과 같은지
- 같은 API를 화면 하나에서 몇 번씩 중복 호출하고 있지 않은지
- 캐시 관련 헤더가 의도대로 나가는지
브라우저 네트워크 탭으로도 상당 부분 볼 수 있지만, 서드파티 스크립트나 서비스 워커 요청까지 한 목록에서 필터링하며 보려면 HTTP Toolkit 쪽이 편합니다.
HTTP Toolkit 사용법 2: 터미널·서버 코드 가로채기
제가 HTTP Toolkit을 계속 쓰는 진짜 이유는 이쪽입니다. Fresh Terminal 카드를 누르면 새 터미널 창이 열리는데, 이 창 안에는 프록시 관련 환경 변수와 설정이 미리 들어가 있습니다. 공식 문서 설명대로라면 이 터미널에서 실행한 Node.js, Python, Java, Ruby, PHP, cURL 같은 도구의 HTTP 요청이 대부분 자동으로 가로채집니다. 다른 점은 없어서 평소처럼 명령어를 치면 됩니다.
예를 들어 이 터미널에서 서버를 띄우고 결제 대행사 API를 호출하는 코드를 돌리면, 내 서버가 바깥으로 보내는 요청이 그대로 보입니다. “SDK가 내부에서 뭘 보내는지 모르겠다”는 상황에서 특히 유용합니다. 서버 코드 쪽 버그 대부분이 결국 “생각했던 것과 다른 요청이 나가고 있었다”로 끝나기 때문입니다.
도커로 돌리는 서비스도 Docker 카드로 컨테이너를 가로챌 수 있습니다. 로컬에서 여러 서비스를 compose로 띄워 놓고 서비스 간 요청을 보고 싶을 때 씁니다.
HTTP Toolkit 사용법 3: 안드로이드 앱 가로채기
모바일 앱을 만든다면 안드로이드 연결도 해 볼 만합니다. 같은 와이파이에 있는 기기라면 QR 코드로, USB 디버깅이 켜진 기기라면 ADB로 연결합니다. 연결하면 기기에 HTTP Toolkit 앱이 설치되고 VPN 형태로 트래픽을 넘겨받습니다.
여기서 많이 막히는 게 HTTPS입니다. 안드로이드 7 이후로 앱은 기본적으로 사용자가 설치한 인증서를 믿지 않습니다. 그래서 내 앱의 HTTPS 요청을 보려면 디버그 빌드에 네트워크 보안 설정(network_security_config)으로 사용자 인증서를 신뢰하도록 넣어 주는 게 일반적인 방법입니다. 루팅된 기기나 에뮬레이터에서는 시스템 인증서로 넣는 방식도 지원합니다. 다른 회사 앱의 통신을 들여다보는 용도로 쓰는 건 약관과 법적 문제가 생길 수 있으니, 내 앱과 테스트 환경에서만 쓰시길 권합니다.
HTTP Toolkit 사용법 4: 자동 설정이 없는 프로그램
카드에 없는 프로그램은 Anything을 누르면 수동 설정에 필요한 정보가 나옵니다. 할 일은 두 가지입니다.
- 그 프로그램의 HTTP 프록시 설정을 HTTP Toolkit이 알려 주는 주소와 포트로 바꾸기
- HTTPS를 쓴다면 HTTP Toolkit의 인증서를 그 프로그램이 신뢰하게 만들기
공식 문서의 문제 해결 팁이 꽤 실용적입니다. amiusing.httptoolkit.tech로 요청을 보내 보고 “가로채지지 않고 있다”가 나오면 프록시 설정 문제, 인증서 오류가 나면서 View 화면에 실패한 요청이 찍히면 인증서 신뢰 문제입니다. 이 두 갈래만 구분해도 대부분 금방 풀립니다.
요청을 멈추고 고치기: 브레이크포인트
보는 것 다음 단계가 고치는 것입니다. Modify 화면에서 규칙을 만들면 특정 주소로 가는 요청이나 돌아오는 응답을 중간에 멈출 수 있습니다. 멈춘 상태에서 헤더나 본문을 직접 바꾸고 계속 보내면 됩니다. 이건 무료 기능입니다.
저는 이걸 이런 테스트에 씁니다.
- 응답에서 가격 필드를 0이나 음수로 바꿔 보고 화면이 깨지지 않는지 확인
- 응답 상태 코드를 500으로 바꿔서 에러 화면이 제대로 나오는지 확인
- 요청에서 인증 헤더를 지워 보고 서버가 401을 제대로 돌려주는지 확인
마지막 항목은 사실 보안 점검에 가깝습니다. 프런트에서 버튼을 숨겼다고 서버가 막아 주는 건 아니라서, 요청을 직접 고쳐 보내 보는 습관이 생각보다 많은 구멍을 찾아 줍니다. 데이터베이스 쪽에서 같은 원리로 막는 방법은 Supabase RLS 설정 체크리스트에 정리해 두었습니다.
내가 직접 요청 보내기
Send 화면에는 기본 HTTP 클라이언트가 들어 있습니다. Postman이나 Insomnia처럼 주소, 메서드, 헤더, 본문을 넣고 요청을 보내는 기능입니다. 가볍게 API 하나 확인하는 정도라면 따로 도구를 켤 필요가 없습니다. 가로챈 요청을 그대로 다시 보내거나 고쳐서 보내는 기능(resend)은 Pro 쪽에 들어 있습니다.
목록이 너무 길 때: 필터 쓰는 법
크롬 하나만 가로채도 몇 분이면 요청이 수백 개 쌓입니다. 광고 스크립트, 폰트, 분석 도구 요청이 섞여서 정작 보고 싶은 API 요청이 묻히는 거죠. 그래서 실제로는 필터를 먼저 걸고 시작합니다. View 화면 아래쪽 입력칸에 조건을 넣으면 되는데, 저는 주로 호스트 이름으로 내 API 서버만 남기거나, 상태 코드로 400 이상인 실패 요청만 남기는 식으로 씁니다. 필요 없는 요청은 지워 버리고, 계속 비교해야 하는 요청은 고정(pin)해 두면 목록을 정리해도 남아 있습니다. 이 정도는 무료 기능이고, 자주 쓰는 필터 조합에 이름을 붙여 저장하는 건 Pro 기능입니다.
실제 흐름 예시: 배포 후에만 외부 API 호출이 401로 실패할 때
제가 디버깅할 때 머릿속으로 밟는 순서를 그대로 적어 보겠습니다. 상황은 이렇습니다. 로컬에서는 잘 되던 외부 API 호출이 배포한 뒤부터 401을 돌려줍니다.
- 먼저 로컬에서 Fresh Terminal로 서버를 띄우고, 같은 기능을 한 번 실행해 성공하는 요청을 기록합니다. 이게 비교 기준입니다.
- 그 요청을 고정해 두고 헤더를 봅니다. 인증 헤더의 이름과 형식(예: Bearer 접두어 유무)을 메모합니다.
- 배포 환경과 같은 환경 변수 값을 로컬에 잠깐 넣고 다시 실행합니다. 여기서 실패하면 원인은 코드가 아니라 환경 변수 쪽입니다. 키 앞뒤 공백, 테스트 키와 운영 키가 바뀐 경우가 가장 흔합니다.
- 로컬에서도 성공한다면 차이는 네트워크 경로에 있을 가능성이 큽니다. 배포 환경에서 프록시를 거치는지, 리다이렉트가 일어나면서 인증 헤더가 떨어지는지 확인합니다. HTTP 클라이언트 상당수가 다른 도메인으로 리다이렉트될 때 인증 헤더를 빼고 보내기 때문입니다.
- 원인을 찾으면 브레이크포인트로 일부러 같은 401 응답을 만들어서, 내 앱이 사용자에게 엉뚱한 화면 대신 제대로 된 안내를 보여 주는지도 같이 확인합니다.
이 과정에서 코드를 한 줄도 고치지 않고 원인 후보를 절반 이상 지울 수 있다는 게 이 도구의 진짜 가치라고 생각합니다.
무료 vs Pro: 언제 돈을 낼까
| 구분 | Hobbyist (무료) | Professional (유료) |
|---|---|---|
| 자동 가로채기 | 지원하는 모든 대상 | 동일 |
| 요청·응답 보기, 필터, 고정 | 가능 | 가능 + 사용자 정의 필터 별칭 |
| 수동 수정(브레이크포인트) | 가능 | 가능 |
| 자동 규칙(가짜 응답, 리다이렉트, 에러·타임아웃 주입) | – | 가능 |
| HAR 가져오기·내보내기, 요청을 코드로 내보내기 | – | 가능 |
| 2,600개 이상 공개 API 문서·검증, 내 OpenAPI 스펙 추가 | – | 가능 |
| TLS 패스스루, 프록시 포트, 상위 프록시 설정 | – | 가능 |
공식 가격 페이지 기준으로 유료는 개인용 Professional과 팀용 Team 두 가지이고, 월간·연간 결제를 고를 수 있으며 연간이 할인됩니다. 가격 페이지가 접속한 지역 통화로 금액을 보여 주는 방식이라 여기엔 금액을 따로 적지 않았습니다. 개인 계정은 여러 기기에서 쓸 수 있지만 한 사람에게 묶여 있어서 공유하면 안 된다고 명시돼 있습니다.
제 기준은 단순합니다. 가끔 요청을 들여다보는 정도면 무료로 충분합니다. 같은 가짜 응답을 매번 손으로 만들고 있거나, 팀원에게 문제 상황을 HAR 파일로 넘겨야 하거나, Stripe·GitHub 같은 외부 API 응답이 스펙에 맞는지 자동으로 검증받고 싶다면 그때 Pro를 검토합니다. 오픈소스 프로젝트를 후원하는 의미도 있습니다.
1인 개발자가 실제로 쓰는 상황 다섯 가지
- 웹훅 디버깅: 로컬에서 결제 대행사 SDK가 보내는 요청과 응답을 보며 키나 파라미터 실수를 찾습니다. 웹훅 중복 처리 같은 구조 문제는 바이브 코딩 앱 프로덕션 가이드에 따로 적었습니다.
- AI가 짠 코드 확인: AI 코딩 도구가 만든 API 호출 코드는 그럴듯해 보여도 헤더 하나, 필드 이름 하나가 틀린 경우가 많습니다. 실제로 나가는 요청을 보면 몇 초 만에 확인됩니다.
- 장애 상황 연습: 외부 API가 느려지거나 500을 돌려줄 때 내 앱이 어떻게 반응하는지 일부러 만들어 봅니다.
- 프런트·백엔드 책임 가르기: 버그가 났을 때 요청이 잘못 나갔는지, 응답이 잘못 왔는지를 화면 하나로 가릅니다.
- 리버스 프록시 설정 확인: 앞단 서버가 헤더를 제대로 넘기는지 볼 때도 씁니다. 웹 서버 설정은 Caddy 웹서버 가이드를 참고하세요.
쓰면서 조심할 점
- 가로챈 요청에는 토큰, 쿠키, 개인정보가 그대로 보입니다. 화면 공유나 스크린샷을 할 때 조심하고, HAR 파일을 남에게 넘길 때는 민감한 헤더를 지우세요.
- HTTP Toolkit이 만든 인증서는 내 컴퓨터에서만 쓰는 테스트용입니다. 개발이 끝나면 설정을 원래대로 돌려 두는 습관이 좋습니다.
- 인증서 고정(certificate pinning)을 쓰는 앱은 일반적인 방법으로는 HTTPS 내용을 볼 수 없습니다. 내 앱이라면 디버그 빌드에서만 고정을 풀어 두는 식으로 해결합니다.
- 회사 네트워크에서는 프록시·인증서 설치가 보안 정책에 걸릴 수 있으니 먼저 확인하세요.
자주 묻는 질문
HTTP Toolkit 무료로 쓸 수 있나요?
네. 가로채기, 요청·응답 보기, 필터, 수동 수정, 요청 보내기까지는 무료이고 핵심 코드는 오픈소스입니다. 자동 규칙, HAR 내보내기, API 검증 같은 고급 기능이 유료입니다.
Charles나 Fiddler와 뭐가 다른가요?
가장 큰 차이는 자동 설정입니다. 브라우저, 터미널, 도커, 안드로이드를 버튼 하나로 연결해서 프록시와 인증서를 손으로 맞추는 시간이 줄어듭니다. 이미 Charles 설정에 익숙하고 그걸로 충분하다면 굳이 갈아탈 이유는 크지 않습니다.
HTTPS 내용이 안 보여요.
대부분 인증서 신뢰 문제입니다. 자동 설정 대상이면 다시 연결해 보고, 수동 설정이라면 인증서를 해당 프로그램이 믿도록 설정했는지 확인하세요. 안드로이드 앱은 앞에서 말한 네트워크 보안 설정이 필요합니다.
iOS 앱도 되나요?
iOS는 안드로이드처럼 버튼 한 번으로 연결되는 방식이 아니라, 기기의 프록시 설정과 인증서 신뢰를 직접 맞추는 수동 방식에 가깝습니다. 설정 방법은 앞의 “자동 설정이 없는 프로그램” 흐름과 같습니다.
localhost로 보내는 요청도 보이나요?
상황에 따라 다릅니다. 많은 HTTP 클라이언트가 localhost나 127.0.0.1로 가는 요청은 프록시를 거치지 않고 바로 보내도록 돼 있어서, 로컬 서비스끼리 주고받는 요청은 목록에 안 찍히는 경우가 있습니다. 이럴 때는 내 컴퓨터의 다른 호스트 이름을 쓰거나, 클라이언트 설정에서 프록시 예외 목록을 확인해 보세요. 반대로 외부로 나가는 요청은 대부분 문제없이 잡힙니다.
정리하면
HTTP Toolkit은 “실제로 무슨 요청이 오가는지”를 가장 빨리 보여 주는 도구입니다. 처음엔 Chrome 카드와 Fresh Terminal 두 개만 써 봐도 디버깅 시간이 눈에 띄게 줄어듭니다. 거기에 브레이크포인트로 응답을 일부러 망가뜨려 보는 습관까지 붙이면, 출시 전에 놓치기 쉬운 에러 처리와 권한 구멍을 상당히 미리 잡을 수 있습니다. 출시 전에 함께 보면 좋은 글은 1인 창업 AI 도구 가이드에 모아 두었습니다.