40년 된 신디사이저, 브라우저랑 연결하니 멈춰버렸다
요즘은 브라우저만 있어도 악기를 제어할 수 있어요. Web MIDI API라는 게 있거든요. 이게 뭐냐면, 크롬 같은 브라우저에서 자바스크립트 코드로 신디사이저나 미디 건반 같은 음악 장비랑 직접 데이터를 주고받게 해주는 기능이에요. 별도 프로그램을 깔 필요 없이 웹페이지 하나로 신디사이저 음색을 편집하거나, 저장된 소리 설정(패치)을 백업하는 도구를 만들 수 있는 거죠.
그런데 한 개발자가 1983년에 나온 빈티지 신디사이저를 Web MIDI로 다뤄보려다가 황당한 일을 겪었어요. 잘 돌아가던 악기가 데이터를 받자마자 그대로 얼어붙어 버린 거예요. 우리가 흔히 "프로그램이 죽었다"고 할 때의 그 crash가, 무려 40년 된 하드웨어 악기에서 일어난 거죠. 코드는 분명 표준대로 짰는데도요.
왜 옛날 악기는 버티지 못할까
이걸 이해하려면 MIDI가 어떤 물건인지부터 알아야 해요. MIDI는 1983년에 정해진 규격이에요. 놀랍게도 40년이 넘은 지금도 거의 그대로 쓰이고 있죠. 그런데 이 규격은 1초에 약 3,125바이트(31,250bps)만 주고받도록 설계됐어요. 바이트 하나 보내는 데 약 320마이크로초가 걸리는 셈이죠. 1983년 기준으로는 충분히 빠른 속도였어요.
문제는 요즘 컴퓨터예요. USB-MIDI나 Web MIDI는 데이터를 이 옛날 속도보다 훨씬 빠르게, 그것도 한꺼번에 몰아서(burst) 쏟아낼 수 있거든요. 반면 1983년 악기 안에 든 칩은 8비트짜리 느린 마이크로프로세서에, 들어온 데이터를 잠깐 담아두는 입력 버퍼도 아주 작아요. 빠른 컴퓨터가 데이터를 와르르 보내면, 악기가 미처 처리하기도 전에 버퍼가 넘쳐버려요. 이걸 버퍼 오버플로우라고 하는데, 넘친 데이터가 엉뚱한 메모리를 건드리면서 악기가 그냥 뻗어버리는 거예요.
특히 위험한 게 SysEx(시스템 익스클루시브) 메시지예요. 신디사이저의 음색 설정 전체를 통째로 주고받을 때 쓰는 큰 데이터 덩어리인데, 한 번에 수백~수천 바이트씩 되거든요. 작은 버퍼를 가진 옛날 악기 입장에선 소화하기 버거운 양이죠.
해결법은 의외로 단순해요: 악기 속도에 맞춰주기
해결의 핵심은 "내 컴퓨터가 빠르다고 빠르게 보내지 말고, 받는 악기의 속도에 맞춰 천천히 보내자"예요. 이걸 스로틀링(throttling), 또는 페이싱(pacing)이라고 해요. 수도꼭지를 활짝 열지 않고 졸졸 흐르게 조절하는 거랑 비슷하죠.
구체적으로는 원래 MIDI가 가진 한계 속도, 즉 바이트당 약 320마이크로초라는 리듬을 지켜주는 거예요. Web MIDI의 send() 함수는 두 번째 인자로 타임스탬프를 받을 수 있는데, "이 메시지는 몇 밀리초 뒤에 보내줘"라고 미리 예약할 수 있어요. 이걸 이용해서 메시지들을 일정 간격으로 줄 세워 보내면 악기가 차분히 받아낼 수 있죠.
큰 SysEx 데이터는 한 번에 다 던지지 말고 작은 조각으로 잘라서(chunk) 보내고, 조각 사이사이에 잠깐의 쉬는 시간(delay)을 끼워 넣어요. 가능하면 악기가 "다 받았다"는 신호를 줄 때까지 기다렸다가 다음 조각을 보내면 더 안전하고요.
업계 맥락에서 보면
이 이야기는 사실 "옛날 하드웨어와 최신 웹 기술을 어떻게 연결할까"라는 더 큰 주제의 한 장면이에요. Web MIDI는 크롬과 엣지에선 잘 되고, 한동안 막혀 있던 사파리와 파이어폭스도 점차 지원을 넓혀가는 중이에요. 덕분에 예전엔 네이티브 앱으로만 만들던 신디사이저 에디터나 패치 관리 도구를 이제 웹으로 만드는 흐름이 생기고 있죠.
비슷한 도전은 음악 쪽 말고도 많아요. RtMidi 같은 네이티브 라이브러리, 또 시리얼 통신으로 옛날 장비를 제어하는 작업들 전부 "최신 시스템은 빠른데 상대 장비는 느리다"는 같은 벽에 부딪혀요. 결국 해법도 비슷하게, 빠른 쪽이 느린 쪽을 배려하는 방식으로 수렴하고요.
한국 개발자에게
이 사례에서 건질 교훈은 음악 하는 사람에게만 해당되는 게 아니에요. 빠른 시스템과 느린 시스템을 연결할 때는 항상 느린 쪽의 한계를 존중해야 한다는 거죠. 이건 IoT 기기 제어, 임베디드 시리얼 통신, 심지어 빠른 서비스가 느린 외부 API를 호출할 때도 똑같이 적용돼요. 백프레셔(backpressure), 레이트 리미팅(rate limiting), 버퍼링 같은 개념이 다 여기서 나와요.
거기에 더해, 창작 도구를 만들고 싶은 분이라면 Web MIDI는 진입 장벽이 낮은 재밌는 놀이터예요. 브라우저랑 미디 건반 하나만 있으면 오늘 당장 소리 나는 웹 앱을 만들어볼 수 있거든요.
마무리
핵심은 한 줄로 이래요. "빠른 게 항상 정답은 아니다. 받는 쪽이 감당할 수 있는 속도로 보내는 게 진짜 정답이다." 40년 된 악기가 우리에게 시스템 설계의 기본을 다시 알려준 셈이죠.
여러분은 최신 시스템과 오래된 장비/레거시를 연결하면서 비슷한 "속도 차이" 문제로 고생한 적 있나요? 어떻게 풀어내셨는지 경험이 궁금해요.
🔗 출처: Hacker News