블로그로 돌아가기
MusicXML 완전 정리: 모든 악보 앱 뒤에 숨은 파일 포맷

MusicXML 완전 정리: 모든 악보 앱 뒤에 숨은 파일 포맷

MIDI Lab2026년 9월 11일·3분 소요
musicxmlsheet-musicnotationmusic-production

모르는 사이에 써온 포맷

MuseScore에서 악보를 열어봤거나, Sibelius에서 표기 파일을 내보냈거나, Finale로 곡을 가져왔거나, 만든 프로그램과 전혀 다른 앱에서도 문제없이 열리는 악보 파일을 다운로드한 적이 있다면 — 그 중심에는 거의 항상 MusicXML이 있었을 겁니다. 이는 필기(written) 음악을 위한 표준 교환 포맷으로, 오디오에서 .mp3가, 문서에서 .pdf가 하는 것과 같은 역할을 표기법 분야에서 해냅니다: 서로 다른 프로그램들이 읽고 쓰기로 합의한 공통 포맷 덕분에 파일이 특정 소프트웨어 하나에 묶이지 않는 거죠.

MusicXML 파일 안에는 실제로 무엇이 있을까

페이지를 고정된 이미지로 담는 PDF나, 고정된 녹음을 담는 오디오 파일과 달리, MusicXML은 구조화되고 편집 가능한 데이터입니다 — 텍스트 기반 마크업 포맷인 XML로, 음악가가 음악을 이야기하는 방식 그대로 음악을 기술합니다:

  • 음높이, 길이, 마디 내 위치를 가진 음표들.
  • 암시가 아니라 명시적으로 기재된 조표와 박자표.
  • 악기나 오선별로 지정된 음자리표.
  • 얼마나 크게, 얼마나 끊어서 혹은 이어서 연주할지, 어디서 숨을 쉴지를 나타내는 셈여림, 아티큘레이션 등 각종 표기.
  • 단일 악기를 넘어서는 모든 것 — 풀 밴드나 오케스트라 악보 — 를 위한 여러 성부(파트).

이 모든 게 납작한 이미지가 아니라 구조화된 데이터이기 때문에, MusicXML 파일을 여는 프로그램은 단순히 보여주기만 하는 게 아니라 조를 바꾸거나, 악기 편성을 바꾸거나, 템포를 조정하거나, 풀 스코어에서 한 파트만 뽑아내거나, 오디오로 재생할 수도 있습니다. 같은 곡의 PDF로는 이런 걸 전혀 할 수 없습니다 — 그저 음표들을 찍어낸 그림일 뿐이니까요.

표기 도구들이 이 포맷을 표준으로 삼은 이유

공용 포맷이 없던 시절에는 서로 다른 표기 프로그램 사이에서 악보를 옮기려면 대체로 처음부터 다시 만들어야 했습니다 — MuseScore는 Finale 고유 파일을 열 수 없었고, Sibelius는 Dorico 고유 프로젝트를 열 수 없었죠. MusicXML은 대부분의 교환 포맷이 자신의 영역에서 문제를 푸는 방식 그대로 이 문제를 해결했습니다: 어느 한 프로그램의 고유 포맷이 되는 게 아니라, 모든 프로그램이 가져오기와 내보내기를 지원하기로 합의한 공통 목표점이 되는 방식으로요. 한 표기 앱에서 곡을 쓰고 MusicXML로 내보낸 뒤, 완전히 다른 프로그램에서 열어도 음표와 리듬, 구조가 그대로 유지됩니다.

MusicXML 파일은 실제로 어디서 오는가

몇 가지 흔한 경로가 모두 같은 포맷으로 수렴합니다:

  • MuseScore나 Sibelius 같은 표기 소프트웨어로 직접 작성한 뒤 내보내는 경우.
  • MIDI에서 변환하는 경우 — MIDI는 정확한 음과 타이밍 데이터를 담고 있지만 조표, 마디, 음자리표 같은 표기 개념은 담고 있지 않으므로, 악보로 표시되기 전에 MIDI-to-MusicXML 단계에서 이를 정해야 합니다.
  • 오디오 트랜스크립션에서 생성되는 경우 — AI나 알고리즘이 녹음을 듣고 무엇이 연주되고 있는지 추론한 뒤, 표준 표기 도구에서 열 수 있도록 결과를 MusicXML로 출력합니다.

어느 경로로 왔든, 일단 유효한 MusicXML 파일이 되고 나면 이후의 모든 도구는 이를 동일하게 취급합니다 — 표기 소프트웨어는 그 음들이 건반에서, MIDI 파일에서, 아니면 트랜스크립션 알고리즘에서 나왔는지 알지도 신경 쓰지도 않습니다.

이 포맷 자체의 실용적인 쓰임새

  • 구조나 서식을 잃거나 음표를 다시 입력할 필요 없이 표기 프로그램 사이에서 악보를 옮길 때.
  • 협업자가 어떤 소프트웨어를 쓰든 그들의 표기 소프트웨어가 열 수 있는 형태로 곡을 공유할 때.
  • 특정 회사의 소프트웨어가 계속 살아남거나 호환성을 유지하는지에 얽매이지 않는 형태로 음악을 보관할 때.
  • 렌더링된 이미지가 아니라 구조화된 텍스트이기 때문에 소프트웨어가 직접 유효한 MusicXML을 작성할 수 있는 프로그래밍 방식 생성 — 결정론적인 MIDI-to-표기법 파이프라인이 손으로 "그릴" 필요 없이 악보를 만들어내는 방식이 바로 이겁니다.

이게 어떻게 맞아떨어지는가

MIDI나 오디오를 읽을 수 있는 악보로 바꾸는 모든 것은, 그 밑에서는 MusicXML 파일을 만든 뒤 이를 렌더링하고 있는 겁니다 — MIDI를 악보로 변환하기도, AI 오디오 트랜스크립션도 마찬가지입니다. 포맷 자체를 이해하면 왜 MIDI 기반 변환은 정확할 수 있고 오디오 기반 변환은 추측에 의존할 수밖에 없는지가 분명해집니다: 둘 다 결국 MusicXML로 끝나지만, 그중 하나만 처음부터 이미 정확한 데이터에서 출발했으니까요.