오늘 소개할 이야기는 뜻밖의 결과, 다시 말해 우연한 발견에 관한 이야기입니다. 연구 프로젝트가 의도한 대로 끝나지 않았기 때문에 복잡하게 느껴지실 수도 있지만 끝까지 지켜봐주세요. 이렇게 예기치 않은 발견은 역사적 연구에서 꽤나 흔히 일어난답니다. Conker’s Bad Fur Day(컨커 최악의 날) 연구 프로젝트는 이에 대한 완벽한 예시입니다. (컨커가 누군지 모르신다면 여기를 클릭해 보세요.) 저는 Twitter에서 Nintendo 64 사운드 시스템에 관한 스레드를 작성하다가 간단한 질문이 생겼는데, 이 질문이 꼬리에 꼬리를 물고 더 많은 질문들로 산사태처럼 커져서 역사적인 재앙이 되어버렸습니다. 사실 '재앙'이라는 단어가 너무 드라마틱하긴 하지만 이 글을 끝까지 읽고 나시면 저와 동의하실 수도 있을 것 같아요.

기술적인 예외 사항

N64 사운드 시스템은 아주 복잡합니다. 하드웨어가 전용 사운드 카드, 칩, 프로세스가 없이 설계되었죠. 각 개발자는 음악과 효과음을 재생하기 위해 완전히 처음부터 모든 것을 즉흥적으로 개발해서 결국 RCP와 RSP 프로세서를 사용하여 재생되도록 더빙해야 했습니다. N64 시스템에서 사운드, 그래픽, AI, 데이터 저장 등의 균형을 조심스럽게 유지하기 위한 기술적인 해결책이 그 당시 아주 많았습니다. 이 섬세한 균형은 복잡하면서도 흥미로운 N64 사운드의 역사를 만들어냈죠. 또한 이 시스템은 잘 알려지지도 않았으며 이 하드웨어에서는 레트로 엔지니어링이 아주 까다롭습니다. 그래서 Rare Limited(레어 리미티드)라는 개발사가 Conker(컨커)와 Perfect Dark(퍼팩트 다크)와 같은 게임에서 MP3 손실 오디오 압축 형식을 가장 처음으로 사용한 스튜디오라는 것을 알게 되었을 때, "도대체 어떻게?"라는 질문이 생길 수 밖에 없었습니다. 그 당시 MP3는 새로운 형식이었으며 90대 후반에는 잘 알려지지 않다가 2000대에 대중적으로 사용되기 시작했죠. 이 파일 형식을 게임에 통합하면서 분명히 문제가 있었을 것이라는 생각이 들었습니다. 혹은 게임 사운드의 역사에서 아주 흥미로운 퍼즐 조각 하나가 숨겨져 있을 것이라고도 생각했죠. 그래서 정보를 찾아보다가 보이스 오버만 MP3를 사용한다는 것을 알게 되었습니다. 음악을 렌더링하기에는 압축률이 그다지 좋지 못했을터이니 이 편이 더 이해가 갔습니다.

저는 기술 애호가 포럼에서 오래된 게시글 중 아주 흥미로운 글을 발견했습니다. 어떤 사람이 Conker에 있는 모든 MP3 파일을 추출해냈더군요. 오디오 클립을 들어보니 단 하나를 빼고는 모두 게임에서 들리는 그대로였습니다. Conker를 제외한 추출된 모든 파일은 게임에서 듣는 것과 완전히 똑같이 들렸습니다. 주요 캐릭터인 Conker의 음성은 속도가 빨라진 것처럼 들렸고 결함음이 아주 많았습니다. 업로드된 예시가 많아서 몇 가지 파일을 가져와 들어보고 모든 파일이 그렇다는 것을 쉽게 알아낼 수 있었습니다. 어떤 도구를 사용하여 파일을 추출해냈는지 알지 않고서는 이 이상한 결함음이 추출해내는 과정에서 생긴 것이라는 가정을 하기가 어려웠습니다. 왜나하면 이 '버그'가 너무 구체적이었기 때문이죠. 심지어 다른 캐릭터와 Conker가 함께 포함된 파일에서도 이상한 결함음을 들을 수 있었습니다. 이 이유를 알아내기에는 제 기술적인 지식이 부족했기 때문에 제 친구인 @Percight에게 도움을 요청했습니다. @Percight도 저처럼 아주 흥미가 생겨서 같이 몇 가지 시험을 해보기로 했습니다.

@Percight가 진행한 시험을 통해 저희가 가진 질문에 대한 시원한 답은 알아내지 못했지만 몇 가지 흥미로운 정보를 알아내기 시작할 수 있었습니다. 저희가 이 이상한 오디오 현상을 이해하는 데에 가장 큰 장애물이 되었던 것은 바로 파일을 얻기 위해 사용된 디컴파일, 추출, 압축 해제 도구에 대한 정보가 아무 것도 없었다는 것이었습니다. [보관 전문가의 팁: 사용된 도구가 무엇인지를 아는 것은 굉장히 중요합니다. 특히 공식적인 도구가 아닐 경우에는요. 어떤 도구를 사용해서 파일을 추출했는지 짐작해볼 수는 있지만 어떤 버전을 사용했는지를 알 수가 없기 때문에 특정 버전에 관련된 문제를 알아낼 수가 없게 됩니다.] Conker의 음성은 사용된 MP3 읽기 도구에 따라 다르게 들리더군요. 저는 MP3 파일을 WAV 파일로 변환해서 Acousmographe 도구를 통해 스펙트럼을 분석해봤습니다. MP3에는 버그와 잡음이 많아서 Windows의 기본 플레이어를 사용할 경우 Conker를 알아듣기가 거의 불가능했습니다. 하지만 WAV 버전은 속도가 빨라진 것처럼 들렸습니다. 바로 이 시점에서 포럼의 원본 게시글에서 언급되었던 신박한 아이디어가 생각났습니다. 설마 저장 공간을 확보하기 위해서 Conker의 음성을 일부러 가속한 것일까요? Conker는 게임에서 가장 수다스러운 캐릭터이기 때문에 그의 대사가 대부분의 데이터 공간을 차지했을 것입니다. 혹시 사운드가 N64 카트리지 공간(당시 제작된 장치 중 공간이 가장 큰 64MB였습니다)을 너무 많이 사용하지 않게 하기 위해 비밀스러운 해결책으로 속도를 높인 것인가라는 생각이 들었죠.

만약 그렇다면 왜 다른 캐릭터의 음성도 가속해서 공간을 절약하지 않은 것인가라는 의문이 생겼습니다. 어떤 가설에서든 가능한 모든 가능성을 배제할 수는 없죠.

여기 이 파일에서 Conker가 어떻게 들리는지 들어보세요 .  CW: 언어.

역사적 근거 파고 들기

저희가 기술적 분석을 한 결과 아주 흥미로운 질문이 생겼습니다. 공간을 확보하기 위해 소리를 가속한 것은 과연 누구였을까요? 저희 이론을 증명할 방법이 없었기 때문에 역사적인 부분을 조금 더 파보기로 했습니다. 게임 역사의 장점은 게임을 제작한 수많은 사람들이 여전히 우리 곁에 있다는 것입니다. 그래서 그분들에게 이에 대해 직접 물어보고 그들의 지식과 전문성을 기록해둘 수 있죠. 특히 수많은 컨퍼런스가 존재하는 게임 업계에서 이 말이 어떻게 보면 아주 당연한 것으로 들릴 수 있겠지만, 기억은 쉽게 사라지기 때문에 이렇게 구체적인 질문을 너무 늦기 전에 물어볼 필요가 있습니다. 저희는 정말 행운스럽게도 Twitter에서 Conker의 작곡가인 로빈 빈랜드(Robin Beanland)로부터 유익한 답변을 얻을 수 있었습니다. MP3 형식이 보이스 오버에서만 사용되었다면 24~40kb/s 사이의 낮은 비트레이트(음악에는 조금 더 높은 음질 사용)의 경우 명료도를 희생하지 않고서는 더 많은 파일을 위해 공간을 절약하기가 어려울 것입니다. 로빈 빈랜드는 '공간 절약'에 대한 가설조차 들어본 적이 없다고 동의하지 않았죠. 여기서 알 수 있었던 것은 Conker가 Rare Limited가 MP3를 사용한 최초의 게임이라는 사실이었습니다. 게임의 코드는 Perfect Dark 개발 팀이 사용할 수 있도록 출시 전에 이들에게 제공되었습니다. 이 부분도 옛날에는 내부적으로 어떻게 일을 처리했는지 엿볼 수 있는 흥미로운 정보였습니다.

그리고 그 당시에는 MP3를 압축 해제해서 ADPCM와 함께 게임플레이 시퀀스 도중 실행할 수 없었다는 흥미로운 사실도 알게 되었죠. 이러한 사실은 'Great Mighty Poo' 노래와 같이 게임에서 중요한 음악들은 다른 형식을 취하고 있다는 점을 떠올리게 했습니다. 시네마틱 씬은 크리스 말로우(Chris Marlow, Great Mighty Poo의 성우)의 음성이 담긴 MP3를 사용하지만 게임플레이 시퀀스 도중 발생하는 음성은 ADPCM을 사용합니다. Great Mighty Poo의 입 안으로 화장지를 던지려면 그가 언제 노래하는지를 알아야 하죠! 아까 언급했었던, 이상하게 가속된 음성에 관해 로빈 빈랜드는 이것이 메모리 절약을 위한 것이 아니었다는 것 말고는 더 이상의 정보를 제공해주지 않았습니다. 하지만 이 형식 차이에 관한 새로운 정보를 알고 난 후에 @Percight는 그의 작업을 더욱 깊게 살펴보기로 했습니다. @Percight는 Foobar2000와 Checkmate MP3 Checker(항상 오류 보고가 있었음)에 관한 대화를 시작했습니다. 지속적인 '알 수 없는 바이트'와 '유효하지 않은 헤더 값'에 관한 오류는 저희에게 한 가지 사실을 증명해주었습니다. 이 파일은 커스텀 MP3이며 Conker가 말할 때 사용하는 헤더는 독특했습니다. 여기에서 저희의 모험을 멈출 수도 있었겠지만 몇 주 후에 저는 매달 개최되는 Interactive Audio Montreal (IAM, 상호작용 오디오 몬트리올) 미팅에서 이 프로젝트에 대해 말할 기회가 생겼습니다. 여기서 저는 Plogue(플로그)의 설립자인 데이비드 비엔스(David Viens)와 공동 발표를 했는데, 새로운 화제가 되었죠.

이 이야기는 역사가와 기록 보관 전문가들이 자주 묻는 질문의 완벽한 예시입니다. 제가 IAM 미팅에서 이 프로젝트를 공유한 이유는 사운드 팀의 시점 없이 게임의 사운드를 맥락을 떠나 이해한다는 것이 얼마나 큰 실수인가를 강조하기 위함이었습니다. 이 발표 후에 저는 몇몇 사운드 전문가에게서 흥미로운 피드백을 받았습니다. 메모리 절약을 위해 보이스 오버를 가속하는 것이 몇 년 전에 실제로 사용하던 방법이라더군요. 그리고 보통 작곡가가 곡을 전달한 후에는 전달한 곡과 사운드에 전반적으로 어떤 일이 일어나는지를 모른다는 것도 알게 되었습니다. 구현 전문가들이 어떤 방식으로 작업하는지 작곡가가 알지 못한 채 많은 기술적 처리 작업이 진행되기 때문에 모든 문제에 관해 작곡가들이 해답을 알지 못한다는 것이죠. 우연히 듣게 된 이 피드백은 저에게 답을 알 수 없는 질문들을 더 안겨주었습니다. 그리고 얼마 지나지 않아 우연히 프랑스 기술 잡지 Canard PC Hardware(까나르 PC 하드웨어)에 N64 사운드 시스템에 대한 글을 써달라는 요청을 받게 되었습니다. 이 이야기를 마무리 지을 수 있는 절호의 기회였죠.

기술적 이야기: 'MyButt.mp3' 이해하기

기술적인 상세 정보에 관심이 있으신 분들을 위해 @Percight가 'Great Mighty Poo' 대사의 아주 흥미로운 부분에서 이름을 얻은 MP3 파일을 분석한 결과를 공유해드리겠습니다. 이 대사는 악당과 다람쥐의 빠른 토론으로 인해 속도 문제가 더욱 현저하게 드러나는 부분입니다. Conker의 음성에 해당하는 프레임은 특정한 헤더를 사용합니다. '일반' 보이스는 0xFF 0xF3 0x50 0xC0이라는 헤더를 사용하지만 다람쥐 음성 헤더의 마지막 바이트는 0xFF 0xF3 0x50 0xC8이라는 다른 헤더를 사용합니다. 이는 'Copyright(저작권)' 정보에 사용되어야 하는 부분에서 0000을 1000로 바꾼다는 것을 나타냅니다. 지금까지는 이 부분이 그 목적으로 존재하는 것 같지는 않습니다. 아래서 확인할 수 있듯이 '1'은 프레임의 끝과 다음 헤더의 시작 사이에 추가된 데이터를 말하지만, 이 정보가 딱히 저작권에 관한 내용을 담는 것은 아닙니다.

이상하게도 성우가 다른 마이크를 사용했을 수 있다는 것을 빼고는 스펙트럼에서 딱히 보이는 것도 없었죠.

@Percight가 이상하게 생각한 또 다른 점은 Conker의 음성에 관련된 모든 프레임이 동일한 헤더를 사용하지 않는다는 것이었습니다. 다른 파일에서는 달랐기 때문에 이 부분도 더 알아볼 필요가 있다고 생각했죠. @Percight는 부속 헤더에서의 프레임을 삭제해서 파일이 좀 더 안정적이도록 만들었습니다. 하지만 사운드가 완전히 별로더군요. 마치 오디오 플레이어가 읽기 속도 대신 기본 프레임을 선택해서 읽는 것처럼 들렸습니다. 저희는 Conker의 단어를 의미 없는 말로 만들기 위해 사운드의 일부를 잘라내서 데이터의 일정 부분이 삭제된 것을 발견했습니다. 그런 다음 @Percight는 모든 '0xC8'을 '0xC0' 헤더로 변경해서 파일이 일반적인 지속적인 비트레이트 MP3처럼 보이게 해봤습니다. 하지만 결국 아무것도 바뀌지는 않았습니다. 그래도 시도 자체는 의미가 있었죠.

마지막으로 살펴봐야 할 것이 하나 있었습니다. 바로 저항 프레임(rebel frame)이 파일을 더 무겁게 만든다는 것입니다. Conker의 파일은 9 바이트로, 다른 헤더를 사용하는 파일보다 더 깁니다. @Percight는 각 파일에 있는 9 바이트 파일을 억제해보았고, 그러자 기적적으로 파일이 완벽하게 읽히게 되었습니다. 드디어 공간 절약 가설이 틀렸음을 완벽하게 밝혀낼 수 있었죠!

사건 해결하기: 우리를 살려준 오디오 소프트웨어 엔지니어

이제 @Percight가 무엇이 Conker의 음성을 바꿨는지 찾아냈으니 남아있는 질문은 이 추가적인 바이트의 목적이었습니다. 헤더가 아주 구체적인 패턴을 가지고 있는 이유가 분명히 있을 것이라고 생각했습니다 (0x4C 0x3A 0x01 0xXX 0x80 0x80/0x81 0xXX 0xXX 0x00). 오디오 디코더가 이 헤더를 올바르게 읽을 수 없다는 점을 감안할 때 아마 소리와 관련이 없는 이유이지 않을까 생각하기 시작했습니다. 이 마지막 질문은 수많은 이유로 인해 이 프로젝트를 작업한 사람만이 답할 수 있었죠. 연구 기사의 마감일이 다가오고 있을 때 드디어 그 당시 프로젝트의 오디오 소프트웨어 엔지니어였던 마이크 커링턴(Mike Currington)과 연락이 닿게 되었습니다. 마이크는 아주 친절하게 모든 질문에 답을 해주며 저희가 찾고 있던 퍼즐 조각을 제공해주었죠.

Conker의 캐릭터는 말을 할 줄 아는 다람쥐라는 것 외에도 숨겨진 기능이 있습니다. 헤더가 오디오와 관련이 없을 것이라는 가정 덕분에 이 부분을 간과하지 않았죠. 바로 정확히 그 이유 때문이더군요. 게임에 있는 다른 캐릭터는 대사 도중 랜덤으로 입을 그저 움직이지만 우리의 귀여운 영웅은 애니메이션 과정과 연결이 되어 있습니다. Conker는 다양한 표정과 입모양으로 애니메이션되어 있었는데, 이를 위해서는 아티스트가 다양한 얼굴 블렌드 모양을 대사와 동기화시켜야 합니다. MP3 파일에 있는 추가 바이트는 마이클 커링턴이 시네마틱 씬 도중 립싱크를 간소화하기 위해 만든 도구의 일부였습니다. 몇 달 간의 연구 끝에 드디어 우리가 원하는 답을 알아낸 순간이었습니다. 세상을 구해낸 듯, 다행히 제 기사도 살려낼 수 있었습니다.

이 이야기는 먼저 프랑스로 출판되었으며, 또 다른 Twitter 스레드를 통해 Rare 팀으로부터 더 많은 정보를 얻을 수 있었습니다. Conker의 만화 같은 목소리는 2 반음(semitone)으로 피치가 높아졌으며 전체 처리와 렌더링은 구현 전에 실행되었습니다. 로빈 빈랜드는 동일한 음성 지속 시간을 유지했기 때문에 저장 공간을 절약하기 위한 것이 아니었다는 걸 100% 분명히 알 수 있었죠.

최근에 크리스 시버(Chris Seavor)는 그의 Twitter 계정을 통해 스케치와 레벨 디자인 스캔을 공유하기 시작했습니다. 개발 도중 게임이 어떻게 변화하는가를 볼 수 있는 훌륭한 자료이죠 (출처: https://twitter.com/conkerhimself/status/1359160911769010183 ) (크리스 시버 님의 허락을 받고 공유합니다)

현명하게 마무리된 우리의 탐험

Conker의 오디오 파일에 있는 이상한 오디오에 대한 흥미로운 이야기를 파헤칠 수 있었던 것은 모두 이 도구를 만들고 결과를 공개적으로 공유해주신 열정적인 익명의 사람들 덕분입니다. @Percight의 분석과 원본 게임 사운드 팀의 답변이 아니었다면 이 모든 것이 그저 오해로 생각되었을 수 있을 뿐만 아니라 제가 Conker의 음성과 사운드에 관한 잘못된 역사를 공유하게 되었을 것입니다. 별 일 아닌 것처럼 느껴질 수 있지만 MP3를 사용한 것이 데이터 저장 전략이었다고 말했다면 역시적으로 큰 실수가 되었을 수 있겠죠. 이것이 실수인 첫 번째 이유는 일단 잘못된 정보라는 것입니다. 두 번째 이유는 잊혀서는 안될 더욱 복잡하고 흥미로운 답변이 있다는 것이죠. 올바른 사람들과의 끝없는 토론으로 인해 저희는 1990대에 게임이 어떤 방식으로 작업되었는가에 관한 흥미로운 이야기를 알 수 있게 되었습니다.

끝으로 저희는 가장 쉬운 답이 항상 옳은 것은 아니며, 아주 중요한 정보가 우리가 필요로 할 때 잊혀질 수 있다는 것을 배우게 되었습니다. 그리고 사운드 파일에 사운드뿐만 아니라 다른 정보가 담길 수 있다는 것도 알게 되었죠. 이것은 기록 보관 전문가인 저에게 있어 이 립싱크 바이트로 무엇을 해야하는지에 대해 흥미로운 질문을 던져줍니다. 이러한 것들은 사운드 보관을 바꾸고 있습니다. 심지어 게임과 완전히 같은 사운드를 복원하더라도 사운드 파일로부터 이러한 것을 다시 가져오면서 보이스오버에 관한 역사의 일부가 사라질 수 있습니다. MP3 파일은 이야기 전체를 들려주기에 충분하지 않으며, 문맥 없이 들을 수 없기 때문에 이 문제를 해결하기 어렵게 만듭니다.

오늘날 프로그래머와 사운드 통합 전문가 사이에 기술적인 팁과 과정이 여전히 기록되거나 공유되지 않고 있죠. 물론 직업 윤리 의식과 NDA를 존중할 때 이러한 방법을 공유하지 않는 것이 중요하다는 것을 압니다. 게임이 출시되고 다음 세대의 게임, 하드웨어, 기술로 전진하게 되면 또다른 기억의 망각이 물결처럼 일어나겠죠. 그러면서 일부 도구와 팁은 쓸모 없는 것이 될 것입니다. 공유되지 않는 도구와 방법을 적절히 보관하지 않는다면 분실되거나 잊혀질 위험이 큽니다. 여기서 본 것처럼 게임에서 추출한 데이터는 작동 방식과 그 이유를 완전히 이해하기 위해 충분하지 않습니다. 역설계법도 대부분 정보의 부재를 채워나갸아 하기 때문에 완벽하지 않습니다. 이렇게 되면 게임 오디오 역사에서 답을 찾을 수 없는 기술적 문제가 남게 되며, 전체 그림을 보기 위한 도구가 없어지는 것이죠. 뿐만 아니라 모든 게임이 아마추어 게임 기술 역사가와 사운드 탐험가의 관심을 동일하게 이끄는 것이 아니기 때문에 우리가 적절한 시기에 적절한 곳을 보지 않는다면 훌륭한 많은 것들이 영원히 사라지게 될 수가 있습니다. 이 글에서처럼 우연함이 이렇게 흥미로운 발견을 가능케 하는 것이라면 시간이 지나면서 얼마나 많은 것들이 없어지게 될 것인지 상상해보세요.

저희의 모험은 그저 아무 것도 얻지 못한 채 끝나지 않았습니다. 공간 절약 이론이 '거짓'이라는 것은 역사적인 사실을 갖습니다. 제 연구를 통해 일부 게임은 오디오 파일의 속도를 높여서 공간을 절약한다는 것을 알게 되었죠. 일부 자료에서는 PlayStation3 시대까지 이 기술이 사용되었다고도 말합니다. 하지만 이 방법을 사용하는 특정 예시를 보지는 못했습니다. 가끔 Rainbow Six 3(레인보우 식스 3)의 보이스오버에서 가속된 음성에 대해 묻는 플레이어를 볼 수 있는데, 여기에 대해 Ubisoft의 게임에서 흔히 사용하는 방법이라는 답변을 볼 수 있습니다. 그리고 Super Mario(슈퍼 마리오)와 Mario Kart 64(마리오 카트 64)처럼 보다 오래된 N64 게임에서 이 기술이 사용되었을 수 있습니다. 오늘 배운 것처럼 정확한 답은 절대 알 수 없겠죠. 아마도 이 글을 읽고 계신 누군가가 이 기술적인 방법을 직접 경험해보셨을 수도 있고요! 기술이 변화해도 여러분의 작업이 잊혀지지 않도록 게임 오디오 역사의 지속적인 기록에 공헌하고 싶으신 분들은 여러분의 이야기를 저에게 들려주세요.