사파리 비밀 지키기

Keeping Safari a secret

사파리라는 이름으로 우리가 부르기 훨씬 전 이야기이지만, 우리가 사파리를 개발하면서 보낸 시간 상당수는 아예 우리가 마이크로소프트 인터넷 익스플로러, 정확히는 맥용 인터넷 익스플로러를 개발하는 것으로 위장했었다. 맥용 익스플로러는 1998년 이후 애플이 제공해 왔었으며, 사파리가 데뷔하기 6개월 전에는 모질라 브라우저인 양 행세했었다.

어째서 그랬을까? 어떻게 사파리가 이들 브라우저인 양 만들었을까? 코드와 행동이 그리 다른데도?

스콧 포스탈(Scott Forstall)로부터 받은 명령은 다음과 같았다. 브라우저를 하나 만들고, 브라우저를 만들 팀도 하나 만들라는 것이었다. 하지만 훨씬 더 중요한 임무가 또 있었다. 프로젝트 전체를 완전히 비밀로 하라는 것. 그래서 처음 팀을 구성할 때 그들에게 뭘 할 팀인지 말해줄 수가 없어서 정말 복잡했었다. 여러분의 회사 내 어려움도 말씀해 보시라. 하지만 그것은 다른 주제이다.

그래, 비밀이다. 우리는 당시 조니 아이브의 디자인 그룹이나 몇 년 후의 아이폰 팀처럼 아예 물리적으로 닫힌 공간에 있지 않았다. 그러나 누구를 찾고 있는지 스스로 알지 못 한다면, 우리는 캠퍼스 안에서 찾을 수가 없었다. 설사 찾는다 하더라도 실제로 우리가 사파리를 돌리는 모습을 잡아 내지라도 않는 한 우리가 뭘 하고 있는지는 몰랐을 것이다. 보통은 사무실 문을 잠근 채로 있었다.

말에 대해서는 염려받지 않았다. 분명 포스탈은 나를 신뢰했고, 그를 훌륭한 보스로 만들어준 수많은 장점 중 하나가 바로 그러한 신뢰성이었다. 나 또한 내 팀을 신뢰했다. 그러하지 않았다면 아예 처음부터 고용하지 않았을 것이다. 우리 중 누구도, 애플 내 베타 테스터 누구도 밀고할 사람은 없었다. 물론 베타 테스터는 너무나 수가 적었지만 비난의 대상이 될 수 없었다.

당시는 트위터나 페이스북도 없었다. 애플 내 누구도 자기 일을 블로그에 적을 정도로 멍청하지도 않았다. 내가 두려워할 일이 뭐 있겠는가?

있었다. 서버 로그이다. 정말 무서운 것이 바로 서버 로그였다.

웹브라우저가 웹서버로부터 페이지를 하나 읽어들이면, 브라우저는 유저 에이전트 스트링을 서버로 보낸다. 기본적으로는 이름과 버전, 플랫폼 등의 정보를 전하게 마련인데, 브라우저는 IP 주소 또한 서버로 보내준다. 그래야 페이지를 어디로 돌리는지 서버가 알기 때문이다. 이러한 교환으로 웹이 움직이기도 하지만, 이런 방식으로 돌아가야 누가 어떤 브라우저를 어디에서 사용하는지도 알 수 있다.

이 이야기가 어디로 향할지 이미들 짐작하시잖겠는가? 잠깐만 기다리시라. 더 있다…

1990년대 무렵, 선각자들이 애플에게 클래스 A 네트워크 IP 주소 전체를 부여해 줬었다. 맞다. 애플은 16,777,216개의 정적 IP 주소를 갖고 있다. 그리고 이 모든 주소가 모두 한데 묶여 있다(현재는 "/8 블럭"이라 불린다). 또한 주소가 모두 특정 숫자로 시작한다. 애플의 경우 그 숫자가 17이었다.

IP 주소 17.149.160.49? 애플이다. 17.1.2.3? 맞다. 애플이다. 17.18.19.20? 또 애플이다. 17.253.254.255? 아, 애플이라니까!

당혹 그 자체였다.

프로젝트를 제아무리 CIA 비밀첩보 작전처럼 수행하더라도(충성 맹세와 함께 말이다) 애플 캠퍼스 네트워크상에서 사용할 때 사파리를 "사파리"로 놓아둘 수가 없었다. 그렇지 않으면 웹서버 관리자 누군가가 로그 파일을 보면서 IP 주소를 눈여겨 보고 유저 에이전트 스트링과 무슨 관계가 있는지 알아볼 것이었다. 게다가 스티브 잡스는 2003년 맥월드가 열릴 1월 7일에 깜짝쇼로 사파리를 보여주고 싶어 했다. 나도 그러했고 말이다.

그래서 우리는 애플에 있을 때마다 나의 사파리 유저 에이전트 스트링을 깔끔하게 가렸다. 방금 "나의"라고 말한 이유가 있다. 실제로는 웹킷과 사파리의 코드 몇 개이기 때문이었다. (1) 내가 디자인했다 주장할 수 있고, (2) 여전히 실질적인 소스였기 때문이기도 하다. 하느님께 감사하다. 내 엔지니어링 팀은 나의 다른 수정도 모두 제거하거나 조절했다. 정말 좋은 사람들을 고용한 셈이다.

애플 캠퍼스 네트워크가 아닌, 가령 집에 갈 때마다 우리는 사파리를 수정해서 진짜 유저 에이전트 스트링이 나타나게 했다. 이러한 호환성 테스트를 하기는 해야 했다. 그때 나는 최대한 호환성을 갖도록 스트링을 조절했었다. 그래서 사파리 유저 에이전트 스트링이 그렇게 많은 정보를 담고 있는 이유이다. (예를 들어서 Gecko와 같은 브라우저 엔진 이름인 KHTML도 정보에 들어 있다.

당연히 실제 사파리 유저 에이전트 스트링을 끈 채 출하시킬 수는 없었기 때문에 차선책을 택했다. 특정 날짜 이후에 활성화시킨 것이다. 바로 10년 전 이맘 때 일이었다. 데뷔하기 며칠 전에서야 사파리는 모습을 감추고 있다가 자랑스러운 제품으로 등장했다.

사파리의 데뷔 며칠 전, 너무나 초조한 나머지 난 인터넷 서버 로그를 뒤지면서 잠도 못 잤었다.