Wwise 생태계에 대해 잘 알려지지 않은 특징 중 하나는 바로 확장성입니다. 프로젝트에 사용할 플러그인을 회사들이 직접 만들기도 하고 판매사는 (가끔은 저희 도움을 통해) 자체 플러그인을 Wwise에 마이그레이션하기도 합니다. 곧 출시되는 새로운 버전을 통해 이 훌륭한 시스템은 대대적인 첫 번째 개편을 앞두고 있습니다!

이 블로그 시리즈에서는 Wwise 저작 플러그인 설계와 관련해 어떤 선택의 폭이 있는지 살펴보고 처음으로 새로운 API를 선보여드리려고 합니다.

• 제 1부: 역사와 목표
• 제 2부: 플러그인 내부 살펴보기
• 제 3부: 플러그인 제작하기

제 1부: 역사와 목표

플러그인은 Wwise가 지향하는 중심 목표 중 하나입니다. 효과와 음원을 사용하는 능력, 프로젝트에 원하는 느낌을 낼 수 있는 능력은 아주 중요하죠. Wwise Launcher에서 설치할 수 있는 십여 가지 플러그인 중에 딱히 맘에 쏙 드는 게 없었나요? 사실 그 외에 훨씬 많은 플러그인이 제공되고 있다는 것을 아시나요? 이십여 개가 넘는 플러그인 모음에서 원하는 것을 고를 수 있을 뿐더러, 커뮤니티 플러그인의 개수도 나날이 늘어가고 있습니다.

모든 플러그인에는 두 가지 부분이 있습니다. 프로젝트의 실행 파일에 들어가게 되는 Sound Engine에서의 부분이 있고 플러그인을 정확히 원하는대로 설정하도록 해주는 Authoring에서의 부분이 있죠.

플러그인의 역사

지난 15년 동안 플러그인 제작 시스템은 계속해서 개선되었으며 Authoring과 Sound Engine과 모두 밀접하게 통합되어 왔습니다. 사실 다른 모든 것을 제작할 때에도 Audiokinetic 내부에서 플러그인의 구조와 기능을 사용했을 정도로 아주 긴밀하게 통합되었죠!

물론 이 부분은 저희에게 양날의 검입니다. 한편으로는 시스템이 밀접하게 통합되며 최적화되지 않은 경로가 없다는 장점이 있습니다. 하지만 저희가 내부 구조에서 어떤 면으로든 재정의하거나 변경하는 것이 불가능하다는 단점이 있죠. 이와 반대로 내부 구조를 바꿀 수는 없지만 저희는 플러그인 인터페이스가 서로 다른 버전 간에 호환될 수 있도록 했습니다.

Sound Engine의 경우, 제품이 효율적으로 가장 빠르게 실행되어야 하기 때문에 이 부분이 장점으로 작용하죠. 하지만 Wwise Authoring의 경우에는 모든 것이 Windows API를 기반으로 하기 때문에 이 부분이 문제가 되었습니다.

우리를 기다려주지 않는 시간

모든 플랫폼을 지원하는 것은 Audiokinetic의 주된 무기이지만, 현재 그리고 다음 세대에서 이 부분이 Authoring 측면에서 잘 지켜지지 못했습니다. Sound Engine의 경우 새로운 SDK와 새로운 플랫폼을 지원함과 동시에 제품 출시에서 수정 사항과 개선을 필요로 하는 고객들을 지원하기 위해 끊임없이 노력해왔습니다. 지원 기반이 큰 제품을 작업하시는 분들도 저희 빌드 장치를 보면 깜짝 놀라실 거예요! 하지만 Authoring의 경우 수년 동안 저희 고객분들이 Windows 버전과 Mac 버전에 만족해주셨습니다.

놀랍게도 저희가 가진 목표와 우선 순위 중에서 크로스 플랫폼 부분을 개선해야 한다는 것을 분명히 알 수 있었습니다. 15년 전에 저희가 먼저 Xbox와 Windows PC를 지원했을 때에는 단순성과 Windows와의 긴밀한 통합 면에서 볼 때 선택하기가 쉬웠습니다. 하지만 수년에 걸쳐 천천히 인터넷이 주류가 되고 게임이 스트리밍되기 시작하며 개발자가 백엔드 서버로 Linux를 사용하기 시작했습니다. 그리고 iOS와 Android는 스마트폰 세계를 정복하고 Mac은 창의적 플랫폼을 위한 선택이라는 과거의 영광을 되찾았죠. 단일 플랫폼 코드 기반을 갖는 것이 점점 큰 문제가 되기 시작했습니다.

프로그래밍 언어도 마찬가지입니다. TIOBE Index에 의하면 16%가 넘던 C++의 사용률이 6%로 감소하고 R과 같은 새로운 언어가 떠오르며 Python을 선택하는 사람들이 많아지기 시작했죠. 15년 간의 C++코드를 가져오는 것만으로는 C++17에서 컴파일할 수도 없습니다. 혹은 심지어 프로그래밍 메소드도 마찬가지입니다. 예전엔 Microsoft Project의 Waterfall이 표준이었지만 이제는 단위 테스트 메소드 방법이 계속해서 인기가 많아지며 Scrum 개발 방법은 현재 많은 회사의 문화에 뿌리를 내리고 있습니다. Apple은 자체적인 CPU를 갖고 있으며 Microsoft Visual Studio는 Apple 장치를 위한 코드를 생성할 뿐만 아니라 심지어 Mac에서도 실행할 수 있죠. 드디어 레이 트레이싱도 사용할 수 있게 되었으며 대부분의 사용자들이 CPU에 적어도 4개의 코어를 가지고 있습니다. 15년 만에 정말 많은 것들이 바뀌었죠!

도약을 위한 작은 걸음들

4년 전에 저희는 가시적인 레이어뿐만 아니라 문제의 근본적인 원인을 제거해나가기 시작했습니다. 하지만 12,000개의 파일에 있는 220만 줄의 C++ 코드(2017)가 그저 스위치 하나를 끄는 것만으로 실행될 수는 없죠. 많은 시간과 헌신이 필요한 작업입니다. 플러그인 코드 자체만으로도 이제 수백 개의 함수가 들어 있으며, 그 중 많은 함수가 처음 출시 후에 한 번도 변경되지 않았습니다. 생산 안정성이 유지되는 동안 모든 조각들이 천천히 제자리를 찾아야 했고 사람들이 알아차리지 못하게 수정되어야 했습니다.

간단한 예시로 저작 코드는 대부분 문자당 2 바이트인 Wide-char(확장 문자)로 되어 있습니다. 저희 플러그인도 이를 반영했습니다. 뿐만 아니라 이 Wide가 Windows에서는 2 바이트지만 Mac에서는 4 바이트기 때문에 플랫폼마다 결과와 코드가 다릅니다. 15년간 UTF-8은 놀라울 정도로 훌륭해지면서 크로스 플랫폼 개발의 표준 선택이 되었기 때문에 저희는 수많은 기반 구조를 UTF-8로 마이그레이션하는 과정을 시작했고 2019.1 & 2019.2 릴리즈에서 반영하기 시작했습니다. 아직도 해야할 일이 정말 많이 남아 있죠.

또 오랫동안 유지해온 WwiseCLI 실행 파일을 예시로 들 수 있습니다. 이 파일은 여전히 명령어에서 Wwise를 실행하도록 해주지만 제작 당시에는 사실 사후 고려 사항이었습니다. 이 실행 파일은 배후에서 전체 그래픽 인터페이스를 실행했죠! 이 그래픽 인터페이스는 Windows와 밀접하게 통합되어 있으며 2년 간 인터페이스가 크로스 플랫폼 논리 부분과 Windows GUI 부분으로 나눠지는 재정의를 거친 후에 WwiseCLI가 2019.1에서  단지 명령줄만이 아닌 논리적 부분만 실행하여 드디어 점검을 거치게 되었습니다. 하지만 여기서 멈추지 않고 계속해서 2019.2 출시의 일부로 WwiseConsole에 표시된 코드를 개선하고 현대화했습니다. 

플러그인 재검토

2019.2에서 새로운 플러그인에 제대로 집중하기 시작했습니다. 사용자들에게는 알려지지 않은 채로 1세대 플러그인이 제작 도중에 출시되기 시작했죠. 물론 간단한 플러그인이긴 하지만 그래도 의미가 있죠! 저희는 이런 플러그인의 안정성에 대한 피드백을 모으기 시작했습니다. 그리고 가장 좋은 결과를 얻었어요. 피드백이 거의 들어오지 않은 거죠! 즉, 이제 레거시 플러그인이라고 부르는 플러그인과 새로운 플러그인 간에 눈에 띄는 차이가 없었다는 것입니다. (심지어 성능 면에서도 큰 차이가 없었죠) 일부 함수는 조금 더 느려지고 모든 것이 서로 연결되었지만, 이 때문에 플러그인에서 새로운 기능을 구현하는 것 뿐만 아니라 Wwise Authoring에서 성능을 개선하는 것이 훨씬 쉬워졌죠.

따라서 2019.2부터 저희는 레거시 플러그인과 새로운 플러그인을 동시에 지원하기 시작했고, 가능한 한 계속해서 이런 방향을 유지할 예정입니다.

새로운 2021.1 플러그인 API의 목표

플러그인의 미래

첫 번째 플러그인 버전은 15년보다 더 오래 전에 Authoring과 함께 제작되었습니다. 이 버전은 또 다른 15년간 Wwise Authoring의 성장을 돕게 될 겁니다! 이게 가장 중요한 목표입니다. 플러그인 인터페이스가 계속해서 변한다면 어떻게 될까요?

이 점은 저희의 다른 목표에서도 반영되는 것을 볼 수 있을 것입니다.

모든 플랫폼에서 사용할 수 있는 플러그인 만들기

플러그인 코드는 Wwise가 지원하는 모든 플랫폼에 걸쳐 동일해야 합니다. 미래에 Authoring 경험이 어떻게 변할 지 과연 누가 알 수 있을까요? 크로스 플랫폼 프로젝트가 시작되었을 때 저희는 네이티브 Mac과 Windows 실행 파일을 제공하고 최대한 빨리 그래픽 인터페이스를 마련하고 싶었습니다. 처음엔 그래픽 인터페이스가 없는 버전이 좋지 않을까 생각했죠. 처음 결과물이 나왔을 때 발빠른 사용자분들은 Linux에서 사운드뱅크를 생성할 수 있기를 원했습니다. 명령줄을 통한 효율적인 생성, WAAPI 서버, 헤드리스(headless), Unreal과 Unity에서의 보다 밀접한 통합까지... 이는 시작에 불과합니다. 휴대용 기기의 기능이 점점 늘고 있기 때문에, 어떻게 끝이 날지는 아무도 모르는 일이죠.

C++가 전부는 아니다

앞서 보았듯이 C++는 플러그인 개발에서 사용할 수 있는 수많은 언어 중 하나일 뿐입니다. 오늘날 사람들은 다양한 프로그래밍 언어로 플러그인을 제작하는 것에 관심이 많습니다. 21.1을 통해 Audiokinetic은 심지어 Sound Engine에서 Python을 실행하는 예시 코드를 제공해드립니다! 저희는 플러그인을 제약하고 싶지 않습니다. '플러그인은 최적화된 언어여야 한다'라는 아이디어는 여전히 C++에서 적용되지만, 이제는 다른 언어에서도 마찬가지입니다.

따라서 새로운 Authoring 플러그인은 C 기반 구조를 가지고 있으며 ABI와 API가 안정적입니다. 심지어 새로운 버전의 경우 전체 인터페이스가 사용한 언어에 상관 없이 모든 플러그인을 더욱 안정적으로 만들어줍니다. 제공된 현대식 메타-프로그래밍 브릿지는 C++ 플러그인을 간단하고 효율적으로 제작할 수 있게 해줍니다.

가장 좋은 플러그인은 플러그인이 없는 것이다

기능성을 확장하기 위해서는 반드시 Sound Engine 플러그인이 항상 필요합니다. 하지만 Authoring 측면 없이 전체 플러그인을 만들 수 있는 것이 가장 최고의 방법이겠죠. 제공되는 수백 가지 메소드를 사용해서 가장 간단하게 사용할 수 있는 파이프라인을 만드는 것이 가장 우선 순위입니다.

하위 호환성

플러그인의 모든 변경 사항에서 플러그인 판매사가 해야하는 일이 많다는 것은 분명합니다. 저희는 이 과정이 최대한 매끄러울 수 있도록 해드리는 것을 목표로 하고 있습니다. 바로 이 때문에 Legacy(레거시) 플러그인이 계속해서 존재하는 것입니다. 플러그인이 크로스 플랫폼으로 호환되지는 않지만 최신 21.1 SDK로 플러그인을 리컴파일하기만 하면 기본적으로 Windows에서 작동하죠.

이 부분은 추후 버전에서도 마찬가지입니다. 원하는 SDK 버전을 설정하고 최신 버전으로 다시 컴파일링하면 인터페이스가 호환할 수 있도록 최대한 지원하겠습니다.

하위 호환성은 결국 나중에 문제가 되기 때문에 이 일시적인 연결 고리는 결국 사라지겠지만, 문제가 되지 않는 이상 저희는 계속해서 제공할 예정입니다.

레거시 연결 고리는 크로스 플랫폼 호환성을 불가능하게 해주기 때문에 가장 먼저 사라지게 됩니다. 하지만 21.1의 경우 아무 것도 수정할 필요가 없습니다.

버전을 통한 확장

코드는 출시를 거듭하며 계속해서 유지되거나 전환되기 때문에 인터페이스에서 내용이 추가 및 변경되거나 제거될 수 있습니다. 간단한 예시로, 21.1에서는 Authoring에 대한 전환을 먼저 준비하기 때문에 크로스 플랫폼 GUI가 아직 제공되지 않습니다. 또한 변환과 분석 플러그인같은 플러그인 종류가 이론적으로는 서드파티 판매사에서 실행될 수 있지만 현재는 구현이 불가능합니다.

모든 부분 시험하기

너무 많은 것이 변경되면 그야 말로 멘붕(두려움, 불안, 의심을 동반함)이 올 수 있죠. 이렇게 수많은 작업에는 적지 않은 예산이 들어가고, 저희는 그 예산을 써서 좋은 결과를 얻고 싶으니까요. 이 Wwise Authoring 부분은 플러그인의 다른 부분을 시험하는 데에 좋은 기반이 됩니다. 아마도 Sound Engine 개선 사항의 기반이 되지 않을까 싶네요. 아무도 모르는 일이죠!

Wwise 생태계에 대해 잘 알려지지 않은 기능 중 하나는 바로 확장성입니다. 프로젝트에 사용할 플러그인을 회사들이 직접 만들기도 하고 판매사는 (가끔은 저희 도움을 통해) 자체 플러그인을 Wwise에 마이그레이션하기도 합니다. 올해 곧 출시되는 새로운 버전을 통해 이 훌륭한 시스템은 대대적인 첫 번째 개편을 앞두고 있습니다!