모바일 지원을 향한 몸부림 그러나...

초창기 시절의 SCP 재단은 그야말로 황무지나 다름없었습니다. 위키닷이라는 생소한 위키엔진에 대해서 잘 알고있던 사람이 없었고, 한국어 안내는 커녕 번역도 일일이 해내야했었던 시절이었습니다.

한국어 위키 사이트가 개설된 2012년도 이전부터 SCP 재단에 끊임없이 제기되어온 문제^{[각주:1][각주:2]}가 하나 있는데, 다름아닌 모바일 지원이었습니다. 그 당시만해도 모바일 홈페이지를 개발하여 새로이 만들어서, 기존 홈페이지로 연결하는 것이 대세였습니다. 그래서 사이트 개발 당시에 모바일 지원이라고하면 상당한 문제 중 하나였습니다.

하지만 위키닷에서는 그 어느것도 지원해주지 않았습니다. 위키닷에서 지원해주는 것은 오로지 CSS 편집 뿐. 그렇다고해서 CSS를 능수능란하게 다룰 수 있는 사람이 아니었던 저 역시 어떠한 수를 쓸 수 없었습니다. 자바스크립트까지는 아니더라도 HTML에 대해서 어느정도 편집이 되어야 가능한 일이 많았으니까요.

API

응용프로그램 프로그래밍 인터페이스_{Application Programming Interface}, 흔히 API로 줄여 부르는 것을 사용하여 모바일 홈페이지를 구축해보려는 노력도 있었습니다. 프로 계정에 한해서였지만, 사이트의 API 키를 위키닷에서 제공했으니까요.

결과만 말씀드리자면, 실패했습니다. 앞선 글에도 말했다시피 저는 프로그래밍을 할 줄 모르며, 프로그래밍을 한다고 해도 모바일 홈페이지의 서버 문제, 유지보수 문제 등 직면한 문제가 한두가지가 아니었기 때문입니다. 특히나 모바일에 전념할 수 있었던 환경이 제공되지 않았던 초창기에는 그런 여유가 더더욱 없었습니다.

사실을 말씀드리자면, 지금까지도 이걸 가지고 모바일 홈페이지를 만들 수 있을지는 미지수입니다.

모바일 어플리케이션

API를 어찌저찌하려는 시도를 포기하고나서 눈을 돌린 곳은 모바일 어플리케이션 부분이었습니다. 당시에는 웹앱 개념이 그리 널려있지 않아, 모바일 어플리케이션 하면 바로 마켓에서 다운받고 하는 그런 앱을 말하는 것이었습니다.

당연하겠지만 제가 안드로이드/iOS 등의 모바일 운영체제를 위한 프로그래밍이 가능할 리 없으므로, 외부에 부탁할 수 밖에 없었습니다. 그런 도중에 눈에 띈 것이 SCP 재단 데이터베이스를 가지고 만든 오프라인 앱이었습니다. 재단 콘텐츠를 한꺼번에 다운받아 인터넷에 연결하지 않아도 SCP를 볼 수 있는 앱이었죠.

사실 용량이 지나치게 많다는 것만 빼면 그리 나쁜 선택은 아니었다고 생각했습니다. 곧바로 개발자인 Mykhailo Radzievskyi에게 메일을 보내었고, 긍정적인 답변을 받고선 제가 필요한 부분을 번역해주었습니다. 그래서 생겨난 앱이 SCP 재단 DB kr nn5n 입니다.

개발 당시의 어플리케이션 로고

이 앱은 문제점이 하나 있었습니다. 다름아니라 실시간 업데이트가 되지 않아 업데이트는 개발자의 마음에 달린 것이라는 점이었습니다. 어느정도 필요한 부분만큼 수정을 해야하는데, 이 개발자는 외국인인데다 한국어 위키가 사소한 것까지 요구할 만큼의 관계도 되지 않았고, 그래서도 안되는 것이었습니다.

모바일을 향한 집념은 끊이지 않고

당연하다면 당연하겠지만, 어플리케이션 개발이 되고 나서도 계속해서 모바일 홈페이지에 매달렸습니다. 그러나 어떤 방법을 쓰더라도 매번 모바일 지원에 대해서는 요원하기만 했습니다.

변화가 일어난 것은 2013년 11월이었습니다. 위키닷 공식 블로그에 어떤 소식이 올라왔습니다. 부트스트랩을 적용하고, 이를 위해 HTML을 수정할 수 있다는 이야기였습니다. 이 소식 하나로 인해서 한국어 위키 사이트의 모바일 지원 계획은 다시 재개되었습니다.

반응형 웹 디자인에서 해답을 찾다

한국어 위키의 모바일 지원에 대한 키워드는 다름아닌 '반응형 웹 디자인_{Responsive Web Design}'이었습니다.

기존의 모바일 홈페이지가 PC 버전의 홈페이지를 각각 따로 구축하여 서로 연결하여 관리한다면, 반응형 웹 디자인은 그럴 필요 없이 하나의 HTML 문서만으로도 여러 디바이스에 대응하여 디자인이 바뀌는 것을 말합니다.

반응형 웹 디자인에 대해서 어느정도 개념만 알고 있었지만, 실질적으로 적용하기 위해서는 어느정도 CSS를 능숙하게 다루는 능력이 필요했습니다. 개인적으로 많은 자료를 통해서 CSS에 대한 본격적인 도전을 시작했죠.

반응형 웹 디자인에서 필요한 요소는 여러가지가 있지만, 대표적인 것은 뷰포트, 미디어 쿼리, 유동형 이미지라고 할 수 있습니다.

뷰포트

가장 기초적인 뷰포트는 아래와 같이 정의할 수 있습니다.

메타 태그를 추가함으로써 디바이스에서 홈페이지를 보는 시점을 각 디바이스의 가로폭으로 정의합니다. 위키닷은 메타 태그 편집 기능을 제공하고, 이 중에 viewport 값을 가진 name을 추가할 수 있었습니다.

미디어 쿼리

미디어 쿼리는 디바이스에서 보이는 폭과 높이를 정해서 특정 범위 내에서 나타나는 CSS를 다르게 나타내는 역할을 합니다.

쉽게 말해서 화면이 작아지거나 커질 때 마다 미디어 쿼리를 지정해두면 다른 CSS가 나타납니다. 손이 많이 가고 극단적인 경우지만, 모바일 기기에서 접속하면 아예 다른 테마로 바꿔버릴 수도 있습니다.

괄호₍₎ 안에 들어가는 속성에는 max-width, min-width, max-height, min-height 값 등이 들어갈 수 있고, 값에는 주로 픽셀 단위가 들어갑니다. 미디어 쿼리의 속성과 값을 정의하는 부분으로, 반응형 웹 디자인을 위해서는 가로폭의 최댓값과 최솟값을 지정해 연산자 and로 범위를 지정할 수 있습니다.

미디어타입은 표시될 미디어의 유형을 정하는 것입니다. 여기서는 전체에 적용되어야 하므로, 생략합니다.

중괄호_{} 안에 들어가는 선택자, 속성, 값은 해당 범위에 적용할 CSS 코드를 적용하면 됩니다. 따라서 미디어 쿼리는 미디어 쿼리의 중괄호와 CSS 코드의 중괄호,즉 두 개의 중괄호로 이루어져 있다는 사실에 유의한다면 코딩할 때에 실수를 줄일 수 있을 것입니다.

한국어 위키에 적용한 미디어 쿼리는 총 6개로, 각각 479px 이하, 480px~580px, 581px~767px, 768px~979px, 980px~1399px, 1400px 이상으로 범위를 정했습니다. 이는 패트릭 그래디_{Patrick Grady}의 스크린 경계치에 대한 글^[각주:3]을 참조하였습니다.

유동형 이미지

비단 이미지만이 해당되는 사항은 아니겠지만, 대표적인 경우가 이미지이기에 제목을 이렇게 정했습니다.

이미지는 매우 크지만, 화면이 작아지면 그만큼 이미지가 옆으로 튀어나가게 됩니다. 그렇다면 과연 그것이 올바른 방향일까요?

현재까지도 수많은 홈페이지의 텍스트, 표, 이미지, 광고, 비디오 등이 옆으로 삐져나오는 사이트가 많습니다. 반응형 웹 디자인에 있어서 가장 큰 적이라고 할 수 있는 부분이죠.

이렇듯 옆으로 튀어나가는 주요 항목에 대한 처리가 반응형 웹 디자인의 마무리단계라고 할 수 있습니다.

가장 대표적인 이미지 처리 방식은 다음과 같습니다.

이는 모든 이미지의 최댓값을 강제로 지정하여, 이미지가 스크린의 가로폭 이상으로 늘어나는 것을 방지합니다. 그러나 이렇게되면 이미지가 가로만 줄어들어서 세로로 길쭉하게 늘어날 가능성이 있습니다. 이를 방지하기 위해서는 CSS로 높이를 다시금 정의할 필요가 있습니다.

이렇게하면 이미지는 처리가 됩니다.

성공적인 모바일 지원, 하지만 또다른 문제

결과적으로 반응형 웹 디자인을 이용한 SCP 재단 한국어 위키의 모바일 지원은 성공했습니다. 심지어 태블릿과 와이드모니터까지 지원하는 훌륭한 홈페이지가 되었습니다.

하지만 그에 따른 문제점 역시 따라오게 되었죠.

위키닷의 유료 계정 문제

매년 10월 즈음이 되면 한국어 위키는 고민에 빠집니다. 왜냐하면 SCP 재단을 호스팅하는 위키닷의 유료 계정 만료 기간이 다가오기 때문이지요.

기본적으로 사이트의 관리자는 QAZ135(Acidfrog)님입니다. 초창기 SCP 재단이라는 사이트를 생성하고, 그 생성한 사이트의 안내를 번역하시는 등 기본 구조를 짜는 데 가장 많은 역할을 하신 분이라고해도 과언이 아닙니다.

그러나 현실적으로 위키닷 무료 계정으로는 도저히 재단을 운영할 수 없었습니다. 300MB라는 극히 적은 양의 용량은 1000개가 넘어갈 재단 콘텐츠에 맞지 않았으니까요.

2012년 사이트가 개설되고, 2013년 10월이 되었을 때 한국어 위키는 중대한 갈림길에 서게 됩니다.

2013년 당시 위키닷 계정 안내 페이지

현실적으로 위키 사이트를 운영하기 위해서는 기본계정이 아닌, 프로 라이트 계정이 필요합니다. 조금 과한 감이 있지만, 초창기 한국어 위키는 연 120 달러^[각주:1] 정도 가격의 프로 계정을 사용하고 있었죠.

이를 유지하기 위해서는 당연히 영리적 행위를 통해 수익을 얻었어야 했지만, 한국어 위키는 그러지 못했습니다. 첫째로는 개발자인 저(Devanos)는 사이트에 끼는 광고를 매우 싫어하기 때문이고, 두번째는 광고를 통해 영리적 목적의 수익을 내려는 것이 보이는 모 블로거 때문이었죠. 그래서 한국어 위키는 순수하게 관리자들의 기부제로 돌아갑니다.

2013년에는 서로 많은 일이 있었고 바빠지는 시기였습니다. 그래서인지 최고 관리자였던 QAZ135님이 본인의 관리 부족을 이유로 사임하시고, 이후 새 최고 관리자 투표를 통해 shfoakdls(노래마인)님이 새 최고 관리자가 되었습니다.

Internet Explorer(인터넷 익스플로러)

Internet Explorer 6의 아이콘.

Internet Explorer는 대한민국에서 컴퓨터를 하는 사람이라면 누구나 알고있는 웹 브라우저일겁니다.

이 웹 브라우저로 웹 서핑을 해보지 않은 사람은 손에 꼽을 정도로 적고, 또한 지금도 수많은 사람이 사용하고 있는 웹 브라우저가 다름아닌 Internet Explorer (IE)입니다.

무엇이 문제인가?

대한민국에서는 이 웹 브라우저를 사용하지 않는 사람이 없다고 할수 있을정도로 많은 사람이 사용하고 있습니다. 하지만 그렇기에 IE에 대한 많은 보안 해킹 시도 역시 많아졌죠.

이제 IE를 개발하는 Microsoft사에서는 더이상 옛날 버전인 Internet Explorer 6 (IE6)에 대해서 지원을 하지 않습니다. 그래서 여러 포털 사이트를 중심으로 IE6 퇴치 운동이 벌어지고, 2000년대 초반 95% 이상의 막강한 점유율을 가졌던 IE6는 오히려 반전이 되어 5%대의 점유율도 가지지 못하게 되었습니다^[각주:1].

IE6는 이제 낡은 구시대의 유물이 되었고, 동시에 대한민국 IT의 발전을 막는 주범이 되었다.

SCP 재단이 IE6, 7을 더이상 지원하지 않는 이유

IT 업계는 끊임없이 발전합니다. 그것은 인터넷이 매일같이 수많은 정보를 받아들이며 성장해가고있기 때문입니다. 변화하는 인터넷의 환경에 맞춰 수많은 브라우저가 개발되고있고, 모든 브라우저에서 동일한 내용을 보여주기 위한 방안으로 '웹 표준'이 제시되었습니다.

하지만 웹 표준을 지키지 않고 IE에서만 작동하는 Active X로 점철된 대한민국의 인터넷은 더이상 가망이 없습니다.

따라서 이번 위키닷 업데이트를 통해 SCP 재단에서는 모바일 뷰를 지원함과 동시에 IE 6, 7에 대한 지원을 중단하기로 했습니다.

인터넷 익스플로러 6, 7을 사용하는데 어떻게 해야하나요?

웹 브라우저를 최신 버전으로 업데이트하시거나, 다른 웹 브라우저를 사용하시면 됩니다. SCP 재단은 Internet Explorer 8버전 이상을 지원하며, 다른 웹브라우저에서도 정상적으로 볼 수 있습니다.

아래 아이콘을 클릭하시면 최신 버전의 웹 브라우저를 설치하실 수 있습니다.

사이트는 만들었지만...

초창기의 SCP 재단의 모습은 처음 봤던 제가 보더라도 별로 좋아보이지 않았습니다. 다채로웠던 영어 폰트와는 다르게 한글 폰트는 전혀 지원하지 않았으니 그야말로 굴림의 향연이었죠.

먼저 굴림으로 가득한 사이트 폰트부터 뜯어고쳐야했습니다. 그리고 발견한 점이 위키닷에서는 테마의 CSS를 수정이 가능하다는 점이었죠.

초창기에는 시스템 기본 폰트만 적용되어 전체 글꼴이 굴림이었다.

웹폰트에 도전하다

다행히 CSS를 수정하여 기본 폰트를 윈도우 기본 폰트인 '맑은 고딕'으로 정하는데까지는 성공했지만, HTML과 CSS를 그저 인터넷에서 보고주워들어서 독학한것 밖에 없었던 저에게있어서는 웹폰트라는것을 깨우치기까지는 좀 시간이 걸렸습니다.

이리저리 보고들은건 있어서 네이버와 산돌에서 제작한 '나눔고딕'을 웹폰트로 하기위해 파일을 올려서 적용시켜봤지만...

정말 엄청나게 느립니다. 위키닷 서버가 별로 좋지 않았는지는 모르겠는데, 아무튼 직접 웹폰트를 적용시키니 엄청나게 로딩이 늦어지게 되었습니다.

그러다보니 웹폰트를 포기할까 싶었는데, 그렇다고해서 맑은 고딕이 굴림처럼 모든 디바이스에 있는 상용폰트가 아니다보니 다른 곳에서는 제대로 표기되지 않는 문제점이 있었습니다.

그러다가 발견한게 구글 웹폰트였죠.

웹폰트로 사이트를 개선하다

어떠한 디바이스를 사용하더라도 웹폰트를 사용하면 동일한 폰트가 나오게됩니다. 하지만 전 이걸 약간 바꿔보기로 했죠. 사실 개인적으로 맑은 고딕이 더 좋다는 사적인 이유가 더 컸습니다.

CSS에서 폰트를 정의하는 속성은 "font-family"입니다. 이것으로 각 태그, 아이디, 클래스의 폰트를 제어할 수 있죠.

일단 CSS에서 웹폰트를 쓰기위해 먼저 사용할 웹폰트를 정의합니다.

위키닷을 처음 개설하고 SCP 재단이 사용하는 스킨을 씌웠을때 CSS가 정의하는 폰트는 다음과 같습니다.

사이트가 굴림으로 나오는것은 이 폰트에 한글 폰트가 없기 때문입니다. 따라서 웹폰트를 지정해주고, 기본 한글 폰트를 '맑은 고딕'으로 한 뒤에 그 뒤에 '나눔고딕'을 넣어줘야했죠.

그런데 여기에 문제가 하나 발생합니다. 맑은 고딕과 나눔고딕을 영어 폰트로 쓰기에는 문제가 좀 많다는 점입니다.

영문 폰트가 뒤섞여 가독성이 더 떨어질바에야 차라리 미리 있던 영어 폰트를 적당히 앞에다 놓고, 한글 폰트만 맑은 고딕과 나눔고딕이 적용되게 설정하기로했습니다.

끝에 돋움을 넣은것은 혹시나 맑은 고딕과 나눔고딕이 뚫렸을때(...)를 대비하여 넣었습니다. 물론 웹폰트를 쓰는 나눔고딕이 뚫리려면 CSS 자체를 지원을 안하는 구버전의 인터넷 익스플로러들이겠지만요.

이제 SCP 재단 홈페이지에서는 나눔고딕이 컴퓨터에 깔려있지 않은 수많은 컴퓨터 기기들(특히 스마트폰같은 모바일 기기)에서 접속하더라도 나눔고딕이 보이게됩니다.

처음엔 개발의욕따위는 없었다.

저는 전문적으로 프로그래밍을 배운 사람도 아니고, 그렇다고 고등학교때까지 컴퓨터 프로그래밍이라는게 뭔지도 몰랐으며, 심지어 막상 개발 당시에도 알고있던건 그냥 html이었고, css도 제대로 활용하지 못하는 그런 사람이었습니다.

예, 저는 그냥 독학으로 여기까지 배워온거고, 사실상 지금도 홈페이지를 만들어 구축하라고하면 못하는 사람입니다. 왜냐면 저에게는 서버도 없고, html과 css이외의 자바스크립트, 제이쿼리 등의 지식은 전무하니까요. 물론 html, css 만으로도 충분히 홈페이지 제작이 가능하고, 서버가 없어도 무료 호스팅 사이트를 몇개 알고있긴 합니다만, 결과적으로 '제가 만족스러운' 홈페이지를 자체적으로 구축할 수 없다는 말입니다.

그래서 제게있어서 위키위키라는건 사실상 구축하기도 어렵고, 운영하기도 어려운 전문 프로그래머들의 전유물(?) 비슷한 느낌이었습니다. 사실 그런 고정관념때문에 한국어 위키가 늦어진점도 있죠.

놀랍도록 쉬운 위키닷

위키닷 메인 사이트. 중앙의 your-wiki라고 쓰인 부분에 원하는 서브도메인을 입력하고 Get it now!라는 버튼만 누르면 위키닷 사이트를 개설할 수 있다.

그렇지만 고정관념은 쉽게 깨지곤 합니다. 메인 사이트에서 사이트에 쓰고자하는 서브도메인을 입력하고 몇가지 정보만 입력하면 '짠!'하고 나타나는게 위키닷 사이트였습니다. 심지어 무료 위키호스팅에, 갖가지 관리 시스템은 그야말로 네이버 카페같은곳보다 훨씬 자유롭고 다양한 것이었습니다.

이 사실을 가장 먼저 발견한 것은 여러 한국 SCP 팬들 가운데서도 Acidfrog(QAZ135)님이셨습니다. 현 SCP 재단 한국어 위키 최고 관리자직을 맡고계시죠. 처음엔 위키사이트를 만들었다길래, 저는 이분이 전문 프로그래머이고 사비를 털어 사이트를 운영하시려고 하는줄 알았습니다.

SCP 재단 한국어 위키 제작을 결심하게 된 것은 한달 정도 뒤였습니다. 사실 예전부터 필요한 일이었고, 저도 한번 위키사이트를 운영해보고 싶었기 때문입니다. 그리하여 Acidfrog님에게 문의하여 사이트 관리자가 되었고, 본격적인 개발에 착수했죠.

엔하위키를 찾아가다

제가 관리자가 되자마자 처음 발길을 향한곳은 다름아닌 리그베다 위키(구 엔젤하이로 위키)였습니다. 국내 최초로 SCP 번역이 이루어진 곳이고, 사실상 한국 내에 SCP가 들어오는 방아쇠 역할을 한게 엔하위키의 SCP 재단 번역이었죠. 그렇기에 SCP 재단에서 엔하위키와의 연계는 필요하다고 보았습니다. 하지만 결과는 달랐죠. 뒷부분은 여러가지 사정상 생략하겠습니다.

부족한 한국어 위키 콘텐츠

결과적으로 한국어 위키는 지역사령부 스탭이었던 Acidfrog님, shfoakdls님, 저(Devanos), 단 3명의 번역가로부터 시작했습니다. 지역사령부에 어느정도 번역해둔 양이 있었지만, 제대로 사이트를 운영하기에는 턱없이 모자랐습니다. 그래서 제가 눈길을 돌린것은 '독창적인 콘텐츠'입니다.

그렇기에 가장 먼저 개발에 착수한것이 'SCP-KR'입니다. 사실 한국어 위키를 내건이상 위키백과처럼 'SCP-KO'라고 표기해야 옳으나^[각주:1], 당시에는 이래저래 정황이 없었는데다가 KR이 너무 굳어진 바람에 나중에 알아채고서도 고칠 수가 없었죠. 이래서 처음이 중요하다는 말이 있는걸까요.

SCP-KR을 걸고 마침내 지역사령부 회원들에게만 알려주었던것이 한국어 위키의 임시개방이었습니다. 그때까지 안내를 비롯한 여러 다양한 번역을 매일같이 해야했죠. 개방한 뒤로도 계속해서 번역을 멈출 수는 없었지만요.

공식 사이트로 채택되다

현재는 SCP-KR이라고 표기하지만, 초기에는 이렇게 SCP-Korea라고 표기했다.

SCP 재단 한국어 위키는 아직 많이 모자란 사이트였습니다. SCP 번역량만해도 엔하위키를 따라잡을 수 없었고, 공식 채택을 노리는 사람이 우리만 있는것도 아니었습니다. 그럼에도 지역사령부에 살짝 공개해놓은 작은 사이트가 채택될 수 있었던 이유는 결정적으로 제가 선택했었던 'SCP-KR'이었습니다. 심지어 관리자들은 한국어 위키 채택에 대해서 만장일치로 찬성하기까지했죠.