VPN과 VDI는 왜 다르고 DB 접속은 왜 더 복잡할까

업무 중 VPN을 VDI와 비슷한 것으로 설명했다가, 두 개가 전혀 다른 역할을 한다는 것을 다시 배웠습니다. 처음에는 용어 하나를 잘못 이해한 문제라고 생각했지만, 다시 살펴보니 IP와 네트워크 구역, VPN, VDI, 방화벽, DB 접근통제가 한 경로 안에서 서로 다른 질문에 답하고 있었습니다.

이 글은 그때의 혼동을 다시 반복하지 않기 위해 만든 학습 기록입니다. 사내 Wi-Fi에서 업무 시스템을 쓰거나 DB 접속 문제를 처음 만났을 때, 각 개념의 역할과 어느 단계부터 확인해야 하는지 다시 펼쳐볼 수 있도록 정리했습니다. 특정 조직의 주소, 권한 정책, 오류 사례는 다루지 않고 여러 조직에서 공통으로 참고할 수 있는 원리만 설명합니다.

연결은 통신 경로를 만들고, 접근 권한은 각 보안 계층에서 따로 판단합니다.

접속 경로에서 맡는 역할부터 나눈다

네트워크 문제는 용어가 겹쳐 보여도 각 구성 요소가 맡은 일이 다릅니다. 나중에 다시 볼 때는 이름보다 각 요소가 어떤 질문에 답하는지 떠올리는 편이 이해하기 쉽습니다.

구성 요소	확인하는 질문	맡는 역할
Wi-Fi 또는 랜선	네트워크에 연결되었는가	장치를 로컬 네트워크에 연결합니다
IP 주소와 VLAN	어느 네트워크 구역에 속하는가	장치의 네트워크 위치와 통신 범위를 정합니다
VPN	어떤 내부 자원까지 가는 경로가 열렸는가	기존 네트워크 위에 보호된 논리적 통신 경로를 만듭니다
VDI	업무용 화면과 프로그램이 어디에서 실행되는가	서버에 있는 가상 데스크톱을 원격으로 사용하게 합니다
방화벽	해당 목적지와 포트로 통신해도 되는가	네트워크 트래픽의 통과 여부를 판단합니다
DB 접근통제	누가 어떤 DB에 어떤 세션으로 접근하는가	DB 접속과 사용자 행위를 통제하고 기록합니다
DB 계정 권한	DB 안에서 무엇을 할 수 있는가	조회와 변경 같은 실제 작업 범위를 제한합니다

이 순서로 보면 VPN과 VDI의 차이도 분명해집니다. VPN은 목적지까지 갈 수 있는 경로이고, VDI는 그 경로를 통해 사용할 수도 있는 원격 업무 환경입니다.

네트워크 연결은 위치를 정하지만 권한을 만들지는 않는다

DHCP는 네트워크 설정을 자동으로 빌려준다

DHCP는 Dynamic Host Configuration Protocol의 약자로, 네트워크에 들어온 장치가 통신에 필요한 설정을 자동으로 받게 하는 프로토콜입니다. 랜선이나 Wi-Fi에 연결한 노트북은 DHCP 서버로부터 사용할 수 있는 IP 주소뿐 아니라 서브넷 마스크, 기본 게이트웨이, DNS 서버 같은 설정을 함께 받을 수 있습니다. IETF의 DHCP 표준도 DHCP를 네트워크 주소를 할당하고 장치별 설정 정보를 전달하는 프로토콜로 설명합니다. IETF RFC 2131

동적으로 배정된 IP 주소는 대개 장치가 영구히 소유하는 값이 아니라 일정 기간 빌려 쓰는 값입니다. 이 기간을 임대 시간이라고 합니다. 장치는 네트워크에 다시 연결하거나 임대 시간이 갱신될 때 같은 주소를 받을 수도 있고 다른 주소를 받을 수도 있습니다.

노트북이 네트워크 설정 요청
→ DHCP 서버가 사용 가능한 IP와 설정 제안
→ 노트북이 설정을 일정 기간 임대
→ IP, 서브넷 마스크, 게이트웨이, DNS 적용

DHCP가 해주는 일은 장치에 네트워크 설정을 제공하는 데까지입니다. IP를 받았다는 사실만으로 중요 시스템에 접근할 권한이 생기는 것은 아닙니다. 사용자가 이더넷 설정 화면에서 IP 주소를 직접 입력할 수도 있지만, 그 주소가 사용 가능한지와 해당 네트워크에서 허용되는지는 별개의 문제입니다.

이미 다른 장치가 쓰는 주소를 입력하면 IP 충돌이 날 수 있습니다. 다른 구역의 IP를 입력해도 스위치 포트, Wi-Fi 정책, VLAN, 장치 인증, 방화벽 규칙이 맞지 않으면 그 구역의 권한을 얻지 못합니다. 고정 IP가 필요하면 임의 변경이 아니라 네트워크 관리자의 예약 또는 승인 절차가 필요합니다.

건물 안의 Wi-Fi라고 해서 모든 내부 시스템에 닿을 수 있는 것도 아닙니다. 조직은 사용자와 장치의 역할에 따라 업무용 단말, 방문자 단말, 서버, 중요 DB 같은 자원을 서로 다른 네트워크 구역으로 나눌 수 있습니다.

Wi-Fi 또는 랜선 연결
→ IP 주소와 네트워크 구역 배정
→ 허용된 목적지와 통신 경로 확인
→ 필요한 경우 VPN이나 별도 인증

이 분리는 물리적으로 다른 장비를 쓰기도 하고, VLAN과 방화벽 규칙으로 논리적으로 나누기도 합니다. 중요한 것은 건물 안에 있는지가 아니라 내 장치가 어느 구역에 속하며 어느 목적지까지 통신하도록 허용되었는지입니다.

VPN은 통로이고 VDI는 원격 PC다

NIST는 VPN을 기존 네트워크 위에 만든 논리적 네트워크이자 안전한 통신 수단으로 설명합니다. VPN을 켜면 노트북에는 기존 Wi-Fi 주소와 별도로 VPN 가상 어댑터용 IP가 생길 수 있고, VPN 정책에 따라 허용된 목적지로 가는 경로가 추가됩니다. NIST VPN 용어 정의

기존 네트워크의 IP
→ VPN 서버에 연결할 때 사용하는 주소

VPN IP
→ VPN 정책 안에서 사용할 수 있는 가상 네트워크 주소

반면 VDI는 운영체제와 애플리케이션을 중앙 서버에서 실행하고 그 데스크톱을 원격으로 사용하는 기술입니다. 내 노트북은 화면을 받아보고 키보드와 마우스 입력을 전달하며, 실제 업무 프로그램은 VDI 안에서 실행될 수 있습니다. Microsoft Learn의 VDI 설명

조직의 정책에 따라 접속 경로는 달라집니다. 다음은 VPN 뒤에서 VDI를 거치거나 로컬 DB 클라이언트를 사용하는 구성을 단순화한 예시입니다.

내 노트북
→ VPN으로 허용된 경로 확보
  ├→ VDI → VDI 안의 DB 클라이언트
  └→ 로컬 DB 클라이언트
→ DB 접근통제
→ DB 서버

두 경로가 모두 허용된다는 뜻은 아닙니다. 어떤 조직은 VDI를 거쳐야만 DB에 접근할 수 있고, 어떤 조직은 승인된 장치와 계정에 로컬 접속을 허용할 수 있습니다. VPN 연결 여부와 VDI 사용 여부는 조직이 정한 접속 방식에 따라 따로 확인해야 합니다.

VPN 연결 뒤에도 DB 접근은 다시 판단한다

VPN 연결이 성공했다는 것은 VPN 접속 단계가 완료되었다는 뜻입니다. 그러나 그 사실만으로 DB에 연결하거나 데이터를 조회할 권한까지 생기지는 않습니다.

VPN 인증
→ 사용자 그룹과 장치 정책 확인
→ 허용된 IP 대역 또는 목적지로만 라우팅
→ 방화벽 통과 여부 확인
→ DB 접근통제 시스템의 사용자와 세션 확인
→ DB 계정 권한 확인

조직은 사용자 그룹, VPN에서 배정하는 IP 대역, 장치 보안 상태, 다중 인증, 방화벽 규칙, DB 접근통제 정책을 함께 사용해 접근 범위를 정할 수 있습니다. CISA도 기존 VPN이 제공하는 넓은 원격 접근보다 자원별로 세분화된 접근통제를 적용하는 방향을 설명합니다. CISA의 현대적 네트워크 접근 보안 안내

NIST의 제로 트러스트 안내도 사내망 위치만으로 자동 신뢰를 주지 말고 사용자·장치·자원별로 접근을 판단해야 한다고 설명합니다. 그래서 “VPN을 켰으니 DB도 접속된다”는 기대보다 “VPN 이후 어떤 자원까지 허용됐는가”를 묻는 편이 정확합니다. NIST SP 800-207

DBSAFER는 실행 여부보다 정책과 세션이 중요하다

PNPSECURE는 DBSAFER DB를 데이터베이스 접근과 권한을 제어하고 SQL 수행 이력을 감사하는 제품으로 설명합니다. 조직마다 구성은 다르지만, 이런 DB 접근통제 시스템은 접속 사용자, 대상 DB, 세션과 수행 명령을 확인하는 통제 지점으로 동작할 수 있습니다. DBSAFER DB 제품 소개

그래서 프로그램이 실행 중이라는 사실만으로 DB 접속이 보장되지는 않습니다. 인증된 사용자, 허용된 네트워크 경로, 유효한 접근통제 세션, 대상 DB 계정 권한을 각각 확인해야 합니다.

DBSAFER 실행
≠ DB 접속 승인

DBSAFER 인증과 세션 생성
+ 허용된 네트워크 경로와 방화벽 정책
+ DB 계정 권한
→ DB 접속 전에 확인해야 할 주요 조건

이런 다층 통제는 불편해 보여도 DB에 저장된 개인정보와 중요 데이터를 보호하고, 누가 어떤 명령을 실행했는지 나중에 확인하기 위한 장치입니다.

DB 접속 실패는 아래 계층부터 좁힌다

실제 장애 원인은 담당자가 로그와 정책을 확인해야 알 수 있습니다. 다만 VPN 연결 뒤 DB 접근통제 프로그램이나 DB 클라이언트가 실패할 때는 아래에서 위로 올라가며 질문하면 어느 계층에서 막혔는지 좁히기 쉽습니다.

1. 네트워크 연결: Wi-Fi나 랜선 연결과 VPN 접속이 정상인가?
2. 이름과 주소 확인: VPN 연결 뒤 DNS가 내부 목적지를 올바르게 찾고, 예상한 네트워크 구역의 IP를 받았는가?
3. 경로와 방화벽 확인: DB 접근통제 시스템이나 DB 서버로 가는 경로와 필요한 통신이 허용되었는가?
4. 접속 방식 확인: 조직 정책상 내 계정과 장치는 로컬 DB 클라이언트를 쓸 수 있는가, VDI를 거쳐야 하는가?
5. 접근통제 세션 확인: VPN 연결 뒤 DB 접근통제 프로그램에 다시 인증하거나 새 세션을 만들어야 하는가?
6. DB 권한과 로그 확인: DB 계정 권한이 유효한가? VPN, 방화벽, DB 접근통제 로그에는 어느 단계의 차단 사유가 남았는가?

여기서 사용자 PC의 IP를 임의로 바꾸는 것은 해결책이 아닙니다. IP 주소는 접근 판단에 쓰일 수 있지만, 권한 자체는 아니기 때문입니다. VPN 사용자 그룹과 방화벽 정책을 우회하려는 방식은 보안 사고와 서비스 장애를 만들 수 있으므로, 담당 조직이 안내한 접속 절차와 승인 경로를 따라야 합니다.

막혔을 때는 이렇게 전달한다

문제를 “DB가 안 됩니다”라고만 전달하면 VPN, 방화벽, DB 접근통제, DB 계정 중 어디를 확인해야 할지 범위가 넓어집니다. 현재 위치와 마지막으로 성공한 단계, 실패한 단계를 나눠 전달하면 담당자가 확인하기 쉬워집니다.

사내 Wi-Fi에서 VPN 연결까지는 정상입니다. 다만 DB 접근통제 프로그램을 통한 DB 접속 단계에서 실패합니다. 제 계정과 장치에 허용된 접속 방식이 로컬 접속인지 VDI 경유인지, VPN 연결 뒤 DB 접근통제 목적지로 가는 경로와 방화벽 정책이 허용되어 있는지 확인 부탁드립니다.

오류 화면, 발생 시간, VPN 연결 전후의 차이처럼 담당자가 요청한 정보만 안전한 내부 경로로 전달하면 됩니다. DB 주소, 계정, 비밀번호, 내부 IP, SQL 문장을 외부 메신저나 공개 문서에 남기면 안 됩니다.

이번에 바뀐 이해

처음에는 VPN을 서버 안의 개인 업무 공간에 들어가는 기능으로 생각했습니다. 이제는 VPN이 통신 경로이고 VDI가 원격 업무 환경이라는 차이부터 봅니다. 그다음 방화벽, DB 접근통제, DB 계정이 각각 무엇을 확인하는지 순서대로 생각합니다.

이번에 바뀐 것은 용어의 정의만이 아니었습니다. “VPN은 연결됐는데 왜 DB는 안 되지?”라는 질문을 받았을 때, 이제는 연결 여부와 권한 여부를 나눠 보고 마지막으로 성공한 계층부터 확인할 수 있게 되었습니다. 나중에 다시 헷갈리더라도 이 순서부터 펼쳐보면 됩니다.

참고자료

• IETF RFC 2131 Dynamic Host Configuration Protocol
• NIST VPN 용어 정의
• NIST SP 800-207 Zero Trust Architecture
• CISA Modern Approaches to Network Access Security
• Microsoft Learn Virtual desktop infrastructure
• PNPSECURE DBSAFER DB 제품 소개