1인 개발자 125M 모델, 아이폰서 피아노 자동완성

개발자는 거의 1년에 걸쳐 열네 차례 실험을 거쳐 이 결과물에 도달했다고 밝혔다. "Think GitHub Copilot, but for piano" — 그가 블로그 글 서두에 남긴 한 줄이 프로젝트의 목표를 압축한다.

MIDI를 어떻게 쪼개야 모델이 배울 수 있는가

MIDI 파일은 녹음된 소리가 아니라 '건반을 눌렀다', '뗐다', '페달을 밟았다' 같은 이벤트의 나열이다. 이 이벤트를 트랜스포머가 읽을 수 있는 토큰 시퀀스로 바꾸는 과정에서 가장 큰 난관이 나왔다. 음 하나마다 켜기·끄기 이벤트를 따로 만드는 방식은 모델이 끄기 신호를 잊어버려 음이 계속 울리는 오류를 자주 냈고, 특히 실시간에 가까운 소형 모델에서 문제가 심했다.

개발자는 여러 시행착오 끝에 음 하나를 한 번에 표현하는 방식을 택했다. 음표마다 이전 음과의 시간 간격(delta_onset), 음높이, 길이, 세기 등 네 개 범주형 값을 함께 담아, 트랜스포머 backbone이 필드마다 네 번씩 돌던 것을 음표 하나당 한 번으로 줄였다. 이 설계 변경이 초당 108개 음이라는 속도를 가능하게 한 핵심이었다고 그는 설명했다. 서스테인 페달 역시 별도 이벤트로 넣지 않고, 페달이 눌린 시간을 음의 실제 지속 시간에 반영하는 방식으로 전처리 단계에서 단순화했다.

데이터는 양보다 질 — 5배 늘렸더니 오히려 나빠졌다

최종 데이터셋은 공개 저작권이 만료된 클래식 음악 위주로 모은 수십만 개 MIDI 파일, 약 3억 건의 노트 이벤트로 구성됐다. 개발자는 데이터 양을 5배가량 늘리는 실험도 해봤지만 결과 모델의 품질은 오히려 떨어졌다. 정제와 선별이 단순히 데이터를 더 넣는 것보다 중요했다는 게 그의 결론이다.

음악 생성 모델을 다루는 시도는 이 프로젝트만은 아니다. 미니맥스, 가사만 넣으면 5분 완곡 뽑는 음악모델 공개

선호도 학습으로 완성도를 끌어올리다

곡 이어치기는 정답이 하나가 아닌 문제다. held-out 곡에서 다음 음 하나만 '정답'으로 놓고 학습하는 교차엔트로피 방식은 음악의 기본 문법은 가르치지만, 실제로 자연스럽게 들리는 완성곡을 만드는 데는 한계가 있었다. 개발자는 이를 보완하기 위해 Gemini 3.5 Flash를 이용해 두 완성본 중 어느 쪽이 나은지 쌍으로 비교하는 평가 체계를 만들고, 이 선호도 데이터로 DPO(직접 선호도 최적화) 후속 학습을 진행했다. 프롬프트를 얼마나 잘 이어받았는지와 그 자체로 음악적으로 좋은지를 별도 기준으로 나눠 평가한 뒤, 전자를 DPO의 핵심 신호로 삼았다.

DPO 적용 뒤 쌍대 평가에서 기존 베이스 모델보다 나은 것으로 선택된 비율이 69%를 넘었다. 베타(β) 값을 바꿔가며 실험한 결과는 다음과 같다.

β 값	결과
0.01	모델 성능 개선
0.03	모델 성능 개선(최적 구간)
0.10	원본에서 과도하게 밀려나 성능 저하

개발자는 노이즈가 많은 선호도 판정 중 평가자가 일관되게 동의한 쌍만 남긴 '컨센서스 데이터셋'이 이 실험 중 가장 좋은 결과를 냈다고 밝혔다.

아이폰에서 실시간으로 돌리기까지

완성된 모델은 PyTorch에서 Core ML로 변환하고 가중치를 INT8로 양자화했다. 앱을 처음 실행할 때는 Core ML 런타임이 기기 하드웨어에 맞춰 모델을 최적화하느라 다소 느리다고 개발자는 전했다. 모델은 최대 512개 노트 길이의 컨텍스트로 학습됐지만, 더 긴 연주 세션을 지원하기 위해 컨텍스트가 한계에 가까워지면 최근 384개 노트만 남기고 그 지점부터 컨텍스트를 다시 구성하는 방식을 적용했다.

앱스토어 심사는 첫 버전 승인까지 11일이 걸렸다고 한다. 현재는 top-k, top-p, min-p, XTC, top-h, Mirostat v2 등 여러 샘플링 방식을 사용자가 고를 수 있게 한 새 버전이 심사를 기다리고 있다. 이런 샘플링 옵션은 모델이 다음 음을 고를 때 다양성과 안정성을 어떻게 조절할지를 결정하는 설정값이다.

어떻게 써보나

RollTab은 MIDI 건반과 아이폰 또는 아이패드가 있는 사용자를 대상으로 무료로 공개됐다. 사용 방식은 원문에서 확인되는 범위로 간단하다. 우선 MIDI 피아노를 케이블이나 무선으로 아이폰·아이패드에 연결한다. 그다음 RollTab 앱을 실행하고, 건반에서 몇 개 음을 짧게 연주한다. 이 몇 개 음이 곧 모델에 건네는 프롬프트 역할을 하고, 모델은 이를 이어받아 나머지 부분을 기기 안에서 자동으로 생성한다.

원문에 따르면 프롬프트로 넣는 음의 개수가 결과 품질에 영향을 준다. 개발자의 청취 평가에서 4개 음짜리 프롬프트는 문맥이 부족해 가장 까다로웠고, 8개 음은 다소 나아졌으며, 16~32개 음을 넣었을 때 모델이 흐름을 더 안정적으로 파악했다. 예를 들어 좋아하는 곡의 도입부 몇 소절을 쳐 넣으면 그 스타일을 이어받은 즉흥 변주를 얻을 수 있고, 즉흥 연주 중 막힌 부분에서 잠시 멈추면 모델이 다음 전개를 제안해주는 식으로 쓸 수 있다.

에디터의 시선

이 프로젝트가 보여주는 건 대형 연구소가 아니어도 좁은 문제 하나를 끝까지 파고들면 실용적인 결과가 나온다는 사실이다. Aria, Moonbeam, MIDI-GPT 같은 기존 심볼릭 음악 생성 연구는 대체로 대규모 모델과 연구 인프라를 전제로 한다. 개발자는 완성 뒤에야 Aria, Moonbeam, MIDI-GPT 같은 기존 논문과 자신의 접근을 비교했다고 밝혔는데, 이 순서 자체가 흥미롭다. 기존 문헌을 먼저 흡수하지 않고 직접 부딪혀 문제를 재발견한 뒤 검증한 셈이다.

이런 소형 온디바이스 모델을 다뤄본 사람이라면 익숙한 패턴이 하나 있다. 데이터를 늘리면 늘릴수록 좋아질 거라는 기대가 실제로는 자주 배신당한다는 점이다. 이 프로젝트에서 데이터를 5배 늘렸을 때 성능이 오히려 떨어진 사례는, 텍스트 모델이든 이미지 모델이든 음악 모델이든 정제되지 않은 대량 데이터보다 잘 걸러진 소량 데이터가 낫다는 원칙이 도메인을 가리지 않는다는 걸 다시 보여준다.

국내에서 온디바이스 생성 모델을 검토하는 팀이라면 이 사례에서 챙길 대목은 두 가지다. 하나는 DPO 같은 선호도 기반 후속 학습이 언어 모델뿐 아니라 시계열 성격의 생성 문제에도 유효하다는 점이고, 다른 하나는 Core ML 양자화·컨텍스트 재구성 같은 배포 단계의 잔손질이 모델 설계 자체만큼이나 실사용 성능을 좌우한다는 점이다. 논문 재현보다 배포 파이프라인에 쓰는 시간이 실제로는 더 길어질 수 있다는 뜻이다.

앞으로 몇 달 안에 비슷한 방식으로 좁은 창작 영역(작곡 보조, 가사 이어쓰기, 안무 시퀀스 등)을 온디바이스로 옮기려는 개인 개발자 프로젝트가 더 나올 가능성이 크다. Core ML이나 유사 온디바이스 런타임의 양자화 도구가 계속 쉬워지고 있어, 100M대 모델을 스마트폰에서 실시간으로 돌리는 문턱이 낮아지고 있기 때문이다.