C언어로 음악을 연주한다고? 'Prayer in C' 구현으로 본 MIDI 프로그래밍의 실체

"단순한 데이터 스트림에서 WAV 파일 출력까지, 저수준 언어로 음악을 다룰 때 마주하는 도전과 선택지"

가끔 코드를 짜다 보면 “이걸 굳이 이렇게까지 해야 하나?” 싶은 순간이 있죠. 그런데 MIDI라는 녀석을 만나면 생각이 좀 달라집니다. 사실 MIDI는 구조가 정말 단순해서, 스펙 문서만 제대로 읽는다면 단 15분 만에 필요한 코드를 직접 짤 수 있을 정도거든요 [3]. 저도 처음엔 음악 프로그래밍이라고 하면 복잡한 신호 처리나 수학적 계산이 필수라고 생각했는데, 막상 뚜껑을 열어보니 생각보다 훨씬 담백한 ‘데이터 놀이’에 가깝더라고요.

MIDI는 단순한 메시지 프로토콜이라 C언어로 충분히 구현할 수 있습니다. 하지만 단순히 “소리가 나게 하는 것”을 넘어 실제 서비스 수준의 안정성을 확보하려면, 어떤 라이브러리를 선택할지 그리고 C언어 특유의 메모리 관리를 어떻게 할지가 핵심이 됩니다.

C언어와 MIDI: 왜 이 조합이 여전히 유효할까?

요즘 같은 시대에 굳이 C언어로 음악을 다루는 게 구식처럼 보일 수도 있어요. 하지만 오디오 처리처럼 ‘타이밍’과 ‘효율’이 생명인 작업에서는 여전히 C언어가 왕입니다. 설계 단계부터 CPU 아키텍처의 기능에 직접 접근할 수 있도록 만들어졌기 때문이죠 [6]. 아주 미세한 지연 시간(Latency)조차 허용되지 않는 음악 작업에서 이보다 더 믿음직한 도구는 드뭅니다.

여기서 우리가 짚고 넘어가야 할 게 바로 MIDI의 본질입니다. 흔히 MIDI 파일을 ‘음악 파일’이라고 생각하지만, 사실 MIDI는 소리 데이터가 아니에요. 대신 “도(C) 음을 어떤 세기로, 언제 누르고, 언제 떼라” 같은 음악적 지시를 담은 ‘이벤트의 집합’입니다 [7].

쉽게 말해 MIDI는 오디오 파일이 아니라 ‘디지털 악보’인 셈이죠. 악보를 읽고 연주하는 건 컴퓨터 내장 신시사이저나 외부 악기의 몫이고, 우리 개발자는 그저 정확한 타이밍에 정확한 명령어를 전달하기만 하면 됩니다. 이 과정이 매우 가볍기 때문에 윈도우나 리눅스는 물론, 임베디드나 웹 환경으로 확장하기에도 매우 유리합니다.

구현 전략: 직접 짤 것인가, 라이브러리를 쓸 것인가

실제로 구현하려고 하면 갈림길에 서게 됩니다. “그냥 내가 짤까, 아니면 남이 만든 걸 쓸까?” 상황에 따라 선택지는 크게 세 가지로 나뉩니다.

첫 번째는 직접 구현하는 겁니다. 앞서 말했듯 MIDI는 극도로 단순한 포맷이라 프로토타이핑 단계에서는 직접 짜는 게 가장 빠를 수 있어요 [3].

“MIDI is an extremely simple format and you can probably write whatever code you need in 15 minutes or so…” [3]

(MIDI는 매우 단순한 포맷이라, 필요한 코드를 15분 정도면 직접 작성할 수 있을 겁니다.)

두 번째는 경량 라이브러리를 쓰는 겁니다. 예를 들어 fmidi 같은 도구는 표준 MIDI 파일과 RIFF MIDI 파일을 모두 지원하면서도 C 인터페이스를 제공해 매우 가볍습니다 [2]. 특히 인터넷에서 다운로드한 MIDI 파일들은 표준을 안 지키거나 깨져 있는 경우가 많은데, fmidi는 이런 ‘엉망인 파일’들을 어느 정도 복구해서 읽어주는 관용적인 리더를 갖추고 있어 실무적으로 매우 유용합니다 [2].

마지막은 SDL_mixer 같은 종합 프레임워크를 사용하는 겁니다. 다채널 오디오 믹싱부터 다양한 포맷 지원까지 한 번에 해결해주죠 [3]. 하지만 단순히 MIDI 하나만 다루기에는 너무 무겁다는 느낌, 즉 ‘오버킬(Overkill)’이 될 수 있습니다.

만약 여러분이 직접 MIDI 이벤트를 정의해서 연주하고 싶다면, 아래와 같은 구조의 코드가 기본이 될 거예요.

#include <stdio.h>
#include <stdint.h>

// MIDI 메시지 구조체 정의
typedef struct {
    uint8_t status;   // 메시지 타입 (예: 0x90은 Note On)
    uint8_t data1;    // 음높이 (Pitch)
    uint8_t data2;    // 세기 (Velocity)
} MidiMessage;

void send_midi_note(uint8_t note, uint8_t velocity) {
    MidiMessage msg;
    msg.status = 0x90; // 채널 1, Note On 메시지
    msg.data1 = note;  // 예: 60은 가운뎃 도(C4)
    msg.data2 = velocity; // 0~127 사이의 세기

    // 실제 구현에서는 여기서 OS의 MIDI API나 하드웨어 포트로 데이터를 전송합니다.
    printf("Sending MIDI: Status=0x%02X, Note=%d, Vel=%d\n", msg.status, msg.data1, msg.data2);
}

int main() {
    // 'Prayer in C'의 간단한 멜로디 라인 예시
    uint8_t melody[] = {60, 62, 64, 65}; // 도, 레, 미, 파
    for(int i = 0; i < 4; i++) {
        send_midi_note(melody[i], 100); // 적절한 세기로 연주
    }
    return 0;
}

이 코드는 아주 기초적인 MIDI 메시지 생성 과정을 보여줍니다. 실제로는 이 메시지들을 정확한 시간 간격으로 큐에 쌓아 전송하는 스케줄러가 필요하겠죠.

환경별 출력의 차이: MIDI 재생에서 WAV 저장까지

재미있는 점은 똑같은 C 코드로 짠 ‘Prayer in C’ 구현체라도 실행 환경에 따라 결과물이 완전히 달라진다는 거예요.

윈도우나 리눅스 같은 OS 환경에서는 보통 내장된 MIDI 신시사이저를 이용해 실시간으로 소리를 냅니다 [1]. 우리가 명령어를 보내면 OS가 “아, 도 음을 내라는 거구나” 하고 즉시 소리를 만들어 스피커로 쏴주는 방식이죠.

그런데 웹 브라우저 환경으로 가면 이야기가 달라집니다. 브라우저는 보안과 환경 제약이 많아 실시간 MIDI 출력이 까다롭거든요. 그래서 보통은 MIDI 데이터를 읽어 소리 파형으로 변환한 뒤, 이를 WAV 파일로 렌더링해서 저장하는 방식을 택합니다 [1].

여기서 WAV 포맷이 등장하는데, WAV는 IBM과 마이크로소프트가 만든 비압축 오디오 표준입니다 [8]. MIDI가 ‘악보’라면, WAV는 그 악보를 연주해서 녹음한 ‘테이프’라고 보시면 됩니다. 내부적으로는 LPCM(Linear Pulse-Code Modulation)이라는 비압축 비트스트림으로 저장되기 때문에 음질은 좋지만 용량이 큽니다 [8].

C 프로그래밍의 함정: MIDI 구현 시 흔히 하는 실수

저수준 언어로 오디오를 다루다 보면 정말 어처구니없는 실수들 때문에 밤을 새우곤 합니다. 제가 겪어보고 주변에서 본 가장 흔한 함정 세 가지를 짚어드릴게요.

첫째는 메모리 관리 실패입니다. 오디오 버퍼를 malloc으로 할당하고 제때 free 하지 않으면 메모리 누수가 발생하고, 이미 해제된 포인터를 건드리는 댕글링 포인터 문제는 곧바로 세그멘테이션 폴트(Segmentation Fault)로 이어집니다 [5]. 오디오 스트리밍 중에 프로그램이 픽 꺼지는 최악의 경험을 하고 싶지 않다면, Valgrind 같은 도구로 메모리 검수를 하는 습관을 들이세요 [5].

둘째는 변수 초기화 누락입니다. C언어에서 지역 변수는 자동으로 0으로 초기화되지 않죠 [5]. 초기화되지 않은 변수가 MIDI 데이터로 들어가면, 갑자기 찢어지는 듯한 소음(Noise)이 나거나 예측 불가능한 동작이 발생합니다. “왜 여기서 삑 소리가 나지?” 싶을 땐 변수 초기화부터 확인해 보세요.

셋째는 MIDI 피드백 루프입니다. 하드웨어든 소프트웨어든 MIDI THRU 설정을 잘못하면, 내가 보낸 메시지가 다시 나에게 돌아오는 무한 루프에 빠질 수 있습니다 [4]. 이 상태가 되면 재생이 불가능해지거나 시스템이 마비될 정도로 메시지가 쏟아지게 됩니다.

이런 실수들을 방지하려면 아래와 같은 방어적인 코딩 습관이 필요합니다.

#include <stdlib.h>
#include <stdio.h>

typedef struct {
    int* buffer;
    size_t size;
} AudioBuffer;

AudioBuffer* create_buffer(size_t size) {
    AudioBuffer* ab = (AudioBuffer*)malloc(sizeof(AudioBuffer));
    if (!ab) return NULL; // 할당 실패 처리

    ab->buffer = (int*)calloc(size, sizeof(int)); // calloc으로 0 초기화 필수!
    if (!ab->buffer) {
        free(ab);
        return NULL;
    }
    ab->size = size;
    return ab;
}

void destroy_buffer(AudioBuffer* ab) {
    if (ab) {
        if (ab->buffer) free(ab->buffer); // 내부 버퍼 먼저 해제
        free(ab); // 구조체 해제
    }
}

int main() {
    AudioBuffer* my_buf = create_buffer(1024);
    if (my_buf) {
        printf("Buffer created and initialized to zero.\n");
        destroy_buffer(my_buf);
        my_buf = NULL; // 댕글링 포인터 방지를 위해 NULL 처리
    }
    return 0;
}

짚고 넘어갈 한계와 안티패턴

물론 모든 상황에서 직접 구현이나 가벼운 라이브러리가 정답은 아닙니다.

우선 SDL_mixer 같은 거대 라이브러리는 단순한 MIDI 재생만 하기에는 너무 무겁습니다 [3]. 배보다 배꼽이 더 큰 상황이 될 수 있죠.

반대로 “스펙이 단순하니 직접 짜겠다”는 생각은 위험할 수 있습니다. 이론적인 MIDI 스펙은 간단하지만, 실제로 세상에 돌아다니는 수많은 MIDI 파일들은 표준을 무시하거나 일부 데이터가 유실된 ‘손상된 파일’인 경우가 많거든요 [2]. 이런 예외 처리를 직접 다 구현하려면 15분이 아니라 15일이 걸릴지도 모릅니다. 안정성이 중요하다면 fmidi처럼 검증된 리더를 사용하는 것이 현명합니다.

핵심 요약 (Takeaways)

성공적인 C-MIDI 프로젝트를 위해 제가 정리한 체크리스트입니다.

• 목적을 명확히 하세요. 단순히 노래를 틀고 싶다면 fmidi 같은 검증된 라이브러리로 호환성을 챙기고, MIDI 데이터를 직접 분석하고 조작해야 한다면 스펙을 공부해서 가벼운 파서를 직접 만드세요.
• 환경별 출력 전략을 분리하세요. OS에서는 실시간 MIDI 출력을, 웹이나 제한된 환경에서는 WAV 렌더링 방식을 설계 단계부터 고려해야 합니다.
• 메모리 관리는 집요하게 하세요. 오디오 스트리밍 중 크래시는 사용자 경험을 완전히 망칩니다. Valgrind를 활용하고 변수 초기화를 생활화하세요.
• 데이터의 불완전함을 인정하세요. 모든 MIDI 파일이 깨끗할 것이라는 믿음은 버리고, 비표준 파일에 대한 예외 처리 로직을 반드시 포함하세요 [2].

단순히 ‘Prayer in C’라는 곡 하나를 C언어로 구현하는 작은 프로젝트였지만, 그 이면을 들여다보면 생각보다 많은 게 들어있습니다. OS의 오디오 스택을 이해하고, 깐깐하게 메모리를 관리하며, 프로토콜의 명세를 해석하는 과정 자체가 컴퓨터 공학의 정수를 맛보는 경험이었거든요. 결국 저수준 언어로 무언가를 만든다는 건, 마법 같은 라이브러리 뒤에 숨겨진 ‘진짜 작동 원리’를 내 손으로 통제하는 즐거움인 것 같습니다.

참고 자료 (References)

1. [reddit.com] Prayer in C in C — https://www.reddit.com/r/programming/comments/1tw5sc1/prayer_in_c_in_c/ 2. [github.com] GitHub – jpcima/fmidi: A library to read and play back MIDI files — https://github.com/jpcima/fmidi 3. [stackoverflow.com] Midi C Library for creating a Game — https://stackoverflow.com/questions/6374526/midi-c-library-for-creating-a-game 4. [youtube.com] The dangers of MIDI FeedBack – THRU and Local control — https://www.youtube.com/watch?v=FTkoIAeHEg4 5. [koenig-solutions.com] Common Mistakes to Avoid in C Programming Exams — https://www.koenig-solutions.com/blog/c-programming-exams 6. [en.wikipedia.org] C (programming language) — https://en.wikipedia.org/wiki/C_(programming_language) 7. [en.wikipedia.org] MIDI — https://en.wikipedia.org/wiki/MIDI 8. [en.wikipedia.org] WAV — https://en.wikipedia.org/wiki/WAV

관련 글 추천

• https://infobuza.com/2026/06/03/20260603-ahcdnf/
• https://infobuza.com/2026/06/03/20260603-av9d99/

FAQ

MIDI와 WAV 파일의 결정적인 차이점은 무엇인가요?

MIDI는 소리 데이터가 아니라 '어떤 음을 언제, 어떤 세기로 연주하라'는 지시를 담은 '디지털 악보'와 같은 이벤트 집합입니다. 반면, WAV는 실제 연주된 소리를 녹음한 '테이프'와 같은 비압축 오디오 표준 파일입니다.

C언어로 MIDI를 구현할 때 라이브러리 선택 기준은 어떻게 되나요?

단순한 프로토타이핑 단계라면 직접 구현하는 것이 빠를 수 있고, 표준을 지키지 않은 손상된 MIDI 파일까지 안정적으로 읽어야 한다면 fmidi 같은 경량 라이브러리가 유용합니다. 다채널 믹싱 등 종합적인 기능이 필요하다면 SDL_mixer 같은 프레임워크를 사용할 수 있지만, 단순 MIDI 재생에는 너무 무거울 수 있습니다.

C언어로 오디오 프로그래밍을 할 때 주의해야 할 메모리 관리 실수는 무엇인가요?

malloc으로 할당한 버퍼를 free 하지 않아 발생하는 메모리 누수, 이미 해제된 포인터를 사용하는 댕글링 포인터 문제가 있으며, 이는 세그멘테이션 폴트로 이어질 수 있습니다. 이를 방지하기 위해 Valgrind 같은 도구로 검수하는 것이 좋습니다.

MIDI 구현 중 갑자기 찢어지는 소음(Noise)이 발생하는 이유는 무엇인가요?

C언어의 지역 변수는 자동으로 0으로 초기화되지 않기 때문에, 변수 초기화를 누락한 상태에서 해당 값이 MIDI 데이터로 들어가면 예측 불가능한 동작이나 소음이 발생할 수 있습니다.

실행 환경(OS vs 웹)에 따라 MIDI 출력 방식이 어떻게 다른가요?

윈도우나 리눅스 같은 OS 환경에서는 내장된 MIDI 신시사이저를 통해 실시간으로 소리를 냅니다. 하지만 보안과 환경 제약이 많은 웹 브라우저 환경에서는 MIDI 데이터를 소리 파형으로 변환하여 WAV 파일로 렌더링해 저장하는 방식을 주로 사용합니다.