클라이언트 서버 역할 구분과 VPN의 네트워크 개입 방식 이해하기

클라이언트-서버 구조 한 장으로 잡기: 누가 누구랑 대화하죠?

클라이언트/서버 구조는 생각보다 단순해요. “요청하는 쪽”이 클라이언트, “항상 켜져 있으면서 응답하는 쪽”이 서버거든요. 웹브라우저(클라이언트)가 웹서버에 “이 페이지 주세요”라고 말하면, 서버가 “여기요” 하고 돌려주는 식이죠. 서버는 다수의 클라이언트를 상대로 24시간 서비스하도록 설계되고, 클라이언트는 사용자의 행동에 맞춰 요청을 던지는 역할이라는 설명이 자료에 따르면 핵심입니다(자료 3에 따르면).

제가 2021년에 국내 쇼핑몰 트래픽 장애 대응을 도와드릴 때도, “서버가 죽었다”가 아니라 사실은 특정 클라이언트 요청이 폭주해서 서버가 숨이 턱 막힌 케이스가 꽤 많았거든요.

여기서 중요한 포인트 하나: 클라이언트와 서버는 “프로그램 역할”이에요. 같은 PC라도 어떤 앱을 돌리느냐에 따라 클라이언트가 되기도, 서버가 되기도 합니다.

실무에서 이 개념이 중요한 이유는, 장애나 보안 사고가 났을 때 “누가 요청했고(클라이언트), 누가 응답했는지(서버)” 역할을 먼저 정리해야 로그도, 방화벽 정책도, 원인 분석도 안 헛다리 짚거든요.

VPN은 어디에 끼어드나: “앱”이 아니라 “네트워크 길목”에요

VPN을 한마디로 비유하면, 내 집(클라이언트)에서 회사(사설망/서버들)로 가는 “전용 터널”을 인터넷 위에 임시로 까는 느낌이에요. 핵심은 VPN이 보통 네트워크 계층에서 동작하면서, 내 트래픽을 “캡슐화(포장)”하고 “암호화(잠금)”해서 터널로 보내준다는 점입니다(자료 2에 따르면). 그래서 웹브라우저 같은 개별 앱이 뭔가를 특별히 바꾸지 않아도, 운영체제/클라이언트 VPN이 “나가는 패킷”을 중간에서 받아 터널로 넣어버릴 수 있어요.

정리하면 VPN의 개입 지점은 대개 이런 순서입니다.

• 앱(브라우저, 메신저 등)이 서버로 보내려는 데이터를 생성

• 운영체제의 네트워크 스택(통신 처리 구간)에서 VPN 클라이언트가 패킷을 가로채 포장/암호화

• 포장된 패킷이 인터넷을 통해 VPN 서버로 이동

• VPN 서버가 포장을 풀고, 원래 목적지 서버로 대신 전달

즉, “클라이언트 앱 ↔ 원격 서버” 사이에 “VPN 클라이언트 ↔ VPN 서버”라는 한 겹이 더 생기고, 그 사이가 터널이 되는 구조라고 보시면 됩니다.

실제 통신 흐름 2가지: VPN을 쓰면 서버는 누굴 보나요?

여기서 독자분들이 제일 헷갈리는 지점이 “그럼 서버는 내 IP를 보나요, VPN IP를 보나요?”잖아요. 답은 “어떤 방식의 VPN이냐에 따라 달라요”인데요, 흔히 쓰는 전형적인 VPN(클라이언트-투-사이트, 또는 상용 VPN)은 보통 서버가 VPN 서버의 IP를 보게 됩니다. 왜냐면 내 트래픽이 VPN 서버를 거쳐 “대리로” 나가니까요. VPN이 사용자 트래픽을 암호화하고 VPN 서버의 IP로 접속하게 만들어 익명성을 제공한다는 설명이 자료에 있습니다(자료 4에 따르면).

참고로 이런 “터널링으로 캡슐화해서 운반한다”는 큰 틀은 IETF 표준 문서인 RFC 4301(IPsec 아키텍처) 같은 데서도 기본 개념으로 다루는 방식이기도 해요.

1) 전형적인 VPN(터널이 ‘모든 트래픽’을 감싸는 경우)

• 내 PC/폰 → (암호화 터널) → VPN 서버 → 목적지 서버

• 목적지 서버 입장: 접속자는 VPN 서버처럼 보임

• 내 ISP(통신사) 입장: “VPN 서버랑 암호화 통신”하는 것까지만 보임(안쪽 목적지는 잘 안 보임)

2) “VPN처럼 보이지만” 실제로는 일부만 건드리는 경우(오해 포인트)

요즘은 앱이나 OS 기능으로 “DNS만 암호화”하거나 “패킷을 변조/파편화”해서 우회 비슷하게 하는 도구도 있거든요. 이런 방식은 말 그대로 일부 트래픽만 손보는 거라, 실제 웹사이트 서버와의 본 통신이 VPN 서버를 경유하지 않을 수 있어요. 나무위키 자료에 따르면 특정 도구/옵션은 DNS 쿼리만 TLS로 암호화하거나 패킷을 변조할 뿐, 사이트 서버와의 통신 자체가 별도 VPN 서버를 거치지 않아 사용자 IP가 그대로 전달된다고 되어 있습니다(자료 1에 따르면).

그러니까 “VPN 켰는데도 내 IP가 그대로 보이네?” 같은 상황이 생기면, 진짜 풀터널 VPN인지, 일부만 처리하는 방식인지부터 의심해보는 게 순서예요.

클라이언트-투-사이트(Client-to-Site)에서 VPN이 특히 빛나는 자리

VPN 종류가 여러 가지지만, 일반 사용자가 체감하기 쉬운 건 “클라이언트-투-사이트”예요. 내 노트북/폰(클라이언트)이 회사 네트워크(사이트)에 안전하게 들어가는 시나리오죠. IBM Cloud 문서도 클라이언트-투-사이트 VPN 서버 개념을 별도로 설명할 만큼, 기업 환경에서 흔한 패턴입니다(자료 5에 따르면).

이 구조에서 VPN은 단순히 “익명화”가 아니라, 접근 제어(누가 들어올 수 있나), 인증(너 누구냐), 무결성(중간에 바뀌었나), 기밀성(내용 숨김) 같은 보안 요구를 묶어서 해결하는 문지기 역할에 가깝습니다. 집 열쇠(인증) 확인하고, 소포(데이터) 봉인 상태(무결성) 확인하고, 내용은 포장지로 가려서(기밀성) 들여보내는 느낌이죠.

흔한 오해 4가지: “VPN이면 다 같은 VPN”이 아니에요

1) “VPN 켜면 모든 앱 트래픽이 무조건 VPN으로 간다”

환경마다 다를 수 있어요. 분할 터널링(일부는 VPN, 일부는 직접) 설정이면 특정 트래픽만 터널로 보낼 수 있습니다. 특히 기업 VPN에서 내부망만 VPN으로, 나머지는 로컬 인터넷으로 보내는 경우가 있어요.

2) “VPN은 무조건 익명이다”

전형적인 상용 VPN은 목적지 서버에 내 IP 대신 VPN 서버 IP가 보이게 할 수 있지만(자료 4 취지), “DNS만 암호화” 같은 방식은 IP가 그대로 노출될 수 있습니다(자료 1 취지). 그리고 VPN 사업자/기업 VPN 장비 쪽에는 접속 기록이 남을 수도 있으니, 익명성은 “상대가 누구냐”에 따라 달라져요.

3) “VPN은 브라우저 설정이다”

대부분은 운영체제 네트워크 계층에서 처리합니다(자료 2 취지). 브라우저 확장 프로그램 형태는 보통 브라우저 트래픽만 프록시처럼 우회하는 경우가 많아, OS 전체 VPN과는 성격이 다를 수 있어요.

4) “VPN 쓰면 무조건 더 빠르다”

보안 터널은 포장/암호화/경유가 들어가서 오버헤드가 생깁니다. 다만 ISP 경로 문제를 우회해 “체감상 빨라지는” 경우도 있어요. 이건 네트워크 경로/서버 위치/혼잡도에 따라 달라집니다.

마무리: VPN은 “클라이언트와 서버 사이의 길목”을 바꾸는 기술

다만, 이 글에서 말하는 VPN 동작 방식은 일반적인 풀터널/클라이언트-투-사이트 기준이라서, 분할 터널링이나 프록시/브라우저 확장처럼 변형된 구성에선 결과가 달라질 수 있습니다.

클라이언트-서버 구조에서 VPN이 개입하는 지점은 앱 자체가 아니라, 내 기기에서 나가는 네트워크 패킷이 지나가는 “길목”이에요. 전형적인 VPN은 내 트래픽을 암호화해 VPN 서버까지 터널로 보내고, 그 다음 VPN 서버가 목적지 서버로 전달하면서 IP도 VPN 쪽으로 보이게 만들 수 있습니다(자료 4, 자료 2 취지). 반대로 “VPN처럼 보이는” 일부 도구는 DNS만 암호화하거나 변조만 해서, 실제 접속은 목적지로 직행하며 IP도 그대로일 수 있고요(자료 1 취지).

한 줄 정리하면 이거예요: VPN은 “클라이언트와 서버의 대화 내용”을 바꾸기보다, 그 대화가 지나가는 “통신 경로와 포장 방식”을 바꾸는 기술입니다.

주제 컨텍스트

클라이언트와 서버 구조: VPN은 어디에 개입할까