COLDSURF Tape는 제가 직접 만든 음악을 트는 자리예요. 이번에 여기에 빛을 입혔어요. 사운드를 틀면 화면 뒤에서 주파수에 맞춰 빛이 번지는 '빛의 벽'이요. 저역이 두꺼우면 화면이 묵직해지고, 고역이 열리면 빛이 가볍게 흩어져요. 소리를 눈으로 보는 느낌이에요.
가장 최근 호에 그대로 걸려 있어요. 직접 틀어보세요.
→ COLDSURF SOUND vol.9: First Light
바닥에서 수면으로 올라오는 다섯 곡짜리 호인데, 소리가 밝아질수록 빛도 같이 열려요. 그게 이 빛의 벽의 핵심이에요 — 미리 만들어둔 영상이 아니라, 그 순간의 소리를 그대로 그린 거라서요.
원래 이 빛은 사이트에서만 돌았어요. 그런데 Tape는 유튜브 영상으로도 나가거든요. 그래서 "영상에도 똑같이 입히자" 했는데 — 여기서부터 뒷이야기가 시작돼요.
근데 영상으로 구우려니 자꾸 죽었어요
영상 렌더는 화면 없는 브라우저를 하나 띄워서 한 프레임씩 그린 다음 이어붙이는 방식이에요. 돌렸더니 첫 프레임부터 이렇게 떴어요.
The browser crashed while rendering frame 0.
한 번이 아니라 계속이요. 브라우저를 새로 띄워도 또 죽고, 또 죽고.
첫 반응이 딱 두 가지였는데 둘 다 틀렸어요. "WebGL이 문제인가?" → GPU 안 쓰는 2D로 바꿔도 똑같이 죽었어요. "메모리인가?" → 오디오 파일을 잘게 줄여 물려도 똑같이 죽었어요. 두 번 다 고쳤다고 확신했고, 두 번 다 프레임 0에서 죽었어요.
"이거 사양 문제 아니야?"
솔직히 그 말이 맞는 것 같았어요. 16GB 맥북에서 16분짜리 영상을 굽는 거니까요. 그냥 더 좋은 장비로 돌리면 되지 않을까.
근데 '사양 문제 같다'는 대부분 확인 안 된 추측이에요. 그래서 추측을 멈추고 딱 하나만 확실히 했어요.
그제야 알아챘어요. 지금까지 테스트가 전부 오디오를 물고 있었다는 걸요. 크래시가 '빛을 그리는 것' 때문인지 '오디오를 읽는 것' 때문인지, 한 번도 따로 떼서 본 적이 없던 거예요.
그래서 오디오를 아예 뺐어요. 진짜 소리 대신 가짜 신호를 넣고 그림만 그려봤어요. → 됐어요. 그것도 아주 예쁘게. 앰버색 빛의 벽이 그대로 나왔어요.
범인이 확정됐어요. 그림 그리는 엔진은 무죄. 남은 용의자는 딱 하나, 오디오였어요.
진짜 원인은 구조였어요
이유는 단순했어요. 16분짜리 곡의 원본 파일은 165MB예요. 브라우저가 소리를 분석하려고 이걸 통째로 펼치면 메모리에서 약 346MB로 부풀어요. 그게 첫 프레임에서 터진 거예요. 32GB 맥북이면요? 조금 더 버티다 터져요. 근본이 안 바뀌거든요.
그러니까 이건 사양 문제가 아니라 질문이 틀린 문제였어요. "왜 브라우저가 곡 전체를 메모리에 들고 있어야 하지?" 안 들고 있으면 되거든요.
그래서 오디오 분석을 브라우저에서 빼서, 브라우저 밖(Node)에서 미리 해뒀어요. 곡을 직접 읽어 프레임마다 주파수를 계산하고(FFT), 14MB짜리 작은 파일 하나로 저장해둬요. 이제 브라우저는 소리를 디코드하지 않아요. 그 파일에서 '지금 프레임 줄'만 꺼내 빛에 넘겨요. 오디오 디코드는 0이에요.
980초짜리 곡이 2.4초 만에 계산됐고, 결과물은 진짜 음악에 반응해요. 무엇보다 — 16GB에서도, 서버에서도, 화면 없는 어디서도 돌아요.
그래서 지금은
이제 Tape 영상 전부에 이 빛의 벽을 입힐 수 있어요. 사이트에서 듣던 그 결을, 유튜브에서도 똑같이요.
그리고 저한테 진짜 남은 건 그 기술보다 그 앞이었어요. "장비가 딸리나" 싶었을 때 정말 필요했던 건 더 좋은 맥북이 아니라, 문제를 반으로 가르는 검증 하나였어요. 오디오를 한 번 뺐더니, 다섯 번 죽던 이유가 5분 만에 드러났거든요.
말로 하면 감이 잘 안 와요. 그냥 한번 틀어보세요.