웹폰트의 역사와 미래

하루에 적지않은 양의 글들(주로 웹페이지)을 읽게 되는데 이따금씩 글꼴의 중요성을 실감한다. 인터넷이 활발해지면서 이러한 글꼴들이 오프라인 인쇄물을 벗어나 웹으로 진출한 것은 자연스러운 흐름이었다. 그러나 웹에서 글꼴들이 편리하고 합리적으로 활용되기 위해서는 기술적인 문제 외에도 저작권을 비롯한 관련 법률 등의 장애물들을 넘어야했고 그 과정은 여전히 현재 진행형이다. 지금 이 순간에도 숨가쁘게 진화해가고 있는 웹과 글꼴의 흥미로운 관계를 소개하고자 한다.

단순히 가독성의 좋고 나쁨 이상으로 적절한 위치의 적절한 글꼴은 전달하고자하는 바를 다양한 감각으로 느끼게 해준다. 읽는 사람 뿐만 아니라 쓰는 사람에게도 비록 눈에 보이지는 않지만 글꼴의 심미적 효과는 분명히 존재한다. 따라서 어떤 글꼴을 선택할지는 그 글을 읽는 사람의 기호와 작성하는 사람의 의중 두 가지가 모두 중요하게 반영되어야 한다.

보통 잡지나 광고물 등에서는 이를 만든 사람이 사용한 글꼴을 독자가 그대로 받아들일 수 밖에 없기 때문에 글꼴의 결정은 전적으로 창작자의 책임이자 권한이다. 반면 웹이라면 얘기가 조금 다르다. 일반적으로 웹을 접하는 통로인 브라우저에서는 사용자가 자신이 설정한 글꼴로 웹페이지를 볼 것인지 또는 웹페이지를 만든 사람이 지정하는 글꼴을 사용할 것인지를 결정할 수 있다. 전자의 경우 원작자의 의도와는 무관하게 사용자가 좋아하는 글꼴로 웹페이지를 보겠다는 경우이므로 논할 거리가 없다. 그런데 만일 후자처럼 웹페이지에서 지정된 글꼴을 사용하도록 허용하였음에도 해당 글꼴이 컴퓨터에 존재하지 않는다면? 이때는 도리 없이 설치되어 있는 글꼴들 중 사용자가 골라둔 글꼴을 이용하여 웹페이지를 보여주게 된다.

이처럼 웹페이지 작성자가 심혈을 기울여 고른 글꼴이 사용자 컴퓨터에 없다는 이유로 제대로 표현되지 못하는 것은 안타까운 일이었고 이를 부분적으로나마 해결해주기 위하여 웹표준을 제정하는 W3C가 CSS Level 1 (1996)에서 font-family를 제공하였다. 기본적인 아이디어는 작성자가 보여주고자 하는 글꼴을 선호 순으로 나열하면서 통용적인 font-family 이름을 추가적으로 명시하여 원하는 글꼴이 없을 경우 최대한 비슷한 글꼴이 사용되도록 유도하는 것이었다. 이는 지금도 가장 흔하게 사용되고 있는 방법이지만 언제 어디서든지 일관성 있고 세련된 디자인을 실현시키고자 하는 창작자들의 욕구를 만족시키기에는 턱없이 부족했다.

사실 더욱 직관적인 방법은 사용자 컴퓨터에 웹페이지가 지정하는 글꼴이 없다면 다운로드하여 보여주는 것이었는데 CSS가 처음 제정될 때에는 공통적인 글꼴 형식도 없었을 뿐더러 작지 않은 글꼴 파일을 페이지 로딩 전에 다운로드한다는 것은 그 당시 인터넷 환경으로는 현실성이 떨어지는 방법이었다. 하지만 CSS가 널리 받아들여지기 시작하고 인터넷 환경도 비교적 발전해가면서 상황이 바뀌었다. W3C의 Working Group은 관련 기술을 갖고 있는 Adobe, Bitstream, Microsoft 등과의 협업을 통하여 CSS Level 2 (1998)에서 @font-face를 추가하였고 이것이 바로 근래에 우리가 말하는 웹폰트(Web-Font)의 시초이다.

@font-face는 인터넷에 미리 올려둔 글꼴 파일들을 웹페이지 내에서 불러와 사용할 수 있는 인터페이스를 마련해주었다. CSS Level 2는 글꼴 파일들의 형식에 대해서 제한을 두지 않았는데 그즈음 한창이었던 브라우저 전쟁의 연장선 상에서 Internet Explorer와 Netscape는 완전히 다른 방식으로 웹폰트 기능을 지원하게 된다. Mirosoft는 자체 개발한 EOT(Embedded OpenType) 글꼴 파일을 @font-face 규칙에 의하여 웹페이지 내에서 사용할 수 있는 기능을 Internet Explorer에 지원하였고 Netscape는 비슷한 기능을 PFR(Portable Font Resource)이라는 기술을 사용하여 독자적으로 구현하였다.

기술적으로만 놓고 보면 이미 오래전에 웹폰트는 일정 궤도에 이르렀다고 할 수 있겠다. 그러나 시대를 너무 앞서간 것 일까? 초창기 웹폰트는 생각만큼의 호응을 얻지 못했다. 여러가지 복합적인 요소가 있었겠지만 무엇보다 브라우저들의 지원과 디자이너들과의 공감대 형성이 부족하였다. 제작하는 과정에 상상 이상의 인내와 노력이 들어가는 글꼴들이 인터넷 상에서 불법적으로 배포되는 일이 만연하자 관련 업계 종사자들은 상용 글꼴을 웹을 통하여 제공하는 것에 대하여 상당한 거부감을 갖게 될 수 밖에 없었다. 결과적으로 많은 디자이너들은 웹폰트 대신 이미지 속에 글씨를 박아넣는 방식으로 다양한 글꼴에 대한 수요를 해결하는 길을 선택하였다.

표준으로써의 역할을 다하지는 못하였지만 그래도 웹폰트 기술은 부분적으로나마 활용되며 살아남았는데 그 예 중 한가지가 우리나라의 싸이월드이다. Mircosoft의 EOT는 글꼴 형식 중 거의 유일하게 라이센스 정보를 파일 내에 포함하고 있었다. 해당 글꼴이 사용될 수 있는 웹사이트의 URL들이 글꼴 파일 내에 담겨있기 때문에 싸이월드는 형식적으로나마 글꼴 파일의 저작권을 보호하면서 글꼴 개발 회사들이 제작한 글꼴들을 판매할 수 있었다. 더군더나 우리나라의 Internet Explorer 점유율은 압도적이였기에 다른 브라우저에서 EOT를 지원하지 않는 것은 큰 문제가 되지 않았다.

한편 웹폰트가 정체 상태에 있는 동안 웹생태계에서는 Image Replacement Technique들이 발전하였다. 이는 앞서 언급한 '이미지 속에 글씨를 박아넣는 방식'의 진화한 형태로써 CSS를 활용하여 디자인적인 요소가 가미된 이미지 정보를 Stylesheet에 담아놓고 브라우저에서 웹페이지를 렌더링할 때 HTML 내의 특정 텍스트를 특정 이미지로 치환해주도록 하는 기술이었다. Semantic Web을 위하여 주로 웹페이지의 타이틀 등에 적용되던 기술이 다방면으로 사용되면 될수록 사람들은 이미지의 유지 관리와 접근성 등에 대해 문제 의식을 느끼기 시작했고 이는 웹폰트로 하여금 새로운 전환점을 맞이하게 하였다.

W3C의 Working Group은 브라우저 제작사들이 웹폰트를 지원하게끔 만드는 것이 가장 좋은 해결책이 될 것이라 판단하였고 이를 위하여 기존의 @font-face 관련 기술을 다듬고 정리하였다. 또한 호환성 문제를 미연에 방지하기 위하여 이번에는 글꼴 형식을 직접 제정하기 위한 작업 역시 진행했다. 아이러니하게도 표준 웹폰트의 유력한 후보는 일반인들에게 웹표준 훼방꾼 이미지가 강한 Microsoft의 EOT였다. EOT는 DRM 수준까지는 아니더라도 납득할만한 수준의 라이센스 장치를 포함하고 있었고 OpenType의 발전된 특성들을 물려받고 있었기에 표준으로 삼기에 매우 매력적인 것이 사실이었다. Working Group은 Microsoft에 EOT 기술 공개를 요청하게 되고 실제로 Microsoft는 EOT의 표준화를 위해 Working Group과 긴밀하게 공조하였다.

우려와는 달리 EOT의 구현은 직관적이었고 표준화 작업은 순조롭게 진행되어갔다. Working Group 관계자들은 글꼴 업계 전반의 여러 사람들을 만나며 의견을 구하고 설득하는 과정에도 많은 노력을 기울였다. 2008년이 끝나갈때즈음 EOT는 표준화의 팔부능선을 넘은것 처럼 보였다. 그러나 최종적으로 W3C가 EOT의 표준화 작업 계획을 발표하자 Microsoft를 제외한 Mozilla, Opera 등의 다른 브라우저 제작자들은 크게 반발하였다. EOT의 내부 구현 및 효용성에 대한 반대는 토론을 통하여 해소될 수 있는 부분이었지만 치명적인 문제는 DMCA(Digital Millennium Copyright Act)였다.

DMCA는 저작권 보호를 위하여 제정된 법안으로써 DRM과 같은 저작권 보호 장치를 우회하는 행위 또는 기술을 범죄로 간주한다. 브라우저에서 EOT를 지원하고자 한다면 웹폰트를 사용한 페이지를 보여주기 위하여 EOT 파일을 읽어들여 분석한 다음 라이센스 정보와 웹페이지의 URL이 일치하는지를 확인해야한다. 만일 악의적인 사용자가 브라우저의 EOT 분석 코드 부분 중 라이센스 정보와 웹페이지 URL을 비교하는 부분의 코드만을 삭제한 다음 재배포한다면 브라우저 원작자는 DMCA에 의하여 공범으로 간주될 가능성이 있다. 이유인즉 EOT 분석 코드의 대부분을 브라우저 원작자가 작성하였기 때문이다. 실제로 이런 일이 일어날 확률이 매우 낮고 법원에서 어떤 판결을 내릴지 확언 할 수는 없지만 브라우저 제작자들(특히 오픈 소스 브라우저 제작자들)은 그러한 위험을 감수하고 싶어하지 않았다.

예상치 못한 난관에 부딪힌 웹폰트 표준화 작업은 다시 원점으로 돌아왔고 결국 Mozilla에서 제안한 글꼴 형식인 WOFF(Web Open Font Format)를 표준으로 채택하기 위한 작업이 2010년 현재 진행중이다. WOFF는 EOT처럼 OpenType 글꼴을 그대로 포함하고 있지만 압축 및 구현 방식에 있어서 차이가 있으며 무엇보다 라이센스 장치 대신 글꼴 제공자가 저작권 등의 정보를 명시할 수 있는 Metadata를 포함하고 있다. 이 Metadata는 글꼴이 로드되는 과정에는 관여 하지 않기 때문에 DRM의 일종으로 간주 될 수 없고 따라서 DMCA로부터 자유로울 수 있을 것이다. 비록 글꼴 파일 단계에서 사용권한을 통제할 수는 없지만 원작자에 대한 정보를 함께 표시할 수 있는 수준에서 글꼴 업계 사람들도 지지를 보내었다.

웹폰트의 표준화 작업이 이렇게 먼 길을 돌아가는 동안 수요에 발맞추어 브라우저들은 속속 @font-face를 지원하기 시작하였고 어느덧 대부분의 브라우저 최신 버전은 @font-face를 지원하고 있다. 다만 여전히 Internet Explorer는 오직 EOT만을 지원하고 그 외의 브라우저들은 EOT를 제외한 OTF/TTF등을 지원하고 있으며 일부 오래된 버전의 브라우저들은 @font-face를 아예 지원하지 않기 때문에 웹페이지 작성자 입장에서는 호환성을 유지하는데에 어려움이 있다. 이러한 번거로움을 해결해주기 위한 서비스로 Google에서는 Google Font API를 무료로 제공하고 있으며 상용 서비스들도 하나둘씩 등장하는 추세이다.

특히 직접 개발한 글꼴로 웹에서 수익을 올리고 싶어하는 업체들과 고급 글꼴을 자신들의 디자인에서 사용하고 싶어하는 사람들 사이의 시장을 파고드는 서비스들이 나타나기 시작했는데 대표격이 TypeKit, Ascender, Kernest, Typtheque 등이다. 이들 업체는 Javascript를 활용하여 강력한 호환성을 제공함과 동시에 저작권자가 글꼴의 사용권한을 원하는대로 통제할 수 있도록 해준다. 뿐만 아니라 글꼴 파일을 직접 호스팅해줌으로써 네트워크 트래픽 부담을 덜어주고 빠른 시간내에 안정적으로 웹폰트 파일이 다운로드 되도록 지원하고 있다.

여기까지 웹과 글꼴의 짧지 않은 여정을 정리해 보았다. 어느 분야던지 기술이 표준화되고 광범위하게 쓰이기까지는 수 많은 사람들과 단체들의 참여와 유기적인 협조가 필요하다는 것을 새삼 느낀다. 아무쪼록 웹폰트의 표준화 작업이 마무리 되고 모든 브라우저에서 공통적으로 해당 글꼴 형식을 지원하게 된다면 더욱 다양한 웹폰트와 관련 서비스 제공 업체들이 등장할 수 있게 되지 않을까 생각한다. 아쉽게도 아직 한글 글꼴을 지원해주는 서비스는 보지 못했는데 이러한 웹폰트의 추세가 국내 글꼴 업체들에게도 좋은 영감을 제공해주리라 기대해본다.

* 이 글은 인터넷 상에 있는 여러 정보들을 재구성하고 글쓴이의 의견을 덧붙인 것 입니다. 문제가 될 수 있거나 잘못된 부분이 있다면 언제든지 지적 부탁드립니다. 참조한 사이트들의 주소는 아래와 같습니다:

• The History of a Model for Fonts on the Web
• The Future of Web Fonts 
• CSS at Ten: The Next Big Thing 
• Making Web Fonts Work
• CSS Fonts Module Level 3 
• Web Open Font Format for Firefox 3.6 
• Why Webfont Services are the Future of Fonts on the Web 
• Reverse Engineering the Embedded OpenType Decompression 
• Font-Face Browser Support and Tutorial