20년 넘게 디스플레이 케이블 안에 숨겨져 있었던 원격 제어 프로토콜인 DDC/CI에 대한 여정, 그리고 이것이 어떻게 내 모니터를 KVM으로 만들었는지에 대하여.

모든 것이 시작된 책상

내 셋업은 평범해 보입니다. 책상 위에 열려 있는 MacBook Air(나의 메인 기기)와 두 개의 HDMI 포트, DisplayPort, USB-C를 갖춘 32인치 4K 모니터인 LG 32UN880K가 있습니다. 평범하지 않은 부분은 MacBook 뒤에 있습니다. Linux를 실행 중인 ASUS 게이밍 노트북인데, 내부 화면이 고장 났습니다. 이제 이 노트북은 헤드리스(headless) 타워로 사용됩니다. 외부 모니터는 이 노트북의 액세서리가 아니라, BIOS, 부팅 메뉴 등 모든 것을 볼 수 있는 유일한 디스플레이입니다.

키보드와 마우스 문제는 이미 해결되었습니다. 소프트웨어 KVM인 Input Leap 덕분에 Mac의 키보드와 마우스를 사용하여 ASUS에서 타이핑할 수 있습니다. 해결되지 않은 문제는 가장 단순한 것이었습니다. 바로 두 기기 사이에서 모니터를 전환하는 것이었습니다. LG 모니터의 물리적 OSD 버튼이 작동하긴 하지만, 하루에 여러 번 스위치를 조작하다 보니 엄지손가락 아래에서 버튼의 수명이 줄어드는 것이 느껴질 정도였습니다.

스포일러를 하자면, 모니터가 자신만의 독특한 방언을 구사한다는 사실이 밝혀졌고, 그것을 알아내는 과정이 이 이야기의 대부분을 차지합니다.

제1장: 합리적인 선택지들

하드웨어 가격을 알아보았습니다. IR 리모컨이 포함된 4K@60 HDMI 스위치는 약 $10 정도 합니다. Mac은 3-in-1 USB-C 동글에 연결하고, ASUS는 HDMI에 연결한 뒤 리모컨을 클릭하면 됩니다. 작동은 했을 것입니다. 하지만 이는 Mac의 경로에 영구적인 동글을 추가해야 함을 의미했고, 그 동글이 4K@60을 지원할지에 대한 도박이었으며, 또 다른 박스와 또 다른 리모컨을 추가하는 일이었습니다. 이미 서랍은 바로 이런 종류의 해결책들로 가득 차 있었습니다.

'지금 구매(Buy Now)'를 클릭하기 직전, 배선 계획을 세우기 위해 사용하던 AI 에이전트와 대화하던 중, 프로젝트의 방향을 완전히 바꿔놓은 말을 들었습니다.

"당신의 모니터는 이미 DDC/CI를 지원합니다. 이 모든 것이 필요하지 않을 수도 있습니다."

제2장: 아무도 말해주지 않았던 프로토콜

제가 배운 점, 그리고 대부분의 사람들이 진정으로 모르고 있는 사실은 다음과 같습니다. 모든 HDMI, DisplayPort, USB-C 디스플레이 케이블 내부에는 기가비트 단위의 비디오를 전송하는 와이어와 함께, 겸손하고 작은 I²C 버스 (I²C bus)를 전송하는 두 개의 추가 와이어가 들어 있습니다. 이것은 컴퓨터가 모니터의 EDID(해상도와 타이밍 정보가 담긴 이름표)를 읽을 수 있도록 존재합니다.

하지만 VESA는 여기서 멈추지 않았습니다. DDC/CI 표준 (MCCS 명령 세트 포함)은 컴퓨터가 동일한 버스를 통해 모니터로 명령을 전송할 수 있게 해줍니다. 밝기 (0x10), 볼륨 (0x62), 전원 (0xD6) — 그리고 가장 핵심적인 것:

VCP 코드 0x60: 입력 소스 선택. 올바른 값을 보내면 모니터의 입력이 변경됩니다. OSD 버튼도, IR 리모컨도, KVM 박스도 필요 없습니다. 모니터 자체가 스위치입니다. 처음부터 그래왔던 것입니다.

모든 OS에는 이를 위한 도구가 있습니다: macOS의 m1ddc 및 BetterDisplay, Linux의 ddcutil, Windows의 ControlMyMonitor 및 Monitorian이 있습니다.

제3장: 깜빡임

최소한의 도구인 m1ddc를 사용한 첫 번째 시도:

m1ddc display 2 set input 17

화면이 깜빡였지만 — 그대로 Mac에 머물렀습니다. get input은 0을 반환했는데, 이는 말이 안 되는 결과였습니다. 다른 값들도 시도해 보았습니다. 깜빡, 깜빡, 그리고 아무 일도 일어나지 않았습니다. 하지만 OSD 버튼으로 수동 전환했을 때는 잘 작동했으므로, ASUS 신호는 분명히 존재했습니다.

명령은 분명히 모니터에 도달했고 — 무언가 일어나고 있었지만 — 전환 자체는 거부당하고 있었습니다. 만약 여러분이 LG 모니터에서 DDC 입력 전환을 시도해보고

바로 그것이었습니다. 많은 LG 모니터는 입력 전환을 위해 대체 DDC (DDC addressing scheme) 주소 체계를 요구합니다. 표준 주소로 지정된 명령이 도착하면, 링크에 오류가 발생하고(깜빡임), 무시됩니다. LG 대체 주소로 지정된 명령은 수용됩니다. 제 모니터는 대화를 거부하고 있었던 것이 아니라, 제가 잘못된 방언을 사용하고 있었을 뿐이었습니다.

betterdisplaycli perform -nameLike=LG -changeInputSource -value=17

Mac 데스크탑이 사라지고 Linux 펭귄 배경화면이 화면을 채웠습니다. 저는 아무도 없는 곳에 무언가 혼잣말을 했을지도 모릅니다.

제5장: 돌아가는 길

ASUS로 전환하는 문제는 해결되었습니다. 다시 돌아가는 것은 새로운 퍼즐이었습니다: 16 ("USB-C (LG alt)")은 아무런 반응이 없었습니다. 그래서 우리는 후보들을 훑었습니다 — MacBook의 작은 화면에 있는 제 터미널에는 TRYING 16, TRYING 6, TRYING 15가 출력되고 있었고... 그동안 큰 모니터는 여전히 Linux를 보여주며, Mac을 집으로 데려올 명령 하나를 기다리고 있었습니다.

"15번에서 돌아왔다" — DP 2 / USB-C (LG alt). 지나고 보니 말이 됩니다: USB-C 대체 모드 (alt mode)는 곧 DisplayPort이며, 이 펌웨어는 자신의 USB-C 포트를 DP로 분류합니다.

그날 기록해 둘 만한 두 가지 사항:

• DDC는 비활성 입력 상태에서도 작동합니다. 여러분이 ASUS 화면을 보고 있는 동안에도 Mac이 모니터를 다시 가져올 수 있습니다. 화면을 점유하기 위해 반드시 해당 화면에 머물러 있을 필요는 없습니다.
• 읽기 응답(Read-back)은 거짓말을 합니다. 이 모니터는 무엇을 묻든 get input에 대해 0으로 응답합니다. 코드를 확인하려면 화면을 직접 관찰한 다음, 코드를 하드코딩(hardcode)하세요.

제6장: 망가뜨려 버렸다

용기를 얻은 저는 테스트 루프를 스크립트로 작성하여 1분도 채 되지 않아 약 10번의 입력 전환을 실행했습니다. 모니터는 USB-C 링크를 완전히 끊어버리는 것으로 응답했습니다. macOS는 장치 목록에서 디스플레이를 제거했고, 화면은 "신호 없음"으로 변했으며, DDC는 먹통이 되었고, 이후의 모든 명령은 Failed.를 반환했습니다. 케이블을 뽑았다가 다시 꽂아도 살아나지 않았습니다 — 물리 버튼을 눌러야만 했습니다.

이제 제 별칭(alias)에 sleep으로 내장된 새로운 규칙: 입력 전환을 함수 호출이 아닌 물리적 릴레이(relay)처럼 취급하십시오. 명령 하나, 잠시의 침묵, 그다음 명령.

제7장: 어떤 하드웨어로도 해결할 수 없는 문제

이제 다 끝났다고 생각했을 때, 낙원의 결함을 발견했습니다. 그리고 그것은 10달러짜리 스위치로는 결코 해결할 수 없는 문제였습니다. 왜냐하면 그것은 전혀 비디오 문제가 아니기 때문입니다.

USB-C 직접 연결을 사용하면, 모니터가 다른 입력을 표시하고 있을 때도 Mac과 모니터 사이의 연결은 *살아있는 상태(stays alive)*로 유지됩니다. 이것이 바로 DDC가 여전히 작동하는 정확한 이유입니다. 따라서 macOS는 LG 모니터가 바로 그곳에 있다고 생각합니다. ASUS로 전환하면, 내 Mac의 모든 창은 내가 볼 수 없는 데스크톱에 그대로 머물러 있게 됩니다. 기존의 HDMI 스위치는 이 문제를 '절단'을 통해 "해결"했습니다. 연결을 끊어버림으로써 macOS가 패닉에 빠지게 만들고, 모든 창을 노트북 화면으로 쏟아내게 한 뒤 다시는 되돌려놓지 않는 방식입니다.

더 나은 해답은 이것입니다: 연결을 끊지 말고, 미러링(mirror)하십시오. ASUS로 전환할 때, MacBook의 디스플레이를 LG의 데스크톱으로 미러링하십시오. 아무것도 움직이지 않습니다. 모든 창은 노트북 화면에서도 동시에 보이게 됩니다. 다시 돌아올 때는 미러링을 해제하십시오. 나는 창의 위치를 편집증적으로 관찰하며 양방향 모두를 테스트했습니다: 레이아웃 유지, 레이아웃 유지.

betterdisplaycli set -name="Built-in Display" -mirror=on  -targetNameLike=LG
betterdisplaycli set -name="Built-in Display" -mirror=off

목적지

전체 워크플로우(workflow)는 처음부터 끝까지 두 개의 셸 별칭(shell aliases)으로 이루어집니다:

# 17 = HDMI 1 (LG alt) -> ASUS | 15 = DP 2 / USB-C (LG alt) -> Mac
alias asus_display='betterdisplaycli perform -nameLike=LG -changeInputSource -value=17; sleep 1; betterdisplaycli set -name="Built-in Display" -mirror=on -targetNameLike=LG'
alias mac_display='betterdisplaycli set -name="Built-in Display" -mirror=off; sleep 1; betterdisplaycli perform -nameLike=LG -changeInputSource -value=15'

배선: MacBook → USB-C 케이블 하나 (4K@60 + 60W 충전 + 모니터의 USB 허브). ASUS → HDMI 직접 연결, 따라서 BIOS와 부팅 화면이 항상 작동합니다. 패널이 꺼진 상태에서는 타협할 수 없는 부분입니다. 키보드/마우스는 ASUS 전용 세션을 위해 저렴한 USB 2-호스트 스위치(USB 2-host switch)를 사용하며, 나머지 90%는 Input Leap가 담당합니다.

디스플레이 전환을 위한 총 하드웨어 지출: $0. BetterDisplay에서 사용한 모든 기능은 무료 티어(free-tier)이며, 로그인 항목(login items)에 상주할 뿐 GUI를 단 한 번도 열어본 적이 없습니다. 총 토큰(token) 지출은 약 $4였으며, 이를 통해 DDC 방언(dialects)을 이해하는 디버깅 파트너를 얻었습니다. 그리고, 뭐, 블로그 포스트의 소재도 얻었고요.

두 개의 별칭(aliases)을 어느 기기에서든 입력하기만 하면, 화면은 자신이 어디를 바라봐야 하는지 즉시 알아차립니다.

과거의 나에게 해주고 싶은 말

직접 이 작업을 수행하려는 분들에게 꼭 전하고 싶은 한 가지는 다음과 같습니다: 여러분의 모니터 DDC 구현 방식은 매우 독특하며(snowflake), 그 방언을 아는 유일한 방법은 문서를 읽는 것이 아니라 직접 테스트하는 것입니다. 코드는 제조사와 펌웨어마다 다르며, 읽기(read-back) 결과가 완전히 거짓일 수도 있습니다. 또한 일부 모델(특히 NVIDIA의 독점 Linux 드라이버)은 재미있는 단계에 도달하기도 전에 ddcutil로부터 DDC 버스를 숨겨버리기도 합니다. 10분 정도의 시간을 할애하세요. 코드를 보내고, 화면을 관찰하며, 사양서(spec sheet)가 약속한 내용이 아니라 실제로 어떤 일이 일어났는지를 기록하십시오.

그리고 시작하기 전에 알아두어야 할 두 가지 명확한 한계가 있습니다: DDC는 실행 중인 OS가 필요합니다. 따라서 부팅 전 액세스(BIOS, GRUB)가 필요한 모든 작업은 설정이 아무리 영리하더라도 일반적인 HDMI 상태로 유지됩니다. 또한 대상 기기가 깨어 있어야 합니다. 절전 모드인 노트북으로 전환하면 결국

설정: MacBook Air (Apple Silicon), 내부 디스플레이가 고장 난 Linux 기반 ASUS 노트북, LG 32UN880K, BetterDisplay 4.3.5 (무료 버전), 키보드/마우스용 Input Leap. 입력 코드는 다를 수 있으므로 — 경험적으로 테스트하십시오. 디버깅 공로: 끈기 있는 인간 한 명, AI 에이전트 한 명, 그리고 $4 상당의 토큰.