[WebProxy] 프록시 서버 제대로 알고 시작하기

프록시 서버 제대로 알고 구현하기

Tiny 서버 숙제를 마쳤다면 다음 목표는 대망의 WebProxy 서버를 구현할 차례입니다. 하지만 '프록시 서버 = 동시성 서버'라고 막연히 생각하고 시작하면 구현 방향이 흐려질 수 있는데요. 이 글에서는 프록시 서버가 무엇인지를 먼저 이해하고, 구현 로드맵을 단계별로 정리해 봅니다.

 

 

프록시 서버란 무엇인가?

프록시 서버는 클라이언트와 원 서버(origin server) 사이에서 요청과 응답을 중계하는 중간 서버입니다. 즉, 클라이언트의 요청을 대신 서버에 전달하고, 서버의 응답을 받아 다시 클라이언트에게 전달해주는 역할을 하지요.

 

이러한 구조 덕분에 프록시 서버는 단순 중계 이상의 기능을 수행할 수 있습니다. 예를 들어, 자주 요청되는 데이터를 캐싱해 서버의 부하를 줄이거나, 특정 요청을 필터링하거나 로깅하는 등의 부가적인 기능도 함께 제공할 수 있습니다. 익명화, 로드 밸런싱 보조, 보안 기능 강화도 프록시가 확장 가능한 부분입니다.

 

결국 프록시 서버의 본질은 중개 기능이라는 점인데요. 동시성은 이를 어떤 방식으로 구현할 것인가의 문제일 뿐, 프록시의 정의 자체에는 포함되지 않습니다.

 

 

프록시 서버는 동시성 서버가 아니다

프록시 서버를 구현한다고 했을 때, 곧바로 '동시성(concurrency)' 개념으로 연결하는 경우가 많습니다. 하지만 프록시와 동시성은 전혀 다른 관점입니다.

 

프록시는 무엇을 하는가에 대한 개념입니다. 요청을 받아 중개하고, 응답을 다시 전달하는 것이 주 역할입니다. 반면, 동시성은 그 요청들을 어떻게 처리할 것인가에 대한 구현 전략입니다.

 

즉, 프록시 서버는 하나의 요청만 처리하는 반복형(iterative) 구조일 수도 있고, 여러 요청을 동시에 처리할 수 있도록 스레드나 이벤트 기반으로 구현될 수도 있습니다. 동시성은 선택사항일 뿐, 프록시 구현의 본질은 아닌 것이죠.

 

결국 우리가 구현해야 할 것은 프록시의 동작 흐름을 정확히 구현한 서버입니다. 그리고 그 위에 성능 향상을 위한 동시성 구현은 이후에 고려할 수 있는 확장입니다.

 

그렇다면 동시성은 어디에 적용되는가?

많은 분들이 혼동하는 부분이 바로 이 부분인데요. “동시성 서버로 만든다는 건 Tiny 서버(원 서버)를 동시성으로 바꾸는 것인가?”

 

정답은 아닙니다. 동시성을 적용하는 대상은 우리가 구현하는 프록시 서버입니다. Tiny 서버는 단지 테스트 대상일 뿐이며, 프록시의 요청을 처리하는 서버로 그대로 두어도 상관없습니다.

 

프록시에 동시성을 도입하면, 여러 클라이언트가 동시에 프록시에 접속해도 각각의 요청을 병렬로 처리할 수 있게 됩니다. 즉, 프록시가 각 클라이언트의 요청을 별도 스레드 혹은 이벤트 루프에서 처리하면서 동시에 여러 개의 서버 요청을 발생시킬 수 있게 되는 것이죠.

 

반대로 프록시에 동시성이 없으면, 한 클라이언트의 요청이 끝나기 전까지는 다른 클라이언트의 요청을 처리하지 못해 전체 응답 지연이 생깁니다. 즉, 동시성은 프록시에서 발생할 수 있는 병목을 해소하기 위한 구현 전략이며, 원 서버의 구조와는 무관합니다.

 

 

단계별 구현 로드맵 (채점 기준 기반)

프록시 서버 구현은 단순히 '동작'만 하는 것이 아니라, 최종적으로는 driver.sh 스크립트를 통해 총 70점 만점을 받는 것이 목표인데요. 아래는 각 기능이 어떤 점수와 연결되는지를 기준으로 한 구현 단계입니다.

 

1단계: 반복형 프록시(기본 기능) 구현 (최대 40점)

프록시는 클라이언트의 요청을 받아 원 서버(Tiny)로 전달하고, 응답을 다시 클라이언트에게 돌려보내는 기본적인 중계 역할을 수행해야 합니다. 텍스트 파일뿐 아니라 이미지 및 바이너리 파일도 정확하게 처리되어야 하며, 파일의 내용이 원본과 완전히 일치해야 하죠.

 

driver.sh는 5개의 파일을 기준으로 diff를 수행해 정확도를 평가합니다.

• 점수: 파일당 8점 × 5개 파일 = 최대 40점
• 성공 조건: 모든 파일을 정확하게 전달할 경우 basicScore: 40/40

 

2단계: 동시성 구현 (최대 15점)

동시성은 프록시가 여러 클라이언트의 요청을 동시에 처리할 수 있어야 함을 의미하는데요. 예를 들어, 한 요청이 오래 걸리더라도 다른 요청이 차단되지 않고 처리되어야 합니다. 일반적으로는 pthread를 사용한 스레드 기반 구현이 가장 보편적입니다.

 

driver.sh는 응답을 보내지 않는 nop-server.py를 이용해 프록시가 블로킹되는지를 테스트합니다.

• 점수: 최대 15점
• 성공 조건: 블로킹되지 않고 병렬 처리되면 concurrencyScore: 15/15

 

3단계: 캐시 구현 (최대 15점)

한 번 요청된 정적 파일을 메모리에 저장하고, 서버가 죽은 후에도 해당 파일을 캐시에서 제공할 수 있어야 합니다. 프록시는 서버가 없는 상태에서도 응답을 제공해야 하며, 이때의 응답 내용은 원본과 일치해야 하죠.

 

driver.sh는 Tiny를 종료한 후, 동일한 요청을 다시 프록시로 보내어 캐시에서 제공되는지 테스트합니다.

• 점수: 최대 15점
• 성공 조건: 캐시에서 정확한 응답을 제공할 경우 cacheScore: 15/15

 

총점 계산

• 기본 기능: 40점
• 동시성: 15점
• 캐싱: 15점
• 총점: 70점

이러한 채점 기준을 염두에 두고 구현 순서를 정하면 디버깅 방향이 명확해지고, 각 단계에서의 성공 여부도 판단하기 쉬워집니다.

 

 

마치면서

프록시 서버 구현은 “동시에 수많은 클라이언트를 처리해야 한다”는 압박감에서 출발하기 쉽습니다. 그러나 첫걸음은 동시성이 아니라, 프록시 본연의 흐름을 정확히 구현하는 일입니다. 기능을 먼저 구현하고, 그 위에 성능과 확장성을 쌓아올리는 것이 가장 좋은 학습 순서입니다.

 

다음 글에서는 1단계 ‘반복형 프록시’를 실제 코드로 살펴보고, Tiny 서버 코드와 어떻게 접목시키는지 설명해 볼 예정입니다. 읽어주셔서 감사합니다.