Teenage Engineering PO-32의 "음파 데이터 전송"을 리버스 엔지니어링한 오픈소스 프로젝트

소리로 데이터를 주고받는 신디사이저가 있다고?

Teenage Engineering이라는 회사를 아시나요? 스웨덴의 전자제품 회사인데, 디자인이 예쁘면서도 기능이 독특한 음악 장비를 만들어서 음악 하는 분들 사이에서 꽤 유명해요. 그중에 PO-32라는 포켓 신디사이저가 있는데요, 이 장비에는 아주 재미있는 기능이 하나 있어요. 바로 "어쿠스틱 모뎀"이에요.

어쿠스틱 모뎀이 뭐냐면, 말 그대로 소리를 통해 데이터를 전송하는 방식이에요. 예전에 전화선으로 인터넷에 연결하던 다이얼업 모뎀 기억하시나요? (나이가 좀 있으신 분들은 "삐리리리릭" 하는 그 소리를 기억하실 거예요.) 그것과 비슷한 원리로, PO-32는 스피커에서 특정 패턴의 소리를 내보내고, 다른 PO-32의 마이크가 그 소리를 받아서 데이터를 복원하는 거예요. 이걸 통해 사운드 패치(신디사이저의 소리 설정값)를 기기 간에 주고받을 수 있죠.

이 프로토콜을 완전히 분석해서 오픈소스 라이브러리로 만든 프로젝트가 바로 libpo32예요.

리버스 엔지니어링, 어떻게 해낸 걸까

이 프로젝트의 핵심은 Teenage Engineering이 공식적으로 공개하지 않은 음파 전송 프로토콜을 완전히 해독한 거예요. 공식 문서가 없으니까 소리 신호 자체를 녹음하고 분석해서 어떤 구조로 데이터가 인코딩되어 있는지 알아낸 거죠.

기술적으로 좀 더 들어가볼게요. 이 어쿠스틱 모뎀은 FSK(Frequency-Shift Keying, 주파수 편이 변조) 방식을 사용해요. FSK가 뭐냐면, 데이터의 0과 1을 서로 다른 주파수의 소리로 표현하는 거예요. 예를 들어 "삐~" 하고 높은 소리가 나면 1이고, "부~" 하고 낮은 소리가 나면 0인 식이죠. 이 방식은 아날로그 환경에서도 꽤 안정적으로 데이터를 전달할 수 있어서, 노이즈가 있는 환경에서도 어느 정도 동작해요.

libpo32는 이 FSK 신호를 디코딩하고 인코딩하는 기능을 구현했어요. 소리를 녹음해서 패치 데이터를 추출할 수도 있고, 반대로 패치 데이터를 소리로 변환해서 PO-32에 전송할 수도 있는 거예요. 이 라이브러리를 사용하면 컴퓨터에서 직접 PO-32의 사운드 패치를 편집하고 관리할 수 있게 되는 셈이죠.

프로젝트는 Swift로 작성되어 있고, Apple 플랫폼(macOS, iOS)에서 사용할 수 있어요. 오디오 처리에는 Apple의 Core Audio 프레임워크를 활용하고 있죠.

왜 이게 기술적으로 흥미로운 걸까

이 프로젝트가 그냥 "음악 장비 해킹" 수준에서 끝나는 게 아니라, 여러 가지 기술적으로 흥미로운 요소가 있어요.

우선, 물리 레이어 통신 프로토콜의 리버스 엔지니어링이에요. 보통 리버스 엔지니어링이라고 하면 바이너리 분석이나 API 리버싱을 떠올리기 쉬운데, 이건 실제 아날로그 신호를 분석한 거라 다른 차원의 재미가 있어요. 오실로스코프(파형 측정 장비)로 신호를 관찰하고, 주파수 분석을 통해 데이터 인코딩 방식을 알아내야 하거든요.

또한 "소리로 데이터 전송" 자체가 여전히 실용적인 기술이에요. 블루투스나 Wi-Fi가 없는 초저가 디바이스, 에어갭(네트워크가 완전히 격리된 환경) 간의 데이터 전달, 또는 추가 하드웨어 없이 스마트폰 마이크와 스피커만으로 기기 간 통신을 구현해야 하는 경우에 어쿠스틱 모뎀이 쓰이곤 해요. 실제로 인도의 일부 결제 시스템에서 이 방식을 사용한 사례도 있어요.

비슷한 시도들, 업계 맥락

소리를 이용한 데이터 전송은 Teenage Engineering만의 아이디어는 아니에요. Chirp(현재 Sonos에 인수됨)라는 회사가 초음파 대역을 이용한 데이터 전송 SDK를 제공했었고, Google의 Nearby Connections API도 초음파를 활용한 적이 있어요. QR 코드의 "청각 버전"이라고 생각하면 쉬운데, QR 코드가 카메라로 읽는 시각적 데이터 전송이라면, 어쿠스틱 모뎀은 마이크로 듣는 청각적 데이터 전송인 셈이죠.

리버스 엔지니어링 관점에서 보면, 이 프로젝트는 하드웨어 해킹 커뮤니티의 전형적인 좋은 사례예요. 제조사가 프로토콜을 공개하지 않았을 때, 커뮤니티가 직접 분석해서 오픈소스 구현을 만들어내는 건 소비자의 수리권(Right to Repair)과도 연결되는 중요한 흐름이거든요.