WireGuard vs OpenVPN: 자가 호스팅 VPN 선택 가이드

간단한 답변

개인 VPS에서 VPN 서버를 운영하는 사용자에게 WireGuard와 OpenVPN 중 하나를 선택하는 것은 고민할 필요도 없는 문제입니다. WireGuard를 선택하십시오. WireGuard는 더 가볍고, Linux 커널 내부에서 동작하며, 연결 속도가 1초 미만이고, 작동하는 클라이언트 설정 파일도 10줄 내외입니다. OpenVPN은 네 가지 특수한 목적을 수행하며, 이 중 본인에게 필요한 것이 없다면 굳이 사용할 이유가 없습니다.

그 네 가지 목적은 TCP 443 포트만 허용하는 네트워크 환경에서의 통신, 기존 인증 기관(CA)과의 연동, 비밀번호나 2단계 인증을 통한 사용자 식별, 그리고 Layer 2 브리징입니다. 아래 내용은 이 권장 사항의 근거이며, 각 예외 상황이 본인에게 적용되는 시점을 설명합니다.

WireGuard가 자가 호스팅 사용자에게 선택받은 이유

코드베이스가 읽을 수 있을 만큼 작습니다. WireGuard 프로젝트의 프로토콜 구현은 약 4,000줄의 코드로 구성됩니다. OpenVPN은 암호화 작업을 위해 의존하는 OpenSSL 라이브러리까지 포함하면 10만 줄이 넘습니다. 코드 크기가 중요한 이유는 모든 줄이 공격 표면이 되기 때문이며, 사용자나 검토자가 100,000줄을 모두 읽을 수는 없기 때문입니다. 4,000줄이라면 읽을 수 있습니다.

커널에서 실행됩니다. WireGuard는 5.6 버전부터 Linux 메인라인에 포함되었으므로, Ubuntu 24.04나 Debian 13은 별도의 컴파일 없이 이를 기본 제공합니다. 패킷은 커널 공간에서 암호화되므로 사용자 공간 프로세스로 복사할 필요가 없습니다. 가장 먼저 다음 명령으로 확인하십시오.

sudo modprobe wireguard && echo ok

KVM VPS에서는 ok가 출력됩니다. OpenVZ나 LXC처럼 호스트 커널을 공유하는 컨테이너 가상화 환경에서는 Operation not supported 오류가 발생합니다. 자신의 커널이 아니므로 모듈을 로드할 수 없기 때문입니다.

협상 과정이 없습니다. WireGuard는 데이터 암호화에 ChaCha20-Poly1305, 키 교환에 Curve25519라는 단일 암호화 제품군을 사용합니다. 버전을 낮추거나(downgrade) 잘못 설정할 옵션 자체가 없습니다. OpenVPN은 클라이언트와 연결할 때마다 암호화 방식과 TLS(transport layer security) 버전을 협상하는데, 이는 유연성을 제공하지만 동시에 잘못된 설정이 발생할 여지가 됩니다. data-ciphers AES-256-GCM:AES-128-CBC 설정이 남은 서버는 더 나은 암호화 방식을 지원하지 않는 클라이언트를 위해 기꺼이 CBC 암호화로 전환하며, 로그에는 이를 문제로 기록하지 않습니다.

포트가 응답하지 않습니다. WireGuard 패킷은 메시지 인증 확인에 실패하면 아무런 응답 없이 폐기됩니다. 따라서 무언가 실행 중인지 여부와 관계없이 nmap -sU -p 51820은 open|filtered를 반환합니다. TCP 모드의 OpenVPN 서버는 연결을 거부하기 전에 TCP 핸드셰이크를 완료하므로, 스캐너에게 서버가 존재한다는 사실을 증명하게 됩니다. tls-crypt을 사용하는 UDP 기반 OpenVPN은 거의 조용하게 작동하므로, 이는 OpenVPN 자체에 대한 비판이라기보다 TCP에서 OpenVPN을 실행하는 것에 대한 반론입니다.

로밍이 자유롭습니다. WireGuard 피어는 주소가 아닌 공개 키로 식별됩니다. 노트북을 집에서 모바일 핫스팟으로 옮기면, 새로운 주소에서 핸드셰이크를 한 번 보내는 것만으로 서버가 응답할 엔드포인트를 업데이트합니다. 연결된 상태가 아니었으므로 다시 연결할 필요도 없습니다. OpenVPN도 float을 통해 유사한 기능을 수행할 수 있지만, 일반적으로 클라이언트가 전체 TLS 세션을 종료하고 다시 구축해야 합니다. 이것이 OpenVPN에서는 노트북 덮개를 열 때 지연이 느껴지고 WireGuard에서는 그렇지 않은 이유입니다.

2026년의 속도: 격차는 좁혀졌다

수년간 OpenVPN의 속도에 관한 정직한 논점은, OpenVPN은 모든 패킷을 유저스페이스로 복사하여 암호화한 뒤 다시 복사하는 반면, WireGuard는 커널을 벗어나지 않는다는 것이었습니다. 이제는 이것이 전체 상황을 대변하지 않으며, 이를 무시한 비교는 구식입니다.

OpenVPN 2.7은 2026년 2월에 출시되었으며, Linux 6.16에 병합된 업스트림 ovpn 커널 모듈을 지원합니다. 이것이 DCO(data channel offload)입니다. 제어 채널은 유저스페이스에 머물고 대량 데이터 경로는 커널로 이동하는데, 이는 WireGuard가 항상 수행해 온 방식과 거의 같습니다. 이를 사용할 수 있을 만큼 최신 버전의 커널과 OpenVPN을 사용한다면, 처리량은 서로 다른 등급이 아닌 같은 등급에 속합니다. 현재 사용 중인 환경을 확인하십시오:

uname -r
openvpn --version | head -n 1
modinfo ovpn 2>/dev/null | head -n 3

2026년 7월 기준으로 기본 Ubuntu 24.04 LTS는 OpenVPN 2.7이 아닌 2.6을 제공하며, ovpn 모듈은 2.7을 필요로 합니다. 해당 릴리스에서는 실행 중인 커널에 맞춰 아웃오브트리(out-of-tree) 모듈을 빌드하고 커널 업그레이드마다 재빌드해야 하는 구형 openvpn-dco-dkms 패키지를 통해서만 오프로드를 사용할 수 있습니다. 이는 WireGuard에는 없는 가변적인 요소입니다.

DCO를 계속 사용해야 할 이유로 꼽기 전에 세부 사항을 확인하십시오. DCO는 Layer 3 터널만 지원하며, AEAD 암호(AES-GCM 또는 ChaCha20-Poly1305와 같은 인증된 암호화)만 허용하고, 압축을 지원하지 않으며, 서버에서는 topology subnet와만 작동합니다. 이러한 제약 사항 하나하나가 애초에 OpenVPN의 장점이었던 유연성을 훼손합니다. 빠른 OpenVPN이란 WireGuard처럼 보이도록 설정된 OpenVPN을 의미합니다.

이 페이지를 포함하여 누군가가 게시한 처리량 수치를 맹신하지 마십시오. VPS의 성능 한계는 보통 프로토콜보다는 CPU 할당량이나 네트워크 대역폭에 의해 결정됩니다. 터널을 통과하는 iperf3으로 직접 측정하고, 터널 외부에서 다시 측정하여 두 값을 비교하십시오.

OpenVPN이 여전히 유용한 경우

TCP 443 포트를 통해 외부로 나가야 하는 경우. WireGuard는 의도적으로 UDP만 지원하며, 향후에도 TCP 모드를 지원할 계획이 없습니다. TCP 443 포트만 허용하는 호텔 네트워크나 기업용 프록시 환경에서는 proto tcp-server 및 port 443로 설정된 OpenVPN을 사용할 수 있습니다. 해당 트래픽이 일반적인 TLS 세션처럼 보이기 때문입니다. WireGuard로 동일한 네트워크를 통과하려면 wstunnel나 udp2raw 같은 래퍼가 필요한데, 이는 실행하고 패치해야 할 프로세스가 하나 더 늘어난다는 의미입니다. 주의할 점은 충돌 가능성입니다. 해당 IP 주소에서 웹 서버가 이미 TCP 443 포트를 점유하고 있다면, 둘 중 하나는 포트를 변경해야 합니다.

이미 인증 기관(CA)을 운영 중인 경우. OpenVPN은 X.509 인증서로 인증하므로 이미 운영 중인 PKI(공개 키 기반 구조)에 바로 통합할 수 있습니다. 인증서는 자체적으로 만료되며, 서버가 crl-verify을 통해 읽어 들이는 인증서 폐기 목록(CRL)에 추가하여 인증서를 폐기할 수 있습니다. WireGuard에는 인증서, 만료 개념, 폐기 목록이 없습니다. 피어를 제거하려면 서버 설정을 직접 수정하고 다시 불러와야 합니다. 피어가 10개라면 괜찮지만, 감사 요건이 있는 400개 규모의 환경에서는 인증서 모델이 실질적인 관리 효율을 제공합니다.

키뿐만 아니라 사용자 이름 기반의 인증이 필요한 경우. OpenVPN은 auth-user-pass-verify나 openvpn-plugin-auth-pam.so 같은 플러그인을 통해 외부 시스템으로 인증을 위임할 수 있습니다. 이를 통해 LDAP나 일회용 비밀번호(OTP)를 이용한 2단계 인증을 추가합니다. WireGuard는 사용자라는 개념 자체가 없습니다. 설정 파일에 키가 있으면 연결되고, 없으면 연결되지 않습니다. "Sara가 휴대폰에서 코드를 입력해야 한다"는 요구 사항이 있다면, WireGuard만으로는 이를 구현할 수 없습니다.

Layer 2 연결이나 오래된 시스템을 위한 클라이언트가 필요한 경우. dev tap를 사용하는 OpenVPN은 이더넷 프레임을 브리지할 수 있는데, 이는 브로드캐스트 프로토콜이나 구형 LAN 게임에 중요합니다. WireGuard는 오직 Layer 3만 지원하며 앞으로도 그럴 것입니다. 또한 OpenVPN은 WireGuard 앱이 지원되지 않는 하드웨어나 운영 체제용 클라이언트를 보유하고 있습니다. 두 이유 모두 점차 중요성이 줄어들고 있으며, dev tap는 DCO와 호환되지 않으므로 브리지를 선택하면 성능상 손해를 감수해야 합니다.

두 설정 방식의 실제 비용

WireGuard ID 생성은 명령어 한 줄로 완료됩니다. 괄호는 키가 생성되기 전에 파일 모드를 설정하므로 필수적입니다.

(umask 077; wg genkey > private.key)
wg pubkey < private.key > public.key

OpenVPN의 경우 VPN을 운영하는 동안 직접 관리해야 하는 인증 기관(CA)이 필요합니다.

sudo apt install -y easy-rsa
make-cadir ~/openvpn-ca
cd ~/openvpn-ca
./easyrsa init-pki
./easyrsa build-ca
./easyrsa gen-req server nopass
./easyrsa sign-req server server

두 방식 모두 나름의 장단점이 있습니다. CA를 사용하면 인증서 만료와 폐기 기능을 얻지만, 수년간 보호해야 하는 개인 키를 관리해야 하고, 갱신 시점을 기억해야 하며, 키를 분실하면 전체를 재구축해야 하는 비용이 발생합니다. 이러한 기능이 필요하지 않다면 불필요한 비용을 지불하는 셈입니다. 포워딩, NAT(네트워크 주소 변환), 그리고 오후 시간을 허비하게 만드는 핸드셰이크 실패 문제를 포함한 WireGuard의 전체 절차는 VPS에서 WireGuard VPN을 직접 호스팅하는 가이드에서 확인할 수 있습니다.

방화벽 설정 요구 사항

WireGuard는 ListenPort에 명시된 포트에 대해 UDP 인바운드 규칙을 정확히 하나만 필요로 합니다.

sudo ufw allow 51820/udp
sudo ufw status verbose

OpenVPN은 기본적으로 UDP 1194를 사용하며, 해당 경로를 선택했다면 TCP 443을 사용합니다. 두 프로토콜 모두 IP 포워딩을 활성화하고 소스 NAT 규칙을 설정해야 합니다. Linux 시스템은 자신에게 주소 지정되지 않은 패킷을 기본적으로 폐기하기 때문입니다. 이 부분은 두 프로토콜 모두 동일하며, "터널은 연결되지만 인터넷이 되지 않는다"는 문제 보고의 대부분이 여기서 발생합니다. ufw가 생소하다면 VPS에서 ufw 방화벽의 기초부터 시작하십시오. 또한 대부분의 제공업체는 제어판에서 별도의 네트워크 방화벽을 운영한다는 점을 기억해야 합니다. 패킷이 서버에 도달하지 못하면 서버에 추가한 규칙은 아무런 효과가 없습니다. 포트의 개념과 Linux의 포트 리스닝 방식을 이해하면 이러한 점검 과정을 더 빠르게 수행할 수 있습니다.

선택 방법, 한 문단 요약

WireGuard가 해결하지 못하는 구체적인 요구 사항이 없다면 WireGuard를 사용하십시오. 제한적인 네트워크 환경을 우회하기 위해 TCP 443 포트가 필요하다면 OpenVPN을 사용하고, 두 방식을 모두 운영하는 것도 고려해 보십시오. 두 서비스는 서로 다른 포트를 사용하므로 한 서버에서 충돌 없이 공존할 수 있습니다. 사용자별 계정 관리나 2단계 인증이 필요하다면 WireGuard의 기본 기능으로 해결하려 하지 마십시오. 대신 그 위에 인증 계층을 추가하십시오. 자체 호스팅 Headscale 제어 서버는 기반 기술로 WireGuard를 사용하면서, 순수 WireGuard에서는 직접 구현해야 했던 계정 모델, 키 배포, 장치 승인 기능을 제공합니다.

중단 없는 OpenVPN 마이그레이션

변환 과정은 존재하지 않습니다. WireGuard는 인증서 기반이 아니므로 OpenVPN의 PKI를 WireGuard 키로 변환할 수 없습니다. 모든 클라이언트는 서버와 동일한 방식으로 생성된 새로운 키 쌍을 발급받아야 합니다.

서비스를 전환하는 대신 병렬로 마이그레이션하십시오. WireGuard는 UDP 51820 포트에서, OpenVPN은 1194 포트에서 동일한 서버 내에 동시에 실행할 수 있습니다. 따라서 wg0을 시작하고 sudo wg show을 통해 최근 latest handshake가 기록되는지 확인한 다음, 클라이언트를 하나씩 이동하십시오. OpenVPN 피어 목록에 더 이상 접속자가 없으면 sudo systemctl disable --now openvpn-server@server 명령으로 서비스를 중단하십시오. CA 파일을 삭제하면 나중에 취소된 클라이언트를 재구성할 수 없으므로, 확실해질 때까지 CA 파일을 보관하십시오.

한 가지 확실히 이전되지 않는 것은 사용자 이름과 비밀번호 계정, 그리고 그와 관련된 폐기 이력입니다. 기존 서버를 끄기 전에 해당 정보를 어디에 관리할지 미리 결정하십시오.

FAQ

WireGuard가 OpenVPN보다 빠른가요?

기본 Ubuntu 24.04 서버 환경에서는 그렇습니다. WireGuard는 커널 내에서 암호화를 수행하는 반면, OpenVPN 2.6은 모든 패킷을 유저스페이스 프로세스를 거쳐 처리하기 때문에 성능 차이가 큽니다. OpenVPN 2.7과 Linux 6.16의 ovpn 커널 모듈을 사용하면 데이터 경로가 커널로 이동하므로 두 방식의 성능은 비슷한 수준이 됩니다. 블로그에 게시된 수치를 맹신하기보다는 iperf3를 사용하여 터널을 통과하는 실제 성능을 직접 측정하십시오. VPS 환경에서는 보통 CPU 성능이나 대역폭 제한이 병목 현상의 주원인이기 때문입니다.

WireGuard를 TCP 포트 443으로 실행할 수 있나요?

단독으로는 불가능합니다. WireGuard는 설계상 UDP만 지원하며 TCP 모드는 계획에 없습니다. TCP 443 포트만 허용되는 네트워크를 통과해야 한다면 wstunnel이나 udp2raw와 같은 터널로 감싸야 합니다. 이 경우 양쪽 끝단에서 실행하고 관리해야 할 프로세스가 추가됩니다. 해당 제약이 일상적인 작업 환경이라면 proto tcp-server 및 port 443을 사용하는 OpenVPN이 더 간단한 해결책입니다.

OpenVPN은 이제 안전하지 않나요?

그렇지 않습니다. AES-256-GCM과 같은 AEAD 암호화와 tls-crypt이 활성화된 최신 OpenVPN은 여전히 견고한 VPN입니다. WireGuard가 선호되는 이유는 다른 데 있습니다. OpenVPN은 훨씬 더 많은 코드와 옵션을 포함하고 있어, 관리자가 설정을 잘못 구성할 여지가 많습니다. 선택지가 적을수록 잘못된 설정을 할 가능성도 줄어듭니다.

VPS에서 개인용 VPN을 구축한다면 무엇을 선택해야 하나요?

WireGuard를 권장합니다. 장치당 키 쌍 하나, 약 10줄 분량의 설정 파일 하나, UDP 포트 하나만 열면 되며, 핸드셰이크도 시작을 인지하기 전에 완료됩니다. UDP를 차단하는 네트워크에서 자주 접속해야 하거나, 기존의 인증 기관(CA) 또는 사용자 디렉터리와 연동해야 하는 경우에만 OpenVPN을 선택하십시오.