구형 iRig BlueBoard 복구 삽질기
한동안 합주를 갈 때 아이폰을 두 대씩 들고 다녔다. 기타 이펙터를 발로 제어하려고 iRig BlueBoard를 쓰고 있었는데, 예전에 쓰던 iPhone SE에서는 연결되던 보드가 지금 쓰는 iPhone 12 Pro에서는 iRig BlueBoard 앱으로 붙지 않았다. 보드 자체는 멀쩡하고 아직 쓸 만했다. 결국 오래된 앱과 오래된 펌웨어 조합이 지금 iOS 환경에 맞지 않게 된 거라 생각했다.
처음에는 단순한 블루투스 페어링 문제라고 생각했는데 찾아보니 아니었다. 이 기기는 일반적인 블루투스 MIDI 컨트롤러처럼만 동작하는 물건이 아니었고 구형 펌웨어에서는 iRig BlueBoard 전용 앱이 중간에서 블루투스 제어 메시지를 받아 MIDI로 바꿔 준다고 한다. 펌웨어를 업데이트하면 MIDI over Bluetooth 모드로 직접 쓸 수 있었다. (IK Multimedia FAQ)
공식 매뉴얼 기준으로 업데이트된 BlueBoard는 전원을 켤 때 누르는 버튼에 따라 모드가 나뉜다. 문제는 내 보드가 이 동작을 하지 않았다는 점이다. 전원을 켤 때 A, B, C를 눌러도 버튼에 불이 들어오지 않았다. 업데이트 전 펌웨어일 가능성이 높았다.
일단 Codex에게 맡겨봤다
펌웨어를 올리려면 Windows PC에 직접 연결해야 한다고 했다. 나는 평소 Mac만 쓴다. 합주 때마다 폰을 두 대 들고 다니는 것도 싫었지만, 이 낡은 장비 하나 때문에 Windows PC를 구하는 것도 싫었다.
마침 Codex 토큰도 남아 있었다. 그래서 "그냥 Codex로 역분석해서 어떻게든 우회할 수 있지 않을까?"라고 생각했다. 공개 매뉴얼을 읽히고, BlueBoard가 블루투스로 어떤 정보를 주고받는지 관찰하는 작은 도구를 만들게 했다. 목표는 단순했다. 버튼을 눌렀을 때 어떤 신호가 나오는지 알아내고, 그 신호를 일반 MIDI 입력처럼 바꿔 쓸 수 있는지 보는 것.
처음에는 가능성이 있어 보였다. BlueBoard는 표준 MIDI 장치처럼 바로 신호를 내보내는 게 아니라, 전용 앱과 따로 정해진 프로토콜로 대화하는 구조에 가까웠다. 버튼을 누를 때마다 일정한 패턴의 값이 들어오는 건 확인할 수 있었다. 각 버튼이 어떤 값에 대응되는지도 어느 정도 Codex가 추정할 수 있었다.
그래서 여기까지는 "어? 될 수도 있겠는데?" 싶었다. 버튼 신호만 안정적으로 읽을 수 있으면, 완전한 대체 앱은 아니더라도 임시 연결 도구 정도를 만들 수 있을 것 같았다.
하지만 진짜 문제는 그 다음이었다. 공식 앱이 장치와 처음 연결될 때 어떤 순서로 인사하고, 어떤 값을 주고받아야 정상 세션으로 인정되는지 알 수 없었다. Codex는 몇 가지 가능성을 추정했다. 그 추정이 맞는지 확인하려면 실제 장치에 값을 써보는 실험이 필요했다.
별생각 없이 go를 외쳤고, 이 실험 뒤로 기존에 되던 연결도 안 되기 시작했다.
결국 벽돌이 됐다...
불편해서 시작한 일이었는데, 아예 못 쓰는 장비가 됐다.
AI가 못한 일
Codex가 못했다는 말은 정확히는 반만 맞다. 공개 매뉴얼을 읽고, 장치가 어떤 방식으로 앱과 대화하는지 추정하고, 실제 버튼 입력에서 반복되는 패턴을 찾는 시도를 했다. 내가 직접 조사했다면 훨씬 오래 걸리고 중간에 포기했을 것이다.
문제는 내가 과정을 제대로 이해하지 않은 채 다음 단계를 온전히 맡겨버렸다는 데 있었다. 한동안 AI를 적극적으로 쓰면서, 만나는 거의 모든 문제를 풀어줄 수 있는 은탄환처럼 생각했던 것 같다. 특히 "관찰 도구를 만들고 값을 읽는다"는 말은 안전하게 들렸다. 하지만 실제로는 그 장치가 어떤 상태인지, 어떤 값이 읽기 전용이고 어떤 값이 설정을 바꾸는지, 내가 충분히 이해하지 못했다.
제조사가 공개하지 않은 연결 절차를 추측으로 맞춰 보는 순간부터는 단순한 분석이 아니었다. 실제 장치에 값을 보내 쓰는 실험이었다. 화면 안의 코드와 달리, 물리 장비는 "실패하면 되돌리면 되지"가 통하지 않는다. 호환성이나 펌웨어 문제는 제조사의 복구 경로부터 따라가야 한다는 것을 덤으로 배웠다.
결국 공식 절차로 돌아갔다
IK Multimedia 지원팀과 몇 번 이메일을 주고받으며 해결 방법을 모색했다.
먼저 개발자 문서가 있는지 물었다. 과거에 iRig BlueBoard Developer's Manual을 요청할 수 있었다는 흔적이 있었기 때문이다. 답변은 문서를 제공할 수 없다는 내용이었다. 대신 MIDI over Bluetooth 모드를 쓰면 전용 앱 없이 사용할 수 있으니 매뉴얼의 해당 섹션을 보라는 안내를 받았다.
내 기기는 배터리 수납부 안에 Mini USB 포트가 있는 구형 모델이고, A/B/C 버튼을 누른 채 켜도 모드 표시가 되지 않는다고 설명했다. iOS용 BlueBoard Updater 앱이 인식하지 않는 것도 구형 모델이라면 자연스러운 일이라고 덧붙였다. Windows 기반 펌웨어 업데이터를 어디서 받아야 하는지, IK Product Manager 안에서 찾을 수 없다면 대체 다운로드 방법이 있는지 물었다.
지원팀은 직접 다운로드 링크와 함께 복구 절차를 보내줬다. 복구 절차는 구체적이었다. 업데이터를 Windows 8 호환성 모드로 실행하고, Windows Search를 끈 뒤, 장치가 외장 드라이브처럼 잡히는 동안 내부 파일을 정리해 새 펌웨어가 들어갈 공간을 만드는 방식이었다. 그래도 답변만으로 바로 해결되지는 않았다. 비슷한 이슈를 겪은 사람이 있는지 더 찾아보다가 Loopy Pro 포럼의 오래된 글도 발견했다. 거기에도 Windows 업데이터를 Program Files (x86) 아래에서 실행해야 한다는 이야기, 업데이트 도중 연결이 끊겨 벽돌이 됐다는 댓글, 외국 낯선이의 긴 업데이트 삽질기가 남아 있었다. (Loopy Pro Forum)
결국 Windows PC를 구해서 직접 해야 했다. 본가에 들러 어머니가 안 쓰시는 오래된 Windows PC를 빌려왔다.
여기까지 와서도 한 번에 깔끔하게 되지는 않았다. 처음에는 BlueBoard가 외장 드라이브처럼 잡혔다가 곧바로 사라지기를 반복했다. 지원팀 메일에도 "반복해서 연결됐다 끊기면 다른 USB 케이블을 써보라"는 말이 있었기 때문에, 다이소에 가서 USB 데이터 케이블을 새로 사 와서 다시 시도했다. 하지만 케이블 문제가 아니었다. 증상은 그대로였다. 돌아보면 Windows Search를 비활성화만 하고 재부팅하지 않은 게 문제였던 것 같다. Windows Search를 끄는 것만으로는 부족했고, 비활성화한 뒤 재부팅 후 연결이 유지됐다.
나중에 연결해서 확인해보니 보드에는 2013년 펌웨어가 설치돼 있었다.
정리하면 핵심은 연결이 유지되는 짧은 순간에 기존 파일을 지워 새 펌웨어가 들어갈 공간을 만들고, 절대 케이블을 뽑지 않은 상태에서 업데이터가 새 파일을 밀어 넣는 것이었다. 최종적으로 성공한 절차는 대략 이랬다.
- 펌웨어 업데이터를 내려받고, 지정된
Program Files (x86)하위 폴더에 둔다. - 실행 파일 속성에서 Windows 8 호환성 모드와 관리자 권한 실행을 설정한다.
- 다운로드받은 파일 차단 해제 설정이 보이면 해제한다.
- Windows Search 서비스를 사용 안 함으로 바꾸고 재부팅한다.
- 업데이터 앱을 관리자 권한으로 먼저 실행한다.
- BlueBoard를 케이블로 연결하고, D 버튼을 누른 채 전원을 켠다.
- 외장 드라이브처럼 잡히면 내부의
.cfg,.bin파일을 지워 새 펌웨어가 설치될 공간을 만든다. 이때 탐색기나 장치 연결이 끊기면 안 된다. - 업데이터에서 검색과 업데이트를 반복해 success가 뜰 때까지 진행한다.
- 업데이트가 끝나면 Windows Search 설정을 원래대로 돌린다.
펌웨어 업데이트를 무사히 마치고 나서 드디어 보드는 다시 살아났다. 이제는 전원을 켤 때 버튼으로 모드를 선택할 수 있고, MIDI over Bluetooth 모드도 사용할 수 있게 됐다.
돌아보니
이번 일은 AI를 어디까지 믿을 수 있는지보다, AI를 쓸 때 내가 어디까지 이해하고 있어야 하는지를 생각하게 했다. Codex는 자료를 빠르게 정리하고, 장치가 어떤 흐름으로 반응하는지 확인하는 데 도움이 됐다.
하지만 내가 진행을 이해하지 못한 채 "알아서 처리해줘"라고 넘기는 순간, 그대로 사고가 났다. 하드웨어 복구 문제에서는 "가능해 보인다"와 "해도 된다" 사이의 거리가 컸다. 구형 펌웨어를 쓰는 오래된 장비, 제조사 전용 프로토콜, OS 호환성 문제가 있으니 더 그랬다. AI가 그럴듯한 다음 실험을 제안해도, 그 실험이 장비 상태를 바꿀 수 있다면 먼저 멈춰야 했다.
이번에는 운 좋게 제조사 지원팀이 펌웨어 업데이터와 절차를 보내줬고, 포럼에 남아 있던 다른 사람들의 실패 기록까지 참고한 끝에 복구할 수 있었다. AI를 쓰는 지금도 이런 포럼 글은 여전히 중요하다는 걸 느꼈다. 공식 문서가 알려주지 않는 실패 지점은 결국 다른 사람의 삽질 기록에서 나왔다.
다음에 비슷한 일을 한다면 순서를 바꿀 것이다. 먼저 공식 문서와 제조사 권고를 확인하고 시도해볼 것이다. 모르는 분야를 AI에게 맡길 때는 실패할 가능성과 복구 경로를 먼저 염두에 둘 것이다. AI는 만능이 아니고, 내가 모르는 작업을 대신 책임져 주지도 않았다. AI에게 맡길 범위를 정하기 전에, 실패했을 때 되돌아올 길부터 확인해야 했다. 귀찮음을 줄이려고 이해를 건너뛰었다가, 오히려 더 먼 길로 돌아갔다.
참고한 자료: