QA를 진행하다 보면 간혹 "프록시 서버?", "리버스 프록시 서버?"와 같은 단어들을 마주하게 된다. 최근에는 API 자동화에 관심을 갖게 되면서 API를 확인하는 방법을 위해 프록시 변경?을 하는 팀원을 보며 프록시가 대체 뭐길래? 라는 의문이 들어, API 자동화에 한 걸음 더 다가가기 위해 이번에 한 번 학습해 보기로 한다.
프록시(Proxy)란 무엇일까?
프록시는 번역을 하면 대리, 대리인이라는 뜻을 갖는다. 무엇인가를 대신하는 놈이구나를 알 수 있다. 흔히 들리는 프록시 서버는 결국 무엇인가를 대신하는 서버구나라고 이해할 수 있다.
위키백과에서는 ”클라이언트가 자신을 통해서 다른 네트워크 서비스에 간접적으로 접속할 수 있게 해 주는 컴퓨터 시스템이나 응용 프로그램” 라고 하는데, 예시로 클라이언트와 Web 서버 중간에서 통신을 주고 받아주는 중계 기능을 하는 것이 프록시 서버이다.
프록시 서버는 왜 사용하는 것일까?
그렇다면 클라이언트가 서버와 직접 통신하면 될 것을 왜 프록시 서버를 통해 중간 단계를 거치는 걸까? 바로 보안을 강화하기 위함이다.
익명성 : 서버가 직접 요청하는 것이 아닌 프록시 서버가 대신 리소스를 요청
보안성과 안정성 : 향상 직접적으로 통신하지 않음
캐싱 : 중복 요청에 대해 서버에 다시 요청하지 않고 프록시 서버의 캐싱 데이터를 활용하여 빠르게 응답, 서버의 불필요한 부하 감소
프록시 종류
프록시에도 종류가 여러가지가 존재하지만 이번에는 대표적인 정방향 프록시와 역방향 프록시에 대해 알아보자.
정방향 프록시(포워드 프록시, Forward Proxy)
: 클라이언트가 서버에 요청을 보낼 때, 요청을 중간에서 가로채고 이를 대신 서버로 전달하는 역할을 하는 서버입니다. 클라이언트의 요청을 처리하지만, 서버는 프록시 서버만 인식하고 클라이언트는 알지 못한다.
익명화 : 클라이언트의 IP 주소를 숨기기 위해 사용
인터넷 필터링 : 기업이나 학교에서 외부 인터넷 접근을 제한하기 위해 사용
역방향 프록시(역방향 프록시, Reverse Proxy)
: 클라이언트의 요청을 받아서, 이를 적절한 내부 서버로 전달하는 프록시 서버입니다. 클라이언트는 실제 서버를 알지 못하고, 오직 역방향 프록시 서버만 알 수 있다.
로드 밸런싱: 여러 서버 간에 트래픽을 분산시켜 부하를 균등하게 분배
캐싱: 자주 요청되는 콘텐츠를 캐시하여, 내부 서버의 부하를 줄이고 응답 속도를 향상
QA에서 어떤 경우 활용될까?
API 자동화를 진행한다면 어떤 API를 주고 받는지 네트워크 트래픽을 분석하는 것이 필요하다. 웹에서는 크롬의 개발자 도구를 사용하여 트래픽 분석이 가능하고 프록시 서버를 사용한다면 웹뿐만 아니라 앱에 대한 네트워크 요청을 모두 추적할 수 있다.
앱의 화면 A에서 화면 B로 넘어갈 때, 화면 B에 필요한 데이터를 서버에서 받아오기 위해 API를 호출한다. 이때, 앱과 서버 간의 트래픽을 가로채고 분석할 수 있는 프록시 서버를 사용해야 한다. 예를 들어, Wireshark 같은 도구나 Fiddler, Charles Proxy 같은 프록시 서버를 사용하면, 앱이 호출하는 API를 실시간으로 모니터링하고 어떤 API가 호출됐는지, 그에 대한 응답은 어땠는지 확인할 수 있다.