“VDI가 너무 느려요” 하소연하던 DBA에게 OpenVPN 서버를 구축해 준 이야기

“VDI 환경이 있는데 왜 굳이 VPN이 필요하죠?”

올해 초, 새로 들어간 프로젝트에서 TA(Technical Architecture) 담당을 맡았을 때의 일입니다. 어느 날 DBA(데이터베이스 관리자) 한 분이 슬그머니 제 자리로 오시더니 “혹시 내부망에 OpenVPN 서버 하나만 구성해 줄 수 있냐”고 요청하시더군요.

속으로 조금 의아했습니다. 이미 프로젝트룸에는 보안용 가상 데스크톱(VDI) 환경이 짱짱하게 구축되어 있었기 때문입니다. ‘VDI 안에서 DB 툴을 쓰면 될 텐데, 왜 번거롭게 VPN을 또 달라고 하지?’라는 의문이 생겨 이유를 묻자, DBA 분은 깊은 한숨을 쉬며 현장의 진짜 고충을 털어놓으셨습니다.

그 이야기를 듣고 나니 고개가 끄덕여졌습니다. 보안과 업무 효율성 사이에서 줄타기를 하는 건 모든 엔지니어의 숙명이지만, 특히 폐쇄망을 다루는 DBA들에게 VDI는 생각보다 큰 걸림돌이었던 거죠.

이번 글에서는 현직 DBA들이 왜 VDI 대신 OpenVPN 방식을 선호하는지 그 숨겨진 이유를 생생하게 짚어보고, 최근 릴리즈된 RHEL 9.6(Red Hat Enterprise Linux) 환경에서 삽질 없이 OpenVPN 서버를 구축하는 상세 방법까지 제 경험을 담아 정리해 보겠습니다.

DBA들이 VDI 화면을 보며 속이 터졌던 진짜 이유

공공기관이나 금융권 프로젝트의 보안 벽은 통곡의 벽과 같습니다. 자산 유출을 막기 위해 화면만 송출되는 VDI 내부에서 오렌지(Orange), 토드(Toad), 디비버(DBeaver) 같은 DB 관리 도구를 쓰도록 강제하곤 하죠. 하지만 실무를 하는 입장은 다릅니다. 왜 그들이 그토록 네트워크 터널링(VPN) 방식을 원하는지 세 가지만 꼽아봤습니다.

1. 내 손에 익은 장비와 툴을 못 쓴다

VDI는 중앙 서버 자원을 쪼개 쓰는 구조라, 조금만 헤비한 쿼리를 돌려도 메모리 부족으로 멈칫거리기 일쑤입니다. 게다가 DBA들은 본인 로컬 PC에 수년간 쌓아온 자신만의 SQL 스니펫(Snippet), 플러그인, 단축키 설정을 가지고 있습니다. VDI를 쓰는 순간 이 소중한 무기들을 다 잃고 깡통 PC에서 작업을 하는 셈이 되니 답답할 수밖에요. OpenVPN을 쓰면 로컬 PC의 빵빵한 하드웨어 자원을 쓰면서 보안망에 접근할 수 있습니다.

2. 미세한 타이핑 렉(Lag)과 데이터 반출의 늪

VDI는 화면을 픽셀 단위로 전송하는 스트리밍 방식입니다. 쿼리를 한 줄 한 줄 짤 때 발생하는 그 미세한 타이핑 딜레이는 개발자나 DBA의 몰입도를 완전히 깨뜨립니다. 더 큰 문제는 데이터 가공입니다. 쿼리 결과 수만 건을 엑셀이나 CSV로 뽑았을 때, VDI 내부에 저장되다 보니 이걸 다시 로컬로 빼내기 위해 결재를 올리고 승인을 기다리는 번거로운 과정을 매번 거쳐야 합니다. 반면 VPN은 데이터 패킷만 직접 오가기 때문에 로컬 PC에 즉시 저장이 가능해 작업 속도가 몇 배는 빨라집니다.

3. 듀얼 모니터의 무용지물화와 멀티태스킹 제약

DB 작업은 혼자 창 하나 띄워놓고 하는 게 아닙니다. 설계 문서를 보고, 협업 툴로 소통하며, 브라우저에서 가이드를 검색하는 멀티태스킹의 연속이죠. VDI라는 작은 ‘창’ 하나에 갇혀버리면 로컬의 화려한 듀얼 모니터 환경을 온전히 쓰기 어렵습니다. 메신저와 DB 툴 사이를 매끄럽게 오가지 못하는 환경은 촉박한 마감 기한을 앞둔 DBA에게 큰 스트레스가 됩니다.

물론 보안을 위해 VDI를 강제하는 취지는 이해합니다. 하지만 적절한 접근 제어 정책(ACL)과 2차 인증(MFA)만 제대로 묶어준다면, OpenVPN이야말로 보안과 생산성을 모두 잡는 훌륭한 대안이 됩니다.

RHEL 9.6 환경에서 OpenVPN 서버 구축하기 (실전 Step-by-Step)

그럼 본격적으로 RHEL 9.6 환경에서 OpenVPN 서버를 올려보겠습니다. RHEL 9 대역은 보안 정책이 꽤나 까다롭기 때문에, SELinux와 방화벽(Firewalld) 설정을 정확하게 짚고 넘어가지 않으면 “연결이 안 돼요”라는 요청을 받기 십상입니다. 차근차근 따라오세요.

단계 1: 필수 패키지 설치

RHEL의 기본 레포지토리에는 OpenVPN이 포함되어 있지 않습니다. 따라서 확장 패키지 저장소인 EPEL을 먼저 활성화한 뒤 패키지를 설치해야 합니다.

Bash

# EPEL 저장소 활성화 및 OpenVPN, Easy-RSA 설치
sudo dnf install epel-release -y
sudo dnf install openvpn easy-rsa -y

단계 2: CA(인증기관) 및 인증서 생성

보안 연결의 핵심인 PKI(공개키 기반구조)를 만듭니다. Easy-RSA 스크립트를 활용하면 편리합니다.

Bash

# 작업 디렉토리 생성 및 초기화
mkdir ~/openvpn-ca
cp -r /usr/share/easy-rsa/3/* ~/openvpn-ca/
cd ~/openvpn-ca

# PKI 초기화 및 CA 인증서 생성 (비밀번호 없이 진행 시 nopass 추가)
./easyrsa init-pki
./easyrsa build-ca nopass

# 서버 요청서 생성 및 승인
./easyrsa gen-req server nopass
./easyrsa sign-req server server

# Diffie-Hellman 파라미터 및 TLS 암호화 키 생성
./easyrsa gen-dh
openvpn --genkey --secret ta.key

단계 3: 서버 환경 설정 (server.conf)

인증서와 키 파일들을 /etc/openvpn/server/ 디렉토리로 안전하게 복사한 뒤, 서버 메인 설정 파일을 작성합니다. 보통 아래와 같은 핵심 옵션들이 들어갑니다.

단계 4: 커널 포워딩 및 방화벽 활성화 (가장 중요!)

인프라 담당자들이 가장 많이 놓치는 구간입니다. VPN 서버가 클라이언트와 내부 DB 서버를 이어주는 게이트웨이 역할을 하려면 커널 수준에서 IP 포워딩을 켜야 합니다.

Bash

# 1. 커널 IP 포워딩 활성화
echo "net.ipv4.ip_forward = 1" | sudo tee -a /etc/sysctl.conf
sudo sysctl -p

# 2. Firewalld 방화벽 서비스 등록 및 마스커레이드(NAT) 설정
sudo firewall-cmd --add-service=openvpn --permanent
sudo firewall-cmd --add-masquerade --permanent
sudo firewall-cmd --reload

설정을 마치고 sudo systemctl enable --now openvpn-server@server 명령어로 서비스를 올리면 서버 측 준비는 끝납니다.

터널링이 뚫린 후, DBA의 실제 작업 워크플로우

이렇게 구축된 VPN 환경에서 DBA는 어떤 방식으로 내부 DB에 안전하게 접근하게 될까요? 실제 활용 단계는 다음과 같습니다.

1. .ovpn 프로필 로드 및 접속: 관리자에게 발급받은 인증서와 프로필 파일을 로컬 PC의 OpenVPN 클라이언트에 넣고 연결을 누릅니다. 이때 사내 계정 비밀번호와 일회용 OTP 번호를 입력하는 2차 인증을 거치게 됩니다.
2. 보안 터널 생성 및 IP 할당: 인증이 끝나면 외부 인터넷망과 완전히 격리된 암호화 터널이 뚫리고, 로컬 PC는 10.8.0.6 같은 가상 내부 IP를 부여받습니다. 이제 물리적으로는 원격지에 있지만, 네트워크상으로는 사내 서버룸에 앉아있는 것과 다름없는 상태가 됩니다.
3. 로컬 툴로 DB 직빨(?) 접속: 이제 답답한 VDI 화면 대신, 내 PC에 설치된 DBeaver나 Orange를 켭니다. 연결 주소에 DB 서버의 진짜 내부 IP(예: 192.168.10.50)를 입력하면 다이렉트로 접속됩니다. 렉 없이 마우스 휠이 부드럽게 내려가는 시원함을 맛보게 되죠.

인프라 관리자를 위한 ‘제로 트러스트’ 보안 방어선 구축 전략

DBA에게 자유를 주는 것은 좋지만, 시스템 전체를 책임지는 TA나 인프라 관리자 입장에서는 밤에 잠이 안 올 일입니다. “혹시 VPN 뚫린 로컬 PC가 악성코드에 감염되어 내부망 전체로 퍼지면 어쩌지?”라는 걱정이 드는 건 당연합니다.

그래서 우리는 ‘통제된 자율성’을 제공해야 합니다. 보안 리스크를 원천 차단하기 위해 제가 적용했던 3가지 관리자 방어 전략입니다.

1. ‘제로 트러스트’ 기반의 꼼꼼한 포트 제어 (ACL)

VPN 대역(10.8.0.0/24)이 뚫렸다고 해서 사내망의 모든 서버에 핑(Ping)이 가도록 방치하면 절대 안 됩니다. 네트워크 방화벽이나 RHEL의 iptables를 활용해 딱 필요한 DB 포트만 열어주세요.

• Oracle인 경우 1521, MySQL은 3306, PostgreSQL은 5432 포트만 정밀 타격하여 접근을 허용하고, 서버 제어 권한이 있는 SSH(22)나 RDP(3389) 포트는 원천 차단해야 합니다. 내부 침입이 발생하더라도 옆 서버로 번지는 것(Lateral Movement)을 막기 위함입니다.

2. 철저한 알리바이 확보, 실시간 감사 로그(Audit Log)

보안 사고 예방과 사후 추적을 위해 ‘누가, 언제, 어떤 IP로’ 들어왔는지 낱낱이 기록해야 합니다. OpenVPN이 제공하는 /var/log/openvpn-status.log와 인증 로그를 주기적으로 수집하고, 사내 SIEM(보안 정보 이벤트 관리) 솔루션과 연동해 두세요. 평소와 다른 새벽 시간대에 대용량 데이터 전송 패턴이 감지되면 관리자에게 즉시 알람이 오도록 설정하는 것이 안전합니다.

3. OTP(다중 인증, MFA) 결합은 필수

클라이언트에게 배포된 .ovpn 파일과 패스워드는 언제든 유출될 수 있다는 가정에서 출발해야 합니다. Google Authenticator 등과 연동한 PAM(Pluggable Authentication Modules) 인증을 OpenVPN에 얹어 가동하세요. 아이디와 패스워드가 맞아도 자기 스마트폰의 OTP 번호 6자리를 넣지 못하면 접속을 승인하지 않는 이중 잠금장치가 있어야 비로소 안심할 수 있습니다.

유연한 인프라가 결국 프로젝트의 퀄리티를 바꿉니다

TA로서 프로젝트 인프라를 만지다 보면 ‘보안’이라는 명목하에 작업자들의 손발을 꽁꽁 묶어두는 경우를 자주 봅니다. 하지만 족쇄가 무거울수록 작업 속도는 느려지고, 꼼수가 생기며, 결국 시스템 품질 저하라는 부메랑으로 돌아오더군요.

최신 RHEL 9.6 위에 얹은 OpenVPN은 엔터프라이즈급의 단단한 안정성을 보여주었습니다. 여기에 꼼꼼한 포트 제어와 MFA라는 안전장치를 더하니, 보안 팀도 만족하고 DBA 팀도 “이제야 일할 맛 난다”며 엄지를 치켜세웠습니다.

혹시 지금 진행 중인 프로젝트에서 가상 환경의 느린 속도 때문에 다들 고통받고 있다면, 무조건 막기만 하는 보안 대신 ‘검증된 보안 터널링을 통한 유연한 인프라’를 제안해 보시는 건 어떨까요? 인프라의 작은 유연성이 프로젝트의 성패를 가르는 열쇠가 될 수 있습니다.

전문가의 인사이트 : 함께 읽어 보세요.

[Agentic AI의 시대: 2026 Oracle AI Experience에서 본 엔터프라이즈 AI의 미래]

참조 및 출처 URL:

https://openvpn.net/community-docs/hardening-openvpn-security.html