2010년 구글 홈페이지는 특별한 날마다 로고를 변형한 '두들'을 선보였다. 그중에서도 팩맨 30주년 두들은 단순한 그림이 아니라 실제로 플레이할 수 있는 게임이었고, HTML과 CSS만으로 구현됐다는 점에서 당시로서는 이례적인 시도였다. 이 글은 그 두들을 만든 개발자가 16년이 지나 직접 밝힌 제작기이자, 좋은 의도로 내린 작은 결정 하나가 어떻게 예상 못 한 사고로 번졌는지에 대한 회고다. 흥미로운 점은 글쓴이 스스로 당시 직함이 '소프트웨어 엔지니어'에 가까운 무언가였을 뿐, 사용자 경험 팀의 디자이너였다고 밝히는 대목이다. 두들 팀 바로 옆자리에 앉아 있었다는 우연이 그를 구글에서 가장 중요한 지면의 코드를 맡는 자리로 이끌었다.
충실한 재현과 의도된 버그
제작의 원칙은 원작에 대한 충실함이었다. 플레이필드가 구글 로고 모양을 닮아야 한다는 제약, 이스터에그로 넣은 미즈 팩맨 모드, '아임 필링 럭키' 버튼을 'Insert Coin'으로 바꾼 장치 정도가 의도적인 예외였다. 글쓴이는 원작 팩맨에 존재했던 몇 가지 버그까지 일부러 재현했다고 말한다. 네임코(당시 표기)에 너무 일찍 도움을 요청하지 않고 거의 완성된 상태로 보여주려 했기 때문에, 인터넷에 축적된 팬들의 집요한 분석 자료에 기대어 게임을 복원했다는 점도 눈에 띈다. 사운드는 팩맨의 정체성이라 할 만큼 상징적이어서 포기할 수 없었는데, 순수 HTML·CSS만으로는 당시 소리 재생이 어려워 플래시의 조용한 지원을 빌렸다. 다행히 그 무렵 플래시는 대다수 브라우저에 깔려 있어 큰 문제가 되지 않았다.
'10초 후 자동 재생'이라는 결정
문제의 씨앗은 리더십이 두들을 더 크게 만들고 싶어 하면서 심어졌다. 사용자가 10초간 아무 조작도 하지 않으면 게임이 홈페이지에서 자동으로 플레이되도록 하자는 아이디어였다. 홈페이지는 오래 머무는 페이지가 아니었기에 글쓴이는 방해가 되리라고 걱정하지 않았다. 다만 그 결정의 당연한 귀결로, 팩맨은 소리까지 자동으로 재생되게 됐다. 팀도 이 사실을 인지했지만 '아마 괜찮을 것'이라고 판단했다고 한다. 결과적으로 그것은 괜찮지 않았고, 아무도 예상하지 못한 방식으로 괜찮지 않았다.
출시 당일 오전 9시(샌프란시스코 기준) 스위치가 켜지자 세계는 다시 팩맨에 열광했다. 피드백이 따라잡을 수 없을 만큼 쏟아졌고, 트위터가 다운되는 것을 글쓴이는 지켜봤으며, 온갖 기기에서 사람들이 게임을 즐긴다는 보고가 들어왔다. 그런데 '컴퓨터에서 무서운 소리가 난다'는 종류의 제보가, 예상한 경로가 아닌 엉뚱한 곳에서 올라오기 시작했다. '탭을 닫으면 된다'는 안내에 돌아오는 답은 한결같이 그들이 팩맨 탭을 열지 않았다는 것이었다.
CoolPreviews라는 숨은 변수
원인은 당시 널리 쓰이던 파이어폭스 확장 프로그램 'CoolPreviews'였다. 링크 위에 마우스를 올리면 페이지를 미리 보여주던 이 확장은 파이어폭스가 켜질 때 함께 조용히 실행됐고, 사용자 모르게 백그라운드에서 특정 웹사이트를 즉시 열었다. 캐시를 미리 채우려던 것인지, 잊힌 임시값이었는지는 글쓴이도 확실히 모른다고 한다. 하필 그 사이트가 google.com이었고, 그날 구글 홈페이지에는 소리가 켜진 채 자동 재생되는 팩맨이 있었다. 브라우저를 최소화해둔 채 메일을 확인하거나 솔리테어를 하려던 사람, 자신이 어떤 브라우저를 쓰는지조차 모르던 사람의 스피커에서, 10초 뒤 정체불명의 사이렌이 터져 나온 것이다. 보이지 않는 팩맨이 가장 기이한 방식으로 PC에 '침투'한 셈이었다.
글쓴이는 몇 시간 만에 패치를 내놨다. 해법은 오늘날 많은 브라우저가 기본값으로 삼는 방식과 같았다. 눈에 보이는 음소거 버튼을 추가하고, 소리가 나려면 사용자가 먼저 키 입력·클릭·멀티터치·Insert Coin 등으로 게임을 건드리게 했다. CoolPreviews는 그런 조작을 하지 않으니 '빙의된 컴퓨터' 문제는 사라졌다. 역설적이게도 홈페이지에서 10초 동안 가만히 있는 사람은 거의 없었던지, 정작 일반적인 자동 재생으로 불편을 겪었다는 제보는 들은 적이 없다고 한다.
실무자가 가져갈 교훈
이 사건이 지금의 개발자에게 주는 함의는 분명하다. 자동 재생 사운드는 그 자체로 위험하지만, 진짜 사고는 내 코드가 통제할 수 없는 외부 요소—다른 회사의 브라우저 확장, 캐시 프리페치 동작, 사용자가 인지조차 못 하는 백그라운드 요청—와 맞물릴 때 터진다. 개발자가 '사용자가 홈페이지를 10초간 본다'는 전제를 세웠지만, 실제로는 보이지도 들리지도 않게 페이지를 여는 제3의 프로그램이 그 전제를 완전히 깨뜨렸다. 사용자가 음소거를 풀거나 먼저 상호작용하도록 요구하는 이른바 '사용자 제스처 게이팅'이 오늘날 표준이 된 배경에는 이런 경험들이 있다. 자동 재생을 설계한다면 내 지면이 어떤 맥락에서 열릴지 끝까지 통제할 수 없다는 전제를 깔아야 한다는 점이, 15년이 지나도 유효한 교훈이다.
다만 이 글은 엄밀한 사후분석 보고서가 아니라 한 개인의 회고라는 한계를 지닌다. 영향을 받은 사용자 규모, 제보 건수, 패치까지 걸린 정확한 시간 같은 수치는 제시되지 않고, CoolPreviews가 왜 그런 동작을 했는지도 글쓴이의 추정에 머문다. 또한 글쓴이 스스로 2010년을 '조금 더 순진했던 시대'라 부르며, 그때의 자동 재생 결정이 지금 기준으로는 '그로스 해킹'에 불편할 만큼 가깝게 느껴진다고 인정한다. 그럼에도 가장 가치 있는 지점은, 당시 세계에서 가장 중요했던 홈페이지를 실시간으로 긴급 패치했던 그 아찔한 순간을 정작 수면 부족 상태의 본인은 대수롭지 않게 넘겼다는 솔직한 고백이다. 참고로 플래시 없이 사운드를 다시 구현한 구글 팩맨 두들은 지금도 플레이할 수 있다.