게임 음악
게임 음악은 언제 끝날지 모르는 장면을 위해 쓰는 음악이다. 음원 칩의 채널 몇 개로 곡을 짜던 시절의 제약에서 시작해, 이음매 없는 루프, 구간을 갈아 끼우는 수평 재배열과 층을 더하고 빼는 수직 레이어링, 박에 맞춘 전환, 매개변수와 생성 음악, 대사와의 믹스, 미들웨어와 메모리까지 직접 계산한 그림으로 따라간다.
목차 (16)
영화 음악과 무엇이 다른가
영화 음악가는 편집이 끝난 장면을 받아 초 단위로 맞춰 쓴다. 추격이 46초면 46초짜리 곡을 쓰고, 칼이 부딪히는 프레임에 금관을 친다. 게임 음악가는 이 두 가지를 모두 모른다. 같은 보스전을 어떤 플레이어는 50초 만에 끝내고 어떤 플레이어는 네 번 죽으며 4분을 버틴다. 언제 문을 열지, 언제 적을 만날지, 메뉴를 열고 30분 동안 장비를 고를지도 플레이어가 정한다.
그래서 게임 음악에는 영화에 없는 숙제가 셋 생긴다. 첫째, 길이를 모르니 반복한다. 루프가 기본 단위가 되고, 몇 바퀴를 돌아도 지겹지 않고 이음매가 들리지 않게 써야 한다. 둘째, 상황이 바뀌면 음악도 바뀌어야 한다. 탐색 중에 적이 나타나면 전투 음악으로, 체력이 바닥나면 더 급하게. 이렇게 게임 상태에 따라 모양을 바꾸는 음악을 적응형 음악(adaptive music)이라 하고, 이 노트의 대부분이 그 방법이다. 셋째, 음악이 정보가 된다. 전투 음악이 끝나면 플레이어는 마지막 적이 쓰러졌음을 안다. 음악이 거짓말을 하면(적이 남았는데 평화로운 곡이 흐르면) 플레이어는 음악을 믿지 않게 된다.
적응형 음악의 흔한 첫 예로는 1978년 스페이스 인베이더가 꼽힌다. 네 음짜리 베이스가 계속 되풀이되며 외계인이 내려올수록 빨라진다(이것을 음악이 아니라 효과음으로 보는 사람도 있다). 디자인 쪽에서 본 적응형 음악의 개요는 게임 개발의 아트·캐릭터·사운드 디자인 노트에, 곡을 쓰는 일반 원리는 작곡과 편곡 노트에 있다.
하드웨어 제약이 만든 소리
1980년대 게임기와 PC는 녹음된 소리를 마음껏 틀 메모리가 없었다. 대신 몇 가지 파형을 직접 만들어 내는 음원 칩이 있었고, 칩이 한꺼번에 낼 수 있는 소리의 수(채널)와 파형의 종류가 곧 작곡의 규칙이었다. 패미컴·NES의 2A03은 펄스파 둘, 삼각파 하나, 노이즈 하나, 1비트 델타 변조 샘플 채널 하나로 다섯 채널이다. 게임보이는 펄스 둘(그중 하나는 음높이를 미끄러뜨리는 스윕 기능이 있다), 4비트 값 32개로 된 파형표를 도는 채널 하나, 노이즈 하나로 넷이다.
칩마다 개성이 뚜렷했다. 세가 메가 드라이브는 야마하 YM2612(연산자 네 개짜리 FM 채널 여섯, 그중 하나는 샘플 재생으로 바꿀 수 있다)에 사각파 셋과 노이즈 하나를 더한 PSG를 함께 썼다. PC의 애드립(AdLib) 카드와 사운드 블라스터는 야마하 OPL2(YM3812)로 연산자 둘짜리 FM 채널 아홉을 냈다. FM 합성의 원리는 컴퓨터 음악 노트에 있다.
채널이 넷이면 멜로디, 베이스, 화음, 드럼을 하나씩 맡기면 끝이다. 작곡가들은 제약을 기법으로 바꿨다. 화음을 낼 채널이 없으니 화음 세 음을 아주 빠르게 번갈아 쳐서 한 채널로 화음처럼 들리게 하는 아르페지오, 노이즈 채널의 짧은 터짐으로 만드는 드럼, 멜로디가 쉬는 틈에 같은 채널로 효과음을 끼워 넣는 일이 그렇다. 효과음이 나면 음악 채널 하나를 잠시 빼앗기 때문에, 점프 소리가 날 때 멜로디가 끊기는 것도 이 시절의 익숙한 소리다.
파형 하나에도 손잡이가 있었다. 펄스파는 한 주기에서 높은 구간의 비율(듀티 비)을 바꿀 수 있고, 50%면 짝수 배음이 사라진 속 빈 소리, 12.5%면 높은 배음이 많은 가늘고 코맹맹이 같은 소리가 난다. NES의 삼각파는 4비트 음량을 계단처럼 오르내려 만든 것이라 매끈한 삼각파보다 조금 거칠고 음량 조절이 따로 없다. 이 사이트의 레트로 SFX로 이런 파형의 효과음을 만들고, 칩튠 메이커로 그 소리를 악기 삼아 채널을 나눠 곡을 짜 볼 수 있다. 칩튠이 장르로 자리 잡은 흐름은 음악사와 장르 노트에 있다.
루프 설계: 이음매 없이 되풀이하기
게임 음악의 기본형은 인트로 + 루프다. 곡을 시작할 때만 한 번 나오는 인트로가 있고, 그 뒤 구간을 끝없이 되풀이한다. 인트로 없이 처음부터 돌리면 매 바퀴 곡이 "시작하는" 느낌이 나지만, 인트로를 따로 두면 루프 끝이 루프 시작으로 자연스럽게 넘어가도록 쓸 수 있다. 엔진은 파일 하나에 루프 시작과 루프 끝 두 위치를 샘플 번호로 기억하고, 끝 샘플 다음에 시작 샘플을 이어 튼다.
루프 지점은 박자 격자 위에 둔다. 마디 경계의 샘플 위치는 마디 수 × 박 수 × (60 ÷ BPM) × 샘플링 레이트다. 120 BPM이면 48kHz에서 한 박이 24,000샘플로 정수지만, 140 BPM이면 한 박이 20571.43샘플이라 루프 끝을 반올림해야 한다. 8마디 루프에서 그 오차는 바퀴마다 0.286샘플씩 쌓여 100바퀴 뒤에는 약 0.6ms가 된다. 음악 하나만 돌 때는 들리지 않지만, 같은 템포의 다른 스템이나 박에 맞춘 전환(다음 절)과 함께 쓰면 조금씩 어긋날 수 있다. 그래서 엔진은 루프 지점을 시간(초)이 아니라 샘플 번호로 다루고, 여러 스템은 같은 길이로 맞춰 함께 돌린다.
- 꼬리 처리: 마지막 마디의 심벌과 리버브는 루프 끝을 넘어 울린다. 그냥 자르면 돌아갈 때 잔향이 뚝 끊긴다. 곡을 한 바퀴 더 이어 녹음한 뒤, 끝 너머로 넘친 꼬리를 루프 첫머리에 겹쳐 섞어 두면 돌아와도 꼬리가 이어진다.
- 영교차와 짧은 페이드: 끝 샘플 값과 시작 샘플 값이 크게 다르면 파형이 계단처럼 끊겨 "틱" 소리가 난다. 루프 지점을 파형이 0을 지나는 곳에 맞추거나, 경계를 몇 ms 크로스페이드한다. 이 사이트의 오디오 루프 편집기가 바로 이 일을 한다.
- 형식의 함정: MP3는 인코더가 앞뒤에 무음 샘플(지연과 채움)을 붙이므로, 이를 알려 주는 정보를 읽지 않고 그대로 이어 틀면 루프 사이에 틈이 생긴다(gapless playback). 게임 엔진과 미들웨어가 자체 압축 형식이나 루프 지점 정보를 쓰는 이유다.
반복이 소리로 이어져도 귀가 지겨우면 실패다. 긴 시간 머무는 곳(마을, 메뉴)의 루프는 길게 쓰거나, 끝에 몇 마디 쉬는 구간을 두거나, 아예 한동안 음악을 멈췄다가 다시 시작하는 방법을 쓴다. 침묵도 설계의 일부다.
수평 재배열: 구간을 바꿔 잇기
적응형 음악의 첫 번째 축은 시간 방향, 곧 다음에 어떤 구간을 틀지를 고르는 것이다. 곡을 탐색, 경계, 전투, 승리 같은 여러 구간(세그먼트)으로 잘라 두고, 게임 상태가 바뀌면 지금 구간을 끝내고 다른 구간으로 건너뛴다. 가로로 늘어선 조각의 순서를 다시 짠다고 해서 수평 재배열(horizontal resequencing)이라 한다. 1991년 LucasArts의 iMUSE가 초기의 잘 알려진 예다. 작곡가 Michael Land와 Peter McConnell이 만들어 Monkey Island 2에 처음 썼고, 곡 안에 분기·반복 지점을 두어 장면이 바뀔 때 테마를 이어 바꿨다(특허 US5315057).
문제는 언제 건너뛰느냐다. 요청이 온 즉시 바꾸면 박 한가운데서 곡이 잘린다. 그래서 다음 박, 다음 마디, 다음 프레이즈처럼 음악의 격자 위에서만 바꾸도록 맞추는데, 이것을 퀀타이즈라 한다. 대가는 기다림이다. 요청이 아무 때나 온다면 평균 대기 시간은 격자 한 칸의 절반이라, 120 BPM 4/4에서 마디 단위면 평균 1.0초, 4마디 프레이즈면 평균 4.0초를 기다린다.
탐색 음악이 2.7초째(2마디 2박 뒤쪽)를 지나는 중에 적이 나타나 "전투로" 요청이 온다. 바꿀 때를 정하는 규칙이 퀀타이즈다.
그래서 단위를 상황마다 다르게 고른다. 적이 나타난 순간처럼 반응이 중요하면 다음 박에서, 탐색에서 마을로 들어가는 것처럼 느긋하면 다음 프레이즈에서 바꾼다. 기다리는 동안 반응이 없어 보이면 바로 아래 절의 스팅어를 즉시 얹어 "알아들었다"는 신호를 주고, 본 전환은 마디에서 한다. 도구들도 같은 선택지를 준다. FMOD Studio는 전환 구간을 박·마디 단위로 퀀타이즈하고 템포 마커가 없으면 120 BPM 4/4로 본다(FMOD: Authoring Events). Godot의 AudioStreamInteractive는 전환 시점을 즉시, 다음 박, 다음 마디, 클립 끝 중에서 고른다.
구간 사이를 이으려면 작곡 단계의 약속이 먼저다. 어느 구간에서 어느 구간으로든 넘어갈 수 있으려면 템포와 조, 마디 길이를 맞추거나, 넘어갈 수 있는 쌍마다 전용 전환을 마련해야 한다. 조가 다른 구간끼리 이어질 때 어떤 화음이 다리가 되는지는 화성학 노트의 영역이다.
수직 레이어링: 스템을 겹치고 빼기
두 번째 축은 세로 방향이다. 한 곡을 악기 묶음별로 따로 녹음한 스템(stem) 여러 개를 처음부터 끝까지 함께 돌리고, 게임 상태에 따라 각 스템의 볼륨만 올리고 내린다. 악보를 세로로 쌓은 층을 켜고 끈다고 해서 수직 레이어링(vertical layering, vertical orchestration)이라 한다. 모든 스템이 같은 박자 위에서 이미 돌고 있으므로 언제 볼륨을 바꿔도 박이 어긋나지 않는다. 퀀타이즈를 기다릴 필요가 없어 반응이 빠르다.
대신 할 수 있는 변화에 한계가 있다. 층을 더하고 빼는 것으로는 템포, 조, 화음 진행, 곡의 구조가 바뀌지 않는다. 탐색과 전투가 전혀 다른 곡이어야 한다면 수평 재배열이 맞고, 같은 곡이 점점 달아올라야 한다면 수직 레이어링이 맞다. 실제 게임은 둘을 섞는다. 구간마다 스템을 두고, 큰 상태 변화는 구간 전환으로, 그 안의 작은 긴장 변화는 레이어로 처리한다.
레이어를 쓸 때 작곡가가 지켜야 할 것도 있다. 어떤 조합으로 켜져도 음악이 성립해야 한다. 베이스 없이 금관만 남는 조합이 이상하게 들리면 그런 조합이 나오지 않게 곡선을 짠다. 스템은 각각 혼자 들어도, 모두 함께 들어도 소리가 탁해지지 않도록 음역을 나눠 편곡한다(작곡과 편곡 노트). 볼륨을 직선으로 올리면 귀에는 처음에 확 커졌다가 나중엔 거의 안 바뀌는 것처럼 들리므로, 데시벨이나 sin 곡선 같은 모양으로 올린다.
전환 기법: 스팅어, 크로스페이드, 전환 구간
구간을 바꾸는 순간을 어떻게 메울지에 따라 같은 퀀타이즈도 다르게 들린다.
- 스팅어(stinger): 한두 박짜리 짧은 악구(금관 한 방, 심벌 롤)를 지금 음악 위에 얹는다. 보물 발견, 적 발견, 레벨 업 같은 순간을 강조하는 데 쓰고, 구간 전환의 이음매를 덮는 데도 쓴다. 스팅어 자체도 다음 박에 맞춰 예약하는 경우가 많다.
- 크로스페이드: 나가는 곡을 줄이며 들어오는 곡을 키운다. 템포나 조가 달라 박을 맞출 수 없을 때도 쓸 수 있는 가장 범용적인 방법이지만, 겹친 동안 두 곡의 화음과 리듬이 부딪칠 수 있어 짧게 하거나 한쪽이 조용한 구간에서 한다.
- 전환 구간(transition segment): A에서 B로 넘어갈 때만 쓰는 한두 마디를 따로 작곡한다. 템포를 끌어올리거나 화음을 B의 조로 옮겨 주므로 가장 음악적이지만, 넘어갈 수 있는 쌍마다 하나씩 필요해 구간이 늘수록 작곡량이 빨리 는다.
크로스페이드의 곡선 모양도 중요하다. 서로 다른 두 곡을 섞을 때 진폭을 직선으로 바꾸면(1−t와 t) 가운데서 두 소리의 세기 합이 절반, 곧 −3dB로 꺼져 전환하는 순간 음악이 움푹 작아진다. 진폭을 cos과 sin으로 바꾸는 같은 세기(equal-power) 곡선은 cos² + sin² = 1이라 세기 합이 내내 같다. 반대로 같은 녹음의 두 복사본(위상이 맞는 신호)을 이을 때는 진폭이 그대로 더해지므로 직선 곡선이 맞다. 루프 경계를 다듬을 때가 그런 경우다.
매개변수로 움직이는 음악
"탐색 상태, 전투 상태"처럼 나뉜 상태 대신 연속된 숫자 하나로 음악을 움직일 수도 있다. 게임이 체력, 적과의 거리, 속도, 긴장도 같은 값을 매 프레임 음악 시스템에 넘기면, 음악 쪽은 그 값을 곡선에 통과시켜 스템 볼륨, 필터 차단 주파수, 리버브 양, 다음 구간의 선택 확률 같은 여러 손잡이를 한꺼번에 돌린다. Wwise는 이것을 RTPC(Real-Time Parameter Control), FMOD는 매개변수(parameter)라 부른다.
곡선의 모양이 곧 연출이다. 주파수처럼 비율로 들리는 값은 지수 곡선으로 대응해야 고르게 변하는 것처럼 들리고, 볼륨은 데시벨 단위로 다뤄야 한다. 값이 프레임마다 출렁이면 음악도 출렁이므로, 매개변수에는 보통 변화 속도 제한(초당 얼마까지만 바뀜)이나 부드럽게 따라가는 필터를 건다. 반대로 상태처럼 딱 끊기는 값(전투 중인가)은 구간 전환에, 연속 값(얼마나 위험한가)은 레이어와 이펙트에 쓰는 식으로 나누면 설계가 깔끔하다.
생성·절차적 음악
미리 녹음한 조각을 고르는 데서 더 나가면, 음 자체를 실행 중에 만든다. 규칙과 난수로 멜로디·리듬·화음을 정하고, 신시사이저나 샘플 악기로 그 자리에서 소리를 낸다. 장점은 끝없이 달라지는 음악과 아주 작은 용량, 그리고 게임 상태에 음표 단위로 반응할 수 있다는 것이다. 단점은 음악적 완성도를 장담하기 어렵다는 것이다. 무작위는 쉽게 "아무 의미 없는 음의 나열"이 된다.
그래서 실제 게임의 생성 음악은 대개 작곡가가 만든 재료를 규칙으로 조립하는 쪽에 가깝다. 작곡가가 같은 조와 템포로 짧은 악구를 많이 써 두고, 시스템이 그중 무엇을 언제 어떤 층에 놓을지 고른다. Galak-Z의 음악을 설명한 GDC 발표 Creating Hyper-Adaptive Music on an Indie Budget(C. Andrew Rohrmann, 2015)이 여러 층의 음악을 판마다 다르게 조립하는 방법을 다룬다. 음 하나하나를 만드는 방식이라면 마르코프 연쇄 같은 확률 모형과 생성형 AI 모델도 쓸 수 있는데, 원리는 컴퓨터 음악 노트의 알고리즘 작곡 절에 있다.
절차 생성의 공통 원칙은 여기서도 통한다. 씨앗(seed)을 고정하면 같은 결과를 다시 만들 수 있어, 버그를 재현하거나 플레이어끼리 같은 판을 나눌 때 음악도 함께 맞출 수 있다(절차 생성 노트). 화성 규칙으로 무작위를 묶는 방법은 화성학 노트, 음계와 박자의 기초는 음악 기초 이론 노트에 있다.
음악의 자리와 의미: 다이제틱과 라이트모티프
다이제틱과 논다이제틱
영화 이론에서 빌려 온 구분이다. 다이제틱(diegetic) 음악은 이야기 속 세계 안에 소리의 출처가 있어 등장인물도 듣는 음악이다. 차 안 라디오, 술집 악단, 캐릭터가 부는 피리가 그렇다. 논다이제틱(non-diegetic) 음악은 세계 밖에서 플레이어에게만 들리는 배경 음악이다(Diegesis).
게임에서는 이 구분이 구현을 바꾼다. 다이제틱 음악은 세계 속 물체에서 나오는 3D 소리라 거리 감쇠, 차폐, 방의 잔향을 받는다(게임 사운드 노트). 라디오 앞을 지나면 커졌다 작아지고, 벽 너머에서는 먹먹하다. 논다이제틱 음악은 화면 어디서나 같은 크기로 들리는 2D 소리로 섞는다. 둘 사이를 넘나드는 연출도 흔하다. 라디오에서 나오던 노래가 장면이 고조되면서 위치를 잃고 배경 음악처럼 커지거나, 플레이어가 악기로 연주하는 선율이 곧 퍼즐의 답이 되는 경우다. 이때는 같은 곡의 3D 재생과 2D 재생을 박을 맞춰 크로스페이드한다.
테마와 라이트모티프
라이트모티프(leitmotif)는 인물, 장소, 생각에 붙은 짧은 음악 주제를 이야기 내내 변형해 다시 쓰는 기법이다. 바그너의 오페라와 함께 널리 알려졌고 영화 음악이 이어받았다(Leitmotif). 게임에서는 효과가 더 크다. 플레이어가 수십 시간 같은 세계에 머물기 때문에 주제를 들을 기회가 많고, 메인 메뉴에서 들은 선율이 마지막 보스전에서 다른 모습으로 돌아오면 그 시간이 한꺼번에 떠오른다.
주제가 변형을 견디려면 짧고 윤곽이 뚜렷해야 한다. 네다섯 음, 특징 있는 도약 하나, 알아들을 수 있는 리듬이면 충분하다. 같은 주제를 탐색 곡에서는 느린 피아노로, 전투 곡에서는 금관으로, 승리 팡파르에서는 장조로 끝맺으면 곡이 달라도 한 게임의 음악으로 묶인다. 앞 절의 스팅어에 주제의 첫 음 몇 개를 쓰는 것도 흔한 방법이다. 모티프를 발전시키는 작곡 기법은 작곡과 편곡 노트, 장조·단조를 오가는 화성의 원리는 화성학 노트에 있다.
믹스 우선순위와 덕킹
게임 음악은 혼자 울리지 않는다. 총성, 발소리, 대사, UI 소리가 같은 스피커를 나눠 쓰고, 플레이에 필요한 정보는 대개 음악이 아니라 그쪽에 있다. 그래서 믹스의 우선순위는 보통 대사와 게임플레이 정보 소리 → 효과음 → 음악 순서다. 음악은 크고 화려할수록 좋은 것이 아니라, 다른 소리가 들릴 자리를 남겨야 한다.
가장 흔한 장치가 덕킹(ducking)이다. 대사가 나오는 동안 음악 버스를 몇 dB 낮췄다가 대사가 끝나면 천천히 되돌린다. 9dB를 낮추면 진폭이 약 35%가 된다. 음악을 끄는 것이 아니라 비켜 주는 것이라 흐름이 끊기지 않는다. 내려가는 시간(어택)은 짧게, 돌아오는 시간(릴리스)은 길게 잡아야 대사 사이사이에 음악이 펌프질하듯 출렁이지 않는다.
음량만 낮추는 대신 사람 목소리의 핵심 대역만 음악에서 살짝 깎는 방법, 대사 버스 크기를 보고 자동으로 누르는 사이드체인 압축, 일시 정지나 물속처럼 믹스 전체가 바뀌는 순간을 묶어 두는 스냅숏도 쓴다. 버스 구조와 보이스 수 제한 같은 구현은 게임 사운드 노트에서 다룬다. 마지막으로 설정 메뉴에 음악·효과음·대사 볼륨을 따로 두는 것은 거의 필수다. 음악을 끄고 자기 음악을 듣는 플레이어도 많고, 청각 정보에 기대는 플레이어에게는 음악이 방해가 될 수 있다. 완성된 음원의 음량은 이 사이트의 음량 측정으로 LUFS 단위로 잴 수 있다.
미들웨어와 엔진 내장 오디오
지금까지의 기능(구간 전환, 퀀타이즈, 레이어 곡선, 매개변수, 스냅숏)을 게임마다 직접 짜면 프로그래머와 작곡가가 같은 일을 몇 번씩 주고받게 된다. 오디오 미들웨어는 이 규칙을 작곡가·사운드 디자이너가 직접 만지는 저작 도구와, 게임에 넣는 런타임 라이브러리로 나눠 준다. 게임 코드는 "전투가 시작됐다", "긴장도 = 0.8"처럼 무슨 일이 일어났는지만 알리고, 음악을 어떻게 바꿀지는 저작 도구에서 정해 뱅크로 구워 넣는다. 규칙을 고쳐도 게임 코드를 다시 빌드하지 않아도 되고, 게임을 실행한 채로 연결해 값을 바꿔 들어 보는 기능도 있다.
- FMOD Studio: DAW처럼 타임라인 위에 소리를 놓고, 로직 마커(전환 마커·전환 구간·목적지·루프 구간·템포 마커)로 흐름을 짠다. 전환 구간은 박·마디에 퀀타이즈할 수 있고, 매개변수 축 위에 소리를 늘어놓아 값에 따라 소리를 바꾼다. 믹서의 스냅숏으로 장면별 믹스를 바꾼다(FMOD Studio 문서). 출시작 Celeste의 FMOD 프로젝트가 예제로 공개되어 있다.
- Wwise: 음악을 세그먼트, 플레이리스트 컨테이너, 스위치 컨테이너로 쌓고, 컨테이너 사이의 전환 규칙(어디서 나가고 어디로 들어올지, 전환 세그먼트와 페이드)과 스팅어를 표로 정한다. 게임은 State·Switch·RTPC 같은 게임 싱크로 음악을 움직인다(Wwise 문서).
미들웨어 없이 엔진 기능만으로도 상당 부분을 할 수 있다. 유니티는 오디오 믹서(버스, 스냅숏, 덕킹 효과)와 AudioSource.PlayScheduled로 오디오 시계 기준의 정확한 예약 재생을 제공해, 다음 마디 시각을 계산해 다음 구간을 예약하는 식으로 수평 재배열을 짤 수 있다. 언리얼 엔진은 소리 재생을 음악 박자에 샘플 단위로 맞춰 예약하는 Quartz와 절차적 오디오 그래프인 MetaSounds를 둔다. Godot는 4.3부터 전환표를 갖춘 AudioStreamInteractive, 여러 스트림을 맞춰 돌리는 AudioStreamSynchronized, 재생 목록인 AudioStreamPlaylist를 넣었다. 어느 쪽이든 핵심은 같다. 게임 프레임 시계가 아니라 오디오 시계로 시각을 계산해야 프레임이 흔들려도 박이 어긋나지 않는다. 엔진 고르기와 구조는 엔진 노트에 있다.
파일 형식과 메모리
음악은 게임 소리 중에서 가장 길다. 3분짜리 스테레오 곡 하나를 48kHz 16비트 PCM으로 풀어 두면 34.6MB다. 효과음 수백 개보다 클 수 있다. 160kbps 손실 압축이면 3.6MB로 줄지만, 수직 레이어링으로 스템 넷을 두면 다시 14.4MB다. 그래서 음악은 대개 압축하고, 메모리에 통째로 올리기보다 스트리밍한다. 스트리밍은 디스크에서 조금씩 읽어 풀면서 트는 방식으로, 메모리에는 작은 버퍼만 머문다.
- 메모리 상주: 짧고 자주, 지연 없이 나야 하는 소리(스팅어, UI, 짧은 효과음)에 맞다. 풀어 둔 PCM은 CPU가 거의 들지 않지만 크고, 압축한 채 두면 작지만 재생할 때마다 풀어야 한다. 유니티 문서는 Vorbis를 불러올 때 풀어 두면 압축 상태보다 메모리를 약 열 배 쓴다고 적는다(Unity: Audio Clip).
- 스트리밍: 긴 음악과 환경음에 맞다. 대신 시작하려면 디스크에서 첫 조각을 읽어야 해 바로 소리가 나지 않을 수 있고, 동시에 여는 스트림 수만큼 디스크 읽기가 늘어난다. 레이어링으로 스템 넷을 동시에 스트리밍하면 그만큼 부담이 커지므로, 스템을 한 파일의 여러 채널에 묶기도 한다. 수평 재배열의 다음 구간은 전환 시각보다 미리 읽어 두어야 하는데, 퀀타이즈 단계 그림의 "준비 시간"이 이것이다.
- 압축 방식: ADPCM은 16비트를 4비트로 줄여 크기가 4분의 1이고 풀기가 아주 싸다. Vorbis·Opus 같은 손실 코덱은 같은 품질에서 훨씬 작지만 풀 때 CPU를 더 쓴다. 게임기마다 하드웨어로 푸는 전용 형식이 있기도 해, 미들웨어와 엔진은 플랫폼별로 다른 형식으로 구워 낸다.
샘플링 레이트·비트 깊이·양자화 노이즈의 원리는 컴퓨터 음악 노트의 디지털 오디오 절과 신호 처리 노트에 있다.
라이선스와 저작권 개요
게임에 들어가는 음악에도 여러 권리가 겹친다. 곡(멜로디·가사)에 대한 저작권과, 그 곡을 녹음한 음원에 대한 권리가 따로 있다는 기본은 컴퓨터 음악 노트의 저작권 절에 정리했다. 게임에서 특히 따져야 할 것은 다음과 같다.
- 새로 의뢰한 곡: 작곡가와의 계약이 권리를 누가 갖는지, 작곡가가 사운드트랙 앨범을 따로 낼 수 있는지, 다른 게임에 재사용할 수 있는지를 정한다. 계약서에 적지 않은 부분은 나라의 법과 관행에 따라 해석이 갈린다.
- 기존 곡을 허락받아 쓰기: 영상이나 게임 장면에 음악을 붙이는 데는 곡에 대한 허락(흔히 싱크 권리라 부른다)과 특정 녹음에 대한 허락이 따로 필요할 수 있다(Synchronization rights). 허락 기간과 지역, 매체가 정해져 있어, 기간이 끝나면 곡을 빼거나 바꾼 판을 내야 할 수 있다.
- 방송과 영상: 플레이어가 게임을 방송하거나 영상으로 올리면 게임 속 음악도 함께 나간다. 허락 범위에 이것이 들어 있지 않으면 영상 플랫폼의 저작권 판정에 걸릴 수 있어, 방송용 모드에서 특정 곡을 빼는 게임도 있다.
- 음원 라이브러리와 생성 음악: "로열티 프리" 라이브러리는 대가를 한 번 내고 쓰는 것이지 권리가 없다는 뜻이 아니며, 쓸 수 있는 매체와 조건은 라이브러리마다 다르다. AI로 만든 음악의 보호와 학습 데이터 문제는 나라마다 논의가 진행 중이다.
이 절은 개념을 정리한 것이고 법률 조언이 아니다. 실제 계약과 사용 전에는 계약서 원문과 권리 단체, 전문가에게 확인해야 한다. 한국의 제도와 상담 창구는 한국저작권위원회가 안내한다. 오픈 소스 라이선스의 일반 원리는 오픈 소스와 라이선스 노트에 있다.
작업 흐름: 임시 음악에서 구현 테스트까지
게임 음악 작업은 곡을 써서 넘기면 끝나는 일이 아니다. 대체로 다음 순서를 몇 번씩 돈다.
- 임시 음악(temp track): 개발 초기에 기존 곡을 임시로 깔아 분위기와 템포를 맞춘다. 팀이 원하는 느낌을 말 대신 소리로 나누는 도구지만, 팀이 임시 곡에 익숙해져 새 곡을 그것과 비교하게 되는 부작용이 영화 쪽에서도 잘 알려져 있다(Temp track). 출시본에 남기면 안 된다.
- 스파팅(spotting): 영화에서 감독과 작곡가가 장면을 보며 음악이 들어갈 자리를 정하는 회의에서 온 말이다(Spotting session). 게임에서는 장면 대신 지역, 상태, 사건의 목록을 놓고 어디에 어떤 음악을, 어떤 상태 변화에 어떤 전환을, 어디는 침묵으로 둘지를 정한다. 이 목록이 곧 구간과 스템, 이벤트 이름의 설계서가 된다.
- 작곡과 편곡: 루프 길이, 인트로, 템포와 조의 약속, 스템 구성, 전환 구간을 처음부터 염두에 두고 쓴다. 나중에 쪼개기 어려운 곡은 나중에 적응형으로 만들기도 어렵다.
- 구현: 미들웨어나 엔진에 이벤트, 전환 규칙, 매개변수 곡선을 넣는다. 작곡가가 직접 하기도 하고, 사운드 디자이너나 오디오 프로그래머가 맡기도 한다.
- 플레이 테스트: 음악은 게임 안에서 들어 봐야 안다. 실제로 몇 바퀴 반복되는지, 전환이 너무 잦아 정신없지 않은지, 대사가 묻히지 않는지, 30분 머물면 지겹지 않은지를 확인하고 앞 단계로 돌아간다.
게임 개발 전체의 단계와 협업 방식은 제작 과정 노트에 있다.
흔한 오해
- "루프는 파일 끝에서 처음으로 돌리면 된다": 끝 너머의 잔향 꼬리, 파형 불연속의 틱 소리, MP3의 앞뒤 무음, 박자 격자와 어긋난 반올림이 모두 이음매로 들린다. 루프 지점은 샘플 단위로, 박 위에, 꼬리를 처리해서 둔다.
- "적응형 음악은 프로그래밍 문제다": 시스템보다 작곡 단계의 약속(같은 템포·조·길이, 어떤 조합으로도 성립하는 스템)이 먼저다. 약속 없이 쓴 곡은 어떤 시스템으로도 매끄럽게 이을 수 없다.
- "전환은 빠를수록 좋다": 즉시 전환은 반응은 빠르지만 박을 깨뜨리고, 상태가 잠깐씩 바뀔 때마다 음악이 정신없이 뒤집힌다. 퀀타이즈와 함께, 상태가 일정 시간 유지될 때만 바꾸는 여유(히스테리시스)를 둔다.
- "8비트 음악은 8비트 소리라서 그렇게 들린다": "8비트"는 대개 그 기계의 CPU를 가리킨다. 칩튠의 소리를 정한 것은 채널 수, 파형 종류, 음량 단계 같은 음원 칩의 구조다. NES의 삼각파는 4비트 계단으로 만들어지고, 게임보이의 파형표도 4비트 값이다.
- "음악은 쉬지 않고 깔려 있어야 한다": 계속 나오는 음악은 귀가 금방 무시하고, 오래 머무는 곳에서는 피로가 된다. 음악을 멈추는 순간도 연출이고, 침묵 뒤에 다시 들어오는 음악이 더 크게 들린다.
- "선형 크로스페이드면 충분하다": 서로 다른 곡을 직선 곡선으로 섞으면 가운데서 −3dB 꺼진다. 다른 곡끼리는 같은 세기 곡선, 같은 녹음끼리는 선형이 맞다.
- "미들웨어를 쓰면 알아서 적응형이 된다": 미들웨어는 규칙을 담는 그릇이다. 어떤 상태에서 무엇을 어떻게 바꿀지는 여전히 스파팅과 작곡이 정한다.
핵심 자료
사운드 엔진 쪽 구현(3D 오디오, 차폐, 보이스 제한, 버스)은 게임 사운드 노트, 합성과 트래커, MIDI는 컴퓨터 음악 노트, 소리의 물리는 음향학 노트에 있다. 아래 GDC 발표는 모두 GDC Vault에 무료로 공개된 것이다.
| 자료 | 종류 | 요지 | 링크 |
|---|---|---|---|
| FMOD Studio User Manual | 공식 문서 | 이벤트, 타임라인, 매개변수, 로직 마커(전환·목적지·루프 구간, 템포 마커), 스냅숏과 믹서, 뱅크 빌드를 설명한다. 적응형 음악의 구조를 도구 쪽에서 익히기 좋다. | FMOD |
| Celeste 예제 프로젝트(FMOD 매뉴얼 부록) | 공개 프로젝트 | 출시된 게임 Celeste의 FMOD Studio 프로젝트를 공개해, 실제 게임의 음악 이벤트가 어떻게 짜여 있는지 열어 볼 수 있다. | FMOD |
| Wwise 문서 라이브러리 | 공식 문서 | Wwise의 인터랙티브 음악(세그먼트, 플레이리스트·스위치 컨테이너, 전환 규칙, 스팅어), 게임 싱크(State, Switch, RTPC), 사운드뱅크 문서가 모여 있다. | Audiokinetic |
| 'DOOM': Behind the Music | GDC 발표(2017) | Mick Gordon이 DOOM(2016) 사운드트랙의 음악적 사운드 디자인, 합성, 인터랙티브 음악, 믹싱을 설명한다. 무료 공개. | GDC Vault |
| Journey vs Monaco: Music is Storytelling | GDC 발표(2012) | Austin Wintory가 성격이 아주 다른 두 게임의 음악을 비교하며, 음악이 이야기를 맡는다는 같은 생각으로 어떻게 설계했는지 말한다. 무료 공개. | GDC Vault |
| Creating Hyper-Adaptive Music on an Indie Budget | GDC 발표(2015) | C. Andrew Rohrmann이 Galak-Z의 여러 층으로 된 음악을 플레이에 맞춰 바뀌고 판마다 다르게 조립되도록 만든 방법을 설명한다. 무료 공개. | GDC Vault |
| AudioStreamInteractive | 엔진 문서 | Godot의 인터랙티브 음악 리소스. 클립 사이의 전환표와 전환 시점(즉시, 다음 박, 다음 마디, 클립 끝), 페이드 방식을 정한다. | Godot Docs |
| Quartz Overview | 엔진 문서 | 언리얼 엔진에서 소리 재생을 박·마디 같은 음악 시간에 샘플 단위로 맞춰 예약하는 시스템. | Epic Games |
| Audio Clip(불러오기 방식과 압축 형식) | 엔진 문서 | 유니티의 오디오 클립 설정. 불러올 때 풀기, 압축한 채 메모리에 두기, 스트리밍의 차이와 PCM·ADPCM·Vorbis 형식을 설명한다. | Unity Docs |
| Pan Docs: Audio | 하드웨어 문서 | 게임보이 음원의 네 채널(펄스 둘, 파형표 하나, 노이즈 하나)과 레지스터를 설명하는 커뮤니티 표준 문서. | gbdev |
- FMOD Studio User Manual — FMOD
- Celeste 예제 프로젝트(FMOD 매뉴얼 부록) — FMOD
- Wwise 문서 라이브러리 — Audiokinetic
- 'DOOM': Behind the Music — GDC Vault
- Journey vs Monaco: Music is Storytelling — GDC Vault
- Creating Hyper-Adaptive Music on an Indie Budget — GDC Vault
- AudioStreamInteractive — Godot Docs
- Quartz Overview — Epic Games
- Audio Clip(불러오기 방식과 압축 형식) — Unity Docs
- Pan Docs: Audio — gbdev
- Authoring Events(로직 마커와 퀀타이즈) — FMOD
- Mixing(스냅숏) — FMOD
- Audio Mixer — Unity Docs
- AudioSource.PlayScheduled — Unity Docs
- MetaSounds — Unreal Engine 문서
- Audio buses — Godot Docs
- Godot 4.3 릴리스 노트 — Godot Engine
- Ricoh 2A03 — Wikipedia
- MOS Technology 6581(SID) — Wikipedia
- Yamaha YM2612 — Wikipedia
- Super Nintendo Entertainment System(Audio) — Wikipedia
- Yamaha OPL — Wikipedia
- Adaptive music — Wikipedia
- iMUSE — Wikipedia
- US5315057A: Method and apparatus for dynamically composing music and sound effects — Google Patents
- Leitmotif — Wikipedia
- Diegesis — Wikipedia
- Gapless playback — Wikipedia
- Temp track — Wikipedia
- Spotting session — Wikipedia
- Synchronization rights — Wikipedia
- Horizontal Resequencing and Dynamic Transitions for Game Music Composers — Game Developer
- 한국저작권위원회