VNC (가상 네트워크 컴퓨팅)

VNC(Virtual Network Computing)는 하나의 단순한 통찰에서 탄생했습니다: 어떤 운영 체제든, 내부적으로는 아무리 달라도, 결국 화면에 색깔 있는 픽셀을 그린다는 사실입니다. VNC는 이 보편적인 진실을 활용합니다. 여러분이 Windows를 쓰든, Linux를 쓰든, macOS를 쓰든, 혹은 특이한 무언가를 쓰든 상관하지 않습니다—그저 화면을 지켜보고, 변한 것을 전송하고, 키보드와 마우스 입력을 받습니다.

덕분에 VNC는 가장 플랫폼 독립적인 원격 데스크톱 프로토콜이 되었습니다. Mac에서 Linux 서버를 제어하거나, Windows 노트북에서 Raspberry Pi에 접속하거나, Android 폰으로 FreeBSD 머신을 관리하는 것—VNC는 이 모든 상황을 동일한 방식으로 처리합니다.

VNC의 동작 방식

VNC는 프레임버퍼 수준에서 동작합니다—애플리케이션이나 창이 아닌 원시 픽셀을 다룹니다. 서버는 화면의 직사각형 영역을 캡처해 클라이언트로 전송합니다. 클라이언트는 그 직사각형을 표시하고, 키보드와 마우스 이벤트를 다시 서버로 보냅니다. 이게 전부입니다.

이 방식은 놀랍도록 단순합니다. 서버는 창 관리, 애플리케이션 상태, 그래픽 API를 이해할 필요가 없습니다. 화면에 어떤 픽셀이 있고 언제 바뀌는지만 알면 됩니다. 클라이언트는 원격 운영 체제에 대해 아무것도 몰라도 됩니다. 픽셀을 표시하고 입력을 캡처하면 그만입니다.

이 단순함에는 절충점이 있습니다. VNC는 무슨 일이 일어나는지 파악해야 가능한 영리한 최적화를 할 수 없습니다—문서를 스크롤하고 있다는 걸 알고 스크롤 변화량만 전송하는 것 같은 일은 불가능합니다. 픽셀이 변한 것을 보고 그 변화를 전송할 뿐입니다. 하지만 바로 이 한계 때문에 VNC는 어디서든 작동합니다: 프레임버퍼에 렌더링할 수 있는 시스템이라면 무엇이든 VNC 서버를 실행할 수 있습니다.

연결 과정

VNC 뷰어를 VNC 서버에 연결하면:

프로토콜 협상이 먼저 이루어집니다. VNC는 여러 버전을 거쳐 발전해 왔으며, 양측은 서로 지원하는 기능에 합의합니다.

인증이 그 다음입니다—주로 비밀번호 기반이지만, 일부 구현은 더 강력한 방법을 지원합니다. 서버는 연결 권한을 확인합니다.

초기화는 세션 매개변수를 설정합니다: 화면 크기, 색상 깊이, 그리고 양측이 지원하는 인코딩(압축 방식).

정상 동작이 시작됩니다. 서버는 픽셀이 변경될 때마다 화면 업데이트를 전송합니다. 여러분이 원격 데스크톱과 상호작용하면 입력이 서버로 전달됩니다. 연결을 끊을 때까지 이 과정이 계속됩니다.

인코딩 선택은 매우 중요합니다. Raw 인코딩은 픽셀을 그대로 전송합니다—단순하지만 대역폭을 많이 소모합니다. Tight와 ZRLE는 적극적으로 압축하여 느린 연결에서도 VNC를 사용할 수 있게 합니다. 대부분의 최신 뷰어는 자동으로 최적의 인코딩을 협상합니다.

VNC와 RDP 비교

RDP(Remote Desktop Protocol)는 VNC의 주요 경쟁자입니다. 둘 다 같은 문제를 다른 방식으로 해결합니다.

플랫폼 지원: VNC가 압도적으로 유리합니다. RDP는 Microsoft의 프로토콜로, 주로 Windows용으로 설계되었습니다. VNC는 처음부터 플랫폼 독립적으로 설계되었으며 모든 환경에서 기본 실행됩니다.

성능: RDP가 종종 크게 앞섭니다. Microsoft는 정교한 압축, 캐싱, 화면에서 일어나는 일에 대한 맥락 기반 이해로 수십 년간 RDP를 최적화해 왔습니다. 기본 VNC 구현은 이에 비해 느리게 느껴지지만, 좋은 인코딩을 갖춘 최신 버전은 그 격차를 좁혔습니다.

기능: RDP에는 드라이브 리디렉션, 프린터 공유, 오디오 스트리밍, 클립보드 동기화, 다중 모니터 지원이 기본으로 포함됩니다. VNC는 좀 더 간소합니다—일부 구현에서는 이런 기능을 추가하지만, 핵심 프로토콜에는 포함되지 않습니다.

보안: RDP는 최신 버전에서 암호화가 내장되어 있습니다. 원래 VNC는 비밀번호를 포함한 모든 것을 평문으로 전송합니다. 이것이 VNC의 가장 심각한 약점입니다.

단순성: VNC가 앞섭니다. 프로토콜이 간단하고, 구현 코드를 검토하고 이해하기 쉬우며, 프레임버퍼 모델에는 숨겨진 복잡성이 없습니다.

Windows 간 연결에서 성능이 중요하다면 RDP를 선택하세요. 서로 다른 운영 체제를 다뤄야 하거나 단순하고 투명한 솔루션을 원한다면 VNC를 선택하세요.

보안 문제

VNC의 원래 설계에는 암호화가 포함되지 않았습니다. 키 입력, 화면 내용, 심지어 비밀번호까지—모든 것이 평문으로 전송됩니다. VNC가 신뢰할 수 있는 로컬 네트워크에서만 사용되던 시절에는 어느 정도 받아들일 수 있었습니다. 오늘날에는 그렇지 않습니다.

VNC 포트를 절대 인터넷에 노출하지 마세요. 이 프로토콜은 다른 시대를 위해 설계되었습니다.

SSH 터널링이 표준 해결책입니다:

ssh -L 5901:localhost:5900 username@server

이렇게 하면 암호화된 터널이 생성됩니다. VNC 뷰어를 localhost:5901에 연결하면 모든 것이 SSH 암호화를 통해 서버의 VNC 포트로 전달됩니다. SSH 터널링은 차선책이 아닙니다. 이것이 바로 정답입니다.

VPN 접근 방식도 비슷하게 작동합니다—VPN에 연결한 후에만 VNC에 접근할 수 있도록 하면, VNC 자체를 수정하지 않고도 보안 계층이 추가됩니다.

일부 최신 VNC 구현은 자체 암호화를 추가합니다. 예를 들어 RealVNC의 상용 제품은 기본적으로 암호화합니다. 하지만 당연하게 여기지 마세요—사용 중인 구현이 실제로 트래픽을 암호화하는지 반드시 확인하세요.

VNC 변형

VNC 생태계는 각자 다른 강점을 가진 여러 구현으로 분화되었습니다:

RealVNC는 원래 개발자들이 만든 것입니다. 상용 버전에는 암호화, 파일 전송, 엔터프라이즈 기능이 추가됩니다. 무료 버전은 기본적이지만 사용 가능합니다.

TightVNC는 Tight 인코딩으로 대역폭을 최적화합니다. 느린 연결에 탁월합니다. 오픈 소스입니다.

TigerVNC는 성능과 최신 기능에 집중합니다. Linux 시스템에서 가장 많이 선택됩니다. 활발하게 유지 관리되는 오픈 소스입니다.

UltraVNC는 파일 전송과 더 나은 화면 캡처 성능을 위한 비디오 훅 드라이버 같은 기능으로 Windows에 특화되어 있습니다. 오픈 소스입니다.

x11vnc는 가상 디스플레이를 새로 만들지 않고 기존 X11 디스플레이를 공유합니다—물리적 화면에 표시된 것과 동일한 세션을 보고 제어하고 싶을 때 유용합니다.

모두 기본 프로토콜 호환성을 유지합니다. TightVNC 뷰어로 TigerVNC 서버에 연결할 수 있습니다. 구현이 갈라지더라도 핵심 프로토콜은 표준화되어 있습니다.

플랫폼별 참고 사항

Linux에서는 주로 TigerVNC나 x11vnc를 사용합니다. 대부분의 데스크톱 환경에는 VNC 서버 기능이 포함되어 있습니다. 기존 디스플레이(물리적 모니터에 표시된 것)를 공유하거나, 원격 세션을 위한 별도의 가상 데스크톱을 만들 수 있습니다.

macOS에는 VNC가 내장되어 있습니다. 시스템 환경설정에서 화면 공유를 활성화하면 Mac이 표준 VNC 연결을 받아들입니다. Apple은 양쪽 모두 Apple 소프트웨어를 사용할 때 독점 기능을 추가하지만, 기본 VNC 호환성은 갖추고 있습니다.

Windows에는 VNC 서버가 포함되어 있지 않아 별도 소프트웨어가 필요합니다. TightVNC, UltraVNC, RealVNC가 일반적인 선택입니다.

성능 최적화

느린 연결에서 VNC는 답답하게 느껴질 수 있습니다. 몇 가지 조정이 도움이 됩니다:

인코딩: Tight 또는 ZRLE를 사용하세요. 매우 빠른 로컬 네트워크를 제외하고는 Raw 인코딩을 쓰지 마세요.

색상 깊이: 24비트에서 16비트 또는 8비트로 줄이면 대역폭이 크게 감소합니다. 텍스트 위주의 작업에서는 차이를 거의 느끼지 못합니다.

압축: 압축률을 높이면 CPU를 더 써서 대역폭을 줄입니다. 느린 연결에서는 압축을 높이세요.

해상도: 해상도를 낮추면 전송할 픽셀이 줄어듭니다. 느린 연결에서 4K를 억지로 밀어내려 하기보다는 원격 데스크톱 해상도를 낮추는 편이 훨씬 쾌적합니다.

VNC를 사용해야 할 때

VNC가 적합한 경우:

• 다양한 클라이언트 플랫폼에서 서로 다른 운영 체제에 접근해야 할 때
• 가끔 그래픽 접근이 필요한 헤드리스 Linux 서버를 관리할 때
• 여러 플랫폼에 걸쳐 기술 지원을 제공할 때
• 경량 VNC 서버가 포함된 임베디드 시스템이나 IoT 기기를 다룰 때
• 독점 솔루션보다 단순하고 개방된 것을 원할 때

VNC가 적합하지 않은 경우:

• 양쪽이 모두 Windows일 때 (RDP를 사용하세요)
• 크로스 플랫폼 지원보다 최고 성능이 더 중요할 때
• 끊김 없는 오디오나 드라이브 리디렉션 같은 고급 기능이 필요할 때

대안

RDP: Windows 환경에 적합합니다. 더 나은 성능, 더 많은 기능, 크로스 플랫폼 지원은 떨어집니다.

Chrome Remote Desktop: NAT와 방화벽을 자동으로 처리하는 손쉬운 브라우저 기반 접근 방식입니다.

TeamViewer와 AnyDesk: 개방형 프로토콜보다 간편한 설치를 우선시하는 상용 솔루션입니다.

NoMachine: 특히 느린 연결에서 기존 VNC보다 나은 성능을 제공합니다.

Apache Guacamole: 별도 클라이언트 소프트웨어 없이 브라우저에서 VNC 및 기타 프로토콜에 접근할 수 있습니다.

VNC에 관해 자주 묻는 질문

VNC 트래픽은 암호화되나요?

기본적으로는 그렇지 않습니다. 원래 VNC 프로토콜은 비밀번호를 포함한 모든 것을 암호화 없이 전송합니다. 일부 최신 구현은 암호화를 추가하지만, 많은 구현이 그렇지 않습니다. 사용 중인 구현이 트래픽을 암호화한다고 확인하지 않은 이상, VNC는 항상 SSH나 VPN을 통해 터널링하세요.

VNC는 어떤 포트를 사용하나요?

VNC 서버는 일반적으로 디스플레이 :0에 대해 포트 5900번, 디스플레이 :1에 대해 포트 5901번을 수신 대기하며, 이후도 순서대로입니다. 웹 기반 VNC 뷰어는 주로 포트 5800번 이상을 사용합니다. 방화벽에서 이 포트들을 차단하고 암호화된 터널을 통해서만 VNC에 접근하세요.

인터넷을 통해 VNC를 사용할 수 있나요?

네, 하지만 VNC 포트를 직접 외부에 노출해서는 절대 안 됩니다. SSH 터널링을 설정하거나 먼저 VPN 접근을 요구하세요. 추가 보안 없는 VNC는 보안 침해를 자초하는 것입니다.

VNC 연결이 왜 느린가요?

인코딩을 확인하세요—Raw나 비효율적인 인코딩을 사용하고 있다면 Tight 또는 ZRLE로 전환하세요. 색상 깊이와 화면 해상도를 낮추세요. 서버에 여유 CPU가 있다면 압축률을 높이세요. 물리적 네트워크 속도가 병목 지점인 경우도 많습니다.

기존 디스플레이 공유와 가상 디스플레이 생성의 차이는 무엇인가요?

기존 디스플레이 공유(Linux의 x11vnc, macOS의 화면 공유)는 물리적 모니터에 표시된 것과 동일한 화면을 보여줍니다—원격 지원에 유용합니다. 가상 디스플레이 생성은 물리적 기기 앞에 앉아 있는 사람에게는 보이지 않는 별도 세션을 시작합니다—헤드리스 서버나 개인적으로 작업하고 싶을 때 유용합니다.