Summary

  • Web MIDI는 웹 앱이 MIDI 입력·출력 포트를 찾고 키보드의 신호를 받으며 신시사이저나 조명 장치로 메시지를 보내게 한다. MIDI가 전달하는 것은 음표와 제어 이벤트이지 스피커의 소리가 아니다.
  • 포트의 식별 정보는 사용자의 장비 구성을 드러낼 수 있다. System Exclusive, 즉 SysEx는 제조사별 장치 기능에 닿기에 일반 MIDI보다 강한 권한을 요구하게 됐다.

왜 오래된 키보드를 웹페이지에 연결할까? 손끝에 익은 건반과 노브를 계속 쓰면서 소프트웨어는 바꾸고 싶기 때문이다. W3C의 2012년 초안은 브라우저가 MIDI 입력과 출력을 열거하고 메시지를 주고받는 통로를 제안했다. 키보드, 드럼 머신, 외부 신시사이저, 무대 조명까지 같은 통로를 쓸 수 있다. 여기서 MIDI를 오디오로 착각하면 이야기가 꼬인다. 메시지는 음표 시작, 제어 값, 박자 신호를 전한다. 소리는 악기가 만든다. 브라우저가 지휘봉을 잡았다고 오케스트라까지 된 것은 아니다.

낮은 층위에서 신호만 전달하는 설계라 활용 폭이 넓었다. 어떤 노브가 비브라토를 키우는지 조명을 밝히는지는 앱과 연주자가 정한다. 브라우저는 음악 이론을 강요하지 않는다. 하지만 장비를 찾는 일 자체가 정보를 읽는 일이다. 초기 초안에는 재시작 뒤에도 같은 포트를 알아볼 수 있게 하는 지속적인 fingerprint가 있었다. 비슷한 키보드 여러 대가 놓인 작업실에서는 편하다. 호기심 많은 페이지에는 장비 목록의 단서다. 제조사, 이름, 버전도 포트 정보였다. 초안은 포트 열거와 특수 메시지가 낳는 개인정보·보안 문제를 이미 거론했다. 연주자의 연락처 수첩이 웹의 연락처 수첩이 되면 열람자를 따져야 한다.

안쪽 문에는 System Exclusive, 줄여서 SysEx라는 이름이 붙는다. 보통 메시지는 음표를 켜거나 제어 값을 바꾼다. SysEx는 제조사 고유의 언어로 음색과 설정 등 장치 내부 자료를 읽거나 바꿀 수 있다. 곡을 연주하려는 페이지와 신시사이저의 내부 서랍을 열려는 페이지는 같은 요청을 하는 게 아니다. 2015년 초안은 requestMIDIAccess({sysex:true})로 차이를 드러냈다. 추가 권한이 거부되면 그 요청은 실패한다. 연습실에 들어왔다고 수리실 열쇠까지 받을 이유는 없다.

실제 연주에는 권한 창보다 소박한 난제도 있다. 연주 도중 케이블이 빠질 수 있고, 예약된 음표가 늦게 나가면 귀가 먼저 알아챈다. 앱이 다른 사이트의 페이지 안에 끼워져 있을 수도 있다. API는 포트 연결 상태와 시간을 지정한 출력을 다루면서도 각 버튼의 음악적 의미는 앱에 맡긴다. 브라우저는 교통정리를 하고, 악보는 쓰지 않는다.

2026년 10월 20일 W3C 초안에서는 문패가 더 선명하다. 권한 이름은 midi이고 sysex: true는 일반 접근보다 강하다. 이 허가가 없으면 SysEx 전송은 예외를 일으키고 수신 메시지는 가려진다. requestMIDIAccess()는 보안 컨텍스트에서 쓰인다. Permissions Policy의 midi 기본 허용 목록은 'self'다. 남의 페이지에 삽입된 콘텐츠가 같은 화면에 있다는 이유로 작업실 열쇠를 얻지 않는다. 초안은 장치별 명령이 취약한 하드웨어에 줄 수 있는 위험도 검토한다. 가능한 공격 경로의 분석을 모든 신시사이저에서 일어난 사건으로 바꿀 수는 없다.

W3C의 발표 이력에는 2012·2013·2015년 초안과 2024~2026년의 새 초안들이 이어진다. 발표일은 표준 문서의 이정표이지 모든 브라우저가 동시에 기능을 갖춘 날짜가 아니다. 오래 남은 질문은 단순하다. 웹이 사람의 악기를 빌려 쓰면서 작업실 전체를 마음대로 뒤지지 않으려면 어떤 문이 필요한가?

연주자는 건반을 한 번 더 누른다. 메시지가 건너가고 신시사이저가 응답한다. 오래된 악기는 여전히 악기다. 문지기도 음악을 막지 않았다. 내부 서랍을 열겠다는 손에만 다른 열쇠를 요구했다.