재생 버튼이 믹서 앞에 앉았다. 힘든 일은 브라우저가 했다

Summary

• W3C가 2011년 12월 15일 공개한 Web Audio API 작업 초안은 AudioContext 안의 AudioNode를 연결하는 오디오 경로 그래프를 중심 모델로 제시했다.
• 2021년 6월 17일 권고안은 시간에 따른 매개변수 변화, 즉시 재생하지 않는 렌더링, AudioWorklet의 맞춤 처리를 규정했다. 스크립트가 그래프를 짜고 브라우저가 실시간 소리를 처리한다.

합주실 구석에는 빨간 버튼 하나를 자랑하는 오래된 주크박스가 있다. 작곡가가 소리를 작게 시작해 필터를 거치고 왼쪽으로 움직이다가 게임 인물이 착지하는 순간 멈추라고 주문한다. 주크박스는 노래를 처음부터 다시 틀겠다고 한다. 고장이 아니다. 업무가 바뀌었다. 웹에서 녹음된 소리를 재생하는 일과 사용자의 동작에 맞춰 소리를 만들어 내는 일은 서로 다른 기술을 요구했다.

2011년 12월 15일 W3C 작업 초안은 오디오를 처리하고 합성하는 고수준 인터페이스를 설명했다. 중심에는 오디오 경로 그래프가 있다. 여러 AudioNode를 연결해 소리가 어떤 처리 과정을 거쳐 귀에 닿을지 정한다. 음원이 필터, 음량 조절, 공간 위치 처리 장치를 지나 최종 출력으로 갈 수 있다. JavaScript가 연결을 정한다. 초안은 실제 처리의 대부분을 브라우저 아래쪽의 최적화된 구현이 맡고, 스크립트 직접 처리도 허용한다고 밝혔다. 작곡가가 선을 꽂고 기계가 공기를 울린다.

이 분업에는 이유가 있었다. HTML의 audio 요소는 기본 재생을 웹에 가져왔다. 그러나 2011년 초안이 겨냥한 게임과 상호작용 앱에는 혼합, 필터링, 합성이 필요했다. 완성된 녹음은 장면의 배경이 될 수 있다. 등장인물이 움직일 때마다 소리의 방향을 바꾸거나, 소리가 나는 동안 음색을 조립하는 일까지 혼자 하지는 못한다. 그래프는 이런 작업에 쓸 작은 공통 부품을 마련했다.

부품의 역할은 꽤 분명하다. AudioContext는 그래프가 놓이는 자리다. 소스 노드는 재료를 내고, gain 노드는 음량을 바꾸며, 필터는 주파수를 손본다. delay 노드는 시간을 늦추고, 분석 노드는 시각화에 쓸 정보를 제공하며, destination 노드는 들리는 출력의 끝이다. 채널을 나누고 합치는 노드도 초안에 등장했다. 한 음원이 여러 효과를 거치거나 여러 소리가 출력 전에 섞일 수 있다. 소리의 성격은 버튼 하나가 아니라 연결 방식에서 나온다.

시간 역시 중요한 장치였다. 화면에서는 벽에 부딪혔는데 충돌음이 늦게 들린다면 플레이어는 연출보다 오류를 먼저 느낀다. 초기 인터페이스는 AudioContext의 시계와 그 시계에 맞춘 소리 일정의 개념을 담았다. 애플리케이션은 언제 시작하고 멈출지 지정할 수 있다. JavaScript가 화면의 다른 일을 하면서 매 샘플마다 제시간에 깨어나기를 바라는 방식과는 다르다.

2013년 10월 10일 작업 초안에서도 그래프가 중심이었다. 다섯 번째 공개 초안이었고, 공통 언어를 다듬는 작업이 이어지고 있었다. 문서는 복잡한 게임 오디오, 상호작용 앱, 혼합과 필터링을 설명했다. 노래 전체를 들을 때 재생 버튼은 여전히 훌륭하다. 새로운 인터페이스는 화면의 행동에 따라 음향을 빚어야 하는 페이지를 위한 것이었다.

2021년 6월 17일 W3C 권고안에서는 이 작업대에 더 자세한 악보가 붙었다. AudioParam은 음량 같은 값을 오디오 시간축에 따라 바꾸게 한다. 페이지의 콜백을 다급하게 이어 붙이지 않아도 된다. OfflineAudioContext는 바로 스피커로 틀지 않고 그래프를 버퍼에 렌더링할 수 있다. 애플리케이션이 결과를 준비하거나 살펴본 뒤 다시 쓸 수 있다. 음원, 처리, 시간, 출력이라는 기본 틀은 유지됐다.

맞춤 처리에는 AudioWorklet이라는 자리가 마련됐다. 권고안은 그래프 쪽의 AudioWorkletNode와 특별한 작업 영역에서 계산하는 AudioWorkletProcessor를 한 쌍으로 설명한다. 앱은 자체 효과를 넣고, 브라우저는 음향 처리에 맞는 실행 경로를 유지한다. 명세가 제어 스레드와 렌더링 스레드를 구분하는 것도 같은 이유다. 메뉴가 열리기를 잠깐 기다리는 것과 음악의 한 박자를 기다리는 것은 전혀 다른 일이다.

W3C의 발표 기록은 2011년 12월 작업 초안에서 2021년 6월 권고안까지 이어진다. 이 날짜만으로 어느 브라우저가 먼저 도입했는지, 이용자가 몇 명이었는지는 알 수 없다. 분명한 것은 연결, 채널, 시간, 처리, 자원, 출력을 공통 규칙으로 엮는 데 긴 작업이 필요했다는 점이다. 믹서에 손잡이가 많다고 좋은 믹서가 되는 게 아니다. 서로 연결했을 때 예상대로 움직여야 한다.

앱의 창작 범위는 넓어졌다. 게임은 폭발음을 공간에 놓고, 온라인 악기는 진동기와 필터를 잇고, 교육 도구는 분석 결과로 소리를 그릴 수 있다. 브라우저가 공통 기계를 제공하고 각 프로그램이 제 악보를 쓴다. 웹페이지의 요구가 “이 파일을 틀어 줘”에서 “이 경로로 소리를 만들어 줘”로 바뀐 것이다.

주크박스가 쓸모없어진 것은 아니다. 노래 한 곡에는 빨간 버튼이 딱 맞다. 그러나 플레이어의 움직임을 따라가는 오케스트라를 버튼 하나가 담당하기에는 직원 수가 턱없이 부족하다. Web Audio는 브라우저에 믹서를 놓고 애플리케이션에 손잡이를 맡겼다. 좋은 곡을 쓰는 일까지 대신하지는 않았다.