Hacker News 2026.06.08 65

브라우저 네트워크 트래픽을 직접 들여다보고 바꿔치기까지 — Oproxy 써봤어요

네트워크 디버깅, 매번 번거로웠죠

웹 개발하다 보면 "이 요청이 서버로 정확히 뭘 보내고 있지?", "응답이 이렇게 오면 화면이 어떻게 바뀔까?" 하고 궁금할 때가 정말 많아요. 보통은 브라우저 개발자 도구의 네트워크 탭을 보거나, Charles Proxy나 Fiddler 같은 별도 프로그램을 깔아서 들여다보죠. 그런데 이런 도구들은 설치도 해야 하고, 시스템 프록시 설정을 건드려야 하고, HTTPS를 까보려면 인증서까지 깔아야 해서 처음 쓰는 사람한테는 진입 장벽이 좀 있어요.

오늘 소개할 Oproxy는 이런 트래픽 들여다보기를 좀 더 가볍게 하려는 도구예요. 이름 그대로 프록시(proxy), 그러니까 나와 서버 사이에 끼어서 오가는 데이터를 중계하면서 보여주는 역할을 해요. 핵심은 단순히 "보는" 데서 그치지 않고 오가는 트래픽을 그 자리에서 수정(modify)할 수 있다는 점이에요.

프록시가 뭔지부터 쉽게

프록시가 뭐냐면, 중간에서 편지를 대신 전달해주는 우체국 직원 같은 거예요. 내 브라우저가 서버한테 편지(요청)를 보내면, 그 편지가 곧장 가는 게 아니라 프록시를 거쳐 가요. 프록시는 편지 내용을 열어볼 수도 있고, 심지어 "이 부분만 살짝 고쳐서 보낼게" 하고 내용을 바꿔서 전달할 수도 있어요. 서버가 답장을 보낼 때도 마찬가지고요. 이렇게 중간에 끼어 있으니 오가는 모든 내용을 관찰하고 손댈 수 있는 거죠.

Oproxy는 이 중간자 역할을 하면서, 들어온 요청과 응답을 보기 좋게 정리해서 보여줘요. 그리고 규칙을 걸어서 특정 요청의 헤더를 바꾸거나, 응답 본문을 가짜 데이터로 바꿔치기하는 것도 할 수 있어요.

이게 실무에서 왜 유용하냐면

첫째, 에러 상황 테스트에 정말 좋아요. 백엔드가 아직 500 에러를 안 내주는데 "서버가 터졌을 때 우리 화면이 어떻게 보이지?"를 확인하고 싶을 때가 있잖아요. 이럴 때 응답을 강제로 500으로 바꿔치기하면, 백엔드 도움 없이도 에러 화면을 바로 테스트할 수 있어요.

둘째, 응답 데이터 조작으로 프론트엔드를 미리 만들 수 있어요. 아직 API가 빈 배열만 주는데 데이터가 100개 왔을 때 목록이 어떻게 보일지 보고 싶다? 응답을 가짜 데이터로 바꿔서 흘려보내면 돼요. 목(mock) 서버를 따로 안 띄워도 되니 편하죠.

셋째, 느린 네트워크 흉내나 특정 요청 차단 같은 것도 가능해서, 모바일 환경처럼 불안정한 상황을 책상 앞에서 재현해볼 수 있어요.

비슷한 도구들과 비교하면

이 분야엔 이미 강자들이 많아요. 데스크톱 쪽엔 Charles Proxy(유료), 오픈소스 Fiddler/mitmproxy가 있고, 브라우저 확장으로는 Requestly나 ModHeader 같은 게 있죠. mitmproxy는 강력하지만 터미널과 파이썬에 익숙해야 제맛이 나고, Charles는 편하지만 유료예요. Oproxy처럼 가볍게 설치해서 트래픽을 보고 바로 수정까지 한다는 콘셉트는, 이 중간 어딘가의 빈틈을 노리는 거예요. "무겁지 않으면서도 수정 기능은 확실히 되는" 자리를 차지하려는 거죠.

물론 mitmproxy 같은 성숙한 도구의 방대한 기능을 단번에 따라잡긴 어려워요. 하지만 "내 흔한 작업 90%는 이걸로 충분해" 수준만 잘 잡아도 충분히 손이 가는 도구가 될 수 있어요. 도구는 기능 개수보다 손에 익는 속도가 중요할 때가 많거든요.

한국 개발자에게

프론트엔드 개발자라면 한 번쯤 써볼 만해요. 특히 백엔드와 병렬로 작업할 때, API가 아직 안 나왔거나 에러 케이스를 재현하기 어려울 때 진가를 발휘하거든요. QA 엔지니어 분들께도 유용해요. 다양한 응답 시나리오를 코드 수정 없이 만들어낼 수 있으니까요.

다만 트래픽을 가로채고 수정하는 도구는 본질적으로 보안에 민감해요. 회사 정책상 사내 트래픽을 가로채면 안 되는 경우도 있고, HTTPS 복호화를 위해 인증서를 까는 건 신중해야 해요. 개인 개발이나 테스트 환경에서 먼저 익히고, 회사에 적용할 땐 보안 가이드를 꼭 확인하세요.